SYSTEM Cited by 4 sources

Amazon CloudFront

Amazon CloudFront is AWS's global content delivery network — edge locations cache + serve HTTP(S) content to end users with low latency, offer DDoS protection + TLS termination + Lambda@Edge compute at the edge. Commonly paired with Route 53 DNS + WAF for the web application security baseline.

Stub — expand as dedicated sources arrive.

Architectural shape: CDN in front of single-write-region origin

The canonical CloudFront + S3 pattern: objects live in one authoritative S3 region; CloudFront caches popular objects at edge locations for fast reads anywhere. This is the shape Fly.io's Tigris announcement contrasts itself against — "AWS agrees, which is why they have a SKU for it, called CloudFront, which will, at some variably metered expense, optimize the read side of a single-write-region bucket" — i.e. a read-side optimisation for an otherwise-regional origin, not a globally distributed storage plane. Compare and contrast with systems/tigris and the patterns/metadata-db-plus-object-cache-tier shape.

Seen in

• sources/2026-04-01-aws-automate-safety-monitoring-with-computer-vision-and-generative-ai — distributes the React web application for the AWS safety- monitoring solution; paired with AppSync GraphQL API behind it + Route 53 DNS + WAF for common web-vulnerability protection.
• sources/2024-02-15-flyio-globally-distributed-object-storage-with-tigris — explicitly cited as the incumbent architectural shape Tigris is not — a caching CDN over a single-write-region bucket, quoted as the two-hour baseline Tigris undercuts on setup time and outperforms architecturally. Useful wiki data point: CloudFront's role in the AWS stack is as the read-side-optimisation SKU, not a globally distributed storage plane.
• sources/2025-07-08-planetscale-caching — Ben Dicken names CloudFront as the canonical CDN / in-memory edge-cache example for recency-biased web content sitting in front of "slow" S3-class storage: "These websites store much of their content (email, images, documents, videos, etc) in 'slow' storage (like Amazon S3 or similar), but cache recent content in faster, in-memory stores (like CloudFront, Redis or Memcached)." Canonical wiki datum positioning CloudFront as the geographic- caching tier of the same two-tier caching pattern — patterns/pair-fast-small-cache-with-slow-large-storage — applied at planet scale. Dicken's latency stratification datum — 10–20 ms east-coast, 50–100 ms west-coast, 250+ ms across the world — makes the geographic-physics case for why the pattern pays off. See patterns/cdn-edge-cache-over-central-origin for the pattern page.
• sources/2026-07-15-aws-bitdrift-scaled-121-million-grpc-connections-cloudfront — canonical DNS-routing-at-CDN-scale incident. bitdrift's mobile observability SDK established 121M concurrent gRPC connections through CloudFront to a multi-NLB origin fleet. CloudFront's internal origin-domain resolution via Route 53 Weighted routing returned 1 IP per query → all edge nodes converged on one NLB per TTL window → thundering herd overwhelmed individual NLBs (80% 5xx). Fix: Multi-Value Answer routing (up to 8 IPs per response) → immediate distribution → zero errors. Key lesson: at CDN edge-fleet scale, the origin-facing DNS routing policy is architecturally load-bearing — not an operational detail. See concepts/dns-ttl-concentration and patterns/multi-value-answer-routing-for-origin-distribution.