June 15th 2020
CEO of Dashbird. 13y experience as a software developer & 5y of building Serverless applications.
In this article, we will dive into more details on how these two types of HTTP networking services compare, using the AWS services as a base level: API Gateway and Application Load Balancer (ALB).
Both are highly-scalable services to a point that scalability should not be a concern for most use cases. For high-throughput applications, though, there are differences that need to be considered.
The 10,000 limit also benefits from burst capacity – up to 5,000 additional RPS – in peak demand moments. However, AWS does not take any hard commitments, and developers can’t control or predict how the burst capacity will be allocated. In practice, it’s risky to rely on it for purposes that involve user-facing endpoints.
Reliability and Availability
Both services are managed by AWS. API Gateway is highly reliable and available out of the box, developers do not have to worry about anything here. ALB requires developers to specify more than one Availability Zone per region to reach a higher level of availability.
For Serverless applications, API Gateway was the only way to go until recently, when AWS announced the integration of ALB with Lambda functions.
Apart from Lambda functions, ALB can route requests to EC2 instances, ECS containers, and IP addresses. It also integrates with AWS Cognito for user authentication and authorization purposes.
API Gateway, on the other hand, is much better integrated with AWS’s managed services. Apart from Lambda functions, it can also integrate with virtually any other service that is available through HTTP requests, such as DynamoDB tables, SQS queues, S3 buckets, etc. Even external HTTP endpoints hosted outside of AWS can be integrated through HTTP.
It’s also possible to customize requests before forwarding to downstream resources, and also the responses from these resources before sending back to the clients. This way, API Gateway can even replace many use cases when a Lambda function would be needed as simply an intermediary, cutting costs and improving performance.
Request Routing Capabilities
API Gateway supports path-based routing. In other words, developers can configure which resources will receive incoming API requests based on the URL requested by the client.
ALB, on the other hand, offers a rule-based routing mechanism. Apart from supporting a URL path-based approach similarly to API Gateway, it also provides:
- Requester Hostname
- Requester IP address (CIDR blocks)
- HTTP Headers
- HTTP Request method (POST, GET, etc)
- Key/value pairs incoming as query strings
It is possible to combine multiple conditions based on the options listed above, but there are some limitations. Wildcards are also supported, making the rule system flexible enough for most use cases.
Based on a fully Serverless pricing model, API Gateway charges only for requests received. The price depends on what type of API service is used:
- Rest APIs: from $1.51 to $3.50 per million requests
- HTTP APIs: from $0.90 to $1.00 per million requests
- WebSockets: from $0.80 to $1.00 per million requests, plus $0.25 per million connection minutes
ALB charges based on two dimensions: time and resource usage. The first is straightforward: $0.0225 per hour. The second is a bit more complex: $0.008 per LCU-hour. LCU measures traffic processed by ALB. One LCU can support:
25 new connections per second3,000 active connections per minute1 GB of traffic per hour for EC2 instances, or 0.4 GB per hour for Lambda functions1,000 routing rule evaluations per second
When any of these dimensions are exceeded, the ALB will charge an additional LCU for the hour.
Supported by both API Gateway and ALB.
API Gateway stores access logs in CloudWatch (optional). For teams relying on AWS Lambda, that can be a convenience factor, since the Serverless functions will also store its logs in CloudWatch. ALB can only store access logs in an S3 bucket. This can be inconvenient for development teams since it’s necessary to download logs from S3 and index somewhere else for searching and debugging purposes.
Both services have health tracking and metrics generated by CloudWatch.
Although many teams developing on AWS are used to rely on CloudWatch, it can be cumbersome for debugging and monitoring tasks. The error detection and alerting capabilities are limited as well, leaving developers in the dark.