agent told us to consolidate to one AZ - it never priced the cross-AZ traffic the database replication would generate
Prices the cross-AZ replication traffic a cost agent skipped when it recommended consolidating everything into one AZ. Use when a consolidation plan ignores data-transfer costs or weakens HA. Key trigger: database replication or multi-AZ traffic missing from the savings model.
TL;DR: Do not consolidate to one AZ until you have priced the cross-AZ traffic the database replication, cache sync, and service mesh generate, because that traffic is charged per gigabyte in both directions. Pull it from VPC flow logs, multiply by the cross-AZ rate, and compare against the instance-hour savings. In most cases the transfer cost plus the lost redundancy kills the recommendation.
What the agent's model contained:
savings from removing 2 AZs of instances: $900 / month
cross-AZ data transfer line item: (missing)Measure current cross-AZ traffic with VPC flow logs, filtering for source and destination in different AZs of the same region. Expected: gigabytes per month for database replication, cache replication, and east-west service traffic.
Price it at the cross-AZ data-transfer rate, charged in both directions, and add it as an explicit line in the consolidation model. Expected: a monthly transfer figure to set against the instance savings.
Add the redundancy cost honestly: single-AZ means any AZ impairment becomes a full outage, so get human sign-off that the business accepts it. Expected: a written risk acceptance, not an agent's silent assumption.
If consolidation still wins, do it for stateless tiers only and keep the data tier multi-AZ. Expected: the database keeps its standby while the web tier consolidates.
Patch the agent's template so any AZ-consolidation recommendation requires a measured cross-AZ traffic figure before it can be emitted. Expected: future recommendations include the transfer math or refuse to recommend.
Use this when
- An agent recommends single-AZ deployment to save instance hours
- The savings model has no data-transfer line item
- Database replication, Redis or Memcached sync, or Kafka mirroring crosses AZ boundaries
- Someone proposes removing the standby AZ to cut costs
Not for this skill when
- The workload is genuinely stateless with no cross-AZ chatter, and flow logs confirm it
- You are comparing regions rather than AZs, which is cross-region pricing instead
- The goal is latency rather than cost, which is an architecture decision, not a savings plan
Variant phrasings
- consolidate to one AZ to save money
- cross AZ data transfer charges explained
- is multi-AZ worth the cost
- database replication traffic cost between AZs
Why it happens
Instance hours are visible in every rightsizing report while cross-AZ traffic hides in flow logs nobody queried. The agent sees N instances across 3 AZs, divides by 3, and books the savings, never modeling that the replication traffic keeping those AZs consistent is metered per gigabyte both ways. Redundancy is treated as waste because the model has no line for the cost of an outage.
Edge cases
- Some managed services absorb cross-AZ replication into their price while self-managed databases on EC2 pay it as data transfer, so the answer depends on who runs the database
- IPv6 and intra-region VPC peering have their own transfer quirks that a single rate will miss
- Traffic between AZs in the same region is charged, but traffic to the same AZ is not, so placement details change the number
- Consolidating the standby without consolidating the primary just moves the traffic, it does not remove it
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_PsFt9lTmdSl2r9XFhdq1PQ