Elastic Load Balancer (ELB)

Elastic Load Balancing is load balancer as a service provided by AWS.

    1. Automatically distributes incoming application traffic across multiple targets, such as Amazon EC2 instances, containers, IP addresses, Lambda functions, and virtual appliances.
    2. It can handle the varying load of your application traffic in a single Availability Zone or across multiple Availability Zones.
    3. Elastic Load Balancing offers four types of load balancers that all feature the high availability, automatic scaling, and robust security necessary to make your applications fault tolerant.

Four types

    1. Classic LB (for classic EC2) uses Transport layer (L4) or application layer (L7) of TCP/IP. Classic Load Balancer provides basic load balancing across multiple Amazon EC2 instances and operates at both the request level and the connection level. Classic Load Balancer is intended for applications that were built within the EC2-Classic network.
    2. Application LB uses application layer of TCP/IP. 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. Application Load Balancer routes traffic to targets within Amazon VPC based on the content of the request.
    3. 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. Network Load Balancer routes traffic to targets within Amazon VPC and is capable of handling millions of requests per second while maintaining ultra-low latencies.
    4. Gateway Load Balancer makes it easy to deploy, scale, and run third-party virtual networking appliances. Providing load balancing and auto scaling for fleets of third-party appliances, Gateway Load Balancer is transparent to the source and destination of traffic. This capability makes it well suited for working with third-party appliances for security, network analytics, and other use cases.

Benefits of ELB

Highly availability and elasticity:

  • Elastic Load Balancing is part of the AWS network, with native awareness of failure boundaries like AZs to keep your applications available across a region, without requiring Global Server Load Balancing (GSLB).
  • ELB is also a fully managed service, meaning you can focus on delivering applications and not installing fleets of load balancers.
  • Capacity is automatically added and removed based on the utilization of the underlying application servers.


  • Elastic Load Balancing works with Amazon Virtual Private Cloud (VPC) to provide robust security features, including integrated certificate management, user-authentication, and SSL/TLS decryption.
  • Together, they give you the flexibility to centrally manage TLS settings and offload CPU intensive workloads from your applications.
  • ALB also supports integration with AWS WAF, adding a level of protection before bad actors reach the application.
  • Further, S2N and HTTP Guardian have been developed as Open Source solutions to reduce the potential for HTTP-based attacks.

Feature breadth

  • Elastic Load Balancing offers the breadth of features needed by businesses of all sizes, while delivering them in an AWS-native experience.
  • Elastic Load Balancing includes support for features needed in container-based workloads, including HTTP/2, gRPC, TLS offload, advanced rule-based routing, and integration with container services as an ingress controller.
  • ALB provides customers with a native HTTP endpoint for calling Lambda functions, removing the dependency on other solutions.
  • Further, Gateway Load Balancer creates one gateway for routing traffic through fleets of third-party appliances.

Robust monitoring & visibility

  • Elastic Load Balancing allows you to monitor the health of your applications and their performance in real time with Amazon CloudWatch metrics, logging, and request tracing.
  • This improves visibility into the behavior of your applications, uncovering issues and identifying performance bottlenecks in your application stack.
  • ELB helps ensure compliance with application Service Level Agreements (SLAs).

Integration and global reach

  • As a native AWS service, ELB is tightly integrated with other AWS services like EC2, ECS/EKS, Global Accelerator and operational tools such as AWS CloudFormation and AWS Billing.
  • Across the Amazon Global Infrastructure and customer data centers with AWS Outposts and on-premises target support, ELB is available everywhere you run your AWS workloads.

