Amazon Aurora Global Database
Does ZopNight manage Amazon Aurora Global Database?
Aurora Global Database adds a full secondary Aurora cluster in every additional region, each billing its own compute and storage, plus replicated write I/O charges per million writes crossing regions. ZopNight discovers global databases via a dedicated provider on the 6-hour cycle and attributes cross-region cost to flag underused secondaries.
Rules that fire on Amazon Aurora Global Database
No active rule family targets Amazon Aurora Global Database today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost tracking only. |
An Aurora Global Database replicates a primary Aurora cluster to secondary regions for disaster recovery and low-latency reads. Each secondary region adds full cluster compute plus replicated write I/O charges, so unused secondary regions are an expensive safety net.
What each region adds to the bill
A global database is priced as the sum of its regional parts plus the glue between them. Every secondary region runs a complete Aurora cluster at normal Aurora rates: instance-hours for its readers, storage for its copy of the data. On top of that, replicated write I/O bills per million write operations shipped to each secondary, and cross-region data transfer applies to the replication stream. Adding a second region roughly doubles the database’s fixed floor; adding a third triples it; and the write-replication charges scale with primary write volume times the number of secondaries.
Secondary regions under scrutiny
ZopNight discovers global databases through a dedicated provider on the 6-hour cycle and attributes cost per region from Cost Explorer or CUR 2.0, which is what makes the safety net’s price visible as a distinct number. The recommendations focus on underused secondaries: regions added for a latency experiment whose readers receive no queries, and DR regions provisioned with reader instances sized like production when headless or minimal configurations would hold the recovery objective at a fraction of the compute.
When the safety net overshoots
The honest use case, regulatory DR with tested failover, earns its cost. The waste variants look identical on an architecture diagram: a secondary added “while we were setting things up” for a market entry that never happened; readers in the secondary sized to serve production traffic that has never been routed there; and global databases in staging environments, faithfully replicating test data across an ocean because staging was cloned from production’s template.
Examining the topology in RDS
The RDS console’s Databases view groups global databases with their primary and secondary clusters per region. For each secondary, two numbers tell the story: reader connection counts (is anything using the low-latency copy?) and the failover objective the business actually signed up for (does it need running readers at this size, or would a smaller footprint meet it?).