In previous articles, we talked about how to build a REST API in a serverless way, and in a more advanced example, we covered how to deploy a serverless GraphQL API with Hasura. In the first example, we explained how to use API Gateway to route requests to Lambda functions, while in the second example, we used ELB to solve the routing. However, neither of the two explains the differences between both products or when to use one over the other. In this article, we will shed some light on this.
Application Load Balancer (ALB) satisfies the increasing need of organizations to move towards microservice architecture, making the mapping between single addresses and specific services easier. Although it supports a lot of other features (SSL Termination, Sticky Sessions, etc.), in the context of this article, we want to highlight the ability to manage routes based on user defined rules. But before we do that, let's try to explain the differences between ALB and Elastic Load Balancer (ELB), a classic product with a longer history which most AWS engineers are familiar with. To understand the differences, we need a basic understanding of the Open Systems Interconnection Model, or OSI Model. You can learn more about the OSI layer and its history on Wikipedia, but basically, ELB operates at Layer 4, and ALB operates at 7. ELB operates at Layer 4 (Transport layer) so it’s controlled by the protocol that is used to transmit the request. In web applications, most of the time we use TCP/IP, although UDP may be used too. Basically, ELB reads the protocol and port of the incoming request and then routes it to different backend servers. In contrast, the ALB operates in Layer 7 (Application Layer), so it allows the redirection of traffic based on the content of the request. Then, a request to a URL that is resolved to an ALB can route traffic to different services based on either the host or the content of the path contained within that URL.
AWS API Gateway is an interface that separates the application from the microservices, acting as a single point of access. Without that interface, you’d have to connect to all your API resources directly, making it more difficult to manage the interaction with client applications. API Gateway can manage and balance traffic just as a Load Balancer, but in a different way. Instead of distributing requests evenly to a set of backend servers, it can be configured to redirect requests to a specific resource based on the endpoint being requested. I know what you may be thinking: “AWS ALB can do all of that too - So is it the same?” Not really. Although it can be used for the same purpose (more about this in the next section), API Gateway offers many additional features such as authentication & authorization (i.e. integrating with Identity Access Management -IAM-), API token insurance, and it even generates SDKs based on an API structure.
To do an unbiased comparison, we will use a subset of the architectural quality attribute list from Chapter 7 of this book. Analyzing each one will provide a better understanding of both AWS’s products and help you choose which one is more suitable for your needs.
If you have chosen a cloud solution, especially AWS, it should be due to its reliability. Both products are highly reliable and available just out of the box, so you don’t have to worry about anything here. But… maybe, with ALB you can define more than one Availability Zone to improve the level of availability you offer.
Also, in this category, both are highly-scalable products and it should not be a concern for most use cases. But for those who expect a high use of many computing resources over long periods of time, you can take this into account. API Gateway documentation sets an explicit limit of 10000 RPS (requests per second), with an additional 5000 RPS in peak demand moments (not controlled by developers, so it’s risky to rely on it). Also, when you look at the Regional API, the limit falls to 600 RPS, without the possibility of increasing it. ALB on the other hand is virtually unlimited (the documentation doesn’t even specify limits in terms of requests or concurrency). It can easily scale to handle more than 100000 RPS in a second and even go beyond, although it could be a good idea to pre-warm the Load Balancer with the help of the AWS support team.
Until AWS announced that Application Load Balancer can now Invoke Lambda Functions to Serve HTTP(S) Requests, the only way to access serverless applications from any HTTP client was using API Gateway. So, ALB lets you invoke Lambdas, in addition to routing requests to IP addresses, EC2 instances and ECS containers. On the other hand, API Gateway is much better integrated with other AWS products. Aside from Lambdas, it can basically integrate with any other service that is available through HTTP requests, such as S3 buckets, SQS queues and DynamoDB tables. Also, it’s powerful enough to let you change requests before they are forwarded to downstream resources and responses from them, before they are sent back to the clients. This can reduce the costs associated with Lambda functions that are used just as simple intermediaries, in addition to improving the overall performance.
The routing mechanism of both deserves a separated treatment of each. API Gateway works with a path-based routing, so you can configure which resource will receive incoming requests based on requested URLs. ALB on the other hand has a rule-based routing system that supports the path-based approach plus rules based on:
- HTTP headers
- HTTP request methods (GET, POST, etc.)
- Querystrings
- Requester IPs and hostnames
ALB injects a tracing header variable called ‘X-Amzn-Trace-Id’ into all the requests routed downstream. Tracing can be enabled for API Gateway to integrate with AWS X-Ray. As for logging, API Gateway stores access logs in AWS CloudWatch, the same place as your Serverless functions (Lambdas). In the case of ALB, logs are stored in S3 buckets, so the development team needs to download them and index somewhere else for searching appropriately. Finally, both products have health tracking and metrics generated by CloudWatch to make health monitoring easy.
Both products support integration with AWS Cognito for user authentication and authorization purposes. ALB also offers integration with any other identity provider compliant with OpenID Connect standards.
This question (as always with AWS products) is core. As usual, you have a free tier to consume and test the product (that is very generous to start with) before AWS starts charging you for its use. API Gateway charges only for the received requests, and the price depends on the type of API service you are using. If you are using the HTTP APIs you will be charged only for the number of requests, and the price ranges between $0.90 - $1.00 per million of monthly requests. REST APIs have a more complex billing schema, charging you by the number of requests, the amount of data transferred out and data caching. Costs range from $1.51 to $3.50 per million monthly requests, with an additional cost of $0.02 to $3.80 per hour of use for a cache ranging from 0.5 GB to 237.0 GB. The last type are the Websocket APIs that will charge you by messages sent and received, and the total number of connection minutes, ranging from $0.80 to $1.00 per million of monthly requests. ALB on the other hand charges you taking into account time and resource usage. So, the first part of the equation, the one related to time, is straightforward because it costs $0.0225 per hour per Application Load Balancer-hour. The second part is more complex because it’s measured in LCU-hour, where LCU measures the traffic processes by the ALB. One LCU supports:
- 25 new connections per second
- 3,000 active connections per minute
- 1 GB per hour for EC2 instances, containers and IP addresses as targets and 0.4 GB per hour for Lambda functions as targets
- 1,000 rule evaluations per second
This gives you an approximate cost of $0.008 per LCU-hour (according to the examples provided here). The example below (taken from here) shows the differences in terms of cost of the same API using both products.
If you don’t need the additional features provided by API Gateway, you should think about using ALB instead, since it can be cheaper in many cases. Although it’s not easy to compare both because (as we saw above) they use different approaches to charge you, low traffic APIs might be more cost-effective on API Gateway while high-traffic ones can be better on ALB instead.
Ready to get started? Use the form or give us a call to meet our team and discuss your project and business goals.
We can’t wait to meet you!
Call us!
+1 (347) 871 09 22
Write to us!
info@vairix.com
.svg)
.svg)
.svg){kind=icon}
.svg){kind=small}