There are several reasons for using an API Gateway, and the first is to abstract the implementation of your application or service away from the client. This is to allow you to have greater flexibility in how the business logic and processing are built, and so that the client doesn't have to understand the underlying data structures or storage layer.

In Chapter 1, The Evolution of Compute, we covered the basics of a microservice, and an API gateway is an integral part of enabling microservices to function. This is because an API layer serves as a common, structured, and predictable way of communicating with a service. The API specification or interface can be published so other microservices and consumers know how to request information and know what format the response will come back in. This is a key premise for a RESTful service.

Another reason for a gateway component is to offload the responsibilities for authentication, authorization, and certificate management. This can lighten the load on a microservice and allow the implementation to be reused for other microservices. This also helps the developer to focus on building the business logic needed for the service.

An API gateway, and especially Amazon API Gateway, can protect your service against attacks because of the way it was designed. Amazon CloudFront sits in front of API Gateway to filter requests and distribute traffic across edge locations. One of the benefits of leveraging CloudFront is that it also has AWS Shield built-in as standard. Shield protects against layer 3 and 4 Distributed Denial-of-Service (DDoS) attacks. 

As in the following diagram, we see that Amazon API Gateway has network and transport layer DDoS protection out of the box. It also has some controls for layer 7 attacks, including the ability to set usage plans so requests can be throttled after a configurable request rate. Also available is Amazon Web Application Firewall (WAF), which can mitigate common web-based attacks at the application layer (layer 7):

So, it's clear that a combination of Amazon API Gateway and other AWS components is a formidable security mechanism for publishing APIs. The reason I usually talk about security when I first introduce a technology is that it should be one of the first aspects of a service that a technology option is evaluated on. If an option can't adequately secure your workload, that's the end of the story.

There are several other benefits as well. Continuing the theme of this book, API Gateway is serverless. You will be familiar with this already—API Gateway is a managed service with no infrastructure you have to manage yourself. Scaling is also taken care of, with the ability to transparently scale from 1 request per second to 10,000 (a default limit that can be increased). APIs can be deployed and published very quickly, and high availability is inherent.

Let's check out what a typical deployment could look like at a high level:

The preceding diagram shows several clients traversing the internet to reach CloudFront, which provides the edge connection. The integration with API Gateway here is internal; you can't actually view the distribution that API Gateway created in the console. A cache is available should you want to reduce the requests to your backend. The implementation under the hood is Amazon ElastiCache but again, we don't get to view the details of what API Gateway creates in the ElastiCache console. API Gateway is natively integrated into CloudWatch, sending metrics and logs to a central location for a consistent experience across the services. Lastly, on the right-hand side, we can see several options for backend integrations. API Gateway can natively invoke Lambda functions—we'll explore this in-depth in this chapter.

Also, an interesting point to note is that you can create an integration with any HTTP endpoint. This includes services running on your data center provided there is network connectivity. In an upcoming section called Securing an API, we will also show you how to integrate API Gateway with Amazon Cognito for authentication and authorization.

Amazon API Gateway can act as a service proxy, which is an interesting concept. This functionality allows you to create an HTTP endpoint to expose an AWS service as a backend. What this enables you to do is apply your own RESTful API definitions with all of the additional benefits of web-type security controls and traffic management. And you can skip your compute layer altogether. An example use case could be when you need your frontend web application to store some data, such as comments on a thread or messages in a chat. Using DynamoDB as a service proxy integration point would allow you to implement a CRUD-like API that the frontend can directly interface with. There are plenty of other useful examples as well, and we'll have a look at some of those in the Use cases section.

So, what happens when we connect up a Lambda as a backend integration? At a high-level view, here is the sequence of events performed by API Gateway:

1. Receives the request
2. Authenticates and authorizes the request
3. Applies the mapping template
4. Invokes the Lambda function
5. Applies output mappings to translate the Lambda response if required
6. Responds to the client

Let's take a quick look at what options are available for authentication and authorization. We'll go into detail later in the Securing an API section:

• First, there are API keys. These are long-lived keys that you can issue and attach to a set of permissions. To use a key to access an API, you need to add it to a header called x-api-key. It is not advisable to use API keys as a primary means of securing an API because of the risk of the key being leaked. Instead, they are more suited for use in development and testing environments where you are not using production data.
• Another option is to use a scoped IAM credential and sign the HTTP request using Signature Version 4 (SigV4).
• The next option, and probably the recommended option in most cases, is to use Amazon Cognito (https://aws.amazon.com/cognito/).
• Finally, you can also create your own authentication and authorization implementation with the use of Lambda authorizers.

You can also pair API key protection with the other methods if you need to, and it is definitely recommended that you pair the use of API keys with a stronger authentication method.

As far as pricing goes, you're in luck—it's pretty cheap. Following the serverless model, you only pay for what you use. The free tier includes one million API requests per month for free for a year. If you pair that with the free tier Lambda invocations, then it's likely you won't be paying anything at all to run a simple RESTful API.

When you go over that amount or your account is older than a year, then the API Gateway cost is $3.50 per million requests. It is tiered pricing, so the more you use, the cheaper it will be but note that the next tier is at 1 billion requests per month! Also note that the pricing and tiers vary between regions, so check on the pricing page to find your region. Caching, data transfer, and CloudWatch all have additional costs as well.

Something to be aware of before going into production with an API is the account-level service limits. By default, API Gateway has a maximum throughput that is throttled to 10,000 requests per second with a burst capacity of 5,000 requests. Clients will receive an HTTP 429 response if this happens. The limit can be increased with a support request. Another limit to be aware of is the payload size. The maximum amount of data you can send with a request is 10 MB, and this cannot be increased. There's a trap for young players here as well. The maximum payload size of a Lambda request is 6 MB, so you will find that requests will fail if the payload is over 6 MB even though they are within the valid size for API Gateway.