Architects propose multi-AZ deployment for a county permitting API to improve reliability. Finance will not approve until the cost impact of that HA choice is visible. What should the solutions architect emphasize before approval?
Select an answer to reveal the explanation.
Short Explanation
HA is not a free lunch. Spreading across two Availability Zones often means paying for two of several things—and leadership should see that bill before they stamp yes. Visibility first, then the reliability win.
Full Explanation
Multi-AZ placement improves fault isolation for a county permitting API by spreading capacity across independent failure domains, but that reliability choice is not free. Duplicate compute, standby or replica storage, load balancer coverage, and cross-AZ data transfer can materially raise the monthly bill—often approaching a near-doubling of several line items versus a single-AZ baseline. Before finance approves the HA design, the solutions architect should make those incremental costs explicit in estimates and ongoing showback so leadership can weigh reliability against budget. Claiming multi-AZ always reduces total cost because idle capacity is free is incorrect; unused replicas and cross-AZ chatter still accrue charges. Treating Availability Zones as free marketing labels ignores real capacity and transfer pricing differences that appear on the invoice. Asserting that Organizations SCPs allow only single-AZ designs misstates SCP purpose: SCPs constrain API actions and services, not a blanket ban on multi-AZ architecture patterns. Exam caveat: not every component doubles one-for-one (managed multi-AZ databases price differently than two identical EC2 fleets), so model the actual services in the design. Operational check: produce a side-by-side estimate for single-AZ versus multi-AZ for the permitting stack, highlight cross-AZ transfer assumptions, and attach the delta to the change request before go-live approval.