Cost-Optimized Network Architectures

What Is a Cost-Optimized Network on AWS

A cost-optimized network on AWS is a VPC-centric architecture that deliberately minimizes the four recurring network charges that show up on every AWS bill: data transfer out (DTO), NAT Gateway processing, inter-AZ traffic, and cross-Region replication. Unlike compute or storage — where you can usually right-size a single resource to save money — a cost-optimized network design saves money by reshaping how packets flow between services. The SAA-C03 exam expects you to spot the expensive flow, replace it with a free or cheaper alternative, and justify the decision in terms of both dollars and architectural constraints.

The cost-optimized network domain sits inside SAA-C03 Task 4.4 ("Design cost-optimized network architectures"). It carries a meaningful share of the 20% Domain 4 weight, and it is the topic most likely to appear as a scenario question where the correct answer is counter-intuitive. For example, putting a VPC Gateway Endpoint in front of an S3 bucket does not improve performance in any measurable way — but it eliminates the NAT Gateway processing charge on S3 traffic, which can dominate the bill for data-heavy workloads. A cost-optimized network answer on SAA-C03 is almost always the answer that removes a charged hop from the packet path, not the one that adds a feature.

This topic walks you through the canonical cost-optimized network decisions: reading AWS's data transfer cost map, replacing NAT Gateway traffic with VPC endpoints, using CloudFront to collapse origin egress, picking between VPC Peering and Transit Gateway at scale, trading Direct Connect against Site-to-Site VPN, and choosing PrivateLink over public endpoints when cross-account traffic would otherwise exit and re-enter AWS. By the end you should be able to read any SAA-C03 scenario, identify the most expensive traffic path, and propose a cost-optimized network refactor in one sentence.

Plain-Language Explanation: Cost-Optimized Network

Before we drown in pricing tables, let us anchor a cost-optimized network in everyday metaphors. Three different analogies — postal, utility, and transit — each surface a different facet of AWS network pricing, and you will see them return throughout the chapter.

Analogy 1 — The Postal System (Data Transfer Direction and Distance)

Think of AWS data transfer as an asymmetric postal system. Inbound mail is free: anyone can send you a postcard, letter, or a truck full of packages into your AWS Region and AWS will not charge you a cent. Outbound mail is expensive: every postcard you mail out to the internet gets stamped with postage, and the further it travels the more stamps it needs — a letter across town (within-AZ, free) costs nothing, a letter across the city (cross-AZ in the same Region, a few cents per GB each way) costs a little, a letter across the country (cross-Region) costs more, and an airmail letter to a customer on the internet (DTO) is the most expensive stamp of all. A cost-optimized network is one where you deliver as much mail as possible within the same post office branch (same AZ), and when you must mail to the outside world, you ship through a bulk-discount courier (CloudFront) instead of paying retail stamps at the counter.

Analogy 2 — The Electrical Utility (NAT Gateway as a Metered Converter)

Imagine your private subnet is a European home (230V) and the internet is American (120V). You need a voltage converter to talk to US appliances — that converter is the NAT Gateway. The converter costs money in two ways: a fixed hourly fee just for being plugged in, and a per-kilowatt-hour fee for every unit of electricity that passes through it. If all your appliances talk only to US appliances, you need the converter. But if some of your appliances only talk to other European appliances in the same building (for example, S3 and DynamoDB via Gateway Endpoints), you can bypass the converter entirely for those conversations and save both fees. A cost-optimized network systematically identifies every conversation that does not actually need to cross borders and reroutes it onto free internal wiring.

Analogy 3 — The Bus Terminal vs Private Walkways (Transit Gateway vs VPC Peering)

Suppose you own ten adjacent buildings (VPCs) in a corporate campus. You could string a private walkway between every pair — that is VPC Peering: free per-GB within a Region, but you need 45 walkways for 10 buildings and every walkway is point-to-point, non-transitive, and a maintenance nightmare. Or you could build a central bus terminal (Transit Gateway) that every building has one door into: each building pays a small hourly rent for its terminal attachment, and every passenger pays a per-GB fare to ride. For two buildings with heavy traffic, the walkway wins on cost. For ten buildings with occasional traffic — or any traffic that must transit through a central inspection point like a firewall — the terminal wins on total cost of ownership because you stop paying for the operational overhead of a 45-walkway mesh. Cost-optimized network design chooses between these two based on VPC count, traffic volume, and whether transitive routing is required, not on which one "seems" cheaper in isolation.

