Use Elastic Load Balancing with Engine Yard Cloud

Updated: October 2nd, 2014

The Elastic Load Balancing (ELB) feature allows you to use the Amazon Elastic Load Balancing service with your AWS environments.

ELB distributes requests to instances (servers) in multiple availability zones (AZs) in a way that minimizes the risk of overloading one single instance. And if an entire AZ goes offline, ELB routes traffic to instances in another AZ. Engine Yard uses cross-zone load balancing, which allows each load balancer node to route requests across availability zones. This means requests will not be sent to an already over-loaded availability zone. ELB also monitors the health of instances registered with the load balancer and sends requests only to the healthy instances. If an instance becomes unhealthy, ELB stops sending traffic to that instance and spreads the load across remaining healthy instances.

Note: Only load balancers added after June 11, 2014 will have the cross-zone load balancing behavior. If you want the cross-zone behavior, then delete the old load balancer and create a new one. Load balancers added prior to June 11, 2014 use the round-robin method.

ELB takes some of the load off the app_master (which, by default, balances traffic across all instances using HAProxy). ELB reveals the client's IP address with HTTPS connections (with HAProxy, this requires a stunnel configuration). ELB also allows for multiple SSL certificates in an environment (with HAProxy you must use wildcard certificates; with ELB you can use certificates for multiple domains).

Finally, ELB allows an environment to run multiple apps with SSL (when SSL is ELB terminated).

Enable the Elastic Load Balancing feature

You need to enable the Early Access feature before you can participate in the program.

To enable the Elastic Load Balancing Early Access

Log in to your Engine Yard Cloud account.

On the dashboard, click Tools > Early Access on the toolbar.

Next to the Load Balancers feature, click Enable.

The ELB-related functionality becomes available.

Add a load balancer

You need to name your load balancer and decide on the SSL configuration.

Note: You can create up to 10 elastic load balancers per region. If you need more than this, contact Engine Yard Support.

To add a load balancer

On the dashboard, click Load Balancers in the main Tools menu.

The Load Balancers page displays.

Select the environment the ELB will be used with.

Enter the ELB name (only letters and numbers) and the other corresponding fields.

Determine the SSL configuration that you need.

Select if and how to terminate SSL:

Disabled - The ELB does not respond to SSL requests.

AppServer - This is an SSL pass-through method, where the ELB acts as a TCP proxy, passing SSL requests through to the app instances (which use existing mechanisms for SSL).

ELB - The ELB itself deals with SSL and passes decrypted traffic through to the app instances. This requires an SSL certificate to be uploaded via the Dashboard's SSL Certificates page). This will offload SSL decryption from the app instances and centralize SSL certificate management.

Click Create ELB.

You will need to wait quite a while (10-15 minutes) for the ELB to provision and attach app instances.

Notes:

After creating an ELB, it will not begin serving traffic for a period of time.

Despite the use of cross-zone load balancing, Engine Yard still recommends that you have approximately the same number of app instances in each AZ so that each app instance gets a roughly equal share of the traffic.

If an entire AZ's instances are terminated, traffic to that AZ is disabled. If the instances simply stop serving traffic for some reason, that AZ will still get traffic but it will have nowhere to go.

Refresh the page to verify that the load balancer has been added. It should look something like this:

Error when Adding SSL Certificates

If you encounter an error message while adding the SSL certificate, it is likely due to the key not using an encoding that is accepted by AWS. You can re-encode the key using the following command (run from any MacOS/Linux/Unix/BSD machine):

openssl rsa -in sslcert.key -out sslcert.new

After you have run this command, you can verify that the new key is compatible with the existing key and certificate file by running the following command over the three files and verifying the modulus is identical:

Move a load balancer

A load balancer can be moved between environments in the same AWS Region, re-assigning the instances attached to it. This is useful in the case of an environment migration, negating the need for any updates to the DNS for domains pointing to ELB(s).

To move a load balancer

To move an ELB simply expand out the required ELB on the Load Balancers page, change the environment to the required one in the Environment dropdown menu, then click Update. This process will detach the current environment's instances from the ELB and attach the new environment's instances. You will see a short period where your application returns a 503 error while no instances are attached to the ELB. Please also ensure that the ELB SSL along with the ELB's specified health check URL, protocol and port are valid on the new environment.

Important: If moving from a v4 to a v5 environment whilst using the TCP health check, the port will also need to be updated from 81 to 8081 to compensate for the change in Nginx listening port on the v5 stack.

