Enterprise-level WordPress hosting with AWS
Reliable, secure and robust hosting for public companies
What is highly-available hosting and why does it matter? How can we ensure our client websites stay online, even during high-traffic periods or planned maintenance? Let’s find out.
We’re quite proud of our technical expertise, especially when it comes to the underlying infrastructure supporting our applications and client websites. By some estimates there are around 1.1 billion websites in the world, although “only” 200 million of those are regularly updated and considered active.
Still, these sorts of numbers might give the impression that web hosting has become a commodity that’s cheap and readily available. And for the most part this is correct. Anyone can rent an inexpensive virtual private server (VPS) and host a website for a few dollars a month, maybe a little more if you have a complex application or a high-traffic site.
But what happens if that server has a problem, or needs to go offline while essential maintenance is carried out? The websites it hosts go dark. Traffic spikes – from human visitors but also malicious attacks – can also cause headaches for a sysadmin. And if that server catches fire and has to be replaced with a new unit? Well, you better have reliable backups at-the-ready.
Understanding single points of failure
Before we get into the technical nitty-gritty we should perhaps look at the components and moving parts of a web application or website.
Most content management systems, WordPress included, consist of a bunch of files which have to sit on a webserver; PHP, HTML, CSS, JS… they combine to make up the application itself.
However, they also need to connect to a database which is where the content, settings and user accounts are stored in a collection of tables. WordPress uses MySQL.
Then we also have to consider things like images, PDFs and other documents. These assets are part of every website and they are essentially in the “bunch of files” bucket, but they are unique to your website and separate from the files which make up the application which powers it.
It doesn’t stop there!
You also have a domain name like “luminate.works” which is managed by a Domain Registrar (the place where you bought your domain, and pay for its renewal each year).
Each domain requires a set of Domain Name System (DNS) records that point different types of traffic to different places. Perhaps email traffic is routed via Gmail or Microsoft, while website traffic gets sent to a server over there, and maybe you have subdomains powering your intranet or extranet, too. DNS records are managed by Name Servers.
The important lesson here is that if any one of these goes offline, it can knock everything offline. All of the components need to be up and working in unison for your website and network to function.
What is highly-available and load-balanced hosting?
Put simply, we try to eliminate single points of failure by spreading the load, including additional capacity and baking redundancy and resiliency into the system. If something breaks, it doesn’t bring the whole show crashing down around us.
Thankfully, the Amazon Web Services (AWS) toolbox exists for geeks like us looking to create this sort of architecture!
Amazon’s Elastic Compute Cloud (EC2) is where we host the website files. We have multiple EC2 units spread across different UK datacentres working together in unison, with files synced in real-time. If a change is detected on one unit, it is replicated to the other units in the chain. This means we can take a unit out of production – perhaps for essential maintenance, or to alter its configuration – and the web application continues to be served by the other remaining units.
Amazon’s Relational Database Service (RDS) is where we host our databases. Most hosting providers include the database AND files on the same unit, but we’re using separate and dedicated services to spread the load. RDS is directly connected to each EC2, and with Multi-AZ enabled, our databases are automatically provisioned across multiple datacentres. If a failure is detected in one instance it automatically fails over to a standby instance without manual intervention.
Amazon’s Simple Storage Service (S3) is where we host assets such as images, PDFs and PowerPoint files. While we could easily host these assets on the EC2 webservers, they would need to be replicated across each EC2, and S3 is simply far more performant and resilient. It sets the standard for scalability, data availability and performance.
Amazon’s Elastic Load Balancing (ELB) is an application load balancer that helps us monitor the health and performance of our hosted environment, while ensuring each component is working under optimal conditions. Like the name suggests, it connects to each EC2 and shapes the traffic so that all of the servers are doing some work. We don’t want one sweating while the others snooze! We run multiple ELBs for added resiliency.
Amazon’s Route 53 (R53) is a highly available and scalable Domain Name System (DNS) service. Each hosted DNS account includes 4 independent nameserver records across different top-level domains (for example, .com, .net, .org and .co.uk) for extra protection, and R53 includes granular controls for routing policies, helping us automate and respond to potential failures.
It looks a bit like this….
What about things like page speed, and security?
Amazon’s Web Application Firewall (WAF) is attached to the load-balancer and sits at the front of our infrastructure. Every request needs to successfully pass through the firewall before it gets routed to a webserver. We also run ModSecurity on each server, just for good measure.
AWS provides a common rule set, which includes basic OWASP protection, and filters for cross site scripting (XSS) and SQL injection (SQLi). They also include dynamic ‘reputation IP’ lists to block known bad traffic at the first hurdle.
In addition, we’ve created our own customised rule sets for additional protection against Distributed Denial of Service (DDoS) or Flood attacks, automatic blocking of specific bots or user-agents (the thing that identifies various bot traffic), IP blacklists, traversal attacks…. the list goes on.
As WordPress experts, we also leverage LiteSpeed at the server and application level to improve page speed and performance. LiteSpeed Cache (LSCache) is the brains of our core WordPress hosting solution. It’s an all-in-one optimization plugin that is intelligent, accurate, and fast, delivering fantastic page speeds by reducing the load on our servers. It also offers added protection against brute force attacks and botnet traffic.
Real-time monitoring, health-checks and alerts
Amazon Cloudwatch is an infrastructure monitoring service. We use it to keep an eye on server health, resource usage and performance across the entire digital estate.
Cloudwatch includes charting, logging and insights, along with customised alarms which go out over email and SMS, depending on their severity. If a server becomes unresponsive, traffic is outside of the normal range, or a resource becomes strained, Cloudwatch lets us know so we can take the appropriate action.
We don’t just rely on AWS’s own systems either. Combined with popular external monitoring services like UptimeRobot and self-hosted solutions like Uptime Kuma, we’re confident that we’ll know about any potential issue before it turns into a disaster.
And if all else fails, we’re ready with backups and disaster recovery
It’s better to be prepared and not need it, than to need it and not be prepared. Or something. We like sleep as much as the next person, so we took a belt and braces approach to disaster recovery to ensure that we’re able to get ourselves and our clients back up and running in the event of an emergency.
Every client project is supported by a private GitHub repository, providing us with immediate access to the ‘theme’ files which are unique to individual client sites.
From twice-daily AWS Snapshots for EC2 and RDS, to AMI Images and EBS Volume Backups, our entire AWS infrastructure is regularly backed up and managed with intelligent lifecycle and retention policies. We also take manual snapshots before any major changes, just in case we need to roll back. Our S3 buckets also have delete protection enabled, and a copy of the assets always lives on our primary EC2 unit, too.
Our webservers also have their own independent daily backup routines for each hosted application, plus all of the system files, with the backups themselves stored directly on the webserver for instant access. They are also transported nightly to a secure, non-AWS hosted environment, just in case.
We can go back in time on a per account basis at the click of a button, and if AWS simply became unavailable (heaven forbid!), our off-site backups would allow us to recreate the infrastructure elsewhere.
Please get in touch if you would like to know more about our WordPress hosting capabilities.
