AWS WordPress Hosting — Series Overview

Series: Experimenting with AWS Architectures to Host WordPress Securely and at Minimal Cost

1. Introduction

This series documents my experiments with hosting WordPress on AWS under three strict constraints:

  • maximum security,
  • minimum cost,
  • minimum maintenance.

The goal is not to build a perfect enterprise-grade solution, but to explore what is realistically achievable for small sites or personal projects — without spending hundreds per month, and without spending hours per week on maintenance.

Throughout this journey, I tested several architectures on AWS, each with different trade-offs in complexity, security posture, and cost. This article provides a high-level overview of the different experiments. The following articles in the series will dive into each approach individually.

2. Global Approach

Before diving into the details, here is the overall methodology used in this laboratory:

  • Start from the simplest possible setup on AWS: a basic EC2 instance hosting WordPress.
  • Gradually harden or decouple components to improve reliability or security.
  • Introduce additional services only when they bring measurable improvements (security, resilience, cost optimisation).
  • Analyse each architecture using the same criteria:
    • security exposure and attack surface,
    • operational maintenance required,
    • expected and hidden costs,
    • real-world feasibility.

This series focuses on decisions, results, and lessons learned — not walkthroughs.

3. Summary of the Main Experiments

This is a quick overview of the setups I tested. Each one will be explored in a dedicated article.

3.1. Experiment #1 — AWS + EC2 + CloudFront + AWS WAF

Goal: build a secure but minimal fully AWS-native architecture.

Key takeaways:

  • Simple in theory; surprisingly complex in practice.
  • Strong security options but sensitive to configuration mistakes.
  • WAF rules and CloudFront behaviours increase the cost quickly.
  • TLS/certificate management is more complex than anticipated.

3.2. Experiment #2 — AWS + EC2 + RDS + ElastiCache

Goal: decouple WordPress into separate compute, database, and caching layers to improve scalability, resilience, and maintainability.

This setup used:

  • a lightweight EC2 instance only for PHP + Nginx/Apache,
  • Amazon RDS (MySQL) for the database,
  • ElastiCache (Redis) for object caching.

Key takeaways:

  • Architecture becomes significantly more complex.
  • Decoupling the database improves recovery scenarios (snapshots, failover).
  • Easy to scale individual components (compute, DB, cache).
  • But performance was worse for small sites:
    • additional network hops,
    • higher latency for small queries,
    • Redis overhead outweighed any caching benefits.
  • Performance depended heavily on the theme and plugins:
    • some WordPress themes slowed down dramatically.
  • Costs increase quickly: RDS + ElastiCache are not “small-site-friendly”.

Conclusion:
Great architecture for medium/high traffic — not cost-effective or performant for very small sites.

3.3. Experiment #3 — AWS + EC2 + Cloudflare

Goal: reduce AWS complexity by delegating caching, TLS, and security to Cloudflare.

Key takeaways:

  • Simplifies TLS and edge protection significantly.
  • Very low cost possible.
  • Cloudflare ZTNA and Tunnel make the origin fully private.
  • But:
    • creates strong dependency on Cloudflare,
    • Cloudflare behaviour can break WordPress admin,
    • Cache logic differs from CloudFront,
    • Some AWS integrations (ACM, S3 signed URLs, Lambda image resizing) do not play well.

3.4. Experiment #4 — AWS + EC2 + ALB + CloudFront + AWS WAF

Goal: introduce an Application Load Balancer (ALB) to cleanly separate responsibilities and simplify WAF and Cognito integration.

Key takeaways:

  • Cleaner traffic flow and more AWS-aligned design.
  • ALB greatly simplifies WAF rules and authentication flows (Cognito).
  • Works extremely well with CloudFront and VPC origins.
  • But adds:
    • extra services,
    • extra logs,
    • extra cost (ALB hours + LCU),
    • more surface for misconfigurations.
  • Feels robust and scalable but overkill for a single small WordPress site.

4. What These Experiments Revealed

Across all experiments, several patterns emerged:

  • Security vs. simplicity is always a trade-off.
    Adding components increases protection but also cost and operational burden.

  • CloudFront, Cloudflare, ALB, and RDS all have non-obvious behaviours.
    Each can introduce subtle constraints in caching, routing, or certificates.

  • Certificate management becomes complex quickly.
    Especially when mixing ACM, external CDNs, and multi-layer proxies.

  • Costs can spike unexpectedly.
    WAF charges, RDS hours, ElastiCache nodes, ALB LCUs, CloudFront logs…
    all add up fast.

  • Maintenance is never zero.
    Even managed services require monitoring, patching, and debugging.

This first article sets the stage. The next ones will examine each setup in depth, with clear discussions around strengths, weaknesses, and total cost of ownership.

5. Planned Structure for the Series

The series is expected to include at least the following articles (final number may change):

  • Article 2 — Experiment #1: AWS + EC2 + CloudFront + WAF
  • Article 3 — Experiment #2: AWS + EC2 + RDS + ElastiCache
  • Article 4 — Experiment #3: AWS + EC2 + Cloudflare
  • Article 5 — Experiment #4: AWS + EC2 + ALB + CloudFront + WAF

Additional experiments or variants may be added depending on future tests.

6. Conclusion

This high-level overview summarises the main paths I explored when trying to host WordPress on AWS securely, affordably, and with minimal ongoing work. Each architecture taught me different lessons — especially regarding cost traps, architectural complexity, and the subtle interactions between AWS services.

The next articles will dive into each setup using a consistent structure:
constraints → architecture → analysis → pros/cons → costs → conclusion.