I am a photographer first and a webmaster second – that is the way it is supposed to be.
Every professional photographer knows how important a good website is for getting their images out there. The flip side is that sometimes my ‘computer time’ is spent more on the web-mastery side of things than working on my images. A website should work for me, not me for it!
WordPress is an excellent foundation, and once you have found and customized the right theme for your needs, the challenge becomes the hosting provider.
As my website scales up and down my back end computing needs change. Sometimes if I want to upgrade to a more powerful instance, the hosting provider forces me to migrate my entire WordPress site with all my content, settings, customizations and databases from one instance to another. Even with specialist migration plugins like All-in-One WP Migration, some little things always break.
Many photographers with smaller websites don’t need an expensive, dedicated platform so they opt for shared hosting. My experience with shared hosting is that after the initial migration of the website, performance and site responsiveness are good. Over time though, generally after 6 to 9 months as the server loads up with other customer sites, performance figures decrease, the user experience becomes sluggish, and visitor numbers drop. So you migrate up or migrate away to another provider – it’s a cyclical process.
Looking at the Amazon AWS menu can be quite daunting if you aren’t familiar with cloud computing. Even if you are familiar, trying to figure out which option is best for your performance needs, with the most efficient administration overhead, can make your head spin!
To make it simpler, AWS EC2, or Elastic Compute Cloud, is Amazon’s play for cloud computing; it’s a Swiss Army knife that can do everything. The key thing is I don’t need to do everything, I want a flexible, scalable platform just to run WordPress on. Amazon Lightsail is just what I have been looking for.
As an experiment, using the 1 month free trial for the smallest Virtual Private Server (VPS), I created my Lightsail Instance. WordPress comes preinstalled, as does the migration plugin I mentioned earlier. After the migration, I accessed my site and my first thought was “wow, this is fast, my site feels much more responsive.”
This feeling is confirmed by the results from 2 separate Pingdom speed tests run a few seconds apart.
My homepage has a size of 2.8Mb and I knew performance was slow in its old home. However, I was shocked the results were this bad. 3.81s (yes seconds!) versus 616ms from Lightsail. That is a night and day difference in responsiveness!
Both the Pingdom server and my old hosting provider are on the US East Coast so latency due to geographic distance won’t make a big difference. This is purely back end server/infrastructure performance.
So, setup and migration were simple. The speed of page delivery is clearly excellent. Two very compelling reasons to keep my site running on Lightsail.
Lightsail and Instance Snapshots
This brings me onto the topic of testing, another major advantage of cloud computing. Previously, when I wanted to do some development (enhancement) to my live site, I would migrate a copy of the live site to a small virtual machine at home. Then I would do my testing and if something broke which I couldn’t fix (remember, I am a photographer, not a web guru!) I would need to migrate (again) a copy from live down to my test environment and try the test again. Not a bad solution but very 20th century (and slow) compared to what I can now achieve with Lightsail.
With AWS, I simply tell Lightsail to create a snapshot of my live virtual machine. A snapshot is exactly that, a full copy of that instance at that moment, all data, all configuration – everything. This snapshot can be used as a backup or as the base for testing using another development instance.
Creating the snapshot and loading it on a new instance with a new Public IP address took me about 15 minutes. I can then complete whatever work I need, whether it takes 1 hour or 1 week. When I am finished with the development instance, I simply delete it. My testing is now so much more efficient.
Lightsail and S3
By this point, you can tell I have got the ‘Amazon bug’, it is simple and it works. Lets see what else I can do – next Amazon S3! If you have read my Photographic Data Management article you may remember that I already use the AWS Storage Product – S3 – to backup my NAS.
To have a backup, I took another snapshot of my Lightsail instance. As you will shortly read, I am very glad I did. The first step to using S3 for my website was to create a bucket for my WordPress wp-content directory to reside.
WP Offload Media Lite
For WordPress integration with S3, the WP Offload Media Lite plugin comes highly recommended. Configuring the free plugin took a few seconds, just a matter of selecting the S3 bucket name I created earlier.
From now on, any new images I upload will be stored on S3, not on my local server storage. The problem is that my current media is still on the local server. Paying a subscription to unlock the ‘migrate existing’ feature in this plugin was a possible option. However, after a short Google search I found an alternative (free) solution with a plugin called Regenerate Thumbnails. It appears the main reason for regenerating the thumbnails is because it tricks WP Offload Media into seeing each as a new upload, and therefore storing it on S3 rather than locally.
I selected the Regenerate All option and waited for the process to complete. Checking the Media page and Envira Galleries showed about 50% of the images as having the correct S3 link, the other 50% all had broken links – not good. Proof indeed that there is ‘no such thing as a free lunch!’
For some time I have planned to update my images with higher resolution versions so I didn’t spend too much time diagnosing the problem.
Lightsail, S3 and CloudFront
Next, CloudFront as a Content Distribution Network (CDN). I am on the US East Coast, so is my AWS region. Therefore my latency to my site is very low and responsiveness is good. If a visitor is accessing that content from the US West Coast or EMEA/APAC all that data, particularly the image data, has to traverse a long distance and the site appears slow. Using a CDN means that my content is stored in all of Amazon’s CloudFront data centers, so if a visitor from Singapore is viewing my site the images aren’t being served from the US, they are delivered from the CDN location in Singapore – in other words – very quickly!
First, a domain name needs to be created within the CloudFront portal. This is normally a ‘longrandomstring.cloudfront.net’. Then I direct this domain to the S3 bucket I created earlier. Content deployment to all of Amazon’s global locations then starts automatically.
At this point, the CloudFront CDN is serving the images from the closest location to the viewer. There is one final step to complete. Google Site Search Bots don’t like the long URL string I mentioned above and it can impact the search rating of my site. The easiest solution was to create a DNS CNAME record for cdn1.exposurecompensation.co.uk. After DNS propagation I added the new CNAME record to the WP Offload Media plugin and everything was complete.
CloudFront and Hotlinking
Hotlinking can be defined as directly linking an image published on one website and making it display on another. Also, if I know the image source URL, I can copy and paste it into a browser making the image display outside of my website theme framework. Neither is good.
Embedded into CloudFront is Amazon’s WAF or Web Application Firewall. Using an Access Control Control list, I can create a policy which checks the Referrer header request and blocks hotlinking.
Without the WAF rule in place, I can for example enter https://cdn1.exposurecompensation.co.uk/image-path/image1.jpg into a browser and only the image is displayed. As you are browsing (and I hope enjoying looking at my photographs!) you are connected to https://www.exposurecompensation.co.uk. When any page displays images, it gets them from the cdn1 location, so in short, www is referring to cdn1. My WAF ACL is configured to check the Referrer header, if it doesn’t contain my https://www domain name the request to display the image is blocked.
Sometimes there are cases where I may want specific hotlinks to exist. For example, for many years I have been a member of the FredMiranda photography community. From time to time, I will post an image to a forum and do this by hotlinking. So in the WAF I can create a second rule which does exactly the same thing but with the FredMiranda referring URL allowed.
This was an interesting (and fun) experience, one that surprised me in terms of how simple everything was. I had no need to tweak or customize the virtual server, it just worked. Also the smallest VPS option appears to be more than adequate for my current needs. It is surprisingly fast – faster than some bigger dedicated platforms I have had from other hosting providers.
After thoroughly testing all content, forms, galleries and internal site links, I decided to make this instance my production one. I updated the DNS A record with the Public IP of the Lightsail instance. After propagation of the DNS record, the site was live!
Lastly, since environment is now Amazon centric, migrating domain ownership to Amazon’s Route 53 (their DNS product) made a lot of sense. The other benefit of doing this is that DNS updates are now almost instant.