What’s New In The AWS Fault-Tolerant Load-Balanced Scripts

Our AWS CloudFormation scripts that deploy a load-balancing, fault-tolerant WordPress stack on AWS in under an hour is not something that gets a lot of updates or attention.

So, if you’re a frequent reader of our site articles and have no idea what we’re talking about, you’re probably not alone in that. (You can learn more about this product on its product page.)

These scripts are usually used for deploying large scale, high-volume WordPress installations and therefore customers tend to want to customize them for their own needs – they’re designed for that purpose.

So what sets these scripts apart from the many free Terraform-based alternatives? Three things:

• The ease of customization – they’re designed for easy customization
• They are based on real-world WordPress experience
• You can get support (optional) directly from the authors (us) – they’re treated as a real product, not something that you have to figure out how handle when things go wrong.

The scripts are also 100% pure AWS – using only BASH and AWS CloudFormation – no Terraform, Ansible or other package or infrastructure manager is needed.

If the AWS CLI is already installed in your WSL or Linux Ubuntu server, you can get a fully load-balanced WordPress cluster in two availability zones up and running in under an hour.

For the last two releases (1.6 and 1.7) here are the changes we made:

1.7.0

• Add a CHANGE LOG section to readme file.
• Add NAME tag to EC2 instances to make them easier to identify.
• Update PHP MAX_INPUT_VARS default to 5000 since page builders such as beaver builder seem to require a higher number here.
• Default the PHP MEMORY_LIMIT to 512M.

1.6.0

• Use Ubuntu 22.04 LTS images as the default OS for all servers.
• Add additional constants to wp-config.php.
• Add REDIS binary to all deployed server instances.
• Upgrade to latest wp-cli version.
• Remove references to older PHP versions.
• Remove old comments.

We also drastically increased the price of the scripts. The original price was way way too low. Even with the new price, the cost savings a customer would reap over spending numerous hours building in-house is still VERY SUBSTANTIAL.

For this latest release we also update the documentation. We added more details on the files that are included in the package as well as guidance on how to make simple modifications and ideas for more complex mods.

AWS Servers VS AWS Containers

In this age of containers, it might strike you as weird that folks will use AWS EC2 servers for scaling instead of using an AWS Container Service such as Fargate.

If you already have a good idea of your load and it’s generally steady state, using a serverless option is far far more expensive than using dedicated EC2 servers instances.

If your load varies substantially on an hourly/daily basis then serverless can definitely provide costs savings. But, if you have a large load that doesn’t vary on an hourly basis then using EC2 SERVERS is likely a more optimal cost option.

Even Amazon’s own PRIME service made the move from serverless to servers and reaped a 90% reduction in costs!

Our AWS scripts are great for when you have a large load that isn’t going to vary substantially every few minutes and doesn’t need to scale down to zero.

---