Cost-Optimized Networking: NAT Gateways, VPC Endpoints, and Data Transfer

You cannot cost-optimize a network you cannot price, so start with the charging rules the exam assumes you know cold. Rule one: inbound data transfer from the internet is free. Ingesting terabytes into AWS costs nothing in transfer — which is why data-heavy ingestion architectures are viable at all. Rule two: traffic between resources in the same Availability Zone over private IP addresses is free. Two instances chatting within one AZ across private IPs generate no transfer charge, no matter the volume. Rule three: traffic that crosses Availability Zones within a Region is charged per gigabyte — and it is billed in both directions, out of one AZ and into the other, so chatty cross-AZ tiers pay twice per exchange. Rule four: traffic between Regions is charged per gigabyte, at rates that vary by Region pair — cross-Region replication is a recurring line item, not a one-time setup cost. Rule five: egress to the internet is charged per gigabyte, on a tiered schedule, and it is typically the largest transfer line on a consumer-facing bill.

One trap hides inside rule two: it requires private IPs. Traffic between two instances in the same AZ that flows via public or Elastic IP addresses hairpins through public address space and gets charged as if it were regional traffic. Internal communication should always use private addressing — a free fix scenarios plant deliberately.

The design consequence: where you place resources and how you address them is a pricing decision. Co-locating chatty components in one AZ makes their conversation free; spreading them across AZs makes every exchange billable — and also makes the system survive an AZ failure. That tension is examined honestly later in this lesson.

The exam tests these rules indirectly: a scenario describes a traffic path — instance to instance, subnet to S3, Region to Region — and the correct answer is the one that reroutes, relocates, or caches the traffic onto a free or cheaper segment. If you can annotate each hop with charged-or-free, the options rank themselves.

This table is the lookup most Task 4.4 questions compile down to. For each path: is it charged, and what is the cost-optimized design response?

Two reading habits make the table stick. First, notice which rows say No — free paths (inbound, same-AZ private, gateway endpoints, origin-to-CloudFront) are the raw material of cost-optimized designs, and correct answers usually move traffic onto them. Second, notice that NAT and Transit Gateway rows charge twice: an hourly fee for existing plus a per-GB fee for processing. Managed network middleboxes bill for presence and for throughput, which is why removing traffic from them saves so reliably.

On the exam, expect the question to describe two or three hops and ask for the MOST cost-effective change. Annotate each hop against this table; the option that converts a charged row into a free row — without violating a security or availability requirement — is the answer.

A NAT gateway lets instances in private subnets reach the internet, and it charges two meters at once: an hourly fee for every hour it exists, and a per-gigabyte processing fee on every byte that flows through it — on top of the ordinary data transfer the traffic would incur anyway. A NAT gateway that moves serious volume can quietly become one of the largest items on a network bill, which is why the exam returns to it constantly.

The architectural decision is how many to run. A single shared NAT gateway in one AZ minimizes the hourly cost — one gateway, one fee — but instances in other AZs must cross an AZ boundary to reach it, adding cross-AZ transfer charges on all of that traffic, and it concentrates risk: if the NAT gateway's AZ fails, every private subnet in the VPC loses internet access. One NAT gateway per AZ multiplies the hourly fees but keeps each AZ's egress local — no cross-AZ charges on the way out, and no cross-AZ dependency: an AZ failure takes down only its own egress. The decision rule: dev, test, and cost-first environments with modest traffic take the single shared NAT; production environments with an availability requirement, or heavy egress from multiple AZs, take per-AZ NATs — where the extra hourly fees are partially offset by the cross-AZ charges they eliminate.

Know the NAT instance at recognition level: the legacy do-it-yourself option, an EC2 instance performing NAT. It can be cheaper than a NAT gateway — a small instance has a low hourly cost and no per-GB processing fee — but you manage patching, sizing, failover, and it bottlenecks at the instance's bandwidth. It appears as the "lowest possible cost, team accepts operational burden" answer, and as a wrong answer whenever the scenario asks for managed or highly available.

When asked to cut a NAT bill, run this list in order: 1) add gateway VPC endpoints for S3 and DynamoDB traffic (next section — usually most of the bill); 2) add interface endpoints for other high-volume AWS service traffic; 3) check what remains with VPC Flow Logs before resizing anything; 4) consolidate to a single NAT if availability requirements and cross-AZ math allow; 5) consider a NAT instance only for small, tolerant environments.

