Elastic load balancing

The term Elastic load balancing refers to the practice of distributing requests across multiple application nodes with the objective of maximizing resource usage and increasing overall application performance. A load balancer is a piece of software, usually running on a dedicated node, that receives incoming requests and distributes them to application nodes. For cloud-native architectures where application nodes change often, load balancers represent a critical infrastructure component that should be carefully architected in order to ensure the performance, security, and availability of the application. Load balancers are often presented as the entry point to an application, and they typically offer more functionality than simple request routing. 

  • Elastic Load Balancing (ELB) automatically distributes incoming application traffic across multiple targets, such as Amazon EC2 instances, containers, and IP addresses. 
  • Elastic Load Balancing (ELB) can handle the varying load of the application traffic in a single Availability Zone or across multiple Availability Zones. Elastic Load Balancing offers three types of load balancers that all feature the high availability, automatic scaling, and robust security necessary to make the applications fault tolerant.
  • 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. Simple, flexible configuration and support for multiple types of application targets. Simplified integration with other core AWS services, such as Amazon CloudWatch for monitoring and metrics and Security Groups for network reachability.
 
Elastic load balancing

Elastic load balancing Benefits

A load balancer distributes workloads across multiple compute resources, such as virtual servers. Using a load balancer increases the availability and fault tolerance of the applications. Users can add and remove compute resources from the load balancer as needed change, without disrupting the overall flow of requests to the  applications. Users can configure health checks, which monitor the health of the compute resources, so that the load balancer sends requests only to the healthy ones. They can also offload the work of encryption and decryption to the load balancer so that users compute resources can focus on their main work. 

Network Load Balancer is best suited for load balancing of TCP 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.

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.

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.

Elastic load balancing Features

Distribution of requests to Amazon EC2 instances (servers) in multiple Availability Zones so that the risk of overloading one single instance is minimized. And if an entire Availability Zone goes offline, Elastic Load Balancing routes traffic to instances in other Availability Zones. 

  • Continuous monitoring of the health of Amazon EC2 instances registered with the load balancer so that requests are sent only to the healthy instances. If an instance becomes unhealthy, Elastic Load Balancing stops sending traffic to that instance and spreads the load across the remaining healthy instances.
  • Support for end-to-end traffic encryption on those networks that use secure (HTTPS/SSL) connections.
  • The ability to take over the encryption and decryption work from the Amazon EC2 instances, and manage it centrally on the load balancer.

Support for the sticky session feature, which is the ability to “stick” user sessions to specific Amazon EC2 instances. Association of the load balancer with your domain name. Because the load balancer is the only computer that is exposed to the Internet, users don’t have to create and manage public domain names for the instances that the load balancer manages.

  • Users can point the instance’s domain records at the load balancer instead and scale as needed (either adding or removing capacity) without having to update the records with each scaling activity.
  • When used in an Amazon Virtual Private Cloud (Amazon VPC), support for creation and management of security groups associated with the load balancer to provide additional networking and security options.
  • Supports use of both the Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6).

Sticky sessions: Sticky sessions are a mechanism to route requests from the same client to the same target. Elastic Load Balancers support sticky sessions. Stickiness is defined at a target group level.

Operational monitoring & logging: Amazon CloudWatch reports Application and Classic Load Balancer metrics such as request counts, error counts, error types, request latency, and more. Amazon CloudWatch also tracks Network and Gateway Load Balancer metrics such as Active Flow count, New Flow Count, Processed bytes, and more. Elastic Load Balancers are also integrated with AWS CloudTrail which tracks API calls to the ELB.

Delete protection: Users can enable deletion protection on an Elastic Load Balancer to prevent it from being accidentally deleted.

Security: When using Amazon Virtual Private Cloud (VPC), you can create and manage security groups associated with Elastic Load Balancing to provide additional networking and security options for Application Load Balancer and Classic Load Balancer. Users can configure any of the Load Balancers to be Internet facing or create a load balancer without public IP addresses to serve as an internal (non-internet-facing) load balancer.

High availability: An Elastic Load Balancer is highly available. Users can distribute incoming traffic across the Amazon EC2 instances in a single Availability Zone or multiple Availability Zones. An Elastic Load Balancer automatically scales its request handling capacity in response to incoming application traffic. To ensure the targets are available and healthy, Elastic Load Balancer runs health checks on targets on a configurable cadence.

High throughput: Elastic Load Balancer is designed to handle traffic as it grows and can load balance millions of requests/sec. It can also handle sudden volatile traffic patterns.

Health checks: An Elastic Load Balancer only routes traffic to healthy targets such as EC2 instances, containers, IP addresses, microservices, Lambda functions, and Appliances. With Elastic Load Balancing, users get improved insight into the health of the applications in two ways: (1) health check improvements that allow to configure detailed error codes. The health checks allow users to monitor the health of each of the services behind the the load balancer; and (2) new metrics that give insight into traffic for each of the services running on an EC2 instance.

Elastic Load Balancing Concepts 

