How to Host Your WordPress Site on Multiple AWS Server Instances

You’ve almost definitely heard about Amazon Web Services. And, given that you’re on this site, I’m going to make the obvious assumption that you’ve heard about WordPress, too. But what you might not have heard about is combining WordPress with Amazon Web Services (AWS) for web hosting.

Articles about hosting WordPress on shared hosting, CPanel hosting, managed hosting and what have you are a dime a dozen. Yet AWS is yet another infrastructure that can be used to host your WordPress site. Not only that, but given that an AWS infrastructure is elastic, it’s a great place to set up a WordPress installation that can be autoscaled to meet demand.

So in this article, let’s get down to the business of setting up a WordPress site on multiple instances of AWS servers.

Note: Once you know how to set up a WordPress installation on AWS, look out for articles coming soon about setting up WordPress for autoscaling to multiple instances to be able to handle spikes in traffic.

Step 1: Registering an AWS Account

First things first: If you still haven’t ever tried Amazon Web Services, head to and click on Create an AWS account.

You can use your regular Amazon account to log in, but following the normal login you’re going to have to go through a process for verifying that there is an actual human behind the person registering the account. You’ll go through the process of filling in your details, actually verifying the account through a phone call, setting up a credit card for billing purposes and a whole host of other standard registration stuff.

Once you get through the registration process, you should finally get access to the AWS Services Dashboard, which looks a little bit similar to this:

Wow – which server do I choose?
Wow – which server do I choose?

If it’s the first time you’re getting access to this it’s a little overwhelming. There’s so much stuff to choose that you’ll actually get pretty confused if you’re not used to this.

Let me run you through a few quick explanations of the most common instances you can use. Truth be told, I don’t even know what half of the services mean, but doesn’t have to worry me (or you) much!

EC2 – the Amazon Workhorse

Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides resizable compute capacity in the cloud. It is designed to make web-scale cloud computing easier for developers. In more simple terms, this is computing power on tap. You can simply start instances of virtual machines here which can be used for whatever you need to run.

S3 – Storage on Demand

Amazon Simple Storage Service (Amazon S3) is object storage (or disk space) with a simple web service interface to store and retrieve any amount of data from anywhere on the web. It is designed to deliver 99.999999999% durability, and scale past trillions of objects worldwide. Simply put, it is very reliable and can get very very big (should you need to). Services such as DropBox are powered by S3.

RDS – Relational Database in the Cloud

Amazon Relational Database Service (Amazon RDS) makes it easy to set up, operate, and scale a relational database in the cloud. Amazon RDS provides you six familiar database engines to choose from, including Amazon AuroraPostgreSQLMySQLMariaDBOracle, and Microsoft SQL Server.

CloudFront – Amazon’s Content Delivery Network

Amazon CloudFront is a global content delivery network (CDN) service that accelerates delivery of your websites, APIs, video content or other web assets. It integrates with other Amazon Web Services products to give developers and businesses an easy way to accelerate content to end users with no minimum usage commitments.

SES – Simple Email Service

Amazon Simple Email Service (Amazon SES) is a cost-effective email service built on the reliable and scalable infrastructure that developed to serve its own customer base. With Amazon SES, you can send and receive email with no required minimum commitments – you pay as you go, and you only pay for what you use.

Step 2: Designing Your AWS WordPress Infrastructure

How do these servers relate to our AWS WordPress setup?


We will be using EC2 to create a web server instance to power our AWS WordPress installation. We can also use this to install a MySQL database to power our WordPress database.


RDS services are optimized database instances for running database based applications. We will be using one of these instances for our database since these are highly optimized for performance and scaling.


A CDN goes hand-in-hand with WordPress performance, so using CloudFront will give us a CDN powered by Amazon Web Services for our WordPress site.


Our media will be stored on S3 instances and distributed via the CloudFront CDN.


Whilst you may choose to use your EC2 instance for sending mail, we typically opt to use Simple Email Service instances because, once again, since these are optimized for sending email, we won’t run into such issues as bad neighborhoods and other mail delivery issues. This is particularly relevant if you plan to send mass mailings.

