We've covered the preceding WebSocket use case for API Gateway, so let's explore a few more at a high level. Some of the examples are not strictly serverless but we're looking to get a broad understanding of where this technology is useful.

The first use case to cover is the Serverless API model, where all of the components that you use live within the serverless category in the AWS ecosystem. You can build a RESTful API backed by Lambda that stores documents or state in a DynamoDB database. 

The following shows the request flow with API Gateway exposing a RESTful API and Lambda used as the compute backend, which performs actions on a DynamoDB table:

This is a really simple model and there is surely an unlimited number of examples you can apply this to. If the type of processing or compute that you need to do is multi-step or needs greater control or orchestration, you can use API Gateway in front of AWS Step Functions. Invoking a method on Gateway can kick off a workflow in Step Functions that can invoke Lambda functions.

In this example, we have added API Gateway in front of step functions to add our layer of API management and give us the flexibility to implement our own logic or transformations before the execution of a state machine. This example doesn't need to include a DynamoDB table because our state is stored in a Step Functions state machine. Lambda is used as our compute provider:

Flow of a REST request as a proxy to a Step Functions state machine

API Gateway also enables APIs for container-based microservices. You could roll your own container orchestration on EC2 with an API in front. 

The following example shows API Gateway in front of a compute workload. The auto scaling group contains EC2 instances running containers, with the load and session durability being provided by an Elastic Load Balancer:

Or you could pick from one of the many managed container platforms that AWS offers such as Amazon ECS, Amazon EKS, AWS Fargate, or Amazon Elastic Bealkstalk (for Docker). The diagram for these examples would look much the same as the preceding. Container platforms also use EC2 for their compute workloads but are managed by a separate control plane.

Before we finish, let's look at one additional use case that is slightly different: securing a backing AWS service by setting up a service proxy. Every service in AWS has a public API. Sometimes, you want to expose the functionality of that API to your clients. You might also want to augment or restrict parts of the API, and you will definitely want to add your own web security controls. 

The following diagram shows an example of using API Gateway as a service proxy to Amazon Kinesis:

This is a way to enable clients to publish events directly into Kinesis using the PutRecord method. You might want to use this design to ingest clickstream events or for IoT devices. As discussed earlier, using API Gateway in front of any service can abstract the implementation of the underlying compute or data store. This makes the implementation modular and flexible, allowing you to migrate the backend to something else without significantly impacting the consumer. For the preceding Kinesis example, you might want to migrate to another event-sourcing solution such as Kafka in the future. Keep this in mind when building your own APIs because, as your technology options evolve, you want to maintain flexibility and agility so you can change your systems to make use of the benefits of newer technology.

That was an introduction to Amazon API Gateway, deployment options, and some common deployment patterns. Next is an important topic—how to secure our APIs.