What Is Amazon CloudFront? The Copy of Your Site Everywhere

Amazon CloudFront is AWS's content delivery network — it copies your website's files to hundreds of data centers around the world, so a visitor in Mumbai loads your images from Mumbai instead of from Virginia. But here is the part almost nobody tells you: the first visitor in each region pays the full latency price so everyone after them gets instant delivery. That is the entire business model in one sentence — CloudFront is a global cache that trades one slow request for thousands of fast ones. And the sweetener that changes the math for small sites: the first 1 TB of data transfer out per month is always free — not a trial, not a first-year bonus, free forever, with 10 million free requests included.

That always-free CloudFront tier deserves its moment, because it rewrites the decision for personal sites, small blogs, and side projects. Before it existed, putting a CDN in front of a small site meant watching a meter. Since December 2021, 1 TB of monthly transfer and 10 million requests cost nothing, every month, indefinitely — which covers the traffic of most websites that are not selling something. The result is that CloudFront stopped being a performance luxury and became the default correct architecture for anything publicly served from AWS.

The second thing worth internalizing before the mechanics: CloudFront is not just for static files anymore. The mental model of "CDN equals image caching" is a decade stale. How CloudFront works today includes terminating TLS at the edge, maintaining persistent connections to your origin, collapsing duplicate requests so your servers see fewer fetches, carrying traffic over the AWS private backbone instead of the public internet, running JavaScript at the edge, filtering requests by geography, blocking DDoS traffic before it reaches you, and fronting dynamic APIs as comfortably as it fronts image files. The caching is the famous part. The edge platform is the part that quietly does the rest of the work.

How CloudFront Works: The Copy-Machine Model

Strip away the acronyms and CloudFront is a global system of photocopiers pointed at your website. Here is the vocabulary you need, then the mechanism.

The CloudFront origin is the source of truth — your original content. It can be an S3 bucket, an HTTP server you run (on EC2 or anywhere else — AWS calls these custom origins), an Elastic Load Balancer, an API Gateway, or other AWS services. The origin is where the definitive version of every file lives. You never move your content; CloudFront reads from wherever it already is.

A CloudFront edge location (technically a "point of presence" or PoP) is one of the hundreds of data centers worldwide where CloudFront caches copies of your files. When someone requests your content, the request routes to the edge location that provides the lowest latency — the one that can respond fastest for that particular visitor's location and network conditions. Behind the edge locations sit regional edge caches, a second caching tier that sits between the edge locations and your origin, so even a cache miss at the edge often hits a copy one hop closer than your server.

A CloudFront distribution is the configuration object — the thing you create that tells CloudFront which origin to pull from, which file types to cache, how long to cache them, and which domain name to serve them under. One distribution fronts one application; a complex site might run several.

Now the mechanism, in the order it actually happens:

1. You create a distribution, point it at your origin, and CloudFront assigns it a domain name — something like logeshwaranorg.cloudfront.net.
2. CloudFront pushes the distribution's configuration (not your content) out to all of its edge locations worldwide. Every PoP now knows how to fetch from your origin if asked.
3. A visitor in Singapore requests https://your-site.com/logo.jpg. DNS routes them to the nearest edge location — one in Singapore or nearby.
4. Cache miss (first request): that edge location does not have the file yet, so it fetches it from your origin — across the AWS backbone network, not the public internet — caches a copy locally, and returns it to the visitor. This request is slower than a direct origin hit would have been.
5. Cache hit (everyone after): the next thousand visitors from that region get the file instantly from the Singapore edge location. Your origin never hears about them.
6. The cached copy sits there serving traffic until its TTL (time-to-live) expires, at which point the next request triggers a fresh fetch from the origin.

That is the entire system. Everything else — the edge compute, the security features, the failover, the geo restrictions — is a feature bolted onto this copy-and-serve loop.

The Full Request Flow: What Happens Between a Click and a Response

Most explanations stop at "cache hit or cache miss." The full journey has more stations, and knowing them makes the troubleshooting sections of your future make sense. Here is what actually happens when a visitor requests a file through CloudFront:

1. DNS resolution. The visitor's browser resolves your domain name. If you are using the CloudFront-provided domain (d123.cloudfront.net), DNS returns the IP of an appropriate edge location. If you are using your own domain (www.example.com) with a CNAME pointing at the distribution, the same resolution happens through your registrar.
2. Edge location receives the request. The request lands at a specific PoP — selected for lowest latency for that visitor.
3. TLS termination. If the request is HTTPS, CloudFront terminates the TLS handshake at the edge location, close to the visitor. This eliminates the multiple round trips that establishing TLS over a long distance would otherwise require — a meaningful speed win for dynamic content, not just cached files.
4. Cache check. CloudFront checks whether the requested object (matching the URL, and depending on your cache policy, the headers, cookies, and query strings) is in the edge cache.
5. Cache hit path: the file is served immediately from the edge. This is the fast path — milliseconds, regardless of where your origin lives. You can see it happen: the response carries an X-Cache: Hit from cloudfront header, visible in browser developer tools.
6. Cache miss path: CloudFront checks the regional edge cache for the same region. If it is there, it serves from the regional cache and populates the edge location. If not, it forwards the request to your origin over the AWS backbone, receives the response, caches it at both the edge and (for cacheable content) the regional tier, and serves it to the visitor. The header reads X-Cache: Miss from cloudfront.
7. Request collapsing. If multiple viewers request the same uncached file simultaneously, CloudFront forwards only one request to your origin and serves all the viewers from the single response. Your origin sees one fetch, not a thundering herd.
8. Response to viewer. The file (or the dynamic response) goes back to the visitor from the edge location, with the cache status header indicating how it was served.

Steps 3, 6, and 7 are why CloudFront speeds up dynamic content too — APIs, personalized pages, anything uncacheable. The TLS termination and the backbone routing and the request collapsing all apply whether or not the response is cacheable. Static file delivery is the famous use case; API acceleration is the one people underestimate.

What Is cloudfront.net, and Why Is It in Your Browser? (It Is Not a Virus)

This section exists because an enormous number of people — a number you would not believe from inside the AWS bubble — encounter cloudfront.net in their browser address bar, their firewall logs, their child's Minecraft launcher, or a pop-up ad, and their first thought is virus. The search volume for "what is cloudfront.net virus" and its cousins dwarfs most technical CloudFront queries. So let us settle it plainly.

cloudfront.net is Amazon's domain. Every CloudFront distribution gets an address like logeshwaranorg.cloudfront.net — that string of characters is a legitimate AWS web address, the same way amazon.com is. When you see it in your browser, you are looking at the CDN layer of some website or service you just used. The website's owner put CloudFront in front of their content; your browser connected to the edge location; the address bar shows the CloudFront domain because that is where the connection landed.

CloudFront is not on your computer. It is server-side infrastructure — data centers operated by AWS. There is nothing to "remove" from your machine because nothing was installed on your machine. If a security scan flags cloudfront.net, it is flagging a network destination your traffic passed through, not a program that lives on your disk. You cannot disable CloudFront on your end any more than you can disable a website's hosting provider — it belongs to the site you are visiting, not to you.

Why it appears in Minecraft, games, and app launchers: game developers use CDNs to distribute patches, updates, and assets. When a launcher downloads an update, the connection goes to a CDN — often CloudFront — and the domain appears in connection logs or download managers. This is the update being delivered efficiently, not malware being installed.

When cloudfront.net IS a problem: the domain itself is neutral infrastructure, but bad actors can (and occasionally do) use CloudFront to host malicious content, just as they can use any hosting service. A CloudFront URL serving a phishing page or a malicious download is a CloudFront abuse problem, not a your-computer problem. The domain in your address bar is not evidence of infection; the content being served through it determines whether the specific page is trustworthy.

For the full breakdown — including how to tell a legitimate cloudfront.net address from a suspicious one, and what to do when a security tool flags it — our dedicated guide covers whether cloudfront.net is safe or a virus in detail.

CloudFront Origins: Where Your Content Comes From

An origin server stores the original, definitive version of your objects. CloudFront supports several kinds, and picking the right one (and configuring access to it correctly) is where most CloudFront setups succeed or stumble.

Amazon S3 as an origin

The classic pairing, and the answer to "do I need CloudFront with S3": files live in an S3 bucket, CloudFront caches them worldwide. When you use S3 as an origin, you can make objects publicly readable (anyone with the CloudFront URL can access them) or keep them private and control access.

Origin Access Control (OAC) is the modern mechanism for private S3 origins, and it is what AWS recommends. An OAC is a CloudFront-managed identity that you authorize in the bucket's policy, so the bucket can deny all public access while still serving CloudFront's fetches. OAC supports all S3 buckets in all regions, server-side encryption with KMS, and dynamic requests (PUT and DELETE) to S3. Its predecessor, the origin access identity (OAI), still works but does not support those newer scenarios — if you are setting up a new distribution, use OAC.