A load balancer accepts incoming traffic from clients and routes requests to its registered targets (such as EC2 instances) in one or more Availability Zones. The load balancer also monitors the health of its registered targets and ensures that it routes traffic only to healthy targets. When the load balancer detects an unhealthy target, it stops routing traffic to that target. It then resumes routing traffic to that target when it detects that the target is healthy again. Users configure the load balancer to accept incoming traffic by specifying one or more listeners. A listener is a process that checks for connection requests. It is configured with a protocol and port number for connections from clients to the load balancer. 

Availability Zones and load balancer nodes

When users enable an Availability Zone for the load balancer, Elastic Load Balancing creates a load balancer node in the Availability Zone. When  registering targets in an Availability Zone but do not enable the Availability Zone, these registered targets do not receive traffic. Users load balancer is most effective when each enabled Availability Zone has at least one registered target.

  • AWS recommend enabling multiple Availability Zones for all load balancers. With an Application Load Balancer however, it is a requirement at least two or more Availability Zones are enabled. This configuration helps ensure that the load balancer can continue to route traffic. If one Availability Zone becomes unavailable or has no healthy targets, the load balancer can route traffic to the healthy targets in another Availability Zone.
  • After disabled an Availability Zone, the targets in that Availability Zone remain registered with the load balancer. However, even though they remain registered, the load balancer does not route traffic to them.
Cross-zone load balancing

The nodes for load balancer distribute requests from clients to registered targets. 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 only across the registered targets in its Availability Zone.

The diagrams below demonstrate the effect of cross-zone load balancing. There are two enabled Availability Zones, with two targets in Availability Zone A and eight targets in Availability Zone B. Clients send requests, and Amazon Route 53 responds to each request with the IP address of one of the load balancer nodes. This distributes traffic such that each load balancer node receives 50% of the traffic from the clients. Each load balancer node distributes its share of the traffic across the registered targets in its scope.

If cross-zone load balancing is enabled, each of the 10 targets receives 10% of the traffic. This is because each load balancer node can route its 50% of the client traffic to all 10 targets.

If cross-zone load balancing is disabled:

  • Each of the two targets in Availability Zone A receives 25% of the traffic.
  • Each of the eight targets in Availability Zone B receives 6.25% of the traffic. This is because each load balancer node can route its 50% of the client traffic only to targets in its Availability Zone.

With Application Load Balancers, cross-zone load balancing is always enabled.

With Network Load Balancers and Gateway Load Balancers, cross-zone load balancing is disabled by default. After creating  the load balancer, users can enable or disable cross-zone load balancing at any time.

During the creation of a Classic Load Balancer, the default for cross-zone load balancing depends on how users 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, users can enable or disable cross-zone load balancing at any time.

Request routing

Before a client sends a request to users load balancer, it resolves the load balancer’s domain name using a Domain Name System (DNS) server. The DNS entry is controlled by Amazon, because the load balancers are in the amazonaws.com domain. The Amazon DNS servers return one or more IP addresses to the client. These are the IP addresses of the load balancer nodes for the load balancer. With Network Load Balancers, Elastic Load Balancing creates a network interface for each Availability Zone that users enable. Each load balancer node in the Availability Zone uses this network interface to get a static IP address. Users can optionally associate one Elastic IP address with each network interface when creating the load balancer.

  • As traffic to the application changes over time, Elastic Load Balancing scales the load balancer and updates the DNS entry. The DNS entry also specifies the time-to-live (TTL) of 60 seconds. This helps ensure that the IP addresses can be remapped quickly in response to changing traffic.
  • The client determines which IP address to use to send requests to the load balancer. The load balancer node that receives the request selects a healthy registered target and sends the request to the target using its private IP address.
HTTP connections

Classic Load Balancers use pre-open connections, but Application Load Balancers do not. Both Classic Load Balancers and Application Load Balancers use connection multiplexing. This means that requests from multiple clients on multiple front-end connections can be routed to a given target through a single backend connection. Connection multiplexing improves latency and reduces the load on your applications. To prevent connection multiplexing, disable HTTP keep-alives by setting the Connection: close header in your HTTP responses.

  • Application Load Balancers and Classic Load Balancers support pipelined HTTP on front-end connections. They do not support pipelined HTTP on backend connections.
  • Application Load Balancers support the following protocols on front-end connections: HTTP/0.9, HTTP/1.0, HTTP/1.1, and HTTP/2. Users can use HTTP/2 only with HTTPS listeners, and can send up to 128 requests in parallel using one HTTP/2 connection. 
  • For HTTP/1.0 requests from clients that do not have a host header, the load balancer generates a host header for the HTTP/1.1 requests sent on the backend connections. The host header contains the DNS name of the load balancer.

Classic Load Balancers support the following protocols on front-end connections (client to load balancer): HTTP/0.9, HTTP/1.0, and HTTP/1.1. They use HTTP/1.1 on backend connections (load balancer to registered target). Keep-alive is supported on backend connections by default. For HTTP/1.0 requests from clients that do not have a host header, the load balancer generates a host header for the HTTP/1.1 requests sent on the backend connections. The host header contains the IP address of the load balancer node.