The exam tests NAT two ways: the bill-reduction scenario (the list above) and the single-versus-per-AZ design choice, where the availability requirement in the question decides which is "cost-optimized."

Here is the pattern SAA-C03 tests more than any other in this task. Instances in private subnets talk to Amazon S3 or DynamoDB. Without an endpoint, that traffic leaves through the NAT gateway — paying the per-gigabyte NAT processing fee on every byte — even though it is going to an AWS service in the same Region. For data-heavy workloads (analytics jobs reading S3, applications streaming objects, backup pipelines), this single path can dominate the NAT bill.

The fix is a gateway VPC endpoint. It is a route-table entry, not a device: you create the endpoint for S3 or DynamoDB, associate it with the private subnets' route tables, and traffic to that service flows directly over the AWS network — never touching the NAT gateway, never traversing the internet. And the part that makes it the exam's favorite answer: gateway endpoints are free. No hourly charge, no per-gigabyte charge. The NAT processing cost for that traffic drops to zero, and as a side benefit the traffic becomes more private, so the answer simultaneously satisfies cost and security framings. Gateway endpoints exist for exactly two services — S3 and DynamoDB — a fact worth memorizing verbatim.

For every other AWS service reached through a NAT gateway — ECR, CloudWatch, SQS, Secrets Manager, and the rest — the private path is an interface VPC endpoint (powered by PrivateLink). Interface endpoints are not free: they bill per hour per AZ plus per gigabyte processed. The concept-level comparison: their per-gigabyte rate is well below NAT processing, so high-volume service traffic through an interface endpoint costs less than the same traffic through NAT — but each endpoint's standing hourly fees mean that a fleet of endpoints serving trickles of traffic can cost more than the NAT charges they replace. Volume justifies interface endpoints; idleness doesn't.

