Elastic Load Balancing

General ELB Concepts

Elastic Load Balancing automatically distributes incoming application traffic across multiple targets, such as Amazon EC2 instances, containers, and IP addresses.

There are three types of Elastic Load Balancer (ELB) on AWS:

  • Classic Load Balancer (CLB) – this is the oldest of the three and provides basic load balancing at both layer 4 and layer 7.
  • Application Load Balancer (ALB) – layer 7 load balancer that routes connections based on the content of the request.
  • Network Load Balancer (NLB) – layer 4 load balancer that routes connections based on IP protocol data.

Note: The Classic Load Balancer may be phased out over time and Amazon are promoting the ALB and NLB for most use cases within VPC.

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

Amazon ELB NLB ALB CLB

The following table provides a more detailed feature comparison:

 

ELB Comparison Table 1

And continued….

ELB Comparison Table 2

Elastic Load Balancing provides fault tolerance for applications by automatically balancing traffic across targets – Amazon EC2 instances, containers and IP addresses – and Availability Zones while ensuring only healthy targets receive traffic.

An ELB can distribute incoming traffic across your Amazon EC2 instances in a single Availability Zone or multiple Availability Zones.

Only 1 subnet per AZ can be enabled for each ELB.

Route 53 can be used for region load balancing with ELB instances configured in each region.

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.

Internal-only load balancers do not need an Internet gateway.

EC2 instances and containers can be registered against an ELB.

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.

An ELB forwards traffic to eth0 (primary IP address).

An ELB listener is the process that checks for connection requests:

  • Listeners for CLB provide options for TCP and HTTP/HTTPS.
  • Listeners for ALB only provide options for HTTP and HTTPS.
  • Listeners for NLB only provide TCP as an option.

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

For ALB at least 2 subnets must be specified.

For NLB only one subnet must be specified (recommended to add at least 2).

For CLB you don’t need to specify any subnets unless you have “Enable advanced VPC configuration” enabled in which case you must specify two.

ELB uses a DNS record TTL of 60 seconds to ensure new ELB node IP addresses are used to service clients.

By default the ELB has an idle connection timeout of 60 seconds, set the idle timeout for applications to at least 60 seconds.

Perfect Forward Secrecy (PFS) provides additional safeguards against the eavesdropping of encrypted data, through the use of a unique random session key.

Server Order Preference lets you configure the load balancer to enforce cipher ordering, providing more control over the level of security used by clients to connect with your load balancer.

ELB does not support client certificate authentication (API Gateway does support this).

ELB Security Groups

Security groups control the ports and protocols that can reach the front end listener.

In non-default VPCs you can choose which security group to assign.

You must assign a security group for the ports and protocols on the front-end listener.

You need to also allow the ports and protocols for the health check ports and back-end listeners.

Security group configuration for ELB:

Inbound to ELB (allow).

  • Internet-facing ELB:
    • Source: 0.0.0.0/0.
    • Protocol: TCP.
    • Port: ELB listener ports.

Internet-Facing ELB Security Group Inbound Rules

  • Internal-only ELB:
    • Source: VPC CIDR.
    • Protocol: TCP.
    • Port: ELB Listener ports.

Internal-Only ELB Security Group Inbound Rules

Outbound (allow, either type of ELB):

  • Destination: EC2 registered instances security group.
  • Protocol: TCP.
  • Port: Health Check/Listener.

Internet-Facing ELB Security Group Outbound Rules

Security group configuration for registered instances:

Inbound to registered instances (Allow, either type of ELB).

  • Source: ELB Security Group.
  • Protocol: TCP.
  • Port: Health Check/Listener.

EC2 Registered Instances Security Group Inbound Rules

Outbound (Allow, for both types of ELB).

  • Destination: ELB Security Group.
  • Protocol: TCP.
  • Port: Ephemeral.

EC2 Registered Instances Security Group Outbound Rules

It is also important to ensure NACL settings are set correctly.

Distributed Denial of Service (DDoS) protection:

  • ELB automatically distributes incoming application traffic across multiple targets, such as Amazon Elastic Compute Cloud (Amazon EC2) instances, containers, and IP addresses, and multiple Availability Zones, which minimizes the risk of overloading a single resource.
  • ELB, like CloudFront, only supports valid TCP requests, so DDoS attacks such as UDP and SYN floods are not able to reach EC2 instances.
  • ELB also offers a single point of management and can serve as a line of defense between the internet and your backend, private EC2 instances.

ELB Monitoring