With the postal, utility, and transit metaphors in hand, the rest of this chapter becomes an exercise in identifying which metaphor applies to which SAA-C03 scenario.

The AWS Data Transfer Cost Map — Memorize This First

Every cost-optimized network decision begins with one fact: AWS charges for data movement, not for data arrival. Inbound (IN) traffic from the internet into AWS is free in almost every case. Outbound (OUT) traffic and internal traffic that crosses certain boundaries is charged. If you internalize the following cost ladder you will solve roughly half of all cost-optimized network questions on sight.

The Six-Rung Cost Ladder (Cheapest to Most Expensive)

1. Within the same Availability Zone, using private IPv4 addresses: FREE. Two EC2 instances in the same AZ talking over their private 10.x.x.x addresses pay nothing.
2. Inbound from the internet to AWS: FREE. Uploads into S3, API calls into ALB, client posts into API Gateway — no ingress charge.
3. Across Availability Zones in the same Region: charged per GB in both directions (roughly $0.01 per GB out of the source AZ and $0.01 per GB into the destination AZ as of writing — check the current Amazon EC2 pricing page for your Region). This is the silent killer of many cost-optimized network bills.
4. VPC Peering inside the same Region: matches cross-AZ pricing — peering itself is free, but cross-AZ traffic across the peer still costs the cross-AZ rate.
5. Cross-Region data transfer: significantly more expensive per GB, with exact rates varying by source and destination Region. Replicating from us-east-1 to eu-west-1 costs materially more than cross-AZ inside us-east-1.
6. Data Transfer Out to the Internet (DTO): the most expensive standard tier, with volume-tiered pricing (the first GB/month is free globally; prices decline per tiered step as monthly volume grows past 10 TB, 50 TB, 150 TB).

What Is Free — And What Still Bites

Traffic through an Internet Gateway (IGW) itself is free; only the DTO bytes going through it are charged. VPC Peering attachments are free; only the data they carry is charged. An Elastic IP is free while attached to a running instance and charged per hour when unattached — a common cost-optimized network leak. And crucially: traffic between an EC2 instance and an S3 bucket in the same Region via the public S3 endpoint does not count as DTO, but if that traffic has to pass through a NAT Gateway it still incurs NAT Gateway processing charges per GB. That last subtlety is the primary justification for VPC Gateway Endpoints.

Cross-AZ Is the Silent Killer

Many engineers know DTO is expensive but forget that cross-AZ traffic is charged in both directions. If your Application Load Balancer in AZ-a sends a request to an EC2 target in AZ-b, and the target responds, you pay cross-AZ egress from AZ-a plus cross-AZ egress from AZ-b. For a chatty microservices architecture with ten inter-service calls per user request, cross-AZ charges can rival the actual compute bill. A cost-optimized network pins tightly coupled services into the same AZ where resilience allows, or uses features such as ALB cross-zone load balancing controls and EKS topology-aware routing to prefer same-AZ targets.

NAT Gateway Cost and Its Alternatives

NAT Gateway is the single most-charged-per-GB item on many VPC bills because it combines an hourly charge with a per-GB data processing charge that applies to every byte in either direction. At typical public pricing, a NAT Gateway costs roughly $0.045 per hour plus $0.045 per GB processed (prices vary by Region; check the current VPC pricing page). For a workload that pulls 10 TB of data per month through NAT — for example, a fleet of private-subnet EC2 instances downloading container images, OS patches, S3 objects, or third-party APIs — the NAT Gateway data processing bill alone can exceed $450 per month per NAT Gateway, on top of the per-AZ hourly fees.

The Per-AZ vs Shared NAT Gateway Trade-off

