Summary:
- Application Load Balancer (ALB) operates at Layer 7 with advanced HTTP/2, gRPC, and WebSocket support, while Classic ELB provides basic Layer 4/7 functionality now considered legacy infrastructure.
- ALB delivers superior security through native AWS WAF integration, mutual TLS authentication, and HTTP desync protection that Classic ELB cannot match.
- Cost structures differ significantly. ALB uses Load Balancer Capacity Units (LCUs) for granular billing, while Classic ELB charges flat hourly rates regardless of traffic patterns.
- Migration from Classic ELB to ALB is essential for modern architectures, with AWS providing automated migration tools and a clear deprecation timeline.
When your production traffic spikes from 10,000 to 100,000 requests per second during a flash sale, the load balancer you chose six months ago suddenly becomes the most critical decision in your architecture. Understanding the distinction between Application Load Balancer and Elastic Load Balancer is no longer optional knowledge for engineers building on AWS. It directly impacts your system’s ability to handle modern traffic patterns, secure sensitive data, and scale cost-effectively. This guide dissects both technologies with the technical depth required for production decisions and interview confidence.
The following diagram illustrates the fundamental architectural differences between ALB and Classic ELB in a typical AWS deployment.
What is Elastic Load Balancer and Classic ELB
Elastic Load Balancing (ELB) represents AWS’s umbrella service for distributing incoming traffic across multiple targets. The terminology creates confusion because “ELB” historically referred to what AWS now calls Classic Load Balancer, launched in 2009 as the original load balancing solution. Today, Elastic Load Balancing encompasses four distinct products. These are Classic Load Balancer, Application Load Balancer, Network Load Balancer, and Gateway Load Balancer. When engineers reference “ELB vs ALB,” they typically mean Classic ELB versus the newer Application Load Balancer.
Classic ELB operates at both Layer 4 (TCP) and Layer 7 (HTTP/HTTPS), but with significant limitations compared to modern alternatives. It routes traffic based on simple round-robin algorithms and basic health checks without understanding application-level context. The architecture binds listeners directly to backend EC2 instances, lacking the abstraction layer that modern microservices demand.
Classic ELB technical constraints
The limitations of Classic ELB become apparent when examining its protocol support and routing capabilities. It lacks native HTTP/2 support, forcing clients to downgrade connections. There is no support for gRPC, which eliminates it as an option for modern service mesh architectures.
Key technical constraints include:
- Single target type: Only EC2 instances can serve as backends, excluding containers and Lambda functions
- No content-based routing: Cannot route based on URL path, hostname, or HTTP headers
- Limited health checks: Basic TCP or HTTP checks without customizable success codes or detailed response validation
Understanding these constraints establishes why AWS developed ALB and why migration has become a priority for engineering teams. The next section examines ALB’s architecture and the specific capabilities that address Classic ELB’s shortcomings.
What is Application Load Balancer
Application Load Balancer operates exclusively at Layer 7, providing intelligent routing decisions based on HTTP/HTTPS request content. Launched in August 2016, ALB introduced the concept of target groups, which decouple routing rules from backend infrastructure. This abstraction enables sophisticated traffic management patterns that Classic ELB cannot achieve.
ALB processes requests with full visibility into HTTP headers, methods, query strings, and source IP addresses. This visibility powers content-based routing where a single load balancer can direct traffic to different backend services based on URL patterns. A request to /api/users routes to your user service target group while /api/orders reaches the order service, all through one ALB endpoint.
Target groups and flexible backends
Target groups represent ALB’s most significant architectural advancement over Classic ELB. A target group is a logical collection of targets that receive traffic based on listener rules. Unlike Classic ELB’s direct instance binding, target groups support multiple target types that reflect modern deployment patterns.
Supported target types include:
- Instance targets: Traditional EC2 instances registered by instance ID
- IP targets: Any IP address within your VPC or peered networks, enabling hybrid cloud routing
- Lambda targets: Serverless functions invoked directly by ALB without API Gateway
- Container targets: ECS and EKS pods with dynamic port mapping for microservices
This flexibility means a single ALB can simultaneously route traffic to EC2 instances running legacy monoliths, containerized microservices in EKS, and Lambda functions handling specific API endpoints. The following section compares the technical specifications between ALB and Classic ELB across critical dimensions.
Key technical differences in routing and protocols
The fundamental difference between Application Load Balancer and Elastic Load Balancer centers on routing intelligence and protocol support. ALB’s Layer 7 focus enables request inspection that Classic ELB’s hybrid Layer 4/7 approach cannot match. This distinction affects every aspect of traffic management from initial connection handling to backend selection.
The comparison table below captures the essential technical specifications that differentiate these load balancers in production environments.
| Feature | Classic ELB | Application Load Balancer |
|---|---|---|
| OSI layer | Layer 4 and Layer 7 | Layer 7 only |
| HTTP/2 support | No | Yes (native) |
| gRPC support | No | Yes (2020+) |
| WebSocket support | Yes (with sticky sessions) | Yes (native) |
| Path-based routing | No | Yes |
| Host-based routing | No | Yes |
| Header-based routing | No | Yes |
| Query string routing | No | Yes |
| Lambda targets | No | Yes |
| Container support | Limited | Native with dynamic ports |
| Max rules per LB | N/A | 100 |
Layer 7 routing capabilities
ALB’s content-based routing transforms how engineers design multi-service architectures. Instead of deploying separate load balancers for each service, a single ALB can route traffic based on multiple conditions evaluated in sequence. This consolidation reduces infrastructure complexity and cost while improving operational visibility.
Routing conditions available in ALB include host headers for multi-tenant applications, URL paths for microservice routing, HTTP headers for A/B testing, HTTP methods for REST API versioning, query strings for feature flags, and source IP for geographic restrictions. Classic ELB offers none of these capabilities, forcing architects to implement routing logic in application code or deploy additional infrastructure layers.
The diagram below shows how ALB routing rules direct traffic to appropriate target groups based on request attributes.
After clarifying these routing differences, the security capabilities of each load balancer type deserve examination since they directly impact compliance requirements and threat mitigation strategies.
Security enhancements with mutual TLS and AWS WAF
Security represents one of the most significant gaps between Classic ELB and Application Load Balancer. ALB integrates natively with AWS WAF (Web Application Firewall), enabling request filtering based on IP reputation, SQL injection patterns, cross-site scripting attempts, and custom rules. Classic ELB has no WAF integration, requiring separate infrastructure to achieve similar protection.
Mutual TLS (mTLS) authentication, added to ALB in 2023, enables client certificate verification at the load balancer level. This capability is essential for zero-trust architectures and B2B API integrations where both parties must prove identity. Classic ELB supports only server-side TLS, leaving client authentication to backend applications.
HTTP desync protection
ALB includes HTTP desync mitigation modes that protect against request smuggling attacks. These attacks exploit differences in how frontend and backend systems parse HTTP requests, potentially allowing attackers to bypass security controls. ALB’s desync protection operates in three modes:
- Monitor mode: Logs suspicious requests without blocking, useful for initial deployment
- Defensive mode: Blocks clearly malicious requests while allowing ambiguous ones
- Strictest mode: Rejects any request that could be interpreted ambiguously
Classic ELB provides no equivalent protection, passing potentially malicious requests directly to backend instances. For applications handling sensitive data or operating in regulated industries, this security gap alone justifies migration to ALB.
Consider the following security feature comparison when evaluating load balancer options for compliance-sensitive workloads. The performance characteristics of each option also warrant detailed analysis.
Performance and scalability benchmarks for 2025
Performance differences between ALB and Classic ELB become pronounced under high-traffic conditions. ALB automatically scales to handle traffic spikes without pre-warming requirements for most workloads. AWS provisions ALB capacity dynamically based on traffic patterns. However, extremely large anticipated spikes (over 50,000 requests per second) benefit from contacting AWS support for pre-warming.
Classic ELB scaling is less predictable, with documented cases of slower response to sudden traffic increases. The architecture’s age means it lacks optimizations present in ALB for modern traffic patterns like HTTP/2 multiplexing and connection reuse.
| Performance metric | Classic ELB | Application Load Balancer |
|---|---|---|
| New connections per second | ~20,000 | ~100,000+ |
| Active connections | ~1,000,000 | ~1,000,000+ |
| Requests per second | ~50,000 | ~100,000+ per target group |
| HTTP/2 streams | Not supported | 128 concurrent streams |
| Connection idle timeout | 60 seconds (fixed) | 1-4000 seconds (configurable) |
| Cross-zone load balancing | Optional (charges apply) | Enabled by default (free) |
The performance advantages of ALB translate directly into cost efficiency for high-traffic applications. Understanding the pricing models helps quantify the total cost of ownership for each option.
Cost and pricing model comparison
Pricing structures differ fundamentally between Classic ELB and ALB. Classic ELB charges a flat hourly rate plus data processing fees, regardless of how efficiently you use the load balancer. ALB introduces Load Balancer Capacity Units (LCUs) that measure actual resource consumption across four dimensions. These are new connections, active connections, processed bytes, and rule evaluations.
As of 2025, AWS pricing in US East (N. Virginia) reflects these rates:
- Classic ELB: $0.025 per hour + $0.008 per GB processed
- ALB: $0.0225 per hour + $0.008 per LCU-hour
The LCU model means low-traffic applications pay less with ALB, while extremely high-traffic applications may see similar or slightly higher costs. However, ALB’s consolidation benefits often offset per-unit costs. Running five Classic ELBs for different services costs more than one ALB with five target groups handling equivalent traffic.
With cost implications understood, teams running Classic ELB should evaluate migration paths to ALB. AWS provides tooling to simplify this transition.
Migration guide from Classic ELB to ALB
AWS provides the Classic Load Balancer Migration Wizard that automates most migration steps. The wizard analyzes your existing Classic ELB configuration and generates an equivalent ALB setup with appropriate target groups and listener rules. However, certain configurations require manual intervention.
A successful migration follows this sequence:
- Audit current configuration: Document all listeners, health checks, security groups, and backend instances
- Run migration wizard: Generate ALB configuration and review proposed target groups
- Validate health checks: ALB health checks offer more options. Optimize thresholds for your application
- Test with weighted routing: Use Route 53 weighted records to send 10% of traffic to ALB initially
- Monitor and iterate: Compare latency, error rates, and backend health between both load balancers
- Complete cutover: Shift remaining traffic and decommission Classic ELB
The diagram below illustrates a phased migration approach using DNS-based traffic shifting.
After completing migration, teams should evaluate which use cases benefit most from ALB’s advanced capabilities.
Use case scenarios and recommendations
Choosing between load balancer types depends on your application architecture, traffic patterns, and operational requirements. While ALB suits most modern workloads, understanding specific scenarios helps justify the migration effort and infrastructure investment.
When ALB is the clear choice
ALB excels in microservices architectures where multiple services share a single entry point. Container orchestration platforms like Amazon ECS and Amazon EKS integrate natively with ALB through dynamic port mapping and service discovery. Serverless applications using Lambda benefit from ALB’s direct invocation capability, eliminating API Gateway costs for simple HTTP endpoints.
Applications requiring advanced routing benefit immediately from ALB. A/B testing implementations use header-based routing to direct specific user segments to experimental backends. Multi-tenant SaaS platforms use host-based routing to serve different customers from isolated target groups while sharing infrastructure costs.
Limited scenarios for Classic ELB
Classic ELB remains viable only for legacy applications with specific constraints. Applications requiring TCP pass-through without HTTP termination may use Classic ELB, though Network Load Balancer (NLB) is the preferred modern alternative. Some compliance frameworks with strict change control processes may delay migration until scheduled infrastructure updates.
However, AWS’s deprecation signals make Classic ELB a poor choice for new deployments. Engineering teams should treat any remaining Classic ELB usage as technical debt requiring remediation.
Conclusion
The comparison between Application Load Balancer and Elastic Load Balancer reveals a clear generational gap in AWS load balancing technology. ALB’s Layer 7 intelligence, flexible target groups, and native security integrations address requirements that Classic ELB cannot meet. The routing capabilities alone justify migration for any team running microservices, containers, or serverless workloads.
Cost analysis favors ALB for most traffic patterns, particularly when consolidation benefits reduce the total number of load balancers required. Security-conscious organizations gain immediate value from AWS WAF integration, mutual TLS support, and HTTP desync protection that Classic ELB lacks entirely.
Looking ahead, AWS continues investing in ALB with features like Automatic Target Weights while Classic ELB receives only maintenance updates. Teams still running Classic ELB should prioritize migration planning before deprecation timelines force rushed transitions. The investment in understanding ALB’s capabilities pays dividends in both production reliability and interview readiness for cloud architecture roles.