Monitoring takes place using:

  • CloudWatch – every 1 minute.
    • ELB service only sends information when requests are active.
    • Can be used to trigger SNS notifications.
  • Access Logs.
    • Disabled by default.
    • Includes information about the clients (not included in CloudWatch metrics).
    • Can identify requester, IP, request type etc.
    • Can be optionally stored and retained in S3.
  • CloudTrail.
    • Can be used to capture API calls to the ELB.
    • Can be stored in an S3 bucket.

Limits

The following table details the default limits for your account on a per-region basis:

AWS Elastic Load Balancing Limits

Classic Load Balancer (CLB)

The Classic Load Balancer provides basic load balancing across multiple Amazon EC2 instances and operates at both the request level and connection level.

Operates at layer 4 and layer 7.

Supported protocols: TCP, SSL, HTTP, HTTPS.

CLB does not support HTTP/2.

Load balancers can listen on the following ports:

  • [EC2-VPC] 1-65535.
  • [EC2-Classic] 25, 80, 443, 465, 587, 1024-65535.

CLB’s do not have pre-defined IPv4 addresses but are resolved using a DNS name.

Does not support Elastic IPs.

Supports IPv4 and IPv6.

Within a VPC only IPv4 is supported.

Provides SSL termination and processing.

Sticky Sessions:

  • Cookie-based sticky sessions are supported.
  • Session stickiness uses cookies and ensures a client is bound to an individual back-end instance for the duration of the cookie lifetime.
  • Cookies can be inserted by the application or by the load balancer when configured.
  • After cookies expire new requests will be routed by the load balancer normally and a new cookie will be inserted and bind subsequent sessions to the same back-end instance.
  • With application-inserted cookies if the back-end instance becomes unhealthy, new requests will be routed by the load balancer normally and a new cookie will be inserted and bind subsequent sessions to the same back-end instance.
  • With CLB-inserted cookies if the back-end instance becomes unhealthy, new requests will be routed by the load balancer normally BUT the session will no longer be sticky.

Must have multiple CLBs for multiple SSL certs.

Integrates with Auto Scaling, CloudWatch, CloudTrail and Route 53.

Instances monitored by CLB are reported as InService or OutofService.

Supports domain zone apex records, e.g. example.com.

Wildcard certificates are supported.

Health checks:

  • Can be configured for HTTP, TCP, HTTPS, SSL.
  • Ping port specifies the port for the health check.
  • Ping path specifies the path to check, e.g. /index.html.
  • Can define timeout, interval, unhealthy threshold, healthy threshold.

For fault tolerance it is recommended to distribute registered instances across multiple AZs (ideally evenly).

Cross-one load balancing:

  • Cross-zone load balancing is enabled by default for CLB and ALB but not for NLB (when created through the console).
  • Cross-zone load balancing is NOT enabled by default if the CLB is created from the CLI or API.
  • You can enable or disable cross-zone load balancing on the CLB and NLB at any time.
  • For the ALB, cross-zone load balancing is always on and cannot be disabled.
  • When cross-zone load balancing is enabled, each load balancer node distributes traffic across the registered targets in all enabled Availability Zones.
  • When cross-zone load balancing is disabled, each load balancer node distributes traffic across the registered targets in its Availability Zone only.

Connection draining is enabled by default and provides a period of time for existing connections to close cleanly.

When connection draining is in action a CLB will be in the status “InService: Instance deregistration currently in progress”.

CLB can take 1 to 7 minutes to detect an increase in load and scale.

If you’re anticipating a fast increase in load you can contact AWS and instruct them to pre-warm (provision) additional CLB nodes.

Listeners:

  • A CLB listener is the process that checks for connection requests.
  • You can configure the protocol/port on which your CLB listener listens.
  • Front-end listeners check for traffic from clients to the CLB.
  • Back-end listeners are configured with the protocol/port to check for traffic from the CLB to the EC2 instances.
  • Front-end and back-end listeners can listen on ports 1-65535.
  • Front-end and back-end listeners must be at the same layer (e.g. layer 4 or layer 7).
  • There is a 1:1 mapping between front-end and back-end listeners.
  • Up to 100 listeners can be configured.
  • Supports L4 (TCP, SSL) and L7 (HTTP, HTTPS) listeners.

With packet interception the source IP/port will be from the ELB.

Proxy protocol for TCP/SSL carries the source (client) IP/port information.

The Proxy Protocol header helps you identify the IP address of a client when you have a load balancer that uses TCP for back-end connections.

