Data Transfer Modeling: NAT, Endpoints, CloudFront, and Hybrid

Model the path before you buy the pipe

Task 2.6 on the official SAP-C02 outline explicitly lists data transfer costs and the skill of performing data transfer modeling. That is a new-solution activity: draw every packet path while the VPC is still a diagram. Task 3.5 is the opposite tempo: CUR already shows NatGateway-Bytes, DataTransfer-Regional-Bytes, or inter-Region AWS-Out-Bytes, and you must stop the hemorrhage. Task 1.5 still applies because those usage types are often shared-platform costs that tagging never captured—Cost Categories and a networking-account showback rule belong next to the technical fix.

Do not quote a memorized per-gigabyte figure on the exam unless the item prints one. Rates vary by Region pair and change. What does not change is the ranking of paths and which service removes which charge.

The qualitative cost ladder

Inbound data transfer into AWS is generally free. Almost every painful bill is outbound or inter-node.

Public or Elastic IP hairpinning even inside a Region can attract regional data-transfer charges that private IP would not. Keep east-west traffic on private addresses.

NAT Gateway bills exploding: existing forensics and new design

The signature Task 3.5 stem is a private-subnet fleet whose NAT Gateway line item rivals compute. NAT Gateway charges per hour per AZ (you usually deploy one NAT per AZ for HA, which multiplies the hourly component) and per gigabyte processed. That processing fee applies to every byte the NAT sees: software updates, third-party APIs, and Amazon S3 or Amazon DynamoDB if the route to those public endpoints still goes 0.0.0.0/0 → NAT.

Gateway VPC endpoints for S3 and DynamoDB are the first architectural fix. They are route-table prefixes, they do not use PrivateLink ENIs, and AWS offers them with no additional hourly or per-GB endpoint charge. After you add the routes, S3 and DynamoDB traffic never hits the NAT, so NAT processing for that volume drops to zero. You may still pay inter-AZ transfer if the instance and the endpoint path cross AZs; place endpoints and workloads with AZ affinity where the volume is huge.

Interface VPC endpoints cover most other AWS APIs (Amazon SQS, Amazon SNS, Amazon ECR, AWS Systems Manager, Amazon CloudWatch, and so on). They do charge hourly per AZ and per-GB processing, but for high-volume AWS API traffic they still often beat NAT because you avoid NAT processing and internet egress to the public AWS endpoint. For a new VPC (Task 2.6), decide the endpoint set on day one. For an existing VPC (Task 3.5), read CUR: if NatGateway-Bytes correlates with S3 GetObject from private subnets, add the gateway endpoint before you buy a bigger NAT.

Do not “fix” NAT cost by adding more NAT Gateways unless you have AZ-by-AZ throughput or resiliency evidence. Extra NATs add hourly charges. Compute Optimizer can now recommend NAT Gateway rightsizing on existing gateways; that is a 3.5 overlay, not a substitute for endpoints.

CloudFront, S3 same-Region versus cross-Region

If humans on the public internet download cacheable bytes, Amazon CloudFront is usually cheaper and faster than opening the bucket or the ALB to the world. Origin fetches from S3 or EC2 to CloudFront do not use the same internet-egress economics as serving every viewer from the origin. Cache hit ratio is the cost control: cache POSTs? No. Cache versioned software artifacts and media? Yes. Lambda@Edge / CloudFront Functions add compute at the edge; they are performance tools that can reduce origin load, not a blank check.

Same-Region S3 is the default for application data sitting next to compute. S3 Cross-Region Replication (CRR) adds inter-Region data transfer out plus duplicate storage. Use CRR when the requirement is distance, sovereignty, or Region isolation—not as a casual cost-optimization. S3 Transfer Acceleration is a performance path via edge locations for long-haul uploads; it is an extra transfer component, not a discount plan.

Direct Connect versus VPN, and inter-AZ honesty

AWS Direct Connect is the professional answer for steady, high-volume hybrid transfer: a dedicated (or hosted) port billed per hour, plus data-transfer-out over DX that is typically lower than sending the same bytes out the internet through a NAT or a VPN. AWS Site-to-Site VPN remains the right backup or low-volume overlay: it is quick to stand up and it encrypts over the internet, so it does not inherit DX transfer rates. A 50 TB/month nightly warehouse feed on VPN is an exam smell; the same feed on DX with VPN as failover is the pattern.

Inter-AZ cost is the HA tax. Multi-AZ RDS, Aurora storage replication, and three-AZ Kubernetes are still the reliability default. The cost lever is chatty application traffic: session stores, mesh sidecars, and chatty microservices that replicate every request across AZs. AZ-aware routing, local caches (Amazon ElastiCache with same-AZ readers where consistency allows), and not forcing every byte through a central inspection VPC unless a security requirement says so, are Task 2.6 modeling choices. After the fact, CUR regional transfer line items plus VPC Flow Logs tell you which pair of subnets is talking.

Transit Gateway and inspection hubs add data processing of their own. Centralizing NAT or inspection for dozens of VPCs is a valid security architecture; it is also how a networking account becomes the largest bill in showback. Pair the technical design with Task 1.5 Cost Categories so product teams see the allocated TGW/NAT bytes rather than treating the networking account as a mystery tax.