The exam signature is unmistakable: private subnets, heavy S3 or DynamoDB traffic, and a complaint about NAT gateway or data processing charges. The answer is the gateway endpoint, and the distractors are predictable — an interface endpoint for S3 (functional, but it has fees where the gateway endpoint has none), resizing or adding NAT gateways (doesn't touch per-GB pricing), or moving instances to public subnets (breaks the security posture the scenario implies).

Internet egress is the transfer charge you cannot route around — users are on the internet, and bytes must reach them. The lever is where the bytes leave from and how often the origin is asked for them, and that is CloudFront's cost story.

Putting CloudFront in front of an origin changes the economics twice. First, edge caching collapses origin fetches: when thousands of users request the same object, the origin serves it once per cache lifetime per edge location instead of once per user. Every cache hit is origin work — and origin data transfer — that never happens, which also means the origin fleet itself can be smaller. Second, the transfer path gets cheaper end to end: data transferred from AWS origins to CloudFront carries no charge, and CloudFront's own egress pricing is designed to be competitive with — and at volume, generally below — serving the same bytes straight from EC2 or S3. You are substituting a cheaper egress channel for a more expensive one, at the same time as you shrink total origin traffic.

CloudFront earns this on cacheable content: static assets, images, video, downloads, and — with sensible TTLs — even semi-dynamic API responses. For fully dynamic, uncacheable traffic the caching benefit disappears, though the free origin-to-CloudFront leg still applies.

Keep Global Accelerator distinct at recognition level: it also uses the edge network, but it is a performance and static-IP product — deterministic routing onto the AWS backbone with an hourly fee plus a per-gigabyte premium. It does not cache, and it is not a cost-reduction tool. When a question's pain is data transfer cost for content delivery, CloudFront is the answer; Global Accelerator appears there as a distractor for TCP/UDP performance scenarios.

The exam frames this as an egress-bill scenario: an application serving media or static files directly from EC2 or S3, transfer costs climbing with popularity. The MOST cost-effective answer adds CloudFront; the distractors scale the origin (more instance cost, same egress rates), move Regions (marginal), or reach for Global Accelerator (a premium, not a saving).

Hybrid connectivity is a classic fixed-versus-variable cost decision, and the exam expects you to reason about it in exactly those terms.

AWS Site-to-Site VPN is the low-fixed-cost option: a modest hourly charge per connection, running as encrypted tunnels over the public internet, live within hours of deciding you need it. Its variable cost is ordinary internet data transfer, and its constraints are the internet's: variable latency, and a documented throughput ceiling of roughly 1.25 Gbps per tunnel. Each connection provides two tunnels for redundancy — not doubled bandwidth by default — and when one tunnel's ceiling is the bottleneck, the design response is multiple VPN connections aggregated with equal-cost multipath routing (ECMP) over a Transit Gateway, scaling bandwidth roughly linearly with tunnel count. That is the answer shape for "more VPN bandwidth": more tunnels, not a bigger tunnel.

AWS Direct Connect inverts the cost structure: a dedicated physical circuit with meaningful fixed costs — port-hours on AWS's side plus whatever the colocation or carrier charges — in exchange for a lower per-gigabyte data transfer out rate than internet egress, plus consistent latency and private connectivity. Dedicated connections come in 1, 10, and 100 Gbps port speeds, with hosted connections available at lower increments through partners — recognition level: pick the port speed from the sustained throughput requirement, don't buy 10 Gbps for a 200 Mbps workload. The operational catch the exam loves: provisioning takes weeks or longer, because physical circuits are involved.

The selection rule follows directly: low or bursty volume, speed-to-deploy, or budget-first means VPN; large, steady transfer volume means Direct Connect, where the discounted per-GB rate on high volume pays back the fixed circuit costs — the break-even logic, no exact prices required. The two also pair: a common pattern runs Direct Connect as primary with a VPN as the low-cost failover, and a VPN over the internet is the standard stopgap while a Direct Connect circuit is being provisioned.

The exam tests this with volume-and-timeline scenarios: "transfers several terabytes daily to on premises" points to Direct Connect; "needs connectivity next week" or "occasional low-volume sync" points to VPN; "needs it now and long-term at volume" points to VPN-now, Direct-Connect-later.

Connecting VPCs privately has two mainstream mechanisms, and their cost structures diverge exactly like NAT versus endpoints did.

VPC peering is the lean option: a direct, non-transitive link between two VPCs with no hourly attachment fee and no processing fee — you pay only the data transfer itself, and traffic that stays within the same AZ across a same-Region peering connection is free, with cross-AZ flows billed at the usual regional rates. Its cost is architectural instead: peering is point-to-point and non-transitive, so full connectivity among N VPCs needs a mesh of N×(N−1)/2 connections, each with its own route-table entries. At three or four VPCs that is trivial; at forty it is an operational tar pit.

AWS Transit Gateway is the hub: every VPC (and VPN, and Direct Connect gateway) attaches once, and the hub routes among them, transitively. It charges like the managed middlebox it is — a per-attachment hourly fee plus a per-gigabyte processing fee on traffic through the hub, on top of any applicable transfer charges. For a handful of VPCs, those standing fees buy you nothing peering doesn't already do cheaper. At scale, Transit Gateway pays for itself in eliminated mesh management: one attachment per VPC instead of dozens of peerings, one routing domain, native transitivity, and a clean on-ramp for hybrid connectivity.

The decision rule the exam rewards: few VPCs (roughly a handful) with simple, stable connectivity — peer them and pay only for transfer; many VPCs, growing, or needing transitive routing and shared hybrid connections — Transit Gateway, accepting its fees as the price of manageability.

Complete the picture with AWS PrivateLink at recognition level: when many consumer VPCs need to reach one specific service — not full network connectivity — PrivateLink exposes just that service through interface endpoints in each consumer VPC. It bills like interface endpoints (hourly per endpoint per AZ plus per GB), avoids both meshes and hubs, and eliminates overlapping-CIDR headaches. Service-to-many equals PrivateLink; network-to-network equals peering or Transit Gateway.

Exam scenarios state the VPC count and trajectory for a reason: "three VPCs, no growth expected" is peering on cost grounds; "dozens of VPCs across accounts" is Transit Gateway; "expose an internal API to hundreds of customer VPCs" is PrivateLink. Distractors offer Transit Gateway's convenience where its fees are unjustified, or a peering mesh where its management burden is the disqualifier.

The rules so far imply an uncomfortable conclusion: the cheapest network is a single-AZ network. Same-AZ private traffic is free, one NAT gateway suffices, and nothing crosses a billable boundary. The reason production architectures don't look like that is availability — and the exam expects you to hold both truths honestly rather than pretend there is a free lunch.

The tension resolves through requirements. Multi-AZ placement of the tiers that provide availability — load-balanced web and application fleets, database replicas — is non-negotiable when the scenario states an availability requirement, and the cross-AZ transfer between them is the accepted price of surviving an AZ failure. What you optimize is the traffic that doesn't buy resilience: batch pipelines shuffling data between components that could sit together, chatty microservices making thousands of cross-AZ calls per second out of placement indifference rather than design, replication chatter that could be batched or compressed. Techniques that shave the billable volume without touching the topology: compress payloads before they cross a boundary, batch small messages into fewer larger ones, and throttle or schedule bulk internal transfers so they don't run unbounded — throttling here is a cost control as much as a stability one. AZ-aware routing within load-balanced tiers (keeping a request's hops inside one AZ where the platform supports it) trims the same line item.

Two closing notes on scope. Route 53 is not a cost lever worth designing around: DNS query charges are negligible next to transfer and NAT, and routing-policy choice (latency, failover, weighted) is an availability and performance decision — treat any answer that picks a DNS routing policy "to save money" with suspicion. And when asked to review an existing workload for network cost optimization, the method is evidence first: Cost Explorer to find which transfer category is actually spending, VPC Flow Logs to see whose traffic it is, then apply this lesson's fixes — endpoints for NAT-bound service traffic, CloudFront for egress, placement and compression for cross-AZ — to the biggest line first.

The exam tests this section's judgment call directly: options that consolidate everything into one AZ "to reduce transfer costs" are wrong the moment the scenario mentions high availability, and options that gold-plate resilience are wrong when the scenario is a dev environment asking for minimum cost. The qualifier only ever means: cheapest among the designs that meet the stated requirements.

Scenario 1 — the NAT bill and the S3 pipeline. An analytics fleet of EC2 instances in private subnets reads and writes several terabytes a day to S3 buckets in the same Region. The finance team flags a large and growing NAT gateway data-processing charge. Security requires the instances stay in private subnets. What is the MOST cost-effective fix?

Reasoning: Annotate the path: instance → NAT gateway (per-GB processing — the flagged cost) → S3. Eliminate moving instances to public subnets: it would bypass the NAT but violates the stated security requirement. Eliminate adding or resizing NAT gateways: NAT pricing is per gigabyte — more gateways spread the load and add hourly fees without reducing the processing charge at all. An interface endpoint for S3 would work but carries hourly and per-GB fees of its own. The answer is a gateway VPC endpoint for S3: a route-table change that sends the S3 traffic over the AWS network directly, is completely free, keeps the instances private, and zeroes out the NAT processing charge for the dominant traffic. This is the most-tested network cost question in the exam's repertoire — recognize it from the first sentence.

Scenario 2 — one NAT or three? A production web application runs across three AZs, with application servers in private subnets making moderate outbound API calls. The architecture currently uses a single NAT gateway in AZ-a. A new requirement states the application must tolerate the loss of any single AZ. Which change is MOST cost-effective?

Reasoning: The availability requirement is doing the work. Keeping the single NAT is the cheapest configuration — until AZ-a fails and instances in AZ-b and AZ-c lose all egress, violating the stated requirement, so it is disqualified regardless of price. A NAT instance per AZ is cheaper still on paper but reintroduces self-managed availability — the wrong direction when the requirement is resilience. The answer is one NAT gateway per AZ with per-AZ route tables: each AZ's egress survives independently, and the added hourly fees are partly offset by eliminating the cross-AZ transfer that AZ-b and AZ-c traffic was paying to reach AZ-a. Flip the scenario — a dev environment, no availability requirement, cost-first — and the single shared NAT becomes the correct answer. The qualifier didn't change; the requirements did.

Scenario 3 — peering or Transit Gateway? A company runs four VPCs that need full private connectivity with moderate inter-VPC traffic. No growth in VPC count is expected. The team proposes Transit Gateway; is there a cheaper design that meets the requirement?

Reasoning: Four VPCs need six peering connections for a full mesh — entirely manageable — and VPC peering carries no hourly attachment or processing fees, so every gigabyte moves cheaper than through a Transit Gateway hub charging per attachment-hour and per GB processed. With a stable, small VPC count, Transit Gateway's manageability premium buys nothing the requirement asks for. Reverse the facts — dozens of VPCs, multiple accounts, shared VPN and Direct Connect on-ramps — and Transit Gateway wins on operational grounds that the exam accepts as part of cost-effectiveness at scale.