Aurora Global Database
Pricing the Second Region Before You Attach It: Replicated Write I/Os Ignore I/O-Optimized
- Replicated write I/O rate ($0.20/M in the us-east-1 example) multiplied per secondary Region.
- Replicated write I/Os billed under both Aurora Standard and I/O-Optimized.
- Replication data transfer (~2.75 KB per write I/O at $0.02/GB in the same example).
- Headless secondary clusters as storage-only DR (must add an instance before switchover/failover).
Production premise
What you are buying is DR posture. What you are paying is a bill that scales as N × full copy.
Every secondary Region runs a full copy of the database: its own instances, its own storage at the same GB as the primary, its own read I/Os. On top of that come the replicated writes. The primary's storage layer ships every write to each secondary Region, and AWS bills those replicated write I/Os per secondary, at the same count as the primary's in-region write I/Os. In AWS's us-east-1 worked example, that is $0.20 per million. The replication stream itself also crosses inter-region transfer: about 2.75 KB per write I/O, at $0.02/GB in the same example.
Aurora I/O-Optimized, the configuration that replaces per-I/O charges with a higher storage rate, eliminates the in-region I/O charges. It does not eliminate replicated write I/Os. AWS's own I/O-Optimized example still bills the secondary $9 a month for 45 million replicated writes.
Failure mode & inflection point
Write-amplified workloads — chatty commits, small transactions — discover that going I/O-Optimized did not fix global costs. The replicated-write line item is untouched by it. At 45 million writes a month, the charge is $9 per secondary: trivial. At 4.5 billion writes a month, a sustained ~1,700 write I/Os per second, the charge is $900 per secondary per month. That is before a single instance hour, multiplied by every secondary Region.
Storage-heavy databases get their own version of the bill: they re-pay full GB-month storage rates in every Region, under whatever configuration each Region runs.
Production guardrail
Default to one warm secondary, and put it in the Region pair closest to your primary — that pairing gives you the lowest transfer cost and the lowest replication lag. Add the secondary only when a named requirement exists: RPO in seconds, a latency SLO, or data residency.
Configure secondaries as Aurora Standard. I/O-Optimized's higher storage rate buys nothing for a Region that mostly receives writes.
If the secondary is for DR only and "add an instance first" fits your RTO, use a headless secondary cluster — storage replicated, no compute attached, instances added only when it must take over. That is the cost floor. AWS publishes no number for how long adding the instance takes, so do not plan around an assumed figure. Add one in a drill, time it, and put the measured number into your RTO.