Firma utworzyła interfejs API w Amazon API Gateway, który wywołuje funkcje Lambda i wdrożyła go na etapie produkcyjnym (Production stage). Zewnętrzny zespół programistów jest jedynym konsumentem API. W pewnych momentach występują skoki użycia, co budzi obawy dotyczące kosztów. Firma chce ograniczyć użycie i koszty bez modyfikowania funkcji Lambda. Jakie jest NAJBARDZIEJ opłacalne rozwiązanie?

Poprawna odpowiedź to utworzenie klucza API Gateway API key i planu użycia z limitami przepustowości (throttling limits) i limitami (quotas). Powiązanie planu użycia z etapem produkcyjnym i kluczem API, a następnie udostępnienie klucza zewnętrznemu zespołowi programistów. Jest to najbardziej opłacalne rozwiązanie, ponieważ API Gateway natywnie oferuje mechanizmy kontroli dostępu i ograniczania użycia (throttling) za pomocą kluczy API i planów użycia, co pozwala na zarządzanie ruchem i kosztami bez modyfikacji funkcji Lambda. Pozostałe opcje są mniej optymalne: Przekierowanie żądań do kolejek SQS i modyfikacja Lambd w celu ich odpytywania wprowadza dodatkową złożoność i wymaga zmian w kodzie Lambd, co jest sprzeczne z wymaganiem. Konfiguracja provisioned concurrency dla Lambd i Application Auto Scaling nie rozwiązuje problemu ograniczania użycia przez zewnętrznego konsumenta, a jedynie optymalizuje wydajność Lambd, co może nie zredukować kosztów, jeśli użycie jest nadmierne. Użycie AWS WAF Regional z regułą opartą na stawkach jest możliwe, ale klucze API Gateway i plany użycia są bardziej bezpośrednim i opłacalnym mechanizmem do zarządzania użyciem i kosztami na poziomie API Gateway.