AWS WordPress Hosting — Series Overview

Experiment #2 — AWS EC2 + RDS + ElastiCache

1. Objective of the Experiment

In this second experiment, the goal was to explore a more modular and scalable architecture for hosting multiple small WordPress sites on AWS.

Specifically, I wanted to test whether delegating the database to Amazon RDS and offloading object caching to ElastiCache could compensate for a deliberately underpowered EC2 instance hosting three WordPress sites.

The objectives were:

  • improve performance with a lightweight EC2 instance,
  • increase modularity by decoupling the database and caching layers,
  • simplify vertical/horizontal scaling,
  • prepare for better resilience and easier recovery,
  • evaluate real-world overhead and costs.

2. Context and Technical Constraints

Architectural Motivation

Instead of running everything on a single EC2 instance (web server + database + object cache), the idea was to:

  • keep the EC2 instance minimal and cheap,
  • move the database to Amazon RDS,
  • move object caching to ElastiCache (Redis),
  • store WordPress data on EBS for easier instance replacement.

This separation is aligned with traditional high-availability WordPress architectures — but the question was whether it actually helps small sites.

Security Requirements

  • EC2 protected behind CloudFront/WAF (same as Experiment #1).
  • RDS placed in private subnets without public access.
  • ElastiCache also isolated within the VPC.
  • Security Groups restricted to EC2 only.

Functional Requirements

  • Host three small WordPress sites with low-to-medium traffic.
  • Ensure acceptable performance despite a modest EC2 instance.
  • Reduce monolith dependency: easier to replace EC2 independently from DB.

Cost Requirements

  • Keep all components small (db.t3.micro, cache.t3.micro, small EC2).
  • Avoid unnecessary multi-AZ or large instance classes.
  • Compare the cost to a simple all-in-one EC2 setup.

Maintenance Requirements

  • Maintain WordPress on EC2 with minimal changes.
  • Delegate database patching to RDS.
  • Avoid managing Redis manually.

Architecture Overview - EC2 + RDS + ElastiCache

flowchart TD
  User["User / Browser"] --> CF["CloudFront\nCDN + TLS (ACM)"]
  CF --> WAF["AWS WAF\nManaged & Custom Rules"]
  WAF --> EC2["EC2 Instance\nWordPress + PHP + Web Server"]

  EC2 --> RDS["Amazon RDS\nManaged Database"]
  EC2 --> Cache["ElastiCache (Redis)\nObject Cache"]

  EC2 --> EBS["EBS Volume\nWordPress Files"]

  Admin["Admin / Ops"] --> SSM["SSM Session Manager"]
  SSM --> EC2

  %% Styles
  classDef edge fill:#eef2ff,stroke:#4f46e5,stroke-width:1px,color:#111;
  classDef data fill:#ecfeff,stroke:#0891b2,stroke-width:1px,color:#111;
  classDef mgmt fill:#fee2e2,stroke:#b91c1c,stroke-width:1px,color:#111;

  class CF,WAF edge;
  class RDS,Cache,EBS data;
  class Admin,SSM mgmt;

Figure A — Three tiers AWS architecture on AWS and Wordpress.

3. Architecture Tested

3.1. AWS Infrastructure Components

  • EC2 instance

    • Small instance hosting Nginx/Apache + PHP + WordPress for three sites.
    • EBS used for /var/www to simplify instance replacement.

  • Amazon RDS (MySQL/PostgreSQL depending on tests)

    • Managed database service.
    • Private subnets only.
    • Automated backups.

  • ElastiCache (Redis)

    • Used for WordPress object caching.
    • Also in private subnets.
    • Connected via Redis-based plugins (e.g., Redis Object Cache).

  • VPC + Subnets

    • Public subnet for EC2.
    • Private subnets for RDS and ElastiCache.

  • CloudFront + WAF

    • Same protection model as Experiment #1.

3.2. Infrastructure Security (AWS Architecture)

  • EC2 accessible only through CloudFront.
  • RDS access restricted to the EC2 Security Group.
  • ElastiCache restricted to the EC2 Security Group.
  • No public endpoints for RDS or Redis.
  • SSM for instance access (no SSH exposed).
  • TLS termination at CloudFront using ACM.

3.3. Application Security (WordPress Layer)

Application-level security was similar to Experiment #1:

  • CloudFront/WAF protections on wp-login.php.
  • Optional integration with Twingate or Cloudflare ZTNA for admin access.
  • WordPress hardening (file editing disabled, strong passwords, plugin restriction).
  • XML-RPC blocked.

Nothing in this experiment was fundamentally different at the application level — the main focus was on the architecture.

3.4. High-Level Traffic Flow

  1. CloudFront receives the request and applies WAF rules.
  2. Valid requests reach the EC2 instance.
  3. The EC2 instance queries:
    • RDS for database operations,
    • ElastiCache for cached objects.
  4. WordPress serves the response back through CloudFront.

3.5. Technical Observations

This architecture introduced major changes in request flow, introducing additional network hops between components:

  • EC2 ↔ RDS
  • EC2 ↔ ElastiCache
  • EC2 ↔ CloudFront (origin fetch)

This brought advantages — but also significant drawbacks.

4. Results and Analysis

4.1. Pros

1. Excellent modularity

Separating components made the system less monolithic:

  • EC2 can be replaced easily without database loss.
  • Database upgrades and backups are cleaner with RDS.
  • Redis caching can be tuned independently.

2. Easier scaling

You can scale bottlenecks individually:

  • scale EC2 CPU/RAM,
  • scale RDS instance class or storage,
  • scale ElastiCache if cache hit rate is low.

This is much more flexible than a single-instance WordPress setup.

3. More resilient design

  • RDS backups and snapshots simplify recovery.
  • EBS-based WordPress files make EC2 replacement trivial.
  • EC2 downtime no longer impacts the database.

4.2. Cons

1. Much more complexity

You must design:

  • VPC subnets,
  • routing tables,
  • Security Groups per component,
  • RDS parameters,
  • Redis connections,
  • failover and maintenance logic.

This adds a lot of operational overhead for small sites.

2. Surprisingly worse performance

For small workloads with frequent tiny WordPress queries, the architecture became slower:

  • Every DB call = VPC network hop
  • Every cache hit = VPC network hop
  • EC2 instance was underpowered → slow PHP execution
  • The theme/plugin architecture played a massive role

In several tests, the database roundtrip latency outweighed the benefits of managed RDS, especially with poorly coded themes.

3. Latency-sensitive WordPress themes performed very poorly

Some themes made 50+ small queries per page, multiplying cross-VPC calls.

Conclusion:
Small WordPress sites benefit more from local DB + local Redis than from managed distributed services.

4. Higher cost

Even at minimal instance sizes:

  • RDS micro instance
  • ElastiCache micro instance
  • Extra data transfer
  • Extra EBS storage

→ cost became significantly higher than a simple EC2-only setup.

4.3. Estimated Costs

Approximate monthly cost:

  • EC2: CHF 8–12
  • RDS micro: CHF 15–25
  • ElastiCache micro: CHF 15–20
  • EBS: CHF 1–3
  • CloudFront: CHF 1–15
  • WAF: CHF 20–25

Total: ~CHF 60–100 per month
This is far above the cost target for small sites.

5. Conclusion

This experiment shows that splitting WordPress into EC2 + RDS + ElastiCache offers strong architectural benefits:

  • better modularity,
  • easier scaling,
  • clean separation of responsibilities,
  • improved resilience.

However, for small multi-site setups with low traffic:

  • the added network latency,
  • the substantial architectural complexity,
  • the higher cost,
  • and the sensitivity to theme/plugin implementation

make this approach less efficient and less performant than a simple all-in-one EC2 configuration.

For most small WordPress environments, a monolithic EC2 with proper caching is not only cheaper but faster.

The next article will explore another variant: architectures involving Cloudflare, ALB, and combinations that aim to reduce complexity while increasing security.

Related Posts