Advanced Load Balancing Techniques with AWS ELB

Elastic Load Balancing (ELB) is a service provided by Amazon Web Services (AWS) to distribute incoming traffic across multiple EC2 instances. By balancing application requests across multiple servers, ELB improves fault tolerance and provides better performance.

In this tutorial, we will cover some advanced techniques to get the most out of AWS ELB and improve your application’s scalability and availability.

Overview of AWS ELB

AWS offers three types of load balancers:

Classic Load Balancer (CLB) — The original AWS ELB, routes traffic based on either application or network level data.

Application Load Balancer (ALB) — Routes traffic to targets within Amazon Virtual Private Cloud (Amazon VPC) based on the content of the request. Provides advanced request routing targeted at modern application architectures.

Network Load Balancer (NLB) — Routes traffic to targets within Amazon VPC based on IP protocol data. Ideal for load balancing TCP and UDP traffic.

In this tutorial, we will focus on Application Load Balancer as it provides the most features and flexibility. The concepts discussed can also apply to other ELB types.

Advanced Load Balancing Techniques

Here are some best practices and advanced techniques to optimize your ALB configuration:

1. Enable Deletion Protection

One important security practice when using Elastic Load Balancing is to enable load balancer deletion protection. By default, any user with permission to delete EC2 resources will also be able to delete your load balancer. Accidentally deleting a load balancer could cause extended downtime for your application.

Deletion protection prevents your load balancer from being deleted, providing an extra layer of protection against accidental or malicious removal. This feature can be easily enabled during initial load balancer creation or on an existing ALB.

To enable load balancer deletion protection on a new ALB:

1. Go to the EC2 console and launch a new Application Load Balancer.
2. On the Configure Load Balancer page, scroll down to the Delete Protection section.
3. Check the Enable delete protection checkbox.
4. Complete the remaining ALB configuration as per your requirements.

For an existing load balancer, you can edit the attributes to enable deletion protection:

1. Go to the EC2 console and select Load Balancers from the menu.
2. Click on your ALB to go to the Description tab.
3. Under the Attributes section, click Edit attributes.
4. Check the Enable delete protection checkbox and save.

Once enabled, the ALB cannot be deleted from the console or CLI. You will have to explicitly disable delete protection if you need to remove the load balancer.

It is highly recommended to enable this protection by default for all your Application Load Balancers running critical services. Accidental deletion is an easy mistake that could happen during routine housekeeping activities. The deletion protection feature provides an additional safeguard so you can rest assured your ALB will continue serving traffic without disruptions.

2. Configure Multiple Listeners

One of the advantages of Application Load Balancers is the ability to configure multiple listeners on the same load balancer instance. Listeners define the protocol and port combinations that the load balancer monitors for incoming traffic.

By default, a new ALB will be setup with a single HTTP listener on port 80. However, you can add additional listeners during initial configuration or later by modifying the ALB. Some common use cases for multiple listeners:

• Adding an HTTPS listener on port 443 for secure traffic, in addition to the plain HTTP listener. You can use AWS Certificate Manager to provision SSL certificates for the ALB.\
• Configuring listeners for both HTTP (port 80) and HTTPS (port 443) while redirecting all HTTP requests to HTTPS for secure communication.
• Creating listeners for different applications on distinct ports like port 5000 for App 1 and port 5001 for App 2. Requests can then be routed to separate target groups based on the listener port.
• Defining TCP listeners to load balance TCP-based traffic like databases or other stateful applications.

To add a new listener on an existing ALB:

1. Go to the EC2 console and select your load balancer.
2. Under the Listeners tab, click Add listener.
3. Specify the protocol (HTTP, HTTPS, TCP etc), port number, and default actions.
4. Click Save to add the new listener.

You can configure advanced rules like host-based and path-based routing to direct traffic from the new listener to appropriate target groups. Adding multiple listeners allows your Application Load Balancer to handle a diverse range of workloads and traffic types. It provides flexibility to evolve your architecture as new applications are added to the infrastructure.

3. Use Path-Based Routing

Path-based routing allows you to route requests to different target groups based on the URL path. This enables a single load balancer to direct traffic to multiple applications and microservices.

For example, you could have two target groups — one for a web application and one for an API backend. The load balancer can route requests based on the path:

• Requests to /app* go to target group for the web servers
• Requests to /api* go to target group for the API servers

To configure path-based routing:

1. Create target groups for each application or service. Register EC2 instances in the appropriate target group.
2. Create a listener on the ALB for the common port like HTTP on 80 or HTTPS on 443.
3. Define a default rule to match the basic listener protocol and port. This will be the fallback if no path rules match.
4. Create path patterns under Path based routing like /app* and /api*. Associate each path pattern with the correct target group.
5. The priority order determines which rule takes precedence if multiple patterns match a request.

With path-based routing, you can run multiple services on the same set of EC2 instances. The requests will be routed to the correct target group and instance based on the URL path.

Additional benefits include being able to implement different health checks for each target group path. You can also isolate microservices requests for more granular monitoring and metrics collection.