Because NAT Gateway is zonal, a highly available deployment places one NAT Gateway per AZ and routes each private subnet to the NAT Gateway in its own AZ. That is the recommended pattern for production. The cheaper alternative is to deploy a single shared NAT Gateway in one AZ and route all private subnets in all AZs to it. The shared pattern saves roughly two-thirds of the hourly NAT Gateway fees in a 3-AZ deployment, but it introduces two downsides: (1) cross-AZ charges apply to traffic from private subnets in the other two AZs heading to the shared NAT Gateway, often erasing the savings, and (2) if the AZ hosting the shared NAT Gateway fails, all outbound internet traffic from the VPC dies until you redeploy. Most cost-optimized network SAA-C03 answers prefer per-AZ NAT Gateways once traffic volumes are meaningful, because cross-AZ fees on NAT traffic outpace the saved hourly fees.

VPC Gateway Endpoints — The Free Alternative for S3 and DynamoDB

A VPC Gateway Endpoint is a route-table entry that points a prefix list (for example, the list of S3 IP ranges in the Region) at a virtual endpoint inside your VPC. Traffic to S3 or DynamoDB takes this route and never touches the NAT Gateway. Critically, VPC Gateway Endpoints are completely free — no hourly fee, no per-GB fee. They support exactly two services: Amazon S3 and Amazon DynamoDB. If your cost-optimized network moves significant volume to S3 or DynamoDB, adding Gateway Endpoints is the highest-leverage single change you can make.

VPC Interface Endpoints (PrivateLink) — Charged but Still Cost-Optimizing

For every AWS service other than S3 and DynamoDB, private access from your VPC uses a VPC Interface Endpoint, powered by AWS PrivateLink. An Interface Endpoint provisions an ENI in each subnet you enable, with a private IP that resolves via private DNS to the AWS service. Interface Endpoints are not free: you pay roughly $0.01 per endpoint per AZ per hour, plus roughly $0.01 per GB processed (exact rates vary by Region). So how does this save money compared to NAT?

The math: a NAT Gateway charges roughly $0.045/hour + $0.045/GB. An Interface Endpoint with three AZs charges roughly 3 × $0.01/hour = $0.03/hour + $0.01/GB. If your workload pushes even modest volume through a given AWS service, the Interface Endpoint's lower per-GB rate dominates the higher fixed cost, and you avoid the NAT Gateway processing fee on the same traffic. For services like KMS, Secrets Manager, SSM, SQS, SNS, and ECR, Interface Endpoints reliably beat NAT after a few hundred GB per month of that service's traffic. Additionally, an Interface Endpoint keeps traffic on the AWS private network with no DTO charge, whereas the equivalent public-endpoint call through NAT would incur NAT processing even on data that never leaves AWS.

NAT Instance — A Rare Cost Alternative

Before NAT Gateway became cheap and scalable, architects ran NAT Instances — ordinary EC2 instances with source/destination check disabled and IPTables rules forwarding traffic. A NAT Instance incurs only the EC2 instance cost (plus its own data transfer), not the NAT Gateway processing fee. For a tiny dev/test VPC with very low traffic and no HA requirement, a t4g.nano NAT Instance can be cheaper than NAT Gateway. For production, NAT Gateway's managed resilience, automatic scaling to 45 Gbps, and absence of single-point-of-failure risk make it the default cost-optimized network choice despite the per-GB fee. SAA-C03 rarely recommends NAT Instance unless the scenario explicitly calls out non-production, cost-above-all, and low traffic.

CloudFront — The Biggest DTO Lever in a Cost-Optimized Network

CloudFront is the second-largest cost-optimized network lever after VPC endpoints, and for any public-internet-facing workload it is often the largest. The core mechanic is simple: every byte that CloudFront serves from its edge cache is one byte that never leaves your origin as DTO. For a cacheable workload with an 80% cache hit ratio, CloudFront takes 80% of the DTO bill off your origin and replaces it with CloudFront DTO — which is cheaper per GB than regional DTO for most destinations, and which also qualifies for committed-use discounts and Free Tier allowances.

CloudFront Egress Pricing Beats Regional DTO

CloudFront's DTO pricing is tiered by price class (destination continent) and by monthly volume. For most destinations, the CloudFront per-GB rate is lower than the equivalent regional DTO rate from S3 or EC2 directly to the internet. CloudFront also includes a permanent Free Tier of 1 TB of DTO per month as of late 2021 changes, which by itself covers many small production workloads. Layered on top, AWS offers private pricing commitments (CloudFront Security Savings Bundle and custom pricing for heavy users) that further reduce the per-GB rate in exchange for a committed monthly spend — a powerful cost-optimized network lever for steady-state workloads.

