Elastic Load Balancing

Home » AWS Certification Cheat Sheets » AWS Certified SysOps Administrator Associate Cheat Sheets » Elastic Load Balancing

*** New topics added for the SOA-C02 ***

The Elastic Load Balancing (ELB) service on AWS distributes incoming connection requests to targets such as Amazon EC2 instances, containers, IP addresses, and AWS Lambda functions.

Traffic can be distributed across a single or multiple Availability Zones (AZs) within an AWS Region.

Elastic Load Balancing  enables high availability, automatic scaling, and robust security necessary to make applications fault tolerant.

The Elastic Load Balancing service offers three different types of load balancer.

The following image provides an overview of some of the key differences between the three types of ELB:


Application Load Balancer (ALB)

Application Load Balancer is best suited for load balancing of HTTP and HTTPS traffic and provides advanced request routing targeted at the delivery of modern application architectures, including microservices and containers.

Operating at the individual request level (Layer 7), Application Load Balancer routes traffic to targets within Amazon Virtual Private Cloud (Amazon VPC) based on the content of the request.

Offers path-based routing and host-based routing to direct connections based on information in the request header.

Does not support a static IP address but does have a fixed DNS address.

You can put an NLB in front of an ALB to get a static IP address.

Provides SSL/TLS termination.

Network Load Balancer (NLB)

Network Load Balancer is best suited for load balancing of Transmission Control Protocol (TCP), User Datagram Protocol (UDP) and Transport Layer Security (TLS) traffic where extreme performance is required.

Operating at the connection level (Layer 4), Network Load Balancer routes traffic to targets within Amazon Virtual Private Cloud (Amazon VPC) and is capable of handling millions of requests per second while maintaining ultra-low latencies.

Network Load Balancer is also optimized to handle sudden and volatile traffic patterns.

NLB can be assigned a static / Elastic IP address (1 per subnet)

Also provides SSL/TLS termination.

Classic Load Balancer (CLB)

Classic Load Balancer provides basic load balancing across multiple Amazon EC2 instances and operates at both the request level and connection level. Classic Load Balancer is intended for applications that were built within the EC2-Classic network.

The CLB is the oldest ELB in AWS and is not covered much on the exam anymore and the remainder of this page covers concepts relating ONLY to the ALB and NLB.

Deployment and Provisioning

ELBs can be Internet facing or internal-only.

Internet facing ELB:

  • ELB nodes have public IPs.
  • Routes traffic to the private IP addresses of the EC2 instances.
  • Need one public subnet in each AZ where the ELB is defined.
  • ELB DNS name format: <name>-<id-number>.<region>.elb.amazonaws.com.

Internal only ELB:

  • ELB nodes have private IPs.
  • Routes traffic to the private IP addresses of the EC2 instances.
  • ELB DNS name format: internal-<name>-<id-number>.<region>.elb.amazonaws.com.

ELB nodes use IP addresses within your subnets, ensure at least a /27 subnet and make sure there are at least 8 IP addresses available in order for the ELB to scale.

Deleting an ELB does not affect the instances registered against it (they won’t be deleted, they just won’t receive any more requests).

Target groups

Target groups are a logical grouping of targets (EC2 instances or ECS).

Targets are the endpoints and can be EC2 instances, ECS containers, IP addresses, or AWS Lambda functions.

Target groups exist independently from the ELBTarget groups can have up to 1000 targets.

A single target can be in multiple target groups.

Only one protocol and one port can be defined per target group.

The target type in a target group can be an EC2 instance ID, IP address (must be a valid private IP from an existing subnet) or AWS Lambda Function (ALB only).

Listeners and Rules


  • Each ALB needs at least one listener and can have up to 10.
  • Listeners define the port and protocol to listen on.
  • Can add one or more listeners.
  • Cannot have the same port in multiple listeners.

Listener rules:

  • Rules determine how the load balancer routes requests to the targets in one or more target groups.
  • Each rule consists of a priority, one or more actions, an optional host condition, and an optional path condition.
  • Only one action can be configured per rule.
  • One or more rules are required.
  • Each listener has a default rule and you can optionally define additional rules.
  • Up to 100 rules per ELB.
  • Rules determine what action is taken when the rule matches the client request.
  • Rules are defined on listeners.
  • You can add rules that specify different target groups based on the content of the request (content-based routing).
  • If no rules are found the default rule will be followed which directs traffic to the default target groups.

Sticky Sessions

Sticky sessions binds a user’s session to a specific target.