Path-based routing increases the flexibility of your core load balancing infrastructure as your applications evolve over time.

4. Implement Sticky Sessions

Sticky sessions bind a user’s session to a specific EC2 instance for the duration of that session. This ensures that all requests from the user during the session will be routed to the same instance.

Some key benefits of sticky sessions:

Improved cache performance — enables reuse of cached session state on the instance

Affinity for stateful applications — keeps user session data like shopping cart on one instance

Preventing session replication — avoids replicating session data across instances

You can enable sticky sessions on an ALB using two methods:

Using Load Balancer Generated Cookies:

• ALB will insert a cookie with an expiration timer for each new session.
• Subsequent requests containing this cookie will be routed to the original instance.
• Easy to implement but cookie can be lost if a user clears cookies.

Using Application Generated Cookies:

• Application servers generate their own cookies for each session.
• ALB is configured to route requests based on a specified cookie header.
• More reliable method compared to load balancer cookies.

Sticky sessions are suitable for stateful applications like shopping carts, user preferences, gaming sessions etc. For stateless applications, sticky sessions provide no benefit and can be disabled.

Proper testing should be done to validate sticky sessions are working as expected for your application architecture and traffic patterns.

5. Configure Auto Scaling and ELB Integration

Amazon EC2 Auto Scaling allows you to automatically scale out and scale in your compute capacity to match traffic demand. Integrating this with Elastic Load Balancing provides a seamless way to scale your web application tier.

Key steps to integrate Auto Scaling and ELB:

1. Create an Auto Scaling group with dynamic scaling policies, health checks and your desired capacity settings. Select the VPC and subnets for the group.
2. Create a new target group for the Application Load Balancer and register the Auto Scaling group as a target.
3. Configure the User Data script for the Auto Scaling launch configuration to automatically register new instances with the target group on boot.
4. Set up lifecycle hooks for newly launched instances to not be added to the load balancer until health checks pass.
5. If enabling termination lifecycle hooks, instances will be deregistered from the target group before termination.
6. Monitor metrics like request count, CPU utilization etc to trigger scale out events. CloudWatch alarms can be configured to call the Auto Scaling API.
7. Load testing your application will help validate scaling works as expected under real-world conditions.

With these steps, Auto Scaling will automatically register new instances to serve traffic via the load balancer when a scale out event occurs. The application can handle fluctuating traffic levels and scale to meet demand.

Make sure to test failover scenarios as well by terminating instances. This verifies the load balancer redistributes traffic smoothly.

6. Enable Cross-Zone Load Balancing

By default, a load balancer node in an AWS Availability Zone will only route incoming requests to registered targets in the same zone. This can lead to uneven distribution of traffic if you have imbalanced target capacity across zones.

Enabling cross-zone load balancing allows the load balancer to evenly distribute requests across healthy targets in all enabled Availability Zones.

Some benefits of cross-zone load balancing:

Improved high availability — If one zone fails, traffic can be served from other zones

Reduced latency — Requests are routed to the nearest healthy target instead of being restricted to the same zone

Evenly distributed load — Zones are not constrained by their target capacity

To enable cross-zone load balancing:

1. In the EC2 console, go to the Description tab for your Application Load Balance
2. Under Attributes, click Edit attributes
3. Check the box to Enable cross-zone load balancing.
4. Click Save to update the setting
5. Wait for the changes to be applied, this usually takes a few minutes
6. Monitor your load balancer metrics to validate traffic is now distributed across zones

Keep in mind that you will be charged for data transfer costs between zones if enabled. But this provides better performance and high availability.

Be sure to load test your architecture with cross-zone balancing to catch any issues early. It should allow your application to smoothly handle zone failures.

7. Configure Health Checks

Load balancers use health checks to continuously monitor the availability and responsiveness of registered targets like EC2 instances. Any unhealthy targets are automatically removed from rotation until they pass the health checks again.

Some key parameters to configure for ALB health checks:

Protocol — HTTP, HTTPS and TCP are supported. Match the protocol of your application.

Port — Specify the port to check such as 80 for HTTP.

Path — For HTTP/HTTPS checks, define a health check endpoint that tests backend connectivity.

Thresholds — Configure the number of consecutive successes/failures before considering a target healthy or unhealthy.

Timeout — Health checks will fail if the response is not received within the timeout duration.

Interval — Frequency of performing the health checks such as every 10 seconds.

Additionally, you can configure custom success codes and request headers sent during HTTP(S) health checks.

The health check criteria should be defined based on your application’s traffic patterns and metrics. Load test your settings to avoid falsely marking healthy targets as unhealthy.

Detailed CloudWatch metrics are available for each target group to monitor the health check statuses and fine tune configurations.

8. Use Multiple Availability Zones

For high availability, it is a best practice to deploy your load balancer instances across multiple availability zones within a region. This provides redundancy in case one zone experiences downtime.

Steps to set up an ALB across availability zones:

1. When creating the load balancer, under Availability Zones, select at least two zones from your region.
2. The load balancer nodes will be created in each selected zone for redundancy.
3. Ensure your backend EC2 instances or auto scaling groups are also distributed across multiple zones.
4. The ALB will then route traffic across zones to available backends.
5. If instances in one zone fail health checks, traffic will be shifted to healthy targets in the other zones.
6. For even distribution, you should have roughly equal target capacity in each enabled zone.
7. Use cross-zone load balancing so requests are spread based on target health rather than zone.

Be sure to monitor the per-zone request metrics for your load balancer. These metrics can help reveal any imbalance or gaps in capacity across zones.

Testing failover across zones ensures your application remains available and minimally disrupted if an entire zone goes down.

9. Set Up HTTPS Listeners

It is considered a security best practice to use HTTPS for encrypted communication between clients and your load balancer. Here are some key steps to set up HTTPS:

1. Obtain an SSL/TLS certificate from AWS Certificate Manager or import your own certificate.
2. Add an HTTPS listener on port 443 in addition to the default HTTP listener on your load balancer.
3. Configure default HTTPS actions to route requests to your target groups.
4. Enable encryption in transit to backends by checking the option under the target group protocol settings.
5. Set up redirection rules to redirect all HTTP requests to HTTPS for secure communication.
6. CloudWatch provides HTTPS-specific metrics to monitor performance.
7. Load test your architecture to catch SSL handshake issues or capacity bottlenecks.
8. Ensure security groups allow inbound HTTPS access from clients.
9. Set the TLS policy minimum to Security Policy TLS 1.2 for PCI compliance.
10. Enable HTTP Strict Transport Security (HSTS) to enforce HTTPS usage.

Proper HTTPS configuration provides encrypts traffic, prevents attacks like MITM and session hijacking, and complies with security regulations. Test regularly to avoid outages and ensure optimal capacity.

10. Enable Access Logs and CloudWatch Metrics

Access logs provide detailed information about all requests sent to your load balancer. These logs are useful for security auditing, troubleshooting, and analyzing traffic patterns.

Steps to enable access logs:

1. In the EC2 console, choose your load balancer, go to the Description tab and select Edit attributes.
2. Under Access logs, choose Enable.
3. Specify the S3 bucket name to store the logs and optional prefix.
4. Click Save and access logs will begin being published to the S3 bucket.

CloudWatch metrics include aggregate statistics like total connections, healthy host count, TLS handshakes, and additional dimensions like targets, Availability Zones etc.

Key steps to enable CloudWatch metrics:

1. In the CloudWatch console, select Metrics in the sidebar and All metrics.
2. Check the box next to the ApplicationELB namespace.
3. Metrics for all load balancers will begin streaming to CloudWatch.
4. You can create custom widgets and dashboards to monitor these metrics.
5. Set up alarms to notify you when thresholds are exceeded.

Access logs and metrics give you greater visibility into traffic patterns, performance trends, and issues. This information ultimately helps improve infrastructure monitoring, optimization, and security.

AWS CLI Commands to manage Application Load Balancers

Here are some examples of AWS CLI commands to manage Application Load Balancers:

Create a load balancer:

aws elbv2 create-load-balancer --name my-alb --subnets subnet-abcdef123 subnet-abc123def --security-groups sg-123abc456

Add a target group:

aws elbv2 create-target-group --name my-targets --protocol HTTP --port 80 --vpc-id vpc-abcdef123

Register targets:

aws elbv2 register-targets --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/abcdef0123456 --targets Id=i-01234567 Id=i-98765432

Create an HTTPS listener:

aws elbv2 create-listener --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-alb/abcdef0123456 --protocol HTTPS --port 443  --certificates CertificateArn=arn:aws:acm:us-east-1:123456789012:certificate/abcdef01-2345-6789-abcd-ef0123456789 --ssl-policy ELBSecurityPolicy-TLS-1-2-Ext-2018-06

Enable access logs:

aws elbv2 modify-load-balancer-attributes --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-alb/abcdef0123456 --attributes Key=access_logs.s3.enabled,Value=true Key=access_logs.s3.bucket,Value=my-logs-bucket

Overall, the AWS CLI provides a powerful way to automate load balancer management and configuration.

Conclusion

Elastic Load Balancing provides a robust suite of features to distribute traffic across Amazon EC2 instances for high availability and scalability. In this tutorial, we covered several advanced techniques like configuring multiple listeners, path-based routing, sticky sessions, and integrating with Auto Scaling to get the most out of Application Load Balancers. Monitoring through access logs and CloudWatch metrics gives you observability into traffic patterns and performance. Load testing validates your configuration under real-world conditions. Other optimization best practices include enabling cross-zone balancing, SSL listeners, and deletion protection. With these capabilities, you can build fault-tolerant architectures that smoothly handle fluctuating workloads and endpoint failures. AWS load balancers are crucial building blocks for provisioning secure, resilient applications able to scale on demand. The methods outlined in this tutorial can help you maximize the flexibility of AWS Elastic Load Balancing for your infrastructure needs as they evolve.