CloudFront Price Classes — Turn Off Expensive Regions

CloudFront distributes content from 600+ edge locations worldwide, but the per-GB DTO rate varies sharply by region — edges in South America, Australia, and parts of Asia cost materially more per GB than edges in North America and Europe. CloudFront Price Classes let you restrict which edge locations serve your distribution:

• Price Class All — use every edge location globally (best performance, highest cost).
• Price Class 200 — exclude the most expensive edges (South America, Australia, New Zealand, some Asian locations).
• Price Class 100 — use only the cheapest edges (North America and Europe only).

If your audience is concentrated in North America and Europe, switching to Price Class 100 eliminates the expensive edge rates entirely with zero code changes. Users outside the included regions still get content, just routed from the nearest included edge at slightly higher latency. For a cost-optimized network serving a regional audience, Price Class selection is a one-click saving.

Origin Shield — Reduce Cross-Region Origin Fetches

CloudFront Origin Shield inserts an additional caching layer between CloudFront's regional edge caches and your origin. Without Origin Shield, every regional edge cache may independently fetch from your origin on a miss, meaning a single cold object can trigger multiple origin requests. With Origin Shield enabled, regional edges fetch from Origin Shield, and only Origin Shield fetches from the origin — collapsing many potential origin requests into one. For origins in a Region far from your audience, Origin Shield reduces both the origin DTO bill and the origin load. It is billed as a request fee per million requests, so it pays off when cache-miss origin fetches are expensive (large files, cross-Region origins, or high request rates).

CloudFront with S3 — The Classic Cost-Optimized Network Pattern

The textbook pattern: S3 origin, CloudFront distribution in front, Origin Access Control locking S3 to CloudFront-only reads. Benefits for a cost-optimized network:

1. S3 DTO to CloudFront is free (S3-to-CloudFront traffic is not billed as DTO out of S3).
2. CloudFront DTO to users is cheaper per GB than direct S3 DTO.
3. CloudFront cache hits eliminate S3 request charges entirely on cached objects.
4. Origin Shield further reduces any remaining S3 requests.

On a popular static site, this pattern can reduce monthly network bills by 70% versus serving directly from S3 — without any application change.

VPC Peering vs Transit Gateway — Cost at Scale

A cost-optimized network must choose between VPC Peering and Transit Gateway for VPC-to-VPC connectivity, and the correct answer depends almost entirely on VPC count and whether transitive routing is required.

VPC Peering — Zero Fixed Cost, Unscalable at Scale

VPC Peering has no hourly fee and no per-GB peering charge beyond the standard cross-AZ or cross-Region rate. If VPC-A in AZ-1a peers with VPC-B in AZ-1a, same-Region and same-AZ traffic costs zero. Cross-AZ across the peer pays the standard cross-AZ rate; cross-Region across the peer pays the standard cross-Region rate. Peering is non-transitive (A↔B and B↔C do not imply A↔C), so with N VPCs you need up to N×(N−1)/2 peering connections. Five VPCs need 10 peerings; ten VPCs need 45. Beyond roughly four to six VPCs, the operational overhead of maintaining the mesh — route tables, overlapping CIDR checks, IAM for cross-account — dwarfs any dollar savings from peering being "free."

Transit Gateway — Fixed Hourly Per Attachment, Plus Per-GB

Transit Gateway charges two ways: a per-attachment hourly fee (roughly $0.05/hour per VPC, VPN, or Direct Connect attachment, varying by Region) and a per-GB data processing fee on traffic crossing the Transit Gateway (roughly $0.02/GB). For two VPCs with heavy traffic, Transit Gateway is strictly more expensive than VPC Peering because peering carries the data for free while Transit Gateway charges both attachments and data. For ten VPCs, Transit Gateway's fixed cost (10 attachments × $0.05/hour ≈ $360/month) replaces the operational complexity of 45 peering connections and enables transitive routing, shared services VPCs, and centralized egress — features that peering cannot provide at any price.

The Cost-Optimized Network Decision Rule

