Most "WordPress on AWS" guides stop at "spin up an EC2 instance and install Apache." That works until the site gets traffic, needs to survive a reboot, or has to pass a security review. This is the senior-engineer playbook: which AWS landing target fits your site (Lightsail, EC2, or ECS/Fargate), the database (Aurora/RDS MySQL), where wp-content/uploads lives (EFS vs offload to S3 + CloudFront), the object cache (ElastiCache), the cutover with the DNS switch — and the real cost. For larger or enterprise WordPress estates, a MAP-funded AWS partner can run the whole thing, often at little-to-no cost to you.
WordPress runs fine on a $15/month shared host right up until it does not. The triggers for moving to AWS are almost always the same three, and they decide which AWS target you should land on.
The first trigger is traffic and reliability. Shared and budget managed hosts cap CPU, memory, and database connections aggressively, and a traffic spike (a launch, a newsletter, a piece that gets picked up) takes the site down or throttles it into uselessness. On AWS you can put WordPress behind an Application Load Balancer with an Auto Scaling group or run it on Fargate so capacity follows demand instead of falling over at it — and you get genuine multi-AZ high availability instead of a single host that is one hardware failure away from an outage.
The second trigger is control and integration. Teams move to AWS to manage PHP versions, OPcache, web-server tuning, and TLS themselves; to put WordPress in the same VPC, WAF, logging, and IAM model as the rest of their stack; or because a compliance requirement (SOC 2, ISO 27001, HIPAA, a procurement security review) demands controls a generic host cannot evidence. AWS gives you VPC isolation, Security Groups, AWS WAF, GuardDuty, CloudTrail, and KMS encryption — the building blocks a security reviewer expects to see.
The third trigger is cost at scale and consolidation. A single small site is cheaper on a budget host than on AWS. But once you run several sites, a multisite network, or a high-traffic publication with a CDN and a staging pipeline, the per-site economics flip — and consolidating onto one AWS account you already operate beats paying a premium managed-WordPress vendor per site. The honest framing: do not migrate a single low-traffic brochure site expecting to save on hosting alone. Migrate when reliability, control, or consolidation is the driver.
Whichever trigger applies, the work splits into two halves: choosing the landing target (the web tier) and getting the state right (database, media, cache). The next sections take them in that order.
This is the decision most guides get wrong by pretending there is one answer. There are three, and they map to three different scale-and-control profiles. Pick deliberately — re-platforming later is more work than choosing right now.
All three run the same WordPress code. The difference is how much of the server you manage, how the site scales, and how high availability is achieved. Below is the short version; the full side-by-side comparison table is later on this page.
What it is: a managed VPS with a one-click WordPress blueprint (a Bitnami stack), fixed monthly pricing, a built-in CDN option, snapshots, and managed Lightsail databases (MySQL) if you want the DB off the instance. It is the lowest-friction way to get WordPress onto AWS infrastructure.
Best for: a single site or a small handful of sites, low-to-moderate traffic, a team that wants predictable pricing and minimal ops. Plans start around $5–$10/month and step up by RAM/CPU.
Tradeoffs: you trade deep control and elastic horizontal scaling for simplicity. Vertical scaling means resizing to a bigger bundle (a snapshot-and-restore step, brief downtime); true multi-AZ auto-scaling is not the Lightsail model. A clean upgrade from a shared host, not the target for a high-traffic publication.
What it is: a virtual machine you own end-to-end. You choose the instance type (a Graviton-based t4g/m7g for the best price/performance, or x86 if a plugin needs it), the OS, the web server (Nginx + PHP-FPM is the common high-performance choice; Apache works), PHP version, OPcache, and TLS. Pair it with an Application Load Balancer and an Auto Scaling group when you need HA and elasticity.
Best for: teams that want to tune the stack, run custom system packages or cron, or match an existing EC2 estate. A single right-sized instance handles a lot of WordPress traffic when caching is done well.
Tradeoffs: you own patching, hardening, and OS lifecycle (or the partner does). HA is not free — it means running the web tier behind an ALB across at least two AZs with shared state (EFS or S3 for media, RDS/Aurora for the DB) so any instance can be replaced without data loss. A single EC2 with everything on the box is the easiest thing to stand up and the easiest thing to lose.
What it is: WordPress packaged as a container (Nginx + PHP-FPM) running as an ECS service on Fargate — no servers to patch. The ALB spreads traffic across tasks in multiple AZs; ECS service auto scaling adds and removes tasks on CPU/request load. The container filesystem is ephemeral, so state must be external by design — which forces the right architecture: RDS/Aurora for the DB, EFS or S3 for media, ElastiCache for sessions/object cache.
Best for: high-traffic sites, multisite networks, teams that already run containers, and anyone who wants serverless-style HA and scaling without managing instances. The most operationally robust target.
Tradeoffs: the highest upfront engineering. You need a working container image, a CI/CD path to ship updates, and a clear answer for the writable parts of WordPress (plugin/theme installs, uploads) since a local disk will not persist. This is the target where a partner earns their fee — and where MAP funding most often applies.
Single site, want it simple → Lightsail. Want to own and tune the box (or match an EC2 estate) → EC2, behind an ALB + Auto Scaling group if you need HA. High traffic, multisite, or container-native and you want hands-off scaling → ECS on Fargate. The web tier is the easy part — the database, media, and cache decisions below matter far more.
WordPress is a stateful app pretending to be a simple one. Everything that makes a WordPress migration succeed or fail lives in three places: the MySQL database, the wp-content/uploads directory, and the object cache. Get these right and the web tier is interchangeable.
The single most important move is to take the database off the web instance. On a default install, MySQL/MariaDB runs on the same box as PHP; if that box dies, so does the data, and you cannot scale the web tier horizontally because each node would have its own database. The fix is a managed database.
Move the WordPress database to Amazon RDS for MySQL (the straightforward managed-MySQL choice) or Amazon Aurora MySQL (MySQL-compatible, higher performance, faster failover, storage that auto-grows). Both give you automated backups, point-in-time recovery, Multi-AZ failover, and KMS encryption at rest — none of which you get from MySQL on an EC2 box without building it yourself.
For a single site, a db.t4g-class RDS instance is plenty and inexpensive. For high-traffic or multi-AZ HA, Aurora MySQL with a writer plus read replicas is the stronger choice; WordPress is read-heavy, and Aurora read replicas absorb that. WordPress only needs a MySQL-compatible endpoint — point DB_HOST in wp-config.php at the RDS/Aurora endpoint and it does not know the difference. Keep the database in private subnets, reachable only from the web tier's Security Group on port 3306 — never publicly exposed.
WordPress writes uploaded media, and (unless you lock it down) plugin and theme files, into wp-content. The moment you run more than one web node, those writes have to be shared or the nodes drift out of sync. There are two good answers, and they are not mutually exclusive.
Option 1 — Amazon EFS (shared filesystem). Mount EFS at wp-content/uploads (and optionally plugins/themes) so every EC2 instance or Fargate task sees the same files. This is the lift-and-shift-friendly option: WordPress keeps writing to a "local" path that is actually a shared, multi-AZ, elastic NFS filesystem. The tradeoff is that EFS is slower than local disk for many small-file reads and costs more per GB than S3 — fine for moderate media volumes, less ideal for a large library under heavy traffic.
Option 2 — offload media to Amazon S3, serve through CloudFront (recommended at scale). Use a plugin (for example WP Offload Media) so new uploads push to an S3 bucket and the URLs are rewritten to a CloudFront distribution. The web nodes become near-stateless — they no longer store the media library — which is exactly what you want for ECS/Fargate and clean horizontal scaling. S3 is cheap and durable; CloudFront puts images, CSS, and JS on a global CDN edge so they are fast everywhere and the origin barely gets touched. For high-traffic sites this is both faster and cheaper than serving media off EFS or an instance.
A common, sensible pattern: S3 + CloudFront for media and static assets (the bulk of bytes and requests) plus a small EFS or container-baked layer only for what WordPress insists on writing locally. The goal is to make the web tier as close to stateless as WordPress allows.
By default WordPress rebuilds a lot of its page on every request and stores transient/object cache in the database, which makes MySQL the bottleneck under load. Add Amazon ElastiCache (Redis or the Valkey engine) and a Redis object-cache plugin so WordPress caches objects in memory instead. This is one of the highest-leverage performance moves: it slashes database queries per page, lets the DB stay small, and is essential once you run multiple web nodes (they share one cache instead of each warming their own).
ElastiCache also gives you a shared session and full-page-cache backend that works across nodes — important for logged-in/WooCommerce traffic where you cannot just cache everything at the CDN. Like the database, keep ElastiCache in private subnets reachable only from the web tier.
A WordPress migration is moving three things — the database, the files, and the DNS — without losing data or taking the site down for long. How you move them depends on the size of the site and the downtime you can tolerate.
There are two honest paths. The plugin-based path is fast and forgiving for small-to-medium sites. The manual path (and DMS for the database) gives you control and the smallest cutover window for large or high-traffic sites. Pick by size and risk tolerance.
Tools like All-in-One WP Migration, Duplicator, or a managed-host migration plugin package the entire site — database, files, plugins, themes — into an archive you import on the AWS target. For a small site this is genuinely a one-evening job: install WordPress (or use the Lightsail blueprint) on the target, import the archive, repoint the database and URLs, test, then cut over DNS.
The catch is size and writes-in-flight. Large media libraries blow past plugin upload limits, and any content created on the old site after you export is lost unless you re-export. So the plugin path works best for sites small enough to export-and-import inside a short window, or sites you can put into a brief read-only/maintenance state during the move.
Database: take a mysqldump of the WordPress DB and load it into RDS/Aurora — or, for the smallest cutover window, use AWS Database Migration Service (DMS) to do an initial load plus change data capture (CDC) so the RDS/Aurora copy stays continuously synced with the live MySQL while you test. With CDC running, the database cutover is just "stop writes on the old DB, let the last changes drain, switch the endpoint" — seconds to a few minutes.
Files: move wp-content with rsync (a one-time copy from a reachable old server) or AWS DataSync for large media libraries into EFS or S3. If you are offloading to S3, bulk-copy the existing uploads into the bucket and let the offload plugin take over new uploads from cutover onward.
Config: update wp-config.php on the target with the new DB_HOST (the RDS/Aurora endpoint), DB credentials (from Secrets Manager, not hard-coded), the Redis/ElastiCache settings, and site/home URL handling. Run a database search-replace for any hard-coded old-domain URLs (WP-CLI's search-replace handles serialized data safely).
Before cutover, lower the DNS TTL on the site's records (in Route 53 or wherever DNS lives) to 60–300 seconds a day ahead, so the switch propagates fast. Stand the new stack up on a temporary hostname, point it at the synced database, and validate end-to-end: pages render, media loads from CloudFront/EFS, logins work, the cache is warming, and any WooCommerce/checkout flows succeed.
When you are satisfied, run the cutover: put the old site read-only (or accept that the last few minutes of writes move via CDC), do the final DB sync, then update the DNS record (and the ALB/CloudFront alias) to point at the new AWS stack. With a low TTL and a synced database, real-world downtime is typically 0–15 minutes — and zero for the read path if you front everything with CloudFront. Keep the old environment alive for a day or two as a rollback path before decommissioning.
The reason most teams move to AWS is to stop the site falling over. Here is what "highly available WordPress" actually looks like once the state is external.
Once the database is on RDS/Aurora, media is on EFS or S3, and the object cache is on ElastiCache, the web tier becomes replaceable — and that is what unlocks HA and scaling. The pattern is the same whether the web tier is EC2 or Fargate:
You do not need all of this on day one. A single right-sized EC2 or small Fargate service with the database on RDS, media on S3+CloudFront, and a page cache already outperforms most managed hosts and survives an instance replacement. Add Multi-AZ web nodes and read replicas when traffic or the SLA demands it — the point of the architecture is that you can add HA incrementally without re-platforming, because the state is already in the right place.
A WordPress site on AWS should be measurably more secure and faster than it was on a shared host — and you should know the bill before you commit. Here are the three in turn.
Put WordPress in a VPC with the web tier in ALB-fronted subnets and the database and cache in private subnets, locked down by Security Groups so only the web tier reaches MySQL (3306) and Redis (6379). Terminate TLS with a free ACM certificate at the ALB or CloudFront. Front the site with AWS WAF using managed rule groups (core ruleset, known-bad-inputs, and a WordPress-specific ruleset that blocks xmlrpc.php abuse, login brute-force, and common plugin exploits) plus rate limiting. Turn on GuardDuty for threat detection and CloudTrail for an audit log, encrypt RDS/Aurora, EFS, and S3 with KMS, and keep DB credentials and salts in Secrets Manager / SSM Parameter Store, not plaintext wp-config.php. Harden WordPress itself: disable dashboard file editing, least-privilege IAM for the instances/tasks, keep core and plugins patched, and (on stateless tiers) make the codebase read-only at runtime so a compromised plugin cannot rewrite files.
Performance on AWS is a layered cache story. At the edge, CloudFront serves static assets and (with the right cache policy) full cached pages globally, so most requests never reach your origin. In WordPress, a page-cache plugin generates static HTML and an ElastiCache-backed object cache eliminates redundant database queries, while OPcache keeps compiled PHP hot. Done together, the origin handles a small fraction of requests, TTFB drops sharply, and you can run a smaller, cheaper compute tier than the raw traffic suggests. For media specifically, the S3 + CloudFront offload pattern (Section III) is the single biggest win — it moves the heaviest bytes off your servers entirely.
A simple single site on Lightsail starts around $5–$10/month (optionally plus a managed Lightsail database and CDN) — competitive with a decent managed host, AWS reliability underneath. A small EC2-based site (a right-sized Graviton instance + a db.t4g RDS + S3/CloudFront for media) typically lands in the ~$30–$80/month range depending on traffic and storage. A production HA estate on ECS/Fargate or multi-AZ EC2 — load balancer, Aurora with a replica, ElastiCache, EFS/S3, WAF, CloudFront — costs more, but buys real availability and scale, and Graviton + Savings Plans + heavy S3/CloudFront caching keep it well below per-site enterprise managed-WordPress pricing once you run several sites. The honest line: AWS is not the cheapest home for one tiny site, but it is usually cheaper and far more capable for anything with real traffic, multiple sites, or a compliance bar — and a partner will model your actual before/after cost first.
Everything above is doable in-house if you have AWS depth and time. Most teams migrating a revenue-bearing WordPress estate would rather have a vetted partner run it — and for larger migrations, AWS will help pay for it.
CloudRoute routes you to an AWS partner who has done WordPress-on-AWS migrations before: they size the right landing target, build the VPC/landing zone, stand up RDS/Aurora + ElastiCache + EFS/S3 + CloudFront, containerize or harden the web tier, run the database and file sync (DMS/DataSync), rehearse and execute the DNS cutover, and stay on for the rollback window. You get a production-grade result instead of a half-finished "WordPress on a single EC2" that nobody wants to own.
The funding mechanism is the AWS Migration Acceleration Program (MAP). For qualifying migrations — typically those with a meaningful post-migration AWS spend commitment, which a larger WordPress estate, a multisite network, or a publication with real infrastructure can reach — AWS funds the work across its phases: Assess (a free TCO/readiness review), Mobilize (landing zone + pilot), and Migrate (production cutover). AWS pays the partner through MAP, so the customer migrates at little-to-no cost. The honest caveat: MAP applies to qualifying migrations only; a single small site will not hit the threshold. When it does not qualify, CloudRoute still routes you to a vetted partner who de-risks the cutover — and you can stack MAP with general-purpose AWS credits where eligible.
Either way, the customer pays CloudRoute nothing — the partner pays a routing commission on closed engagements, and AWS funds the migration through MAP. Your job is to describe the site; the partner's job is to land it on AWS without a bad cutover.
Larger or enterprise WordPress estate (multisite, high traffic, a real infra footprint) → likely MAP-eligible: AWS funds Assess → Mobilize → Migrate and you migrate at low/$0 cost. Smaller single site → a vetted-partner referral that de-risks the move, plus AWS credits where eligible. Read more: how AWS MAP funds your migration · $100K AWS credits · the migration service in detail.
The web-tier decision in one table. All three run the same WordPress; they differ in how much you manage, how they scale, and how HA is achieved. State (DB, media, cache) lives off-box in every case for anything beyond a single Lightsail instance.
| Variable | Lightsail | EC2 | ECS on Fargate |
|---|---|---|---|
| What you manage | Almost nothing (managed VPS + blueprint) | The whole server (OS, web server, PHP, patching) | The container image + the service config (no servers) |
| Best for | Single / few sites, low–moderate traffic | Full control, tuning, matching an EC2 estate | High traffic, multisite, hands-off HA scaling |
| Scaling model | Resize the bundle (vertical; brief downtime) | Vertical, or ALB + Auto Scaling group for horizontal | Service auto scaling — add/remove tasks automatically |
| High availability | Single-instance (snapshots for recovery) | HA via ALB across multi-AZ + external state | Multi-AZ by design; tasks self-heal |
| Database | Lightsail managed DB or RDS | RDS / Aurora MySQL (off-box) | RDS / Aurora MySQL (must be external) |
| Media / wp-content | Instance disk or S3 offload | EFS (shared) or S3 + CloudFront | S3 + CloudFront (preferred) or EFS — never local |
| Object cache | Optional (Redis on instance or ElastiCache) | ElastiCache (Redis/Valkey) | ElastiCache (required for shared sessions/cache) |
| Ops effort to run | Lowest | Medium–high | Medium (after the initial container build) |
| Starting cost | ~$5–$10/mo bundle | ~$30–$80/mo small site | Higher; scales with traffic (best per-site at scale) |
Situation: Outgrowing their managed host: per-site pricing had ballooned, traffic spikes on big stories caused throttling and 5xx errors, and a new advertiser security review demanded WAF, audit logging, and encryption their host could not evidence. They wanted one consolidated, highly available platform with a CDN and room to scale — but had no in-house AWS team and were wary of a long, expensive migration.
What CloudRoute did: Routed within 24 hours to a UK-based AWS migration partner with WordPress-on-AWS and media experience. Partner ran a MAP Assess (free TCO + readiness), then Mobilize: built the landing zone/VPC, containerized the multisite on ECS Fargate behind an ALB across two AZs, moved the database to Aurora MySQL (writer + read replica), offloaded all media to S3 served via CloudFront, added ElastiCache (Redis) for the object cache, and fronted everything with AWS WAF + ACM TLS. Database cutover used DMS with CDC; media bulk-copied to S3 via DataSync; final DNS switch in Route 53 with a 60-second TTL.
Outcome: Cutover downtime under 10 minutes, zero on the read path (served from CloudFront throughout). Spikes that used to throttle now auto-scale on Fargate. The migration was MAP-funded — AWS paid the partner across Assess/Mobilize/Migrate — so the customer's migration cost was effectively $0. Run-rate hosting landed ~45% below the prior per-site managed bill, and the WAF + CloudTrail + KMS posture cleared the advertiser security review.
engagement window: ~3 weeks · cutover downtime: <10 min · run-rate hosting: ~45% lower · migration cost to customer: $0 (MAP-funded)
CloudRoute routes you to a vetted AWS partner who lands WordPress on the right target (Lightsail, EC2, or ECS/Fargate), gets the database, media, and cache right, and runs the cutover. For qualifying estates, MAP funds the migration — customer pays $0. No procurement theater.