laurence shaw posts

laurence shaw posts

23 January 2021

Amazon AWS Services provides a solid, reliable WordPress hosting platform that gives fast performance. The key differentiators apart from integrity are speed of delivery of the website pages at low pricing, with servers in Sydney.

A “standard” site has no requirement to make use of other services such as RAID disk and load balancing, but these are available primarily for IT teams in business, government and corporations.

A good starting place for an individual, sole trader, or small business is what we call a t3amicro (or t3micro) EC-2 Linux 64-bit instance. A good starting place for other popular “Aussie” providers is an entry level business plan with the cPanel interface.

My experience is that lower cost plans may lack performance, ease of use and functionality with ensuing frustration leading to upgrades anyway.

It should be said up front that a domain name is part of any web design and delivery solution. Any hobbyist or sole trader with an ABN number needs a relevant .com.au domain name.

Having grown up with Unix and being in the IT industry, it is within my scope to make use of the AWS platform, which is an advantage. It is also fun. Most “Ma and Pa” websites will not be using Amazon, as you need IT skills, including strong problem solving experience.

One noticeable disadvantage of AWS services for us ordinary folks, is the On-Demand USD pricing model. That is, you receive a monthly invoice instead of an annual invoice, each month has slight variations being based on what you and Internet visitors use, and it is subject to the USD/AUD exchange rate.

A fully fledged AWS WordPress solution needs several services to configure and run. Of these, some have a cost, so they need to be documented so that they can be switched off to stop billing when the service is no longer required. All of these services as part of an overall fabric takes considerable investment of your learning time. Help is either through forums or testing as the monthly support costs are too high for individuals, or to warrant continual use per month.

Amazon is used by another service called Lightsail that provides a stable USD price per month, but after years of using this service too, I no longer go down that track myself.

If we look at the heart of WordPress, it relies on a database and PHP. Some Aussie providers split the WordPress platform into two parts, placing WordPress files on one piece of hardware, and the database on another. This is bad practice for us, because it gives two points of potential failure. Further, a provider may locate these in different regions.

Amazon has servers in Sydney, so we don’t end up with reliance on overseas countries that have nature disasters or other factors for downtime. While we use Sydney services, there are some that are configured globally, or specifically for email in Oregon on the West Coast of USA.

When we place the web server in another country, we have both longer wait times and what we call an initial protocol or handshake between the user and the server called server response time. Server response time in other countries can delay loading a web page from 1 to 2 seconds, so it is essential to use servers in Australia to reduce this to microseconds.

Another aspect of local servers is security. Some clients now prefer that WordPress data is kept in-country.

There is one desirous use of Amazon we can also take advantage of, which is use of a CDN to distribute content in other countries. This reduces delay time when loading WordPress content such as images. For most people this is not an issue, but it is available.

Where this is particularly useful is with thousands of files. Large files, or large quantities chew up hard disk space. This can increase costs a bit too much and cause management and maintenance headaches. Amazon provides a very low cost vehicle called S3 storage that may house virtually unlimited numbers and sizes of file. If the WordPress cost is increasing too much, S3 storage removes the problem. But the problem is then technical, how to use it. However, once on S3 storage, files can make use of CDN distribution.

These are nice goals to head towards, but again, they require investment of time, a learning curve.

As with any IT system, there needs to be some care in some parts of the system, such as the use of domain name services, (DNS) and security settings. We could write a book on best practices and how to configure all of these services. However, there is no such book. An IT person can come up to speed on each service over time if this is their goal. Once it is under our belts we can go to town on it.

Clients using AWS need to adjust to the monthly billing, but they may need to overcome a barrier around why AWS is so different to another Aussie provider. There is a perception of safety. Is Amazon safe, and what happens when someone else takes over management of the website? In reality, these are not problems, but they are perceived that way. It is something we have to deal with.

For example, a hosting provider includes a Help Desk. In practice, a web developer or support person knows too well the many times a Help Desk does not give critical help. To the non-IT person, a Help Desk may provide a sense of safety. From a psychological perspective, another problem is that people find it hard to change from one provider to another. It should be no issue at all for the web developer to transition any website to any provider.

Behind the scenes there are all sorts of issues with hosting. For example, you may think your website is secure and not know the provider did maintenance that accidentally opened your site to being hacked, the provider then refusing to re-install your site after the hack. The provider may advertise virtually no downtime, but this is not backed up by reporting metrics and contractual financial penalties. Many users have given their own stories of inordinate amounts of downtime and black outs of information from the provider. Another example is that you may think your website is secure because you have backups. A number of times the standard backups will not work. There are reasons for this, but backups are not the same as Disaster Recovery Backups. Maintaining current software is not only for WordPress versions, but the upgrade levels of PHP that accesses the database, and the operating system.

One provider changed ownership four times in ten years. In one case, the hardware was changed without notification to users. The websites got slower. In another case, the hardware was downgraded. Sites were freezing. In another case, a provider removed an entire service – manual WordPress rebuilds were required via backups.