Load balancer scheme

When creating a load balancer, users need to choose whether to make it an internal load balancer or an internet-facing load balancer. Note that when creating a Classic Load Balancer in EC2-Classic, it must be an internet-facing load balancer. The nodes of an internet-facing load balancer have public IP addresses. The DNS name of an internet-facing load balancer is publicly resolvable to the public IP addresses of the nodes. Therefore, internet-facing load balancers can route requests from clients over the internet.

  • The nodes of an internal load balancer have only private IP addresses. The DNS name of an internal load balancer is publicly resolvable to the private IP addresses of the nodes. Therefore, internal load balancers can only route requests from clients with access to the VPC for the load balancer.
  • Both internet-facing and internal load balancers route requests to your targets using private IP addresses. Therefore, users targets do not need public IP addresses to receive requests from an internal or an internet-facing load balancer.

If the application has multiple tiers, users can design an architecture that uses both internal and internet-facing load balancers. For example, this is true when application uses web servers that must be connected to the internet, and application servers that are only connected to the web servers. Create an internet-facing load balancer and register the web servers with it. Create an internal load balancer and register the application servers with it. The web servers receive requests from the internet-facing load balancer and send requests for the application servers to the internal load balancer. The application servers receive requests from the internal load balancer.

Elastic Load Balancing Concepts 

#01

Application Load Balancer

 
 

An Application Load Balancer functions at the application layer, the seventh layer of the Open Systems Interconnection (OSI) model. 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. Users can configure listener rules to route requests to different target groups based on the content of the application traffic. Routing is performed independently for each target group, even when a target is registered with multiple target groups. Users can configure the routing algorithm used at the target group level. The default routing algorithm is round robin; alternatively, users can specify the least outstanding requests routing algorithm.

Users can add and remove targets from the load balancer as needed, without disrupting the overall flow of requests to the application. Elastic Load Balancing scales the load balancer as traffic to the application changes over time. Elastic Load Balancing can scale to the vast majority of workloads automatically.

  • load balancer serves as the single point of contact for clients. The load balancer distributes incoming application traffic across multiple targets, such as EC2 instances, in multiple Availability Zones. This increases the availability of the application.
  • A listener checks for connection requests from clients, using the protocol and port configuration. The rules that was defined for a listener determine how the load balancer routes requests to its registered targets. Each rule consists of a priority, one or more actions, and one or more conditions. When the conditions for a rule are met, then its actions are performed. Users need to  define a default rule for each listener, and optionally define additional rules.
  • Each target group routes requests to one or more registered targets, such as EC2 instances, using the protocol and port number that users specify. Users can register a target with multiple target groups. They can configure health checks on a per target group basis. Health checks are performed on all targets registered to a target group that is specified in a listener rule for the load balancer.

Application Load Balancer operates at the request level (layer 7), routing traffic to targets (EC2 instances, containers, IP addresses, and Lambda functions) based on the content of the request. Ideal for advanced load balancing of HTTP and HTTPS traffic, Application Load Balancer provides advanced request routing targeted at delivery of modern application architectures, including microservices and container-based applications. Application Load Balancer simplifies and improves the security of users application, by ensuring that the latest SSL/TLS ciphers and protocols are used at all times.

  • Layer-7 Load Balancing: Users  can load balance HTTP/HTTPS traffic to targets – Amazon EC2 instances, microservices, and containers based on request attributes (such as X-Forwarded-For headers).
  • Security Features: When using Amazon Virtual Private Cloud (VPC), users can create and manage security groups associated with Elastic Load Balancing to provide additional networking and security options. Users 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.
  • Outposts Support: Application Load Balancer (ALB) supports AWS Outposts, a fully managed service that extends AWS infrastructure, services, and tools to virtually any datacenter, co-location space, or on-premises facility for a truly consistent hybrid experience. Customers can provision ALBs on supported instance types and the ALB will auto scale up to the capacity available on the rack to meet varying levels of application load without manual intervention. 
  • HTTPS Support: An Application Load Balancer supports HTTPS termination between the clients and the load balancer. Application Load Balancers also offer management of SSL certificates through AWS Identity and Access Management (IAM) and AWS Certificate Manager for pre-defined security policies.
  • HTTP/2 and gRPC Support: HTTP/2 is a new version of the HyperText Transfer Protocol (HTTP) that uses a single, multiplexed connection to allow multiple requests to be sent on the same connection. It also compresses header data before sending it out in binary format and supports SSL connections to clients.
  • TLS Offloading: Users can create an HTTPS listener, which uses encrypted connections (also known as SSL offload). This feature enables traffic encryption between the load balancer and the clients that initiate SSL or TLS sessions. Application Load Balancer supports client TLS session termination. This enables you to offload TLS termination tasks to the load balancer, while preserving the source IP address for your back-end applications.
  • Sticky Sessions: Sticky sessions are a mechanism to route requests from the same client to the same target. Application Load Balancer supports sticky sessions using load balancer generated cookies. When enabled sticky sessions, the same target receives the request and can use the cookie to recover the session context. Stickiness is defined at a target group level.
  • Native IPv6 Support: Application Load Balancers support native Internet Protocol version 6 (IPv6) in a VPC. This will allow clients to connect to the Application Load Balancer via IPv4 or IPv6.
  • Request Tracing: The Application Load Balancer injects a new custom identifier “X-Amzn-Trace-Id” HTTP header on all requests coming into the load balancer. Request tracing allows to track a request by its unique ID as it makes its way across various services that make up the bulk of traffic for the websites and distributed applications. Users can use the unique trace identifier to uncover any performance or timing issues in the application stack at the granularity of an individual request.
 

