Skip to content

AWS Updated 2026-07-04

WooCommerce on AWS: the operations checklist for stores that cannot drop orders

Running WooCommerce on AWS without dropping orders comes down to a checklist: durable order writes, sessions off local disk, cache rules that never touch checkout, and restore drills that count orders.

A WooCommerce store differs from every other WordPress site in one operational fact: it takes money, so every request that matters is a write. Orders, stock decrements, payment webhooks, and carts cannot be served from cache, cannot be lost in a failover, and cannot silently fail while the homepage stays green. The AWS operations checklist for a store that cannot drop orders is therefore built around write durability and session correctness first, speed second — because a fast store that loses one order per hundred is quietly worse than a slower one that loses none.

What you are deciding

The question behind every line of the checklist is: which failures are you willing to survive? Four mechanisms decide whether an order survives a bad five minutes:

Where the order write lands. WooCommerce writes orders to the database in the same request that confirms them to the customer. If the database is a single-AZ instance, a failover, maintenance event, or storage failure during checkout drops the order mid-write. Multi-AZ RDS or Aurora turns that into seconds of retryable errors instead. Choosing between them is the subject of RDS versus Aurora for the WordPress data tier.

Where the cart and session live. On a single server, PHP sessions on local disk work by accident. Behind a load balancer, a customer whose requests land on two instances gets two carts — items vanish, checkouts half-complete. Carts belong in the database or in ElastiCache for Redis, never on an instance’s disk.

What the cache is allowed to touch. Full-page caching is what lets WooCommerce ride a marketing spike on modest compute, and it is also the classic source of the worst bug in commerce: one customer seeing another’s cart, address, or order confirmation because /checkout/ or /my-account/ got cached. Cache aggressively, but the exclusion list is load-bearing.

Whether asynchronous work actually runs. Payment webhooks (Stripe, PayPal) and Action Scheduler jobs (subscription renewals, stock syncs, follow-up emails) fail silently. A store can look perfectly healthy for days while renewals quietly stop.

What to check first

  • Cache behaviour on money pages: does /cart/, /checkout/, or /my-account/ ever return a cache HIT?
  • MultiAZ on the database instance, and the backup retention window against your order volume — with point-in-time recovery, your exposure is minutes; without it, up to a day of orders.
  • Where sessions are stored — a WooCommerce session handler backed by Redis or the database, not PHP’s file-based default.
  • The Action Scheduler backlog: WooCommerce > Status > Scheduled Actions, sorted by past-due.
  • Whether payment webhook failures would page anyone, or just accumulate in a gateway dashboard nobody opens.

How to verify

Confirm the cache never touches checkout — from outside, like a customer:

# These must never be HITs, and should set no-cache headers
curl -sI https://store.example.com/checkout/ | grep -iE 'x-cache|cache-control'
curl -sI https://store.example.com/cart/ | grep -iE 'x-cache|cache-control'

# A product page SHOULD be cached
curl -sI https://store.example.com/product/sample/ | grep -iE 'x-cache|age'

Confirm the data tier can lose an AZ:

aws rds describe-db-instances \
  --db-instance-identifier prod-woo-db \
  --query 'DBInstances[0].[MultiAZ,BackupRetentionPeriod,LatestRestorableTime]'

Confirm the session store is shared:

aws elasticache describe-replication-groups \
  --query 'ReplicationGroups[].[ReplicationGroupId,Status,AutomaticFailover]' \
  --output table

In the console, RDS > Databases > Monitoring during a traffic peak shows whether DatabaseConnections and write latency have headroom, which is where checkout failures appear first.

The runbook

  1. Make the data tier survivable. Multi-AZ RDS or Aurora, point-in-time recovery enabled, and connection headroom validated at peak-plus-half. Everything else on this list assumes the order write lands.
  2. Move sessions and carts to Redis. A shared session store makes instances disposable and load balancing safe. The pattern, including failover behaviour, is in the Redis session store pattern.
  3. Write the cache exclusion list and test it from outside. Cart, checkout, my-account, and anything carrying a WooCommerce session cookie bypass the page cache. Re-run the curl checks after every caching-layer change, in the deploy pipeline if possible.
  4. Alarm on commerce symptoms, not just infrastructure. Orders per hour dropping to zero during business hours is the alarm that matters; CloudWatch anomaly detection on a custom OrdersCreated metric catches what CPU graphs never will.
  5. Watch the async machinery. A scheduled check on Action Scheduler past-due counts, and webhook endpoints logged and alarmed on failure rate. Run wp action-scheduler run via cron rather than relying on site traffic to trigger it.
  6. Load-test before sale events with logged-in, cart-holding users. Anonymous browsing tests only prove the CDN works. The store’s real ceiling is uncached, session-carrying checkout traffic hitting PHP and the database.
  7. Drill restores by counting orders. Restore last night’s backup to a scratch environment and compare order counts against production for the same window. A restore that loses orders is a discovery you want in a drill, not in an incident.

When this is the wrong move

A store doing a handful of orders a day does not need Multi-AZ, Redis, and a load balancer; a well-backed-up single instance with honest restore tests covers it, and the engineering hours are better spent on the products. This checklist earns its cost when an hour of downtime visibly costs revenue, when sale events multiply baseline traffic, or when subscriptions make silent async failure expensive. Below that line, apply items 3, 5, and 7 only — they are nearly free.

Common mistakes

  • Caching /checkout/ after a plugin or CDN config change — the bug that shows customers each other’s data and ends up in an incident report to your payment processor.
  • Sticky sessions as a substitute for a shared session store: it works until an instance is replaced by the autoscaler mid-shopping-session.
  • Testing performance logged-out and concluding the store scales, when checkout traffic bypasses every cache being tested.
  • Treating gateway webhook retries as a safety net; retries expire, and a webhook endpoint that 500s for a day loses real subscription renewals.

Keeping it under control

  • Re-run the external cache checks after any change to caching plugins, CloudFront behaviours, or headers.
  • Review the Scheduled Actions backlog weekly; past-due growth is the earliest sign of async trouble.
  • Track orders per hour as a first-class metric with anomaly alarms, and annotate deploys against it.
  • Rehearse the peak-sale runbook (scale-up, cache warm, on-call assignment) before the season, not during it.
  • Quarterly restore drill with order-count verification, logged with dates.

Every item here is ordinary discipline; what stores lack is someone accountable for the whole list at once. Running WordPress or WooCommerce on AWS that earns real money deserves an operator, not a hobbyist setup — Stack Harbor runs that exact stack under Enterprise WordPress; book an infrastructure consult.