Designing Your Infrastructure: Scaling Out vs Scaling Up

There are hundreds of ways you can set up your WordPress infrastructure. If you want a small instance to host your small site, we’re going to discuss LightSail later on, which is Light VPS which Amazon have launched very recently. You can also set up all of your WordPress instance including server, PHP and MySQL database on a single EC2 instance. However, this is not going to take your performance very far – once you hit the physical server limit, you’re done.

So what’s this scaling out vs scaling up jargon? There are two primary ways of increasing the throughput / performance of your website.

  1. Scaling up aka scaling vertically – this means increasing the actual hardware / memory resources used to power your website. Essentially, you increase the RAM, CPUs and other hardware allocated to your website. If you’re on a shared server, you go to a VPS. If you’re on a VPS, you increase the RAM and / or CPUs allocated to your server. If you’ve reached the maximum hardware on shared hosting, you buy a dedicated server. When you’ve exhausted the dedicated server, you switch to a more powerful server with better hardware.
  2. Scaling out aka scaling horizontally – as I’ve hinted slowly in the previous paragraph, you might notice that scaling up has an actual physical limit – the hardware running your website. If your website is exhausting the physical hardware its hosted on, you’ve run into a problem. Scaling out, rather than throwing more hardware at the server, throws more servers at the website. Essentially, we farm out each component of the website to a different server. That, of course, allows our website to handle a much heavier load because we have multiple servers handling the load.

Our setup is designed with scaling out in mind. For this reason, we’re going to use different instances for each component of WordPress. This will allow us to scale up (increase the computing power) and scale out (increasing the number of instances doing the work) as part of our infrastructure to handle additional load.

In particular, we’re going to use multiple web servers to be able to handle large amounts of traffic. We will also be setting up a load balancer, which will determine which server to send requests to.

This means we’re going to be creating at the very least the following difference instances:

  1. A database component using RDS
  2. (Multiple) WordPress installation component(s) using EC2
  3. A mailing service component using SES
  4. (Optional) A CDN component using S3 and CloudFront

There are also multiple ways of actually designing this infrastructure. AWS also has pre-defined Application Containers. The idea is that certain specific common applications development environments have pre-defined instances which can be activated at the click of a button.

A word of warning: Amazon has so many possible configurations and setups possible, that it is quite difficult to understand them without lots of experience, let alone explain them in a single blog. For this reason, we’ll be taking some shortcuts and not explain everything in detail. For further reading, refer to the AWS documentation.

Scaling Out a Database

Scaling out a database to multiple instances is possible, however, the complexities of performing such a configuration are way beyond such a blog.

We’re thus going to restrict our infrastructure to a single instance of the database. Now, although this may seem like a limitation, in reality, having a server instance dedicated solely to the database means that the website would be able to handle significant amounts of traffic.

We will also be using Aurora DB, Amazon’s own build of MySQL which is optimized for performance and for the cloud.

This, coupled with the fact that our database instance can get pretty high-speced in terms of performance should ensure that the database would never become a real bottleneck.

To ease the load of the database components further, one would also enable WordPress caching to ensure that database hits are kept to a minimum.

All-in-all, our decision to keep a single instance of the database should be sufficient for most website loads, unless your website will be handling tens of thousands of hits per second. In that case, you can probably afford to hire an expert to configure your website!

Step 3: Setting up Your WordPress Database Instance

To set up a WordPress installation on Amazon Web Services, you’re going to need a few components. The first you’re going to need is a database service, so go to RDS and launch a MySQL instance.

Create a MySQL AWS Instance

If you’re just testing out stuff, you can choose to create a DEV/Test environment. On the other hand, if this is your production environment, you have two choices:

Option 1: MySQL

This uses a multiple Availability Zone (i.e. you will have a Primary instance and a secondary instance on standby in case of failure of the primary instance). The creation and failover to the secondary standby instance is completely transport – it is of course designed for High Availability and Provisioned IOPS Storage for fast, consistent performance.

