Static Site With CloudFront And S3

Concepts Covered

• Static website delivery
• S3 bucket as origin
• CloudFront distribution
• Origin access control
• S3 Block Public Access
• Route 53 alias records
• ACM TLS certificates
• Cache behavior
• Invalidations
• Exam traps around public buckets

1. Situation

You need to host a static website: HTML, CSS, JavaScript, images, fonts, and other assets.

The site should be publicly reachable over HTTPS, load quickly for global users, avoid running servers, and keep the storage origin from being directly exposed. The team also wants low operational overhead.

This scenario appears in SAA-C03 as "static website", "global low latency", "content delivery", "S3 origin", "CloudFront", "custom domain", "TLS", and "prevent direct access to the bucket."

The best architecture is usually S3 for durable object storage plus CloudFront for public delivery and caching.

2. Naive Design

The naive design enables S3 static website hosting and makes the bucket public:

users -> public S3 website endpoint

This is simple and can serve a static website, but it exposes the bucket directly and does not provide CloudFront edge caching, custom HTTPS behavior in the same way, origin protection, or the same performance posture.

Another naive design runs a static site on EC2:

users -> EC2 web server -> static files

That adds patching, scaling, availability, and server management for content that does not need a server.

A third naive design puts CloudFront in front of S3 but leaves the bucket public. That improves caching but misses the origin access boundary.

3. What Breaks

Public buckets are easy to misconfigure. If the bucket contains only public website assets, direct public access may be acceptable in some designs. But many exam questions explicitly ask to prevent direct S3 access and allow access only through CloudFront.

EC2 hosting creates unnecessary operations. A static site does not need an app server, Auto Scaling group, OS patching, or load balancer unless there is server-side behavior.

Without CloudFront, global users may have higher latency. S3 is regional. CloudFront caches content at edge locations and can reduce load on the origin.

Without TLS and DNS planning, custom domain delivery becomes incomplete.

Without cache invalidation or content versioning, users can receive stale assets after deployment.

4. AWS Architecture

Store static files in an S3 bucket.

Create a CloudFront distribution with the S3 bucket as the origin. Use origin access control so CloudFront can read from the S3 origin while the bucket remains private. Keep S3 Block Public Access enabled when the design requires private origin access.

Use AWS Certificate Manager for a TLS certificate. For CloudFront custom domains, the certificate must be in the Region required by CloudFront certificate integration, commonly us-east-1.

Use Route 53 alias records to map the custom domain to the CloudFront distribution.

The final shape is:

users
  -> Route 53
  -> CloudFront distribution
  -> private S3 bucket origin through OAC

Deploy files to S3. Use object versioning or CloudFront invalidations to control cache updates.

5. Request Or Data Flow

A user requests https://example.com/app.js.

Route 53 resolves the domain to the CloudFront distribution. The user connects to a nearby CloudFront edge location over HTTPS.

If the object is cached and fresh, CloudFront returns it from the edge cache.

If the object is missing or stale, CloudFront requests it from the S3 origin. The origin access control signs or authorizes the origin request according to the CloudFront and S3 configuration. The S3 bucket policy allows CloudFront to read expected objects.

CloudFront caches the response according to cache headers, cache policy, and behavior settings.

For deployments, the pipeline uploads changed files to S3. It can either use content-hashed filenames, such as app.abcd1234.js, or issue CloudFront invalidations for changed paths.

6. Security Controls

Keep the S3 origin private when the requirement says users must access content only through CloudFront.

Use origin access control rather than public bucket access. Configure the S3 bucket policy to allow the CloudFront distribution to read objects.

Use HTTPS with CloudFront and ACM. Redirect HTTP to HTTPS if the site should be secure by default.

Enable S3 Block Public Access unless public bucket access is explicitly intended.

Use least privilege for deployment roles. A CI/CD role may need s3:PutObject, s3:DeleteObject, and cloudfront:CreateInvalidation, but it should not be an account administrator.

Use CloudTrail and S3 access logs or CloudFront logs when audit and observability requirements exist.

7. Resilience Controls

S3 provides durable regional object storage. CloudFront provides a globally distributed delivery layer.

If the origin is temporarily unavailable, cached objects can continue to be served until cache behavior and error handling settings decide otherwise.

Use versioned assets to reduce deployment risk. If each asset filename contains a content hash, new deployments do not need to overwrite old objects immediately.

Consider S3 versioning when accidental object overwrite or deletion matters. Consider cross-Region replication only when the recovery requirement justifies it.

CloudFront is managed, but DNS, certificate expiration, bucket policy, and deployment invalidations still need operational care.

8. Performance Controls

CloudFront improves global latency by caching content at edge locations.

Set appropriate cache headers. Long cache lifetimes work well for versioned assets. Shorter lifetimes or invalidations may be needed for HTML entry files.

Compress text assets such as HTML, CSS, and JavaScript where appropriate.

Use modern image formats and right-sized assets. CloudFront can help delivery, but it cannot make oversized assets efficient by itself.

Avoid forwarding unnecessary headers, cookies, or query strings because they can reduce cache hit ratio.

9. Cost Controls

S3 cost includes storage, requests, and data transfer. CloudFront cost includes requests and data transfer from edge locations.

CloudFront can reduce origin request volume and improve performance, but it is not automatically cheaper in every traffic shape.

Use lifecycle policies for old build artifacts if the bucket stores many historical versions.

Use cache-control headers to avoid excessive origin reads.

Be careful with invalidations. A small number of paths may be free or low cost, but large frequent invalidations can become wasteful. Content-hashed asset names often reduce invalidation needs.

10. Exam Variants

"Static website with global low latency" points to CloudFront with S3 origin.

"Prevent direct access to the S3 bucket" points to CloudFront origin access control and a private bucket.

"Custom domain with HTTPS" points to Route 53 alias plus ACM certificate for CloudFront.

"Lowest operational overhead for static content" points away from EC2 and toward S3 plus CloudFront.

"Users see stale content after deployment" points to cache invalidation, cache headers, or object versioning.

"S3 website endpoint with OAC" is tricky because CloudFront origin access patterns differ between S3 REST origins and website endpoints. Read the wording carefully.

11. Common Traps

Do not make the bucket public when the requirement says only CloudFront should access it.

Do not use EC2 for static files unless there is server-side behavior the question requires.

Do not forget the ACM certificate Region requirement for CloudFront custom domains.

Do not ignore cache behavior. Stale assets are a deployment problem.

Do not forward all headers and cookies unless the application needs them. It can damage cache efficiency.

Do not confuse S3 static website hosting endpoints with private S3 REST origins.

12. Related Topics

Review Amazon S3, S3 vs EBS vs EFS vs Instance Store, and Identity Policies vs Resource Policies.

Official AWS references:

• Restrict access to an Amazon S3 origin
• S3 access control best practices
• Amazon CloudFront Documentation