Rationale
AWS ELB (Elastic Load Balancing) is the service we use for exposing applications to the Internet. It provides load balancers using an IaaS model.
The main reasons why we chose it over other alternatives are the following:
- It seamlessly integrates with VPC, EC2, EKS, etc., allowing for the easy serving of applications hosted in the cloud.
- It complies with several certifications from ISO and CSA. Many of these certifications are focused on granting that the entity follows best practices regarding secure cloud-based environments and information security.
- When combined with Kubernetes, it allows to balance application load by distributing requests to multiple replicas using a horizontal scaling approach.
- It has its own Kubernetes module for automatically provisioning application load balancers when Kubernetes applications are deployed. This is specially useful for serving ephemeral environments.
- It supports VPC security groups, allowing us to easily set networking inbound and outbound rules for the load balancers. Such a feature is essential for avoiding CDN bypassing.
- A single load balancer supports multiple availability zones, granting networking redundancy, which is essential for keeping it always available to the Internet.
- It supports health checks, allowing for the constant monitoring of all the endpoints associated to a load balancer. Application requests are only sent to healthy endpoints.
- Application load balancers support rules, allowing us to create complex routing scenarios when it comes to request forwarding.
- It supports application load balancers, network load balancers, and gateway load balancers, providing infrastructure for a wide range of solutions.
- Load balancers can be monitored via CloudWatch.
Alternatives
Usage
We use ELB for
We do not use ELB for serving our website, as it is a static site served by S3, which directly provides endpoints without having to manage load balancers.