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 Balancingservice 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
  • Add a load balancer
  • Add an ELB SSL certificate for a load balancer
  • Activate a load balancer
  • Verify a load balancer
  • Move a load balancer
  • Delete a load balancer
  • FAQs

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

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 | 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 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:

  3. Verify that it returns the hostname for the load balancer. For example: has address
  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.



Article is closed for comments.