Option 2: Aurora DB

This is the recommended configuration. Whilst this is not strictly MySQL, Aurora DB is a custom build created by Amazon, specifically optimized for higher performance and better reliability. Tests have shown that instances of WordPress on Aurora DB run up to 3 times faster. This is also classified as Enterprise level performance, so if you want absolutely top-notch performance, you should go for this option.

Use Aurora DB for top notch performance.
Use Aurora DB for top notch performance.

Once you’ve selected Aurora DB, you need to specify some basic configurations. You’ll need to figure out what the right DB Instance Class for you is. Besides actual throughput, you’ll also need to consider DB Instance pricing.

AWS Aurora database configuration.
AWS Aurora database configuration.

Take note of the of settings you are using, particularly names, because we’re going to need them later on when we’re creating the WordPress instance.

Step 4: Creating and Setting up Your Web Server Infrastructure

Once our database has been created, we’re now going to set up our web server. We’re be using an EC2 instance to run our WordPress web server.

Once again, you’ve got various options to install WordPress on an EC2 instance. If you head over to the AWS MarketPlace, you’ll find preconfigured instances of WordPress which you can get up and running in next to no time. These come with the added benefit of using a tried and tested configuration.

The AWS MarketPlace also allows you to install very specific WordPress configurations. For example, if you want to push performance to the limit, you might want to use an Nginx web server rather than an Apache web server. There are various Nginx configurations available on the AWS Marketplace.

To create a new EC2 instance, access the AWS Management Console and click the EC2 tab:

  • Choose an Amazon Machine Image (AMI) in the wizard: a good choice for WordPress would be Amazon Linux AMI 2016.09.0 (HVM), SSD Volume Type 64-bit.
  • Choose the Instance types details: Once again, this is something that depends on two main things: the expected traffic, and consequently, the throughput and performance you need, together with what you are prepared to pay for them. You can learn more about EC2 Instance types here. Select the Instance Type you want to use.
  • Create a new key pair. Enter a name for your key pair (i.e. WordPress_AWS) and download your key pair (i.e. WordPress_AWS).
  • Select the quick start security group.
  • Launch your instance.

Woohoo! You’ve got our main components setup!

Setup correct inbound and outbound rules to be able to access the server through HTTP. Using the security groups, you can edit the inbound and outbound rules to add firewall rules as necessary to allow traffic to the various instances you have created.

Allowing inbound traffic.
Allowing inbound traffic.

Step 5: Install Apache Web Server + WordPress

So now that our actual server instances are up and running, we need to get all of our software components in place.

Install the Web Server

We’re going to skim through a few steps which we’re going to assume are pretty standard stuff.

A SSH into EC2 instance.
A SSH into EC2 instance.
  1. SSH into your web server instance (EC2)
  2. Install the Apache web server (sudo yum install httpd)
  3. Start the web server server (sudo service httpd start)

Test whether the server is up and running (Access – you’ll actually need to enter the public DNS name of your EC2 instance). If you are unable to connect you’ll need to make sure that the security groups have been set correctly to allow inbound HTTP traffic.

Install PHP on the Web Server

  1. Install the PHP package specifically for MySQL  (sudo yum install php php-mysql)
  2. Restart the Apache Web Server (sudo service httpd restart)
  3. Create a test.php file which simply runs phpinfo()

type i to start the insert mode in VI

Type <?php phpinfo() ?>

Type :wq to write the file and quit vi

Open a browser and access test.php to test your PHP installation: (Use your actual public DNS name).

Confirmation that PHP is up and running.
Confirmation that PHP is up and running.

Great, so now we know our web server is up and running with PHP5.

Download, Install and Setup WordPress on the Amazon Web Server

