CloudFront-distribusjoner og origins

Amazon CloudFront er AWS sitt globale Content Delivery Network (CDN) som hurtigbufrer og leverer innhold fra edge-lokasjoner fordelt på over 400 byer i mer enn 90 land. Når en bruker ber om innhold, leverer CloudFront det fra den nærmeste edge-lokasjonen, noe som reduserer forsinkelsen betydelig sammenlignet med å hente innholdet fra opphavsserveren.

CloudFront brukes ikke bare til statiske filer – tjenesten akselererer også dynamisk innhold, API-er og videostrømming. Den integreres med andre AWS-tjenester som S3, ALB, Lambda@Edge, WAF og Shield, og er derfor distribusjonslaget som vanligvis brukes i moderne AWS-arkitekturer.

En CloudFront-distribusjon er den primære konfigurasjonsenheten. Den definerer én eller flere opphav (der innholdet ligger), hurtigbufferatferd (hvordan ulike URL-baner hurtigbufres), sikkerhetsinnstillinger og prisnivåer. De får tilgang til innholdet via distribusjonens domenenavn (for eksempel d1234abcdef.cloudfront.net) eller et egendefinert domene (for eksempel cdn.example.com) ved hjelp av en CNAME- eller ALIAS-post.

Etter opprettelsen tar det 10–15 minutter å distribuere distribusjoner globalt til alle edge-lokasjoner. Endringer i en eksisterende distribusjon tar også flere minutter å spre. Historisk har det vært to distribusjonstyper, men i dag bruker alle distribusjoner det samme samlede konfigurasjonsgrensesnittet.

Å bruke en S3-bøtte som CloudFront-opphav er et av de vanligste mønstrene. CloudFront henter objekter fra S3, hurtigbufrer dem ved edge-lokasjoner og leverer påfølgende forespørsler fra hurtigbufferet uten å kontakte S3 på nytt. Dette reduserer kostnadene for S3-forespørsler, forbedrer latenstiden for globale brukere og avlaster S3 for båndbredde.

For å levere et S3-basert nettsted trenger De ikke å gjøre bøtten offentlig. Bruk i stedet Origin Access Control (OAC) – den moderne erstatteren for Origin Access Identity (OAI). OAC gir bare CloudFront-distribusjonen tillatelse til å lese fra bøtten, slik at S3 forblir privat mens CloudFront leverer innholdet offentlig.

CloudFront støtter også egendefinerte opphav: alle HTTP- eller HTTPS-servere som er tilgjengelige fra internett, inkludert EC2-instanser, Application Load Balancers, API Gateway-endepunkter og lokale servere. Egendefinerte opphav gjør det mulig for CloudFront å hurtigbufre og akselerere dynamiske applikasjoner og API-er, ikke bare statiske filer.

Når De bruker en ALB som egendefinert opphav, må De konfigurere ALB-en til bare å godta tilkoblinger fra CloudFronts IP-områder i sikkerhetsgruppen. Dette tvinger all ekstern trafikk gjennom CloudFront, slik at WAF-regler og TLS-terminering kan brukes ved edge-lokasjonen, mens ALB-en holdes intern i AWS.

Origin Access Identity (OAI) var den opprinnelige måten å begrense S3-bøttetilgang til CloudFront på. Det er en spesiell CloudFront-brukeridentitet som tildeles i S3-bøttens policy. OAI fungerer fortsatt, men regnes som en eldre løsning.

Origin Access Control (OAC) er den moderne erstatteren. OAC støtter alle typer S3-bøtter (inkludert S3 i AWS China-Regioner og SSE-KMS-krypterte bøtter), bruker IAM-tjenesteprinsipaler for mer detaljert kontroll og signerer automatisk forespørsler til S3 med SigV4. For nye distribusjoner bør De alltid bruke OAC i stedet for OAI.

Viewer Protocol Policy styrer hvordan CloudFront håndterer tilkoblinger mellom brukere (visningsklienter) og edge-lokasjonen:

• HTTP and HTTPS: tillat begge deler; anbefales ikke for sensitivt innhold
• Redirect HTTP to HTTPS: videresend HTTP-forespørsler transparent til HTTPS; den vanligste innstillingen
• HTTPS Only: avvis HTTP-tilkoblinger fullstendig; bruk dette for streng håndheving av TLS

Separat styrer Origin Protocol Policy hvordan CloudFront kommuniserer med opphavet: bare HTTP, bare HTTPS eller samsvar med visningsklienten. For S3-opphav med OAC bruker CloudFront alltid HTTPS.

For å levere innhold fra cdn.example.com i stedet for CloudFront-domenet konfigurerer De et Alternate Domain Name (CNAME) i distribusjonen og knytter til et SSL/TLS-sertifikat fra AWS Certificate Manager (ACM). ACM-sertifikatet må være i us-east-1 Region (uavhengig av hvor distribusjonen leverer trafikk), fordi CloudFront er en global tjeneste som administreres fra us-east-1.

Opprett Route 53-posten som en ALIAS-post som peker til domenenavnet for CloudFront-distribusjonen. CloudFront leverer automatisk sertifikatet ved samsvarende SNI-forespørsler.

CloudFronts Price Class styrer hvilke edge locations som brukes til å levere distribusjonen. Høyere prisklasser inkluderer dyrere edge locations (vanligvis i regioner med høyere båndbreddekostnader):

• Price Class 100: kun Nord-Amerika og Europa (lavest kostnad)
• Price Class 200: Nord-Amerika, Europa, Asia, Midtøsten og Afrika
• Price Class All: alle edge locations over hele verden (best ytelse, høyest kostnad)

Bruk Price Class 100 for interne verktøy eller målgrupper som er begrenset til Nord-Amerika og Europa. Bruk Price Class All for globale applikasjoner rettet mot forbrukere.

Origin groups gjør failover for CloudFront-origin mulig. De definerer en primær origin og en sekundær origin i en gruppe. Hvis den primære origin-en returnerer en bestemt HTTP-feilkode (for eksempel 500, 502, 503 eller 504), prøver CloudFront automatisk forespørselen på nytt mot den sekundære origin-en.

Origin-failover er nyttig for gjenoppretting etter katastrofer: behold en primær S3-bøtte i us-east-1 og en replikert sikkerhetskopi i us-west-2 som sekundær origin. CloudFront går transparent over til den sekundære origin-en ved et S3-avbrudd, uten at DNS-endringer kreves. Dette mønsteret utfyller S3 Cross-Region Replication.

CloudFront kan levere access logs til en S3-bøtte og registrere detaljer om hver visningsforespørsel: tidsstempel, edge location, statuskode, overførte byte, cache-treff eller -bom, brukeragent og mer. Logger leveres i puljer med noen minutters mellomrom.

Bruk tilgangslogger til å analysere trafikkmønstre, identifisere innhold med høy belastning, revidere sikkerhetsrelevante felt (IP, referent, brukeragent) og måle treffprosenten i cachen. Feltet x-edge-result-type forteller om forespørselen var en Hit, Miss eller RefreshHit på edge location.

CloudFront har to nivåer med hurtigbufferinfrastruktur:

• Edge locations: hundrevis av PoP-er globalt, nær sluttbrukerne; leverer bufret innhold med minimal forsinkelse
• Regional Edge Caches (RECs): 13 større cacher med lengre levetid mellom edge locations og origin-er; leverer innhold som ikke er populært nok til å bli værende i de små cachene ved edge locations

Når et oppslag i cachen ved edge location ikke treffer, kontrollerer CloudFront REC-en før forespørselen sendes helt til origin-en. REC-er er transparente – De konfigurerer dem ikke direkte – men de forbedrer treffprosenten i cachen betydelig for innhold med lang hale og reduserer belastningen på origin-en.

I denne leksjonen lærte De at CloudFront-distribusjoner bufrer innhold globalt ved edge locations, at OAC holder S3-bøtter private samtidig som CloudFront får tilgang, og at egendefinerte origin-er støtter ALB-er, API Gateway og alle HTTP-servere. ACM-sertifikater for CloudFront må klargjøres i us-east-1. Deretter skal vi se nærmere på cache-atferd og TTL-innstillinger.