SAP-C03 Data Transfer and Network Cost Optimization: CloudFront, VPC Endpoints, NAT, Transit Gateway and Replication

Data transfer cost on AWS comes from a small set of meters, and an architect lowers it by changing the path traffic takes so that it crosses fewer of them. Data coming in from the internet is free. Data leaving AWS to the internet is charged per GB. Data crossing between Regions is charged per GB by the sending Region. Data crossing between Availability Zones in the same Region is charged in each direction. On top of the transfer meters sit processing charges: a NAT gateway, a transit gateway attachment, an interface VPC endpoint and VPC Lattice each bill per GB that flows through them, and a Network Load Balancer bills capacity units in which processed bytes are one dimension.

Two habits follow from this table. First, price a design by following each GB from source to destination and adding every meter it crosses, rather than looking at a single service. Second, the cheapest design usually moves data once to where it is read many times, then serves the repeated reads locally. Every section below applies one of those habits.

Putting Amazon CloudFront in front of an AWS origin is the main way to cut internet egress, because data transfer from AWS origins (Amazon S3, Application Load Balancers, Amazon EC2) to CloudFront edge locations is free, CloudFront's own delivery rates are lower than S3 or EC2 data transfer out to the internet, and every cache hit is served without touching the origin at all. This holds for dynamic sites too: an ALB origin serving shared, cacheable pages and images benefits in the same way, and uncacheable requests still travel over the AWS network at CloudFront rates. For a private S3 bucket, use origin access control (OAC) so only the distribution can read it.

Options that look like egress savings but are not

• S3 Requester Pays moves request and transfer charges to the requester, but the requester must be an authenticated AWS identity. Anonymous web visitors cannot be billed, so it does not fit a public website.
• S3 Multi-Region Access Points route requests to the nearest replica bucket, but they add a per-GB data routing charge (and an internet acceleration charge for internet traffic) on top of normal transfer.
• AWS Global Accelerator improves the network path to load balancers, EC2 instances and Elastic IP addresses, but it caches nothing, cannot use an S3 bucket as an endpoint, and adds an hourly fee plus a data transfer premium.
• S3 Transfer Acceleration speeds long-distance uploads and downloads through edge locations and adds a per-GB fee; it is a speed feature, not a cost saving.

Price classes

A CloudFront price class limits which edge locations serve the distribution, so you stop paying the highest-cost regional rates. Viewers outside the chosen class are not blocked: they are served from an included edge location, with higher latency. A geographic restriction is a different feature that refuses viewers by country, so it is never the way to save money while staying reachable.

Pick the smallest class that still contains every region where your viewers are. For steady, predictable CloudFront usage, the CloudFront Security Savings Bundle lowers the bill in exchange for a one-year commitment of monthly spend, so it is the wrong lever when the requirement is no commitment. CloudFront also offers flat-rate pricing plans: a fixed monthly price per distribution with a usage allowance and no overage charges, which suits teams that want a predictable bill rather than pay-as-you-go rates.

The cost of a CloudFront distribution falls as its cache hit ratio rises, and the hit ratio is decided mostly by the cache key. CloudFront separates two policies attached to a cache behavior:

The rule is: the cache key contains only what changes the response. Suppose a search results page changes with its sort and currency query strings, while the origin also wants a tracking cookie and a device-type header for analytics. Key on the two query strings and forward the cookie and header through an origin request policy. Every value that is unique per visitor or per device and sits in the cache key splits the cache into near-identical copies that are each fetched from the origin.

Compression and long TTLs for versioned assets

To reduce the bytes delivered, enable Gzip and Brotli in the behavior's cache policy (this also makes the normalized Accept-Encoding part of the key) and turn on automatic object compression for the behavior, so CloudFront compresses text files such as JavaScript, CSS and JSON at the edge. Then set a long Cache-Control: max-age on any file whose name carries a fingerprint of its contents (for example styles.8d2e7b.css), so the setting travels with the object from the moment the pipeline writes it. Because the file name changes with every release, the old object never needs replacing, and browsers and edges reuse it without re-downloading.

