Building blocks
Design goal
Serve static content from the edge without allowing users to bypass CloudFront and reach the S3 origin directly.
Architecture
CloudFront serves cached content over HTTPS and signs origin requests through Origin Access Control to a private S3 bucket origin.
Architecture decisions
Use a private S3 origin
WhyKeep the bucket non-public and grant CloudFront controlled origin access.
Trade-offBlocking direct S3 access strengthens the delivery boundary, but origin troubleshooting and alternate access paths must go through the CloudFront design.
Use OAC for new designs
WhyOrigin Access Control is the current preferred control for supported S3 origins.
Trade-offOAC is the preferred control for supported origins, but it introduces signed-origin-request behavior that must be reflected in bucket policies and migration planning.
Security
Protect the control and data paths deliberately. Enforce HTTPS, private bucket access, least-privilege bucket policy, WAF where required, and secure response headers.
Availability
Design for the failure domain that must be survived. CloudFront is globally distributed; S3 durability and origin design should be considered separately from regional application recovery.
Disaster recovery
Treat regional recovery as a separate operating state. For stricter regional resilience requirements, define origin replication or failover behavior independently of the CDN layer.
Cost drivers
- CloudFront requests/data transfer
- S3 storage/requests
- WAF requests
- Route 53
Design assumptions
- Content is static or suitable for CDN delivery
- Custom domain ownership is available
Implementation plan
- Create the S3 origin with Block Public Access enabled and no direct public website endpoint.
- Create the CloudFront distribution and use Origin Access Control so requests to S3 are authenticated by CloudFront.
- Restrict the bucket policy to the intended CloudFront distribution rather than granting broad service or public access.
- Configure the certificate, DNS, cache behaviors, security headers, and WAF policy required by the application exposure model.
- Enable access and security logging, then test both the CloudFront path and attempted direct access to the S3 origin.
Validate the design
- Confirm HTTPS redirects and certificate validation work on the public hostname.
- Attempt direct S3 object access and confirm it is denied outside the CloudFront authorization path.
- Change a test object and verify cache TTL/invalidation behavior matches the intended freshness model.
- Trigger a controlled WAF rule, when enabled, and confirm the request and log entry are visible.