Deploying Magento on AWS

Why AWS for Magento?

Magento is a demanding platform. A mid-size catalogue with 100,000 SKUs and moderate traffic can easily saturate an underpowered server. AWS gives you the elasticity to handle Black Friday traffic spikes without paying for that capacity in July. Its managed services — Aurora, ElastiCache, OpenSearch — replace components that would otherwise require dedicated engineering effort to operate reliably.

The architecture below has been tuned for real-world Adobe Commerce workloads. It is not a generic LAMP stack deployment — every component choice is deliberate.

Architecture at a Glance

Internet
    │
    ▼
Route 53  (DNS + health checks)
    │
    ▼
CloudFront + WAF  (CDN, full-page cache, bot protection)
    │
    ├──► S3  (/media/*, /static/* assets)
    │
    ▼
Application Load Balancer  (HTTPS, multi-AZ)
    │
    ▼
Auto Scaling Group  (EC2 — Nginx + PHP-FPM)
    │         │          │
    ▼         ▼          ▼
ElastiCache  Aurora   OpenSearch
(Redis)      MySQL    Service
    │
    ▼
EFS  (shared pub/media, var/)

Traffic hits CloudFront first. For a typical Magento store with full-page caching enabled, 70–80% of requests never reach your origin servers. That single fact drives down compute costs more than any instance right-sizing.

Layer 1: DNS and Edge

Route 53 provides DNS with latency-based routing and health checks. If your primary region becomes unhealthy, Route 53 fails over automatically — no manual intervention required.

CloudFront sits in front of everything and serves two purposes:

• Static asset delivery — JS, CSS, and product images are served from the nearest edge location globally, cutting latency for international shoppers dramatically.
• Full-page caching — Magento's built-in FPC, when pointed at CloudFront, caches entire rendered pages at the edge. A cached category page costs zero PHP execution time.

AWS WAF is attached directly to the CloudFront distribution with two managed rule sets:

• AWSManagedRulesCommonRuleSet — OWASP Top 10 protection (SQL injection, XSS, path traversal)
• AWSManagedRulesBotControlRuleSet — blocks scrapers and credential-stuffing bots that disproportionately target Magento admin panels and checkout flows

Layer 2: Compute — Auto Scaling with Spot Instances

The web tier runs Nginx + PHP-FPM on EC2 inside an Auto Scaling Group spread across three Availability Zones. The key cost lever is the mixed instances policy:

Using three instance family fallbacks for Spot prevents interruptions from draining your entire fleet simultaneously. Scaling is driven by ALBRequestCountPerTarget rather than CPU — CPU is a lagging indicator on PHP workloads and scales too late.

All instances are launched from a golden AMI — a pre-baked image containing the Magento application code, Nginx config, and PHP-FPM tuning. Cold start time for a new instance is under 90 seconds.

Layer 3: Shared Storage (EFS + S3)

Magento writes to two locations that must be shared across every web node: pub/media (uploaded product images) and var/ (logs, reports, import/export). We mount Amazon EFS at both paths on every instance via the bootstrap script.

EFS with throughput_mode = elastic handles burst I/O without pre-provisioning throughput — you pay only for what you use. Product images and static files are also synced to S3 and served via CloudFront's S3 origin. S3 Intelligent-Tiering automatically moves infrequently accessed media to cheaper storage classes, reducing S3 costs by up to 40% for stores with large back-catalogues.

Layer 4: Database — Aurora MySQL Serverless v2

Aurora MySQL Serverless v2 replaces a traditional provisioned RDS instance with a database that scales its compute capacity in fine-grained increments in response to actual load — in under a second.

A store running overnight at 0.5 ACUs is paying a fraction of what a provisioned instance costs at idle. During a flash sale that drives 10× normal query load, Aurora scales to 32 ACUs automatically — without a maintenance window, a failover, or a support ticket.

• 1 writer + 1 reader across two AZs — Aurora handles automatic failover to the reader in ~30 seconds
• Backtrack enabled (24-hour window) — rewind the database to any point in the past 24 hours without restoring from a snapshot
• Deletion protection on — a safeguard we always enable in production
• Credentials in Secrets Manager — database passwords are never in environment files

Compared to a provisioned db.r6g.xlarge Multi-AZ instance, Aurora Serverless v2 typically saves 40–55% on database costs for stores with variable traffic patterns.

Layer 5: Cache — ElastiCache Redis

Magento uses Redis for three distinct purposes and it is essential to configure them correctly:

A properly configured Redis layer reduces Aurora query load by 60–80% for a typical Magento store. We deploy a Redis 7.x replication group with two nodes across two AZs, automatic failover, and encryption at rest and in transit — required for PCI-DSS compliance.

Layer 6: Search — OpenSearch Service

Magento 2.4+ requires Elasticsearch or OpenSearch for catalogue search. Self-managing Elasticsearch on EC2 is operational overhead that rarely pays off. AWS OpenSearch Service handles version upgrades, automated snapshots, and node replacement transparently.

For most catalogues up to 500,000 SKUs, two t3.medium.search nodes with zone awareness enabled is sufficient and cost-effective. Stores with complex attribute filtering or high concurrent search loads should size up to r6g.large.search.

Zero-Downtime Deployments: Blue/Green via ALB

Maintenance mode is the enemy of conversion rate. Our deployment strategy eliminates it entirely using Blue/Green deployments via ALB weighted target groups.

ALB
 ├── Target Group BLUE  (current production)  ← 100% traffic
 └── Target Group GREEN (new deployment)       ←   0% traffic

Step 1: Deploy new code to GREEN ASG
Step 2: Run setup:upgrade on one GREEN node
Step 3: Warm up GREEN (curl key URLs, warm Redis)
Step 4: Shift 10% traffic to GREEN → monitor error rate
Step 5: Shift 100% traffic to GREEN
Step 6: Deregister BLUE

If monitoring detects elevated error rates during the traffic shift, we shift 100% back to BLUE in seconds. The entire rollback is a single ALB listener rule weight change — no re-deployment required.

Cost Summary

For a medium-traffic store (~500,000 page views/month), this architecture runs comfortably in the $500–900/month range. At 5 million page views/month, expect $1,500–3,000/month — a fraction of the cost of traditional dedicated hosting at the same performance level.

High Availability Summary

Is This Architecture Right for You?

This stack is designed for stores that have outgrown shared hosting or single-server VPS deployments and need infrastructure that grows with them. If you're experiencing any of the following, it's time to consider this architecture:

• Slow page loads during peak hours
• Downtime during deployments or database migrations
• Infrastructure that cannot absorb promotional traffic spikes
• High hosting costs relative to traffic volume
• No automated failover for database or cache