How do you manage your REST API on AWS so that it scales with traffic?
AWS offers two front-end traffic managers for REST APIs: Amazon API Gateway and Application Load Balancer (ALB). But which one is "better"?
Previously, we compared the cost profiles of Amazon API Gateway and Application Load Balancer (ALB). But costs are only one factor when deciding which solution is best for your architecture. In this write-up, I’ll compare the benefits - and limitations - of each service.
Application Load Balancer (ALB)
ALB is part of AWS's Elastic Load Balancer feature. It's the go-to traffic manager for many AWS-hosted apps - and for good reason.
Elastic Load Balancer supports several different types of load balancers that operate at different layers of the OSI reference model. As its name denotes, ALB operates at Layer 7, the Application layer. An ALB serves as a single endpoint routing HTTP requests to a number of back-end resources. These can be Amazon EC2 virtual machines, Amazon Lambda functions, or Docker containers hosted in Amazon Elastic Container Service (ECS).
An ALB typically exposes a public Web address endpoint whose resources are hosted in private subnets in an Amazon VPC. Private ALBs, accessible only from within an organization’s internal network, are also supported. Application developers define resources in target groups and specify routing rules that determine how to send incoming traffic to target groups. Target groups can support either HTTP/2 or WebSocket connections.
Within target groups, requests are balanced across resources to ensure that no single resource is overwhelmed. By default, ALBs use a round-robin algorithm, distributing requests evenly across resources. Developers may also use a least outstanding requests algorithm. This sends requests to the resources with the fewest number of current HTTP and HTTPS requests.
Additionally, ALBs can define health checks to monitor the state of running resources in a target group. If a resource fails its health check consistently, it’s temporarily removed from availability.
The flexibility of ALBs means they can be used for multiple purposes in a Web application architecture. Developers can use ALBs, target groups, and routing rules to build microservice architectures using any number of technologies on the back end.
Amazon API Gateway
API Gateway exists specifically for creating, publishing, and maintaining microarchitecture services at scale. Using API Gateway, developers can create stateless, HTTP-based method calls that can provide services to any number of applications in a highly scalable and decoupled fashion.
Using API Gateway, a developer can model an API much as it exists in code - as a series of paths that correspond to REST operations. API Gateway uses path-based routing to map a path to a back-end service, called an integration in API Gateway parlance. Using an HTTP integration, for example, a developer can tie their API calls to a set of tasks running on an Amazon ECS cluster.
API Gateway is specifically designed for REST APIs. As such, it supports a number of features that enable developers to publish and manage their APIs more quickly and easily:
- Deploying an API in multiple stages (such as dev, test, stage, and prod).
- Shipping a test canary. With canaries, you can vet a new release of an API to a select portion of your user base.
- Specifying throttling limits to rate limit API calls, preventing unnecessary cost spikes and potential Denial of Service attacks.
For API creation, API Gateway supports the OpenAPI standard. This enables mocking out your API in a tool such as Swagger or Postman and then importing it into AWS. API Gateway also supports creating and exporting API documentation using the OpenAPI standard.
Similarities Between ALB and API Gateway
Based just on this short description, you can see there’s a lot of overlap between ALB and API Gateway. Both services act as front ends to your back-end API applications. And they each support key higher-level services required by most industrial-grade APIs, such as authentication and monitoring.
A key challenge with microservice architectures is providing a method for other applications and services to discover a dependent service's current DNS information. Both ALB and API Gateway can leverage AWS Service Discovery. With Service Discovery, other services can look up another service's metadata and DNS information using a friendly name and other associated metadata, such as version and stage name.
Both ALB and API Gateway can also enhance your application’s security posture. There's no need, for example, to expose an entire EC2 instance or Docker container to the public Internet. Instead, developers can use ALB or API Gateway to tie a set of public endpoints to AWS resources running in a private subnet in a VPC. This reduces the potential attack surface area to which a would-be intruder might have access.
ALB and API Gateway both also support an authentication layer to verify a user’s identity before granting them access to privileged resources. Additionally, ALB and API Gateway can both expose their endpoints via AWS PrivateLink to provide secure API services to private VPC and on-premise networks.
Differences Between ALB and API Gateway
Despite the similarities, there are some key differences between ALB and API Gateway that could influence your decision over which one to adopt.
Both ALB and API Gateway can scale to meet massive demand. However, API Gateway by default has a soft limit of 10,000 Requests per Second (RPS) per AWS region per account. (Customers can raise that limit by request.) By contrast, ALB has no pre-set request rate limit.
The major advantage of ALBs is their ability to distribute load intelligently across resources. This makes them ideal when using services such as Amazon EC2 or Amazon ECS, where a single instance or task could become non-operational if flooded with requests.
Also, as we discussed previously, ALBs rule when it comes to cost at scale. API Gateway is more affordable than ALB for up to around 500,000 monthly transactions. But at larger scales, API Gateway’s costs quickly accumulate, and ALB becomes the much more affordable solution.
It should be noted, however, that API Gateway pricing is much more transparent. API Gateway charges based strictly on total number of requests. (Data transfer charges may also apply if you're transferring data out of AWS.) By contrast, ALB uses a complex metric of Load Balancer Capacity Units (LCU) that's harder to calculate. This makes it more difficult to predict costs.
Advanced API Management Features
API Gateway's direct mapping to the REST API framework and its multitude of REST-oriented features make it ideal for implementing and maintaining REST APIs at scale. Some features, like throttling, can be implemented (via AWS WAF) easily in ALB. However, other features (such as stages) require more heavy lifting to emulate.
AWS Feature Integration
API Gateway has additional ease of use advantages, such as its integration with services like AWS Lambda. The service also supports integrations for major AWS features such as Amazon S3 and Amazon Kinesis. That simplifies the task of exposing a portion of your AWS services to your user or developer base.
API Gateway also has a slight advantage with security configuration, as it supports HTTPS out of the box. ALB also supports HTTPS but requires configuring and deploying an SSL certificate to your load balancer.
Summary of Differences Between ALB and API Gateway
The following table summarizes some of the key differences between ALB and API Gateway:
|Protocols supported||HTTP/2 (HTTP API, REST API), WebSockets||HTTP/2, WebSockets, gRPC|
|HTTPS||Out-of-the-box support||SSL certificate configuration required for SSL termination|
|A/B testing support||Support through defining separate routes||Load balancing based on % of traffic|
|Load balancing strategy||Round robin||Round robin or least connections strategies|
|AWS service integration||Amazon EC2, Amazon ECS, AWS Lambda, Amazon S3, Amazon Kinesis||Amazon EC2, Amazon ECS, AWS Lambda|
|Sticky session support||No out-of-the-box support||Direct support|
|REST API management support||Integrated REST API management platform||Requires additional coding to support|
|Scalability||Soft limit of 10,000 RPS||No predetermined scalability limits|
Which to Use?
Many AWS feature choices are about trade-offs. This one is no different.
While ALB is the clear cost-leader at a massive scale, API Gateway provides numerous features that could save development teams hours of maintenance in the long run. If you'll utilize more than one of the features of API Gateway, you'll likely make up what you pay for the feature in terms of saved development and support costs.
Finally, we’d be remiss if we didn’t point out that, sometimes, the answer to the question of ALB versus API Gateway is “both”! An HTTP API in API Gateway can itself redirect to an ALB, which then load-balances requests across back-end resources such as EC2 instances or Docker containers. Such an architecture is ideal if you want to add load balancing capabilities to the powerful REST API management capabilities of API Gateway.
Bottom line: use ALB if pure cost/performance is your most compelling need, and API Gateway if you're looking to trim development and support costs.
The TinyStacks Approach
AWS contains a ton of features like ALB and API Gateway. Both features can meet an array of application team's needs. But choosing between them often involves days - or even weeks - of analysis and testing.
Now multiply that by the dozens of other choices you're forced to make when launching your app on the cloud. It's no wonder developers frequently complain that AWS is too complicated.
TinyStacks simplifies AWS with an intuitive interface that enables your teams to launch their apps on the cloud in minutes - not weeks or months. Our full application stacks contain everything your apps need to run. We even support creating ALB and API Gateway front ends - and switching between them as your application's needs change.
Check it out today and let us know what you think!