Designing the Frontend: S3 and CloudFront
By the end of this lesson, you'll be able to:
- Justify serving a static learning-application frontend from S3 rather than from a traditional web server
- Explain what CloudFront adds in front of an S3 static site, and what problem it specifically solves
- Apply the Project Decision Record format to a frontend-delivery decision
Prerequisites: "Capstone Overview and Architecture Planning"
Why static, and why S3
The learner-facing frontend for this scenario — the pages that list courses, show a lesson, and display progress — doesn't need a server generating a fresh HTML response on every request. It needs the browser to receive HTML, CSS, and JavaScript, which then calls the API layer (Lesson 3) for anything dynamic. That's exactly the static-website-hosting pattern Module 4 introduced with S3: durable, low-operational-overhead storage for files that get served as-is.
Requirement: serve the frontend's static assets reliably without operating a fleet of web servers just to hand out unchanging files. Decision: host the built frontend as objects in an S3 bucket. Reason: S3 is built for exactly this — durable object storage served over HTTP, with no server to patch, scale, or keep running. Alternative: run a small EC2-based web server (or a container) serving the same static files. Trade-off: S3 alone has no built-in HTTPS at a custom domain and no edge caching — which is exactly what the next section adds.
What CloudFront adds in front of S3
CloudFront is a content delivery network: it caches content at locations distributed around the world, so a learner's request can often be served from a location near them rather than travelling all the way to the S3 bucket's home Region every time. Placed in front of the S3 bucket as its origin, CloudFront gives this frontend three things S3's own static-website endpoint doesn't provide by itself: HTTPS at a custom domain, edge caching that reduces both latency and direct load on the origin bucket, and a single global entry point for the application.
Requirement: learners anywhere should get a responsive frontend over HTTPS at the application's own domain. Decision: place a CloudFront distribution in front of the S3 origin bucket. Reason: CloudFront adds HTTPS, edge caching, and global reach without requiring the frontend itself to change. Alternative: point a domain directly at the S3 static-website endpoint. Trade-off: CloudFront adds a layer to reason about — cache invalidation when the frontend is updated, and one more piece of the architecture to monitor — in exchange for meaningfully better performance and security posture for learners.
Exercise
A teammate suggests skipping CloudFront and pointing the application's domain directly at the S3 bucket's static-website endpoint, to "keep things simple." Write the Project Decision Record you would present in response, including a genuine trade-off CloudFront introduces that a reviewer might reasonably ask about.
Show hint
Simplicity is a real trade-off worth naming honestly — don't pretend CloudFront is free of downsides just because it's the recommended choice here.
Designing the Frontend: S3 and CloudFront Quiz
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
A learning application's frontend — the HTML, CSS, and JavaScript a learner's browser loads — can be served as static files from S3, and placing CloudFront in front of that bucket adds HTTPS, edge caching closer to learners, and global reach that a bare S3 static-website endpoint does not provide on its own, extending the static-hosting pattern from Module 4.