Elastic Load Balancing tricks for AWS applications

Configure Elastic Load Balancing and security groups

If you're automatically redirecting HTTP traffic to HTTPs, enable HTTPS proxying on Elastic Load Balancing (ELB) and upload an SSL certificate. In addition, open up HTTPS on the security group for the outside world and ensure HTTP is also open to the outside world.

If your load balancer can't connect to the AWS instance, make sure the security group that hosts the load balancer can access the port in which your service is running on application servers. Application servers run in a different security group than the ELB, and the load balancer must have access to them.

Set Auto Scaling Group to use ELB health checks

By default, the Auto Scaling Group (ASG) will check that instances are running, which could indicate that services on the AWS instance are working. While using the ELB health check provides a few false-error conditions, such as when a server is recovering from high load, it can ensure your service remains responsive. Play it safe; have the ASG health check use the ELB health check.

In addition, be sure there's enough time specified on the ASG's Health Check Grace Period or the time the system waits after a server is spawned before it assumes it didn't work. I've had issues where this was so low the ASG continually spawned and then killed instances because they took too long to spin up.

Setting this up is as simple as defining an .ebextension in the repository. This works only on the first time you create the environment, so be sure to add it before you spin up the environment. You can also add something like the following under .ebextensions/asg.config:

Resources:

AWSEBAutoScalingGroup:

Type: AWS::AutoScaling::AutoScalingGroup

Properties:

HealthCheckGracePeriod: 600

HealthCheckType: ELB

Setting up Virtual Private Cloud routing

AWS instances need access to the outside world and to Amazon. One common issue is that developers accidentally set up a subnet group that doesn't have access to the Internet and launch the environment there. If you've blocked access to the outside world, servers won't be able to download the software they need to spin up and, most likely, won't be able to contact Elastic Beanstalk to update their own status. Check the VPC subnet configuration to be sure servers can access the outside world. And check that routes have a path to 0.0.0.0/0 that is not in a black hole.

Planning subnets for ELB and application servers

If you set up a new VPC and try to save time by only creating only one subnet, it won't work. While you can apply the same route to Elastic Load Balancing and application servers, they cannot be in the same subnet because this causes countless problems.

App servers don’t need public IP addresses, but load balancers do. App servers can proxy Internet traffic through NAT instances; load balancers can't. Place the load balancer in the same availability zones (AZ) as application servers and always set up at least two AZs. That means the typical setup is four subnets split across two AZs. Reserve two subnets for the load balancer and two for app servers. And be sure the subnets are large enough to support all the application servers you need. Keep more available in case ELB needs to scale.

Prepare for load balancer changes

If you make major changes or update the environment, the load balancer may change. This is important because you can't make a CNAME to a root domain, such as Amazon.com, but you can make an alias to Elastic Load Balancing. To determine what the load balancer is for an environment, check to see what instances are associated to it.

If you use an alias via Route 53 to point a root domain to the load balancer, check it every time you make a major change, such as replacing the environment. Keep in mind: DNS takes a few minutes to propagate, so be sure to spin up the replacement, make the change to Route 53 and wait at least a day before terminating the old environment.