AWS API Gateway vs. Application Load Balancer (ALB)

Ready to monitor your serverless applications?

Dashbird Banner

Instantly find and prevent your serverless errors!

Get free account

We recently wrote about whether API Gateway can act as a Load Balancer. The answer is yes and, in many cases, they are substitutes for each other. But how should we choose which one to use?

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).

Scalability

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.

API Gateway has a limit of 10,000 RPS (requests per second), which might not be enough for some cases. When we look at Regional and Edge APIs, the limit is a lot more concerning: 600 and 120, respectively. More troublesome is that the last two can’t be increased, while the larger quota can on a per-request basis.

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.

ALB, on the other hand, is virtually unlimited. In fact, AWS specifies no limits in terms of connections per second or concurrently in the service quotas page. It can easily scale to handle +100,000’s RPS in a second and, in principle, could go beyond millions of RPS as well at these levels, it’s probably a good idea to pre-warm the Load Balancer with the help from the AWS support team, as well as to conduct stress tests and make sure the architecture is well optimized for the load.

Dashbird Logo

Get alerted of issues in your API endpoints!

Dashbird helps you monitor serverless applications at any scale.

Get started free

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.

Integrations

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.

Cost

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 second
  • 3,000 active connections per minute
  • 1 GB of traffic per hour for EC2 instances, or 0.4 GB per hour for Lambda functions
  • 1,000 routing rule evaluations per second

When any of these dimensions are exceeded, the ALB will charge an additional LCU for the hour.

Other features

WebSockets

Supported by both API Gateway and ALB.

Tracing

ALB injects an “X-Amzn-Trace-Id” header into all requests routed to downstream resources. Tracing can be enabled for API Gateway to work integrated with X-ray.

Firewall

Both the API Gateway and ALB can be protected by AWS firewall service WAF.

Authentication

API Gateway offers its own token-based authentication system, as well as integration with Cognito. ALB also offers integration with Cognito and any other identity provider that is compliant with OpenID Connect standards.

Logging

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.

Monitoring

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.

Thousands of developers are using Dashbird to stay on top of their infrastructure and avoid the embarrassment of getting blindsided and alerted of issues in their API endpoints by their customers or company executives. Join them – it’s free, doesn’t require any code changes and only takes 2 minutes to set up.

api gateway monitoring

Sign up now

Read our blog

Daniel Grzelak joins Dashbird’s advisory board

Dashbird is thrilled to welcome legendary security executive, Daniel Grzelak, to its advisory board. Daniel is currently serving as the Security Chief of Staff at Atlassian.

How to check NFT supply with AWS Lambda?

How can serverless technology be used in tandem with blockchains? Find out how we built a Lambda function to monitor NFT supplies.

Python Error Handling in AWS Lambda

Best Practices and need-to-knows for error handling in Python AWS Lambdas.

Made by developers for developers

Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.

What our customers say

Dashbird gives us a simple and easy to use tool to have peace of mind and know that all of our Serverless functions are running correctly. We are instantly aware now if there’s a problem. We love the fact that we have enough information in the Slack notification itself to take appropriate action immediately and know exactly where the issue occurred.

Thanks to Dashbird the time to discover the occurrence of an issue reduced from 2-4 hours to a matter of seconds or minutes. It also means that hundreds of dollars are saved every month.

Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.

I mean, it is just extremely time-saving. It’s so efficient! I don’t think it’s an exaggeration or dramatic to say that Dashbird has been a lifesaver for us.

Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.

Great UI. Easy to navigate through CloudWatch logs. Simple setup.

Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.