Useful for servers that maintain state information in order to provide a continuous experience to clients.

Used with HTTP/HTTPS load balancers.

Enabled at the target group level.

There are two configuration options for sticky sessions:

  • Duration-based cookies – always uses AWSALB.
  • Application-based cookies – set a custom app cookie name.

Both types are generated by the load balancer (not the application).

For application-based cookies, cookie names have to be specified individually for each target group.

For duration-based cookies, AWSALB is the only name used across all target groups.

Troubleshooting your AWS ELB

Common issues:

  • A registered target is not in service:
    • A security group does not allow traffic The security group associated with an instance must allow traffic from the load balancer using the health check port and health check protocol.
    • A network access control list (ACL) does not allow trafficThe network ACL associated with the subnets for your instances must allow inbound traffic on the health check port and outbound traffic on the ephemeral ports (1024-65535).
    • The ping path does not exist – Create a target page for the health check and specify its path as the ping path.
    • The connection times out – Verify that you can connect to the target directly from within the network using the private IP address of the target and the health check protocol.
    • The target did not return a successful response code – Confirm the success codes that the load balancer is expecting and that your application is configured to return these codes on success.
  • Clients cannot connect to an internet-facing load balancer:

    • Your Internet-facing load balancer is attached to a private subnet – Verify that you specified public subnets for your load balancer.
    • A security group or network ACL does not allow traffic – The security group for the load balancer and any network ACLs for the load balancer subnets must allow inbound traffic from the clients and outbound traffic to the clients on the listener ports.
  • The load balancer sends requests to unhealthy targets – If there is at least one healthy target in a target group, the load balancer routes requests only to the healthy targets. If a target group contains only unhealthy targets, the load balancer routes requests to the unhealthy targets.

  • The load balancer sends a response code of 000 – With HTTP/2 connections, if the compressed length of any of the headers exceeds 8K, the load balancer sends a GOAWAY frame and closes the connection with a TCP FIN.

Some HTTP errors may be generated by the load balancer

The following HTTP errors are generated by the load balancer. The load balancer sends the HTTP code to the client, saves the request to the access log, and increments the HTTPCode_ELB_4XX_Count or HTTPCode_ELB_5XX_Count metric.

HTTP 400: Bad request – The client sent a malformed request that does not meet the HTTP specification. Or, the request header exceeded 16K per request line, 16K per single header, or 64K for the entire header.

HTTP 401: Unauthorized – You configured a listener rule to authenticate users. Either you configured OnUnauthenticatedRequest to deny unauthenticated users or the IdP denied access.

HTTP 403: Forbidden – You configured an AWS WAF web access control list (web ACL) to monitor requests to your Application Load Balancer and it blocked a request.

HTTP 405: Method not allowed – The client used the TRACE method, which is not supported by Application Load Balancers.

HTTP 408: Request timeout – The client did not send data before the idle timeout period expired. Sending a TCP keep-alive does not prevent this timeout. Send at least 1 byte of data before each idle timeout period elapses. Increase the length of the idle timeout period as needed.

HTTP 413: Payload too large – The target is a Lambda function and the request body exceeds 1 MB.

HTTP 414: URI too long – The request URL or query string parameters are too large.

HTTP 460 – The load balancer received a request from a client, but the client closed the connection with the load balancer before the idle timeout period elapsed.

HTTP 463 – The load balancer received an X-Forwarded-For request header with more than 30 IP addresses.

HTTP 500: Internal server error – Possible causes:

You configured an AWS WAF web access control list (web ACL) and there was an error executing the web ACL rules.

You configured a listener rule to authenticate users, but one of the following is true:

  • The load balancer is unable to communicate with the IdP token endpoint or the IdP user info endpoint. Verify that the security groups for your load balancer and the network ACLs for your VPC allow outbound access to these endpoints. Verify that your VPC has internet access. If you have an internal-facing load balancer, use a NAT gateway to enable internet access.
  • The size of the claims returned by the IdP exceeded the maximum size supported by the load balancer.
  • A client submitted an HTTP/1.0 request without a host header, and the load balancer was unable to generate a redirect URL.
  • A client submitted a request without an HTTP protocol, and the load balancer was unable to generate a redirect URL.
  • The requested scope doesn’t return an ID token.

HTTP 501: Not implemented – The load balancer received a Transfer-Encoding header with an unsupported value. The supported values for Transfer-Encoding are chunked and identity. As an alternative, you can use the Content-Encoding header.

