Design Cost-Optimized Architectures
Cost-Optimized Networking and Delivery
CoreOptimize NAT, endpoint, topology, bandwidth, routing, edge caching, and transfer paths without breaking resilience.
Aligned to the current SAA-C03 exam guide, verified August 16, 2026.
Why this matters
Network charges follow the actual path. The architect must trace bytes across NAT, endpoints, Availability Zones, Regions, origins, hubs, and edge services, then change placement or delivery only after preserving protocol, bandwidth, security, and failure-isolation requirements.
Must Know
- Draw each high-volume flow with source, destination, AZ, Region, service endpoint, and egress device. Hidden cross-AZ or NAT paths often dominate avoidable cost.
- A NAT gateway per AZ improves AZ isolation and can avoid cross-AZ access to a centralized NAT; one shared NAT can reduce fixed resources but creates a broader dependency and may add cross-AZ paths.
- Gateway endpoints for supported services can avoid NAT for those service paths. Interface endpoints add private connectivity and their own cost dimensions; compare actual volume, AZ placement, and security needs.
- Place tightly communicating resources carefully, but never co-locate them in one failure boundary when resilience requires separation.
- VPC peering can be economical for a small mesh; Transit Gateway reduces topology and management complexity for many networks but adds hub processing/attachment considerations.
- Site-to-Site VPN has lower entry overhead and variable internet performance; Direct Connect can fit sustained bandwidth and consistency. Evaluate redundancy and encryption separately.
- CloudFront can reduce origin requests and origin data transfer for cacheable delivery while improving global performance; uncacheable data needs a different optimization.
- Global Accelerator optimizes supported TCP/UDP global paths and availability but is not a cache and should not be selected solely as a transfer discount.
- Use API Gateway or application throttling to protect capacity and cost when the requirement is rate control; load balancers and DNS solve different jobs.
- Cost Explorer and CUR help identify transfer by service/account/dimension; Budgets alerts on thresholds. The architecture still needs path analysis.
Compare and Distinguish
- Single shared NAT vs NAT per AZ: shared can reduce fixed gateway count; per-AZ wins for AZ isolation and local egress paths. The availability requirement decides before cost.
- NAT gateway vs NAT instance: a gateway is managed, scalable NAT with substantially lower operational burden; an instance is customer-managed EC2-based NAT, so compare possible cost with required sizing and throughput plus customer-owned patching, scaling, availability, failover, and operations.
- VPC endpoint vs NAT: an endpoint wins for supported private service traffic when its security/path economics fit; NAT wins for general internet/unsupported public endpoints.
- Peering vs Transit Gateway: direct relationships can be simpler/cheaper at small scale; a transit hub wins as connection count and central routing needs grow.
- VPN vs Direct Connect: lower entry and internet variability versus dedicated consistent bandwidth. Compare steady volume, lead time, resilience, and encryption.
- CloudFront vs Global Accelerator: cache/proxy HTTP delivery and origin offload versus non-cacheable supported TCP/UDP anycast acceleration.
- Cross-AZ vs single-AZ placement: lower transfer path versus required fault isolation; never violate availability to save transfer cost.
Scenario examples
- Scenario: Private workloads in three AZs all use one NAT in a fourth path. Think: compare cross-AZ bytes and failure coupling with per-AZ NAT, then preserve required resilience.
- Scenario: Large S3 traffic exits through NAT. Think: an S3 gateway endpoint changes the path and can reduce exposure and NAT processing.
- Scenario: Hundreds of VPC peerings are hard to govern. Think: Transit Gateway may lower operational complexity even if every individual attachment is not cheapest.
- Scenario: Global users repeatedly fetch cacheable objects. Think: CloudFront serves edge hits and reduces origin work/transfer.
- Scenario: A steady high-volume hybrid flow suffers internet variability. Think: evaluate Direct Connect total economics and redundancy, not headline bandwidth alone.
Exam traps
- One NAT gateway is not automatically the cheapest after cross-AZ data paths and outage impact.
- A NAT instance can appear cheaper, but the customer owns its capacity, patching, scaling, high availability, failover, and ongoing management.
- A VPC endpoint is not universally free and does not replace NAT for every destination.
- Putting all resources in one AZ to avoid transfer violates a multi-AZ requirement.
- Transit Gateway is not always cheaper than a few peering links.
- CloudFront does not cache content configured as uncacheable.
- Global Accelerator is not a CDN.
- Direct Connect alone is not encrypted or redundant.
Key takeaways
- Trace the byte path before changing services.
- Preserve failure isolation while reducing unnecessary NAT, cross-AZ, and cross-Region paths.
- Use endpoints for supported service paths and CloudFront for cacheable delivery.
- Choose hub versus mesh from topology scale and management.
- Size hybrid connectivity from sustained demand, variability, and redundancy.
How it works
- Routes and DNS determine the selected path; NAT, endpoints, hubs, and edge services process traffic on that path.
- CloudFront answers edge requests from cache when eligible and fetches misses from the origin.
- Transit Gateway provides a routing hub; peering routes directly between VPCs.
- VPN or Direct Connect carries hybrid traffic according to configured routing and available redundant paths.
When to use it
- Use per-AZ NAT for strong AZ independence and local paths; centralize only when the tradeoff is explicit.
- Use gateway/interface endpoints for supported service traffic when private access and economics fit.
- Use peering for small direct topologies and Transit Gateway for many networks.
- Use CloudFront for cacheable global delivery and Direct Connect for justified sustained hybrid requirements.
Security and governance implications
- Do not route sensitive service traffic through unnecessary public/NAT paths when private endpoints meet requirements.
- Keep redundant network paths and avoid one centralized egress device becoming the wrong failure boundary.
- Apply least privilege to route, endpoint, DNS, and edge changes.
- Protect origins and apply throttling/WAF at the correct layer.
Operational and diagnostic signals
- For transfer spikes, correlate billing dimensions with flow paths, AZ/Region placement, NAT metrics, and origin logs.
- For unexpected NAT use, inspect private DNS, endpoint policy, routes, and application endpoint selection.
- For edge misses, inspect cache key, TTL, headers/cookies, and response cacheability.
- For hybrid underuse/overrun, compare provisioned bandwidth, actual sustained demand, routing, and redundancy.
More detail
- Network total cost can include hourly resources, processed bytes, cross-boundary transfer, public egress, origin transfer, acceleration, and operational complexity.
- Data locality is useful when it follows access patterns, but unnecessary copies can increase storage, consistency, and transfer cost.
- Throttling can cap abusive or accidental demand but must preserve legitimate throughput and user experience.
- Use detailed billing data to locate cost, then network telemetry and topology to explain it.
Ready for the quiz?
- When does per-AZ NAT beat a shared NAT?
- What traffic can a VPC endpoint remove from NAT?
- Why can co-location be a false economy?
- When does Transit Gateway beat peering?
- How do CloudFront and Global Accelerator differ economically and technically?
Related objectives
- D4.4.K1
- D4.4.K2
- D4.4.K3
- D4.4.K4
- D4.4.K5
- D4.4.K6
- D4.4.K7
- D4.4.S1
- D4.4.S2
- D4.4.S3
- D4.4.S4
- D4.4.S5
- D4.4.S6
- D4.4.S7