CertExams/SAA-C03/Domain4/D4_CostOptimizedNetworkArchitecture

Design Cost-Optimized Network Architectures

Core Idea

AWS networking is a managed service — you no longer own switches/routers, and you pay for network resources the same consumption-based way you pay for CPU/storage. The catch: API calls and data transfer costs are easy to forget and are where most network cost surprises come from.

Hybrid Connectivity Cost Choice

Direct Connect is generally more costly than Site-to-Site VPN. Default to VPN unless the scenario specifically needs Direct Connect's throughput or security guarantees — don't reach for Direct Connect just because it "sounds more robust."
Separately, for managing/accessing EC2 instances (not app traffic): classic SSH/RDP vs. Systems Manager Session Manager vs. EC2 Instance Connect — each has different cost implications, know them.

VPC-to-VPC Connectivity Cost Choice

VPC Peering vs. Transit Gateway: peering can be more cost-effective for connecting VPCs, especially across Regions, since cross-Region data transfer charges apply regardless of the mechanism — so the connectivity method's own cost becomes the deciding factor once volume is fixed.

Minimizing Data Transfer Charges — the Core Skill of This Lesson

VPC Gateway Endpoints (S3, DynamoDB): communication with these two services incurs no data transfer charge within the same Region when routed through a gateway endpoint.
Traffic that crosses an Availability Zone boundary typically incurs a charge — prefer resources in the same AZ when possible to avoid it.
NAT Gateway cost tactic: production should have one NAT Gateway per AZ (for resilience), but development environments can share a single NAT Gateway to cut hourly cost — resilience/cost trade-off made explicit per environment tier.

API Throttling as a (Cost-Adjacent) Design Concern

API Gateway usage plans + API keys: control transactions-per-second and per-period quotas per customer, and throttle requests once limits are hit — framed here primarily as a control mechanism, but it prevents cost blowouts from runaway/abusive usage.

Bandwidth & Failover Cost Choice

On-prem connected via Direct Connect, need a low-cost failover path: choose Site-to-Site VPN, not a second Direct Connect connection — a second DX connection adds both cost and setup time; VPN is faster to configure and cheaper.

S3 Cost Structure (as it intersects with networking)

You pay for: storage, API calls, and data transfer out.
Cost lever: reduce API calls and data transfer — fronting S3 with CloudFront is the standout tactic here, not just for latency but specifically for cost, since a well-designed CloudFront caching layer cuts repeated origin fetches and thus repeated data-transfer-out charges.
CloudFront's own cost advantages: no charge for data transferred from AWS origins (S3, EC2, ELB) to CloudFront edge locations, and regional edge caches at no additional cost — reducing both operational burden and cost on the origin.
CloudFront use cases go beyond fronting S3 — worth exploring broadly, not just as an S3 cache.

Monitoring & Root-Cause Tooling

CloudWatch, Health Dashboard, VPC Reachability Analyzer, Transit Gateway Network Manager, Config, Route Analyzer — the toolkit for finding why a network cost or performance issue is happening, not just that it's happening.

General Cost-Review Habits

Start with historical cost pattern monitoring.
Prefer keeping data in the same AZ/Region when possible.
Some Regions cost more than others — factor Region selection into cost design when there's no hard latency/compliance constraint forcing a specific Region.
Use the free tier where applicable.

Exam Angle

Expect "no data transfer charge for X" pointing to Gateway Endpoints (S3/DynamoDB only — Interface Endpoints/PrivateLink are not free), VPN-vs-Direct-Connect cost-only framing, single-shared-NAT-Gateway-for-dev, and CloudFront-in-front-of-S3-to-cut-cost scenarios.

Practical Examples

NAT Gateway cost tactic, concretely: A dev environment has 3 AZs, each with its own NAT Gateway "to mirror production" — that's 3x the hourly NAT Gateway charge for an environment where nobody's on-call and downtime for one AZ's outbound traffic is a non-issue. Consolidating dev to a single shared NAT Gateway in one AZ cuts that cost by two-thirds; production keeps one-per-AZ for its actual resilience requirement.

Gateway Endpoint avoiding a NAT bill entirely: An app in a private subnet downloads config files from S3 constantly, routed through a NAT Gateway — racking up both the NAT Gateway's hourly charge and its per-GB data-processing charge. Adding an S3 Gateway Endpoint removes this traffic from the NAT path completely (free, route-table-based) — for an S3-heavy workload this alone can be a meaningful chunk of the monthly network bill.

VPN vs. Direct Connect for a new hybrid link: A mid-size company needs private connectivity to AWS but doesn't have massive sustained throughput needs and wants something live in days, not weeks. Site-to-Site VPN (cheap, minutes to provision) is the right default. A financial firm doing continuous large-scale data replication needing consistent low-latency, high-throughput, dedicated bandwidth reaches for Direct Connect instead, accepting the higher cost and multi-week lead time for the performance/reliability guarantee.

Cheap DX failover: A company already has a Direct Connect connection as their primary path to AWS and wants a backup for the rare DX outage. Standing up a second Direct Connect connection means real cost and lead time for something used rarely. A Site-to-Site VPN as the failover path is far cheaper, provisions in minutes, and only carries traffic during the (hopefully rare) DX outage window.

CloudFront cutting S3 egress cost: A public dataset bucket in S3 serves the same handful of popular files to thousands of downloaders daily, each download billed as S3 data-transfer-out. Fronting the bucket with CloudFront means the first request per edge location fetches from S3 (and that S3→CloudFront hop is free for AWS origins), but every subsequent request at that edge is served from the CloudFront cache — dramatically cutting actual S3 egress charges for popular content.

Same-AZ placement avoiding cross-AZ charges: A chatty microservice pair (frequent small requests back and forth) gets deployed with one service's ASG in us-east-1a and the other's in us-east-1b "for resilience," not realizing every single call between them now crosses an AZ boundary and incurs a data-transfer charge. For latency- and cost-sensitive high-chatter pairs, keeping the primary traffic path within one AZ (while still using multi-AZ for the redundant copies) reduces both latency and cost — the resilience goal can be met with AZ-aware routing rather than by scattering every hot-path call across AZs indiscriminately.