Module 7: Reference Architectures And Domain Practice

3. Pattern: high-performing static site

Next →

Description

Of this module's five patterns, this is the one with the lowest operating cost — and, per official AWS documentation, the one that carries the most-cited CloudFront exam decision no previous lesson in this guide has covered yet: cache invalidation versus file versioning. Module 4, lesson 5, already gave you CloudFront in depth — edge locations, origins, Origin Access Control, signed URLs/signed cookies. This lesson doesn't repeat that content: it takes those already-established pieces and combines them into the complete pattern (S3 + CloudFront + Route 53), and goes deep specifically on the one point left pending — what to do when a cached file needs updating before it expires on its own.

Connection to the module

Of the five patterns, this is the one that needs the fewest new pieces — you already established every component with full precision in a previous module. This lesson's value is in seeing them as a single named pattern, and in closing the one real gap that remains: the invalidation decision.

The reference diagram

   REFERENCE PATTERN: HIGH-PERFORMING STATIC SITE

   User ──requests── app.example.com
       │
       ▼
   Route 53 (ALIAS record → CloudFront distribution)
       │
       ▼
   Amazon CloudFront (distribution, TLS with an ACM certificate in us-east-1)
       │
       │ Origin Access Control (OAC) — only CloudFront can read the bucket
       ▼
   Amazon S3 (private bucket, no direct public access)
       └── static objects: HTML, CSS, JS, images

   NO application server, NO database, NO Auto Scaling Group

The absence is this pattern's central feature: there's no compute tier to provision, scale, or patch. All content is static — generated ahead of time, not on each request — and all the work of serving it with low global latency falls to CloudFront's edge location network, not to any server you manage.

The components, revisited in one sentence each (full source in Module 4, lesson 5, and Module 2, lesson 6):

  • Amazon S3 — the origin, with Block Public Access enabled and no bucket policy allowing direct public access; the bucket never serves itself.
  • Origin Access Control (OAC) — the mechanism that gives CloudFront, and only CloudFront, permission to read the private bucket's objects.
  • Amazon CloudFront — the edge caching layer, with the TLS certificate requested in ACM us-east-1 without exception (Module 2, lesson 6, already established why), and with a default TTL of 24 hours if you don't configure a different one.
  • Amazon Route 53 — an ALIAS record (not a CNAME, which can't point to a domain's root name) that directs your application's public name to the CloudFront distribution.

The gap this lesson closes: invalidation vs. versioning

Module 4, lesson 5, already told you an invalidation forces CloudFront to discard cached copies of a path before they expire naturally. What that lesson left pending is the complete decision: when to invalidate, and when to use the alternative?

