Design Cost-Optimized Network Architectures for AWS SAA-C03: Thinking in Traffic Paths, Not Just Services

1. Introduction: what cost-optimized network architecture means in AWS

In AWS, networking cost optimization is basically traffic-path optimization wearing a nicer jacket. The trap I see over and over: people stare at the hourly price tag of a service and miss the billable trail a packet leaves behind — internet egress, inter-AZ transfer, NAT processing, Transit Gateway processing, interface endpoint charges, load balancer usage, public IPv4 costs… the whole parade. For SAA-C03, that distinction is huge. The exam loves to hide the real answer in routing behavior, not in the shiny service name.

The practical mindset is almost annoyingly simple: find the destination, trace the path, list the billed hops, then pick the plainest design that still satisfies reliability, security, and operations. One exam-safe caveat, though, is that AWS pricing does move around over time and it can vary by Region, so don’t anchor on hardcoded numbers. You do not need exact numbers. You do need the rough shape of the costs — what tends to get expensive, what tends to stay cheap, and where the architecture quietly bites back.

2. Core AWS networking cost drivers

The big cost drivers are not just services; they are services plus data movement. High-yield SAA-C03 territory:

• Internet data transfer out: outbound traffic to the internet is commonly billed.
• Inter-AZ transfer: traffic crossing Availability Zones can create charges.
• Inter-Region transfer: usually pricier than staying inside one Region.
• NAT Gateway: hourly charge plus per-GB data processing. NAT Gateway is for IPv4 only.
• Interface Endpoints: hourly charge per endpoint per AZ plus data processing.
• Transit Gateway: hourly attachment charges plus per-GB data processing.
• Elastic Load Balancing: ALB uses hourly + LCU pricing; NLB uses hourly + NLCU pricing.
• Public IPv4: public IPv4 addresses now have direct cost implications; keep unnecessary ones on a short leash.
• Direct Connect: port-hour charges plus data transfer, and usually provider or colocation costs outside AWS.
• Site-to-Site VPN: hourly connection charges plus the usual transfer considerations.

It helps to think in packet paths. One flow can stack up several charges. For example:

• Private EC2 in AZ-B -> NAT Gateway in AZ-A -> internet: possible inter-AZ transfer + NAT processing + internet egress.
• Private EC2 -> S3 via Gateway Endpoint: skips NAT processing for that S3 traffic entirely. Nice little win.
• Spoke VPC -> Transit Gateway -> centralized egress VPC -> NAT -> internet: TGW data processing + attachment cost + possible inter-AZ or inter-VPC transfer effects + NAT processing + internet egress.

3. VPC fundamentals through a cost lens

A VPC is regional; subnets are AZ-specific. That one detail keeps coming back in both cost and resilience trade-offs. Route tables are VPC-scoped resources associated with subnets, so subnet-to-route-table design directly shapes both reachability and billing.

A subnet is public because its route table sends internet-bound traffic to an Internet Gateway, not because an instance merely lives there. For internet access, the instance also needs the right addressing and allowed security controls. Small detail, big difference.

Typical IPv4/IPv6 route patterns:

Public subnet, IPv4:
0.0.0.0/0 -> igw-xxxx

Private subnet, IPv4 outbound:
0.0.0.0/0 -> nat-xxxx

Public subnet, IPv6:
::/0 -> igw-xxxx

Private subnet, IPv6 outbound-only:
::/0 -> eigw-xxxx

The IPv6 bit matters. And just to keep it crisp: NAT Gateway is IPv4 only. For IPv6, outbound-only internet access uses an Egress-only Internet Gateway. That works only if the workload actually has IPv6 addresses, the security rules allow the flow, DNS returns AAAA records where needed, and the destination speaks IPv6.

For cost questions, route tables usually matter more than security groups and NACLs. Security controls affect correctness and exposure, sure — but the bill tends to follow the route.

4. Egress architecture choices: IGW, NAT Gateway, NAT Instance, and IPv6

The main egress options get much less mysterious once you separate public access from private outbound access.

Internet Gateway is the direct answer for public-facing subnets. If the component is supposed to be internet-facing, use an IGW and keep only the required tier public. No need to get fancy.

NAT Gateway is the usual production default for IPv4 outbound internet access from private subnets. It is managed and operationally simpler than a NAT instance, but the wording matters: a NAT Gateway is AZ-scoped and highly available within one AZ. Not magically multi-AZ. If you want AZ fault tolerance, deploy one NAT Gateway per AZ and route each private subnet to the NAT Gateway in the same AZ.