Ensure the client doesn’t go through a proxy or there will be multiple proxy headers.

Also need to ensure the EC2 instance’s TCP stack can process the extra information.

X-forwarded-for for HTTP/HTTPS carries the source IP/port information.

To use an HTTPS listener the CLB must have an X.509 SSL/TLS server certificate – this will allow the CLB to terminate the secure session from the client to the CLB.

The session between the CLB and the EC2 instance can be re-encrypted.

You can use a certificate generated by AWS Certificate Manager (ACM) or your own certificate.

If you don’t want interception/offloading you can use TCP listeners with certificates on the EC2 instances (traffic is secured end-to-end).

Proxy protocol only applies to L4.

X-forwarded-for only applies to L7.

To filter by source IP use NACLs for proxy protocol (L4) / X-forwarded-for (L7) headers with the EC2  instance’s application performing the filtering.

Security

CLB supports a single X.509 certificate.

Two way authentication with client certificates is not supported on the CLB – you would need to pass through the session using the proxy protocol and have an application that supports client-side certificates.

When using end-to-end encryption use TCP not SSL/HTTPS on the CLB (does not support Session Stickiness).

AWS ACM certificates include an RSA public key – ensure you include a set of ciphers that support RSA in the security policy.

The latest predefined security policy does not include support for SSLv3.

When choosing a custom security policy you can select the ciphers and protocols (only for CLB).

SSL Security Policy includes:

  • Protocol Versions (SSL/TLS).
    • Supports TLS 1.0, 1.1, 1.2, SSL 3.0.
  • SSL Ciphers.
    • Encryption algorithms.
    • SSL can use different ciphers to encrypt data.
  • Server Order Preference.
    • When enabled the first match in the cipher list with the Client list is used.

If disabled (default) the first match in the client cipher list with the CLB is used.

 

Application Load Balancer (ALB)

The Application Load Balancer operates at the request level (layer 7), routing traffic to targets – EC2 instances, containers and IP addresses based on the content of the request.

You can load balance HTTP/HTTPS applications and use layer 7-specific features, such as X-Forwarded-For headers.

Supports HTTPS termination between the clients and the load balancer.

Supports management of SSL certificates through AWS IAM and AWS Certificate Manager for pre-defined security policies.

Server Name Indication (SNI) supports multiple secure websites using a single secure listener.

With Server Name Indication a client indicates the hostname to connect to.

IP addresses as targets allows load balancing any application hosted in AWS or on-premises using IP addresses of the application back-ends as targets.

Need at least 2 availability zones and you can distribute incoming traffic across your targets in multiple Availability Zones.

Automatically scales its request handling capacity in response to incoming application traffic.

Can configure an Application Load Balancer to be Internet facing or create a load balancer without public IP addresses to serve as an internal (non-Internet-facing) load balancer.

Native IPv6 support.

Internal only ALB only supports IPv4.

Content-Based Routing allows the routing of requests to a service based on the content of the request:

  • Host-based routing – route client requests based on the Host field of the HTTP header allowing you to route to multiple domains from the same load balancer.
  • Path-based routing – route a client request based on the URL path of the HTTP header (e.g. /images or /orders).

Provides support for micro-services and containers with load balancing across multiple ports on a single EC2 instance.

Better performance for real-time streaming.

Deletion protection can be enabled.

Request tracing (allows you to track a request by its unique ID).

Better health checks and CloudWatch metrics.

Integration with Amazon Cognito for user authentication.

Uses a round-robin load balancing algorithm.

Slow start mode allows targets to “warm up” with a ramp-up period.

Health Checks:

  • Can have custom response codes in health checks (200-399).
  • There are more details provided in the API and management console for health check failures.
  • Reason codes are returned with failed health checks.
  • Health checks do not support WebSockets.
  • Fail open means if no AZ contains a healthy target, the load balancer nodes route requests to all targets.

Detailed access log information is provided and saved to an S3 bucket every 5 or 6 minutes.

ALB does not support back-end server authentication (CLB does).

ALB does not support EC2-Classic (CLB does).

Deletion protection is possible.

Deregistration delay is similar to connection draining.

Sticky Sessions:

  • Session stickiness uses cookies and ensures a client is bound to an individual back-end instance for the duration of the cookie lifetime.
  • ALB supports load balancer-generated cookies only.
  • The name of the cookie is AWSALB.
  • The contents of these cookies are encrypted using a rotating key.
  • You cannot decrypt or modify load balancer-generated cookies.
  • Sticky sessions are enabled at the target group level.
  • You can also set the duration for the stickiness of the load balancer-generated cookie, in seconds.
  • WebSockets connections are inherently sticky (following the upgrade process).

