Inter-Region Replication Cost
also called Cross-Region Transfer Cost, Replication Egress
The recurring transfer and duplicate-storage charge created by keeping a copy of data in another region, which scales with write volume and replica count rather than with dataset size.
A multi-region design is usually costed from the storage line: two copies of 50 TB instead of one. The line that grows without anyone deciding is transfer, because replication charges follow the write rate, and the write rate is a property of the application that changes every quarter.
The arithmetic is short enough to do in a design review. Cross-region transfer is charged per gigabyte leaving a region, with published rates commonly in the $0.02 per GB range between regions and cross-zone traffic inside a region billed at about $0.01 per GB in each direction (AWS list prices, 2025). Replicating 2 TB of writes a day to one other region is about 2,000 GB x $0.02 = $40 a day, roughly $15,000 a year - and to two regions, double it, plus a duplicate of the storage in each.
Why it matters
It converts an availability decision into a recurring operating cost that scales with product growth, not with the decision. A second region signed off on a one-off basis grows its own bill as write volume rises, and the number nobody holds is bytes replicated per user action.
It also sits on the critical path of several architectural choices at once. Synchronous cross-region replication buys RPO = 0 and pays a round trip of tens of milliseconds on every commit - roughly 60–80 ms between US coasts - as well as the per-gigabyte charge. Asynchronous replication removes the latency and keeps the charge. Cost and consistency are decided together, and most designs discuss only one of them.
Implementation patterns
- Compress the replication stream. Write-ahead logs compress 3–5x, and compression changes bytes without changing the durability promise. This is the highest-value change available and is usually a configuration flag.
- Replicate what is needed, not everything. Filter by table, prefix or tenant; derived data that can be recomputed in the target region should be recomputed there rather than shipped.
- Prefer one hop over a mesh. Replicating A to B and A to C costs twice; A to B and B to C costs the same per gigabyte but halves the primary's egress and adds lag - a real trade, not a free one.
- Batch and coalesce. An asynchronous target can take a compacted stream in which multiple updates to the same row become one, which is a direct reduction in bytes.
- Measure bytes replicated per user action as a product metric, so a feature that triples write volume is visible at design time.
- Check the storage class of the target. A standby copy that is never read can live in a colder tier, provided its minimum duration and retrieval cost are acceptable for a disaster scenario.
Industry example
The economics are a standard part of published multi-region guidance, and the common recommendation follows the arithmetic: keep one writable region with asynchronous replicas and promote on failure, rather than running active-active, unless the business genuinely needs regional write locality. The transfer charge is what makes active-active expensive in operation as well as in complexity, because every write crosses a boundary in both directions and conflict resolution adds its own traffic. Providers have also begun waiving egress fees for customers migrating data off the platform entirely, which is worth knowing precisely because it does not apply to ongoing replication.
Failure scenarios
- A retry loop that triples cross-region traffic, invisible for weeks because billing data lags and is aggregated per service rather than per code path.
- Chatty replication of ephemeral data - session state, cache fills, telemetry - that nobody intended to replicate.
- A full re-sync after a replica falls behind its retention window, producing a one-off transfer charge the size of the whole dataset.
- An orphaned replica in a region nobody uses, discovered during an audit, billing storage and transfer for a project that was cancelled.
- Replication lag treated as free, so a failover promotes a replica that was minutes behind and the data loss is discovered after the incident.
Trade-offs
What is gained is survival of a region loss, lower read latency near users, and in some cases a regulatory requirement satisfied. What is paid is per-gigabyte transfer that grows with the product, duplicate storage, operational complexity in failover, and - for synchronous designs - latency on every commit. The honest framing for the review is cost per year of avoided downtime risk, because stated that way the choice between a hot replica and a tested restore from backup becomes a question with an answer rather than a matter of taste.
When not to use it
For a system whose recovery objective is measured in hours, a cross-region backup with a rehearsed restore is dramatically cheaper than continuous replication and is the right answer far more often than it is chosen: backups are compressed, deduplicated and infrequent, so the transfer line is a fraction. Skip inter-region replication entirely for data that can be regenerated from a source of truth, and for internal tools where a day of unavailability costs less than the replication does. The rule: replicate continuously when the recovery objective is minutes; restore from backup when it is hours.
Interview question
Q: Finance queries a cross-region transfer line that has grown 40% in two quarters while the dataset grew 10%. What is happening and what do you do about it?
What a strong answer covers: recognising that transfer follows write rate rather than dataset size, so the question is which writes grew; auditing what is being replicated and finding the ephemeral or derived data that should not be; compression as the first change because it preserves the durability promise; filtering and coalescing next; the hop topology as a second-order lever; adding bytes-replicated-per-user-action as a standing metric; and separately re-examining whether the recovery objective justifies continuous replication at all rather than a tested restore.
Quick check
Quiz: Why does a replication bill grow when the dataset does not? It is charged on bytes transferred, which follows the write rate, so more updates to the same rows cost more without adding storage.
Flashcard: First change to cut a cross-region replication bill without changing RPO? Compress the stream - logs compress 3–5x and every replica still acknowledges before commit.