MyWordPress.com - Scalable Storage

Overview

Yet another stateful web application — this time we're building a fully scalable WordPress website on AWS. WordPress is one of the most popular ways to create a website, and many people deploy it on AWS.

The unique challenge here isn't about sessions or shopping carts — it's about image storage. WordPress stores uploaded pictures (blog images, media) on a drive, and when you scale to multiple instances across multiple AZs, all instances need access to those images. This case study highlights a critical architectural decision: EBS vs EFS.

Key requirements:

• Fully scalable WordPress website
• Correctly display picture uploads across all instances
• Blog content and user data stored in a MySQL database
• Must work across multiple AZs for high availability

Database Layer: Why Aurora MySQL?

We're already familiar with the standard architecture — Route 53, ELB, ASG, database in the backend. For WordPress, we need a MySQL-compatible database. We have two choices:

Option A: Standard RDS MySQL          Option B: Aurora MySQL
┌──────────────────────┐              ┌──────────────────────┐
│  RDS MySQL           │              │  Aurora MySQL        │
│  - Manual Multi-AZ   │              │  - Built-in Multi-AZ │
│  - Up to 5 replicas  │              │  - Up to 15 replicas │
│  - Manual storage    │              │  - Auto-scaling      │
│  - Standard perf     │              │    storage           │
│                      │              │  - 5x MySQL perf     │
│                      │              │  - Less ops overhead │
│                      │              │  - Global databases  │
└──────────────────────┘              └──────────────────────┘

As a Solutions Architect, choosing Aurora is a deliberate decision. You don't have to — RDS MySQL works fine. But Aurora gives you:

• Less operational overhead — AWS manages more of the infrastructure
• Built-in Multi-AZ with automatic failover
• Up to 15 read replicas (vs 5 for standard RDS)
• Auto-scaling storage — grows automatically in 10 GB increments up to 128 TB
• 5x MySQL throughput — better performance out of the box
• Global databases if you need to scale internationally

The Image Storage Problem: EBS

Now let's talk about the real challenge of this case study — storing and serving uploaded images.

Single Instance: EBS Works Perfectly

┌──────────┐   ┌─────┐   ┌────────────────┐   ┌──────────────┐
│          │   │     │   │  EC2 Instance  │   │  EBS Volume  │
│   User   │──▶│ ELB │──▶│  (AZ1)        │──▶│  (AZ1)       │
│          │   │     │   │               │   │              │
│  Upload  │   │     │   │  Stores image │   │  image.jpg   │
│  image   │   │     │   │  on EBS       │   │  ✅ HERE     │
└──────────┘   └─────┘   └────────────────┘   └──────────────┘

With a single EC2 instance, everything is simple. The user uploads an image, it gets stored on the EBS volume attached to that instance. When someone wants to view the image, the same instance reads it from EBS and serves it. Works perfectly.

Multiple Instances: EBS Breaks

┌──────────┐   ┌─────┐   ┌────────────────┐   ┌──────────────┐
│          │   │     │   │  EC2 (AZ1)     │──▶│  EBS (AZ1)   │
│   User   │──▶│ ELB │──▶│  Upload image  │   │  image.jpg   │
│          │   │     │   │               │   │  ✅ HERE     │
│          │   │     │   └────────────────┘   └──────────────┘
│          │   │     │
│  Read    │   │     │   ┌────────────────┐   ┌──────────────┐
│  image   │──▶│     │──▶│  EC2 (AZ2)     │──▶│  EBS (AZ2)   │
│          │   │     │   │  Read image    │   │              │
│          │   │     │   │  ❌ NOT FOUND! │   │  ❌ EMPTY    │
└──────────┘   └─────┘   └────────────────┘   └──────────────┘

Now we have two instances in different AZs, each with its own EBS volume. A user uploads an image through Instance A — it gets stored on EBS in AZ1. Later, the same user (or another user) tries to view that image, but the request gets routed to Instance B in AZ2. Instance B looks at its own EBS volume — the image isn't there.

This is a very common mistake when scaling WordPress on AWS. EBS volumes are:

• AZ-specific — an EBS volume in AZ1 cannot be accessed from AZ2
• Attached to a single instance — not shared between instances (with limited exceptions)

The Solution: EFS (Elastic File System)

┌──────────┐   ┌─────┐   ┌────────────────┐   ┌───────────┐   ┌─────────────────┐
│          │   │     │   │  EC2 (AZ1)     │──▶│ ENI (AZ1) │──▶│                 │
│   User   │──▶│ ELB │──▶│  Upload image  │   └───────────┘   │      EFS        │
│          │   │     │   └────────────────┘                    │   (Shared NFS)  │
│          │   │     │                                          │                 │
│  Read    │   │     │   ┌────────────────┐   ┌───────────┐   │   image.jpg     │
│  image   │──▶│     │──▶│  EC2 (AZ2)     │──▶│ ENI (AZ2) │──▶│   ✅ FOUND!    │
│          │   │     │   │  Read image    │   └───────────┘   │                 │
│          │   │     │   │  ✅ SUCCESS!   │                    │   Shared across │
└──────────┘   └─────┘   └────────────────┘                    │   ALL instances │
                                                                │   ALL AZs       │
                                                                └─────────────────┘

EFS (Elastic File System) is a Network File System (NFS) that solves the shared storage problem:

1. EFS creates ENIs (Elastic Network Interfaces) in each AZ — these are mount targets
2. EC2 instances in each AZ connect to EFS through their local ENI
3. All instances see the exact same file system — it's shared storage
4. Upload an image from Instance A → it's immediately visible from Instance B, C, D, etc.
5. Works across any number of instances and any number of AZs

EBS vs EFS: The Complete Comparison

Can EBS Multi-Attach Replace EFS?

No. EBS Multi-Attach has severe limitations:

• Only works with io1/io2 volume types (expensive)
• Only works within the same AZ (defeats the purpose of Multi-AZ)
• Requires a cluster-aware file system (not standard Linux file systems)
• Not designed for general shared storage

The Complete WordPress Architecture

┌──────────┐   ┌──────────┐   ┌───────────────────┐   ┌──────────────────────────┐
│          │   │ Route 53 │   │    Multi-AZ ELB   │   │         ASG              │
│  Users   │──▶│  Alias   │──▶│  + Health Checks  │──▶│  AZ1: EC2  EC2          │
│          │   │          │   │                   │   │  AZ2: EC2  EC2          │
└──────────┘   └──────────┘   └───────────────────┘   └───────────┬──────────────┘
                                                                    │
                              ┌─────────────────────────────────────┼──────────────┐
                              ▼                                     ▼              │
                    ┌──────────────────┐                  ┌──────────────────┐     │
                    │   Aurora MySQL   │                  │       EFS        │     │
                    │   Multi-AZ       │                  │   Shared NFS     │     │
                    │   Read Replicas  │                  │   Media/Images   │     │
                    │                  │                  │   Multi-AZ       │     │
                    │   Blog content   │                  │                  │     │
                    │   User data      │                  │   ENI in AZ1     │◀────┘
                    │   Comments       │                  │   ENI in AZ2     │
                    └──────────────────┘                  └──────────────────┘

The complete architecture has three storage layers:

1. Aurora MySQL — blog content, user data, comments, settings (structured data)
2. EFS — uploaded images, media files, WordPress themes/plugins (shared files)
3. EC2 local storage — WordPress application code, temporary files

Key Takeaways

Questions & Answers