An overall picture begins to develop of what builds a fully working WordPress system. What we find are a number of designers addressing a simple subset of these components. Every component needs to be addressed when using Amazon, because there are no shortcuts. This does not mean heavier burdens for maintenance ongoing. In fact, one can leave a system as it is for the whole year, but it is best to perform upgrades at nominated times or under advisement of security related risks.

Even when using Amazon, major upgrades or development needs prior data backup to ensure a failure is no risk. One way we do this is with AWS “snapshots”. These backups are able to return a system to its prior state within minutes of a failure. That is superb.

But consider, what if you backup faulty data? There are precautions to prevent this scenario. You may think this would be too rare to happen. In fact, it does happen. None of the standard builds we are talking about use RAID disk, or database rollbacks. There are two basic ways to test a system before backing it up. One is to do a database check, and the other is to do a recursive list of all files in the operating system, making sure the listing does not freeze up. There are other file system checks, but in former days, we had a highly reliable and useful fsck Unix command to fix a faulty system. Today using alternative commands we may not recover.

Another part of WordPress sites are the Contact Forms. These days security means we must use the domain name for the email addresses. Some emails will get lost if we do not. Amazon provides a service similar to Outlook with its own interface, at USD $4 per month. This is fine. It is possible however to configure secure DKIM email with no such interface for free if you then forward the emails to another address, but you have to know how. A business would not operate this way. The $4 cost can be much less than the MS Office packages offered by providers. Amazon does allow you to block emails, but as we all know, we cannot block Google or Outlook emails that do not provide an IP address, so those blocks can be a hassle to maintain. For Amazon, the main thing to know is that the reverse pointer record, or what we cal PTR in the DNS services, is automatically configured behind the scenes. We are not meant to tinker with that value. If a business blocks an Amazon email, we cannot change that. The business has to open up their own servers to allow our emails.

Aussie 3rd Party hosting providers have “cheap” email plans that lack proper security, so we do need to spend money on setting up DKIM security with them. If we use a non-Amazon provider, we have to select the business version of MicroSoft email, as that lets the provider configure DNS settings. We do not want MS Exchange, as that is a platform for a business to manager company emails. We just need the simpler business version of Outlook Express. A personal version of MS Outlook gives no DNS capability.

Today all websites should be configured with SSL certificates. It used to be an option. We can provide low cost certificates through the WordPress plugin of CleanTalk. Email must first be set up in Amazon so we have something like admin@domain.com.au in order to receive an authenticated certificate. We then have to know how to add the certificate to Amazon and keep a calendar notice on when to pay for and add a new certificate in years to come. Other Aussie providers will make this process automated at the click of a button.

As Amazon releases new operating system versions or hardware, we may find transferring from one major architecture to another has problems, meaning we have to install and build an operating system, then manually rebuild WordPress from backups while referencing the old system to ensure we have everything the same, like menus and widgets. If we transition from another provider to Amazon, the same applies, as the database may not transfer over. This is not an Amazon issue. It is about the database and software on the existing platform in relation to another platform. This could be provider to provider, or even to your PC as a localhost testing platform.

Recently Amazon provided the newer t3 instances. All the instances allow for bursts of CPU at no extra cost, but by default they also allow for exceeding the CPU limits by temporarily using additional CPU power. This can lead to bill shock, so it is important to switch the “unlimited” CPU option off when installing/launching an EC2 instance. As new versions of Linux or PHP are provided, there may be some hiccups. For example, you may need to work out detailed steps for installing ZIP – WordPress and various plugins need to ZIP files. Or, how to install ImageMagick. The list goes on.

From an operating system point of view, one needs to know how to install and configure essential files with httpd, mysql, php, phpmyadmin, apcu, memcached, opacache, ssl, and postfix. One may add on IP2location for country blocking.

From the Amazon services, one needs to know how to configure EC2, DNS (Route 53), SES, SNS, IAM, with various subsystems like static ip address, security groups, snapshot, and reserved instances to reduce costs. One can add CDN with S3 storage, so that Google can see subdomain names like myfiles.mydomain.com.au instead of very long S3 URL links. Cloudwatch monitors an instance and gives email logs, or WorkMail manages emails similar to Outlook. If we build email, we use known Lambda functions.

If we do add S3 storage with CDN, it is possible to mount that storage similar to an NFS mounted file system. As you can see this is all very technical.

Like any environment, there are things we learn to do. For instance, Amazon will have associated requirements for setting up billing, budget alerts and notifications. Clients as members of the public will probably feel uncomfortable logging into Amazon accounts and looking at the billing, as compared to another provider. Are the learning curves, risks, investment of time, client differences all worth it? Sure, I sometimes wonder, but I have worked in IT for over 25 years with major companies, and Amazon is clearly my default position, so for me there is no question on things like its use and robustness. This does not mean I won’t build a site on another provider platform. I do however stay clear of services that do not hold servers in Australia.