Is RDS Multi AZ Worth the Money for a Small Ecommerce Store?
Managed cloud services sell peace of mind. You click a few buttons and somebody else handles failover, patching and backups. For a lot of businesses that is exactly right.
But the price is real, and it grows quietly. In a project I wrote up in Cutting AWS Costs by Over 50%, an ecommerce client doing roughly $1.5 million a year was paying more than $4,500 a month on AWS. A managed search cluster was about $1,900 of that, a Multi AZ MySQL database on RDS was about $1,400, and those two items made up more than 70 percent of the bill.
The application itself was fine. The spend came from services that had grown with the company without anyone asking whether they still fit.
What Multi AZ really buys you
Multi AZ keeps a standby copy of your database in another availability zone. If the main one fails, AWS switches over automatically, usually within a minute or two. You pay for the extra capacity whether or not a failure ever happens.
That is a good deal if an hour of downtime would cost you more than the premium. The mistake is paying the premium without ever doing that arithmetic.
Questions I ask before recommending anything
I do not start with technology. I start with the business:
- What does an hour of downtime cost you, in lost orders and in trust?
- Is a short read only period acceptable, or must the site accept orders at all times?
- How much of your traffic is served from a cache or a CDN, so the database is not hit by every visitor?
- Are your payment and order flows safe to retry, so a brief interruption does not create duplicates?
- Who on your team can respond if something goes wrong at night?
In that project, the customer facing pages were mostly cached with CloudFront and Redis, and payment processing had idempotent retries. Those two facts changed the risk calculation a lot. The leadership team could tolerate a short maintenance window, and they wanted the savings to go into customer acquisition.
Laying the options side by side
Put the choices in front of the decision makers in plain numbers. In that project I compared keeping everything managed, moving only search to EC2, and moving both. Each option had a monthly cost, an annual difference and a risk description. Once the money and the risk were on one page, the conversation became easy, and the CTO who had been nervous about leaving managed failover could judge the trade for himself.
What replacing it responsibly looks like
If you decide to run the database yourself on EC2, the work is in the surrounding discipline, not the install:
- Size the instance from real measurements of memory and query load, with headroom.
- Take automated backups and copy them somewhere else.
- Replicate to a warm standby in another availability zone, so recovery is a short switchover and not a rebuild.
- Test restores on a schedule. A backup you have never restored is a hope, not a backup.
- Tighten access, keeping permissions narrow and auditable.
- Write down the failure playbook, and rehearse it once.
We ran the old and new systems side by side for about three weeks and practiced failure drills before the cutover.
The cost you cannot skip
Running it yourself means somebody patches, monitors and upgrades it. That is a real ongoing cost. In that project I stayed on a light monthly retainer for exactly that work, such as reviewing slow queries and handling operating system updates. The bill still came down to around $1,930 a month, a drop of about 57 percent, but only because the operational work was planned and paid for.
When I would keep it managed
I would leave Multi AZ in place if order volume is high enough that minutes of downtime are expensive, if your team has nobody who can respond to database issues, or if your compliance rules require it. The right answer changes as a business grows, and revisiting it every year or so is healthy.
The goal is not to run everything on the cheapest option. It is to pay for resilience that matches how much failure would really hurt.
If your AWS bill has crept up and you are not sure why, email kevin@kevinhq.com with a screenshot of your cost breakdown by service. The top three lines usually tell me where to look.