How to Create ELB

    1. Create Load Balancer
      • Choose type of ELB, Name, internal or internet facing, VPC
      • ELB Protocol, ELB Port
        • For Classic choose HTTP/HTTPS/TCP/SSL
        • For application ELB choose HTTP/HTTPS
        • Tor Network ELB choose TCP/Port
      • Instance protocol, Instance port and assign Security Group
      • aws elbv2 create-load-balancer --name my-load-balancer --subnets subnet-0e3f5cac72EXAMPLE subnet-081ec835f3EXAMPLE --security-groups sg-07e8ffd50fEXAMPLE
        output: arn:aws:elasticloadbalancing:us-east-2:123456789012:loadbalancer/app/my-load-balancer/1234567890123456
    2. Create Target group
      • For Network ELB and Application ELB, create a new Target Group or use existing target group (for classic ELB, add EC2’s directly to the ELB).
        • TG needs Name, Protocol, Port, Target Type (Instance id or ip)
      • aws elbv2 create-target-group --name my-targets --protocol HTTP --port 80 --vpc-id vpc-0598c7d356EXAMPLE
        output: arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/1234567890123456
      • modify-target-group
        --target-group-arn <value>
        [--health-check-protocol <value>]
        [--health-check-port <value>]
        [--health-check-path <value>]
        [--health-check-enabled | --no-health-check-enabled]
        [--health-check-interval-seconds <value>]
        [--health-check-timeout-seconds <value>]
        [--healthy-threshold-count <value>]
        [--unhealthy-threshold-count <value>]
        [--matcher <value>]
        [--cli-input-json <value>]
        [--generate-cli-skeleton <value>]
      • Configure health check:
        • Ping protocol/port/path (example: /test.html)
        • Response timeout (amount of time before response starts)
        • Interval (amount of time between pings)
        • Unhealthy threshold (number of consecutive failures before declaring instance unhealthy)
        • Healthy threshold (number of consecutive pass before declaring instance healthy)
    3. Register Targets to the Target Group: Add EC2 instances (instance id) or private ip/port to the TG
      • aws elbv2 register-targets --target-group-arn targetgroup-arn --targets Id=i-0abcdef1234567890 Id=i-1234567890abcdef0
      • Skip this step if you choose to use this TG as a proxy to an ASG (see next point #8)
    4. Creating ELB listeners (for elbv2)
      • Using CLI, or console you need to create a listener for each target group. The listener can be assigned multiple TGs. Using below CLI command you can create a Listener with a default rule that forwards requests to your target group
      • aws elbv2 create-listener --load-balancer-arn loadbalancer-arn --protocol HTTPS --port 443 --certificates CertificateArn=certificate-arn --default-actions Type=forward,TargetGroupArn=targetgroup-arn
        output: listner arn
    5. You can create additional rules in the listener. A rule attaches a listener to a TG. Example: Create a rule to send path-pattern based requests to a special target group:
      • aws elbv2 create-rule --listener-arn listener-arn --priority 10 --conditions Field=path-pattern,Values='/img/*' --actions Type=forward,TargetGroupArn=targetgroup-arn
    6. Final steps
      1. After creating ELB note the DNS name, which looks similar to: elbname.regionname.elb.amazonaws.com. This can be updated in your DNS
      2. You can delete ELB either from console or CLI
      3. aws elbv2 delete-load-balancer --load-balancer-arn loadbalancer-arn

Session management (AWS documentation on ELB session management)

    1. By default, a Classic Load Balancer routes each request independently to the registered instance with the smallest load. However, you can use the sticky session feature (also known as session affinity), which enables the load balancer to bind a user’s session to a specific instance. This ensures that all requests from the user during the session are sent to the same instance.
    2. Stickiness can be setup thru console or CLI
    3. Elastic Load Balancing creates a cookie, named AWSELB, that is used to map the session to the instance.
    4. Duration based session stickiness:
      1. On the Edit stickiness page, select Enable load balancer generated cookie stickiness.
      2. (Optional) For Expiration Period type the cookie expiration period, in seconds. If you do not specify an expiration period, the sticky session lasts for the duration of the browser session.
      3. If there is no cookie (first request), the load balancer chooses an instance based on the existing load balancing algorithm (least loaded EC2). A cookie is inserted into the response for binding subsequent requests from the same user to that instance.  After a cookie expires (after duration from above step), the session is no longer sticky.
    5. Application-Controlled session stickiness:  
      1. The load balancer uses a special cookie to associate the session with the instance that handled the initial request, but follows the lifetime of the application cookie specified in the policy configuration.
      2. The load balancer only inserts a new stickiness cookie if the application response includes a new application cookie.
      3. The load balancer stickiness cookie does not update with each request.
      4. If the application cookie is explicitly removed or expires, the session stops being sticky until a new application cookie is issued.
      5. If an instance fails or becomes unhealthy, the load balancer stops routing requests to that instance, and chooses a new healthy instance based on the existing load balancing algorithm.
      6. The load balancer treats the session as now “stuck” to the new healthy instance, and continues routing requests to that instance even if the failed instance comes back.
      7. On the Edit stickiness page, select Enable application generated cookie stickiness.
      8. For Cookie Name, type the name of your application cookie.
    6. ELB can distribute load across EC2 instances running across AZs within a region only.

Robust monitoring & visibility

You can use request tracing to track HTTP requests from clients to targets or other services. When the load balancer receives a request from a client, it adds or updates the X-Amzn-Trace-Id header before sending the request to the target. Any services or applications between the load balancer and the target can also add or update this header. If you enable access logs, the contents of the X-Amzn-Trace-Id header are logged

Microservices inside a single EC2

You can use a micro services architecture to structure your application as services that you can develop and deploy independently. You can install one or more of these services on each EC2 instance, with each service accepting connections on a different port. You can use a single Application Load Balancer to route requests to all the services for your application. When you register an EC2 instance with a target group, you can register it multiple times; for each service, register the instance using the port for the service.

When you deploy your services using Amazon Elastic Container Service (Amazon ECS), you can use dynamic port mapping to support multiple tasks from a single service on the same container instance. Amazon ECS manages updates to your services by automatically registering and de-registering containers with your target group using the instance ID and port for each container.

Load balancing Databases

If your web servers must be connected to the Internet and database servers are only connected to the web servers

    1. Create an Internet-facing load balancer and register the web servers with it.
    2. Create an internal load balancer and register the database servers with it.
    3. The web servers receive requests from the Internet-facing load balancer and send requests for the database servers to the internal load balancer.
    4. The database servers receive requests from the internal load balancer.

If you have ten instances in Availability Zone 1  and two instances in AZ2, the requests are distributed evenly between the two Availability Zones. As a result, the two instances in us-west-2b serve the same amount of traffic as the ten instances in us-west-2a. Instead, you should have six instances in each Availability Zone

Advantages of ALB over CLB:

    1. Support for host-based routing. You can configure rules for your listener that forward requests based on the host field in the HTTP header. This enables you to route requests to multiple domains using a single load balancer
    2. Support for routing requests to multiple applications on a single EC2 instance. You can register each instance or IP address with the same target group using multiple ports.
    3. Support for registering targets by IP address, including targets outside the VPC for the load balancer.
    4. Support for containerized applications in Amazon Elastic Container Service (Amazon ECS)

Advantages of ALB over NLB:

    1. NLB is at layer 4, does not understand applications, uses simple ICMP ping to determine the health as opposed to actual application health
    2. ALB can distribute traffic to to different web servers with own ips but port 80 running on the same host. NLB can’t
<<< Elastic Block Storage (EBS)Auto Scaling Groups and Launch Configurations >>>
Copyright 2005-2016 KnowledgeHills. Privacy Policy. Contact .