Magento 2 Load Balancer: AWS ELB Setup and Architecture Guide
[Updated: March 19, 2026]
Your Magento store handles 500 concurrent users fine. Then a flash sale hits 5,000 and everything crashes. A single server cannot absorb that kind of spike.
This guide covers how AWS Elastic Load Balancing distributes traffic across multiple Magento 2 servers, which ELB type fits your store, and the reference architecture that keeps high traffic stores online.
Key Takeaways
- AWS offers three current load balancer types for Magento: Application Load Balancer (Layer 7), Network Load Balancer (Layer 4), and Gateway Load Balancer. Classic Load Balancer is deprecated.
- The recommended Magento architecture uses two ALBs: one distributing traffic to Varnish cache servers, one routing requests to Magento application instances.
- ALB costs $0.0225 per hour plus $0.008 per Load Balancer Capacity Unit, with a free tier of 750 hours per month for new AWS accounts.
- Multi-AZ deployment with Auto Scaling eliminates single points of failure and handles traffic spikes without manual intervention.
- Redis 7.2 handles session persistence across load-balanced Magento nodes, so users stay logged in regardless of which server processes their request.
What Is a Magento Load Balancer?
A Magento load balancer = a traffic distribution layer that routes incoming requests across multiple Magento servers. It prevents any single server from becoming overwhelmed while keeping your store responsive during traffic spikes.
Perfect for: High traffic Magento stores, stores running flash sales, multi-server production environments, any store where downtime costs revenue.
Not ideal for: Single-server development environments, stores with under 100 concurrent users, staging setups.
A load balancer sits between your visitors and your Magento servers. When a customer requests a product page, the load balancer decides which server handles that request based on current server health and capacity.
Without load balancing, a single server handles every request. If traffic exceeds that server's capacity, customers see timeouts or errors. With load balancing, traffic spreads across multiple servers. If one server fails, the load balancer routes traffic to healthy servers without visitors noticing.
For Magento stores on AWS, Elastic Load Balancing (ELB) provides this capability as a managed service. You do not provision or maintain load balancer hardware. AWS scales the load balancer capacity based on incoming traffic.
AWS ELB Types for Magento Stores
AWS offers three current-generation load balancers and one deprecated option. Each operates at a different network layer and serves different use cases.
Application Load Balancer (ALB)
ALB operates at Layer 7 (application layer) and is the recommended choice for most Magento deployments. It understands HTTP and HTTPS traffic, enabling content-based routing decisions.
Core capabilities:
- Routes requests based on URL path, hostname, HTTP headers, or query strings
- Supports HTTP, HTTPS, gRPC, and WebSocket protocols
- Enables sticky sessions through load balancer-generated cookies
- Handles SSL/TLS termination with certificates from AWS Certificate Manager
- Cross-zone load balancing enabled by default
- Integrates with AWS WAF for web application firewall protection
Magento use case: Route /media/ requests to a dedicated media server while sending /checkout/ requests to servers optimized for transaction processing.
Pricing: $0.0225 per hour + $0.008 per LCU (Load Balancer Capacity Unit) in US East. One LCU covers 25 new connections per second, 3,000 active connections per minute, or 1 GB of processed bytes per hour. Rates vary by region.
Network Load Balancer (NLB)
NLB operates at Layer 4 (transport layer) and handles millions of requests per second with ultra-low latency. It processes TCP, UDP, and TLS traffic without inspecting content.
Core capabilities:
- Handles millions of requests per second at sub-millisecond latency
- Supports static and Elastic IP addresses per Availability Zone
- Preserves client source IP addresses
- Cross-zone load balancing disabled by default (enable it for Magento)
- Supports connections over VPC peering and VPN
Magento use case: Stores that need extreme throughput or static IP addresses for firewall whitelisting. Also useful as the entry point when you need a fixed IP that routes to an ALB behind it.
Gateway Load Balancer (GLB)
GLB manages third-party virtual appliances like firewalls, intrusion detection systems, and deep packet inspection tools. It operates at Layer 3 (network layer) with Layer 4 routing.
Magento use case: Enterprise stores that route all traffic through security appliances before it reaches the Magento application servers. Most Magento deployments do not need GLB.
Classic Load Balancer (Deprecated)
AWS deprecated the Classic Load Balancer. It supported both Layer 4 and Layer 7 but with limited features compared to ALB and NLB. AWS recommends migrating existing CLB deployments to ALB or NLB for better performance and lower costs.
ALB vs NLB: Which One for Magento?
| Feature | ALB (Layer 7) | NLB (Layer 4) |
|---|---|---|
| Best for | Most Magento stores | Ultra-high throughput stores |
| Routing | URL path, headers, hostname | Port and protocol |
| Protocols | HTTP, HTTPS, gRPC, WebSocket | TCP, UDP, TLS |
| Latency | Low (milliseconds) | Ultra-low (sub-millisecond) |
| SSL termination | Yes (with ACM) | Yes (TLS passthrough or termination) |
| Sticky sessions | Cookie-based | Source IP-based |
| Static IP | No (use Global Accelerator) | Yes (Elastic IP per AZ) |
| WAF integration | Yes (AWS WAF) | No |
| Cross-zone default | Enabled | Disabled |
| Hourly cost | $0.0225 | $0.0225 |
Recommendation: Use ALB for Magento. Content-based routing, WAF integration, and cookie-based sticky sessions align with how Magento handles HTTP requests. Choose NLB only when you need static IPs or process non-HTTP traffic.
Magento AWS Reference Architecture
The official AWS whitepaper for Magento on AWS still references older components (PHP 7.4, MySQL 5.6, Elasticsearch). The architecture below reflects current best practices for Magento 2.4.8, using a two-tier load balancing setup with Auto Scaling groups across multiple Availability Zones.
Traffic Flow
Customer Request
↓
Amazon CloudFront (CDN)
↓
ALB #1 → Varnish Cache Tier (Auto Scaling Group, Multi-AZ)
↓
ALB #2 → Magento App Tier (Auto Scaling Group, Multi-AZ)
↓
├── Amazon OpenSearch 2.19 (catalog search)
├── Amazon ElastiCache Valkey 8 / Redis 7.1 (cache + sessions)
├── Amazon RDS MySQL 8.4 (database, Multi-AZ replica)
└── Amazon S3 (media storage)
How Each Layer Works
CloudFront (CDN): Caches static assets (images, CSS, JavaScript) at edge locations worldwide. Reduces load on your origin servers and cuts page load times for international customers.
ALB #1 + Varnish tier: The first Application Load Balancer distributes requests to Varnish cache instances. Varnish serves cached full-page responses without touching Magento, handling 80-95% of requests for returning pages. The Varnish tier runs in an Auto Scaling group that adds instances during traffic spikes.
ALB #2 + Magento app tier: Cache misses pass through the second ALB to Magento application servers. These EC2 instances run Magento with PHP 8.3 or 8.4, nginx 1.26, and connect to shared backend services. This tier also Auto Scales based on CPU utilization or request count.
Backend services: All Magento instances connect to the same Amazon RDS database (MySQL 8.4 or Aurora with Multi-AZ failover), ElastiCache for cache and session storage, and OpenSearch 2.19 for catalog search.
Session Management Across Load-Balanced Nodes
When a customer logs in on Server A, their session data must be available if the next request routes to Server B. Magento offers two approaches for load-balanced environments.
Redis Session Storage (Recommended)
Configure Redis as the session handler in env.php. All Magento nodes read and write sessions to the same Redis cluster. This approach works with any load balancing algorithm because session data lives outside the web servers.
Amazon ElastiCache provides a managed caching service with automatic failover. Magento 2.4.8 supports Redis 7.2 (on-premises) while ElastiCache offers Redis OSS 7.1 (enhanced) or Valkey 8 as a Redis-compatible alternative. AWS recommends Valkey for new deployments.
Sticky Sessions (Fallback)
ALB supports cookie-based sticky sessions that route a user to the same backend server for the duration of their session. This works but creates uneven load distribution. If one server accumulates more long-running sessions, it becomes a bottleneck while other servers sit idle.
Use Redis session storage over sticky sessions. It distributes load more evenly and survives server failures without losing customer sessions.
Health Checks and Auto Scaling
Health Check Configuration
ELB runs periodic health checks against each registered target. If a target fails consecutive health checks, the load balancer stops sending traffic to it until it recovers.
Recommended health check settings for Magento:
| Setting | Value | Why |
|---|---|---|
| Protocol | HTTPS | Matches production traffic |
| Path | /health_check.php |
Lightweight endpoint, no full Magento bootstrap |
| Interval | 30 seconds | Balances detection speed with server load |
| Healthy threshold | 2 checks | Confirms recovery before sending traffic |
| Unhealthy threshold | 3 checks | Avoids false positives from brief hiccups |
| Timeout | 10 seconds | Magento can be slow during deployments |
Create a simple health_check.php in your Magento root that returns HTTP 200 if the application can connect to the database and Redis. This catches infrastructure failures without the overhead of a full page render.
Auto Scaling Integration
AWS Auto Scaling works with ELB to add or remove Magento instances based on demand. Define scaling policies that respond to metrics like CPU utilization, request count per target, or custom CloudWatch metrics.
A practical Auto Scaling configuration for Magento:
- Minimum instances: 2 (one per AZ for redundancy)
- Desired instances: 2-4 (normal traffic)
- Maximum instances: 8-12 (peak events, flash sales)
- Scale-out trigger: Average CPU above 60% for 3 minutes
- Scale-in trigger: Average CPU below 30% for 10 minutes
- Cooldown: 300 seconds between scaling actions
SSL/TLS Termination
SSL termination at the load balancer level offloads encryption and decryption from your Magento servers. The ALB handles the TLS handshake with the client and forwards unencrypted traffic to backend servers over the private VPC network.
Benefits for Magento:
- Reduces CPU load on web servers (TLS handshakes are expensive)
- Centralizes certificate management through AWS Certificate Manager (free public certificates)
- Simplifies certificate rotation (one location instead of every server)
Configuration note: Set $_SERVER['HTTPS'] = 'on' in your Magento configuration or use the X-Forwarded-Proto header to ensure Magento generates HTTPS URLs even though backend traffic is HTTP.
Multi-AZ Deployment for High Availability
A high availability Magento setup requires resources in at least two Availability Zones. If one AZ experiences an outage, the load balancer routes all traffic to healthy instances in the remaining AZ.
Multi-AZ components:
- ALB endpoints in 2+ AZs (automatic with ALB)
- Varnish instances in 2+ AZs (via Auto Scaling group)
- Magento app instances in 2+ AZs (via Auto Scaling group)
- RDS Multi-AZ deployment (automatic failover, 1-2 minute recovery)
- ElastiCache with Multi-AZ and automatic failover
Cross-zone load balancing (enabled by default on ALB) distributes traffic evenly across all registered instances regardless of their Availability Zone. This prevents uneven load when one AZ has more instances than another.
ELB Pricing and Cost Optimization
Cost Structure
| Component | ALB | NLB |
|---|---|---|
| Hourly rate | $0.0225/hr (~$16.20/mo) | $0.0225/hr (~$16.20/mo) |
| Capacity unit | $0.008/LCU-hr | $0.006/NLCU-hr |
| Free tier | 750 hrs/mo + 15 LCUs (12 months) | 750 hrs/mo + 15 NLCUs (12 months) |
Prices shown for US East (N. Virginia). Rates vary by region. Check the AWS ELB pricing page for current rates.
Typical monthly cost for a Magento store with moderate traffic (100-500 concurrent users): $25-$60 per ALB. The two-ALB reference architecture costs $50-$120 per month for load balancing alone.
Cost Optimization Tips
- Use CloudFront to reduce requests hitting your ALBs (cached assets never reach the load balancer)
- Right-size health check intervals to avoid unnecessary health check traffic
- Enable connection idle timeout matching your application needs (default 60 seconds is fine for Magento)
- Remove unused load balancers from staging or development environments when not in use
Magento 2.4.8 Stack Requirements
When deploying a load-balanced Magento environment on AWS, ensure all instances run the same software versions.
| Component | Version (2.4.8) | AWS Service |
|---|---|---|
| PHP | 8.3 or 8.4 | EC2 (self-managed) |
| nginx | 1.26 | EC2 (self-managed) |
| MySQL | 8.4 | Amazon RDS |
| MariaDB | 11.4 | Amazon RDS |
| Redis | 7.2 (on-prem) / 7.1 (ElastiCache) | Amazon ElastiCache |
| Valkey | 8 | Amazon ElastiCache (recommended) |
| OpenSearch | 2.19 | Amazon OpenSearch Service |
| Elasticsearch | 8.17 (on-prem only, phased out on cloud) | Self-managed |
| Varnish | 7.6 | EC2 (self-managed) |
| RabbitMQ | 4.1 | Amazon MQ |
| Composer | 2.9.3+ | EC2 (build server) |
Pros and Cons of AWS ELB for Magento
| Pros | Cons |
|---|---|
| Managed service with zero hardware maintenance | Adds $50-$120/month for two-ALB architecture |
| Auto Scales with traffic, no capacity planning | Requires AWS expertise for proper configuration |
| Multi-AZ failover protects against AZ outages | Vendor lock-in to AWS ecosystem |
| Native integration with WAF, ACM, CloudWatch | Debugging requires understanding of VPC networking |
| Health checks auto-remove failing instances | Session management needs Redis or sticky session setup |
FAQ
What is the difference between ALB and NLB for Magento?
ALB operates at Layer 7 and understands HTTP traffic, enabling URL-based routing and WAF integration. NLB operates at Layer 4 with ultra-low latency and static IP support. Most Magento stores should use ALB because it supports content-based routing and cookie-based sticky sessions.
How many load balancers does a Magento setup need?
The AWS reference architecture uses two ALBs: one for the Varnish cache tier and one for the Magento application tier. Smaller stores can start with a single ALB routing direct to Magento instances, adding the Varnish tier as traffic grows.
Does AWS ELB handle SSL certificates for Magento?
Yes. ALB integrates with AWS Certificate Manager to provision and renew free public SSL certificates. The ALB terminates TLS connections and forwards unencrypted traffic to backend instances over the private VPC network.
How does session persistence work with a Magento load balancer?
Store sessions in Redis (Amazon ElastiCache) so all Magento nodes share session data. This is more reliable than sticky sessions because it survives server failures. Configure the Redis connection in Magento's env.php file.
What happens when a Magento server fails behind the load balancer?
The ALB detects the failure through health checks within 60-90 seconds (based on your configuration). It stops routing traffic to the failed instance and distributes requests to healthy instances. If Auto Scaling is configured, AWS launches a replacement instance.
How much does AWS load balancing cost for a Magento store?
Each ALB costs $0.0225 per hour (~$16.20/month) in US East plus capacity charges based on traffic. A typical Magento store with moderate traffic pays $25-$60 per ALB per month. The two-ALB reference architecture costs $50-$120 per month total. Rates vary by AWS region.
Can I use NLB and ALB together for Magento?
Yes. A common pattern places an NLB in front of an ALB when you need static IP addresses (for firewall whitelisting) combined with Layer 7 routing capabilities. The NLB forwards TCP traffic to the ALB, which then routes based on content.
Is Classic Load Balancer still supported for Magento?
AWS deprecated the Classic Load Balancer and recommends migrating to ALB or NLB. CLB lacks features like path-based routing, WebSocket support, and HTTP/2 that modern Magento deployments benefit from.
How do I monitor my Magento load balancer?
ALB publishes metrics to Amazon CloudWatch including request count, latency, HTTP error rates (4xx, 5xx), healthy host count, and active connections. Set CloudWatch alarms for 5xx error spikes and unhealthy host counts to catch issues early.
What is cross-zone load balancing?
Cross-zone load balancing distributes traffic evenly across all registered instances in all enabled Availability Zones. ALB enables this by default. Without it, each AZ receives an equal share of traffic regardless of how many instances it has, creating uneven per-instance load.
Summary
AWS Elastic Load Balancing keeps Magento stores online during traffic spikes by distributing requests across multiple servers. The Application Load Balancer is the right choice for most Magento deployments, offering Layer 7 routing, WAF integration, and SSL termination at $0.0225 per hour.
The proven architecture uses two ALBs (Varnish tier + application tier), Auto Scaling groups across multiple Availability Zones, and Redis for shared session storage. This setup handles everything from steady daily traffic to flash sale surges without manual intervention.
Building and maintaining this infrastructure requires AWS expertise and ongoing monitoring. Managed Magento hosting handles the load balancer configuration, Auto Scaling policies, health checks, and failover setup so you focus on running your store instead of managing servers.