When the OAC configuration is incomplete — the bucket policy does not authorize the OAC, or the OAC is not attached to the distribution's origin — the result is the infamous CloudFront 403 error from an S3 origin. Our step-by-step guide on fixing CloudFront 403 from S3 with OAC walks through the full checklist.

Custom origins (any HTTP server)

A custom origin is any HTTP server you point CloudFront at — an EC2 instance running nginx, an application load balancer fronting a fleet of servers, an API Gateway, or even a server outside AWS entirely. CloudFront treats it as an HTTP endpoint and fetches from it on cache misses.

For custom origins, the guidance is straightforward: use an Elastic Load Balancer rather than a single EC2 instance, so your origin survives instance failure and scales across availability zones. You can also configure custom headers that CloudFront sends with every origin request — useful for authenticating that traffic came through CloudFront and not directly at your server.

Other AWS origins

Beyond S3 and custom HTTP origins, CloudFront integrates with AWS services that serve as origins in their own right — API Gateway for REST APIs, AWS Elemental MediaPackage for video streams, Application Load Balancers, Lambda function URLs. The pricing page notes that data transfer from your origin to CloudFront is free when using AWS origins like S3, Elastic Load Balancing, or API Gateway — meaning the origin-to-edge fetches cost nothing, and you only pay for the edge-to-viewer delivery.

CloudFront Distributions, Domain Names, and Using Your Own Domain

When you create a distribution, CloudFront assigns it a domain name — the logeshwaranorg.cloudfront.net style address — visible in the console or in the API response. Every file in that distribution is reachable at that domain: https://logeshwaranorg.cloudfront.net/logo.jpg serves the logo.jpg from your origin, through the global cache.

Most real sites do not want cloudfront.net in their URLs. The fix is an alternate domain name (a CNAME): you add www.example.com to the distribution, then point your DNS at the CloudFront domain. The requirements: the domain must be registered (Route 53 or any registrar), and you need a TLS certificate covering that domain attached to the distribution to validate you are authorized to use it.

This is where CloudFront and Route 53 meet — a pairing so common that people search for them together. Route 53 is AWS's DNS service: it translates your domain name into the IP address browsers should connect to. CloudFront is the delivery layer: it caches and serves the content. They are different services solving different problems, and the standard architecture uses both — Route 53 routes your domain's traffic to the CloudFront distribution, CloudFront serves the content from the edge. With ACM (AWS Certificate Manager), the TLS certificate is free and auto-renews. The full setup — ACM certificate in us-east-1, the CNAME, the Route 53 alias record — is walked through step by step in our guide on custom domains with HTTPS on CloudFront and Route 53.

By default, every CloudFront distribution serves HTTPS using the default CloudFront certificate that covers *.cloudfront.net. That is enough to get started — your site is encrypted end to end from day one, at the cloudfront.net domain. The ACM certificate is only needed when you add your own domain name.

Standard vs. multi-tenant distributions

CloudFront now offers two distribution shapes. Standard distributions — what most people mean by "a CloudFront distribution" — are designed for one website or application each, with full per-distribution configuration. Multi-tenant distributions (managed through CloudFront SaaS Manager) are designed for SaaS providers serving many customer sites from shared infrastructure: centralized control over common configuration, with per-tenant customization where needed. If you are building a platform that hosts hundreds of customer domains, the multi-tenant shape exists precisely for you. Everyone else starts with standard.

CloudFront Cache Expiration: How Long Copies Live, and How to Kill Them Early

Every cached copy has a lifetime — a TTL, set by your origin's headers or by the distribution's cache policy. The defaults: each file stays in an edge location for 24 hours before it expires by default, with a minimum TTL of 0 seconds and no maximum. The interplay between Minimum TTL, Default TTL, Maximum TTL, and the Cache-Control headers your origin sends is where most caching confusion lives.

Your origin can attach headers to files — Cache-Control: max-age=3600, for instance — telling CloudFront how long to keep them. Your cache policy sets the guardrails: a Minimum TTL (files are cached at least this long even if the origin says shorter), a Maximum TTL (files are cached at most this long even if the origin says longer), and a Default TTL (applied when the origin sends no header). The effective cache time for any object falls within the min/max window, guided by what the origin said.

The "CloudFront is not updating my site" problem

This is the single most common CloudFront support question — someone uploads new files, and the site still shows the old version. The cause is specific: the edge locations are still serving cached copies of the old files until the TTL expires. You uploaded the new logo; the edge locations do not know that; they serve what they cached.

Two solutions, in order of preference:

1. Version your files. Name files with a fingerprint (logo-v2.jpg, or logo.jpg?hash=abc123) and update the HTML to reference the new names. The new URLs are cache misses, fetch fresh from the origin, and the old cached copies simply expire on their own. This is the zero-cost, zero-API-call approach and why every serious deployment pipeline does it.
2. CloudFront invalidation. Tell CloudFront to evict specific paths from its caches immediately: aws cloudfront create-invalidation --distribution-id EDFDVBD6EXAMPLE --paths "/images/logo.jpg". The next request for that path fetches fresh from the origin. The first 1,000 invalidation paths per month are free; beyond that they are billed. Invalidation works but it is the slower, costlier tool — the hammer when versioning is the screwdriver.

One subtlety worth knowing: when you invalidate a file, CloudFront invalidates every cached version of it regardless of the cookies or headers associated with each cached variant. There is no selective invalidation — if your distribution caches multiple header-based variants of a path, invalidating the path flushes all of them. And when invalidation does not seem to be working — the file still serves stale after the invalidation completes — the usual culprit is a second caching layer (the browser's own cache, or a service worker) serving the old copy locally, beyond CloudFront's reach. Our dedicated guide on CloudFront not updating cache covers the full diagnostic for both the CDN-side and browser-side versions of this problem.

Edge Compute: CloudFront Functions and Lambda@Edge

CloudFront is not just a dumb cache. Two separate compute services run at the edge locations themselves, intercepting requests and responses as they flow through:

CloudFront Functions

CloudFront Functions is the lightweight option — JavaScript functions that run with submillisecond startup times, scaling immediately to handle millions of requests per second, executed natively within CloudFront. When you associate a function with a distribution, CloudFront intercepts requests and responses at the edge locations and passes them through your code.

The use cases are the small-but-constant transformations: rewriting request URIs, redirecting URLs, normalizing query strings, adding security headers, basic authentication at the edge, generating simple HTTP responses without touching the origin. Because they run at every PoP with no cold starts, they handle the highest-traffic customizations with effectively zero latency cost.

Lambda@Edge

Lambda@Edge is the heavyweight option — full Lambda functions that run in a regional edge cache location (not at every PoP, but at the regional tier), triggered by viewer requests, origin requests, and origin responses. Lambda@Edge can read and modify headers, cookies, the request body (in some trigger types), and generate full responses — the power of a Lambda function applied to the CDN request path.

The division of labor: CloudFront Functions for lightweight, per-request customizations that must run everywhere with zero latency cost; Lambda@Edge for heavier logic that justifies running at the regional tier — dynamic routing, complex header manipulation, authentication requiring external calls.

Security: HTTPS, Private Content, Geo Blocking, and DDoS Absorption

CloudFront's position — in front of everything, distributed across the globe — makes it a natural security layer, and AWS has built accordingly.

HTTPS and TLS everywhere

Every distribution serves HTTPS by default with the *.cloudfront.net certificate. Add your own domain with an ACM certificate and your site serves your domain over HTTPS with a certificate AWS manages and renews automatically. CloudFront also lets you enforce HTTPS-only — redirecting all HTTP requests to HTTPS — with a single setting.

Private content: signed URLs and signed cookies

By default, CloudFront content is public — anyone with the URL gets the file. For content you want to restrict (paid downloads, subscriber media, internal documents), CloudFront provides signed URLs and signed cookies, which embed a cryptographic signature proving the request is authorized.

The choice between them has a documented logic:

• Use CloudFront signed URLs when you want to restrict access to individual files — an installation download, a single report — or when your users' clients do not support cookies.
• Use CloudFront signed cookies when you want to provide access to multiple restricted files — all the segments of a video, all the files in a subscribers' area — without signing each URL individually.

The additional layer: require that users access content through CloudFront URLs, not URLs that hit the origin directly. With OAC on an S3 origin, the bucket denies all direct access, so the signed URL through CloudFront is the only path — closing the bypass hole.

CloudFront geo restriction

CloudFront can block or allow access by country at the distribution level — a setting AWS calls geographic restrictions (or geo blocking). A distribution can be configured with a block list (deny specific countries) or an allow list (permit only specific countries). The restriction applies to all files served by that distribution. For finer granularity — restricting some paths but not others, or blocking at a level more specific than country — the documented route is a third-party geolocation service, typically implemented as a Lambda@Edge function or a WAF rule.

DDoS absorption and AWS WAF

Because CloudFront is the entry point — traffic hits the edge locations before it ever reaches your infrastructure — it is the ideal place to absorb attacks. AWS's own framing: the edge network spreads traffic across hundreds of locations, so a volumetric attack distributed against your site is distributed against CloudFront's entire capacity, which is designed to withstand large bursts that would flatten a single-origin application. Add AWS WAF (Web Application Firewall) and you get request filtering — blocking SQL injection patterns, known bot signatures, rate-limiting abusive clients — with the blocked traffic never reaching your servers. The flat-rate plans bundle WAF and DDoS protection into the monthly price; on pay-as-you-go, they are separate services billed by their own metrics.

Origin Failover and Origin Shield

CloudFront can automatically switch to a backup origin when the primary fails. The mechanism is an origin group: you create a group containing two origins — a primary and a secondary — and configure which HTTP error codes trigger failover. When the primary origin is unreachable or returns one of the configured failure codes, CloudFront retries the request against the secondary, serving the visitor from the backup without them knowing anything happened.

The classic setup: primary origin is your production S3 bucket or load balancer; secondary is a static backup — an S3 bucket containing a "we'll be back shortly" page, or a standby deployment in another region. When the primary goes down, visitors get the fallback content instead of a 502 error. When the primary recovers, CloudFront switches back automatically.

A complementary feature is Origin Shield: an additional caching layer that sits in front of your origin, behind all the regional edge caches. Every cache miss from every region funnels through Origin Shield first, which means your origin sees dramatically fewer fetches — Origin Shield can serve a miss to one region while caching the response for the others. For origins that are expensive to hit ( APIs with rate limits, databases behind a thin API layer), Origin Shield is the pressure valve that keeps the origin breathing.

CloudFront Price Classes: Paying for Only the Edge Locations You Need

Not all edge locations cost the same to serve from — data transfer rates vary by geography, and some regions are substantially more expensive than others. CloudFront's answer is the price class setting, which controls how many edge locations your distribution uses:

• PriceClass_100 — only the least-expensive edge locations (North America and Europe)
• PriceClass_200 — those plus the next tier of regions
• PriceClass_All — every edge location, everywhere, at whatever each region costs

The trade is direct: restricting the price class saves money but means visitors outside the covered regions get served from farther away — worse latency for them, lower cost for you. If your audience is entirely in North America and Europe, PriceClass_100 delivers the same performance as All for less. If you have customers in South America or India, restricting the class means those customers cross oceans to reach your content — the exact problem CloudFront exists to solve. The right setting is audience-dependent, not a universal default.

CloudFront Pricing and the Free Tier

CloudFront pricing comes in two shapes, and the always-free tier sits underneath both of them. For the complete rate tables, regional breakdowns, and worked cost examples, our companion piece on CloudFront pricing and free cost covers the numbers in detail; here is the shape of the thing.

The always-free tier (the part that changes the math)

Since December 2021: data transfer from CloudFront is free for up to 1 TB per month, with 10 million free HTTP/HTTPS requests, indefinitely — not a 12-month trial, not a signup bonus, but a permanent free tier. The 2 million free CloudFront Functions invocations per month also lost their 12-month limit. The only exclusion is traffic from CloudFront PoPs in China.

For context on what 1 TB covers: at an average page weight of 2 MB (generous for a well-built site), 1 TB is roughly 500,000 page views per month. Most personal sites, portfolios, and small blogs will never exceed the free tier. This is why the default advice for any AWS-hosted static site is now "put CloudFront in front of it" — the cost is zero and the performance gain is global.

Pay-as-you-go pricing

Beyond the free tier, you pay for data transfer out from edge locations plus HTTP/HTTPS requests, with rates varying by usage volume, geographic region (which edge locations served the traffic), and which features you use. One structural fact worth knowing: data transfer from your AWS origin to CloudFront is always free when using AWS origins like S3, Elastic Load Balancing, or API Gateway — the origin-to-edge fetches cost nothing, and you pay only for the edge-to-viewer delivery. Because cached content served from edge locations means fewer requests hitting your origin, and duplicate requests are collapsed, CloudFront typically reduces your overall AWS costs by shielding the origin services that bill by usage.

Flat-rate plans (the newer option)

CloudFront now offers flat-rate pricing plans that bundle multiple AWS services into a fixed monthly price with no overage charges — even during traffic spikes or attacks. What the plans include:

• CloudFront CDN
• AWS WAF and DDoS protection
• Amazon Route 53 DNS
• Amazon CloudWatch Logs ingestion
• TLS certificate
• Serverless edge compute
• Monthly S3 storage credits

The pitch for flat-rate is predictability: one price, no overage charges, bundled security, and attacks blocked by WAF never count against your allowance. The counterargument is flexibility — pay-as-you-go gives complete control over individual service configuration and access to features not available in flat-rate plans. For traffic that is steady and predictable, pay-as-you-go arithmetic may come out ahead; for traffic that spikes unpredictably (product launches, viral content, DDoS-adjacent events), the flat-rate ceiling is insurance.

CloudFront vs. Cloudflare (and the Other Comparisons People Search)

"What is CloudFront vs Cloudflare" is one of the most searched CloudFront questions, and the honest answer is less dramatic than the framing suggests: both are CDNs, both are excellent, and the right choice depends on where your infrastructure lives and what you need from the layer above the CDN.

CloudFront is AWS's CDN. Its advantages: deep AWS integration (S3 origins with OAC, ALB origins, IAM authentication, CloudWatch monitoring, ACM certificates, Route 53 DNS — everything speaks the same language), the AWS private backbone for origin fetches, edge compute in CloudFront Functions and Lambda@Edge, and the always-free tier. Its disadvantage: if your infrastructure is not on AWS, the integration advantages evaporate and you are left with a CDN that assumes AWS underneath.

Cloudflare is an independent CDN that sits at the DNS level — you point your domain's nameservers at Cloudflare and it fronts everything, caching, filtering, and routing. Its advantages: works equally well regardless of where your origin lives (AWS, GCP, Azure, a closet in your office), a famously generous free tier, and a broad feature set (DNS, DDoS protection, Workers at the edge, registrar services) bundled at the same layer. Its disadvantage for AWS-heavy shops: less native integration with AWS-specific services and origins.

The decision rule that holds up: if your origin is on AWS, CloudFront is the natural fit — the integration, the backbone routing, and the free tier compound. If your origin is elsewhere or multi-cloud, Cloudflare's neutrality wins. Plenty of organizations use both — Cloudflare for DNS and edge filtering, CloudFront for AWS-originated content delivery.

The other "difference between" questions, answered in one paragraph each

CloudFront vs. Route 53: Route 53 is DNS — it translates domain names to IP addresses. CloudFront is delivery — it caches and serves content. They solve different problems and work together: Route 53 routes your domain's traffic to the CloudFront distribution. Not competitors; collaborators.

CloudFront vs. Global Accelerator: Global Accelerator routes TCP and UDP traffic to the optimal AWS endpoint — it improves the network path, but does not cache anything. CloudFront caches HTTP content at edge locations. Use CloudFront for web content; use Global Accelerator for non-HTTP protocols (game servers, IoT) or when you need static IPs.

CloudFront vs. CloudWatch: CloudWatch is AWS's monitoring service — metrics, logs, alarms. CloudFront is content delivery. One watches, one delivers. The confusion is purely the shared "Cloud" prefix.

Azure equivalent of CloudFront: Azure Front Door. GCP equivalent: Cloud CDN. Every major cloud has one; the mechanics are broadly similar, the integration story differs.

CloudFront Errors: The 403, the 502, the 504, and What They Mean

When CloudFront fails, it fails with specific errors that point at specific causes. Here are the ones you will actually meet, admin-side and user-side.

The CloudFront 403 error — "The request could not be satisfied"

This is the error most people encounter, and it has two distinct audiences. If you are the visitor seeing "403 Forbidden — The request could not be satisfied" on a website you are trying to use: the site's CloudFront configuration is refusing your request, and there is nothing wrong with your computer. The site's owner has either blocked your region, the content requires authentication you do not have, or the site's configuration is broken. You cannot fix it from your side — this is why "why is CloudFront blocking me" is such a common search, and why the answer is almost always "the site you are visiting decided to block requests like yours, or misconfigured something."

If you are the site operator whose visitors are getting 403s: the cause is one of three things — the S3 origin's OAC is misconfigured (the most common, and covered in our CloudFront 403 from S3 origin fix guide), a WAF rule is blocking legitimate traffic, or the geo restriction is blocking a region you did not intend. The full diagnostic for the user-facing "request could not be satisfied" error is in our guide on fixing the CloudFront 403 request-could-not-be-satisfied error.

The CloudFront 502 and 504 errors — origin problems

A 502 Bad Gateway means CloudFront could not connect to your origin — the server is down, unreachable, or rejecting the connection. A 504 Gateway Timeout means the origin accepted the connection but did not respond in time — the server is too slow, overloaded, or hanging on the request. Both are origin-side problems, not CDN-side problems, which is why they are covered together in our guide on CloudFront 502 and 504 errors.

The quick diagnostic for both: is the origin responding to direct requests (bypassing CloudFront)? If the origin is down, no CDN configuration will save you — that is what origin failover exists for. If the origin responds directly but not through CloudFront, the problem is in the connection path: security groups blocking CloudFront's IP ranges, the wrong port, or a header mismatch the origin rejects.

"CloudFront is not updating my site" — the stale cache problem

Covered in depth in the cache expiration section above, and in our dedicated guide on CloudFront not updating cache. The short version: the TTL has not expired, and the fix is versioning (long term) or invalidation (short term).

When CloudFront Is the Wrong Choice (The Honest Section)

CloudFront is genuinely the right default for most public-facing AWS-hosted content. But there are situations where it adds complexity without adding value, and pretending they do not exist serves nobody.

Your entire audience is local to your origin

If every visitor is in the same city as your server, the edge locations add nothing — the request to the edge and the edge's fetch from the origin cannot beat a direct local request. CloudFront helps when distance is the problem; no distance, no problem to solve.

Everything on your site is dynamically generated and uncacheable

CloudFront still helps here (TLS termination, backbone routing, request collapsing), but the benefit shrinks and the operational surface grows. If your origin must generate every response uniquely — heavy personalization, per-user rendering — and your audience is domestic, the edge layer may be complexity without payoff. The more cacheable your content, the more CloudFront earns its place.

You need deep per-request logic CloudFront cannot express

Edge compute is real but bounded — CloudFront Functions are deliberately limited, Lambda@Edge runs at the regional tier with its own constraints. If your application's logic is so request-dependent that the CDN layer would need to make decisions on every request that only your application understands, the edge adds a second place for that logic to live and drift out of sync. Some applications belong behind a plain load balancer, full stop.

Compliance requires knowing exactly where data transits

A global CDN routes requests through whatever edge location serves each visitor best — which means content and request metadata touch infrastructure in multiple jurisdictions. For data with strict residency requirements (some healthcare, some government, some financial), the global-anywhere model needs careful legal review before deployment.

IT Admin: CloudFront at Fleet Scale

For platform teams operating many distributions, the concerns scale differently:

1. Manage distributions as infrastructure, not console artifacts. CloudFormation or Terraform for every distribution means changes go through code review, and configuration drift becomes visible in a plan instead of invisible in a console. The continuous deployment feature for distributions (staging distributions) lets you test configuration changes safely before promoting them to production.
2. Standardize cache policies across the org. A handful of well-designed cache policies (one for static assets, one for HTML, one for APIs) shared across distributions beats every team inventing their own — and makes the fragmentation debugging tractable when something is slow.
3. Front everything public with CloudFront, and lock the origins down. The security argument: CloudFront plus WAF plus DDoS absorption in front, OAC or custom headers so origins reject non-CloudFront traffic, and your origin servers see only legitimate, filtered requests. This is the shape of AWS's own guidance for public applications.
4. Monitor cache hit ratio and origin load together. A falling hit ratio with rising origin traffic is the early warning that a cache policy change fragmented the cache — catching it in monitoring beats discovering it in an origin outage.
5. For SaaS, evaluate multi-tenant distributions. If you are serving hundreds of customer domains from shared infrastructure, CloudFront SaaS Manager exists to prevent you managing hundreds of individual distributions by hand.

Frequently Asked Questions

What is Amazon CloudFront used for?

CloudFront is used to deliver web content — static files, dynamic APIs, video streams — to users worldwide through a global network of edge locations. It caches content close to each visitor, reducing latency, offloading origin servers, absorbing traffic spikes, and providing security features like DDoS protection and HTTPS.

Is CloudFront free?

The first 1 TB of data transfer per month and 10 million HTTP/HTTPS requests are always free — indefinitely, not a trial. Beyond that, pay-as-you-go rates or flat-rate plans starting at $0/month. Data transfer from AWS origins to CloudFront is always free.

How much does CloudFront cost after the free tier?

Pay-as-you-go charges per GB of data transfer out from edge locations plus per-request charges, varying by region and volume. Flat-rate plans bundle CDN, WAF, DNS, and more into fixed monthly prices from $15 to $1,000+. Exact rates are on the CloudFront pricing page — see our companion pricing guide for the breakdown.

What is a CloudFront distribution?

A distribution is the CloudFront configuration object — it tells CloudFront which origin to fetch from, how to cache, which domain to serve under, and which features to enable. Each distribution gets a *.cloudfront.net domain; you can attach your own domain with an ACM certificate.

What is a CloudFront origin?

An origin is where CloudFront fetches your content on cache misses — an S3 bucket, an HTTP server (custom origin), a load balancer, or other AWS services. Multiple origins with automatic failover are supported through origin groups.

What is cloudfront.net?

cloudfront.net is Amazon's domain for CloudFront distributions. Every distribution gets an address like d123abc.cloudfront.net. It is not a virus — it is server-side AWS infrastructure. When you see it in your browser, a website you used is running on AWS. It is not installed on your computer and there is nothing to remove.

Why is CloudFront blocking me?

If you see "403 Forbidden — The request could not be satisfied" on a website: the site's CloudFront configuration is refusing your request. Common causes are geo restrictions blocking your country, content requiring authentication, or a site configuration error. The problem is on the website's side — nothing is wrong with your computer.

How do I remove CloudFront?

You do not need to — and cannot — because CloudFront is not on your computer. It is server-side infrastructure operated by AWS. Seeing cloudfront.net in your browser or firewall logs means a website or app you used is running on AWS. If you are a site operator wanting to remove CloudFront from your own site, delete the distribution and point DNS back at your origin.

Do I need CloudFront with S3?

Not required, but strongly recommended. S3 serves files from one region; CloudFront caches them worldwide. Benefits: faster global delivery, HTTPS on your custom domain (which S3 website endpoints alone do not provide), DDoS protection, and origin protection through OAC. The first 1 TB per month is free, so the cost argument is zero for most sites.

What does "Hit from cloudfront" mean?

It is the X-Cache response header telling you the file was served from a CloudFront edge cache — the fast path. "Miss from cloudfront" means the edge location did not have the file and fetched it from the origin. "RefreshHit from cloudfront" means the cached copy had expired and CloudFront revalidated it with the origin before serving.

How long does CloudFront cache content?

By default, files stay in an edge location for 24 hours. Cache-Control headers from your origin can specify different durations, bounded by the cache policy's Minimum TTL (default 0 seconds) and Maximum TTL (default one year). After expiration, the next request fetches a fresh copy.

How do I clear the CloudFront cache?

Create an invalidation for specific paths: aws cloudfront create-invalidation --distribution-id YOUR_ID --paths "/path/to/file". The first 1,000 paths per month are free. The better long-term approach is versioning filenames so new deploys are cache misses.

What is the difference between CloudFront Functions and Lambda@Edge?

CloudFront Functions are lightweight JavaScript at every edge location with submillisecond startup — for URL rewrites and header manipulation. Lambda@Edge runs full Lambda functions at regional edge caches — more powerful, for heavier logic.

What is the difference between CloudFront and Cloudflare?

Both are CDNs. CloudFront is AWS-native with deep AWS integration (S3 origins, IAM, ACM certificates) and the AWS backbone. Cloudflare is independent, works with any origin, and sits at the DNS level with a broad bundled feature set. If your infrastructure is on AWS, CloudFront is the natural fit; if it is elsewhere or multi-cloud, Cloudflare's neutrality wins.

Does CloudFront protect against DDoS attacks?

Yes. Attack traffic hits the distributed edge network before reaching your infrastructure. AWS WAF adds request filtering and rate limiting. Blocked traffic never reaches your origin, and on flat-rate plans does not count against usage allowance.

Can CloudFront serve dynamic content and APIs?

Yes. CloudFront accelerates dynamic content through TLS termination close to viewers, persistent origin connections, request collapsing, and routing over the AWS private backbone. These apply whether or not responses are cacheable — which is why API acceleration is a major CloudFront use case.

Wrapping Up: The Photocopier That Pays for Itself

CloudFront is the copy of your site everywhere — a global system that trades one slow request per region for instant delivery to everyone who follows, backed by a private fiber backbone, fronted by security that absorbs attacks before they reach you, and priced so the first terabyte costs nothing.

The two takeaways if you take away nothing else: first, the always-free tier means putting CloudFront in front of any AWS-hosted public content is the default correct move, not an optimization to consider — there is no cost argument left. Second, caching is a design decision, not a setting — version your filenames, keep HTML TTLs short and asset TTLs long, and the cache works for you instead of against your deploys.

Jake put CloudFront in front of the repair-shop site that afternoon, pointed it at the S3 bucket the site already lived in, and attached the shop's domain with an ACM certificate. Ethan's verdict: "The photocopier is running, the closet is stocked, and the first customer from another continent already paid the latency price for everyone who comes after them. That is the entire miracle — and it costs you nothing until half a million people care."

Revision note. Written September 2026.. Pricing figures reflect the current pricing page and will change as AWS adjusts rates. If your site is still serving straight from a single origin and you just learned the first terabyte of global acceleration is free, that realization is worth more than the hour it took to read this — and acting on it puts you ahead of every site still crossing oceans one request at a time.