# 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.

Source: https://zop.dev/integrations/aws/aurora-global-db
Updated: 2026-08-19

---

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?).