AZ-local NAT design example:

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

This avoids the classic anti-pattern: a single NAT Gateway in AZ-A serving private subnets in multiple AZs. That setup is often a resilience smell and a cost smell, because now you may pay cross-AZ transfer on top of NAT processing. Lovely little surprise.

NAT Instance can still make sense for low-throughput, noncritical, cost-sensitive environments, but it comes with real chores:

• Disable source/destination checks
• Enable IP forwarding
• Configure masquerading with iptables or nftables
• Patch and monitor the instance yourself
• Implement your own HA and failover if needed
• Watch instance bandwidth, connection, and packet-per-second limits

That is why NAT instance is usually the exam answer only when the scenario explicitly screams low cost, low traffic, and low operational concern.

5. VPC Endpoints: the most common NAT-cost optimization

VPC Endpoints are a high-yield SAA-C03 topic because they often remove pointless NAT usage.

Gateway Endpoints exist only for Amazon S3 and DynamoDB. They are VPC-level resources associated with selected route tables, not per-subnet or per-AZ deployments. AWS adds the relevant service-prefix routing through the endpoint association model. The exam takeaway is clean: if private workloads need S3 or DynamoDB, think Gateway Endpoint first.

Interface Endpoints are powered by PrivateLink. They create ENIs in selected subnets, are usually accessed via DNS, and generally should be deployed in each AZ where clients run if you want resilient, local access and want to avoid cross-AZ traffic. They are billed hourly per AZ plus data processing, so multi-AZ deployment increases cost. Convenient, yes. Free? absolutely not.

Important implementation details:

• Gateway Endpoint: associate the endpoint with the route tables used by private subnets that need S3 or DynamoDB.
• Gateway Endpoint policies: use endpoint policies and bucket or table policies to restrict allowed access.
• Interface Endpoint: select subnets, attach security groups, and usually enable private DNS so service names resolve to the endpoint ENIs.
• Security groups: interface endpoints need SG rules allowing inbound traffic from clients on the relevant ports.
• Service support: not every AWS service supports interface endpoints in every Region.

One subtle correction: using public AWS service endpoints does not always mean traffic literally wanders across the public internet in the everyday sense. The stronger exam point is that endpoints can remove NAT dependence, reduce public endpoint exposure, and often cut cost.

6. How to trace a billable packet path

When a question gets fuzzy, I use a packet-walk method:

1. Identify the source: which subnet, which AZ, which account or VPC?
2. Identify the destination: internet, AWS service, another VPC, another Region, or on-premises?
3. List every hop: IGW, NAT, endpoint, load balancer, TGW, peering, VPN, DX.
4. Ask whether the path crosses AZs or Regions.
5. Choose the simplest path that still meets HA and security needs.

Example 1: Private EC2 to S3 through NAT
Source: private subnet in AZ-A. Destination: S3. If routed to NAT, you pay NAT processing for no good reason. Better answer: S3 Gateway Endpoint.

Example 2: Private EC2 in AZ-B to centralized NAT in AZ-A
Source: AZ-B. Destination: internet. Path crosses an AZ boundary first, then NAT, then internet. Better answer for production multi-AZ design: NAT Gateway in each AZ with AZ-local routing.

Example 3: Spoke VPC to internet through TGW and centralized egress VPC
Source: spoke VPC. Destination: internet. Path includes TGW processing, possible extra transfer, NAT processing, and internet egress. That may be justified for governance, but it is not automatically the cheapest move.

7. Minimizing data transfer charges in multi-AZ and multi-tier designs

The biggest hidden cost in highly available architectures is often unnecessary east-west traffic. Usual suspects:

• App servers in AZ-A making constant synchronous calls to a database writer in AZ-B
• Microservices spread across AZs with chatty service-to-service traffic
• Centralized inspection or logging VPCs hairpinning high-volume traffic
• Backup, replication, and analytics copy jobs crossing AZs again and again

The goal is not to erase every cross-AZ packet. Some managed-service replication, like Multi-AZ database behavior, is absolutely deliberate and worthwhile, so don’t optimize away something you actually need for resilience. The optimization target is unnecessary application traffic that crosses AZs because of sloppy placement or routing.

For load balancers, keep the guidance precise: ALB and NLB both use usage-based pricing, but cross-zone behavior and inter-AZ billing implications depend on the exact traffic path, target placement, and load balancer type. So… no blanket slogans. Check the design.

8. VPC connectivity: Peering vs Transit Gateway

