All Services
Networking & CDN
Elastic Load Balancing
Elastic Load Balancing distributes traffic across healthy targets and Availability Zones through Application, Network, Gateway, and Classic Load Balancers, with protocol-specific listeners, routing, health checks, TLS, logs, metrics, and integrations.
Explore pricing models, common use cases, infrastructure support, and the AWS services that commonly work with Elastic Load Balancing.
Elastic Load Balancing pricing and cost programs
Pricing model: Load balancer time and capacity usage
- On-Demand
- Available
- Reserved Instances or reserved capacity
- Not applicable
- Savings Plans
- Service-specific
- Spot
- Not applicable
Billing dimensions: Load balancer hours · Capacity units · Data processed · Public IPv4 addresses
Programs and modes: Application Load Balancer · Network Load Balancer · Gateway Load Balancer · Classic Load Balancer
Load balancer type determines the capacity-unit calculation; compute commitments are not assumed to cover load-balancer fees.
Free Tier: Available — verify current offers
Pricing reviewed 2026-07-25. Reviewed against the linked official AWS pricing page. Recheck regional rates and program terms before purchase.
Official AWS pricing
Official AWS sources reviewed 2026-07-21.
Why implement Elastic Load Balancing?
- Provides managed, elastic, highly available traffic distribution without maintaining proxy or appliance fleets.
- Offers HTTP-aware Application, high-performance TCP/UDP Network, virtual-appliance Gateway, and legacy Classic load-balancing models.
- Integrates with Auto Scaling, ECS, EKS, ACM, WAF, Shield, Route 53, Global Accelerator, PrivateLink, CloudWatch, access logs, and zonal recovery.
How to implement Elastic Load Balancing
- Select the load-balancer type from protocol, routing, source-IP, static-address, appliance, TLS, client-auth and performance needs; choose at least two zones where the type and workload support it.
- Create restricted listeners, modern TLS policies, certificates, target groups, health checks, deregistration delay, routing and stickiness only when required; align security groups and target ports and automate registration.
- Test healthy, unhealthy, slow, draining, overloaded and zonal-loss behavior, validate client IP and timeout semantics, enable access or flow logs and metrics, and monitor target errors, latency, capacity units and rejected connections.
Elastic Load Balancing best practices
- Distribute targets across zones and understand the selected load balancer's cross-zone default and pricing; do not assume the load balancer can mask an application or single-zone dependency failure.
- Use least-exposed listener and target security, current TLS policies and managed certificates, WAF for supported HTTP workloads, and authenticated or private backends when direct target access is a risk.
- Make health checks representative but lightweight, set graceful draining and timeouts from real request behavior, publish logs and alarms, and rehearse zonal shift or removal before an incident.
Elastic Load Balancing use cases and server impact
- Highly available web and API front doors
- TCP, UDP, and TLS load balancing
- Virtual-appliance insertion and service endpoints
Replaces self-managed load balancers and proxy scaling, while protocol design, certificates, target health, application capacity, zone resilience, security, and request-level troubleshooting remain yours.
Official implementation resources
How Elastic Load Balancing works with other AWS services
Arrows show the documented technical direction. Reciprocal navigation does not imply a reverse technical dependency.
Official AWS sources reviewed 2026-07-25.
Amazon Route 53 → Elastic Load Balancing
A Route 53 alias record maps an application hostname to an Elastic Load Balancing endpoint.
- Why teams use it
- The pairing gives applications a stable DNS name while the load balancer distributes traffic across changing healthy targets.
- Permissions and networking
- Choose the record and load balancer type for the protocol, and align public or private hosted zones with the load balancer scheme.
- Pricing and security caveats
- Route 53 and load balancer usage have separate charges. DNS routing is upstream configuration, not a reciprocal runtime call from the load balancer.
AWS Certificate Manager → Elastic Load Balancing
An HTTPS listener on an Application Load Balancer uses an ACM certificate to terminate TLS before forwarding requests to a target group.
- Why teams use it
- Central certificate management enables encrypted public endpoints without putting private keys on application instances or containers.
- Permissions and networking
- The certificate must exist in the same Region as the load balancer; listener security policies and backend encryption remain separate decisions.
- Pricing and security caveats
- The certificate and listener do not encrypt traffic from the load balancer to targets unless the target group also uses HTTPS.
AWS WAF → Elastic Load Balancing
A regional web ACL associated with an Application Load Balancer evaluates HTTP and HTTPS requests before they reach registered targets.
- Why teams use it
- The pairing adds centrally managed layer-7 filtering in front of EC2, ECS, or other ALB targets.
- Permissions and networking
- Use a regional web ACL in the load balancer Region, tune rules against real traffic, and retain security groups for network-layer controls.
- Pricing and security caveats
- WAF and load balancer charges are independent. WAF protects supported HTTP traffic but is not a network firewall or a substitute for secure application code.
Elastic Load Balancing → Amazon Elastic Container Service
An ECS service registers tasks in a load balancer target group, and the load balancer forwards traffic only to healthy registered targets.
- Why teams use it
- This lets tasks scale or be replaced without changing the public endpoint.
- Permissions and networking
- Align target type with the ECS network mode, open only required security-group paths, and give ECS permission to manage target registration.
- Pricing and security caveats
- Load balancer capacity and ECS task compute are billed separately. Health-check mistakes can remove every task from service.
Elastic Load Balancing → Amazon Elastic Kubernetes Service
The AWS Load Balancer Controller provisions and configures Elastic Load Balancing resources from Kubernetes Service or Ingress resources in EKS.
- Why teams use it
- Teams retain Kubernetes-native routing declarations while using managed AWS load balancers.
- Permissions and networking
- Install and authorize the controller, tag or discover subnets correctly, and choose instance or IP targets intentionally.
- Pricing and security caveats
- The controller, Kubernetes objects, and load balancer have separate lifecycles; deleting or misconfiguring one can interrupt routing and load balancer charges continue while provisioned.
Elastic Load Balancing → Amazon CloudWatch
Elastic Load Balancing publishes operational metrics such as request and target health signals to CloudWatch.
- Why teams use it
- Metrics and alarms help teams detect unhealthy targets, error growth, and capacity symptoms without polling the load balancer.
- Permissions and networking
- Alarm on user-impacting signals with enough evaluation time to avoid flapping, and enable access logs separately when request-level evidence is required.
- Pricing and security caveats
- Basic service metrics and custom alarms have different pricing; metrics do not contain full request or application traces.
Architecture patterns using this service