A Network Load Balancer functions at the fourth layer of the Open Systems Interconnection (OSI) model. It can handle millions of requests per second. After the load balancer receives a connection request, it selects a target from the target group for the default rule. It attempts to open a TCP connection to the selected target on the port specified in the listener configuration. When enabled an Availability Zone for the load balancer, Elastic Load Balancing creates a load balancer node in the Availability Zone. By default, each load balancer node distributes traffic across the registered targets in its Availability Zone only. When enabled cross-zone load balancing, each load balancer node distributes traffic across the registered targets in all enabled Availability Zones

  • For TCP traffic, the load balancer selects a target using a flow hash algorithm based on the protocol, source IP address, source port, destination IP address, destination port, and TCP sequence number. The TCP connections from a client have different source ports and sequence numbers, and can be routed to different targets. Each individual TCP connection is routed to a single target for the life of the connection.
  • For UDP traffic, the load balancer selects a target using a flow hash algorithm based on the protocol, source IP address, source port, destination IP address, and destination port. A UDP flow has the same source and destination, so it is consistently routed to a single target throughout its lifetime. Different UDP flows have different source IP addresses and ports, so they can be routed to different targets.
  • Users can use SNI to serve multiple secure websites using a single TLS listener. If the hostname in the client matches multiple certificates, the load balancer selects the best certificate to use based on a smart selection algorithm.

Network Load Balancer operates at the connection level (Layer 4), routing connections to targets (Amazon EC2 instances, microservices, and containers) within Amazon VPC, based on IP protocol data. Ideal for load balancing of both TCP and UDP traffic, Network Load Balancer is capable of handling millions of requests per second while maintaining ultra-low latencies. Network Load Balancer is optimized to handle sudden and volatile traffic patterns while using a single static IP address per Availability Zone. It is integrated with other popular AWS services such as Auto Scaling, Amazon EC2 Container Service (ECS), Amazon CloudFormation, and AWS Certificate Manager (ACM).

  • Connection-based Layer 4 Load Balancing: Users can load balance both TCP and UDP traffic, routing connections to targets – Amazon EC2 instances, microservices, and containers.
  • TLS Offloading: Network Load Balancer supports client TLS session termination. This enables users to offload TLS termination tasks to the load balancer, while preserving the source IP address for the back-end applications. Users can choose from predefined security policies for the TLS listeners in order to meet compliance and security standards. AWS Certificate Manager (ACM) or AWS Identity and Access Management (IAM) can be used to manage your server certificates.
  • Sticky Sessions: Sticky sessions (source IP affinity) are a mechanism to route requests from the same client to the same target. Stickiness is defined at the target group level.
  • Low Latency: Network Load Balancer offers extremely low latencies for latency-sensitive applications.
  • Preserve source IP address: Network Load Balancer preserves the client side source IP allowing the back-end to see the IP address of the client. This can then be used by applications for further processing.
  • Static IP support: Network Load Balancer automatically provides a static IP per Availability Zone (subnet) that can be used by applications as the front-end IP of the load balancer.
  • Elastic IP support: Network Load Balancer also allows users the option to assign an Elastic IP per Availability Zone (subnet) thereby providing own fixed IP.
  • DNS Fail-over: If there are no healthy targets registered with the Network Load Balancer or if the Network Load Balancer nodes in a given zone are unhealthy, then Amazon Route 53 will direct traffic to load balancer nodes in other Availability Zones.
  • Integration with Amazon Route 53: In the event that the Network Load Balancer is unresponsive, integration with Route 53 will remove the unavailable load balancer IP address from service and direct traffic to an alternate Network Load Balancer in another region.
  • Integration with AWS Services: Network Load Balancer is integrated with other AWS services such as Auto Scaling, Elastic Container Service (ECS), CloudFormation, Elastic BeanStalk, CloudWatch, Config, CloudTrail, CodeDeploy, and AWS Certificate Manager (ACM).
  • Long-lived TCP Connections: Network Load Balancer supports long-lived TCP connections that are ideal for WebSocket type of applications.
  • Central API Support: Network Load Balancer uses the same API as Application Load Balancer. This will enable users to work with target groups, health checks, and load balance across multiple ports on the same Amazon EC2 instance to support containerized applications.
  • Zonal Isolation: The Network Load Balancer is designed for application architectures in a single zone. If something in the Availability Zone fails, AWS will automatically fail-over to other healthy Availability Zones. While AWS recommend customers configure the load balancer and targets in multiple AZs for achieving high availability, Network Load Balancer can be enabled in a single Availability Zone to support architectures that require zonal isolation.

