Uma API REST do API Gateway invoca uma função Lambda que carrega um grande conjunto de dados de uma tabela DynamoDB durante a inicialização, causando inícios a frio (cold starts) de 8 a 10 segundos. A tabela DynamoDB usa DAX. O aplicativo experimenta respostas longas intermitentes e tem tráfego muito variável (um pico no meio do dia 10 vezes maior que o normal e uma queda no final do dia para 10% do normal). O engenheiro de DevOps deve reduzir a latência do Lambda em todos os momentos do dia. Qual solução atende ao requisito?

A simultaneidade provisionada do Lambda mantém as funções inicializadas e prontas para responder, eliminando os inícios a frio. Configurar o Application Auto Scaling para a simultaneidade provisionada permite ajustar dinamicamente o número de instâncias provisionadas com base na demanda, garantindo baixa latência mesmo com tráfego variável. Definir um mínimo de 1 assegura que sempre haverá uma instância pronta, e um máximo de 100 acomoda picos de tráfego. Habilitar a simultaneidade provisionada com valor 1 e excluir o DAX não é ideal porque o valor 1 não escalaria para picos de tráfego e remover o DAX aumentaria a latência do DynamoDB. Definir a simultaneidade reservada como 0 impediria a execução da função. Definir a simultaneidade reservada e configurar o Auto Scaling no API Gateway não resolve o problema de inícios a frio do Lambda; a simultaneidade reservada apenas garante que a função terá capacidade, mas não a mantém "quente".