Or "5 ELB Tips That Will Surprise You", or, "The Five Things About ELB That Broke The Internet Last Week." Something catchy like that.
If you're using Amazon Web Services and need a load balancer to distribute traffic and make deployments easier, you'll probably want to go with AWS's Elastic Load Balancing instead of maintaining your own on an instance. The ELB functionality is pretty complete (health checks, monitoring, HTTPS support, etc.). A big weakness for me with AWS is their lack of quality documentation and unfortunately you'll have to learn some things by trial and error. So here I'm passing along some things I learned about ELB The Hard Way. For a nice overview of what ELB can do, check out the links at the bottom of this post.
The AWS web console is usually good enough to setup or edit an elastic load balancer, however there are a few things that you won't be able to do through it. One thing is deleting the SSL certificate that you have previous uploaded. To do that, you'll have to use the command line and here's the specific command to execute. When I've had to update SSL certs in the past (always a lot of fun), I've found it easier to delete the old cert and add a new one instead of attempting to edit the old cert in Amazon's system. And make sure to name your certs properly, perhaps even include its expiration date.
This one is pretty nifty: you can have the ELB automatically save access logs to a S3 bucket for a configurable interval. It's easy to set and forget. If you read my last post about centralizing your logs, no fear, Logstash has S3 input and output plugins.
Having trouble with your instances passing health checks? The load balancer just needs to receive a 200 status code back from the endpoint that you have set it up to check, the content doesn't really matter. If possible,
tailyour server's access and error logs to see what your server is sending back to the load balancer. If your entire server is behind some form of authentication that you can't add in the health check configuration, consider creating a dummy endpoint that always returns a 200.
This is pretty clear in the web console but is worth repeating here because it's a gotcha: ELBs don't have a fixed IP associated with them. Amazon suggests using a CNAME instead to associate a domain name.
This is actually an Auto Scaling Groups issue but it mainfests itself when administering an elastic load balancer. If you've got ELB instances coming for an Auto Scaling Group, do not use the "Remove from Load Balancer" option unless you want to replace the current instance with a new one from that ASG. What will happen is that the auto scaling group will realize that it is below its minimum number of instances and will bring up a new machine to meet the configured minimum. What I do instead when removing an old version of an app from a load balancer is to set the minimum number of instances for that auto scale group to zero which will make it automatically terminate all of the instances in that group.
- Solving Common ELB Problems with a Sanity Test: Having trouble passing your health checks or with incoming traffic forwarding to your backend server? This post really helped me work through those kinds of issues in the past. Someone even made a utility to check for common problems.
- ELB Internals, Security and Troubleshooting: A nice overview of ELB that's probably better than Amazon's version.
- When Are Your SSL Certificates Expiring on AWS?: Super helpful one-liner for staying on top of your SSL certificates.
- Troubleshooting Elastic Load Balancing: Health Check Configuration: For all your I-can't-believe-I-wasted-a-day-on-this needs.