#02

Network Load Balancer

 
 

 

#03

Gateway Load Balancer

 
 

Gateway Load Balancers enable users to deploy, scale, and manage virtual appliances, such as firewalls, intrusion detection and prevention systems, and deep packet inspection systems. A Gateway Load Balancer operates at the third layer of the Open Systems Interconnection (OSI) model, the network layer. It listens for all IP packets across all ports and forwards traffic to the target group that’s specified in the listener rule. The Gateway Load Balancer and its registered virtual appliance instances exchange application traffic using the GENEVE protocol on port 6081. It supports a maximum transmission unit (MTU) size of 8500 bytes.

  • Gateway Load Balancers use Gateway Load Balancer endpoints to securely exchange traffic across VPC boundaries. A Gateway Load Balancer endpoint is a VPC endpoint that provides private connectivity between virtual appliances in the service provider VPC and application servers in the service consumer VPC. Users deploy the Gateway Load Balancer in the same VPC as the virtual appliances. Users register the virtual appliances with a target group for the Gateway Load Balancer.
  • Traffic to and from a Gateway Load Balancer endpoint is configured using route tables. Traffic flows from the service consumer VPC over the Gateway Load Balancer endpoint to the Gateway Load Balancer in the service provider VPC, and then returns to the service consumer VPC. Users need to create the Gateway Load Balancer endpoint and the application servers in different subnets. This enables them to configure the Gateway Load Balancer endpoint as the next hop in the route table for the application subnet.

Gateway Load Balancer makes it easy to deploy, scale, and manage the third-party virtual appliances. It gives users one gateway for distributing traffic across multiple virtual appliances, while scaling them up, or down, based on demand. This eliminates potential points of failure in the network and increases availability. Users can find, test, and buy virtual appliances from third-party vendors directly in AWS Marketplace.

  • Deploy third-party virtual appliances faster: AWS Partner Network and AWS Marketplace partners are ready for Gateway Load Balancer today. As you move to the cloud, you can choose to continue using the appliances and tools you are familiar with, or look for something new. This can be done as simply as choosing a third-party virtual appliance in the AWS Marketplace.
  • Scale virtual appliances while managing costs: Hitting the limit of what your virtual appliances can handle can bottleneck the entire network. To prevent this, Gateway Load Balancer automatically scales the virtual appliances up, or down, based on demand. With many virtual appliances available with bring-your-own-license (BYOL) or pay-as-you-go pricing, users have the option to only pay for what is used, and reduce the chances of over provisioning.
  • Improve virtual appliance availability: To ensure the virtual appliances are available and healthy, Gateway Load Balancer runs health checks on a configurable cadence. When it detects an unhealthy virtual appliance, Gateway Load Balancer reroutes traffic away from that instance to a healthy one, so users experience graceful failover during both planned and unplanned down time. 
Scale virtual appliance instances automatically

Gateway Load Balancer works with AWS Auto Scaling groups and lets users to set target utilization levels for virtual appliance instances. This ensures optimal amount of resources available at all times. When traffic increases, additional instances are created and connected to the Gateway Load Balancer. When traffic returns to normal levels, those instances are terminated.

Bring higher-availability to your third-party virtual appliances

Gateway Load Balancer ensures high availability and reliability by routing traffic flows through healthy virtual appliances, and rerouting flows when a virtual appliance becomes unhealthy. To ensure that the virtual appliances are available and healthy, Gateway Load Balancer runs health checks on each virtual appliance instance on a configurable cadence. If the number of consecutive failed tests exceed a set threshold, the appliance will be declared unhealthy and traffic will no longer be routed to that instance.

Monitor continuous health and performance metrics

Users can monitor the Gateway Load Balancer using CloudWatch per Availability Zone metrics. These include the total number of ENIs/interfaces, IP addresses of ENIs/interfaces, number of packets in/out, number of bytes in/out, packet errors, and packet drops, load balancer metrics (such as the number of target appliance instances, target health status, healthy/unhealthy target count, current number of active flows, max flows, and processed bytes), and VPC Endpoint metrics (such as the number of Gateway Load Balancer Endpoint mappings).

Simplify deployment with AWS Marketplace

Deploying a new virtual appliance can be as simple as selecting it in AWS Marketplace. This further simplifies deployment while creating a great user experience. 

Ensure private connectivity over the AWS network using Gateway Load Balancer Endpoints