• Two to three VPCs, stable pairs, no transitive routing needed → VPC Peering (cheapest).
• Four or more VPCs, or any requirement for transitive routing, centralized firewall inspection, or shared services VPCs → Transit Gateway (cheapest once you include operational cost).
• Cross-Region VPC connectivity → either cross-Region VPC Peering or Transit Gateway Peering; the per-GB rates are similar, so pick based on whether you need transitive routing.

Centralized Egress via Transit Gateway

A powerful cost-optimized network pattern at scale: attach all application VPCs to a Transit Gateway, put a single shared egress VPC with its own NAT Gateway (or a fleet of NAT Gateways) on the Transit Gateway, and route all internet-bound traffic through the egress VPC. Instead of running N NAT Gateways in N VPCs, you run one set in the egress VPC. The savings on NAT Gateway hourly fees can be substantial for organizations with dozens of application VPCs, though you must account for the Transit Gateway per-GB processing fee applied to egress traffic as it traverses the hub.

Direct Connect vs Site-to-Site VPN — Cost Trade-offs

For hybrid connectivity, a cost-optimized network must trade two dimensions: fixed cost vs variable cost and setup time vs long-term efficiency.

Site-to-Site VPN Cost Profile

Site-to-Site VPN charges a modest hourly fee per VPN connection (around $0.05/hour per connection, roughly $36/month) plus standard DTO rates on data leaving AWS through the VPN tunnel. The DTO over VPN is at internet DTO rates — the same pricing as any other public internet egress. For low steady-state traffic (say, under 1 TB/month on-premises-bound), the VPN hourly fee dominates and total cost stays low. For higher volumes, the internet DTO rate becomes the dominant cost, because every GB leaving AWS through the VPN is priced like a public internet byte.

Direct Connect Cost Profile

Direct Connect charges two separate components: a port hourly fee based on port speed (1 Gbps, 10 Gbps, 100 Gbps; or hosted connections starting at 50 Mbps) and a reduced per-GB DTO rate for traffic leaving AWS via the Direct Connect link. The Direct Connect DTO rate is typically 60–80% lower than internet DTO for equivalent destinations. So while Direct Connect adds a significant fixed port fee (hundreds to thousands of dollars per month depending on speed), it reduces the marginal cost per GB substantially.

The Break-Even Analysis

The cost-optimized network break-even point between VPN and Direct Connect is roughly:

• Under ~1–2 TB/month of outbound traffic: VPN wins on total cost.
• Above ~5–10 TB/month: Direct Connect wins on total cost, with savings growing linearly thereafter.
• Between 2 and 5 TB/month: depends on Region, port size, and whether you need the non-cost benefits (consistent latency, no public internet exposure, compliance).

Hybrid Pattern — VPN Backup for Direct Connect

A common enterprise cost-optimized network design: Direct Connect as the primary link for its low per-GB rate and consistent performance, plus a low-cost Site-to-Site VPN as backup that only carries traffic when Direct Connect is down. The VPN hourly fee is modest relative to the risk reduction, and because VPN traffic only flows during outages the DTO premium is rarely incurred.

PrivateLink vs Public Endpoints — Hidden Cost Comparison

When one AWS account exposes a service to another AWS account (for example, a SaaS vendor offering an API to customers), there are two transport options and their cost profiles differ sharply for a cost-optimized network.

Public Endpoint Path

Consumer calls the provider's public DNS name. Packets leave the consumer's VPC through a NAT Gateway (or IGW for instances with public IPs), traverse the public internet (or AWS backbone for same-Region same-network AWS services), and arrive at the provider's public ALB or API Gateway. Cost components on the consumer side: NAT Gateway processing per GB + potential DTO to the internet, though same-Region AWS-to-AWS traffic using public DNS is not billed as DTO but still incurs NAT processing. Cost components on the provider side: DTO out of the provider's ALB or API Gateway back to the consumer (for response payloads).

PrivateLink Path

Provider publishes a VPC Endpoint Service on an NLB. Consumer creates a VPC Interface Endpoint pointing at the provider's service. Traffic flows entirely on the AWS private network, never touching NAT or the public internet. Cost components on the consumer side: hourly fee per endpoint per AZ + per-GB data processing (PrivateLink rates). Cost components on the provider side: hourly Endpoint Service fee (small) + the NLB it fronts.

When PrivateLink Wins for Cost-Optimized Network

