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.

Rule one has a corollary the exam likes: a paid transfer tool only solves a bandwidth or deadline problem, never a transfer-cost problem. Uploading over the internet into Amazon S3 costs nothing in transfer, so when the connection is fast enough and the schedule is relaxed, a plain (multipart) upload is the cheapest migration. AWS DataSync charges per gigabyte copied and S3 Transfer Acceleration charges per gigabyte accelerated; both are worth paying for only when the network path or the deadline actually needs them. (AWS Snowball Edge is no longer available to new customers since 7 November 2025 — AWS points new customers to DataSync — so it is not a current choice for a new account.)

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.

Since 2025 there is a third managed option: the regional NAT gateway. Instead of one gateway per AZ in a public subnet, you create one NAT gateway in regional availability mode for the VPC; it has a single gateway ID that every private route table can target, needs no public subnet, and automatically expands into each AZ where you have workloads (and contracts when they leave), keeping traffic zonal once it has expanded. Expansion into a newly used AZ can take up to an hour, and until it completes that AZ's traffic is processed in another AZ, so it briefly incurs cross-AZ charges. Its billing follows that footprint: an hourly charge for each AZ it is active in, plus the same per-GB processing fee. So it is the operational equivalent of per-AZ gateways — simpler routing and high availability by default — not a cheaper meter. It does not reduce processing charges, and with workloads in three AZs it costs about what three zonal gateways do. (It also supports public NAT only; private NAT still needs zonal gateways.)

The NAT instance is 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 and failover, and it bottlenecks at the instance's bandwidth. AWS no longer maintains a NAT AMI, so you build one from a current AMI (for example Amazon Linux) and configure it yourself: enable IP forwarding and masquerading in the operating system, place it in a public subnet with a public or Elastic IP (that subnet keeps its route to the internet gateway), turn off the source/destination check (EC2 otherwise drops traffic that is not addressed to or from the instance itself), allow the private subnets in its security group, and point the private subnets' default route at the instance. It is the "lowest possible cost, team accepts operational burden" answer, and 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 (at low volume, idle hourly fees dominate, so fewer gateways save most); 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.

Because a gateway endpoint is a route, two details decide whether it actually saves money. First, it only affects the route tables it is associated with: the endpoint adds a route to the service's prefix list, which is more specific than the default route to the NAT gateway, but only in the associated tables. A VPC with one route table per AZ needs the endpoint associated with every private route table, and each service needs its own endpoint — an S3 endpoint does nothing for DynamoDB traffic. If the NAT bill barely moves after adding an endpoint, check the associations first. Second, it only reaches the service in the VPC's own Region; traffic to a bucket in another Region still leaves through NAT and pays inter-Region transfer. Private DNS is not a gateway-endpoint setting — it belongs to interface endpoints, where it makes the service's default hostname resolve to the endpoint's private IPs.

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.

Some services need both kinds. Pulling images from a private Amazon ECR repository without NAT takes interface endpoints for the ECR API and the Docker registry (with private DNS enabled so the usual hostnames resolve to them) and an S3 gateway endpoint, because ECR serves the image layers from Amazon S3. Leave out the S3 route and the largest part of every pull still flows through NAT.

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.

Global Accelerator also uses the edge network, but it solves a different problem. It gives you two static anycast IP addresses, accepts TCP and UDP traffic at the nearest edge location and carries it over the AWS backbone to endpoints such as Network Load Balancers, Application Load Balancers, EC2 instances or Elastic IPs. It charges an hourly fee plus a per-gigabyte data transfer premium, and it caches nothing. It is justified when traffic is latency-sensitive and cannot be cached — non-HTTP protocols such as UDP game or voice traffic, or clients that need a few fixed IP addresses to allowlist — and when you want better paths without adding Regions. It is not a cost-reduction tool, and it cannot front an S3 bucket.

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 per-tunnel throughput limits. Each connection provides two tunnels for redundancy — not doubled bandwidth by default.