Used by Gateway Load Balancer to connect to sources and destinations of network traffic, Gateway Load Balancer Endpoints are a new type of VPC endpoint. Powered by PrivateLink technology, it connects Internet Gateways, VPCs, and other network resources over a private connection. Users traffic flows over the AWS network, and data is never exposed to the internet. 

 
 

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 are built within the EC2-Classic network. We recommend Application Load Balancer for Layer 7 traffic and Network Load Balancer for Layer 4 traffic when using Virtual Private Cloud (VPC).

  • Layer 4 or Layer 7 Load Balancing: Users can load balance HTTP/HTTPS applications and use Layer 7-specific features, such as X-Forwarded and sticky sessions. Users can also use strict Layer 4 load balancing for applications that rely purely on the TCP protocol.
  • SSL Offloading: Classic Load Balancer supports SSL termination, including offloading SSL decryption from application instances, centralized management of SSL certificates, and encryption to back-end instances with optional public key authentication. Flexible cipher support allows to control the ciphers and protocols the load balancer presents to clients.
  • IPv6 Support: Classic Load Balancer supports the use of both the Internet Protocol version 4 and 6 (IPv4 and IPv6) for EC2-Classic networks.

Classic Load Balancers are now integrated with AWS Certificate Management (ACM). Integration with ACM makes it very simple to bind a certificate to each load balancer thereby making the entire SSL offload process very easy. Typically purchasing, uploading, and renewing SSL/TLS certificates is a time-consuming manual and complex process. With ACM integrated with Classic Load Balancers, this whole process has been shortened to simply requesting a trusted SSL/TLS certificate and selecting the ACM certificate to provision it with each load balancer.

  • Users can enable cross-zone load balancing using the console, the AWS CLI, or an AWS SDK. See Cross-Zone Load Balancing documentation for more details.
  • The Classic Load Balancer supports Amazon EC2 instances with any operating system currently supported by the Amazon EC2 service.
  • The Classic Load Balancer supports load balancing of applications using HTTP, HTTPS (Secure HTTP), SSL (Secure TCP) and TCP protocols.
  • Users can perform load balancing for the following TCP ports:

    • [EC2-VPC] 1-65535
    • [EC2-Classic] 25, 80, 443, 465, 587, 1024-65535
  • Each Classic Load Balancer has an associated IPv4, IPv6, and dualstack (both IPv4 and IPv6) DNS name. IPv6 is not supported in VPC. Users can use an Application Load Balancer for native IPv6 support in VPC.
  •  Classic Load Balancers do not cap the number of connections that they can attempt to establish with the load balanced Amazon EC2 instances. Users can expect this number to scale with the number of concurrent HTTP, HTTPS, or SSL requests or the number of concurrent TCP connections that the Classic load balancers receive.
  • Users can terminate SSL on Classic Load Balancers. Users need to install an SSL certificate on each load balancer. The load balancers use this certificate to terminate the connection and then decrypt requests from clients before sending them to the back-end instances.
  • Users can either use AWS Certificate Manager to provision a SSL/TLS certificate or obtain the certificate from other sources by creating the certificate request, getting the certificate request signed by a CA, and then uploading the certificate using the AWS Identity and Access Management (IAM) service.

#04

Classic Load Balancer

 
 

 

Load Balancer Architecture

ELBs are managed services that provide powerful, feature-rich load balancing solutions with simple configuration.

Layer 4 vs. Layer 7 Load Balancers

Layer 4 transport layer and Layer 7 application layer refer to abstractions outlined in the Open Systems Interconnection model (OSI model). Fundamentally, a load balancer can be classified as Layer 4 or Layer 7 based on the type of information the load balancer processes in order to make a decision on traffic routing. For example, HTTP headers are only available at Layer 7 of the OSI model, and therefore, a Layer 7 load balancer must be used if HTTP headers (URL, method, cookies, and etc.) are to be considered in routing policies.

  • Information such as IP address source, IP address target, port, and protocol are available at Layer 4 of the OSI model, and can be used with a Layer 4 load balancer. On AWS, ALBs are Layer 7 load balancers, NLBs are Layer 4 load balancers, and custom load balancers can be either Layer 4 or Layer 7.
Custom Load Balancers

In addition to using the managed services offered by ELB, companies can optionally configure a custom load balancing solution. Custom load balancing solutions can use any load balancing software, and many popular third-party load balancing solutions such as F5 BIG-IP and NGINX Plus are available as Amazon Machine Images (AMI) on the AWS Marketplace.

  • Custom load balancing solutions can be run on Amazon EC2 instances, or can be containerized and run on ECS or another container orchestration solution, if desired.
  • Running an EC2-based or containerized load balancer is a good option for organizations looking to lift and shift existing, on-premises load balancers without deprecating these load balancers in favor of ELBs. This can be useful if existing load balancers have complex or opaque configurations, or an application has a requirement to work with a specific, third-party load balancing software.
Advanced Monitoring

