AWS Elastic Load Balancing (ELB) receives incoming traffic and distributes it among eligible application or network targets. It is a managed traffic-distribution service, not a guarantee that an application can never fail. A load balancer uses listeners, routing rules where supported, target groups, and health checks to decide where requests or connections should go. The application’s availability still depends on healthy targets, sufficient capacity, correct network permissions, and functioning data or service dependencies.<\/p>\n
The service has four load-balancer types: Application Load Balancer (ALB), Network Load Balancer (NLB), Gateway Load Balancer (GWLB), and the older Classic Load Balancer (CLB). They are not interchangeable. An ALB understands application-layer web requests; an NLB handles transport-layer connections; a GWLB helps insert virtual network appliances into traffic flows; and CLB is a previous-generation option for existing environments. AWS recommends considering current-generation types when migrating legacy Classic deployments rather than choosing CLB as the default for a new application.<\/p>\n
Consider a customer opening a website. The client resolves a DNS name and connects to an internet-facing endpoint. The load balancer accepts the connection through a configured listener, evaluates any supported routing conditions, and selects a registered target from the relevant target group. That target might be an EC2 instance, an IP-addressed service, a supported container workload, or another target type allowed by the chosen load balancer. The application processes the request and returns a response through the appropriate path.<\/p>\n
On an Application Load Balancer, a listener may handle HTTP or HTTPS and apply rules based on host names, request paths, or supported HTTP attributes. One target group might serve an API while another handles an administrative interface. Target-group configuration identifies protocol, port, target type, and health checks. A listener rule must forward requests to the intended group; a healthy target in the wrong group will not fix a routing rule that sends requests elsewhere.<\/p>\n
The load balancer is deployed within a VPC networking context. Its scheme, enabled Availability Zones, subnet choices, routes, security groups where applicable, and target reachability determine whether traffic can traverse the intended path. The Amazon VPC routing and security boundaries<\/a> need to be considered alongside the load-balancer configuration. An endpoint resolving in DNS does not prove that the client can reach the listener or that the target can receive the forwarded connection.<\/p>\n An Application Load Balancer<\/strong> is commonly appropriate for web applications and HTTP APIs that need application-layer routing. It can route supported requests based on paths or host names, integrate with supported authentication patterns, and forward to target groups. Its ability to interpret a web request is the reason it fits an API or microservices entry point. A client using a non-HTTP protocol may need a different load-balancer model.<\/p>\n A Network Load Balancer<\/strong> handles transport protocols such as TCP, UDP, and TLS with characteristics suited to high-throughput or low-latency connection processing. It may be selected when the application requires transport-layer behavior or supported static address capabilities. Unlike an ALB, it does not inspect URL paths to choose targets. A team that needs fixed network endpoints for a non-HTTP service should compare NLB features and limitations with the exact application protocol before deploying it.<\/p>\n A Gateway Load Balancer<\/strong> serves a different architectural purpose: distributing traffic across compatible virtual appliances for security inspection or related network processing. It can form part of a route-based design that inserts firewalls or other appliances into a traffic path. This is not the normal choice for sharing web requests among application servers. The network routing, availability, and appliance health requirements deserve their own design and failure testing.<\/p>\n Classic Load Balancer<\/strong> remains relevant when operating an existing legacy deployment. AWS describes it as previous generation and provides tools to migrate to an ALB or NLB where appropriate. The migration creates a new load balancer; it does not convert the existing one in place. Compare required listener protocols, target behavior, policies, monitoring, and DNS cutover before committing to a migration. Do not assume every Classic setting is transferred automatically or that a new type provides exact feature parity.<\/p>\n Load balancers use configured health checks to determine whether registered targets should receive traffic. An HTTP health check may request a selected path and evaluate the returned response; other types can test transport connectivity or use supported protocol behavior. The health configuration includes intervals, timeouts, thresholds, and a matching rule where appropriate. A successful check establishes only that its defined condition was met, not that the entire application, database, or customer workflow is healthy.<\/p>\n For example, a target that responds to When a target fails its check, the load balancer can stop routing ordinary requests to it under normal supported conditions, but the result also depends on the load-balancer type, group state, and availability of other targets. Do not promise zero errors during every failure or imply that a load balancer replaces application-level retries and recovery. Investigate the reason code and target state when all endpoints become unhealthy, rather than repeatedly modifying health thresholds to force a green status.<\/p>\n Configuring a load balancer across appropriate Availability Zones can help an application tolerate some zonal failures, but the application needs healthy capacity in those zones and supporting dependencies that can also survive. Cross-zone load-balancing behavior and configuration vary by type and target-group settings. Review the actual enabled zones and whether their targets are registered and healthy. A traffic distributor cannot create a healthy database or replace an unavailable identity service on its own.<\/p>\n Elastic Load Balancing and EC2 Auto Scaling solve related but distinct problems. The load balancer distributes traffic among available targets, while an Auto Scaling group can adjust or replace compute capacity according to its configuration and scaling policies. The EC2 Auto Scaling capacity lifecycle<\/a> helps explain how new instances become registered, pass health checks, and start serving traffic. A new instance that boots but fails initialization should not be considered useful capacity merely because the Auto Scaling API succeeded.<\/p>\n Capacity planning still matters. A load balancer can scale to accommodate many workloads, but the end-to-end request path may bottleneck at a database, external API, application worker pool, or shared storage resource. When traffic rises, inspect target response time, request failures, backend utilization, and downstream latency before changing instance size or count. Adding targets without locating the bottleneck can increase cost while leaving the customer experience unchanged.<\/p>\n For an HTTPS application, a listener can terminate TLS using a supported certificate, often managed through AWS Certificate Manager. The AWS Certificate Manager and TLS deployment process<\/a> involves domain validation, certificate association, supported security policies, and renewal behavior. Terminating client TLS at the load balancer does not automatically mean the traffic between the load balancer and target is encrypted; backend protocol and target configuration must be reviewed separately.<\/p>\n Restrict access on both sides of the path. The load-balancer listener should accept only intended traffic, and targets should generally be reachable through appropriate controls rather than being unnecessarily exposed to the public internet. Security-group behavior differs by load-balancer type, while network ACLs and route tables can affect reachability independently. A service may return an apparent application timeout when the actual cause is a blocked connection or an incorrect subnet route.<\/p>\n Security also extends to identity and operations. Limit who can change listeners, rules, certificates, target groups, and logging settings. Use appropriate service identities for automation, review deployment changes, and monitor unexpected modifications. A load balancer can help with selected application traffic and integration controls, but it is not a substitute for application authentication, authorization, secure code, data protection, or web-layer defenses where those are required.<\/p>\n AWS publishes metrics for the different load-balancer families, including request or connection volume, target health, latency, and errors where supported. The CloudWatch monitoring and alarm model<\/a> is useful when an operator can explain the distinction between load-balancer-generated errors and failures returned by targets. A spike in unsuccessful responses could originate at the listener, target, application, or dependency. Metrics should direct investigation rather than become a dashboard whose green color is accepted without question.<\/p>\n When a user reports an HTTP 503 or a connection failure, begin with the request path. Confirm DNS resolution and endpoint reachability, then the listener and rules, target group membership and health, subnet\/security controls, target process, and downstream dependencies. An Application Load Balancer access log may help reconstruct a request, while VPC Flow Logs can assist with transport reachability and CloudTrail can show certain configuration changes. Each evidence source answers a different question.<\/p>\nChoose Application, Network, or Gateway Load Balancing<\/h2>\n
Health checks are readiness signals, not full application tests<\/h2>\n
\/health<\/code> with a static success message may still be unable to authenticate users or query its database. On the other hand, a health check that requires an unavailable optional downstream service may mark otherwise usable instances as unhealthy. Decide whether the check reflects the service’s true ability to handle requests and whether a dependency failure should remove the target from rotation. Test it with both a healthy and a deliberately degraded target in an authorized environment.<\/p>\nUnderstand Availability Zones, capacity, and Auto Scaling<\/h2>\n
Secure the listener and backend path<\/h2>\n
Monitor the right metric and locate the failed layer<\/h2>\n