In our previous blog, we integrated the Amazon Elastic file system with our EC2 instances.
The concept of EFS comes in very handy when we want to run multiple instances in our virtual private cloud, consistently accessing the same data. So, an obvious question arises from here.
Why on earth we would want to run the same server over multiple instances delivering the same content? The answer to this very question is Redundancy.
However the robust architecture and precise configuration our server possesses, we should always ensure redundancy. It is key to higher fault tolerance.
We can divide our traffic among various instances and manage our load as per their availability. The term coined for this approach is load balancing.
Amazon Web Services provides its load balancer which forwards the traffic across multiple targets (say EC2 instances) depending upon their availability. It is termed an Elastic load balancer.
Elastic Load Balancer
ELB can automatically scale its request handling capacity to meet the demands of incoming traffic, justifying the term elastic associated with it.
It monitors the health of registered targets and routes traffic only to the healthy targets.
Also, it serves as an endpoint for clients, and it can add or remove the desired number of instances, which increases the availability of your server or application and ensures high availability.
Apart from the benefits of high availability and elasticity, ELB provides robust networking and security features.
Your load balancer can be internet-facing (public), private (internal), or both (multi-tier architecture).
A multi-tiered architecture can be implemented using internal and public load balancers to route traffic between application tiers.
With this multi-tier architecture, our application infrastructure can use private IP addresses and security groups. It exposes only the internet-facing tier with public IP addresses.
It also provides integrated certificate management. Also, SSL decryption allows you to centrally manage the SSL settings of the load balancer.
It can also integrate with AWS Certificate Manager to enable SSL for your site or application.
You get integrated certificate management, managed certificate renewal and deployment, and SSL decryption, allowing you to centrally manage the SSL/TLS settings of the load balancer.
Best Practices for Using Elastic Load Balancer
- A higher level of fault tolerance can be achieved by placing our target zones in multiple availability zones. So just in case, if one of the availability zones becomes unreachable then the load balancer will route traffic to the available instance in another availability zone.
- Amazon Route 53 provides health checks and DNS failover features to ensure the availability of the applications running behind Elastic Load Balancers. Route 53 disallows traffic from the load balancer if there are no healthy instances registered with the load balancer or if the load balancer itself is unhealthy. Facilitating its features, we can run our servers in various regions and assign alternate load balancers across regions for failover. If a load balancer becomes unhealthy or unavailable, route 53 will remove that load balancer endpoint from service and route the traffic to the available load balancer in another region.
- Amazon Autoscaling also ensures a specific count for healthy instances. It can also generate instances on-demand to meet conditions. Autoscaling is configured in front of our ELB and provides better availability, fault tolerance, and cost management. Cost-effective in the manner that we only pay for instances being needed at the moment.
- Assign security groups to ELB to control exposed ports from the security point of view. Each subnet for your load balancer should have a CIDR block with at least a /27 bitmask and at least 8 free IP addresses. Load balancer uses this IP addresses to establish connections with instances.
- Enable HTTP keep-alive in the web server as it enables the load balancer to reuse connections to instances, which reduces CPU utilization. HTTP keep-alive time should be greater than the idle timeout setting on the load balancer.
Classification of Elastic Load Balancer
Elastic load balancer is broadly classified as Classic load balancer and Application load balancer.
- Quoting from the AWS docs, “Classic Load Balancer routes traffic based on either application or network level information, and the Application Load Balancer routes traffic based on advanced application level information that includes the content of the request.
- The Classic Load Balancer is ideal for simple load balancing of traffic across multiple EC2 instances, while the Application Load Balancer is ideal for applications needing advanced routing capabilities, microservices, and container-based architectures.
- Application Load Balancer offers the ability to route traffic to multiple services or load balance across multiple ports on the same EC2 instance.”
- This has been a brief introduction to Amazon Elastic load balancer. In our next blog, we will dive a little deeper into Elastic load balancer classification and configuration.
Need Support?
Thank You for reading this Blog!
For further more interesting blogs, keep in touch with us. If you need any kind of support, so simply raise a ticket at https://webkul.uvdesk.com/en/.
You may also visit our Magento development services and quality Magento 2 Extensions.
For further help or queries, please contact us or raise a ticket.