Monitoring client requests is a common feature in load balancers, and can take many forms depending on the  application requirements. Load balancer monitoring allows application owners to analyze traffic patterns, troubleshoot issues, and improve application performance and security. Some common monitoring features that are found on load balancers include: 

  • Access logs: capture detailed information (e.g. source IP address, user agents, URLs) about each request made to a load balancer. Performance and application metrics: capture statistics (e.g. active connection counts, HTTP response code counts, throughput) about an application.
  • HTTP request tracing: use custom HTTP headers to track requests as they move between clients to targets.
  • Management and governance: capture detailed information (e.g. user IDs, timestamps) about changes made to load balancer configurations.
API Gateway vs. Load Balancer

An API Gateway refers to API management software that is deployed in front of a collection of backend services. Requests to an application are routed through the API Gateway, and the API Gateway provides common features such as authentication/authorization, request throttling, caching, and more. API Gateways can be implemented as a custom solution or a managed service. Using an API Gateway introduces the ability to add features to the application without requiring code to be present in the service to support these features.

  • For example, with an API Gateway, users can validate request schemas before passing the request to a backend service, thereby removing the need for the backend service to validate the incoming request schema.

API Gateways and load balancers can both be used to proxy requests to downstream targets; however, these solutions differ in terms of their supported features and intended use cases. API Gateway solutions typically offer different feature sets than load balancing solutions. For Amazon API Gateway, the ability to introduce request validation, rate limiting, API keys, SDK generation, or proxying requests directly to AWS services (e.g. Amazon Kinesis) are all features that are not supported by ELB. 

Downstream Targets

One of the most important considerations for designing a load balancer architecture is identifying the compute engine used by downstream targets, as well as determining how these targets will be registered with the load balancer. When a target is registered with a load balancer, the load balancer will start to route client requests to the target. In a cloud-native architecture, the number and location of application nodes changes (e.g. in response to scaling events) more often than in a traditional on-premises architecture.

  • While dynamic application nodes allow applications to be elastic and highly available, organizations migrating applications to AWS will have to consider how their new, dynamic application nodes will be registered and deregistered from load balancers.
  • ELB uses the concept of a target group to route requests to a group of resources. A target group is a pool of similar resources that serve similar client requests. A health check is a periodic request sent to each resource in the target group to test the resource’s capability to serve client requests.
Request Inspection

In order to route a request to its destination, a load balancer needs to inspect a request and compare the request to rules defined on the load balancer. In ELB, listener rules are defined for each port and protocol combination used with an ELB and consist of a priority, one or more actions, and one or more conditions.

  • In addition to basic request inspection and routing, some load balancer architectures have additional requirements for resource pool switching or payload scanning. Payload scanning refers to the practice of searching for patterns in an incoming request and acting on the result(s) of pattern matches. Resource pool switching refers to the practice of changing the destination of a request based on a dynamic value.

Monitoring

 

 

AWS users can use the following features to monitor your load balancers, analyze traffic patterns, and troubleshoot issues with the load balancers and targets.

  • CloudWatch metrics: Elastic Load Balancing publishes data points to Amazon CloudWatch for your Gateway 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. Think of a metric as a variable to monitor, and the data points as the values of that variable over time. Each data point has an associated time stamp and an optional unit of measurement. Users  can use Amazon CloudWatch to retrieve statistics about data points for thev load balancers and targets as an ordered set of time-series data, known as metrics. Users  can use these metrics to verify that the system is performing as expected. 
  • VPC Flow Logs: Users can use VPC Flow Logs to capture detailed information about the traffic going to and from the Network Load Balancer.  Create a flow log for each network interface for your load balancer. There is one network interface per load balancer subnet. To identify the network interfaces for a Network Load Balancer, look for the name of the load balancer in the description field of the network interface. There are two entries for each connection through your Network Load Balancer, one for the frontend connection between the client and the load balancer and the other for the backend connection between the load balancer and the target. 
  • Access logs: Users can use access logs to capture detailed information about TLS requests made to the load balancer. The log files are stored in Amazon S3. Users can use these access logs to analyze traffic patterns and to troubleshoot issues with the targets. Access logging is an optional feature of Elastic Load Balancing that is disabled by default. After users enable access logging for your load balancer, Elastic Load Balancing captures the logs as compressed files and stores them in the Amazon S3 bucket that was specified. Users can disable access logging at any time.
  • CloudTrail logs: Elastic Load Balancing is integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, role, or an AWS service in Elastic Load Balancing. CloudTrail captures all API calls for Elastic Load Balancing as events. The calls captured include calls from the AWS Management Console and code calls to the Elastic Load Balancing API operations. Users can use AWS CloudTrail to capture detailed information about the calls made to the Elastic Load Balancing API and store them as log files in Amazon S3. Users can use these CloudTrail logs to determine which calls were made, the source IP address where the call came from, who made the call, when the call was made, and so on. 
  • Request tracing: Users can use request tracing to track HTTP requests. The load balancer adds a header with a trace identifier to each request it receives. 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.

Elastic Load Balancing Security

Elastic load balancing

