WordPress is one of the most popular CMSs. It’s easy to install and easy to use, and there are thousands of plugins and templates that make the website development super easy and super fast. But its advantages are also disadvantages because the page generation can be really resource-demanding and WordPress is not only one of the most popular but also one of the most vulnerable systems.
There are many cases where a simple static webpage would be enough, but using WordPress is a more convenient solution. A blog or a product website is a good example. You have to simply choose a template, set the colors and some other things, upload the content, and voila, you have a full-featured website with some hours of work. These are the cases when CloudFront can be a good solution to make your website fast, scalable, and secure.
Amazon CloudFront is a Content Delivery Network. A worldwide distributed cache system. When a user tries to access your content through CloudFront, the system routes the request to the nearest edge server which serves the content if it exists on it or asks it from your WordPress server.
In this case, WordPress is something like a static page generator that generates the pages that CloudFront serves. The resource consumption of your site will be extremely low because CloudFront asks for the content only once and serves it million times if needed. You can handle extremely high traffic with millions of users by using only a micro instance for your WordPress!
Another advantage of this system is that only the CloudFront part is public. Your WordPress is hidden from the outer world so, nobody can attack or hack it. Behind CloudFront, your origin is in maximum safety.
To add CloudFront to your WordPress site, set up a CloudFront distribution on the AWS console.
Set the origin domain to your current WordPress site URL, and give a name to your distribution.
On the “Settings” block choose an alternate domain. This will be the new domain where your WordPress site will be accessible through CloudFront.
If the deployment is done, copy the CloudFront domain name, and create a CNAME record to it. For example, if your alternate domain is www.example.com and the CloudFront domain is d3qu6ceheilwux.cloudfront.net, then add a
www.example.com CNAME d3qu6ceheilwux.cloudfront.net
record to your DNS zone file.
If everything has done well, you will see your site on www.example.com. Clicking on the links on the new site will go back to the original WordPress site. To prevent this, add these two lines of code to the beginning of your wp-config.php:
if($_SERVER['HTTP_USER_AGENT'] == 'Amazon CloudFront') {
define( 'WP_HOME', '... new site URL …' );
define( 'WP_SITEURL', '... new site URL …' );
} else {
define( 'WP_HOME', '... original site URL …' );
define( 'WP_SITEURL', '... original site URL …' );
}
The user agent of CloudFront is ‘Amazon CloudFront’, so when CloudFront reads the site content, it will get the new URLs, but when we access it for the administration, it will use the original URLs. After this modification, the links will point to the CloudFront URLs (ex.: www.example.com).
Congratulation! You have set up CloudFront for your WordPress site. We are almost done, but I promised improved safety and our original site is still public. The easiest way to prevent attacks on the original site is to add HTTP authentication with a strong password to it.
If you are using Nginx, you can generate a password file by using the htpasswd utility:
htpasswd -c /etc/nginx/htpasswd wordpress
that you can add to your config:
auth_basic "Password protected content";
auth_basic_user_file /etc/nginx/htpasswd;
CloudFront can send HTTP headers when it accesses the origin, so you can add the auth header to its config. The auth header looks like this:
Authorization: Basic {base64encode({user}:{password})}
So, if your user name is abc and your password is 123 then the auth header will be:
Authorization: Basic YWJjOjEyMw==
The header can be generated by using any online base64 encoder. If you generated the header, add it to your origin’s config.
After the deployment, CloudFront will access your site, so it will be publically available through CloudFront, but the original site will be password protected. To keep your site protected, you can change the password monthly and set up fail2ban to prevent brute force attacks.
The last thing that I wanted to talk about is invalidation. The default behavior of CloudFront is that it refreshes the content only once per day, so if you change something and don’t want to wait for a day, you have to delete the cache. CloudFront uses invalidations to do it.
If you want to delete one or more files from the cache, you have to create an invalidation. Invalidation is a broadcast message to the edge servers to delete the given content. The parameter of the invalidation is a list of file paths that can contain *. If you want to fully delete the cache, use ‘/*’.
As you see, CloudFront is a perfect solution to scale your WordPress site and make it safe. By using it, your site can serve millions of users, and you need only a micro instance behind CloudFront. The solution is not WordPress specific. You can use it for any site that does not use server-side interactions. In some cases, it needs a little bit of different thinking. For example, you have to use hosted comment services like Disqus or Facebook comments, or if you have a webshop on your site, you have to organize it to another domain as a separate service. But I think it's a really low price for the safety and the seamless, fast, and scalable content serving.