VPC Peering is usually the simpler and cheaper answer for a small number of VPCs. It’s point-to-point, needs routes on both sides, doesn’t support transitive routing, and can’t be used as a generic edge-to-edge transit path through another peer. Also keep the cost nuance in mind: inter-Region peering can incur inter-Region transfer charges, and same-Region traffic still deserves cost awareness depending on architecture.

Transit Gateway is the better answer when you have many VPCs, multiple accounts, on-premises connectivity, segmentation, or shared services. It has hourly attachment charges and per-GB data processing charges, but often saves enough operational pain to earn its keep.

Centralized networking through TGW can also push cost upward if traffic hairpins through shared services without reason. That theme shows up a lot.

9. Hybrid connectivity: VPN vs Direct Connect

Site-to-Site VPN is the low-entry-cost option. It gives you encrypted connectivity over internet paths and is often the right answer for quick setup, smaller environments, DR connectivity, or early hybrid adoption. Performance can wobble because the underlay is still the internet. The internet, being itself.

Direct Connect is private connectivity, but it is not encrypted by default. If encryption is required, add a control such as VPN over DX, or another supported encryption option depending on the scenario. DX makes sense when traffic is steady, high-volume, and needs more predictable performance. Resilient DX designs generally use multiple connections or locations; a single DX is not the whole story. A common pattern is DX primary with VPN backup.

Exam-safe rule: use VPN for low-cost initial hybrid connectivity; use DX when predictable high-volume private connectivity justifies the commitment.

10. Global traffic services: Route 53, CloudFront, and Global Accelerator

These services solve different problems:

• Route 53: DNS routing and health-based traffic management
• CloudFront: edge caching and content delivery
• Global Accelerator: static anycast IP entry and improved routing for dynamic or non-cacheable traffic onto the AWS global network

CloudFront can reduce origin load and can reduce origin egress, but it brings its own CDN charges. It makes the most sense when the cache hit ratio is high enough to justify edge delivery. Classic pattern: CloudFront in front of S3 for static content, or CloudFront in front of ALB for mixed web delivery.

Global Accelerator is not a caching service and does not replace CloudFront. It fits when the problem is dynamic application performance, static IP entry, or fast failover to healthy endpoints.

11. IPv4 vs IPv6 for cost optimization

Public IPv4 has direct cost implications now, so minimizing unnecessary public IPv4 usage is a real design lever. IPv6 can reduce dependence on NAT because NAT Gateway is IPv4-only. In a dual-stack design, private subnets can use an Egress-only Internet Gateway for outbound-only IPv6 internet access.

That said, IPv6 is not some magic cheat code. It only helps if the application, DNS, security controls, and destination path all support IPv6. In practice, dual-stack is often the realistic transition path. For SAA-C03, if the scenario explicitly mentions IPv6 and outbound-only internet access, egress-only IGW is usually the cost-aware answer.

12. Centralized vs distributed egress in multi-account environments

In AWS Organizations, you often choose between distributed egress and centralized egress.

Distributed egress: each application VPC uses its own NAT Gateways and local endpoints. This is often simpler for locality and can reduce hairpin transfer.

Centralized egress: application VPCs route outbound traffic through TGW to a shared egress VPC. This can improve governance and inspection consistency, but may add TGW processing, inter-VPC transfer effects, and extra hops.

Centralized interface endpoints can be awkward too. Some sharing patterns are possible, but private DNS and service-specific limitations make this far from a universal plug-and-play design. On the exam, do not assume centralized endpoints are automatically cheaper or cleaner.

13. Security implications of cost-optimized networking

The cheapest path is not always the right path. Private connectivity can improve exposure posture, but security still depends on IAM, endpoint policies, SGs, NACLs, DNS, and inspection design.

• Gateway Endpoints: use endpoint policies and S3 bucket policies or DynamoDB controls to restrict access.
• Interface Endpoints: lock down endpoint security groups to known clients and required ports.
• Centralized inspection: useful for compliance, but expensive if every packet hairpins through it.
• Public vs private access: private access often reduces exposure, but can cost more if overused with low-value interface endpoints.

Exam rule: cost optimization never overrides explicit security, compliance, or reliability requirements.

14. Observability and troubleshooting: how to find hidden network spend

If network charges jump, use a practical workflow:

• Cost Explorer: group by service and usage type to isolate NAT Gateway, data transfer, ELB, TGW, or public IPv4 spend.
• Cost and Usage Report (CUR): use detailed billing dimensions for deeper analysis and chargeback or showback.
• VPC Flow Logs: identify chatty flows, unexpected destinations, and cross-AZ communication patterns.
• Transit Gateway Flow Logs: useful when centralized networking is involved.
• CloudWatch NAT Gateway metrics: look for bytes or packet spikes that suggest backups, patching, or AWS service traffic still going through NAT.
• Reachability Analyzer: validate whether traffic should use an endpoint, NAT, peering, or TGW path.

