CloudFront-distributioner og origins

At bruge en S3-bucket som CloudFront-oprindelse er et af de mest almindelige mønstre. CloudFront henter objekter fra S3, cacher dem på kantlokationer og leverer efterfølgende forespørgsler fra cachen uden at kontakte S3 igen. Det reducerer omkostningerne til S3-forespørgsler, forbedrer latenstiden for globale brugere og aflaster S3 for båndbredde.

Du behøver ikke gøre bucketen offentlig for at levere et S3-baseret websted. Brug i stedet Origin Access Control (OAC) – den moderne erstatning for Origin Access Identity (OAI). OAC giver kun CloudFront-distributionen tilladelse til at læse fra bucketen, så S3 forbliver privat, mens CloudFront leverer indholdet offentligt.

CloudFront understøtter også brugerdefinerede oprindelser: enhver HTTP- eller HTTPS-server, der er tilgængelig fra internettet, herunder EC2-instanser, Application Load Balancers, API Gateway-endpoints og lokale servere. Brugerdefinerede oprindelser gør det muligt for CloudFront at cache og accelerere dynamiske applikationer og API'er, ikke kun statiske filer.

Når du bruger en ALB som brugerdefineret oprindelse, skal du konfigurere ALB'en til kun at acceptere forbindelser fra CloudFronts IP-intervaller i dens sikkerhedsgruppe. Det tvinger al ekstern trafik gennem CloudFront, så WAF-regler og TLS-terminering kan aktiveres ved kanten, mens ALB'en holdes intern i AWS.

Origin Access Identity (OAI) var den oprindelige måde at begrænse S3-bucket-adgang til CloudFront på. Det er en særlig CloudFront-brugeridentitet, der tildeles i S3-bucket-politikken. OAI fungerer stadig, men betragtes som forældet.

Origin Access Control (OAC) er den moderne erstatning. OAC understøtter alle typer S3-buckets (herunder S3 i AWS China-Regions og SSE-KMS-krypterede buckets), bruger IAM-tjenesteprincipaler til mere detaljeret kontrol og signerer automatisk forespørgsler til S3 med SigV4. Brug altid OAC i stedet for OAI til nye distributioner.

Protokolpolitikken for brugere styrer, hvordan CloudFront håndterer forbindelser mellem brugere (viewere) og kantlokationen:

• HTTP og HTTPS: Tillad begge dele; anbefales ikke til følsomt indhold
• Omdiriger HTTP til HTTPS: Omdiriger HTTP-forespørgsler transparent til HTTPS; den mest almindelige indstilling
• Kun HTTPS: Afvis HTTP-forbindelser fuldstændigt; brug dette til streng håndhævelse af TLS

Separat styrer oprindelsesprotokolpolitikken, hvordan CloudFront kommunikerer med din oprindelse: kun HTTP, kun HTTPS eller match bruger. For S3-oprindelser med OAC bruger CloudFront altid HTTPS.

Hvis du vil levere indhold fra cdn.example.com i stedet for CloudFront-domænet, konfigurerer du et alternativt domænenavn (CNAME) i distributionen og tilknytter et SSL/TLS-certifikat fra AWS Certificate Manager (ACM). ACM-certifikatet skal være i regionen us-east-1 (uanset hvor din distribution leverer trafik fra), fordi CloudFront er en global tjeneste, der administreres fra us-east-1.

Opret Route 53-posten som en ALIAS-post, der peger på CloudFront-distributionens domænenavn. CloudFront leverer automatisk dit certifikat til matchende SNI-anmodninger.

CloudFronts prisklasse styrer, hvilke edge-lokationer der bruges til at levere din distribution. Højere prisklasser omfatter dyrere edge-lokationer (typisk i regioner med højere båndbreddeomkostninger):

• Prisklasse 100: kun Nordamerika og Europa (laveste pris)
• Prisklasse 200: Nordamerika, Europa, Asien, Mellemøsten og Afrika
• Prisklasse Alle: alle edge-lokationer verden over (bedste ydeevne, højeste pris)

Brug prisklasse 100 til interne værktøjer eller målgrupper, der er begrænset til Nordamerika og Europa. Brug prisklasse Alle til applikationer rettet mod forbrugere over hele verden.

Oprindelsesgrupper aktiverer failover for CloudFronts oprindelse. Du definerer en primær og en sekundær oprindelse i en gruppe. Hvis den primære oprindelse returnerer en bestemt HTTP-fejlkode (f.eks. 500, 502, 503 eller 504), prøver CloudFront automatisk anmodningen igen mod den sekundære oprindelse.

Failover for oprindelsen er nyttigt til katastrofeberedskab: Behold en primær S3-bucket i us-east-1 og en replikeret sikkerhedskopi i us-west-2 som den sekundære oprindelse. CloudFront skifter transparent over under et S3-nedbrud, uden at der kræves DNS-ændringer. Dette mønster supplerer S3 Cross-Region Replication.

CloudFront kan levere adgangslogfiler til en S3-bucket, hvor der registreres oplysninger om hver eneste seeranmodning: tidsstempel, edge-lokation, statuskode, overførte bytes, cache-hit eller cache-miss, brugeragent og meget mere. Logfilerne leveres i batches med få minutters mellemrum.

Brug adgangslogfiler til at analysere trafikmønstre, identificere populært indhold, kontrollere sikkerhedsrelevante felter (IP, henviser og brugeragent) og måle cache-hit-forhold. Feltet x-edge-result-type fortæller, om anmodningen var et Hit, Miss eller RefreshHit ved edge-lokationen.

CloudFront har to niveauer af cacheinfrastruktur:

• Edge-lokationer: hundredvis af PoP'er globalt tæt på slutbrugerne, som leverer cachelagret indhold med minimal latenstid
• Regionale edge-caches (REC'er): 13 større caches med længere levetid mellem edge-lokationerne og oprindelserne, som leverer indhold, der ikke er populært nok til at blive i de små caches på edge-lokationerne

Når en anmodning ikke findes i edge-lokationens cache, tjekker CloudFront den regionale edge-cache, før den går hele vejen til oprindelsen. REC'er er transparente—du konfigurerer dem ikke direkte—men de forbedrer cache-hit-forholdet betydeligt for indhold med lav popularitet og reducerer belastningen på oprindelsen.

I denne lektion lærte du, at CloudFront-distributioner cacher indhold på edge-lokationer globalt, at OAC holder S3-buckets private, samtidig med at CloudFront får adgang, og at brugerdefinerede oprindelser understøtter ALB'er, API Gateway og enhver HTTP-server. ACM-certifikater til CloudFront skal klargøres i us-east-1. Næste gang undersøger vi cacheadfærd og TTL-indstillinger.