Write to one Region mode (single primary)

The write to one Region write mode, illustrated in the following diagram, is active-passive and routes all table write operations to a single active Region. (DynamoDB doesn’t have a notion of a single active Region; the layer outside DynamoDB manages this.) The write to one Region mode works well for MREC tables that need to avoid write conflicts by ensuring that write operations flow only to one Region at a time. This write mode helps when you want to use conditional expressions and can't use MRSC for some reason, or when you need to perform transactions. These expressions aren’t possible unless you know that you’re acting against the latest data, so they require sending all write requests to a single Region that has the latest data.

When you use an MRSC table, you might choose to generally write to one Region for convenience. For example, this can help minimize your infrastructure build-out beyond DynamoDB. The write mode would still be write to any Region, because with MRSC you could safely write to any Region at any time without concern of conflict resolution that would cause MREC tables to choose to write to one Region.

Eventually consistent read operations can go to any of the replica Regions to achieve lower latencies. Strongly consistent read operations must go to the single primary Region.

It’s sometimes necessary to change the active Region in response to a Regional failure, as discussed later. Some users change the currently active Region on a regular schedule, such as implementing a follow-the-sun deployment. This places the active Region near the geography that has the most activity (usually where it’s daytime, thus the name), which results in the lowest latency read and write operations. It also has the side benefit of calling the Region-changing code daily, and making sure that it’s well tested before any disaster recovery.

The passive Region(s) might keep a downscaled infrastructure surrounding DynamoDB that gets built up only if it becomes the active Region. This guide doesn’t cover pilot light and warm standby designs. For more information, you can read the blog post Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby.

Using the write to one Region mode works well when you use global tables for low-latency, globally distributed read operations. An example is a large social media company that needs to have the same reference data available in every Region around the world. They don’t update the data often, but when they do, they write to only one Region to avoid any potential write conflicts. Read operations are always allowed from any Region.

As another example, consider the financial services company discussed earlier that implemented the daily cash-back calculation. They used write to any Region mode to calculate the balance but write to one Region mode to track payments. This work requires transactions, which aren't supported in MRSC tables, so it works better with a separate MREC table and write to one Region mode.