Sign in Subscribe

Design Cost-Optimized Network Architectures for AWS Certified Solutions Architect – Associate (SAA-C03)

Design Cost-Optimized Network Architectures for AWS Certified Solutions Architect – Associate (SAA-C03)

1. Why AWS network cost matters

For SAA-C03, network cost is one of those topics that punishes shallow thinking. The bill is rarely about one service in isolation. It is about the traffic path: which AZs traffic crosses, whether it uses NAT, whether it goes through Transit Gateway, whether it leaves a Region, and whether it could have stayed private through an endpoint instead.

The best exam mindset is simple: follow the traffic, then follow the charges that stack on that path. Also remember that “lowest cost” on the exam means the lowest cost architecture that still meets the stated requirements for availability, security, and operational simplicity.

Pricing note: AWS networking prices vary by Region, path, and service. The exam is conceptual; real designs should always be validated with current pricing.

2. How AWS network charges stack on a traffic path

AWS network cost usually comes from a few recurring dimensions:

  • Hourly infrastructure charges: NAT Gateway, Interface Endpoints, Transit Gateway attachments, Direct Connect ports.
  • Per-GB processing charges: NAT Gateway, Interface Endpoints, Transit Gateway.
  • Data transfer charges: internet egress, cross-AZ transfer, inter-Region transfer, some hybrid paths.
  • Service-specific request or transfer charges: S3, CloudFront, load balancers, and others have their own pricing models.

That is why one path can accumulate multiple cost components.

Common path examples:

  • EC2 -> NAT Gateway -> public endpoint: NAT hourly + NAT per-GB + possible transfer charges depending on path.
  • EC2 -> S3 Gateway Endpoint -> S3: no gateway endpoint hourly charge, but normal S3 charges still apply where relevant.
  • EC2 -> Interface Endpoint -> service API: endpoint hourly + per-GB, plus service charges as applicable.
  • VPC -> Transit Gateway -> VPC: TGW attachment-hour + TGW per-GB, plus any other transfer dimensions on the full path.

Important correction: if an instance in a private subnet reaches the public S3 endpoint through a NAT Gateway, do not think of it as “going out to the public internet” in the everyday sense. The key distinction is that it is using NAT-based access to a public service endpoint instead of a VPC endpoint-based private path. That still matters for both cost and design.

3. VPC placement, subnet design, and hidden transfer cost

A private subnet does not mean “no outbound access.” In plain English, it means that subnet doesn’t have a direct route to an Internet Gateway. Outbound access can still exist through a NAT Gateway, NAT instance, VPC endpoints, VPN, Direct Connect, or IPv6 egress-only internet gateway.

The biggest hidden cost driver in VPC design is unnecessary traffic crossing AZ or Region boundaries. Common examples include:

  • Application instances in AZ-A repeatedly calling a database writer in AZ-B.
  • Private subnets in AZ-A routing to a NAT Gateway in AZ-B.
  • Centralized inspection or logging that forces east-west traffic through another AZ.
  • Load balancers forwarding requests to targets in a different AZ.

For production, multi-AZ is usually the right answer. The goal isn’t to eliminate cross-AZ traffic altogether. That’s not realistic. It is to eliminate unnecessary cross-AZ traffic on the busy path.

Inter-Region reminder: replication, cross-Region app calls, inter-Region peering, and inter-Region Transit Gateway designs can become expensive quickly. If traffic is continuous, inter-Region cost can dominate the architecture.

4. NAT Gateway optimization and NAT instance caveats

NAT Gateway is a managed IPv4 egress service for private subnets, but it is a zonal resource. It does not provide cross-AZ failover by itself. For resilient and locality-aware design, deploy one NAT Gateway per AZ and route each private subnet to the NAT Gateway in the same AZ.

Per-AZ route pattern:

Private subnet route table in AZ-A: 0.0.0.0/0 -> nat-az-a

Private subnet route table in AZ-B: 0.0.0.0/0 -> nat-az-b

This reduces cross-AZ transfer and avoids making other AZs dependent on one NAT Gateway’s AZ.

Single NAT Gateway design can be acceptable for small dev or low-criticality environments, but in production it creates a zonal dependency for egress and may add cross-AZ charges.

NAT instance can be cheaper in narrow cases, but the trade-off is real. With a NAT instance, you’ve got a lot more to own yourself: you need to disable source/destination checks, size it properly, patch it, monitor throughput, design failover, and then pay for the EC2 instance, EBS, and the related network costs. That’s a lot of operational overhead. For exam purposes, NAT Gateway usually wins when the question emphasizes managed service, high availability, or low operational overhead.

IPv6 note: native IPv6 internet egress does not use NAT Gateway. Use an egress-only internet gateway for outbound-only IPv6 internet access. In some IPv6-only designs, NAT Gateway can support IPv6-to-IPv4 access through DNS64/NAT64 patterns, but that is a specific architecture, not the default mental model.