• The consumer side saves on NAT Gateway processing per GB.
• The provider side saves on DTO back to the consumer — responses over PrivateLink are billed at PrivateLink rates, not DTO rates, which is dramatically cheaper at scale.
• For steady or high-volume consumer-to-provider flows, PrivateLink is unambiguously cheaper once both sides are tallied.

When Public Endpoint Wins for Cost-Optimized Network

• Occasional low-volume calls from many consumers, where the per-AZ hourly PrivateLink cost exceeds the few cents of NAT processing.
• Internet-exposed services that must also serve non-AWS clients, where PrivateLink is not an option anyway.

Cross-AZ Traffic Reduction Patterns

Because cross-AZ traffic charges in both directions and is easy to accumulate accidentally, a cost-optimized network includes deliberate patterns to minimize it without sacrificing resilience.

Pattern 1 — Same-AZ Pinning Within a Service Tier

Deploy tightly coupled services (an application process and its cache, for example) as sets per AZ rather than a mesh across AZs. The application in AZ-a talks to the cache in AZ-a, the application in AZ-b talks to the cache in AZ-b. If one AZ fails, the other AZ's application plus cache continue serving — resilience is preserved at the AZ level rather than at the service level. Cross-AZ fees drop to near zero except during fail-over.

Pattern 2 — Topology-Aware Load Balancing

ALB supports zone-aware routing where the load balancer node in each AZ prefers targets in the same AZ before spilling to other AZs. EKS and ECS support similar topology hints. Enabling same-AZ preference retains capacity across all AZs but routes the common case locally, dramatically reducing cross-AZ fees.

Pattern 3 — Aurora and RDS Reader Endpoint Placement

Aurora's cluster reader endpoint distributes across AZs. If your application pool spans three AZs, each application instance may connect to a reader in a different AZ, generating cross-AZ query traffic. Using per-AZ reader instances and per-AZ custom endpoints lets each application pool read from its local AZ. Same pattern applies to RDS read replicas.

Pattern 4 — S3 Gateway Endpoints Eliminate the AZ Question Entirely

A Gateway Endpoint to S3 routes S3 traffic directly from the instance to the Gateway Endpoint inside the VPC, bypassing both NAT and cross-AZ considerations. For workloads where S3 is the dominant data source, Gateway Endpoints are the single largest cross-AZ and NAT saver.

Route 53 and DNS Cost Optimization

Route 53 is rarely the largest line item in a cost-optimized network, but several small costs add up in large deployments:

• Hosted zone fee: roughly $0.50/month per hosted zone for the first 25 zones.
• Query charges: per-million-query fees differ by query type (standard, latency-based, geo).
• Health checks: each health check costs per month plus optional HTTPS or string-matching premiums.
• Alias records to AWS resources are free — use aliases rather than CNAMEs whenever the target is AWS.

At scale (hundreds of thousands of query-per-second workloads), swapping unnecessary latency-based or weighted policies for simple routing, and consolidating hosted zones where possible, produces measurable savings. More importantly, Route 53 Resolver outbound endpoints and DNS Firewall are extra charged features — only use them where required, not by default.

Throttling and Rate Control as Cost Controls

API Gateway usage plans, AWS WAF rate-based rules, and CloudFront rate-limiting behaviors are not usually thought of as cost-optimized network tools, yet they are powerful in this role. By capping per-client requests, you cap the associated downstream cost: fewer Lambda invocations, fewer DynamoDB reads, fewer origin fetches. For a cost-optimized network that could be scraped or abused, configuring WAF rate-based rules at the edge (before traffic reaches origins) converts a potential bill-shock vector into a bounded spend.

Bandwidth Allocation — Right-Sizing Direct Connect

Direct Connect ports come in fixed sizes (1 Gbps, 10 Gbps, 100 Gbps for dedicated; 50 Mbps through 10 Gbps for hosted). A cost-optimized network sizes the port to peak committed bandwidth plus growth headroom, not to maximum theoretical throughput. Over-provisioning a 100 Gbps port for a workload that averages 2 Gbps wastes money. Under-provisioning forces packet loss and retransmission, which creates its own cost pain.

Putting It All Together — A Cost-Optimized Network Checklist

A production cost-optimized network review should verify:

