A permit application's chatty app tier and database generate large cross-AZ data-transfer charges inside one Region. Which cost-aware placement approach is most appropriate while retaining HA?
Select an answer to reveal the explanation.
Short Explanation
Chatty neighbors should live on the same block, with a spare house on the next block for HA. Cut pointless cross-AZ chatter without abandoning Multi-AZ design.
Full Explanation
Chatty permit application tiers that exchange large volumes with their database inside one Region can generate noticeable cross-AZ data-transfer charges. The cost-aware approach is thoughtful colocation: keep primary app-to-database conversations local within AZ pairs where possible, while still spanning Availability Zones for Multi-AZ high availability of both tiers. That reduces unnecessary cross-AZ chatter without abandoning HA for citizen-facing permitting. Placement groups, subnet mapping, and connection locality awareness in the app help implement the pattern.
Placing every instance in a different Region so cross-AZ fees become cross-Region fees fails by concept: cross-Region transfer is typically more expensive and adds latency. Disabling Multi-AZ entirely and collapsing app plus database onto one host eliminates transfer but also eliminates HA—unacceptable for permitting uptime. Hairpinning database queries through the public internet to avoid AZ transfer pricing worsens security and usually cost.
Exam caveat: some cross-AZ traffic is inherent and desirable for Multi-AZ failover readiness; the goal is eliminating unnecessary chatter, not creating a single-AZ architecture disguised as savings.
Operational check: map app and DB subnet placements, use VPC Flow Logs or Cost Explorer data-transfer types to quantify cross-AZ bytes from the permit stack, redesign so primary pools talk locally with standby capacity in a second AZ, remeasure transfer charges, and validate failover drills still meet municipal RTO.