5. Endpoint design deep dive: Gateway vs Interface Endpoints

VPC endpoints are one of the highest-yield cost topics on SAA-C03.

Gateway Endpoints are for S3 and DynamoDB only. They’re Regional, they get associated with selected route tables, and they don’t have hourly endpoint charges. That’s a big part of why they’re so cost-effective. AWS adds routes for AWS-managed prefix lists to those route tables; you do not create a special 0.0.0.0/0 exception manually.

Example concept:

pl-aws-s3-prefix-list -> vpce-gateway-id

Because that route is more specific than the default route to NAT, matching S3 traffic uses the endpoint path.

Interface Endpoints use AWS PrivateLink and create ENIs in your subnets. That means they consume subnet IP addresses, they usually have hourly plus per-GB charges, and if you want resilient access, you’ll often deploy them in multiple AZs. Pricing varies by service and Region.

The most important implementation detail is private DNS. If private DNS is enabled and your VPC DNS settings are set up correctly, clients can often keep using the normal AWS service name and still get routed to the private endpoint. That’s one of those details that feels invisible when it works, which is exactly why people forget to check it. If private DNS is disabled or hybrid DNS is misconfigured, clients may still resolve the public endpoint and keep using NAT.

Security controls you should know:

  • Endpoint policies can restrict what a gateway or interface endpoint can access.
  • Interface endpoints use security groups.
  • S3 bucket policies can restrict access to a specific VPC endpoint ID.

Example S3 bucket policy idea:

Condition: StringEquals aws:sourceVpce = vpce-12345

Exam rule: private subnet + S3 or DynamoDB usually points to Gateway Endpoint. Private access to other AWS service APIs usually points to Interface Endpoint.

6. VPC peering, Transit Gateway, and centralized inspection

VPC peering is best for a small number of VPCs with simple direct connectivity. It’s non-transitive, which is the detail people forget under pressure. One peered VPC can’t become a transit path for another VPC’s Internet Gateway, NAT Gateway, or VPN edge. Same-Region peering has no hourly peering connection charge, but transfer charges can still apply depending on same-AZ, cross-AZ, and inter-Region context.

Transit Gateway (TGW) is the right mental model for many-VPC, multi-account, or hybrid hub-and-spoke designs. TGW usually bills you through attachment-hours and per-GB processing, and depending on the exact route, other transfer charges can still stack on top of that. That’s why I always tell teams to follow the traffic, not just the headline service choice. TGW does not magically make an architecture resilient; resiliency depends on attachment design, route segmentation, Region strategy, and workload placement.

If the architecture includes centralized inspection, also know Gateway Load Balancer (GWLB). It’s commonly used when you need to insert third-party firewalls into the traffic path. That kind of design can absolutely improve governance and security, but every extra hop tends to add cost and latency. The trade-off is real, and on the exam you need to recognize when it’s justified. Centralized egress through TGW + inspection VPC + GWLB is a valid enterprise pattern, but it can create tromboning and even DNS or asymmetric-routing surprises if route and name-resolution design are inconsistent.

7. Hybrid connectivity: VPN vs Direct Connect

Site-to-Site VPN provides encrypted connectivity over the internet and is usually the faster, lower-entry-cost option. Direct Connect (DX) provides private connectivity, but it is not encrypted by default. If encryption is required, pair DX with VPN or use MACsec where supported.

For the exam:

  • VPN: quick deployment, moderate traffic, backup path, lower fixed commitment.
  • DX: sustained high-volume traffic, more predictable latency, private connectivity.

DX economics can include dedicated or hosted connections, Direct Connect Gateway designs, transit VIF usage, and redundancy across links or locations. That means “DX is cheaper” is only true in the right traffic profile. A common enterprise answer is DX for primary + VPN for backup, often aggregated through Transit Gateway.

8. Load balancers, CloudFront, and Global Accelerator

Load balancers affect both traffic flow and billing.

ALB is usually the right choice for HTTP/HTTPS and Layer 7 routing. It spreads requests across enabled AZs and can forward traffic to targets in multiple AZs, which means target placement can quietly create cross-AZ transfer on the request path. That’s one of those details that looks harmless in a diagram but shows up on the bill later. ALB pricing uses LCUs.

NLB is for TCP/UDP and high-performance Layer 4 scenarios. Cross-zone load balancing behavior is configurable, so do not assume it behaves exactly like ALB. NLB pricing uses NLCUs.

CloudFront can reduce origin load and may reduce total cost, but only when the cache profile supports it. Whether CloudFront saves money depends on things like cache hit ratio, request volume, object size, viewer geography, and origin pricing. It’s a great service, but it’s not a magic cost reducer in every case. It is great for global users, static assets, and cacheable APIs. It is not an automatic cost win for highly dynamic content.

