Elastic Load Balancing sits at a deceptively simple point in AWS architecture: accept traffic and send it to healthy targets. The design choices around load-balancer type, Availability Zones, cross-zone behavior, health checks, TLS termination, target registration, session behavior, and failure handling determine whether that simple function improves resilience or hides a fragile application behind a managed endpoint.<\/p>\n
AWS recommends multi-Availability-Zone use for load balancers, and Application Load Balancers require at least two Availability Zones. The production question is not merely whether a load balancer exists. It is whether the routing behavior matches the application\u2019s availability, protocol, scaling, and isolation goals across AWS<\/a>.<\/p>\n Application Load Balancer operates at the HTTP\/HTTPS application layer and supports host, path, header, and other request-aware routing. Network Load Balancer is designed for high-performance Layer 4 traffic and static IP-oriented patterns. Gateway Load Balancer integrates virtual network appliances into traffic paths. These products solve different problems even though each distributes traffic.<\/p>\n Start with the protocol and routing requirement. Do not choose NLB because \u201cit is faster\u201d when the application needs application-aware routing, or ALB when preserving network-level characteristics is the real requirement. Service choice should reduce custom infrastructure rather than forcing the application into an awkward protocol model.<\/p>\n A load balancer can have nodes in multiple Availability Zones and route to registered healthy targets. Resilience requires usable target capacity in those zones. Enabling an Availability Zone with no meaningful target capacity creates the appearance of redundancy without the ability to serve normal traffic after another zone fails.<\/p>\n Capacity planning should account for what happens when one zone is removed. Auto Scaling groups, container schedulers, and target-registration logic should distribute capacity intentionally. The AWS high availability versus fault tolerance<\/a> distinction is useful here: surviving a zone impairment requires both a routing mechanism and sufficient healthy capacity elsewhere.<\/p>\n Capacity models should include zonal imbalance during maintenance as well as failure. Deployments, scaling events, and instance replacement can temporarily reduce one zone before an outage occurs. Reserve enough headroom that the architecture does not depend on every zone being perfectly balanced at the moment another zone becomes unavailable.<\/p>\n With cross-zone load balancing enabled, a load-balancer node can distribute traffic to targets in other enabled Availability Zones. Without it, a node sends traffic only to targets in its own zone. AWS behavior differs by load-balancer type and can also be configured at the target-group level for some products.<\/p>\n Cross-zone routing can smooth uneven target counts and simplify capacity utilization. Zonal isolation can reduce cross-zone dependencies and data-transfer patterns. The trade-off should be explicit. If the architecture depends on cross-zone behavior to compensate for lopsided capacity, operators need to know what happens when a zone or zonal target group is intentionally shifted away.<\/p>\n A target that answers TCP or returns a simple HTTP 200 may still be unable to serve a useful request because a database, cache, dependency, or configuration is broken. Health checks should be lightweight but meaningful enough to remove targets that cannot satisfy the application\u2019s contract.<\/p>\n Avoid checks that are so deep they overload dependencies or cause cascading failure. Consider separate liveness and readiness concepts in the application platform even when the load balancer consumes one health signal. During an incident, operators should be able to explain why a target is healthy from the load balancer\u2019s perspective and whether that health state matches user experience.<\/p>\n Health thresholds affect recovery speed and stability. Aggressive unhealthy thresholds can remove targets quickly but may amplify transient failures; slow thresholds can keep broken targets in rotation too long. Recovery thresholds determine how quickly a repaired target returns. Tune these values with the application startup and failure characteristics rather than accepting defaults without measurement.<\/p>\n For dependencies shared by all targets, a deep health check can create a dangerous correlated response. If the database is briefly unavailable and every application target reports unhealthy, the load balancer may remove all targets even though keeping some endpoints available for degraded behavior would be preferable. Health semantics should reflect what the application can safely serve during dependency impairment.<\/p>\n Terminating TLS at a load balancer can centralize certificates and reduce cryptographic work on application targets. Whether traffic should also be encrypted from the load balancer to targets depends on the threat model, compliance requirements, and network boundary. Internal traffic is not automatically trustworthy merely because it stays inside a VPC.<\/p>\n Keep certificate renewal and policy changes automated where possible. Restrict security groups so targets accept traffic only from the expected load-balancer path. Logging and monitoring should identify handshake failures, certificate problems, and unusual client behavior without exposing secrets in application logs.<\/p>\n Client identity requirements can also affect the front-door pattern. Where mutual TLS or service-specific authentication is used, confirm which load-balancer features support the required handshake and what identity information is forwarded to targets. Security architecture should not assume that terminating TLS is equivalent to preserving every end-to-end client-authentication property.<\/p>\n Session stickiness can make stateful applications easier to operate, but it couples a client to target availability and can create uneven load. Long-lived connections can also change how quickly traffic shifts away from a target or zone. Applications that externalize session state are usually easier to scale and recover than applications that depend heavily on one target.<\/p>\n If stickiness is required, understand why and test failure behavior. A load balancer cannot preserve application state that exists only on a failed instance. Architecture should make state durable or reproducible rather than expecting routing affinity to provide resilience.<\/p>\n Elastic Load Balancing is often the traffic layer in rolling, blue\/green, and canary deployments. Target groups provide a useful boundary for registering a new version, warming it, evaluating health, and shifting traffic. Deployment automation should wait for actual target health rather than merely for instances or containers to start.<\/p>\nChoose the load-balancer family from protocol and control needs<\/h2>\n
Design target capacity across Availability Zones<\/h2>\n
Understand cross-zone load balancing before relying on it<\/h2>\n
Make health checks represent real service readiness<\/h2>\n
Use TLS termination to simplify, not weaken, the trust boundary<\/h2>\n
Treat stickiness and connection lifetime as state-management choices<\/h2>\n
Coordinate load balancing with Auto Scaling and deployment strategy<\/h2>\n