Allocating VPN bandwidth is its own skill. A standard tunnel carries up to about 1.25 Gbps. Beyond that there are two levers, and both need the VPN on a transit gateway (or AWS Cloud WAN) rather than a virtual private gateway:

• Large Bandwidth Tunnels raise a tunnel to up to 5 Gbps. They are not supported on virtual private gateways, both tunnels of the connection must use the same setting, and the customer gateway device must be able to push that rate through one tunnel.
• Multiple VPN connections with ECMP spread traffic across many tunnels. ECMP needs a transit gateway and dynamic (BGP) routing; static-routed VPNs and virtual private gateways do not load-balance across connections. This is the answer when the on-premises device can only handle about 1.25 Gbps per tunnel, and it also scales past 5 Gbps by combining Large Bandwidth Tunnels.

Accelerated Site-to-Site VPN is a different lever: it uses Global Accelerator so the tunnels enter the AWS network at the nearest edge location instead of crossing the whole internet path, which improves consistency for distant sites. It costs extra (accelerator hourly and data transfer charges), works only with transit-gateway attachments, does not raise per-tunnel bandwidth (and cannot be combined with Large Bandwidth Tunnels), and still uses the internet between the site and the edge — so it is not a substitute for Direct Connect's consistent latency.

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 fixed port speeds (1, 10 and 100 Gbps, with 400 Gbps at selected locations), with hosted connections available at lower increments through partners — pick the port speed from the sustained throughput requirement, and 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; "more VPN bandwidth soon" points to a transit gateway with ECMP or Large Bandwidth Tunnels, chosen by what the customer gateway can handle per tunnel.

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 traffic that could be compressed or served from a per-AZ cache. Transfer is billed per byte, so the techniques that shrink the bill are the ones that shrink the bytes that cross: compress payloads before they cross a boundary, and cache repeated reads in each AZ (for example a per-AZ cache node or local read replica) so the same data is not fetched across AZs again and again. Batching small messages saves request overhead and API calls, but barely changes the billed gigabytes. 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.

The same logic applies across Regions: when a workload rereads the same data from another Region every day, stop paying for the crossing instead of optimizing it. S3 Cross-Region Replication copies the data once and then only the changes, and readers use the local copy. Replication applies only to objects written after the rule exists, so existing objects need a one-time S3 Batch Replication job before readers switch over.

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.

Throttling is a cost control because every request you reject or absorb early is compute, database and transfer you do not pay for. The right strategy depends on who you need to limit and where the request should stop.

Two distinctions are worth holding. Per-client limits need usage plans: stage throttling and Lambda concurrency limit everyone together, and a WAF rule counts per IP address over minutes, not per customer over a month. And usage-plan throttling and quotas are applied on a best-effort basis: they enforce fair use per tier, but AWS does not present them as a hard cost cap, so pair them with AWS Budgets alerts and backend protections rather than relying on them alone to bound spend. Rejected requests still cost little, but a request stopped at the edge by WAF or served from the CloudFront cache costs least.

Reviewing a workload for network optimization starts with evidence: find which charge is growing, who owns it and which traffic causes it, then apply the fixes in this lesson to the biggest line first. Each AWS tool answers one of those questions.

Two network services change the bill directly and are easy to miss. Route 53 alias records point a name at an AWS resource (a load balancer, CloudFront distribution, S3 website endpoint and others); Route 53 does not charge for alias queries to AWS resources, whereas CNAME queries are billed, and an alias also works at the zone apex where a CNAME is not allowed. DNS routing policies (latency, failover, weighted) remain availability and performance decisions rather than cost levers. And load balancers bill per hour plus capacity units, so several lightly used ALBs can often be consolidated into one ALB with host-based and path-based listener rules (and multiple certificates via SNI), keeping each application's routing separate while paying one standing fee.

Scenario 1 — the NAT bill and the S3 pipeline. A reporting workload on private-subnet EC2 instances moves terabytes of objects daily between itself and same-Region S3 buckets. 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.