The Golden AMI Pattern: How We Provision Hardened WordPress Sites in 30 Seconds

Most SaaS platforms provision tenant infrastructure the same way: spin up a bare EC2 instance, run a configuration management tool, install packages, download application code, harden the OS, and hope nothing drifts. For a single tenant, this works. For a platform that needs to launch hundreds of isolated WordPress instances, it doesn’t.

The problems compound quickly:

The golden AMI pattern eliminates all of this. You build once, validate once, and deploy the same proven image hundreds of times.

Our golden AMI is a pre-baked Ubuntu 24.04 LTS image running on AWS Graviton (ARM64) that contains everything a WordPress instance needs — already installed, configured, and hardened before a single tenant touches it.

The Build Pipeline

We use HashiCorp Packer to orchestrate seven provisioner scripts that run in sequence. Each script handles one concern, and the output is an encrypted EBS-backed AMI registered in AWS.

The result is a 20 GB encrypted AMI that contains a complete, production-ready WordPress stack. No downloads needed at deploy time. No apt-get. No pip install. Everything is already on disk.

Most teams treat security hardening as a post-deploy step — if they do it at all. We run the CIS Ubuntu 24.04 Level 1 benchmark as part of the AMI build. Every instance launched from this image is compliant from the moment it boots.

Here’s what the hardening layer covers:

Additional hardening on the PHP side: dangerous functions are disabled, session cookies are secured, and direct file access is blocked. Nginx enforces security headers (X-Frame-Options, X-Content-Type-Options) and blocks access to sensitive files like wp-config.php and .env at the web server level.

Services that have no business running on a web server — snapd, CUPS, Avahi, Bluetooth — are masked. Unattended-upgrades handles security patches automatically. This isn’t a checklist we run after launch. It’s infrastructure that ships compliant by default.

The golden AMI handles the what — a hardened, pre-loaded server image. The tenant bootstrap handles the who — configuring that image for a specific customer. Here’s how the full provisioning flow works:

The entire bootstrap runs in a single script with 7 phases. No orchestration tool, no Ansible pull, no Chef converge. Just a shell script that reads a JSON config and applies it. Total wall clock time: 30–45 seconds from EC2 launch to a customer-facing WordPress site with AI-generated content, a custom theme, and full monitoring.

Golden AMIs are only useful if they stay current. Stale images mean unpatched vulnerabilities and outdated runtimes. Our build pipeline runs automatically and keeps the image fresh:

It’s a fair question. Containers are the default choice for multi-tenant SaaS in 2026. We chose AMIs for WordPress specifically because of what WordPress is:

The golden AMI pattern gives us container-like reproducibility with VM-level isolation. For WordPress multi-tenancy, that’s the right tradeoff.

Launching a site is only half the problem. Running hundreds of them requires operational tooling baked into the platform from day one.

The golden AMI pattern isn’t new — it’s an AWS best practice that most teams skip because the upfront investment feels heavy. For a multi-tenant SaaS platform, that upfront cost pays for itself on the second deployment.

Here’s what we gained:

Every instance is identical. Every instance is compliant. Every instance is monitored from boot. And when we need to update the base image — new PHP version, new security patch, new WordPress release — we rebuild the AMI, test it, and let the next launch pick it up automatically.

That’s the power of immutable infrastructure: you stop fixing servers and start replacing them.