Global Accelerator is not primarily a cost-optimization service. Think of it when the question emphasizes static anycast IPs, fast global failover, or improving global performance for non-cacheable applications.

9. Security vs cost in network architecture

Sometimes the cheapest path is not the right path. Security requirements often intentionally increase network cost:

  • Private service access through endpoints instead of public endpoints.
  • Centralized inspection using TGW, GWLB, or AWS Network Firewall.
  • Endpoint policies and bucket policies to reduce exfiltration risk.
  • Distributed NAT or distributed endpoints to improve fault isolation.

That is normal. On SAA-C03, if the scenario requires private connectivity, least privilege, or compliance controls, do not choose a cheaper public path that violates the requirement.

10. Troubleshooting unexpected network spend

If network charges spike, use a simple workflow:

  1. Find the billing dimension in AWS billing and cost reporting tools: NAT processed bytes, TGW bytes, inter-Region transfer, cross-AZ transfer, endpoint charges.
  2. Map charges to traffic paths using flow logs, Transit Gateway flow logs, and load balancer metrics.
  3. Validate routing: check whether private subnets are using same-AZ NAT, whether gateway endpoint routes are associated with the right route tables, and whether TGW routes are propagating as intended.
  4. Validate DNS: confirm interface endpoint private DNS is working. Misresolution to public endpoints is a classic reason traffic still uses NAT.
  5. Check locality: look for app-to-db, app-to-cache, or ALB-to-target traffic crossing AZs unnecessarily.
  6. Review centralized egress: inspect whether inspection VPCs or shared egress paths are adding tromboning.

Useful tools: AWS cost analysis tools, cost and usage reporting, VPC Flow Logs, reachability analysis, network access analysis, NAT Gateway metrics, and DNS resolver diagnostics.

Classic root causes: S3 still using NAT, image pulls and patch repositories through NAT, interface endpoints missing in one AZ, private DNS disabled, and centralized inspection adding extra hops.

11. Worked examples and exam decision guide

Worked example 1: Replace NAT-based S3 access

Starting state: private subnet route table has 0.0.0.0/0 -> nat-az-a. Instances access S3 through NAT-based public endpoint access. A better move is to create an S3 Gateway Endpoint and associate it with the private subnet route table. That lets S3 traffic take the private path instead of burning NAT charges for no good reason. AWS then inserts the managed S3 prefix-list route, and S3 traffic takes that endpoint path while everything else still uses NAT. It’s a neat little routing change, and it usually saves money right away. Exam takeaway: for private S3 access, gateway endpoint is usually the cost-optimized answer.

Worked example 2: Single NAT vs per-AZ NAT

If AZ-A and AZ-B private subnets both use one NAT in AZ-A, AZ-B traffic pays for NAT processing and may also incur cross-AZ transfer while depending on AZ-A for egress. With one NAT per AZ and local routing, the hourly cost goes up, but locality and zonal isolation improve. That’s the trade-off. Exam takeaway: in production HA, per-AZ NAT is usually the safer choice.

High-yield clue words:

  • Private subnet to S3/DynamoDB - Gateway Endpoint
  • Private API access to AWS service - Interface Endpoint
  • Many VPCs / transitive routing / shared services - Transit Gateway
  • Few VPCs / simple direct connectivity - VPC peering
  • Steady high-volume hybrid traffic - Direct Connect
  • Quick lower-cost hybrid path - Site-to-Site VPN
  • Global cacheable content - CloudFront
  • Static anycast IP / fast global failover - Global Accelerator

Common distractors:

  • NAT for S3 instead of a gateway endpoint.
  • Transit Gateway for only two small VPCs.
  • Direct Connect for small sporadic traffic.
  • CloudFront for a purely internal, non-cacheable app with no edge need.
  • Single NAT in one AZ for a highly available production design.

12. Final SAA-C03 takeaways

Memorize these billing facts:

  • NAT Gateway: hourly + per-GB processed.
  • Interface Endpoint: hourly + per-GB processed.
  • Transit Gateway: attachment-hour + per-GB processed.
  • Gateway Endpoint: no hourly endpoint charge.
  • Cross-AZ and inter-Region transfer can quietly dominate cost.

And keep these rules in your head during the exam:

  • Follow the traffic path, not just the service name.
  • Prefer endpoints over NAT when the destination is an AWS service that supports them.
  • Keep busy traffic local to the AZ when possible.
  • Use managed services when the question emphasizes low operational overhead.
  • Do not sacrifice stated HA or security requirements just to pick the cheapest component.

If you see a private subnet, ask whether the destination is the internet, an AWS service, another VPC, on-premises, or global users. That one habit will usually lead you to the right answer faster than memorizing isolated facts.