HTTP 502: Bad gateway – Possible causes:

  • The load balancer received a TCP RST from the target when attempting to establish a connection.
  • The load balancer received an unexpected response from the target, such as “ICMP Destination unreachable (Host unreachable)”, when attempting to establish a connection. Check whether traffic is allowed from the load balancer subnets to the targets on the target port.
  • The target closed the connection with a TCP RST or a TCP FIN while the load balancer had an outstanding request to the target. Check whether the keep-alive duration of the target is shorter than the idle timeout value of the load balancer.
  • The target response is malformed or contains HTTP headers that are not valid.
  • The load balancer encountered an SSL handshake error or SSL handshake timeout (10 seconds) when connecting to a target.
  • The deregistration delay period elapsed for a request being handled by a target that was deregistered. Increase the delay period so that lengthy operations can complete.
  • The target is a Lambda function and the response body exceeds 1 MB.
  • The target is a Lambda function that did not respond before its configured timeout was reached.

HTTP 503: Service unavailable – The target groups for the load balancer have no registered targets.

HTTP 504: Gateway timeout – Possible causes:

  • The load balancer failed to establish a connection to the target before the connection timeout expired (10 seconds).
  • The load balancer established a connection to the target but the target did not respond before the idle timeout period elapsed.
  • The network ACL for the subnet did not allow traffic from the targets to the load balancer nodes on the ephemeral ports (1024-65535).
  • The target returns a content-length header that is larger than the entity body. The load balancer timed out waiting for the missing bytes.
  • The target is a Lambda function and the Lambda service did not respond before the connection timeout expired.

HTTP 561: Unauthorized – You configured a listener rule to authenticate users, but the IdP returned an error code when authenticating the user.

Targets can also generate HTTP errors.

The load balancer forwards valid HTTP responses from targets to the client, including HTTP errors. The HTTP errors generated by a target are recorded in the HTTPCode_Target_4XX_Count and HTTPCode_Target_5XX_Count metrics.

Monitoring and Reporting

Elastic Load Balancing publishes data points to Amazon CloudWatch for your load balancers and your targets.

CloudWatch enables you to retrieve statistics about those data points as an ordered set of time-series data, known as metrics.

Some of the key metrics reported for load balancers are:

  • BackendConnectionErrors
  • HealthyHostCount / UnhealthyHostCount
  • HTTPCode_Backend_2XX – Successful request
  • HTTPCode_Backend_3XX – Redirected request
  • HTTPCode_ELB_4XX client error
  • HTTPCode_ELB_5XX server error (generated by ELB)
  • Latency
  • RequestCount
  • SurgeQueueLength – the total number of requests (HTTP listener) or connections (TCP listener) that are pending routing to a healthy instance. Can be used to scale out an Auto Scaling group. Max value is 1024.
  • SpilloverCount – the total number of requests that were rejected because the surge queue is full.

For a detailed list of the metrics reported for load balancers and targets check the AWS documentation here.

Logging and Auditing

CloudTrail is enabled on your AWS account when you create the account. When activity occurs in Elastic Load Balancing, that activity is recorded in a CloudTrail event along with other AWS service events in Event history.

All Elastic Load Balancing actions for Application Load Balancers are logged by CloudTrail and are documented in the Elastic Load Balancing API Reference version 2015-12-01.

Every event or log entry contains information about who generated the request. The identity information helps you determine the following:

  • Whether the request was made with root or AWS Identity and Access Management (IAM) user credentials.
  • Whether the request was made with temporary security credentials for a role or federated user.
  • Whether the request was made by another AWS service.

ELB access logs can be stored on Amazon S3 and contain the following data:

  • Time
  • Client IP address
  • Latencies
  • Request paths
  • Server response
  • Trace ID

ELB and AWS X-Ray

  • Elastic Load Balancing application load balancers add a trace ID to incoming HTTP requests in a header named X-Amzn-Trace-Id.
  • Load balancers do not send data to X-Ray, and do not appear as a node on your service map.

Authorization and Access Control

Elastic Load Balancing supports identity-based IAM policies.

Elastic Load Balancing does not support resource-based policies.

Elastic Load Balancing has partial support for resource-level permissions.

For API actions that support resource-level permissions, you can control the resources that users are allowed to use with the action.

To specify a resource in a policy statement, you must use its Amazon Resource Name (ARN). When specifying an ARN, you can use the * wildcard in your paths. For example, you can use the * wildcard when you do not want to specify the exact load balancer name.