Skip to content
Cloud Efficiency Hub

Internet Traffic Served Directly from S3 or EC2 Instead of CloudFront

The short version

Public websites, static assets, software downloads, media and APIs are often served straight from an S3 bucket, an EC2 instance or an internet-facing load balancer.

PointFive Research

Cloud cost research at PointFive

AWS service
AWS CloudFront
Category
Networking
Reference
CER-0350
Type
Inefficient Architecture

Explanation

Why the waste happens and who it affects.

Every byte then leaves AWS as regional data transfer out to the internet, billed by the origin service. Putting Amazon CloudFront in front of the same origin changes the billing: data transferred from AWS origins to CloudFront edge locations is free, and viewers are billed at CloudFront's own delivery rates, which include a monthly always-free allowance and volume tiers.

The pattern usually starts with a bucket made public for a quick download link or an ALB exposed directly at launch, and is not revisited as traffic grows. It affects content-heavy and download-heavy workloads most, and the saving is largest when a high share of responses is cacheable, because CloudFront also stops repeat requests from reaching the origin. AWS Well-Architected (COST08-BP03) lists edge locations and CDNs as a way to reduce data transfer cost.

Billing model

The pricing dimensions that drive this cost.

Origin internet egress
S3, EC2 and ELB traffic to the internet is billed per GB at regional data transfer out rates, after 100 GB per month free across all AWS services
Origin fetches to CloudFront
Data transferred from AWS origins such as S3, EC2 and ELB to CloudFront edge locations is free of charge
CloudFront data transfer out
Billed per GB by viewer geography in volume tiers, with the first 1 TB per month free under the always-free tier
CloudFront requests
Billed per 10,000 HTTP or HTTPS requests by geography, with the first 10 million requests per month free
Flat-rate plans
Fixed monthly CloudFront plans with usage allowances and no overage charges, as an alternative to pay-as-you-go

How to detect

4 checks to find it in your estate.

  • In Cost Explorer or the Cost and Usage Report, group S3, EC2 and ELB costs by usage type and look for large internet data transfer out lines (usage types containing DataTransfer-Out-Bytes)
  • Identify S3 buckets that serve public reads or use static website hosting, and check whether their download volume goes to the internet rather than through a CloudFront distribution
  • Find internet-facing ALBs and EC2 instances whose responses are mostly static or cacheable content such as images, scripts, installers or video segments
  • Compare the origin's monthly internet egress against CloudFront pay-as-you-go rates and flat-rate plan allowances for the same traffic profile

How to fix

5 ways to remove the waste.

  • Create a CloudFront distribution with the S3 bucket, ALB or EC2 instance as origin, and point the public DNS name at the distribution
  • For S3 origins, use origin access control and a bucket policy scoped to the distribution so the bucket no longer needs to be public and viewers cannot bypass CloudFront
  • Set cache behaviors and TTLs so static and cacheable paths are served from edge caches, which also reduces origin requests and compute
  • Evaluate CloudFront flat-rate plans or the CloudFront Security Savings Bundle when traffic is predictable, and compare them with pay-as-you-go before committing
  • Keep in mind that uncacheable, highly personalized responses still generate a CloudFront request and delivery charge, so model the traffic mix before moving dynamic APIs

Documentation

Vendor references for pricing and configuration.