Invalidation, with its real cost. Per official AWS documentation, verified live, the first 1,000 invalidation paths you submit per month, per account, are free — starting from path 1,001 within the same month, each one is charged. A wildcard path (/images/*) counts as a single path, regardless of how many files it actually invalidates — so invalidating an entire site with /* still counts as just one of the 1,000 free paths, but invalidating a thousand individual files, one by one, exhausts the free limit much faster than invalidating the same content with a single wildcard.

File versioning, the alternative AWS recommends for frequent updates. Instead of overwriting app.js every time you deploy, you publish app.v2.js, app.v3.js, and so on — or, more commonly in practice, a content hash in the filename (app.a1b2c3.js) — and update the references in your HTML to point to the new name. Official AWS documentation is explicit about why it recommends this route when the site updates frequently: versioning controls exactly which version each user sees, even if they have a copy cached locally or behind a corporate proxy (something a CloudFront invalidation can't force to clear, because those caches are outside CloudFront's control); it simplifies rolling back to a previous version; and, the reason that weighs most in an architecture decision, versioning has no invalidation cost at all — you only pay the normal transfer of serving the new file to the edge, the same rate you'd pay anyway.

   INVALIDATION vs. VERSIONING — THE COMPLETE DECISION

   Invalidation                              File versioning
   ├── Free up to 1,000 paths/month/account   ├── No invalidation cost, ever
   ├── Charges per path past the limit        ├── The filename changes
   ├── Doesn't clear caches outside            │   (hash or version number)
   │   CloudFront (corporate proxy,            ├── Precisely controls which version
   │   local browser)                          │   each user sees, with no ambiguity
   └── Ideal for: one-off, infrequent          └── Ideal for: frequent deployments,
       corrections                                 regular CI/CD pipelines

The exam decision: a scenario describing one-off, infrequent corrections — a wrong image, a document with a typo, something fixed once and not repeated — points to invalidation, with no real cost concern given the low volume. A scenario describing frequent deployments — a CI/CD pipeline publishing several times a day, a site that changes constantly — points to file versioning as the recommended practice, precisely to avoid both the accumulated cost of repeated invalidations and the problem of external caches an invalidation can't reach.

The justification by domain (brief, because this pattern is narrow by design)

This pattern, unlike the other four, doesn't spread weight evenly across the four domains — its central value lives in High-Performing and Cost-Optimized, with Secure resolved almost entirely by OAC and no relevant Resilient surface beyond S3's native durability.

Secure: the bucket is never public — OAC is the only entry point, and Module 4, lesson 5, already established why a directly accessible public bucket is never the recommended answer when the alternative of keeping it private behind CloudFront exists.

High-Performing: it's the pattern's whole reason for existing — edge locations around the world bring content closer to the user, wherever they are, with the exact mechanism Module 4, lesson 5, already diagrammed (a cache hit responds immediately; a cache miss queries the origin only once per object and edge location).

Cost-Optimized: with no compute tier to provision, this pattern has no idle-server cost at all — you pay for data transfer and requests, nothing more — and this lesson's invalidation-vs-versioning decision is, itself, a continuous operating-cost decision.

Resilient: S3 offers extremely high object durability by design (documented as eleven nines), and CloudFront, serving from multiple edge locations in parallel, doesn't depend on the availability of a single delivery point — but this pattern doesn't need the Multi-AZ or Auto Scaling vocabulary that dominates the other four, precisely because there's no compute tier that can fail.

Common mistakes

Using a CNAME instead of an ALIAS record for the root domain (a standard-DNS limit Route 53 does resolve). What happens: someone tries pointing the root domain (example.com, with no subdomain) to CloudFront with a CNAME record, and discovers the DNS standard doesn't allow it at a zone's root name. How to spot it: if your DNS configuration for the root domain uses CNAME instead of ALIAS. How to fix it: a Route 53 ALIAS record — an AWS-specific extension over the DNS standard — can point the root name to an AWS resource like a CloudFront distribution, solving exactly this limitation.

Invalidating individual paths one by one, instead of with a wildcard, for the same deployment (needlessly exhausting the free limit). What happens: someone, after a deployment that changes a hundred files, submits a hundred individual path invalidations instead of a single one with /* or the shared prefix. How to spot it: if your invalidation bill grows faster than expected for the number of real deployments you made. How to fix it: a wildcard path counts as a single one of the 1,000 free paths, regardless of how many files it invalidates — grouping invalidations by prefix, instead of listing them one by one, is almost always cheaper for the same result.

Choosing invalidation for a site with several deployments a day, without considering the accumulated cost (ignoring AWS's explicit recommendation). What happens: someone keeps invalidating on every deploy of a frequent CI/CD pipeline, without evaluating file versioning as an alternative. How to spot it: if your scenario mentions a continuous deployment pipeline and your answer is still manual or automated invalidation on every run. How to fix it: official AWS documentation explicitly recommends versioning for frequent updates — no invalidation cost, with precise control over which version each user sees, the correct answer when the scenario describes regular, sustained changes, not one-off ones.

❓ Practice question — Domains 3 and 4 (combined pattern)

Scenario: MediaCentral, a digital magazine, publishes 15 to 20 new articles a day, each with its own generated HTML file, published through an automated CI/CD pipeline several times an hour. The team notices its monthly CloudFront bill includes a significant charge for invalidations — every publication triggers an invalidation of the new article's exact path — and wants to reduce that cost without risking a reader seeing an outdated version of a recently corrected article.

Question: Which is the most cost-effective change that solves this problem, without sacrificing the correctness of served content?

A. Disable CloudFront caching entirely for the articles bucket, always serving directly from the origin. B. Change each article file's name to include a unique version identifier (content hash or version number) on every publication or correction, and update the site's references instead of invalidating the previous path. C. Reduce publishing frequency to once a day, to trigger fewer total invalidations. D. Configure Amazon Global Accelerator in front of the existing CloudFront distribution to reduce invalidation latency.

✅ Correct answer: B

Why it's correct: the scenario describes exactly the textbook case official AWS documentation uses to recommend versioning over invalidation — frequent publications, several times an hour, triggering an accumulated invalidation cost. Naming each file with a unique version identifier eliminates the invalidation cost entirely (versioning carries no associated charge, only the normal transfer of the new file to the edge), and guarantees every reader sees exactly the correct version, without relying on an invalidation clearing caches outside CloudFront's control.

Why the others fail:

  • A: disabling caching entirely removes CloudFront's central advantage — serving content from the edge with low latency — and increases direct load on the S3 origin with every request; it's an overcorrection that sacrifices High-Performing to solve a cost problem that has a more precise solution.
  • C: reducing publishing frequency isn't an architecture decision — it's changing the business to accommodate a technical limitation that has a real solution available; it also doesn't eliminate the per-publication invalidation cost, only reduces it proportionally, leaving the underlying problem unsolved.
  • D: Global Accelerator accelerates network traffic to an endpoint — it has no relationship to CloudFront's cache invalidation mechanism or its cost; it's the right service for a different problem (Module 4, lesson 5), not this one.

Summary and next step

In this lesson you combined S3, CloudFront, and Route 53 into the exam's lowest-operating-cost pattern, and closed the exact gap Module 4 left pending: invalidation (free up to 1,000 paths a month, then charges per path) versus file versioning (no invalidation cost, the recommended practice for frequent deployments).

Before moving on you should be able to explain, in one sentence, when the exam expects invalidation and when it expects versioning, with the exact monthly free-path figure.

Lesson 4 covers the fourth pattern, and the most-cited decision diagram in industry practice exams: multi-region disaster recovery.

Resources

  1. CloudFront — Invalidate files to remove content — official source for the invalidation vs. versioning comparison, quoted verbatim in this lesson.
  2. CloudFront — Pay for file invalidation — official source for the exact figure of 1,000 free invalidation paths per month, per account, verified live on August 15, 2026.
  3. Module 4, lesson 5, and Module 2, lesson 6, of this guide — the complete CloudFront, OAC, ACM-in-us-east-1, and signed URLs/signed cookies vocabulary this pattern combines.
  4. Amazon Route 53 — Choosing between alias and non-alias records — official source for why an ALIAS record, not CNAME, is the correct answer for this pattern's root domain.
← Previous2. Pattern: async queue-based processingNext →4. Pattern: multi-region disaster recovery