A parks-and-recreation booking app’s RTO can be met with multi-AZ in one Region. Stakeholders propose active-active in three Regions “for prestige.” What should the cost-aware architect recommend?

When a parks-and-recreation booking app’s RTO is already met by multi-AZ in one Region, adding active-active in three Regions “for prestige” is a cost anti-pattern. Cost-aware architects keep the design single-Region multi-AZ unless RTO/RPO, residency, or explicit continuity requirements justify multi-Region active traffic and its replication and transfer premiums. That recommendation works because multi-Region is a requirement-driven premium—dual stacks, cross-Region database replication, and global traffic management multiply run-rate without improving a satisfied stopwatch. Enabling continuous cross-Region database replication and dual active stacks in three Regions with no RTO driver fails by buying unused geographic complexity. Replicating every CloudWatch log and every S3 object to all commercial Regions by default fails conceptually as unconstrained data fan-out that inflates storage and transfer without a stated recovery or analytics need. Requiring citizens to pin DNS to a far Region to generate cross-Region charges for testing only fails as both poor UX and artificial cost generation unrelated to resilience goals. Exam caveat: if leadership later tightens RTO below what one Region can guarantee, revisit multi-Region with a written continuity driver—do not confuse today’s correct single-Region choice with a forever ban on multi-Region. Operational check: record the approved RTO/RPO against the multi-AZ design, estimate incremental monthly cost of a three-Region active proposal, and require a signed requirement change before any cross-Region active path is funded.