AWS is not the easiest way to run WordPress. Managed WordPress hosts exist precisely because most site owners don’t want to think about EC2 instances, security groups, or PHP-FPM tuning. But if you need fine-grained control over server resources, plan to scale traffic unpredictably, or already run other infrastructure on AWS and want WordPress to sit alongside it, installing WordPress on Amazon Web Services gives you a level of control that shared and even most managed hosts don’t offer. This guide walks through the real steps, the parts that trip people up, and where AWS is genuinely the wrong tool for the job.
What AWS Actually Gives You Over Traditional Hosting
Amazon Web Services is a collection of cloud computing services rather than a single hosting product. For WordPress, the relevant pieces are EC2 (virtual servers), RDS (managed databases), S3 (object storage), CloudFront (a content delivery network), and Route 53 (DNS management). You can run WordPress entirely on a single EC2 instance, or split it across several of these services as traffic grows.
The advantage over a shared host is control: you choose the operating system, the PHP version, the web server, and how resources scale. The disadvantage is that you’re responsible for all of it. A shared or managed host patches the server, monitors uptime, and handles backups as part of the price. On AWS, that’s your job unless you pay for additional services or a managed WordPress-on-AWS provider to do it for you.
Before signing up, it’s worth being clear-eyed about AWS’s free tier. AWS overhauled its Free Tier structure in 2024, moving new accounts toward a credit-based model rather than a blanket “750 hours of a micro instance for 12 months” offer that older accounts remember. The exact credit amount and which services qualify change periodically, so check the current terms on AWS’s Free Tier page before you budget around it rather than relying on older articles (including this one) for exact numbers.
Step 1: Create an AWS Account and a Non-Root IAM User
Signing up requires an email address, a credit card, and phone verification. Once the account exists, resist the temptation to do everything as the root user. Create an IAM (Identity and Access Management) user with administrative permissions for day-to-day work, and enable multi-factor authentication on both the root account and the IAM user. This single habit prevents most of the account-takeover horror stories that circulate about compromised AWS accounts running up thousands of dollars in mining charges.
Log in going forward through the IAM user’s sign-in URL, not the root account. Keep the root credentials somewhere secure and use them only for tasks that genuinely require root, such as changing the account’s support plan or closing the account.
Step 2: Launch an EC2 Instance
From the EC2 dashboard, click “Launch Instance.” You’ll choose four things:
- An Amazon Machine Image (AMI): the base operating system. Amazon Linux 2023 and Ubuntu Server (22.04 or 24.04 LTS) are the two most common choices for WordPress. Ubuntu has a larger community of WordPress-specific tutorials; Amazon Linux integrates a little more tightly with other AWS services.
- An instance type: t3.micro or t3.small are reasonable starting points for a low-traffic blog. t2.micro still exists in the EC2 catalog but t3 instances generally offer better baseline performance for a similar price, so there’s rarely a reason to default to t2 today. You can resize the instance later without reinstalling WordPress, so don’t over-think this step.
- A key pair: AWS generates a public/private key pair for SSH access. Download the private key file (.pem) immediately, since AWS won’t let you download it again. Store it somewhere you won’t lose, and set its file permissions to read-only for your user (chmod 400 on Linux/macOS).
- A security group: this is AWS’s firewall. Open port 22 (SSH) restricted to your own IP address if possible, and ports 80 (HTTP) and 443 (HTTPS) open to everyone. Leaving SSH open to 0.0.0.0/0 is one of the most common misconfigurations that leads to brute-force login attempts within hours of launch.
Launch the instance, wait a minute or two for it to reach the “running” state, and note its public IPv4 address.
Step 3: Attach an Elastic IP
By default, the public IP address assigned to an EC2 instance changes if you stop and restart it. That’s fine for testing, but it will break your DNS records the moment you reboot the server for maintenance. Allocate an Elastic IP address from the EC2 console and associate it with your instance. Elastic IPs are free while attached to a running instance; AWS charges a small hourly fee only if you allocate one and leave it unattached, so don’t grab one and forget about it.
Step 4: Connect and Update the Server
Connect over SSH using the key pair you downloaded:
ssh -i your-key.pem ubuntu@your-elastic-ip
(The username depends on the AMI: ubuntu for Ubuntu images, ec2-user for Amazon Linux.) Once connected, update the package index and installed packages before doing anything else:
sudo apt update && sudo apt upgrade -y
This matters more than it sounds like it should. A freshly launched AMI is often weeks or months out of date by the time you provision it, and installing WordPress on top of outdated system packages is asking for trouble later.
Step 5: Install the Web Server, PHP, and Database
WordPress needs a web server, PHP, and a MySQL-compatible database. A typical LAMP stack (Linux, Apache, MySQL, PHP) on Ubuntu looks like this:
- Install Apache:
sudo apt install apache2 -y - Install MySQL or MariaDB:
sudo apt install mysql-server -y, then runsudo mysql_secure_installationto set a root password and remove default test accounts. - Install PHP and the extensions WordPress needs:
sudo apt install php php-mysql php-curl php-gd php-mbstring php-xml php-zip libapache2-mod-php -y - Restart Apache:
sudo systemctl restart apache2
Some administrators prefer Nginx over Apache for its lower memory footprint under concurrent connections, paired with PHP-FPM instead of mod_php. Nginx requires a bit more manual configuration for WordPress’s permalink rewriting, but it’s a reasonable choice if you expect meaningful traffic. Either stack works; don’t spend too long agonizing over the choice for a new site.
Create a dedicated database and database user for WordPress rather than using the MySQL root account in wp-config.php:
CREATE DATABASE wordpress_db;
CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'a-strong-unique-password';
GRANT ALL PRIVILEGES ON wordpress_db.* TO 'wp_user'@'localhost';
FLUSH PRIVILEGES;
Step 6: Download and Configure WordPress
Pull the latest WordPress release directly from the official source rather than trusting an old tutorial’s version number:
cd /tmp && curl -O https://wordpress.org/latest.tar.gz && tar -xzvf latest.tar.gz
Move the extracted files into Apache’s web root (typically /var/www/html), then copy wp-config-sample.php to wp-config.php and fill in the database name, username, and password you created above. While you’re editing the file, generate a fresh set of authentication keys and salts from WordPress.org’s secret-key generator and paste them in; this replaces the placeholder values and hardens session security.
Set ownership and permissions so Apache can write to the directory (needed for updates, media uploads, and plugin installation) without making the whole site world-writable:
sudo chown -R www-data:www-data /var/www/html
sudo find /var/www/html -type d -exec chmod 755 {} \;
sudo find /var/www/html -type f -exec chmod 644 {} \;
Step 7: Finish Setup in the Browser
Visit your Elastic IP address (or domain, once DNS is pointed) in a browser. WordPress’s five-minute installer will prompt for a site title, admin username, admin password, and email address. Choose a genuinely random admin username rather than “admin,” since that username is the first thing every automated login-guessing script tries.
Step 8: Point a Domain at the Server
If you want a real domain rather than the raw IP address, you have two options. You can manage DNS through your existing registrar by creating an A record pointing at your Elastic IP, or you can move DNS management to Amazon Route 53 and create the record there. Route 53 costs a small monthly fee per hosted zone plus a per-query charge, so it’s worth it mainly if you’re already consolidating other infrastructure on AWS or want programmatic DNS control through the AWS API.
Step 9: Secure the Site With HTTPS
An unencrypted WordPress login page is not something to leave running for more than the few minutes it takes to fix. The simplest free option is Certbot, which automates obtaining and renewing a Let’s Encrypt certificate:
sudo apt install certbot python3-certbot-apache -y
sudo certbot --apache -d yourdomain.com -d www.yourdomain.com
Certbot configures Apache to serve HTTPS and sets up automatic renewal via a cron job or systemd timer, so you shouldn’t need to touch it again barring a major server migration. If you later put a load balancer or CloudFront in front of the instance, you’d instead issue the certificate through AWS Certificate Manager, which integrates directly with those services.
Backups: Don’t Rely on Good Intentions
EC2 instances don’t back themselves up. Two layers are worth setting up on day one. First, use AWS Backup or scheduled EBS snapshots to capture the whole server volume; this protects you against a botched update or a corrupted filesystem. Second, run a WordPress-level backup plugin that exports the database and uploads to S3 on a schedule, which protects you at the content level and makes it far easier to restore a single post or a media file without rolling back the entire server. Test the restore process at least once. A backup nobody has ever restored from is a hope, not a plan.
When to Reach for RDS, CloudFront, and Load Balancing Instead
A single EC2 instance running Apache, PHP, and MySQL together is fine for a low-to-moderate traffic site. As traffic grows, the database is usually the first bottleneck. Moving the database to Amazon RDS (a managed MySQL or MariaDB service) offloads that work to a separate instance, gives you automated backups and point-in-time recovery, and lets you scale the database independently of the web server. It costs more than running MySQL on the same box, so it’s worth doing when you actually need it rather than as a default from day one.
CloudFront, AWS’s CDN, caches static assets (images, CSS, JavaScript) at edge locations closer to visitors, which reduces load on the origin server and speeds up page loads for a geographically spread audience. For a site that outgrows a single instance entirely, an Application Load Balancer distributing traffic across multiple EC2 instances in an Auto Scaling group is the next step, though at that point most teams either hire someone with AWS operations experience or switch to a managed WordPress-on-AWS provider that handles this layer for a monthly fee.
The Simpler Alternative: AWS Lightsail
If everything above sounds like more infrastructure than you want to manage, Amazon Lightsail is worth a look before committing to raw EC2. Lightsail offers a pre-built WordPress blueprint (via a Bitnami image) that launches with WordPress, Apache, and MySQL already installed and configured, for a flat monthly price that bundles compute, storage, and a data transfer allowance. It’s less flexible than a hand-built EC2 stack, but it removes most of the steps above and is a reasonable middle ground between AWS’s raw building blocks and a fully managed WordPress host.
Estimating What This Actually Costs Per Month
One of the most common surprises for people moving from a flat-rate host to AWS is the bill’s shape: several small line items instead of one predictable number. A rough monthly estimate for a small WordPress site on a t3.small instance, running its own MySQL rather than RDS, looks something like this once any free-tier credits expire: the EC2 instance itself, a general-purpose EBS storage volume (typically 20 to 30 GB is plenty for WordPress plus a media library of modest size), and outbound data transfer, which is free up to a monthly allowance and then billed per gigabyte beyond it. Add Route 53 if you’re managing DNS there, and CloudFront if you’ve put a CDN in front of the site. None of these individually costs much for a low-traffic site, but they add up in a way a single “$8/month shared hosting” invoice never made you think about.
If you add RDS for the database, budget for a second, separate line item roughly comparable to the EC2 instance cost, since you’re now running two managed resources instead of one. This is exactly why the advice above is to add RDS when you have a concrete reason (database load becoming a bottleneck, wanting automated point-in-time recovery) rather than by default. Set a AWS Budget alert early, even a simple one that emails you at a dollar threshold, so an unexpected traffic spike or a misconfigured Auto Scaling group doesn’t turn into a surprise invoice at the end of the month.
Common Installation Problems and How to Fix Them
A handful of errors account for most of the trouble people run into when they first install WordPress on AWS:
- “Error establishing a database connection”: almost always a mismatch between the database name, username, or password in wp-config.php and what you actually created in MySQL, or MySQL simply isn’t running. Check the service status with
sudo systemctl status mysqlbefore assuming the credentials are wrong. - 500 Internal Server Error immediately after install: frequently a missing PHP extension. Confirm that php-mysql, php-xml, and php-curl are all installed, and check Apache’s error log at
/var/log/apache2/error.logfor the specific missing module. - Can’t connect over SSH: almost always a security group rule blocking port 22, an incorrect key file, or wrong file permissions on the .pem file. AWS requires the private key file to be readable only by your user; a too-open permission setting will cause SSH to refuse the connection outright.
- Site loads over HTTP but not HTTPS after running Certbot: check that port 443 is open in the security group. Certbot configures Apache correctly but can’t open a port AWS’s firewall is still blocking.
- Uploaded media fails or plugins can’t self-update: almost always a file ownership or permissions problem, not a WordPress bug. Re-run the chown and permission commands from the setup steps above.
Caching and Performance Tuning
A single small EC2 instance running PHP on every request will feel slower than equivalent managed hosting unless you add caching. A page caching plugin (several free options are available in the WordPress plugin repository) that serves static HTML for anonymous visitors removes the PHP and database work from the vast majority of requests. Beyond page caching, an object cache backed by Redis, either self-installed on the instance or run through Amazon ElastiCache, speeds up database-heavy operations like WooCommerce carts or membership sites with frequent logged-in activity. Enabling gzip or Brotli compression in Apache or Nginx and setting far-future cache headers for static assets rounds out the basics. None of this is AWS-specific advice exactly, but it matters more on a modest EC2 instance than it would on hosting that already bakes server-level caching into the platform.
Ongoing Maintenance You’re Now Responsible For
This is the part managed hosting quietly does for you and self-managed AWS does not. Put a recurring calendar reminder, at minimum monthly, to apply operating system security patches (sudo apt update && sudo apt upgrade), review WordPress core, theme, and plugin updates, and check that automated backups actually ran and are restorable. Set up basic monitoring through Amazon CloudWatch so you get an alert if CPU, memory, or disk usage crosses a threshold rather than finding out the server ran out of disk space when the site goes down. None of this is exotic, but skipping it is exactly how a well-configured server from launch day turns into a security liability eighteen months later.
Is AWS the Right Choice for Your Site?
AWS makes sense when you need infrastructure control, plan to integrate WordPress with other AWS services, or expect traffic patterns spiky enough that pay-for-what-you-use pricing beats a fixed hosting plan. It makes less sense for a straightforward blog or small business site where a managed WordPress host will patch, back up, and cache the site for a predictable monthly fee without requiring anyone on the team to understand security groups or PHP-FPM pools. Neither choice is wrong; they’re solving different problems. If you’re unsure which camp you’re in, start with Lightsail or a managed host, and migrate to full EC2 only once you can point to a specific limitation you’ve actually hit.
Interesting Reads:
How to Start Selling online courses from your website?