AWS Server Setup for Magento 2: Production-Ready Guide

The Right AWS Architecture for Magento 2

Choosing the wrong instance type or missing a caching layer can mean the difference between a Magento 2 store that loads in 800ms versus one that times out under traffic. After deploying dozens of Magento 2 stores on AWS, this is the architecture that reliably handles production traffic.

Phase 1: Infrastructure Stack

Recommended AWS Services

• EC2: Application server. Start with c6i.2xlarge for mid-traffic stores (8 vCPU, 16GB RAM). Use c6i.4xlarge for high-traffic.
• RDS MySQL 8.0: Managed database. Use db.r6g.large minimum. Enable Multi-AZ for production. Separate read replica for heavy catalog queries.
• ElastiCache Redis: Sessions + full-page cache backend. cache.r6g.large with cluster mode disabled for Magento 2 compatibility.
• S3 + CloudFront: Media storage and CDN. Use S3 for pub/media and CloudFront distribution for global edge caching.
• Elastic Load Balancer: Required for multi-node setups and SSL termination. Terminating TLS here is infrastructure work, not Magento security work, and the two get confused often enough to be worth separating.

Phase 2: Web Server Configuration

Most of this section transfers directly to WordPress and WooCommerce hosting, where the same Nginx and PHP-FPM tuning applies to a much lighter application.

Nginx + PHP-FPM Setup

The official Magento 2 Nginx configuration is a good starting point but requires tuning for production:

# PHP-FPM pool config (/etc/php/8.2/fpm/pool.d/magento.conf)
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500

Varnish 7.x Configuration

Varnish provides full-page cache for Magento 2 with significant performance gains. Key configuration points:

• Use Magento's built-in VCL export from System → Cache Management → Varnish Configuration
• Configure BACKEND_HOST to point to Nginx (not public), listening on port 8080
• Set BACKEND_PORT to 8080, Varnish listens on 80/443 via ELB
• TTL for full-page cache: 86400s (24h): Magento handles cache invalidation via ban

Phase 3: Redis Configuration

Separate Redis Instances for Sessions & Cache

Using a single Redis instance for both sessions and cache is a common mistake: cache eviction can clear session data, causing unexpected logouts. It is also one of the cheapest wins in Magento performance work, because it costs nothing but configuration. Use two separate Redis databases or instances:

# app/etc/env.php
'session' => [
    'save' => 'redis',
    'redis' => [
        'host' => 'session-redis.xxx.cache.amazonaws.com',
        'port' => '6379',
        'database' => '2',
        'compression_threshold' => '2048',
    ],
],
'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'Cm_Cache_Backend_Redis',
            'backend_options' => [
                'server' => 'cache-redis.xxx.cache.amazonaws.com',
                'database' => '0',
                'port' => '6379',
            ],
        ],
    ],
],

Phase 4: Deployment Pipeline

A pipeline anyone on the team can run is the difference between maintainable Magento and a platform that waits on one person. A reliable Magento 2 deployment pipeline on AWS should include:

• GitHub Actions or CodePipeline triggering on merge to main
• Composer install in the CI environment (not on the server)
• Zero-downtime deployment via rsync to a staging directory + atomic symlink swap
• bin/magento setup:upgrade --keep-generated for production deploys
• Automated Varnish flush post-deploy via Magento CLI or AWS Lambda

Infrastructure is usually the second answer to a slow Magento store rather than the first. Magento performance work covers the caching and application layers that decide whether better hardware changes anything at all. If the store is slow and nobody has established why, an eCommerce technical audit measures it on field data before anything gets provisioned.