Amazon CloudFront

What CloudFront is

CloudFront is a content delivery network — it caches your content at edge locations worldwide, so a visitor in Singapore fetches it from a nearby location instead of round-tripping to your origin in Virginia every time. For a static site, it’s the piece that turns “an S3 bucket serving files” into “a production website”: it adds HTTPS, caching, and a real custom domain on top.

Design Beaver models CloudFront as a global edge network with no VPC or subnet — nesting it inside a subnet is misleading, so it doesn’t let you. It validates as you draw which services can be a CloudFront origin and how each of those edges has to be set up to be correct.

When to use CloudFront (and when not to)

Reach for CloudFront on any publicly accessible production site or API that benefits from caching, HTTPS, and global low latency. The most common case: you need HTTPS on an S3-backed static site, and S3 website endpoints don’t support it directly — CloudFront is the fix, not a bucket setting. It’s also the standard way to add a custom domain with TLS in front of an ALB, EC2, or API Gateway origin.

Don’t reach for it on purely internal or private tools with no public traffic and no need for edge caching. It’s also the wrong layer for content that changes on every request with nothing cacheable and no specific need for the HTTPS or edge piece — a plain ALB may be simpler there.

Variants: price classes

CloudFront’s “variants” are price classes — the dial between how many edge locations serve your traffic and how much you pay. The default is every global edge location; the narrower classes trade some geographic reach for lower cost.

CloudFront pricing

You pay for data transfer out to viewers plus HTTP(S) requests. The important nuance: data from an AWS origin — S3, EC2, ALB, API Gateway — into CloudFront is free, so you’re only billed for the edge-to-viewer leg.

How CloudFront connects to other services

A CDN box on a canvas hides the real work — which service is the origin, and what that origin edge actually requires to function. Design Beaver models each CloudFront connection, so it knows what can be an origin and what that connection needs to be correct.

• →S3

  CloudFront uses an S3 bucket as its origin (standard static-site setup)

• →Lambda

  CloudFront Functions or Lambda@Edge for request/response manipulation at the edge (e.g. redirects, header rewriting, auth checks)

• →EC2

  CloudFront uses an EC2 instance (directly, or via an ALB) as a custom HTTP(S) origin — e.g. a dynamic app server or API in front of which CloudFront adds caching, HTTPS, and a CDN layer

• →Application Load Balancer

  CloudFront uses the ALB as a custom HTTP(S) origin, adding edge caching, HTTPS, and a CDN layer in front of the app server tier the ALB fronts

• →API Gateway

  CloudFront uses a Regional API Gateway endpoint as a custom origin, adding edge caching, a custom domain, and WAF in front of the API

What CloudFront can’t connect to

Some edges look reasonable on a canvas but don’t exist in AWS. Design Beaver flags them instead of letting you draw a diagram that can’t be built.

• ✕RDS

  CloudFront is an HTTP(S) edge cache/CDN in front of an origin — it has no direct database client relationship; RDS is never a CloudFront origin

• ✕DynamoDB

  Same as RDS — not a valid CloudFront origin type

• ✕Route 53

  DNS resolution happens before traffic ever reaches CloudFront, not as a connection from it — Route 53 points at a CloudFront distribution, never the other way around

Anti-patterns Design Beaver catches

These are the CloudFront mistakes that pass a diagram review but undercut the reason you added CloudFront in the first place — the ones the validation engine flags as you draw.

Gotchas that bite in production

• A public S3 bucket policy defeats the point of CloudFront. If the S3 origin uses a public bucket policy instead of OAC, you’ve paid for CloudFront but left the direct S3 door open — visitors and bots can bypass the CDN entirely. Use Origin Access Control and keep Block Public Access on.
• Price Class All is the tutorial default, not always the right one. Most tutorials show the widest price class, but if your users are all in one region, you’re paying for edge locations nobody uses. Match the class to where traffic actually originates.
• Data into CloudFront from an AWS origin is free. You only pay the edge-to-viewer leg, not the S3, EC2, ALB, or API Gateway origin fetch — worth knowing before you model transfer costs.
• Lambda@Edge is not standard Lambda. Functions attached to CloudFront events have no VPC support and tighter execution limits that depend on which viewer-request or response event they run at. Don’t carry standard-Lambda assumptions into an edge function.
• Front a Regional API Gateway endpoint, not an edge-optimized one. An edge-optimized API Gateway endpoint already sits behind an AWS-managed CloudFront distribution, so putting your own in front is redundant — use a Regional endpoint as the origin instead.

Further reading

• Official AWS documentation
• Why we built a validation engine