1. VPC Gateway Endpoints deployed for S3 and DynamoDB in every VPC.
2. VPC Interface Endpoints for high-traffic services (KMS, Secrets Manager, ECR, SSM, CloudWatch Logs) where NAT volume justifies it.
3. NAT Gateway per AZ for production; share only where traffic is genuinely low.
4. CloudFront in front of every public-internet-facing S3 bucket and ALB, with Origin Access Control.
5. CloudFront Price Class aligned to audience geography.
6. Origin Shield for origins serving cache-miss-expensive content.
7. Transit Gateway only at ≥4 VPCs or when transitive routing required; VPC Peering otherwise.
8. Direct Connect only where monthly traffic and latency needs justify the port fee; otherwise Site-to-Site VPN.
9. PrivateLink for high-volume inter-account service consumption on AWS.
10. Cross-AZ traffic reduction via same-AZ pinning and topology-aware routing.

Side-by-Side: Cost-Optimized Network Cheat Sheet

Common Exam Traps for Cost-Optimized Network

1. Gateway Endpoint vs Interface Endpoint confusion — Gateway (free) = S3, DynamoDB only; everything else is Interface (charged).
2. Transit Gateway "always cheaper" — false; for 2–3 VPCs, VPC Peering is cheaper.
3. Cross-AZ traffic is free — false; charged both directions.
4. NAT Gateway saves money by sharing across AZs — usually false; cross-AZ fees erase the savings.
5. Direct Connect DTO is free — false; Direct Connect has discounted DTO, not free DTO.
6. CloudFront only for performance — false; it is also a DTO cost tool with a 1 TB/month permanent Free Tier.
7. VPN and Direct Connect are always alternatives — in practice they are complementary (VPN as DC backup).
8. Elastic IP is always free — false; unattached EIPs charge hourly.
9. PrivateLink is always cheaper than public endpoints — false for very low volumes.
10. Inbound data is free, so IN is always free — true for internet-to-AWS; but cross-AZ "in" is still charged at the receiving AZ.

Cost-Optimized Network vs High-Performing Network — The Boundary

SAA-C03 splits networking across two task statements that sometimes reach for the same services. Task 3.4 (high-performing network architectures) cares about latency, throughput, and topology fitness for performance goals — CloudFront as CDN, Global Accelerator as anycast, Direct Connect for bandwidth, Transit Gateway for topology. Task 4.4 (cost-optimized network architectures) cares about the dollar cost of the same packet path — CloudFront as DTO saver, Gateway Endpoints as NAT bypass, VPC Peering as free mesh at small scale, Direct Connect for cheaper per-GB DTO. The services overlap; the framing does not. On exam day, read the scenario's primary goal sentence: if it says "lowest cost," you are in cost-optimized network territory; if it says "lowest latency" or "highest throughput," you are in high-performing network territory; if it says both, prefer the answer that meets cost while still satisfying the performance constraint.

FAQ — Cost-Optimized Network Top Questions

Q1: How do I reduce NAT Gateway costs for a VPC that heavily accesses S3?

Add a VPC Gateway Endpoint for S3 to the VPC and associate it with the route tables of every private subnet. S3 traffic then bypasses the NAT Gateway completely, eliminating the NAT processing charge on those bytes. Gateway Endpoints are free — there is no hourly or per-GB charge — so this is always a net-positive change. If the VPC also hits DynamoDB, add the DynamoDB Gateway Endpoint too. For workloads that also consume services like ECR, KMS, or Secrets Manager at meaningful volume, evaluate Interface Endpoints against the NAT Gateway processing cost they would replace.

Q2: When is VPC Peering cheaper than Transit Gateway, and when does that reverse?

VPC Peering is cheaper for a cost-optimized network when you have a small number of VPCs (typically 2–3), stable peering pairs, and no need for transitive routing or central inspection. Peering has no attachment fee and no per-GB data processing charge beyond standard cross-AZ or cross-Region rates. Transit Gateway becomes cheaper once you hit roughly four or more VPCs, need transitive routing, or want centralized egress/inspection, because the operational cost of an N×(N−1)/2 peering mesh plus the capabilities you gain from the hub-and-spoke topology outweigh Transit Gateway's per-attachment hourly fee and per-GB data processing fee.

Q3: Is CloudFront actually cheaper than serving directly from S3?

