Firma używa CloudFront dla globalnej aplikacji webowej. Z czasem wydajność uległa pogorszeniu, a współczynnik trafień w pamięci podręcznej CloudFront stale spadał. Metryki pokazują, że niektóre adresy URL zawierają ciągi zapytań, których parametry są niespójnie uporządkowane i czasami używają liter o różnej wielkości (wielkie/małe), co zmniejsza liczbę trafień w pamięci podręcznej. Jakie działania powinien podjąć architekt rozwiązań, aby jak najszybciej zwiększyć współczynnik trafień w pamięci podręcznej?

Prawidłowa odpowiedź to wdrożenie funkcji Lambda@Edge, która normalizuje parametry ciągu zapytania poprzez sortowanie ich alfabetycznie i konwersję na małe litery. Dołączenie tej funkcji do zdarzenia CloudFront viewer request gwarantuje, że normalizacja nastąpi przed sprawdzeniem pamięci podręcznej CloudFront. Dzięki temu identyczne zapytania, różniące się jedynie kolejnością lub wielkością liter, będą traktowane jako ten sam obiekt w pamięci podręcznej, co znacząco zwiększy współczynnik trafień. Wyłączenie buforowania na podstawie parametrów ciągu zapytania (opcja 2) nie jest optymalne, ponieważ całkowicie uniemożliwi buforowanie treści dynamicznych, co negatywnie wpłynie na wydajność. Wdrożenie odwrotnego serwera proxy (opcja 3) jest rozwiązaniem bardziej złożonym i kosztownym niż Lambda@Edge, a także wprowadza dodatkowy punkt awarii. CloudFront nie oferuje wbudowanej funkcji przetwarzania ciągów zapytań bez uwzględniania wielkości liter (opcja 4), co sprawia, że ta opcja jest niemożliwa do zrealizowania bezpośrednio w konfiguracji dystrybucji.