Given that PHP is working on our web server, we need to download and install WordPress. Let’s download and configure our WordPress installation.

  1. Go to the public HTML folder of the server where we will be installing WordPress (cd /var/www/html)
  2. Download the latest version of WordPress (wget
  3. Uncompress the file we’ve downloaded (tar -xzvf latest.tar.gz)
  4. This will uncompress WordPress in its a directory called “wordpress” directory. We will rename this to something which makes more sense, so that we can set up more stuff on the web server. Let’s rename it to blog. (mv wordpress blog)
  5. Create the WordPress wp-config.php file and modify the database connection parameters as follows – of course, you’ll need to use your own set of parameters which you’ve used when creating the Aurora DB instance

Type “i” to start insert mode.

Edit with the correct parameters.

Type “:wq” to write the file and quit “vi.”

If you’re not sure of what values you’ll need to enter, you can find the details you’ll need to use by using the details found on your Aurora Database instance.

AWS Aurora database settings.
AWS Aurora database settings.

Open a Browser and access your new WordPress website blog:  (Use your actual public DNS name).

This should trigger the WordPress configuration process. If you get an error establishing a connection to your database, you either have some of the database details which are incorrect or possibly you need to ensure you’ve setup a correct security group with the correct firewall rules (this is a bit outside the scope of this blog).

Run through the 5-minute install (which should actually take much less, since everything should be nearly done), setup a WordPress administrator, a strong password and you should be good to go.

Once you’re done you should get a nice fresh, new install of WordPress!

Step 6: Setup an Amazon Mailer (SES) Instance with WordPress

SES or Simple Email Service is just that – a way of sending email where you pay as you go based on the volumes you send. If you’re planning to send newsletters or other mass mailing to thousands of users, SES is a good, reliable, cheap choice, if you just need a volume sending server. If you’re looking at more complex stuff for sending emails, we make a few great recommendations for growing your email list and sending emails here.

To be able to send emails using SES, you’ll need to verify that you own and are able access to the domain you’ll be sending emails from. You can do this by creating DKIM DNS entries to your domain.

Follow the AWS SES domain verification process:

AWS Verify SES domain

Once you’ve created and verified the domain through your DNS settings, you’ll need to setup an identity (email address) to send from. Again, there is a verification process associated with creating an identity, so follow that through to verify you have access to the email address.

Verify AWS SES identity

We’re not ready yet – we need to create credentials to be able to access the SES server via SMTP. To do this, go to SMTP Settings and create a new set of SMTP credentials of our WordPress website.

AWS SES SMTP credentials.
AWS SES SMTP credentials.

This will involve creating a new IAM user which will have an SMTP Username and SMTP password.

Now, using SMTP with WordPress requires the installation of the WP Mail SMTP Plugin.

Copy the username and password and put them directly into the WordPress SMTP settings plugin details. You will only be shown these details once – a safety precaution meant to keep access to the SES servers limited.

AWS SMTP Settings

Step 7: Serve WordPress Media from Amazon’s CloudFront CDN (Optional, But Recommended)

Since we’re on the subject of boosting performance, integrating Amazon’s CloudFront CDN would help scale out our setup further, allowing the site to achieve better levels of performance. As we’ve discussed on this blog (and elsewhere), a CDN gives your website a performance boost by serving static, heavy resources from a location which is closer to your website’s visitor.

To integrate the WordPress site with CloudFront, you can use the Amazon S3 and CloudFront WordPress plugin, to store the media folder onto Amazon S3 and then serve it through Amazon CloudFront. This has been already been covered in detail by our very own Daniel, so have a look at How to Move WordPress Media Folder to Amazon S3.

Step 8: Connect EC2 Instance with Your Domain

To be able to use the AWS WordPress installation with our domain, we need to associate a public IP address to our instance and then map our domain name to that IP address.

Associate an IP Address to an EC2 Instance

  1. In the AWS EC2 Management Console, click Elastic IPs (left navigation bar)
  2. Allocate New Address, and confirm by clicking the Allocate button
  3. Right-click the newly allocated IP address and select Associate in the popup menu. Select the WordPress EC2 instance we created above and click Associate
Associating an AWS Elastic IP to instance.
Associating an AWS Elastic IP to instance.

Setup DNS records for your domain with Route53

Route53 is a DNS service from AWS, which will essentially be used to translate the domain name to the elastic IP we have just created. It’s quite cheap, at about $.50/month.

  1. Create a hosted zone, with the name of your domain (without www). This will create four name servers, one master and three slaves.
  2. While still in the hosted zone, unselect all records and then click on Create Record Set. Create a new A record (for example pointing to the Elastic IP record you created in the previous step.
Create DNS A Record to Elastic IP


With the above, we now know that a domain lookup of will resolve to the EC2 elastic IP.

The final step is to map your domain from the registrar to your Route53 name server. In GoDaddy or wherever you have registered your domain to point to the name of your master DNS server (e.g.

You’ll need to wait a few hours (sometimes up to 48 hours) to check whether your IP is resolving correct. You can check the progress of the domain name propagation using a service such as What’s my DNS.

Once DNS has propagated correctly, go to WordPress General Settings in the WordPress management console and make sure the WordPress Address and Site Address are specified correctly using your domain name.

Using Amazon LightSail VPS

A few weeks ago, AWS launched a new service, LightSail. Essentially, these are virtual private servers priced at a very cheap $5 per month.

  1. You simply click on the instance of the application you’d like to host.
Create a AWS LightSail instance

2. Select how much resources you want to allocate.

Choose LightSail plan

And AWS LightSail will spin up an instance for you with WordPress and a database pre-installed. You can then SSH into as a regular EC2 instance and tweak as necessary.

AWS WordPress LightSail Instance.
AWS WordPress LightSail Instance.

Phew, We’re Done! But Are We Really…?

That was pretty taxing to set up! Getting it all up and running smoothly is not for the faint-hearted. Keeping everything up and running in tip-top shape is going to take a continuous effort of monitoring states of the various instances, making sure we’re not running up costs on large instances. We also need to monitor whether the servers are coping with demand – where necessary we can stop an instance and allocate more resources to it as necessary.

We’ll also be discussing in another post, how to actually setup autoscaling on AWS such that traffic spikes will automatically create new instances of the web server we have created to be able to handle loads as necessary.

Why Not Leave It All to the Experts?

As you might have seen from the above, setting up and maintaining an AWS WordPress infrastructure is not an easy task. Keeping it up and running is also going to need constant investment in time, and of course the billings on AWS itself.

Whilst AWS gives you quite a lot of control, literally you can configure bits and pieces as necessary for your infrastructure, we do believe this is only for those who have very specific needs.

On the other hand if you run an enterprise website and want top performance right off the bat, why not go for managed WordPress hosting with WPMU DEV (launching to the public in 2017) or any of the other managed WordPress hosting companies we’ve reviewed?

David Attard
Have you worked with AWS hosting before? What are your tips for making the most of this hosting? Let us know in the comments below.

24 Responses

    • Support/SLS MockingJay

      Hi Nicolas,

      Currently, we don’t have plans for any simple/cheap hosting, one reason is because there’s already a lot of extremely cheap & moderately priced hosting available and it is very difficult to compete in that market area.

      If we do reconsider this at some point in the future, we will certainly put out an announcement if we decide to go down that road.


  • Rod
    Site Builder, Child of Zeus

    Hi WPMU Dev members,

    I am verifying AWS hosting since quite a while holding an AWS account for many years. Since the beginning of this month after finishing and testing development of my biz model with WP on a dedicated server I have taken action to setup my final production environment totally based on AWS infrastructure, except DNS and mail. DNS goes with Cloudflare, mail with G-suite. The domain is strictly configured to SSL.

    To launch an r3.large EC2 instance I used an AWS marketplace Pro package of Parallels Plesk, which is connecting to the smallest Aurora RDS instance to test the water. Media assets can go to S3, configured with AWS Cloudfront AND Cloudflare already. Caching is configured with the WPMU Dev Hummingbird plugin integrating Cloudflare and Comet Cache plugin for advanced onsite caching also integrated with AWS Cloudfront. My website is already multisite configured and administered by WPMU Dev dashboard plugin and will hold a marketplace for many subdomains based related sites.

    Up to this point it took almost three weeks to get up and running with monthly costs of some $250 on my AWS account including $29 for upgraded developer support. This might be a no-brainer for future issues because I bet almost anyone will run into its individual configuration scenario and you’ll enjoy AWS support so much. They REALLY care straightforward until your problem is solved. I even was able to combine it with Parallels Plesk support stuff, which is also excellent. This was especially necessary i. e. as I had to solve an FTP connectivity issue via FileZilla because SELinux was enabled by default and avoided proper retrieving directory listing.

    Regarding reducing monthly costs summing up at my AWS account I have already switched to ‘Reserved Instances’ for EC2 and RDS. For production environments, this is highly recommended because it saves up to more than 30% of fees.

    I am looking forward to a very prosperous and interesting discussion in here. AWS WP hosting has definitely arrived.


  • Hi Rod,

    that’s a great AWS setup you’ve there. I’d be really interested in having a direct look at it if you would be able to do that.

    I’d love to know what kind of performance you are able to achieve with this setup. If you could share some loading numbers during peak traffic, it would be a good real-world example of what kind of results can be achieved with this type of setup.

    Thanks again for sharing.


    • Rod
      Site Builder, Child of Zeus

      Hi David,

      thanks for the feedback. I’ll love to share all upcoming experience with this setup, especially when it comes to scaling. Which will be for sure. This brings me to the underlying story of it. As I said I was doing all my tests of developing and transforming the business model on a dedicated server before I decided to migrate completely to AWS for the production environment. This server had more capacity as the one Anthony mentioned in his blog post of 27th January. It was a machine with 24 virtual cores and a whopping 120 GB RAM with four of the fastest 250GB SSD drives. And WP was powered by pure Nginx FPM and PHP 7.x. BUT, I got the machine meltdown various times. Without any traffic! The reason was because it had large import routines of products running through WooCommerce for hours and at the same time all products got synced every 15 minutes with regular cronjobs.

      I was talking to many system engineers at last year’s AWS Po-Up loft and we all agreed on, even when importing of products will finish once, the synchronization part would remain and expected traffic would replace the import routine’s impact. Further on, large amounts of media files need to be offloaded and best stored on S3 buckets which are directly integrated with Cloudfront AND Cloudflare. Meaning kind of double power regarding any CDN issues. Additionally, there is always the possibility to extend functionality with special Lamda functions such as taking automated snapshots of the recent machine image which gets deleted weekly again after the latest was saved. And last but not least the fully integrated Aurora database engine which does not need to be reached over the Internet endpoint. I can’t wait to see it in action under heavy traffic peaks. In a summary, it might even make sense one day to continue with specially designed AWS Cloudformation templates for replication of infrastructure by code.

      Well, coming soon. Meanwhile, I was busy to setup my WP and Multisite environment and get it closed to the UI and UX status I try to perform. It will take me about two more weeks so by the end of the month I will be able to soft launch and provide the URL with further details of where I want to go to with this concept.

      I’ll keep you updated.


      • Rod
        Site Builder, Child of Zeus


        after testing the workloads of import scripts and/or sync cycles I detected a very serious bottleneck within my configuration. The CPU usage was significantly increasing when starting import scripts with large amounts of items for hours. This was caused by the Apache webserver configuration using Nginx just as a proxy server and due to a smaller ‘r3’ EC2 instance to test the water. For this reason, I decided not to open up the floodgates yet to SEO crawlers because doing that would result in additional traffic peaks impacting the performance of the site even more.

        I decided to reconfigure the whole production system using just the commercial version of Nginx which is available via AWS marketplace package named Nginx Plus. In June they will add memory optimized ‘r4’ EC2 instances to their available AMI list, which are my favorite EC2 instances since they got released by AWS a couple of months ago. At the moment I maintain the recent configuration for further imports and site design tasks. As soon as I am going live I’ll let you know.

  • Hi Raghav,

    an interesting question – hardware is hardware, no matter where it is hosted really and truly. Whether it’s hosted on AWS, DigitalOcean or any other site. To me it’s all “the same” – at a basic level the differences between cloud hosts are going to be minimal in reality, they’re all run a flavour of an OS.

    It’s typically what they build on that which marks the difference between one host and another.

    With regards to whether you choose a VPS versus AWS – again, it very much depends. With a VPS you are going to have good performance at a predictable price. Yet the implementation of VPS differs on different hosts. Some give you burstable CPU and RAM meaning you will be able to handle traffic spikes.

    Others will scale up specs (and price) to handle spikes in traffic.

    I do believe though that a good set of VPS servers will also scale up WordPress very nicely. The thing with AWS is that they have some pretty good optimization already in place (such as the Amazon Aurora). You will probably not get that on VPS but there are still other PROs to setting it up on multiple VPS instances.


  • The Incredible Code Injector

    I currently have my own Managed Service hosting w/ 1and1 using Plesk. The specs are as the following:

    Processor: AMD Opteron™ 6338P,
    Speed: 12 Cores x 2.3 GHz,
    RAM: 32 GB DDR3 ECC,
    Hard-disk space: 2,000 GB (2 x 2,000 GB SATA),
    RAID: Software RAID 1,
    SSD: Optional: 240 GB (2 x 240 GB SSD) Intel® S3500,
    Bandwidth transfer: Unlimited transfer,
    Operating System: Linux, Windows, 1&1 Managed,
    1&1 Firewall: External Cisco-based IP firewall,
    IP address: Own static IP adress,
    Management software: Plesk 12.5 (resellable, unlimited domains),
    Access: Full root/administrator access,
    Port speed: 100 Mbit/s,
    Domains: 1 included, 1&1 Managed Server

    I’m paying 199.99 per month for this. Would there be any incentive in going to AWS hosting vs my current setup? Pros vs Cons?

    Others things to note: I house about 10sites WP sites and 1 php site. I’m not having any performance issue so why would one go to amazon for hosting options?

    • Hi Anthony,

      that looks like a pretty high-specced service to me – are your sites getting heavy traffic? I’m sure it’s going to get pretty close to that (maybe even more expensive) to run the same kind of specs on AWS. With Amazon, you pay a little bit for everything, but it all adds up. For example, if you have heavy bandwidth sites, with AWS you pay per Gb … it’s difficult to make a good judgement.


  • Site Builder, Child of Zeus

    I’d really like to give AWS a test drive, though it’s sounding like the cost is in the $100+/mo range (a bit much for, pardon the metaphor, a joyride). Question for those with AWS experience: if I’m just experimenting with the platform and not pushing any significant traffic, could I get the cost down to the $25-40/mo range? In advance, many thanks!

    • Staff

      Sorry David, I mean no disrespect toward your article, it is great. :-)

      Hi Mark if you are looking at experimenting (depending on your skill level). Digital ocean might be a better option. You can ‘spin up’ a server in 1 minute and costs start at $5 a month depending on how much storage you want. They work with pre designed containers that will include for example WordPress included. You can destroy and build as many times as you want. It is very easy to do. Hopes this helps.


      • m33
        Site Builder, Child of Zeus

        Just a heads up: I use Digital Ocean for a multisite network. I have been getting the “error establishing database connection” quite a bit lately.

        It ALWAYS happens when I’m sleeping so I usually wake up to angry clients (exciting!)

        In fact, it happened this morning around 3:39 am. Coincidentally, I saw a huge spike in CPU, Disk and RAM usage right before the outage. The logs don’t show anything in terms of usage or plugin issues. It works perfectly during the day when we’re getting the most traffic.

        It’s not XMLRPC attack- the logs show that only valid search bots are using it. Besides, I’ve blocked xml.

        But it’s still happening. And apparently, it’s happening to a lot of users:

        Which is why I started searching and found this article. Seriously considering AWS at this point. I hate to move an entire network but I can’t keep having unexplained outtages. I have note into DO to see what the issue is.

        @david I’d love to see more on how to run a load balancer etc as well as maybe using lightsail and how a wordpress network might be able to take advantage of lightsail pricing but still use some of the aws enterprise features.

        • Hi m33

          I feel your pain – waking up to downtime and frustrated clients is a nightmare of epic proportions – and that is the last thing you expect from your hosting service.

          If it were happening to me they’d be getting an earful!

          Yeah, migrating is a bitch (excuse my french), yet sometimes it’s the right way to go – just plan it out so you can do it as cleanly as possible if it becomes absolutely necessary.

          Re load balancing and stuff, I’ll have to set some time aside to work on this article because there’s been much demand for it!

          Wishing you luck with the resolution of your issues!


  • New Recruit

    I gave a talk about running a high-availability set-up on AWS at WordCamp Baltimore last year ()

    A couple of points:
    – AWS Aurora might be more performant but it isn’t available in smaller database sizes. I went with MariaDB + the smallest ElastiCache Redis instance. I use WP Redis object cache plugin to improve performance and reduce the load on the database.
    – KeyCDN is half the price as CloudFront ($0.04/GB vs. $0.085/GB) and works just as well for most needs. You can point KeyCDN at your S3 bucket and off you go.
    – You mentioned going with a load balancer in the intro but didn’t actually go into the details of setting one up. One advantage of going with a load balancer is it is required to use Amazon’s Certificate Manager service (think AWS’ LetsEncrypt for free SSL certs). Secure requests are terminated at the load balancer level which reduces some load on your server(s).
    – Another fun challenge not covered here is figuring out how to deploy code changes to your instances (assuming any custom development) and back ups. I briefly go over deploying code changes in my talk and highlight our deployment pipeline.
    – When you work with multiple servers, full page caching becomes tricky. You can’t generate static HTML that you keep on each server because then you need to worry about keeping the cached files in sync. I use’s script to set-up servers. It includes an option to do full page caching via Redis. It works quite well and you can have all of your instances point to your ElastiCache instance so they all use and update the same cache files. Works great.
    – Billing wise I would add 10-20% extra to your expected monthly budget for bandwidth/usage gotchas. AWS is pay for what you use and its really hard to calculate the usage portion of your bill.
    – Pricing wise, a minimum high availability set-up runs about $220/month for (2) t2.small EC2 instances (reserved instances for a discount), the smallest ElastiCache instance, and the 2nd smallest RDS instance running MariaDB. This can also fluctuate depending on your traffic.
    – AWS can be intimidating but it can also be a lot of fun learning how it all works and fits together. I would encourage everyone to at least poke around and play with it a little bit.

    • Hi Kingkool,

      thanks very much for your very informed response. By no means do I claim to be an expert on AWS, I chose to take certain shortcuts. I’d be really really interested in having a look at your own talk, I’m sure I can learn a lot from it.

      1. Re Aurora and MariaDB, you’re right – I chose to go for an AuroraDB mostly for achieving top performance.

      2. Once agree, I agree with you, AWS’s CDN (or bandwidth cost in general) is one of the most expensive around, so you’ll surely find a better deal elsewhere.

      3. Yes, I started with the intent of setting up a load balancer but opted out for the sake of reducing the complexity of this specific article – I should be following this up with another setup which does use load balancers.

      4. Code deployment has not been covered, it’s assumed you’d be taking the normal approach of installing themes / plugins etc.

      5. That’s exactly why I opted out of using multiple servers on the front-end, when in reality, multiple servers on the front-end AND backend are a must if you seriously want to scale up. Besides caching, you also have to consider sticky sessions, database replication for high avialability, all of which are somewhat beyond the scope of this article.

      6. Agreed – the biggest gripe I’ve had with AWS is the unexpected billing charges coming at you from a lot of different places.

      7. Thanks – that’s very informative for our audience who have been asking these very questions.

      8. Haha agreed, it IS intimidating and challenging, but once you master it you do open quite a lot of opportunities.

      Once again, thanks so much for your feedback and I’d be really interested to speak to you directly so it would be great if you would get in touch.


Comments are closed.