For public-internet-facing content, yes, in almost every case. CloudFront's per-GB DTO rate is lower than regional S3 DTO for equivalent destinations, S3-to-CloudFront traffic is not billed as DTO out of S3, and CloudFront includes a permanent 1 TB/month Free Tier. Additionally, cache hits eliminate S3 request charges entirely on cached objects. For a private workload served only to clients inside the same VPC or AWS account, CloudFront does not help — but for any content accessible from the public internet, putting CloudFront in front of S3 with Origin Access Control is a cost-optimized network default.

Q4: What is the cost-optimized network way to connect an on-premises datacenter to AWS?

It depends on monthly traffic volume. For under roughly 1–2 TB/month of outbound traffic, Site-to-Site VPN wins on total cost — the hourly fee is low and VPN traffic is billed at internet DTO rates, which is fine at low volumes. For more than roughly 5–10 TB/month, Direct Connect wins because its discounted per-GB DTO rate (often 60–80% cheaper than internet DTO) offsets the port hourly fee within a few TB. Between those thresholds, run the math for your specific Region and destination. Many enterprises use Direct Connect primary with VPN backup — getting Direct Connect's cheap per-GB cost for normal traffic plus VPN's low-cost standby during outages.

Q5: How do I reduce cross-AZ data transfer charges without breaking high availability?

Use topology-aware routing patterns: deploy tightly coupled services (application plus cache, application plus database reader) as per-AZ sets, and configure load balancers with zone-aware routing that prefers same-AZ targets. For Aurora and RDS reader fleets, place a reader instance in each AZ and use per-AZ endpoints so each application pool reads locally. For S3, Gateway Endpoints bypass the cross-AZ question entirely. The principle: retain capacity across AZs for failure tolerance, but route the common case locally so cross-AZ fees only accrue during actual failover.

Q6: When should I choose PrivateLink over a public endpoint for a cross-account AWS service?

Choose PrivateLink when the consumer side's NAT Gateway processing cost plus the provider side's DTO cost — both of which disappear with PrivateLink — exceed PrivateLink's per-AZ hourly and per-GB fees. That break-even happens quickly for steady-state or high-volume flows. For low-volume consumption from many consumers, or when the service must also be reachable from non-AWS clients, public endpoints remain the cost-optimized network choice. A useful rule of thumb: if you are about to provision a NAT Gateway primarily to reach a specific AWS-hosted service, PrivateLink is almost certainly cheaper.

Q7: Does putting a NAT Gateway in every AZ really save money compared to sharing one?

Usually yes, once you account for cross-AZ fees. A shared NAT Gateway in one AZ saves roughly two-thirds of the hourly NAT Gateway fees in a 3-AZ VPC, but it charges cross-AZ fees on every byte from the other two AZs' private subnets heading to the shared NAT. Those cross-AZ fees typically outweigh the saved hourly fees once monthly traffic crosses a modest threshold, and the shared model also creates a single-AZ failure dependency for all internet egress. For production cost-optimized network design, deploy NAT Gateway per AZ; share only in genuinely low-traffic non-production VPCs where the hourly fee dominates.

Further Reading

• AWS VPC Pricing Page (check current per-Region rates)
• AWS PrivateLink Pricing Page
• CloudFront Pricing and Price Classes Documentation
• AWS Transit Gateway Pricing Page
• AWS Direct Connect Pricing and Connection Types
• AWS Well-Architected Framework — Cost Optimization Pillar (Networking section)
• AWS Whitepaper: Overview of Amazon Web Services — Networking and Content Delivery
• AWS Whitepaper: Building a Scalable and Secure Multi-VPC AWS Network Infrastructure

Master these cost-optimized network levers — the data transfer cost map, Gateway and Interface Endpoints, CloudFront with Price Classes and Origin Shield, Transit Gateway vs VPC Peering at scale, Direct Connect vs VPN break-even, PrivateLink vs public endpoints, and cross-AZ reduction patterns — and SAA-C03 Task 4.4 becomes a reliable scoring area. Every cost-optimized network question on the exam is ultimately asking you to spot the charged hop and remove it. Do that consistently and your architectures will stay within budget long after the exam is behind you. Good luck on your SAA-C03 cost-optimized network questions.