Engine Yard Developer Center

Using Amazon Elastic Load Balancers

Updated: October 2nd, 2014

The default load balancing tool on Engine Yard Cloud is HAProxy running on the Application Master Instance. If advanced load balancing is required Amazon Load Balancers can be deployed, at additional cost.

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).

Get help or provide feedback

If you have any issues or questions about this Early Access feature, use the Early Access Feature Feedback forum.

Get started with Elastic Load Balancing

This document describes how to use Elastic Load Balancing in the Engine Yard Cloud environment:

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

  1. Log in to your Engine Yard Cloud account.

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

  3. 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

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

    The Load Balancers page displays.

  2. Select the environment the ELB will be used with.

  3. Enter the ELB name (only letters and numbers) and the other corresponding fields. 
  4. 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.

  5. Click Create ELB.

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


    • After creating an ELB, it will not begin serving traffic for a period of time.
    • ELBs balance across availability zones (AZs) using cross-zone load balancing (requests are routed across multiple availability zones).
    • 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.
  6. Refresh the page to verify that the load balancer has been added. It should look something like this:

  7. If you are ready to activate your load balancer, see Activate a load balancer.

Add an SSL certificate for a load balancer

Note: There is a limit of 20 SSL certificates per region, per account. If you need more than this, contact Engine Yard Support.

To add an SSL certificate to your Engine Yard account, you need your key file; the CRT file from your vendor; and, if your vendor provided one, the certificate chain file. See obtain and install SSL certificates for more information.

To add an SSL certificate

  1. If you are not on the SSL Certificates page:

    a. From the dashboard, click Tools > SSL Certificates on the toolbar.

    The SSL Certificates page appears.

    b. Click Add SSL Certificate (under the required account if you have more than one).

    The Create New SSL Certificate page appears.

  2. Enter a name in the SSL Certificate Name field.

  3. In the SSL Certificate text box, paste the contents of the CRT file.

  4. In the SSL Certificate Key text box, paste the SSL Certificate Key.

  5. If you have a certificate chain file, paste it into the SSL Certificate Chain field.

  6. Click Add Certificates.

    Engine Yard Cloud uploads your SSL certificate information.

    Continue to Activate a load balancer.

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:

deploy$ openssl rsa -text -noout -modulus -in sslcert.key | grep Modulus
deploy$ openssl rsa -text -noout -modulus -in sslcert.new | grep Modulus
deploy$ openssl x509 -text -noout -modulus -in sslcert.crt | grep Modulus

During one rewrite, we found the original key was 1705 bytes long and the rewrite was 1679 bytes long. The difference came from the hex code, not just spacing or EOL's.

After the rewrite, the certificate was accepted (using the sslcert.new) by Amazon.

Activate a load balancer

To activate the new load balancer, you need to move your custom domain name from the app_master to the ELB load balancer instance.

To activate a load balancer

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

    The Load Balancers page displays.

  2. Find the Hostname for your load balancer; this is the DNS (Domain Name System) name. For example:

  3. Cut/paste the Hostname and provide it to your domain name provider.

  4. Ask your domain name provider to move your custom domain name from the app_master to the load balancer hostname.

    Note: Your domain name provider needs to create a CNAME record using the hostname to get load balancing to function properly.

  5. If you need to set up a zone apex alias, or for more information about CNAME records, see the AWS documentation, Using Domain Names with Elastic Load Balancing.

  6. Continue to Verify a load balancer.

Verify a load balancer

To verify the new load balancer and its new DNS name, you can use a simple shell command.

To verify a load balancer

  1. Open a UNIX shell.

  2. Type:

    host your.customdomainname.com
  3. Verify that it returns the hostname for the load balancer. For example:

    your.customdomainname.com has address EYelb-866271027.us-west-2.elb.amazonaws.com
  4. If the address is still the app_master address, you might need to wait for DNS propagation; try again after a few minutes or contact your domain name provider.

    For more information see Using domain names with ELB

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

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

    The Load Balancers page displays.

  2. Find the Hostname for your load balancer. For example:

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

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


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.

Was this article helpful?
16 out of 16 found this helpful
Have more questions? Submit a request


  • Avatar
    Christopher Bailey

    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.

  • Avatar
    Josh Hamilton

    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!

  • Avatar
    Mullen Host

    May need to edit this documentation - current interface reads 'add provider ssl certificate' with aws as a dropdown. 

  • Avatar
    Tasha Drew

    Thanks Mullen! I'll ask our tech writers to take a look.

  • Avatar
    Keri Meredith

    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


  • Avatar
    Mullen Host

    No problem - section 1b under 'To add an ELB SSL certificate'

    Looks like the workflow may be a little different now.

  • Avatar
    Diana Lam

    Hi Mullen. I've updated the process flow based on your feedback. Please let me know if you have any further feedback.  Thanks. -diana

  • Avatar
    Artem Baguinski


    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?



  • Avatar
    J. Austin Hughey

    Hi Artem,

    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.

    Hope this helps!

  • Avatar
    James Almeida

    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?

  • Avatar
    Tyler Poland

    Hi James,
    A lot of this is going to be dependent on how your account and application is setup. Please open a ticket with our support team so we can speak specifically to your deployment.
    - Tyler

    Edited by Tyler Poland
  • Avatar
    Matt Jones

    Hello James,

    The pricing will be a 20% uplift from the AWS published prices which can vary slightly by region and can be found at https://aws.amazon.com/elasticloadbalancing/classicloadbalancer/pricing/. This generally means around $20 / ELB / month, but as there is a small charge for the amount of data processed your totals may vary.

    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.

Please sign in to leave a comment.

Powered by Zendesk