Monitoring

CloudTrail can be used to capture API calls. Only pay for the S3 storage charges.

CloudTrail records information on API calls only.

To monitor other actions such as time the request was received, the client’s IP address, request paths etc. use access logs.

Access logging is optional and disabled by default.

You are only charged for the S3 storage.

ALB logs requests sent to the load balancer including requests that never made it to targets.

ALB does not log health check requests.

Logging of requests is best effort so shouldn’t be relied on for auditing.

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, or IP addresses.

Target groups can exist independently from the ALB.

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

You cannot use public IP addresses as targets.

You cannot use instance IDs and IP address targets within the same target group.

A target group can only be associated with one load balancer.

The following diagram illustrates the basic components. Notice that each listener contains a default rule, and one listener contains another rule that routes requests to a different target group. One target is registered with two target groups.

ALB Listeners, targets and rules

Target groups are used for registering instances against an ALB or NLB.

Target groups are a regional construct.

The following diagram shows how target groups can be used with host-based and target-based routing to route traffic to multiple websites, running on multiple ports, on a single EC2 instance:

ALB Host-Path Routing

The following attributes can be defined:

  • Deregistration delay – the amount of time for Elastic Load Balancing to wait before deregistering a target.
  • Slow start duration – the time period, in seconds, during which the load balancer sends a newly registered target a linearly increasing share of the traffic to the target group.
  • Stickiness – indicates whether sticky sessions are enabled.

The default settings for attributes are shown below:

ELB Target Group Attributes

Auto Scaling groups can scale each target group individually.

You can only use Auto Scaling with the load balancer if using instance IDs in your target group.

Health checks are defined per target group.

ALB can route to multiple target groups.

You can register the same EC2 instance or IP address with the same target group multiple times using different ports (used for routing requests to micro-services).

If you register by instance ID the traffic is routed using the primary private IP address of the primary network interface.

If you register by IP address you can route traffic to an instance using any private address from one or more network interfaces.

You cannot mix different types within a target group (EC2, ECS, IP).

An EC2 instance can be registered with the same target group multiple times using multiple ports.

IP addresses can be used to register:

  • Instances in a peered VPC.
  • AWS resources that are addressable by IP address and port.
  • On-premises resources linked to AWS through Direct Connect or a VPN connection.

Listeners and Rules

Listeners:

  • 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 ALB.
  • 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.

The image below shows a ruleset with a host-based and path-based entry and a default rule at the end:

ALB Ruleset

Default rules:

  • When you create a listener you define an action for the default rule.
  • Default rules cannot have conditions.
  • You can delete the non-default rules for a listener at any time.
  • You cannot delete the default rule for a listener.
  • When you delete a listener all of its rules are deleted.
  • If no conditions for any of a listener’s rules are met, the action for the default rule is taken.

Rule priority:

  • Each rule has a priority and they are evaluated in order of lowest to highest.
  • The default rule is evaluated last.
  • You can change the value of a non-default rule at any time.
  • You cannot change the value of the default rule.

Rule action:

  • Only one target group per action.
  • Each rule has a type and a target group.
  • The only supported action type is forward, which forwards requests to the target group.
  • You can change the target group for a rule at any time.

Rule conditions:

  • There are two types of rule condition: host and path.
  • When the conditions for a rule are met the action is taken.
  • Each rule can have up to 2 conditions, 1 path condition and 1 host condition.
  • Optional condition is the path pattern you want the ALB to evaluate in order for it to route requests.

Request routing:

  • After the load balancer receives a request it evaluates the listener rules in priority order to determine which rule to apply, and then selects a target from the target group for the rule action using the round robin routing algorithm.
  • Routing is performed independently for each target group even when a target is registered with multiple target groups.
  • You can configure listener rules to route requests to different target groups based on the content of the application traffic.

Content-based routing:

  • ALB can route requests based on the content of the request in the host field: host-based or path-based.
  • Host-based is domain name based routing e.g. example.com or app1.example.com.
  • The host field contains the domain name and optionally the port number.
  • Path-based is URL based routing e.g. example.com/images, example.com/app1.
  • You can also create rules that combine host-based and path-based routing.
  • Anything that doesn’t match content routing rules will be sent to a default target group.

ALB and ECS

ECS service maintains the “desired count” of instances.

Optionally a load balancer can distribute traffic across tasks.