Delete a load balancer

Before deleting a load balancer, ensure that traffic is no longer being directed to that hostname. You should have configured and verified a replacement load balancer (or use the regular elastic IP method) to serve traffic before removing it.

Warning: Deleting a load balancer can cause a service disruption to any customers connected to the load balancer.

To delete a load balancer

On the dashboard, click Load Balancers in the main Tools menu.

The Load Balancers page displays.

Find the Hostname for your load balancer. For example:

EYelb-866271027.us-west-2.elb.amazonaws.com

Once you have confirmed that the load balancer is no longer receiving traffic, then you can click Delete next to the load balancer name.

Refresh the page to verify that the load balancer has been deleted.

FAQs

You might have these questions about the ELB load balancing feature.

How do I know that ELB / the load balancer is working?

The easiest way to check that a load balancer is working is to visit it. The hostname of the load balancer is listed on the Load Balancers page for an environment. Click the hostname to visit the app; your application should appear.

How can I tell which instances are attached to a load balancer?

All app instances in the environment are automatically added to all load balancers in the environment.

Can I see the amount of traffic going through a load balancer and to specific instances?

We aren't exposing a special way to see this.

Are there any health warnings or other health-check stats I can review?

We'd like to offer a status page showing which app instances the load balancer thinks are healthy and unhealthy, but have not released it yet.

Can I have multiple SSL certificates on a single environment?

Yes. Each SSL will need its own ELB. Follow the directions above for each SSL you need to use, creating a new ELB for each SSL certificate.

How do I update an expired certificate?

Add a new certificate with a new name, switch all load balancers to it, and remove the old one.

Note: Amazon does not provide a way to change an existing certificate.

Why are my ELB load balancers not balanced?

ELBs use round-robin based on availability zones (AZ), not on instances. This means if your traffic comes from different sources, the total traffic on each AZ should be equal.

Engine Yard ELBs don't use session stickiness, but ELBs still go to a particular AZ because of the way ELBs work. An ELB has one IP address per AZ unless scaling is occurring. With scaling, AWS will have two IP addresses but drain traffic to the old IP address. For example, if you have two IP addresses and users visit your web site, these users will get one of the 2 IP addresses. The first IP address will be cached for 1 minute before they can possibly get to the other IP address.

An alternative is to use a single AZ, but that AZ will be a single point of failure. When you have 8 instances, the total per AZ will be closer to each other, but this won't solve the single IP source issue.

If you have feedback or questions about this page, add a comment below. If you need help, submit a ticket with Engine Yard Support.

Comments

Christopher Bailey

February 15, 2013 18:55

Given the time it takes for DNS changes to percolate, as well as the setup time for ELB per above, will our app master still be running HAProxy and serving traffic sent to it via the existing DNS/IP Address configuration? I'd like to understand what the actual downtime impact would be if we changed an existing setup to use ELB.

When you add ELB, your app master and HAProxy will continue to run and serve traffic. We do not do a cookbook run to stop HAProxy. Your previous configuration should still continue to sever traffic until ELB and your DNS changes take place, meaning you should not have any downtime.

Support will be able to help walk you through these steps and answer any further questions on how this happens. Thanks!

Hi Mullen, meant to get back to this comment - if you can tell us which section above you are referring to specifically, that would be great. Otherwise, we've logged a ticket to test this out ourselves. thanks! kjm

Is it possible to use ELB-terminated HTTPS and client certificate authentication? As far as I understand ELB doesn't support that on its own, but workarounds exist using ELB's Proxy Protocol support. Is it possible to use such a workaround with Engine Yard?

Any such workarounds would probably need to go through our professional services team (https://www.engineyard.com/services). I don't know _for sure_ off the top of my head if we can do that, but if you're indeed interested, put in a ticket with support, tell them you want to talk to professional services about it, and it'll get routed to my team to look into. We can tell you more at that point.

Hello, my name is James - I am being asked to setup Elastic Load Balancing (ELB) for an event we have where our servers get particularly high activity. Can someone tell me what the additional financial impact of using ELB is? Also how far in advance should this feature be enabled in order to assure that ELB is active for the beginning of our peak season?

In terms of advanced setup, changing to the ELB will require a DNS change and it never hurts to have a few days to test things before making any production changes. Via a ticket we can contact AWS on your behalf to get the ELB's pre-warmed based on your specifics. All told I'd say a week ahead of time should be sufficient.