Going Serverless with WordPress: A Pragmatic Guide for AWS

I got a call from a client in a full-blown panic. Their WooCommerce site, which had been humming along just fine, had completely fallen over. Why? Because their Black Friday campaign was a massive success. The site was flooded with traffic, and the server just gave up. Total mess. They were losing sales by the second. This is the classic scaling problem with traditional hosting, and it’s where a proper serverless WordPress architecture on AWS becomes a lifesaver.

For years, the standard playbook was just to throw more hardware at the problem. Vertically scale the server. My first thought, years ago, would have been to bump their EC2 instance up to the next biggest size and pray. But that’s a costly, inefficient fix. You pay for that massive server 24/7, even when traffic is low. It doesn’t make sense.

Breaking Down a Real Serverless WordPress Stack

Going serverless isn’t about getting rid of servers; it’s about not having to manage them. You’re swapping server admin work for infrastructure configuration. The core idea, which I saw detailed nicely over at carlalexander.ca, is to replace each part of the traditional stack with a managed, auto-scaling AWS service.

• AWS Lambda for PHP: Instead of a server running PHP-FPM, you have Lambda. Your WordPress PHP code runs in response to a request and then shuts down. It automatically scales to handle one request or ten thousand. No more PHP workers getting exhausted.
• Amazon API Gateway & CloudFront: API Gateway acts as the front door, taking HTTP requests and triggering your Lambda function. You stick CloudFront (a CDN) in front of it to cache pages and assets globally. This handles the HTTP caching layer beautifully.
• Amazon RDS or Aurora Serverless: Your MySQL database still exists, but it’s on RDS, a managed service. For sites with truly spiky traffic, Aurora Serverless v2 is the holy grail—it scales the database itself up and down almost instantly.
• Amazon S3 for Media Uploads: Here’s the kicker. In a serverless environment, there’s no persistent `wp-uploads` folder. Every request could be handled by a different container. The fix is to offload all media uploads to an S3 bucket. This requires some clever code to intercept WordPress’s default upload process.

That last part is where people usually get stuck. You can’t just install a standard S3 offload plugin, because many of them still upload to the local filesystem first. You have to hijack the process before the file ever touches the server’s temporary storage. It’s a bit of a headache but completely doable.

add_filter( 'wp_handle_upload_prefilter', 'my_serverless_upload_prefilter' );

function my_serverless_upload_prefilter( $file ) {
    // 1. Generate a presigned URL from AWS S3 SDK.
    // 2. Upload the file directly to S3 from the browser using that URL.
    // 3. Return a custom structure telling WordPress to skip its own file handling.
    // This is a simplified concept, the actual implementation is more involved.
    
    // Forcing an error to stop the original upload process
    // In a real scenario, you would handle the upload and return correct data.
    $file['error'] = 'Upload handled by serverless function. Bypassing local storage.';
    
    return $file;
}

So, What’s the Point?

Moving to serverless is a trade-off. You’re trading the familiar world of SSH, Nginx configs, and server monitoring for Infrastructure as Code (IaC), IAM roles, and VPC networking. It’s not simpler, it’s just a different kind of complex. But when it’s set up right, you get an architecture that can withstand almost any traffic spike without breaking a sweat. And you only pay for the compute time you actually use.

For a high-traffic WooCommerce store, a publication with unpredictable readership, or any site where downtime equals disaster, it’s the only way to build for resilience. You fix the scaling problem at its foundation instead of just patching the symptoms.

Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.

Have you been burned by a traffic spike that brought your site down? Let me know, I’m curious what broke first.