All containers in a single task definition are placed on a single EC2 container instance.

You can put multiple containers in the same task definition behind a CLB.

  • Define multiple host ports in the service definition.
  • Define these listener ports as listeners on the CLB.

ECS service can only use a single load balancer.

If your task definition requires multiple ports per container you must use a CLB with multiple listeners.

ALB cannot do multiple listeners on a single task definition.

AWS does not recommend connecting multiple services to the same CLB.

ALB allows containers to use dynamic host port mapping so that multiple tasks from the same service are allowed on the same container host.

ALB supports path-based routing and priority rules.

ALB integrates with EC2 container service using service load balancing.

If a service uses multiple ports then multiple task definitions will need to be created with multiple target groups.

Federated authentication:

  • ALB now supports authentication from OIDC compliant identity providers such as Google, Facebook and Amazon.
  • Implemented through an authentication action on a listener rule that integrates with Amazon Cognito to create user pools.
  • AWS SAM can also be used with Amazon Cognito.

Network Load Balancer

Network Load Balancer operates at the connection level (Layer 4), routing connections to targets – Amazon EC2 instances, containers and IP addresses based on IP protocol data.

It is architected to handle millions of requests/sec, sudden volatile traffic patterns and provides extremely low latencies.

Network Load Balancer supports features including:

  • WebSockets.
  • TLS termination.
  • Preserves the source IP of the clients.
  • Provides stable IP support and Zonal isolation.
  • Long-running connections that are very useful for WebSocket type applications.

High throughput – designed to handle traffic as it grows and can load balance millions of requests/second.

Extremely low latencies for latency-sensitive applications.

Want to see the Network Load Balancer in action? In the AWS Hands-On Labs video tutorial, below we’ll be covering the Network Load Balancer (NLB). In around 10 minutes, we’ll review the differences between the NLB and the Application Load Balancer (CLB) and Classic Load Balancer (CLB), setup an Internet-facing NLB with Target Groups and EC2 web server instances and demonstrate the load balancing behaviour of the NLB.

Uses static IP addresses – each NLB provides a single IP address for each AZ.

Can also assign an Elastic IP to the load balancer per AZ.

The IP-per-AZ feature reduces latency with improved performance, improves availability through isolation and fault tolerance and makes the use of NLBs transparent to your client applications.

Preserves the source IP of clients, and provides stable IP support and Zonal isolation.

Can load balance any application hosted in AWS or on-premises using IP addresses of the application back-ends as targets.

NLB supports connections from clients to IP-based targets in peered VPCs across different AWS Regions.

Supports both network and application target health checks.

Supports long-running/lived connections (ideal for WebSocket applications).

Supports failover between IP addresses within and across regions (uses Route 53 health checks).

Integration with Route 53 enables the removal of a failed load balancer IP address from service and subsequent redirection of traffic to an alternate Network Load Balancer in another region.

Supports cross-zone load balancing (not enabled by default when created through the console, unlike ALB and CLB).

Uses the same API as the Application Load Balancer.

Also uses Target Groups (see section above).

Target groups for Network Load Balancers support the following protocols and ports:

  • Protocols: TCP, TLS, UDP, TCP_UDP.
  • Ports: 1-65535.

The following table summarizes the supported combinations of listener protocol and target group settings:

NLB Listener and Target Group Support

CloudWatch reports Network Load Balancer metrics.

Enhanced logging – can use the Flow Logs feature to record all requests sent to your load balancer.

Ready to test yourself? Click here to check out the free sample practice questions for AWS Compute

Also in AWS Compute

References

https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/load-balancer-types.html

https://aws.amazon.com/elasticloadbalancing/faqs/

https://aws.amazon.com/elasticloadbalancing/resources/

https://aws.amazon.com/elasticloadbalancing/pricing/