Invalidation is for objects whose names do not change. A wildcard such as /* counts as a single path against the monthly free allowance, but invalidation only removes cached copies: it does not reduce the bytes delivered and, used after every deploy, it forces the edges to refetch everything. Versioned file names make most invalidations unnecessary.

CloudFront Origin Shield is an extra, centralized caching layer that collapses cache misses from all regional edge caches into a single request to the origin, which lowers origin load and origin-side egress. It is configured per origin, and you choose the Origin Shield Region with the lowest latency to that origin; for an AWS origin that is normally the origin's own Region.

When Origin Shield pays off

• Viewers spread across many geographies, so many regional edge caches miss on the same object.
• Origins that are expensive to hit: just-in-time video packaging (for example AWS Elemental MediaPackage), on-the-fly image processing, on-premises origins with limited bandwidth.
• Multi-CDN setups, where Origin Shield acts as the one cache in front of the origin for every CDN.

Origin Shield has its own request charge. Requests it treats as dynamic always pass through it as an extra layer and are always charged: PUT, POST, PATCH and DELETE requests, requests to behaviors with caching disabled, and GET or HEAD requests whose TTL is under 3,600 seconds (so frequently refreshed objects, such as live playlists, count as dynamic). Cacheable requests are charged only when they reach Origin Shield from a regional edge cache in a different Region; requests that start in the Origin Shield Region itself skip the extra layer. Because Origin Shield is a property of an origin, a distribution can define the same host twice: one origin entry with Origin Shield for the cache behaviors that serve long-lived objects, and one without it for behaviors that carry uncacheable traffic. Keep the cache policy on the shielded behaviors lean too, or cookies and irrelevant query strings split the cache and defeat the shield.

Origin groups for failover

A CloudFront origin group lists a primary and a secondary origin and a set of failover status codes (typically 5xx) and timeouts. When the primary fails a request, CloudFront retries that request against the secondary, inside the same distribution. Origin failover applies only to GET, HEAD and OPTIONS requests, so it protects read paths, not writes. For a static site in S3, the low-cost Regional failover pattern is S3 Cross-Region Replication to a bucket in a second Region plus an origin group that uses both buckets. You pay for the replica's storage and replication, and the secondary serves traffic only after a failure.

A routing or acceleration service placed in front of the origin adds its own charges to every request, not just the requests served during a failure, so check its fee schedule before using it as a failover layer (the S3 and Global Accelerator charges are covered above).

Origin groups work with Origin Shield, but each origin uses its own setting. After failover, requests reach the secondary through the secondary's Origin Shield, not the primary's. Enable Origin Shield on every origin in the group, each in the Region closest to that origin (a replica bucket in ap-southeast-2 gets a shield in ap-southeast-2), or the secondary takes the full, unshielded load during a failover.

Traffic from private subnets to AWS services is cheapest through VPC endpoints, because a NAT gateway charges per GB processed on top of its hourly fee, and that processing charge dominates at volume.

Gateway endpoints

For same-Region S3 or DynamoDB traffic from private subnets, a gateway endpoint associated with the private route tables removes the NAT processing charge at no cost and keeps instances without public IPs. A gateway endpoint never carries cross-Region traffic: requests to a bucket in another Region do not match its prefix list and follow the default route, through NAT, so cross-Region S3 reads keep their NAT and inter-Region charges.

Interface endpoint economics

• High-volume service traffic (for example Amazon CloudWatch Logs, Amazon SQS or AWS Secrets Manager) from private subnets should use that service's interface endpoint with private DNS, because its per-GB rate is far lower than NAT processing.
• Low-traffic environments pay mostly the per-AZ hourly fee. Two levers cut that fee: S3 and DynamoDB traffic that stays inside the VPC can use free gateway endpoints instead of interface endpoints, and where a workload can tolerate losing endpoint access if one AZ fails, fewer endpoint subnets mean fewer AZ-hours. Production VPCs normally keep an endpoint ENI in every AZ they use.
• Private Amazon ECR pulls need three endpoints: interface endpoints for ecr.api and ecr.dkr, and an S3 gateway endpoint, because image layers are stored in S3.

Centralized endpoints: the break-even

Sharing one set of interface endpoints in a central VPC across many spokes through AWS Transit Gateway avoids paying endpoint hours in every VPC, which suits many low-volume spokes. But each GB from a spoke then also pays transit gateway processing. For one very high-volume VPC, a local interface endpoint for that service costs less than routing its traffic through the hub, so leave other spokes on the shared endpoints and give the heavy VPC its own. (The routing and DNS design of centralized endpoints is covered in the SAP-C03 network architecture lesson; this lesson covers only the cost decision.)

Inter-AZ data transfer is charged in each direction, so an AZ-aware architecture keeps traffic in the AZ where it starts whenever availability does not require crossing.

One NAT gateway per AZ

A single zonal NAT gateway shared by private subnets in three AZs makes two-thirds of the egress cross an AZ boundary, adding inter-AZ charges, and makes one AZ a single point of failure. Creating a NAT gateway in each AZ and routing each AZ's private subnets to the NAT gateway in the same AZ removes both problems.

Regional NAT gateways (2025) span AZs automatically: they need no public subnet and expand into an AZ when workloads appear there. That expansion can take up to 60 minutes, during which traffic from the new AZ is processed across zones and pays inter-AZ charges. They also contract out of an AZ that no longer has active workloads, so a fleet that repeatedly starts in an otherwise empty AZ can meet the expansion window again on each run, paying cross-zone processing every time. They do not support private NAT. For bursty, short-lived workloads in an otherwise empty AZ, zonal NAT gateways in each AZ avoid the cross-zone window; for steady workloads in fixed AZs, the regional gateway reduces management.

Keeping service-to-service traffic in-zone

• Amazon MSK rack awareness: by default Kafka consumers read from the partition leader, often in another AZ. Set replica.selector.class to org.apache.kafka.common.replica.RackAwareReplicaSelector in the cluster configuration and set client.rack on each consumer to its AZ ID (for example use1-az1), and consumers fetch from a same-AZ replica. Replication between brokers inside an MSK cluster is not charged as data transfer.
• Kubernetes topology-aware routing: setting trafficDistribution: PreferClose on a Service (or the older topology-aware routing hints) makes calls prefer endpoints in the caller's zone, while still falling back to other zones.
• Load balancers: with Network Load Balancer cross-zone load balancing turned on, traffic sent to targets in other AZs incurs inter-AZ charges; when every AZ has healthy targets, turning it off keeps each node's traffic local. Application Load Balancer traffic to targets in other AZs is not charged as inter-AZ transfer, so ALB cross-zone is not a cost lever.

The four ways to connect VPCs charge for different things, so the cheapest choice depends on how much data flows between which pairs.

Hub plus direct peering

Transit Gateway processing is charged per GB, so any two VPCs that exchange a large, steady volume (for example a central log archive and a security analytics VPC) pay that processing on every byte. Keep Transit Gateway as the hub for everything else and peer the heavy pair directly, routing each other's CIDR through the peering connection; more specific routes win, so only that pair's traffic moves.

Inter-Region flows

For traffic from a VPC in one Region to a VPC in another through peered transit gateways, processing is charged once, at the sending side's transit gateway when the data enters from the VPC attachment, plus inter-Region data transfer out of the source Region. The receiving transit gateway does not charge processing for data arriving over the peering attachment.

PrivateLink

When a central team exposes an API to many consumer VPCs, some with overlapping CIDRs, PrivateLink fits: publish the API as an endpoint service behind an NLB, and each consumer creates its own interface endpoint and pays for it. No routes are exchanged, so overlapping address space does not matter, and the provider does not carry consumers' endpoint costs.

For large, steady flows from AWS to on premises, AWS Direct Connect is cheaper per GB than Site-to-Site VPN, because data transfer out over Direct Connect is billed at Direct Connect rates, which are well below the internet data transfer out rates that VPN traffic pays. VPN adds its own connection-hour fee. If a Direct Connect connection already exists, routing heavy analytics exports over it rather than over VPN lowers the bill without new infrastructure.

The rate is a property of the path. Anything that keeps the traffic on the internet-based VPN, whether it adds speed or bandwidth, keeps internet egress rates and may add fees of its own; a managed copy service adds its per-GB fee on top of whichever path carries the bytes. Only moving the bytes onto Direct Connect changes the egress rate.

Reaching Amazon S3 from on premises over Direct Connect

So for on-premises access to your own S3 data at volume, a public VIF is the lower-cost path; choose the interface endpoint when private IP addressing or a no-public-route policy is the stated requirement.

Replication costs scale with what you copy and how many copies you keep, so a cost-aware design replicates only the data that needs a second Region and stores the copy in the cheapest form that still meets its access need.

Amazon S3 Cross-Region Replication levers

S3 Cross-Region Replication (CRR) bills inter-Region data transfer, requests at the destination and storage of the replica. Three settings control the bill:

• Filters: scope each rule with a prefix or object tag filter so only the data that needs a copy is replicated.
• Destination storage class: a rule can store replicas in a cheaper class. For a rarely read copy that must still return in milliseconds, S3 Glacier Instant Retrieval fits; S3 Glacier Deep Archive is cheaper but restores take hours, so it fails a fast-read requirement.
• S3 Replication Time Control (RTC): gives a replication SLA with metrics and is billed per GB replicated under rules that enable it. RTC is set per rule, so split rules by SLA and enable it only on the prefixes or tags whose data needs the guaranteed replication time.

Existing objects are not replicated by a new rule; S3 Batch Replication copies them as a one-time job.

Amazon DynamoDB global tables cost

A global table bills every write again in each replica Region as a replicated write, plus inter-Region transfer and storage in each Region, so its write cost is roughly writes multiplied by replicas. To cut it:

• Remove replicas in Regions that no longer serve users.
• Keep frequently updated attributes that only matter in one Region in a separate single-Region table, and write the global item only when data the other Regions need changes.
• Remember that TTL deletes are free in the Region where they happen but replicate to the other replicas as replicated writes.
• Amazon DynamoDB Accelerator (DAX) caches reads; it does not reduce writes or replication.
• Multi-Region strong consistency (MRSC) still replicates every write and is available only in three-Region configurations, so it is never a cost saving.

Disaster recovery without a global table

Global tables are for active-active workloads or seconds-level RPO. When hours of RPO and RTO are acceptable, a cheaper design keeps a single-Region table and uses AWS Backup to copy backups to a vault in another Region (cross-Region copy of DynamoDB backups needs AWS Backup advanced features for DynamoDB). Point-in-time recovery can restore to another Region, but its backups live in the source Region, so it cannot help if that Region is unavailable. Table class choices change storage and throughput pricing, not where a recoverable copy lives.

AI workloads add two data transfer decisions: where model inference runs, and where model artifacts and training data are read from.

Amazon Bedrock cross-Region inference

Cross-Region inference sends on-demand requests through an inference profile that can route them to other Regions with capacity. AWS charges no extra routing or data transfer fee for it, and tokens are billed at the price of the source Region you call from.

With no residency constraint and real-time traffic, the global profile is the cheaper choice. When data must stay inside a geography such as the EU, the geographic profile adds throughput at standard pricing without leaving it. Other Bedrock pricing options solve different problems: batch inference lowers per-token price for supported models but returns results asynchronously, and Provisioned Throughput is a capacity commitment that inference profiles do not use. (Controlling which accounts may use cross-Region profiles, and residency guardrails, belong to the security and governance lessons.)

Keep AI data next to the compute that reads it

Model weights and training datasets are large and read repeatedly, so reading them across Regions pays inter-Region transfer on every node start or every job. Move them once instead: replicate the bucket (for example with S3 replication) to each Region where they are read, point the inference nodes or training jobs at the local copy, and read it through an S3 gateway endpoint so the reads skip NAT processing. Each new model version then crosses Regions once.

The test for any alternative is whether each read still leaves the Region. If it does, the inter-Region transfer repeats on every read however the request is routed or accelerated, and routing or acceleration features add their own per-GB fee on top. Gateway endpoints help only after the copy is local, because they reach same-Region buckets only.