AWS Solutions Architect · Lektion

Cacheadfærd og TTL-indstillinger

Definer sti-baseret cacheadfærd, angiv minimale, standardmæssige og maksimale TTL'er, og brug Cache-Control-headere til finjustering af caching.

Lektion 2 af 413 trin

Cacheadfærd og TTL-indstillinger er en gratis AWS Solutions Architect-lektion på CoddyKit. Dette er lektion 2 af 4. Du kan læse alle 3 lektioner i dette læringsspor gratis i deres fulde længde — derefter låser CoddyKit PRO alle lektioner op samt praktiske øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Den er en del af læringsforløbet i AWS Solutions Architect, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. AWS Solutions Architect-kurset indeholder 4 lektioner i alt.

Hvad er cacheadfærd?

Cacheadfærd er de regler, der fortæller CloudFront, hvordan anmodninger til forskellige URL-stimønstre skal håndteres. Hver cacheadfærd knytter et stimønster (f.eks. /images/*, /api/* eller *.css) til en bestemt oprindelse og cachekonfiguration.

En distribution har én standardcacheadfærd (som matcher alle stier, der ikke fanges af mere specifikke adfærdsmønstre) og op til 25 yderligere stimønsterbaserede adfærdsmønstre. CloudFront evaluerer adfærdsmønstrene i rækkefølge fra mest specifikt til mindst specifikt og falder derefter tilbage til standarden.

Matchning af stimønstre

Stimønstre understøtter jokertegn: * matcher enhver kombination af tegn, herunder skråstreger, og ? matcher ét vilkårligt tegn. Eksempler:

/images/* — alle URL'er, der starter med /images/
*.jpg — alle anmodninger, der ender på .jpg, uanset hvor i stien
/api/v2/* — alle API v2-ruter
/static/??.css — statiske CSS-filer med præcis to tegn før .css

Adfærdsmønstrene evalueres i den rækkefølge, de står i distributionskonfigurationen. Placér de mest specifikke mønstre først. Standardadfærden (*) matcher altid til sidst.

Cachepolitik sammenlignet med politik for oprindelsesanmodninger

CloudFront opdeler cachelogikken i to politiktyper:

Cachepolitik: definerer, hvad CloudFront bruger som cache-nøgle—kombinationen af headere, forespørgselsstrenge og cookies, der afgør, om et cachelagret objekt matcher en anmodning. Angiver også TTL-grænser.
Politik for oprindelsesanmodninger: definerer, hvilke headere, forespørgselsstrenge og cookies der videresendes til oprindelsen—selv hvis de ikke er en del af cache-nøglen (så du kan sende godkendelsesheadere til oprindelsen uden at variere cachen efter tokenet)

AWS leverer administrerede politikker (f.eks. CachingOptimized og CachingDisabled), der dækker de fleste anvendelser, eller du kan oprette brugerdefinerede politikker.

TTL-indstillinger i CloudFront

CloudFront respekterer tre TTL-værdier fra cachepolitikken:

Minimum-TTL: den korteste tid, CloudFront cacher et objekt, uanset headere fra oprindelsen (standard er 0)
Standard-TTL: den tid, CloudFront cacher et objekt, når oprindelsen ikke sender en Cache-Control- eller Expires-header (standard er 86.400 sekunder = 1 dag)
Maksimum-TTL: den længste tid, CloudFront cacher et objekt, og som sætter en øvre grænse for oprindelsens Cache-Control max-age-direktiv (standard er 31.536.000 = 1 år)

Disse tre værdier afgrænser den faktiske cachevarighed, som oprindelser angiver via Cache-Control-headere.

Cache-Control-headere fra oprindelser

Når din oprindelse sender en Cache-Control: max-age=3600-header, cacher CloudFront objektet i 3.600 sekunder—så længe værdien ligger inden for cachepolitikkens minimums- og maksimums-TTL. Hvis oprindelsen sender Cache-Control: no-cache eller Cache-Control: no-store, kontrollerer CloudFront oprindelsen, før den cachelagrede kopi leveres hver gang.

For statiske aktiver, der sjældent ændres, skal du angive en lang max-age (f.eks. 31536000 = 1 år) og bruge cache-busting—inkludér en indholdshash i filnavne (f.eks. app.a3f4b5.js)—så URL'en ændres, når indholdet ændres, og den gamle cachelagrede version dermed automatisk ugyldiggøres.

# S3 object metadata with long cache TTL
aws s3 cp app.a3f4b5.js s3://my-bucket/ \
  --cache-control 'max-age=31536000, immutable' \
  --content-type 'application/javascript'

Adskillelse af statisk og dynamisk adfærd

Et effektivt mønster for cacheadfærd adskiller statisk og dynamisk indhold:

/static/*, *.css, *.js, *.jpg → S3-oprindelse, politikken CachingOptimized (høj TTL, ingen cookies eller forespørgselsstrenge i cache-nøglen)
/api/* → ALB-oprindelse, politikken CachingDisabled (hentes altid fra oprindelsen, alle headere og cookies videresendes)
/* (standard) → ALB-oprindelse, moderat cachelagring

Dette adskiller det statiske lag, der egner sig godt til cachelagring, fra det dynamiske API-lag. Dermed maksimeres cache-hit-forholdet for statisk indhold, samtidig med at API-svar altid er aktuelle.

Ugyldiggørelse af cache

Når du opdaterer indhold i S3 eller på din oprindelse og vil levere den nye version fra CloudFront med det samme uden at vente på, at TTL'en udløber, opretter du en cache-ugyldiggørelse. Angiv de stier, der skal ugyldiggøres (f.eks. /images/logo.png eller /images/*), så fjerner CloudFront disse objekter fra alle edge-caches.

Ugyldiggørelser koster penge: De første 1.000 stier pr. måned er gratis, mens yderligere stier koster pr. sti. Ugyldiggørelser med jokertegn (f.eks. /*) tæller som én sti. Bedste praksis er at bruge versionsnumre i filnavne til statiske aktiver (cache-busting) i stedet for hyppige ugyldiggørelser for at reducere omkostninger og forsinkelse.

# Create a cache invalidation for updated images
aws cloudfront create-invalidation \
  --distribution-id EDFDVBD6EXAMPLE \
  --paths '/images/logo.png' '/css/main.css'

Komponenter i cache-nøglen

Cache-nøglen er den entydige identifikator, CloudFront bruger til at slå et cachelagret svar op. Som standard består cache-nøglen kun af URL-stien. Hvis du medtager flere komponenter, øges antallet af forskellige cacheposter:

Forespørgselsstrenge: /search?q=aws og /search?q=s3 er separate cacheposter, hvis q er med i cache-nøglen
Headere: Hvis du medtager Accept-Encoding, kan CloudFront cache gzip- og ikke-gzip-versioner separat
Cookies: Hvis du medtager sessionscookies, oprettes der cacheposter pr. bruger, hvilket i praksis deaktiverer cachelagring

Minimér antallet af komponenter i cache-nøglen for at opnå maksimal cacheeffektivitet. Medtag kun det, der reelt medfører forskelligt svarindhold.

Komprimering ved edge-lokationen

CloudFront kan automatisk komprimere tekstbaserede objekter (HTML, CSS, JavaScript og JSON) ved hjælp af gzip eller Brotli, før de leveres til seerne. Det reducerer nyttelastens størrelse med 60–80 % og forbedrer indlæsningstiderne for sider uden ændringer på din oprindelse.

Sådan aktiverer du komprimering: Sørg for, at cachepolitikken medtager Accept-Encoding i cache-nøglen (CloudFront skal kunne cache gzip- og ikke-gzip-versioner separat), og aktivér Compress Objects Automatically i cacheadfærden. CloudFront komprimerer objekter, der er større end 1.000 bytes og mindre end 10 MB.

Cache-hit-forhold og overvågning

Cache-hit-forholdet er procentdelen af anmodninger, der leveres fra CloudFront-cachen uden at gå til oprindelsen. Et højt forhold (80 % eller mere) betyder lavere omkostninger til oprindelsen og bedre ydeevne. Overvåg det via rapporten Cache Statistics i CloudFront-konsollen eller via CloudWatch-metrikken CacheHitRate.

Sådan forbedrer du cache-hit-forholdet: Forøg TTL-værdierne, reducér antallet af headere og cookies i cache-nøglen, brug normalisering af forespørgselsstrenge (videresend kun de forespørgselsstrenge, som din applikation faktisk bruger), og angiv passende Cache-Control-headere på oprindelsen.

# Get CloudFront metrics for cache hit rate
aws cloudwatch get-metric-statistics \
  --namespace AWS/CloudFront \
  --metric-name CacheHitRate \
  --dimensions Name=DistributionId,Value=EDFDVBD6EXAMPLE \
  --start-time 2026-06-19T00:00:00Z \
  --end-time 2026-06-20T00:00:00Z \
  --period 3600 \
  --statistics Average \
  --region us-east-1

Indstillinger for oprindelse og protokol pr. adfærd

Hver cacheadfærd kan pege på en anden oprindelse, så én CloudFront-distribution kan levere indhold fra flere backend-systemer. Eksempel:

/static/* → S3-oprindelse (privat bucket via OAC)
/api/* → ALB-oprindelse i us-east-1
/media/* → MediaPackage CDN-oprindelse til videostreaming

Hver adfærd konfigurerer også uafhængigt seerprotokolpolitik, tilladte HTTP-metoder og funktionstilknytninger (CloudFront Functions eller Lambda@Edge). Det gør én distribution til et fleksibelt leveringslag til mange formål.

Hurtigt tjek

Test din forståelse af AWS Solutions Architect-koncepterne (SAA-C03) fra denne lektion.

Besvar den i den interaktive lektion

Opsummering af lektionen

I denne lektion lærte du, at cacheadfærd knytter URL-stimønstre til oprindelser og cacheringsregler, at grænserne for minimums-, standard- og maksimums-TTL styrer, hvor længe indhold cacheres, hvor oprindelsens Cache-Control-headere har forrang, når de er til stede, og at cache-ugyldiggørelser straks fjerner forældet indhold fra alle edge-lokationer. Minimér komponenterne i cache-nøglen for at maksimere cache-hit-forholdet. Næste gang undersøger vi signerede URL'er, signerede cookies og geografisk begrænsning.

Gratis at komme i gang

Lær AWS Solutions Architect med en AI-underviser — gratis

Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.

Kurser: 30
Lektioner: 120

Start gratis Se hele kurset

Ofte stillede spørgsmål

Er lektionen “Cacheadfærd og TTL-indstillinger” gratis?

Ja — alle 3 lektioner i læringssporet AWS Solutions Architect, inklusive “Cacheadfærd og TTL-indstillinger”, kan læses gratis i deres fulde længde her på webstedet. Derefter låser CoddyKit PRO alle lektioner op samt interaktive øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. AWS Solutions Architect-kurset indeholder 4 lektioner i alt.

Hvad lærer jeg i “Cacheadfærd og TTL-indstillinger”?

Definer sti-baseret cacheadfærd, angiv minimale, standardmæssige og maksimale TTL'er, og brug Cache-Control-headere til finjustering af caching. Du øver dig i AWS Solutions Architect med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.

Skal jeg have erfaring for at begynde på AWS Solutions Architect?

Der kræves ingen tidligere erfaring. AWS Solutions Architect på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 2 af 4.

Hvor lang tid tager lektionen “Cacheadfærd og TTL-indstillinger”?

De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.

Kan jeg skrive og køre kode i denne AWS Solutions Architect-lektion?

Ja. Alle AWS Solutions Architect-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.

Alle lektioner i dette kursus

CloudFront-distributioner og origins
Cacheadfærd og TTL-indstillinger
Signerede URL'er, signerede cookies og geobegrænsning
CloudFront med WAF og Lambda@Edge

← Tilbage til AWS Solutions Architect