# AWS Service - Elastic Load Balancer **Elastic Load Balancer** * What is load balancing? * Load Balances are servers that forward traffic to multiple servers (e.g., EC2 instances) downstream ![AWS Elastic Load Balancers - ELB Fundamentals - AWS Certification Cheat Sheet – in28minutes Cloud](https://d33wubrfki0l68.cloudfront.net/872ee6df901ead26b5b4ff099babaf7ef43c0478/fe21d/images/aws/ec2/1-simple-elb.png align="left") * Why use a load balancer? * Spread load across multiple downstream instances * Expose a single point of access (DNS) to your application * Seamlessly handle failures of downstream instances * Do regular health checks to your instances * Provide SSL termination (HTTPS) for your websites * Enforce stickiness with cookies * High availability across zones * Separate public traffic from private traffic * Why use an Elastic Load Balancer? * An Elastic Load Balancer is a managed load balancer * AWS guarantees that it will be working * AWS takes care of upgrades, maintenance, high availability * AWS provides only a few configuration knobs * It costs less to setup your own load balancer but it will be a lot more effort on your end * It is integrated with many AWS offerings / services * EC2, EC2 ASG, Amazon ECS * ACM, CloudWatch, Route 53, WAF, AWS Global Accelerator * Health Checks * Health Checks are crucial for Load Balancers * They enable the load balancer to know if instances it forwards traffic to are available to reply to requests * The health check is done on a port and a route * If the response is not 200 (OK), then the instance is unhealthy * Types of load balancer on AWS * AWS has 4 kinds of managed Load Balancers * Classic Load Balancer (v1 - old generation) – 2009 – CLB * HTTP, HTTPS, TCP, SSL (secure TCP) * Application Load Balancer (v2 - new generation) – 2016 – ALB * HTTP, HTTPS, WebSocket * Network Load Balancer (v2 - new generation) – 2017 – NLB * TCP, TLS (secure TCP), UDP * Gateway Load Balancer – 2020 – GWLB * Operates at layer 3 (Network layer) – IP Protocol * It is recommended to use the newer generation load balancers as they provide more features * Some load balancers can be setup as internal (private) or external (public) ELBs * Load Balancer has security group using which you could control traffic at your downstream Instances to allow traffic only from ELB's SG ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1725721680888/9fa1c30c-67fb-4baf-ac3e-92b5ef001940.png align="center") * Classic Load Balancers (v1) * Supports TCP (Layer 4), HTTP & HTTPS (Layer 7) * Health checks are TCP or HTTP based * Fixed hostname `XXX.region.elb.amazonaws.com` * ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1725721897225/885b109c-09b9-4629-ba2b-407a7372141c.png align="center") * Application Load Balancer (v2) * Application load balancers is Layer 7 (HTTP) * Load balancing to multiple HTTP applications across machines (through target groups) * Load balancing to multiple applications on the same machine (containers) * Support for HTTP/2 and WebSocket * Support redirects (from HTTP to HTTPS for example) * Routing tables to different target groups: * Routing based on path in URL (`example.com/users` & `example.com/orders`) * Routing based on hostname in URL (`one.example.com` & `other.example.com`) * Routing based on Query String, Headers (`example.com/users?id=123&order=false`) * ALB are a great fit for micro services & container-based application (Docker; ECS; EKS) * Has a port mapping feature to redirect to a dynamic port in ECS * In comparison, we’d need multiple Classic Load Balancer per application * HTTP Based Traffic ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1725722284503/6b0249f4-6aff-4a98-b0b0-909576852846.png align="center") * Target Groups * EC2 instances (can be managed by an Auto Scaling Group) - HTTP * ECS tasks (managed by ECS itself) - HTTP * Lambda functions - HTTP request is translated into a JSON event * IP Addresses - must be private IPs * ALB can route to multiple target groups * Health checks are at the target group level * Query Strings/Parameters Routing * ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1725724163674/45016e8f-bc3a-4595-91d2-e5a686b86c1e.png align="center") Fixed hostname - `XXX.region.elb.amazonaws.com` * The application servers don’t see the IP of the client directly * The true IP of the client is inserted in the header `X-Forwarded-For` * We can also get Port (X-Forwarded-Port) and proto (X-Forwarded-Proto) * Network Load Balancer (v2) * Network load balancers (Layer 4) allow to: * Forward TCP & UDP traffic to your instances * Handle millions of request per seconds * Less latency - 100 ms (vs 400 ms for ALB) * NLB has one static IP per AZ, and supports assigning Elastic IP (helpful for whitelisting specific IP) * NLB are used for extreme performance, TCP or UDP traffic ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1725724563181/ca1c9632-0e21-4dd1-9be5-0a16b58498a5.png align="center") * Network Load Balancer –Target Groups * EC2 instances * IP Addresses – must be private IPs * Application Load Balancer * Health Checks support the TCP, HTTP and HTTPS Protocols ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1725724690212/e951662b-6a87-4fa0-beea-f3d8c257b905.png align="center") * Gateway Load Balancer * Deploy, scale, and manage a fleet of 3rd party network virtual appliances in AWS. * Example: Firewalls, Intrusion Detection and Prevention Systems, Deep Packet Inspection Systems, Payload Manipulation. * Operates at Layer 3 (Network Layer) - IP Packets * Combines the following functions: * Transparent Network Gateway - single entry/exit for all traffic * Load Balancer - distributes traffic to your virtual * Uses the GENEVE protocol on port 6081 ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1725724954116/5f08521d-5656-4c1d-afc3-b13430913052.png align="center") * Gateway Load Balancer - Target Groups * EC2 instances * IP Addresses – must be private IPs * ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1725725005792/16ad9ea7-add4-4f8a-9157-5ff1066f91d5.png align="center") * Sticky Sessions (Session Affinity) * It is possible to implement stickiness so that the same client is always redirected to the same instance behind a load balancer * This works for Classic Load Balancer, Application Load Balancer, and Network Load Balancer * For both CLB & ALB, the “cookie” used for stickiness has an expiration date you control * Use case: make sure the user doesn’t lose his session data * Enabling stickiness may bring imbalance to the load over the backend EC2 instances * ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1725725246768/85ec5f55-db11-466f-8435-367d7d9a9aa7.png align="center") * Sticky Sessions - Cookie Names * Application-based Cookies * Custom cookie * Generated by the target * Can include any custom attributes required by the application * Cookie name must be specified individually for each target group * Don’t use AWSALB, AWSALBAPP, or AWSALBTG (reserved for use by the ELB) * Application cookie * Generated by the load balancer * Cookie name is AWSALBAPP * Duration-based Cookies * Cookie generated by the load balancer * Cookie name is AWSALB for ALB, AWSELB for CLB * Cross-Zone Load Balancing * With Cross Zone Load Balancing - Each load balancer instance distributes evenly across all registered instances in all AZ * ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1725725467431/c0a5f308-309a-4301-9dd7-232f4ee94a9c.png align="center") * Without Cross Zone Load Balancing - Requests are distributed in the instances of the node of the Elastic Load Balancer * ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1725725521319/162cd520-832d-4b2d-8b7e-b5670df72739.png align="center") * Application Load Balancer * Enabled by default (can be disabled at the Target Group level) * No charges for inter AZ data * Network Load Balancer & Gateway Load Balancer * Disabled by default * You pay charges for inter AZ data if enabled * Classic Load Balancer * Disabled by default * No charges for inter AZ data if enabled * SSL/TLS - Intro * An SSL Certificate allows traffic between your clients and your load balancer to be encrypted in transit (in-flight encryption) * SSL - refers to Secure Sockets Layer, used to encrypt connections * TLS - refers to Transport Layer Security, which is a newer version * Nowadays, TLS certificates are mainly used, but people still refer as SSL * Public SSL certificates are issued by Certificate Authorities (CA) * Comodo, Symantec, GoDaddy, GlobalSign, Digicert, Letsencrypt, etc * SSL certificates have an expiration date (you set) and must be renewed * Load Balancer - SSL Certificates * The load balancer uses an X.509 certificate (SSL/TLS server certificate) * You can manage certificates using ACM (AWS Certificate Manager) * You can create upload your own certificates alternatively * HTTPS listener: * You must specify a default certificate * You can add an optional list of certs to support multiple domains * Clients can use SNI (Server Name Indication) to specify the hostname they reach * Ability to specify a security policy to support older versions of SSL / TLS (legacy clients) * SSL – Server Name Indication (SNI) * SNI solves the problem of loading multiple SSL certificates onto one web server (to serve multiple websites) * It’s a “newer” protocol, and requires the client to indicate the hostname of the target server in the initial SSL handshake * The server will then find the correct certificate, or return the default one * Note: * Only works for ALB & NLB (newer generation), CloudFront * Does not work for CLB (older gen) * ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1725725980059/d8be7e1c-2f18-4ba2-ad5b-5d65d2632c96.png align="center") * Elastic Load Balancers - SSL Certificates * Classic Load Balancer (v1) * Support only one SSL certificate * Must use multiple CLB for multiple hostname with multiple SSL certificate * Application Load Balancer (v2) * Supports multiple listeners with multiple SSL certificates * Uses Server Name Indication (SNI) to make it work * Network Load Balancer (v2) * Supports multiple listeners with multiple SSL certificates * Uses Server Name Indication (SNI) to make it work * Connection Draining * Feature naming * Connection Draining - for CLB * Deregistration Delay - for ALB & NLB * Time to complete “in-flight requests” while the instance is de-registering or unhealthy * Stops sending new requests to the EC2 instance which is de-registering * Between 1 to 3600 seconds (default: 300 seconds) * Can be disabled (set value to 0) * Set to a low value if your requests are short ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1725726219592/79ae31a4-faf9-4c44-96c3-51a63dd378bd.png align="center") **Relevant doc:** [https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/index.html](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/index.html) [https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/index.html](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/index.html) [https://docs.aws.amazon.com/elasticloadbalancing/latest/network/index.html](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/index.html) [https://docs.aws.amazon.com/elasticloadbalancing/latest/application/index.html](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/index.html) **Disclaimer:** This is a personal blog that might come in handy when I suffer from Dementia in future.