> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # EC2 Auto Scaling and Load Balancing > Explains AWS EC2 Auto Scaling and Elastic Load Balancing, load balancer types, multi AZ distribution, listeners, target groups, health checks, and design best practices. Welcome. This lesson explains AWS EC2 Auto Scaling and Elastic Load Balancing (ELB) — the key AWS services that distribute incoming traffic and keep compute fleets resilient, available, and scalable. You’ll learn what each load balancer type does, how multi-AZ and cross-zone distribution work, and how listeners and target groups route traffic. ## Analogy: reception desk in an office building Imagine a large office building with many departments and a central receptionist. The receptionist receives visitors and directs them to the correct department so no single office becomes overwhelmed. * The office building = your EC2 compute/backend infrastructure. * Visitors = external traffic / requests. * The receptionist = the Elastic Load Balancer (ELB), which directs traffic to the appropriate servers. ELB acts as a traffic director, distributing incoming requests so no one server is overloaded. It can front many AWS services (EC2, ECS, EKS, Lambda, API Gateway, etc.) and provides features such as SSL termination, health checks, and a single externally-visible entry point for your application. ## Types of AWS Load Balancers (quick comparison) | Load Balancer | OSI Layer | Use cases / strengths | Typical examples | | -: | :-: | - | - | | Application Load Balancer (ALB) | Layer 7 (HTTP/HTTPS) | Content-based routing (path/host), web applications, integration with containers, host/path rules, WAF | `HTTP`, `HTTPS` | | Network Load Balancer (NLB) | Layer 4 (TCP/UDP/TLS) | Ultra-low latency, high throughput, static IPs, preserve client source IP | TCP/UDP/TLS services | | Gateway Load Balancer (GWLB) | Layer 3/4 (transparent) | Transparent insertion of 3rd-party network/security appliances (firewalls, IDS/IPS) using GENEVE | Network appliance chaining | | Classic Load Balancer (CLB) | Legacy (Layer 4/7 mix) | Older workloads; not recommended for new architectures | N/A (legacy) | When you need the official docs: * ALB: [https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) * NLB: [https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) * GWLB: [https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html) * ELB overview: [https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) Because ALBs and NLBs are managed services, AWS provisions and scales the underlying infrastructure for you. They expose a single endpoint while actually running multiple devices across Availability Zones (AZs) for high availability and fault tolerance. Features (summary) ![A presentation slide titled "Features" showing a numbered list of benefits (Managed Service; High availability and fault tolerance; Efficient distribution of incoming network traffic; Flexibility for internal or external use; Simplified DNS management; SSL termination; Health checks) with teal numbered circles and gray rounded text bars. Copyright KodeKloud is shown at the bottom.](https://mintcdn.com/kodekloud-c4ac6d9a/iUH-E6aFfTq3W6nc/images/AWS-Certified-DevOps-Engineer-Professional/Domain-3-Resilient-Cloud-Solutions/EC2-Auto-Scaling-and-Load-Balancing/features-loadbalancer-managed-service-dns-ssl.jpg?fit=max\&auto=format\&n=iUH-E6aFfTq3W6nc\&q=85\&s=7433563b1493b5e4ebb79cbc16ba5415) Key features: * SSL/TLS termination: Terminate TLS at the load balancer using ACM certificates; optionally re-encrypt traffic to backend instances. * Health checks: Load balancers perform checks against registered targets so unhealthy instances stop receiving traffic. Health checks should validate real application paths and, where feasible, downstream dependencies. * Single entry point: Use a load balancer as the externally-visible DNS endpoint that distributes traffic internally and simplifies certificate and DNS management. Design health checks to reflect real availability: if your app depends on downstream services (databases, caches, third-party APIs), include checks that reflect those dependencies so the load balancer routes only to truly healthy instances. ## Multi-AZ distribution and ENIs Elastic Load Balancers are designed for high availability across Availability Zones. When cross-zone load balancing is enabled, the LB distributes traffic evenly across registered targets in all AZs it's attached to. Internally, an ALB/NLB creates an elastic network interface (ENI) in each AZ; these ENIs act as the entry points for traffic into that AZ. ![A diagram titled "ELB With Multi-AZ" showing clients hitting an Elastic Load Balancer that distributes traffic to EC2 instances across three availability zones (AZ1, AZ2, AZ3). The right side lists benefits: distribution of traffic, high availability, fault tolerance, and scalability.](https://mintcdn.com/kodekloud-c4ac6d9a/iUH-E6aFfTq3W6nc/images/AWS-Certified-DevOps-Engineer-Professional/Domain-3-Resilient-Cloud-Solutions/EC2-Auto-Scaling-and-Load-Balancing/elb-multi-az-ec2-high-availability.jpg?fit=max\&auto=format\&n=iUH-E6aFfTq3W6nc\&q=85\&s=4538dad36d4293f681eb068e33b3bd76) Note: Application Load Balancers perform cross-zone load balancing by default. Behavior can vary by load balancer type (for example, older NLB configurations historically required enabling cross-zone balancing); always verify settings for the specific LB you choose. ## Cross-Zone load balancing (visual) ![A diagram titled "Cross-Zone Load Balancing" showing a user connecting to an Application Load Balancer in a VPC that distributes traffic across two Availability Zones. Backend LB nodes and instances are shown with traffic split percentages (e.g., 50%, 25%).](https://mintcdn.com/kodekloud-c4ac6d9a/iUH-E6aFfTq3W6nc/images/AWS-Certified-DevOps-Engineer-Professional/Domain-3-Resilient-Cloud-Solutions/EC2-Auto-Scaling-and-Load-Balancing/cross-zone-alb-traffic-split.jpg?fit=max\&auto=format\&n=iUH-E6aFfTq3W6nc\&q=85\&s=b5c29497191f89dd698a458d168096f3) This image illustrates how traffic can be split across targets in multiple AZs. Cross-zone balancing helps ensure even load distribution even when target counts differ per AZ. ## Target Groups and Listeners (ALB specifics) Application Load Balancers use two important concepts to route traffic: * Listener: Defines the protocol and port the load balancer accepts (for example, `HTTP:80` or `HTTPS:443`). A listener contains rules that evaluate incoming requests and route them to target groups. * Target group: A logical set of targets (EC2 instances, IP addresses, Lambda functions) that receive traffic from the load balancer. Each target group has its own health check configuration and settings. Common routing patterns: * Path-based routing: route `/auth` to one target group and `/cart` to another. * Host-based routing: route `app1.example.com` to one target group and `app2.example.com` to another. * Registering by IP: Register IPs as targets to route to resources outside the EC2 instance set (VPCs/peered VPCs where supported). * Lambda targets: Forward HTTP(S) requests to Lambda functions for serverless backends. ![A diagram titled "Listeners and Target Groups" showing a load balancer listener routing requests for app1.com, app2.com/auth, and app2.com/cart to corresponding target groups. The target groups are illustrated with AWS service icons (EC2/ECS and Lambda), with a note that load balancers can forward to ECS and Lambda.](https://mintcdn.com/kodekloud-c4ac6d9a/iUH-E6aFfTq3W6nc/images/AWS-Certified-DevOps-Engineer-Professional/Domain-3-Resilient-Cloud-Solutions/EC2-Auto-Scaling-and-Load-Balancing/loadbalancer-listeners-target-groups-ecs-lambda.jpg?fit=max\&auto=format\&n=iUH-E6aFfTq3W6nc\&q=85\&s=bfe42a3f15c73d12e6a6b1c0871d1716) ## When to choose which load balancer * ALB: Use for HTTP/HTTPS workloads needing content-based routing, WAF integration, host/path rules, or containerized services (ECS/EKS). Good for web applications and many HTTP APIs. * NLB: Choose when you need extremely low-latency, high throughput, static IPs, or to preserve client source IP (for example, for IP-based allowlists). * GWLB: Use when you need to insert and scale third-party network or security appliances transparently (e.g., firewall or IDS chains). * CLB: Legacy option. Avoid for new architectures; use ALB or NLB depending on workload. Classic Load Balancer (CLB) is a legacy option. For new designs, prefer ALB or NLB depending on protocol and routing requirements. ## Additional operational notes * Auto Scaling: Load balancers are commonly used in front of Auto Scaling Groups so instances can scale horizontally while the LB maintains even traffic distribution. * Health check strategy: * Prefer application-level health checks (e.g., a readiness endpoint) that verify critical dependencies where possible. * Configure appropriate thresholds and timeouts to avoid flapping during short spikes or slow startups. * API vs. ALB: For API-specific features like request throttling, caching, and usage plans, consider API Gateway. ALB is still valid for many HTTP APIs and web apps but lacks some API Gateway features. * Security: Use security groups (for ALB) and NACLs at the subnet level. Configure WAF and TLS via ACM for production workloads. ## Quick checklist for building a resilient ALB + Auto Scaling architecture * Use multiple AZs and register targets across AZs. * Enable cross-zone balancing if your traffic pattern or LB type requires it. * Attach an Auto Scaling Group to the target group for automatic scale-out/in. * Terminate TLS at the ALB (ACM) and optionally re-encrypt to backends. * Implement application-level health checks and set conservative deregistration delay and thresholds. * Monitor using CloudWatch metrics and set alarms for `TargetResponseTime`, `UnhealthyHostCount`, and `RequestCount`. ## Summary This lesson covered the core concepts for designing resilient, scalable architectures with EC2 Auto Scaling and Elastic Load Balancing: * The role of ALB, NLB, GWLB, and the legacy CLB. * Key features like SSL termination, health checks, and single entry point. * How multi-AZ and cross-zone distribution improve availability. * How listeners and target groups route traffic for ALBs. Further reading and references: * AWS Elastic Load Balancing documentation: [https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) * Application Load Balancer docs: [https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) * Network Load Balancer docs: [https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) * Gateway Load Balancer docs: [https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html) > **[Watch Video](https://learn.kodekloud.com/user/courses/aws-certified-devops-engineer-professional/module/614fb8a5-8397-4ea6-9d7c-fe05ebc43d18/lesson/1795eda8-8cd7-4728-a2d6-408236eaad4c)** This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.