A chatty pair of services runs one task in each of two Availability Zones, and cross-AZ data transfer is the largest network charge. The design allows both tasks to run in the same zone. What cuts that charge?
Select an answer to reveal the explanation.
Short Explanation
The expensive part is the conversation crossing zones, not the fact that the tasks exist. You put the pair in the same zone when the design allows it. A NAT gateway in a third zone adds a detour, it does not make the path free.
Full Explanation
Inter-AZ traffic is billed, and a chatty pair split across zones pays that rate on every byte. Placing both tasks in one zone keeps the flow local and drops the cross-AZ charge, which the design explicitly allows. A NAT gateway in another zone adds processing and another AZ hop. Cross-zone load balancing spreads traffic across zones; it does not waive the charge. Public IPs do not make AZ transfer free. Caveat: same-zone placement gives up AZ isolation for that pair, so do it only where the design said a single zone is acceptable, and keep the stateless tier spread out if that was the resilience requirement. Operational check: the tasks should share an Availability Zone, and the cross-AZ bytes for that pair should fall. Set the service or the task placement so both tasks prefer the same Availability Zone, and keep them there only because the design allowed it. Measure the cross-AZ bytes before and after. A NAT gateway in a third zone adds cost. Cross-zone load balancing would spread a stateless tier, which is the opposite of this saving. If resilience later requires two zones, accept the charge instead of forcing the pair together.