Interfejs API Gateway REST API wywołuje funkcję Lambda, która podczas inicjalizacji ładuje duży zbiór danych z tabeli DynamoDB, powodując zimne starty trwające 8–10 sekund. Tabela DynamoDB używa DAX. Aplikacja doświadcza sporadycznie długich odpowiedzi i ma bardzo zmienny ruch (szczyt w środku dnia 10 razy wyższy niż normalnie i spadek pod koniec dnia do 10% normy). Inżynier DevOps musi zmniejszyć opóźnienia Lambda o każdej porze dnia. Które rozwiązanie spełnia ten wymóg?

Poprawna odpowiedź to włączenie provisioned concurrency dla funkcji Lambda i skonfigurowanie Application Auto Scaling. Provisioned concurrency utrzymuje określoną liczbę instancji funkcji Lambda w stanie zainicjowanym i gotowym do obsługi żądań, eliminując zimne starty, które są główną przyczyną długich opóźnień. Application Auto Scaling pozwala dynamicznie dostosowywać liczbę provisioned concurrency w zależności od obciążenia, zapewniając optymalną wydajność w okresach szczytowego ruchu i minimalizując koszty w okresach niskiego obciążenia. Pozostałe opcje są nieprawidłowe: Włączenie provisioned concurrency z wartością 1 i usunięcie klastra DAX nie rozwiąże problemu zmiennego ruchu i może zwiększyć opóźnienia związane z odczytami z DynamoDB. Ustawienie reserved concurrency na 0 uniemożliwiłoby wywołanie funkcji Lambda. Ustawienie reserved concurrency i Application Auto Scaling w API Gateway nie wpływa bezpośrednio na zimne starty funkcji Lambda.