AWS Hosting Migration for WordPress: Lightsail vs EC2 vs Managed Hosting

Moving a WordPress site to AWS is usually triggered by one of three things: the current shared host has become slow or unreliable, a compliance or data-residency requirement has appeared, or the company already runs everything else on AWS and wants WordPress in the same account. Whatever the trigger, an AWS hosting migration for WordPress is not one decision but two: which AWS product to run it on, and how to move the site without losing data, rankings or email. We handle both through our AWS hosting migration for WordPress service, and this article lays out how we make the call.

This is for the owner or CTO comparing Lightsail, a self-managed EC2 stack, and a managed WordPress host that happens to run on AWS. All three are legitimate. They differ in what you pay, what you have to operate yourself, and how far they scale before you need to re-architect.

the three ways to run WordPress on AWS

Amazon Lightsail

Lightsail is AWS with the sharp edges filed off: fixed-price bundles (typically from about $5 to $40 a month for a single instance), a one-click WordPress image maintained by Bitnami, built-in snapshots, a simple static IP and DNS, and a load balancer if you ever need one. Under the hood it is still EC2 and EBS. What you give up is granularity: you cannot pick an arbitrary instance type, the Bitnami image has its own opinions about file layout and updates, and the moment you want RDS or a real VPC design you are half-way to EC2 anyway.

EC2 with RDS, S3 and CloudFront

The full stack: an EC2 instance running Nginx and PHP-FPM, Amazon RDS for MySQL as the database, S3 for media, CloudFront as the CDN, Route 53 for DNS, ACM for certificates, ElastiCache for Redis object caching and SES for outbound mail. You control every version and every setting, you can scale each layer independently, and you can put it inside the same VPC as the rest of your infrastructure. The price is that you own patching, monitoring, backups and security groups. Nothing here is hard, but all of it is work.

managed WordPress hosting on AWS

Providers such as Cloudways (with AWS as a selectable backend) or WP Engine run the platform for you: server patching, caching layer, backups, staging and support are included. You pay a margin on top of the raw AWS cost and accept some restrictions (banned plugins, limited SSH, no custom Nginx rules). For a marketing site with a small team and no ops person, that margin is often the cheapest engineer you will ever hire.

how we choose between them

Every AWS hosting migration for WordPress we scope starts with the same five questions.

• Is it WooCommerce or a membership site? Uncached, logged-in traffic hits PHP and MySQL on every request. That pushes toward EC2 with RDS and Redis, where the database is not competing with PHP for the same CPU.
• Who will be on call? If the answer is nobody, choose Lightsail with a maintenance contract or a managed host. An unpatched EC2 instance is a liability, not a saving.
• What does the rest of the company run on? If there is already a VPC, an IAM structure and CloudWatch alerting, WordPress belongs inside it on EC2.
• How big is the media library? Above roughly 20-30 GB, offloading uploads to S3 and serving them through CloudFront becomes the sensible default on any option.
• Is there a compliance requirement? Data residency, encryption at rest with your own KMS keys and audit logging are straightforward on EC2 and RDS, and awkward or impossible on the other two.

the reference stack we deploy on EC2

When EC2 is the answer, this is the shape of what we build. It is deliberately boring.

• EC2 t3.small or t4g.small (Graviton, cheaper per request) running Ubuntu LTS, Nginx with FastCGI page cache, PHP-FPM 8.2 or 8.3 with OPcache tuned.
• RDS MySQL 8 on db.t4g.micro or db.t4g.small, Multi-AZ only if the business case justifies doubling the database cost, automated backups with 7-35 day retention.
• An S3 bucket for uploads via WP Offload Media, a CloudFront distribution in front of both the bucket and the origin, and an ACM certificate on the distribution.
• ElastiCache Redis (or Redis on the instance for smaller sites) with the Redis Object Cache plugin.
• SES for transactional email through WP Mail SMTP, with SPF, DKIM and DMARC records in Route 53.
• The CloudWatch agent for memory and disk metrics (EC2 does not report these by default), and alarms on 5xx rate, CPU credit balance and free storage.
• An instance role with least-privilege IAM, so no access keys live in wp-config.php.

// wp-config.php additions on the new stack
define( 'DB_HOST', 'wp-prod.abcdefgh1234.eu-west-1.rds.amazonaws.com' );
define( 'WP_REDIS_HOST', 'wp-cache.abcdef.0001.euw1.cache.amazonaws.com' );
define( 'WP_CACHE', true );
define( 'DISABLE_WP_CRON', true );           // system cron runs wp cron instead
define( 'AS3CF_SETTINGS', serialize( array(
    'provider'         => 'aws',
    'use-server-roles' => true,            // IAM instance role, no keys in config
    'bucket'           => 'example-com-media',
    'region'           => 'eu-west-1',
) ) );

the AWS hosting migration for WordPress, step by step

1. audit the source site