As a managed service, Elastic Load Balancing is protected by the AWS global network security procedures that are described in the Amazon Web Services: Overview of security processes whitepaper. Customers can use AWS published API calls to access Elastic Load Balancing through the network. Clients must support Transport Layer Security (TLS) 1.0 or later. AWS recommend TLS 1.2 or later. Clients must also support cipher suites with perfect forward secrecy (PFS) such as Ephemeral Diffie-Hellman (DHE) or Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). Most modern systems such as Java 7 and later support these modes. Additionally, requests must be signed using an access key ID and a secret access key that is associated with an IAM principal. Or users can use the AWS Security Token Service (AWS STS) to generate temporary security credentials to sign requests.

Network isolation

A virtual private cloud (VPC) is a virtual network in your own logically isolated area in the AWS Cloud. A subnet is a range of IP addresses in a VPC. When creating a load balancer, users can specify one or more subnets for the load balancer nodes. Users can deploy EC2 instances in the subnets of the VPC and register them with the load balancer. 

  • When creating a load balancer in a VPC, it can be either internet-facing or internal. An internal load balancer can only route requests that come from clients with access to the VPC for the load balancer.
  • Load balancer sends requests to its registered targets using private IP addresses. Therefore, users targets do not need public IP addresses in order to receive requests from a load balancer.
  • To call the Elastic Load Balancing API from the VPC without sending traffic over the public internet, use AWS PrivateLink.
Controlling network traffic

Elastic Load Balancing supports three types of load balancers: Application Load Balancers, Network Load Balancers, and Classic Load Balancers. Application Load Balancers operate at the request level (layer 7) of the Open Systems Interconnection (OSI) model. Network Load Balancers operate at the connection level (layer 4) of the OSI model. Classic Load Balancers operate at both the request and connection levels. Consider the following options for securing network traffic when you use a load balancer:

  • Use secure listeners to support encrypted communication between clients and your load balancers. Application Load Balancers support HTTPS listeners. Network Load Balancers support TLS listeners. Classic Load Balancers support both HTTPS and TLS listeners. Users can choose from predefined security policies for the load balancer to specify the cipher suites and protocol versions that are supported by the application. Users can use AWS Certificate Manager (ACM) or AWS Identity and Access Management (IAM) to manage the server certificates installed on the load balancer. Users can use the Server Name Indication (SNI) protocol to serve multiple secure websites using a single secure listener. SNI is automatically enabled for the load balancer when associating more than one server certificate with a secure listener.
  • Configure the security groups for the Application Load Balancers and Classic Load Balancers to accept traffic only from specific clients. These security groups must allow inbound traffic from clients on the listener ports and outbound traffic to the clients.
  • Configure the security groups for the Amazon EC2 instances to accept traffic only from the load balancer. These security groups must allow inbound traffic from the load balancer on the listener ports and the health check ports.
  • Configure the Application Load Balancer to securely authenticate users through an identity provider or using corporate identities. 
  • Use AWS WAF with the Application Load Balancers to allow or block requests based on the rules in a web access control list (web ACL).
  • Users can establish a private connection between the virtual private cloud (VPC) and the Elastic Load Balancing API by creating an interface VPC endpoint. Users can use this connection to call the Elastic Load Balancing API from the VPC without sending traffic over the internet. The endpoint provides reliable, scalable connectivity to the Elastic Load Balancing API, versions 2015-12-01 and 2012-06-01.
  • Elastic Load Balancing simplifies the process of building secure web applications by terminating HTTPS and TLS traffic from clients at the load balancer. The load balancer performs the work of encrypting and decrypting the traffic, instead of requiring each EC2 instance to handle the work for TLS termination. When configuring a secure listener, users specify the cipher suites and protocol versions that are supported by your application, and a server certificate to install on your load balancer. Users can use AWS Certificate Manager (ACM) or AWS Identity and Access Management (IAM) to manage the server certificates. Application Load Balancers support HTTPS listeners. Network Load Balancers support TLS listeners. Classic Load Balancers support both HTTPS and TLS listeners.
 

The term Elastic load balancing refers to the practice of distributing requests across multiple application nodes with the objective of maximizing resource usage and increasing overall application performance. A load balancer is a piece of software, usually running on a dedicated node, that receives incoming requests and distributes them to application nodes. For cloud-native architectures where application nodes change often, load balancers represent a critical infrastructure component that should be carefully architected in order to ensure the performance, security, and availability of the application. Load balancers are often presented as the entry point to an application, and they typically offer more functionality than simple request routing. 

  • Elastic Load Balancing (ELB) automatically distributes incoming application traffic across multiple targets, such as Amazon EC2 instances, containers, and IP addresses. 
  • Elastic Load Balancing (ELB) can handle the varying load of the application traffic in a single Availability Zone or across multiple Availability Zones. Elastic Load Balancing offers three types of load balancers that all feature the high availability, automatic scaling, and robust security necessary to make the applications fault tolerant.
  • 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. Simple, flexible configuration and support for multiple types of application targets. Simplified integration with other core AWS services, such as Amazon CloudWatch for monitoring and metrics and Security Groups for network reachability.