AWS provides free static web site hosting via its flagship S3 and CloudFront services. Free, serverless hosting? Sounds great! So why can’t you run WordPress with this? Lets take a closer look.

Summary

AWS has been offering free static web site hosting on S3 since 2011, which is amazing. Better still, by combining S3 with Cloudfront you get static web hosting combined with a global content delivery network, ensuring a consistent and performant browsing experience to your site visitors no matter where in the world they might be located.

When you first heard about this you might have thought to yourself, “Awesome! now I can run my WordPress site for free!”. Well, not so fast. WordPress will not run from S3. But why not?

To answer that question lets take a closer look at How S3 static web site hosting works, and then lets also take a look at how WordPress works at a high level at least.

S3 Static Web Hosting

S3 (AWS’ “Simple Storage Service”) and CloudFront (AWS’ global content delivery service) are each wildly sophisticated solutions, but their enormous popularity stems more from their ease-of-implementation and low-cost than anything else, in my opinion at least. A few years after S3 initially launched AWS began offering free static web hosting, however, this enhancement only serves a specific and narrow use case.

To implement their static web site hosting solution AWS simply attached an http listener to S3, enabling it to receive and respond to simple http requests. However, this listener is just that: a listener, and nothing more. This means that, for example, there is no means of parsing a URI, or executing a php script, or applying regular expressions on the URI; all of which are common tasks performed by web servers like Apache or Nginx. Therefore in order for S3 static web site hosting to work, the URI’s from each http request header must resolve to a folder path & filename contained by the S3 bucket itself. Anything else will result in an http error.

Adding CloudFront to the architecture, while a good idea, does nothing to enhance the S3 http listener’s capabilities. In fact, the only thing that CloudFront does is maintain synchronized sets of copies of your static web site’s html files and assets (CSS, Javascript, images, media, etc.) in dozens of cluster nodes located all around the world, with the sole aim of decreasing the response and download times of each of these files.

WordPress Functional Architecture

WordPress on the other hand is a full-featured content management system. The overarching aim of WordPress is to drastically dial-down the amount of technical web know-how that is required to publish a simple web page. And by this measure, WordPress is enormously successful. Now then, lets take a look at how WordPress stores web page, and then lets take an inventory of the information technology infrastructure that’s required to facilitate WordPress’ storage and publication strategy.

Per the diagram below you can see that an http request made to a WordPress site is actually received by a php file which then executes, meanwhile executing various SQL queries against a relational database, to generate a dynamic html file that is returned in the body of an http response. The http requests and responses themselves are processed by Apache (usually), enabling WordPress to leverage sophisticated security features as well as techniques like regular expressions and branching and parsing capabilities on the URI’s contained in the requests.

WordPress stores html fragments in a MySQL database in order to leverage sophisticated SQL queries to dynamically parse, filter and combine the various html fragments into a complete html document. WordPress furthermore leverages the Linux file system to store static assets like CSS and Javascript as well as publisher content like images and other multimedia files. Apache marries all of these pieces together, intelligently calling php scripts to retrieve html fragments and then calling on the Linux file system to server up the digital assets that are referenced in the html document.

To facilitate all of this we need the following four information technologies services available to our WordPress site, and furthermore, these services need to be able to interoperate. That is, they need to communicate with each other in order to exchange information.

  • Linux Server. The server provides a file system for storing the php scripts as well as digital assets for styling and automation, and for storing authors’ file uploads like images and other multi-media files. The server also provides compute power via its processors and RAM, all of which are needed in order to host Apache, MySQL and to execute PHP scripts.

  • Apache Web Server. The web server processes http requests using dynamic processing capabilities that consider how and where each resource is stored and also taking into consideration memory management, security and a host of other resource management concerns.
  • MySQL Database Server. The MySQL server stores web page content as well as lots of parameter values for the site itself and for any plugins that have been installed..
  • PHP Interpreter Engine. PHP is the automation language that glues all of the pieces together. Many of the http requests received by Apache are resolved by executing a php script that in turn executes SQL queries and applies dynamic logic to build pages based on limitless parameters and conditions that the author can build into each page.

Analyzing What’s Need Versus What’s Available

Comparing what S3 provides to what WordPress requires, we can quickly conclude that a lot is missing from S3. Namely, we lack compute power, a file system, a MySQL database server, and an ability to execute PHP scripts. And so, if you really want to work with WordPress then you’re going to need a LAMP server.