Zachowania pamięci podręcznej i ustawienia TTL

Zachowania pamięci podręcznej to reguły określające, jak CloudFront ma obsługiwać żądania dla różnych wzorców ścieżek URL. Każde zachowanie pamięci podręcznej przyporządkowuje wzorzec ścieżki (np. /images/*, /api/*, *.css) do konkretnego źródła i konfiguracji buforowania.

Dystrybucja ma jedno Default Cache Behavior (pasujące do wszystkich ścieżek, których nie obejmują bardziej szczegółowe zachowania) oraz maksymalnie 25 dodatkowych zachowań opartych na ścieżkach. CloudFront sprawdza zachowania w kolejności od najbardziej do najmniej szczegółowego, a następnie przechodzi do domyślnego.

Wzorce ścieżek obsługują symbole wieloznaczne: * dopasowuje dowolną kombinację znaków, w tym ukośniki, a ? dopasowuje dowolny pojedynczy znak. Przykłady:

• /images/* — wszystkie adresy URL zaczynające się od /images/
• *.jpg — wszystkie żądania kończące się rozszerzeniem .jpg, niezależnie od miejsca w ścieżce
• /api/v2/* — wszystkie trasy interfejsu API w wersji 2
• /static/??.css — statyczne pliki CSS z dokładnie dwoma znakami przed .css

Zachowania są sprawdzane w kolejności widocznej w konfiguracji dystrybucji. Bardziej szczegółowe wzorce należy umieszczać wcześniej. Zachowanie domyślne (*) zawsze jest sprawdzane na końcu.

CloudFront rozdziela logikę buforowania na dwa typy zasad:

• Cache Policy: określa, czego CloudFront używa jako klucza pamięci podręcznej — kombinacji nagłówków, parametrów zapytania i plików cookie, które decydują o tym, czy buforowany obiekt pasuje do żądania. Ustawia również zakresy TTL.
• Origin Request Policy: określa, które nagłówki, parametry zapytania i pliki cookie są przekazywane do źródła — nawet jeśli nie są częścią klucza pamięci podręcznej (aby wysyłać nagłówki uwierzytelniania do źródła bez różnicowania pamięci podręcznej dla każdego tokenu)

AWS udostępnia zarządzane zasady (np. CachingOptimized, CachingDisabled) obejmujące większość przypadków użycia; można też utworzyć własne zasady.

CloudFront respektuje trzy wartości TTL z zasad pamięci podręcznej:

• Minimum TTL: najkrótszy czas przechowywania obiektu w pamięci podręcznej CloudFront, niezależnie od nagłówków źródła (domyślnie 0)
• Default TTL: czas przechowywania obiektu w pamięci podręcznej CloudFront, gdy źródło nie wysyła nagłówka Cache-Control ani Expires (domyślnie 86 400 sekund = 1 dzień)
• Maximum TTL: najdłuższy czas przechowywania obiektu w pamięci podręcznej CloudFront, ograniczający dyrektywę źródła Cache-Control max-age (domyślnie 31 536 000 = 1 rok)

Te trzy wartości wyznaczają zakres rzeczywistego czasu buforowania określanego przez źródła za pomocą nagłówków Cache-Control.

Gdy źródło wysyła nagłówek Cache-Control: max-age=3600, CloudFront buforuje obiekt przez 3600 sekund — o ile ta wartość mieści się w zakresie minimalnego i maksymalnego TTL określonym przez zasady pamięci podręcznej. Jeśli źródło wysyła Cache-Control: no-cache lub Cache-Control: no-store, CloudFront przed każdym wyświetleniem buforowanej kopii sprawdzi źródło.

W przypadku statycznych zasobów, które rzadko się zmieniają, należy ustawić długi max-age (np. 31536000 = 1 rok) i stosować unieważnianie pamięci podręcznej przez zmianę nazw — umieszczać skrót treści w nazwach plików (np. app.a3f4b5.js) — aby po zmianie treści zmieniał się adres URL, automatycznie unieważniając starą wersję z pamięci podręcznej.

Skuteczny wzorzec zachowań pamięci podręcznej rozdziela treści statyczne i dynamiczne:

• /static/*, *.css, *.js, *.jpg → źródło S3, zasada CachingOptimized (długi TTL, bez plików cookie i parametrów zapytania w kluczu pamięci podręcznej)
• /api/* → źródło ALB, zasada CachingDisabled (zawsze pobierane ze źródła, wszystkie nagłówki i pliki cookie są przekazywane)
• /* (domyślne) → źródło ALB, umiarkowane buforowanie

Rozdziela to warstwę statyczną, którą można intensywnie buforować, od dynamicznej warstwy API, maksymalizując współczynniki trafień dla treści statycznych i zapewniając, że odpowiedzi API są zawsze aktualne.

Gdy zaktualizują Państwo treść w S3 lub w źródle i chcą natychmiast udostępniać nową wersję z CloudFront bez oczekiwania na wygaśnięcie TTL, należy utworzyć unieważnienie pamięci podręcznej. Należy określić ścieżki do unieważnienia (np. /images/logo.png lub /images/*), a CloudFront usunie te obiekty ze wszystkich pamięci podręcznych na brzegach.

Unieważnienia wiążą się z kosztami: pierwsze 1000 ścieżek miesięcznie jest bezpłatne, a za kolejne ścieżki pobierana jest opłata. Unieważnienia z symbolem wieloznacznym (np. /*) są liczone jako jedna ścieżka. Najlepsza praktyka to używanie wersjonowanych nazw plików dla zasobów statycznych (unieważnianie przez zmianę nazw) zamiast częstych unieważnień, aby ograniczyć koszty i opóźnienia.

Klucz pamięci podręcznej to unikatowy identyfikator używany przez CloudFront do wyszukiwania buforowanej odpowiedzi. Domyślnie klucz pamięci podręcznej obejmuje tylko ścieżkę URL. Uwzględnienie dodatkowych elementów zwiększa liczbę różnych wpisów w pamięci podręcznej:

• Parametry zapytania: /search?q=aws i /search?q=s3 są osobnymi wpisami, jeśli parametr q znajduje się w kluczu pamięci podręcznej
• Nagłówki: uwzględnienie Accept-Encoding pozwala CloudFront buforować osobno wersje gzip i bez gzip
• Pliki cookie: uwzględnienie plików cookie sesji tworzy wpisy dla poszczególnych użytkowników, skutecznie wyłączając buforowanie

Należy ograniczać liczbę elementów klucza pamięci podręcznej, aby uzyskać maksymalną efektywność buforowania. Należy uwzględniać tylko te elementy, które rzeczywiście powodują powstawanie różnych treści odpowiedzi.

CloudFront może automatycznie kompresować obiekty tekstowe (HTML, CSS, JavaScript, JSON) za pomocą gzip lub Brotli przed dostarczeniem ich odbiorcom. Zmniejsza to rozmiar danych o 60–80% i skraca czas ładowania strony bez jakichkolwiek zmian w źródle.

Aby włączyć kompresję, należy upewnić się, że zasada pamięci podręcznej uwzględnia Accept-Encoding w kluczu pamięci podręcznej (CloudFront musi buforować osobno wersje gzip i bez gzip), a następnie włączyć opcję Compress Objects Automatically w zachowaniu pamięci podręcznej. CloudFront kompresuje obiekty większe niż 1000 bajtów i mniejsze niż 10 MB.

Współczynnik trafień pamięci podręcznej to odsetek żądań obsłużonych z pamięci podręcznej CloudFront bez kontaktowania się ze źródłem. Wysoki współczynnik (80% lub więcej) oznacza niższe koszty źródła i lepszą wydajność. Można go monitorować za pomocą raportu Cache Statistics w konsoli CloudFront lub metryki CloudWatch CacheHitRate.

Sposoby na poprawę współczynnika trafień: zwiększenie wartości TTL, ograniczenie liczby nagłówków i plików cookie w kluczu pamięci podręcznej, normalizacja parametrów zapytania (przekazywanie tylko parametrów rzeczywiście używanych przez aplikację) oraz ustawienie odpowiednich nagłówków Cache-Control w źródle.

Każde zachowanie pamięci podręcznej może wskazywać na inne źródło, dzięki czemu jedna dystrybucja CloudFront może dostarczać treści z wielu backendów. Na przykład:

• /static/* → źródło S3 (prywatny bucket za pośrednictwem OAC)
• /api/* → źródło ALB w us-east-1
• /media/* → źródło CDN MediaPackage do strumieniowania wideo

Każde zachowanie niezależnie konfiguruje również Viewer Protocol Policy, Allowed HTTP Methods oraz powiązania z funkcjami (CloudFront Functions lub Lambda@Edge). Dzięki temu jedna dystrybucja staje się elastyczną, wielofunkcyjną warstwą dostarczania treści.

Sprawdź swoją znajomość zagadnień AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.

W tej lekcji poznali Państwo następujące zagadnienia: zachowania pamięci podręcznej mapują wzorce ścieżek URL na źródła i reguły buforowania, minimalny, domyślny i maksymalny TTL określają, jak długo treść jest buforowana, przy czym obecne nagłówki Cache-Control ze źródła mają pierwszeństwo, a unieważnienia pamięci podręcznej natychmiast usuwają nieaktualną treść ze wszystkich lokalizacji brzegowych. Należy ograniczać liczbę elementów klucza pamięci podręcznej, aby maksymalizować współczynnik trafień. Następnie omówimy podpisane adresy URL, podpisane pliki cookie i ograniczenia geograficzne.