25 thoughts on “Elastic Load Balancing”

  1. NLB Supports SSL termination now. Updated in 2019 to support TLS listeners. Also wanted to check, if you have tests available for Pro level certification as well?

    1. Update this and revisit this document. I see lot of out to date information
      Does not support SSL termination (NLB) – it indeed supports and that is one of they key features of using NLB
      Q: What are the key features available with the Network Load Balancer?

      A: Network Load Balancer provides TCP (Layer 4) load balancing. It is architected to handle millions of requests/sec, sudden volatile traffic patterns and provides extremely low latencies. In addition Network Load Balancer also supports TLS termination, preserves the source IP of the clients, and provides stable IP support and Zonal isolation. It also supports long-running connections that are very useful for WebSocket type applications.

  2. Hi Neal, thank a lot for your great notes on the subject. I’ve some difficulties to understand the reason behind the following rule:

    “You must create public subnets in the same Availability Zones as the private subnets that are used by your private instances. Then associate these public subnets to the internet-facing load balancer.” (https://aws.amazon.com/premiumsupport/knowledge-center/public-load-balancer-private-ec2/)

    Let say, we have three private subnets on three different AZs with EC2 instances running on them. Why do we need to create three public subnets (one in each AZ) and assign the to the ELB? Wouldn’t is be enough to have only two subnets? This way the HA for the ELB is given (it would tolerate the absence of one AZ).

    I understand that using three public subnets would be more resilient. But what is the intention of AWS for enforcing this rule?

    1. Hi Ali, it’s because of the way ELB’s are implemented on AWS. They are actually EC2 instances and internet facing ELBs have public IPs. The association of the public subnet within each AZ is so that AWS can deploy an ELB instance into that AZ.

      1. Hi Neal, thanks for your response. I understand that internet facing ELB’s are implemented as EC2 instances and need public IPs.
        But, we can have two public subnets and three private subnets all being part of the same VPC and assign the public subnets to the ELB. The EC2 instances for the ELB will be deployed into public subnets and get their public IPs. They can route requests to instances in the private subnets using their private ips. So I still don’t understand why it is necessary to have three public subnets…

        1. It’s per Availability Zone. You must have 1 public subnet per AZ that corresponds with a private subnet where you have EC2 instances. Please check the AWS link provided which gives more detail on how this all works.

  3. Dmitriy Subbotovskiy

    For NLB – can you elaborate on routing/decision algorithm…since it’s not content-based like ALB, what is the decision made based on? Or is it simple round robin? Thanks!

    1. It’s more like round robin whereby it spreads the connections to available instances in each AZ. If you have cross-zone load balancing enabled it will distributed evenly between instances, whereas if you have it disabled it will distribute evenly between AZs (not regarding how many instances are in each AZ).

  4. amarech@gmail.com

    Is this statement valid for all types of load balancers or just for classic ELB?

    “make sure there are at least 8 IP addresses available in order for the ELB to scale”

    Thanks!

    1. Hi, this is valid for all types of load balancer. The ELBs use EC2 nodes and auto scale as required. The reserved addresses are used for the ELB nodes and this applies to CLB, ALB and NLB.

  5. I am having a problem with this statement:

    With application-inserted cookies if the back-end instance becomes unhealthy, new requests will be routed by the load balancer normally and a new cookie will be inserted and bind subsequent sessions to the same back-end instance
    With CLB-inserted cookies if the back-end instance becomes unhealthy, new requests will be routed by the load balancer normally BUT the session will no longer be sticky

    What does “normal” mean? It seems to contradict what is found in docs. Where it states in case of an unhealthy instance, the CLB will route to a new instance and create a new sticky session on that new instance whether the old one comes back or not. Please clarify your above statement.

    1. Hi Doug, do you have a reference you’d like to share? Normally means it will be routed by the load balancing algorithm the same way any new session would be.

  6. Hey Neal,

    What is meant by ‘An ELB scales automatically to meet the desired capacity’? Are they mentioning about auto scaling here or can ELB scales itself?

    Thanks, Sabareesh M

    1. Hi Sabareesh, ELB nodes are actually EC2 instances that auto scale. This is transparent to us and handled by AWS but that’s how they are able to scale the ELBs horizontally in response to load.

      1. Hey Neal,

        Thanks for your response, I would like to know how can we scale it up and where can we see the capacity of an ELB? What does the capacity of an ELB denotes is it no. of connection requests? or anything else?

        1. This is transparent to us as users so there’s not a lot of control we have. I expect AWS scale based on a number of factors including connections, processing, and bandwidth to ensure latency is reduced as much as possible. The one area you need to know about is pre-warming where you contact AWS to notify them of expected large traffic spikes. This ensures that they are able to scale the ELB nodes ahead of time to reduce the risk of failing connection requests.

        1. ALB by default, and for CLB depends on how you created the LB. from Amazon Docs:

          When you create a Classic Load Balancer, the default for cross-zone load balancing depends on how you create the load balancer. With the API or CLI, cross-zone load balancing is disabled by default. With the AWS Management Console, the option to enable cross-zone load balancing is selected by default. After you create a Classic Load Balancer, you can enable or disable cross-zone load balancing at any time.

Leave a Reply

Scroll to Top