Firma wynajmująca samochody zbudowała bezserwerowy interfejs API REST używany przez jej aplikację mobilną. Stos wykorzystuje Amazon API Gateway z punktem końcowym Regional, AWS Lambda i klaster Amazon Aurora MySQL Serverless DB. Po udostępnieniu dostępu partnerom, liczba żądań gwałtownie wzrosła i spowodowała sporadyczne błędy pamięci bazy danych. Logi pokazują, że wielu klientów wysyła powtarzające się żądania HTTP GET dla identycznych zapytań w krótkich odstępach czasu. Ruch jest skoncentrowany w godzinach pracy, ze szczytami w święta. Firma chce obsłużyć zwiększone obciążenie, minimalizując jednocześnie wzrost kosztów. Które podejście spełnia te wymagania?

Poprawna odpowiedź to konwersja punktu końcowego API Gateway Regional na punkt końcowy zoptymalizowany pod kątem brzegowym i włączenie buforowania. Punkt końcowy zoptymalizowany pod kątem brzegowym wykorzystuje Amazon CloudFront do buforowania odpowiedzi, co zmniejsza obciążenie API Gateway, funkcji Lambda i bazy danych. Włączenie buforowania w API Gateway dla środowiska produkcyjnego bezpośrednio adresuje problem powtarzających się zapytań HTTP GET, serwując buforowane odpowiedzi i znacząco redukując liczbę zapytań do bazy danych, co minimalizuje błędy pamięci i koszty. Wdrożenie ElastiCache for Redis jest skuteczne, ale wiąże się z większymi kosztami operacyjnymi i złożonością zarządzania niż wbudowane buforowanie API Gateway. Zwiększenie maksymalnej pamięci Aurora Serverless może rozwiązać problem błędów pamięci, ale nie optymalizuje kosztów ani nie adresuje problemu powtarzających się zapytań. Włączenie ograniczania przepustowości w API Gateway chroni system, ale odrzuca legalne żądania, pogarszając doświadczenie użytkownika, zamiast skalować usługę.