PHP version and extensions in use (imagick, intl, gd and soap are the usual surprises), total size of wp-content/uploads, database size and the largest tables, cron jobs at the server level, any custom .htaccess rules that must become Nginx rules, and which email paths the site relies on. Most migration failures trace back to something on this list that nobody wrote down.

2. drop the DNS TTL early

Set the TTL on the A and CNAME records to 300 seconds at least 48 hours before cut-over, so the switch propagates in minutes rather than a day.

3. build and test the target with the real data

# files: run from the new server, repeatable
rsync -avz --delete -e "ssh -i ~/.ssh/old-host.pem" 
  old-user@old-host:/home/old-user/public_html/ /var/www/example.com/ 
  --exclude 'wp-content/cache' --exclude 'wp-content/updraft'

# database
ssh old-user@old-host "cd public_html && wp db export - --single-transaction" > /tmp/site.sql
wp db import /tmp/site.sql
wp search-replace 'http://example.com' 'https://example.com' --all-tables --precise
wp cache flush && wp rewrite flush

Test the new server by pointing your own machine at it with a /etc/hosts entry, before any DNS changes. Log in, upload an image, submit every form, place a test order if it is a shop, and check Site Health for missing extensions.

4. freeze, final sync, cut over

For a brochure site: run the rsync and database steps again, switch DNS, done. For WooCommerce or anything with user-generated content, put the old site into maintenance mode first so no orders land during the final sync, then repeat the sync (the rsync is incremental and fast), import the final database, switch DNS, and remove maintenance mode on the new site. The window is usually 10-20 minutes.

5. watch for 72 hours

Keep the old server running, read-only, for at least a week. Watch the Nginx error log, the CloudWatch 5xx alarm and Search Console crawl stats. Rankings do not move on a correctly done migration because nothing about the URLs changed.

what breaks after the move, and the fix for each

• Email stops arriving. SES starts in sandbox mode and only delivers to verified addresses. Request production access on day one; it takes up to 24 hours.
• Scheduled tasks stop. With DISABLE_WP_CRON set, WordPress no longer fires its own scheduler on page loads, so system cron has to call it (see below). Without this, scheduled posts, WooCommerce Action Scheduler jobs and backup plugins silently stop.
• Uploads fail. Almost always ownership: chown -R www-data:www-data wp-content/uploads, plus client_max_body_size in Nginx and upload_max_filesize in PHP.
• Large imports fail on RDS. Raise max_allowed_packet in a custom parameter group; the default is small.
• The site is slower than expected. Usually the object cache is not actually connected, or the page cache is bypassed because of a cookie set by a plugin. wp redis status and the X-Cache response header tell you in a minute. If the database was already slow before the move, moving it will not fix it; run the nine-step database cleanup or hand it to our WordPress database optimization service.
• Mixed-content warnings. Hard-coded http:// URLs in theme options or page builder data that search-replace missed because they were serialized oddly; the --precise flag handles most of them.

# /etc/cron.d/wp-example-com
# run WordPress scheduled events every minute, as the PHP user
* * * * * www-data cd /var/www/example.com && wp cron event run --due-now >/dev/null 2>&1

# Nginx: only the cached page reaches the visitor unless they are logged in or have a cart
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache     $skip_cache;
add_header X-Cache   $upstream_cache_status;

cost and operating reality after month one

The AWS bill is only part of it. Somebody has to apply OS security updates monthly, bump PHP when the current branch reaches end of life, review the RDS snapshot policy, respond to the CloudWatch alarms and test that the backups restore. On EC2, budget a couple of hours a month for this or put it under a maintenance and support plan. Lightsail reduces it slightly; managed hosting removes most of it. An AWS hosting migration for WordPress that nobody maintains afterwards ends up in the same state the old host was in.

Two related jobs usually pair with a migration because the site is already being touched: getting a proper offsite, versioned backup in place (see our guide to automated WordPress backups), and using the new caching layers to fix the performance metrics Google actually measures, covered in Core Web Vitals optimization for WordPress.

when to do this yourself vs hire someone

Do it yourself if the site is a brochure site with no e-commerce, you are comfortable with SSH, Nginx and IAM, and you can tolerate an evening of downtime if something goes wrong. Lightsail plus the steps above is a reasonable weekend project.

Hire someone if the site takes money, if the media library is large, if you need the RDS, S3, CloudFront and SES pieces wired correctly the first time, or if the person doing it would be learning AWS on your production site. The migration itself is a fixed-scope job, and we quote it as one.

get a fixed quote for your migration

Tell us the current host, the approximate size of the site, whether it runs WooCommerce, and what is pushing you to move. Within 24 hours you get a recommendation between Lightsail, EC2 and managed hosting, a fixed price for the AWS hosting migration for WordPress, and a cut-over plan with the downtime window stated. Reach us through the contact page and we will take it from there.