Asynchronous replication trades durability for latency

The primary acknowledges a write as soon as it has it and ships it to other regions afterwards. Writes are as fast as one region allows, and the other regions trail slightly behind.

The trailing is the catch. A write in the gap between replying and copying exists only in the primary's region, and if that region goes, the gap goes with it. AWS's disaster recovery guidance is plain that even a well-built asynchronous setup leaves both recovery time and recovery point above zero. The real RPO is the gap at the worst moment, not the typical one (RTO and RPO name the two costs of an outage), and an asynchronous system cannot know an upper bound on that gap.

It is a common default. Relational read replicas are fed this way, as are Redis replicas and DynamoDB global tables across regions. It is the right trade for plenty of data. Whether it suits this design is a question about what users were promised, not about the database.

When the primary's region fails, the choice is between waiting for it and promoting a replica that is missing the gap.