Troubleshooting example: NAT Gateway charges suddenly increased

• Check whether S3 backups or log uploads are still using NAT instead of a Gateway Endpoint
• Look for new private workloads pulling packages from internet repositories
• Confirm route tables did not lose endpoint associations
• Check whether one AZ is hairpinning through another AZ's NAT

Troubleshooting example: inter-AZ transfer is high

• Look for app-to-DB placement mismatches
• Check service-to-service traffic between AZs
• Review centralized egress or inspection patterns
• Validate load balancer target placement and actual traffic distribution

15. Common architecture anti-patterns

• Single NAT Gateway for multi-AZ production traffic: often cheaper on paper, worse for resilience and often worse for transfer cost.
• S3 or DynamoDB access through NAT: classic exam trap; use Gateway Endpoints.
• Endpoint sprawl: interface endpoints in every VPC for every service without enough traffic to justify them.
• Premature Transit Gateway adoption: paying for attachments and processing before scale actually needs it.
• Chatty cross-AZ app or database placement: hidden transfer charges.
• Assuming Direct Connect includes encryption: it does not by default.

16. SAA-C03 answer selection framework

Use this sequence on the exam:

1. Identify the traffic destination: internet, AWS service, another VPC, another Region, or on-prem.
2. Identify billable hops: NAT, endpoint, TGW, load balancer, VPN, DX, inter-AZ, inter-Region.
3. Eliminate overengineered answers first.
4. Check HA and security requirements.
5. Choose the simplest architecture that satisfies the requirements.

17. Compact scenario guide

18. Practical labs and validation ideas

Lab 1: Replace NAT-routed S3 access with a Gateway Endpoint
Build a VPC with a private EC2 instance using NAT for outbound access. Verify S3 access works. Add an S3 Gateway Endpoint and associate it with the private subnet route table. Re-test connectivity and watch S3-bound traffic stop depending on NAT. Satisfying, in a quiet little way.

Lab 2: Compare one NAT per AZ vs centralized NAT
Create private subnets in two AZs. First, route both through one NAT Gateway in a single AZ. Then redesign to one NAT Gateway per AZ with AZ-local route tables. Compare resilience and expected billing-path differences.

Lab 3: Interface Endpoint private access
Create an interface endpoint for Systems Manager or Secrets Manager in private subnets, enable private DNS, apply SG rules, and confirm private instances can reach the service without internet or NAT dependency.

19. Final rapid review

• Follow the traffic, not just the service price.
• And just to keep it crisp: NAT Gateway is IPv4 only.
• Egress-only IGW is for outbound-only IPv6 internet access.
• Public subnet is defined by routing, not by instance type.
• Gateway Endpoint first for S3 and DynamoDB.
• Interface Endpoints are billed per AZ plus data processing.
• NAT Gateway is AZ-scoped; resilient design usually means one per AZ.
• Single-AZ centralized NAT for multi-AZ workloads is a common anti-pattern.
• Peering is for small or simple; TGW is for scale and transitive routing.
• TGW adds hourly attachment and per-GB processing cost.
• VPN is the low-cost hybrid starter option.
• Direct Connect is private, not encrypted by default.
• CloudFront caches; Global Accelerator accelerates dynamic traffic.
• ALB uses LCUs; NLB uses NLCUs.
• Public IPv4 addresses have direct cost implications.
• Not every service supports interface endpoints in every Region.
• Private access can improve exposure posture, but security still depends on policy and controls.
• Do not optimize away required HA or compliance.
• Cost Explorer, Flow Logs, and CloudWatch help find hidden network spend.
• On the exam, the simplest architecture that meets requirements usually wins.

20. Conclusion

The best cost-optimized AWS network architecture is rarely the one with the cheapest-looking component. It is the one with the cleanest billable path. For SAA-C03, remember the defaults: Gateway Endpoint for private S3 or DynamoDB access, interface endpoint for private access to other supported services, NAT Gateway for production private IPv4 egress, peering for a few VPCs, TGW for many VPCs and shared services, VPN for low-cost hybrid starts, DX for predictable high-volume hybrid, CloudFront for cacheable content, and Global Accelerator for dynamic global performance. If you can trace the packet path and spot the billed hops, you will answer these questions well on the exam and design better systems in real life.