A primary database writes 2 TB a day and replicates synchronously to two other availability zones in the same region. Cross-AZ transfer is charged at $0.01 per GB in each direction (AWS list price, 2025). Which change cuts the transfer bill most without changing RPO?

The arithmetic first

2 TB a day to two replicas is 4 TB a day crossing a zone boundary. Cross-AZ traffic is billed in both directions, so the effective rate is about $0.02 per GB: 4,000 GB x \(0.02 = **\)80 a day, roughly $2,400 a month, about $29,000 a year** for moving data a few kilometres.

That figure is the point of the question. Teams audit instance sizes for months and never look at a transfer line that costs as much as several instances.

Why compression is the answer

Database write-ahead logs are highly compressible - repeated column names, row headers, similar values, and in many engines whole pages. A 3x to 5x ratio on log data is ordinary, which takes the bill from $2,400 to between $500 and $800 a month.

The property that makes it the right answer here is that compression changes the number of bytes, not the commitment about data loss. Every replica still acknowledges before the primary commits, so RPO stays at zero. What it costs is CPU on both ends and a little latency for the compression step, both small next to a cross-zone round trip of a millisecond or so. Most mainstream engines ship this as a configuration flag.

Why the other options fail

• "Replicate to one zone instead of two." It halves the bill and it halves the redundancy: a two-zone deployment survives one zone loss with no spare, so the next fault is an outage. This is a durability decision disguised as a cost saving, and the question asked for one that does not change the guarantee.
• "Switch to asynchronous replication." The largest saving of all, because an async replica can be fed a batched and compacted stream - and it is exactly what the question excludes. Async means acknowledged writes can be lost on failover, which is an RPO change. Make it deliberately or not at all.
• "Larger instances with faster network." Network capacity is not the constraint; 4 TB a day is about 400 Mbps. Transfer is billed per gigabyte, not per gigabit, so this raises the compute bill and leaves the transfer bill untouched.

When this is the wrong answer

When the write volume is small. At 50 GB a day the whole transfer line is $30 a month and no amount of tuning is worth an engineer's afternoon. Compression is also wrong when the payload is already compressed - a log of image blobs or encrypted fields will not shrink, and you have bought CPU for nothing. The honest first move in either case is to check whether 2 TB a day of writes is necessary: indexes updated for nobody, audit rows written per read, and debug columns are a larger saving than any transport change, because they remove the bytes at the source rather than making them cheaper to move.