Battle of the Serverless API Routers: ALB vs. API Gateway - Feature Comparison
Recently, we looked at how Amazon API Gateway and Application Load Balancer (ALB) compare as API routing solutions in terms of cost at scale. But costs are only one factor when deciding which solution is best for your architecture. In this write-up, we’ll go beyond cost and compare the benefits - and limitations - of each service, and when you might choose from a functionality standpoint to choose one over the other.
Application Load Balancer
AWS’s 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 - such as 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, which 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 EC2 instances, Docker containers hosted on Amazon ECS, or AWS Lambda functions as the functional 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 their 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. For example, API Gateway has built-in support for deploying an API in multiple stages (such as dev, test, stage, and prod), and for shipping a test canary to vet a new release of an API to a select portion of one’s user base. API Gateway also directly supports 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 features act as front ends to back-end AWS services. Both also 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, enabling other services to lookup 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. Instead of exposing, for example, an entire EC2 instance or Docker container to the public Internet, 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. Finally, ALB and API Gateway can both expose their endpoints vis 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.
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.
But that doesn’t mean that API Gateway lacks advantages. The service’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. While some features, like throttling, can be implemented (via AWS WAF) easily in ALB, others, such as stages, require more heavy lifting to emulate.
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, simplifying 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.
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.
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|
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. Which one you choose will come down to your specific application scenario, and the role that cost plays versus other factors such as speed of development and ease of maintenance.