Escalabilidade da função do Lambda

Simultaneidade corresponde ao número de solicitações em andamento que a função do AWS Lambda está processando ao mesmo tempo. Para cada solicitação simultânea, o Lambda provisiona uma instância separada do seu ambiente de execução. À medida que suas funções recebem mais solicitações, o Lambda gerencia a escalabilidade do número de ambientes de execução de forma automática até atingir o limite de simultaneidade da sua conta. Por padrão, o Lambda fornece à sua conta um limite total de simultaneidade de mil execuções simultâneas para todas as funções em uma Região da AWS. Para atender às necessidades específicas da sua conta, é possível solicitar um aumento de cotas e configurar controles de simultaneidade em nível de função para que as funções essenciais não sofram controle de utilização.

Este tópico explica a simultaneidade e a escalabilidade de funções no Lambda. Ao final deste tópico, você será capaz de compreender como calcular a simultaneidade, visualizar as duas principais opções de controle de simultaneidade (reservada e provisionada), estimar as configurações apropriadas de controle de simultaneidade e visualizar métricas para otimização adicional.

Seções

• Compreender e visualizar a simultaneidade
• Como calcular a simultaneidade
• Simultaneidade em comparação com solicitações por segundo
• Simultaneidade reservada e simultaneidade provisionada
• Cotas de simultaneidade
• Configurar a simultaneidade reservada
• Configurar a simultaneidade provisionada
• Comportamento de escalabilidade do Lambda
• Monitorar a simultaneidade

Compreender e visualizar a simultaneidade

O Lambda invoca sua função em um ambiente de execução seguro e isolado. Para processar uma solicitação, o Lambda deve primeiro inicializar um ambiente de execução (a Init phase [Fase de inicialização]) antes de usá-lo para invocar sua função (a Invoke phase [Fase de invocação]):

nota

As durações reais de inicialização e invocação podem variar dependendo de diversos fatores, como o runtime escolhido e o código da função do Lambda. O diagrama anterior não pretende representar as proporções exatas das durações das fases de inicialização e de invocação.

O diagrama anterior usa um retângulo para representar um único ambiente de execução. Quando sua função recebe a primeira solicitação (representada pelo círculo amarelo com o rótulo 1), o Lambda cria um novo ambiente de execução e executa o código de forma externa ao manipulador principal durante a fase de inicialização. Em seguida, o Lambda executa o código do manipulador principal da sua função durante a fase de invocação. Durante todo esse processo, esse ambiente de execução fica ocupado e não consegue processar outras solicitações.

Quando o Lambda terminar de processar a primeira solicitação, o ambiente de execução poderá processar solicitações adicionais para a mesma função. Para solicitações subsequentes, o Lambda não precisará reinicializar o ambiente.

No diagrama anterior, o Lambda reutiliza o ambiente de execução para processar a segunda solicitação (representada pelo círculo amarelo com o rótulo 2).

Até o momento, nos concentramos em apenas uma única instância do seu ambiente de execução (ou seja, uma simultaneidade de um). Na prática, o Lambda pode precisar provisionar diversas instâncias do ambiente de execução em paralelo para processar todas as solicitações recebidas. Quando a função receber uma nova solicitação, uma das duas coisas poderá acontecer:

• Se uma instância do ambiente de execução inicializada previamente estiver disponível, o Lambda a usará para processar a solicitação.

• Caso contrário, o Lambda criará uma nova instância do ambiente de execução para processar a solicitação.

Por exemplo, vamos explorar o que acontece quando a função recebe dez solicitações:

No diagrama anterior, cada plano horizontal representa uma única instância do ambiente de execução (rotulada de A a F). Veja como o Lambda processa cada solicitação:

Comportamento do Lambda para solicitações de 1 a 10
Solicitação	Comportamento do Lambda	Reasoning
1	Provisiona novo ambiente A	Esta é a primeira solicitação; não há uma instância do ambiente de execução disponível.
2	Provisiona novo ambiente B	A instância A do ambiente de execução existente está ocupada.
3	Provisiona novo ambiente C	As instâncias A e B do ambiente de execução existente estão ambas ocupadas.
4	Provisiona novo ambiente D	As instâncias A, B e C do ambiente de execução existente estão todas ocupadas.
5	Provisiona novo ambiente E	As instâncias A, B, C e D do ambiente de execução existente estão todas ocupadas.
6	Reutiliza o ambiente A	A instância A do ambiente de execução concluiu o processamento da solicitação 1 e está disponível.
7	Reutiliza o ambiente B	A instância B do ambiente de execução concluiu o processamento da solicitação 2 e está disponível.
8	Reutiliza o ambiente C	A instância C do ambiente de execução concluiu o processamento da solicitação 3 e está disponível.
9	Provisiona novo ambiente F	As instâncias A, B, C, D e E do ambiente de execução existente estão todas ocupadas.
10	Reutiliza o ambiente D	A instância D do ambiente de execução concluiu o processamento da solicitação 4 e está disponível.

À medida que a função recebe mais solicitações simultâneas, o Lambda aumenta a escala verticalmente do número de instâncias do ambiente de execução em resposta. A animação a seguir monitora o número de solicitações simultâneas ao longo do tempo:

Ao paralisar a animação anterior em seis pontos distintos no tempo, obtemos o diagrama a seguir:

No diagrama anterior, é possível traçar uma linha vertical em qualquer ponto no tempo e contar o número de ambientes que cruzam essa linha. Isso nos fornece o número de solicitações simultâneas naquele ponto no tempo. Por exemplo, no tempo t1, existem três ambientes ativos atendendo três solicitações simultâneas. O número máximo de solicitações simultâneas nessa simulação ocorre no tempo t4, quando existem seis ambientes ativos atendendo seis solicitações simultâneas.

Para resumir, a simultaneidade da sua função corresponde ao número de solicitações simultâneas que ela está processando ao mesmo tempo. Em resposta a um aumento na simultaneidade da sua função, o Lambda provisiona mais instâncias do ambiente de execução para atender à demanda de solicitações.

Como calcular a simultaneidade

Em geral, a simultaneidade de um sistema corresponde à capacidade de processar mais de uma tarefa simultaneamente. No Lambda, simultaneidade corresponde ao número de solicitações em andamento que sua função está processando ao mesmo tempo. Uma maneira rápida e prática de medir a simultaneidade de uma função do Lambda é usar a fórmula a seguir:

Concurrency = (average requests per second) * (average request duration in seconds)

Simultaneidade é diferente de solicitações por segundo. Por exemplo, suponha que a função receba 100 solicitações por segundo em média. Se a duração média da solicitação for de um segundo, é verdade que a simultaneidade também será cem:

Concurrency = (100 requests/second) * (1 second/request) = 100

No entanto, se a duração média da solicitação for de 500 ms, a simultaneidade será 50:

Concurrency = (100 requests/second) * (0.5 second/request) = 50

Na prática, o que significa uma simultaneidade de 50? Se a duração média da solicitação for de 500 ms, você pode pensar em uma instância da função que é capaz de processar duas solicitações por segundo. Ou seja, são necessárias 50 instâncias da função para processar uma carga de 100 solicitações por segundo. Uma simultaneidade de 50 significa que o Lambda deve provisionar 50 instâncias de ambiente de execução para processar essa workload com eficiência sem qualquer controle de utilização. Veja como expressar isso em forma de equação:

Concurrency = (100 requests/second) / (2 requests/second) = 50

Se a função receber o dobro do número de solicitações (200 solicitações por segundo), mas requerer apenas metade do tempo para processar cada uma (250 ms), a simultaneidade ainda será 50:

Concurrency = (200 requests/second) * (0.25 second/request) = 50

Teste sua compreensão sobre simultaneidade

Suponha que você tenha uma função que demora, em média, 200 ms para ser executada. Durante o pico de carga, você observa 5 mil solicitações por segundo. Qual será a simultaneidade da sua função durante o pico de carga?

Resposta

A duração média da função é de 200 ms, ou 0,2 segundo. Usando a fórmula da simultaneidade, é possível inserir os números para obter uma simultaneidade de mil:

Concurrency = (5,000 requests/second) * (0.2 seconds/request) = 1,000

Como alternativa, uma duração média da função de 200 ms significa que sua função pode processar 5 solicitações por segundo. Para lidar com a workload de 5 mil solicitações por segundo, você precisará de 1 mil instâncias do ambiente de execução. Portanto, a simultaneidade será 1 mil:

Concurrency = (5,000 requests/second) / (5 requests/second) = 1,000

Simultaneidade em comparação com solicitações por segundo

Conforme mencionado na seção anterior, simultaneidade é diferente de solicitações por segundo. Essa é uma distinção especialmente importante a ser feita no trabalho com funções que têm uma duração média de solicitação inferior a 100 ms.

Em geral, cada instância do ambiente de execução pode processar no máximo dez solicitações por segundo. Esse limite se aplica às funções síncronas sob demanda, bem como às funções que usam simultaneidade provisionada. Se você não conhece esse limite, é possível que não saiba porque as funções podem apresentar controle de utilização em determinados cenários.

Por exemplo, considere uma função com uma duração média de solicitação de 50 ms. Com 200 solicitações por segundo, veja a simultaneidade dessa função:

Concurrency = (200 requests/second) * (0.05 second/request) = 10

Com base nesse resultado, você pode achar que precisa de apenas dez instâncias do ambiente de execução para processar essa carga. No entanto, cada ambiente de execução pode processar apenas  dez execuções por segundo. Isso significa que, com dez ambientes de execução, você só pode lidar com cem solicitações por segundo do total de 200 solicitações. Essa função sofre controle de utilização.

A lição é que você precisa considerar a simultaneidade e as solicitações por segundo ao definir as configurações de simultaneidade para as funções. Nesse caso, você precisa de 20 ambientes de execução para a função, mesmo que ela tenha apenas uma simultaneidade de dez.

Teste sua compreensão da simultaneidade (funções abaixo de 100 ms)

Suponha que você tenha uma função que demora, em média, 20 ms para ser executada. Durante o pico de carga, você observa 3 mil solicitações por segundo. Qual será a simultaneidade da sua função durante o pico de carga?

Resposta

A duração média da função é de 20 ms ou 0,02 segundo. Usando a fórmula da simultaneidade, é possível inserir os números para obter uma simultaneidade de 60:

Concurrency = (3,000 requests/second) * (0.02 seconds/request) = 60

No entanto, cada ambiente de execução pode processar apenas  dez solicitações por segundo. Com 60 ambientes de execução, a função pode processar no máximo 600 solicitações por segundo. Para acomodar totalmente as três mil solicitações, você precisará de pelo menos 300 instâncias do ambiente de execução.

Simultaneidade reservada e simultaneidade provisionada

Por padrão, sua conta tem um limite de simultaneidade de mil execuções simultâneas para todas as funções em uma região. Suas funções compartilham esse grupo de mil para simultaneidade sob demanda. Suas funções poderão apresentar controle de utilização (ou seja, começarem a descartar solicitações) se a simultaneidade disponível for esgotada.

Algumas de suas funções podem ser mais essenciais do que outras. Como resultado, talvez seja necessário definir as configurações de simultaneidade para garantir que as funções essenciais obtenham a simultaneidade de que precisam. Existem dois tipos de controle de simultaneidade disponíveis: simultaneidade reservada e simultaneidade provisionada.

• Use a simultaneidade reservada para reservar uma parte da simultaneidade de sua conta para uma função. Isso é útil se você não deseja que outras funções ocupem toda a simultaneidade não reservada disponível.

• Use a simultaneidade provisionada para inicializar previamente diversas instâncias de ambiente para uma função. Isso é útil para reduzir as latências de inicialização a frio.

Simultaneidade reservada

Se você deseja garantir que uma determinada quantidade de simultaneidade esteja disponível para sua função a qualquer momento, use a simultaneidade reservada.

A simultaneidade reservada corresponde ao número máximo de instâncias simultâneas que você deseja alocar para a função. Quando você dedica uma simultaneidade reservada para uma função, nenhuma outra função pode usar essa simultaneidade. Em outras palavras, definir a simultaneidade reservada pode afetar o grupo de simultaneidade disponível para outras funções. As funções que não têm simultaneidade reservada compartilham o grupo restante de simultaneidade não reservada.

A configuração da simultaneidade reservada é contabilizada para o limite geral de simultaneidade da sua conta. Não há cobrança para configurar a simultaneidade reservada para uma função.

Para compreender melhor a simultaneidade reservada, considere o diagrama a seguir:

Neste diagrama, o limite de simultaneidade da sua conta para todas as funções nesta região está no limite padrão de mil. Suponha que você tenha duas funções essenciais, function-blue e function-orange, que rotineiramente espera obter altos volumes de invocação. Você decide oferecer 400 unidades de simultaneidade reservada para function-blue e 400 unidades de simultaneidade reservada para function-orange. Neste exemplo, todas as outras funções em sua conta devem compartilhar as 200 unidades restantes de simultaneidade não reservada.

O diagrama tem cinco pontos de interesse:

• Em t1, tanto function-orange quanto function-blue começam a receber solicitações. Cada função começa a usar sua parte alocada das unidades de simultaneidade reservadas.

• Em t2, function-orange e function-blue, elas estão recebendo constantemente mais solicitações. Ao mesmo tempo, você implanta algumas outras funções do Lambda, que começam a receber solicitações. Você não precisa alocar simultaneidade reservada para as outras funções. Elas começam a usar as 200 unidades restantes de simultaneidade não reservada.

• Em t3, function-orange atinge a simultaneidade máxima de 400. Embora haja simultaneidade não utilizada em outras partes da sua conta, function-orange não consegue acessá-la. A linha vermelha indica que function-orange está passando por um controle de utilização e o Lambda pode descartar solicitações.

• Em t4, function-orange começa a receber menos solicitações e não está mais sob o controle de utilização. No entanto, suas outras funções experimentam um aumento no tráfego e começam a sofrer o controle de utilização. Embora haja simultaneidade não utilizada em outras partes da sua conta, essas outras funções não conseguem acessá-la. A linha vermelha indica que suas outras funções estão passando pelo controle de utilização.

• Em t5, as outras funções começam a receber menos solicitações e não estão mais sob o controle de utilização.

Com base neste exemplo, observe que a reserva de simultaneidade tem os efeitos a seguir:

• Sua função pode ser escalada independentemente de outras funções em sua conta. Todas as funções da sua conta na mesma região que não têm simultaneidade reservada compartilham o grupo de simultaneidade não reservada. Sem a simultaneidade reservada, as outras funções podem potencialmente usar toda a simultaneidade disponível. Isso evita que funções essenciais aumentem a escala verticalmente, se necessário.

• Sua função não pode ser escalada para além do controle. A simultaneidade reservada limita a simultaneidade máxima da sua função. Isso significa que a função não pode usar a simultaneidade reservada para outras funções ou usar a simultaneidade do grupo não reservado. É possível reservar a simultaneidade para evitar que a função use toda a simultaneidade disponível em sua conta ou sobrecarregue os recursos downstream.

• Talvez você não consiga usar toda a simultaneidade disponível em sua conta. A reserva de simultaneidade é contabilizada para o limite de simultaneidade da sua conta, mas isso também significa que outras funções não podem usar essa parte da simultaneidade reservada. Se a função não usar toda a simultaneidade reservada para ela, você estará efetivamente desperdiçando essa simultaneidade. Isso não é um problema, caso outras funções em sua conta possam se beneficiar da simultaneidade desperdiçada.

Para saber como gerenciar as configurações de simultaneidade reservada das funções, consulte Configurar a simultaneidade reservada.

Simultaneidade provisionada

Você usa a simultaneidade reservada para definir o número máximo de ambientes de execução reservados para uma função do Lambda. No entanto, nenhum desses ambientes está inicializado previamente. Como resultado, as invocações da sua função podem demorar mais porque o Lambda deve primeiro inicializar o novo ambiente antes de poder usá-lo para invocar a função. Quando o Lambda precisa inicializar um ambiente novo para realizar uma invocação, isso é conhecido como inicialização a frio. Para mitigar as inicializações a frio, é possível usar a simultaneidade provisionada.

A simultaneidade provisionada corresponde ao número de ambientes de execução inicializados previamente que você deseja alocar para a função. Se você definir a simultaneidade provisionada em uma função, o Lambda inicializará esse número de ambientes de execução para que estejam preparados para responder imediatamente às solicitações da função.

nota

O uso de simultaneidade provisionada gera cobranças na sua conta. Se você estiver trabalhando com os tempos de execução Java 11 ou Java 17, você também pode usar o SnapStart Lambda para mitigar problemas de inicialização a frio sem custo adicional. SnapStart usa instantâneos em cache do seu ambiente de execução para melhorar significativamente o desempenho da inicialização. Você não pode usar ambas SnapStart e a simultaneidade provisionada na mesma versão da função. Para obter mais informações sobre SnapStart recursos, limitações e regiões suportadas, consulteMelhorando o desempenho da startup com o Lambda SnapStart.

Ao usar a simultaneidade provisionada, o Lambda ainda recicla os ambientes de execução em segundo plano. No entanto, a qualquer momento, o Lambda garantirá que o número de ambientes inicializados previamente seja semelhante ao valor da configuração de simultaneidade provisionada da sua função. Esse comportamento difere da simultaneidade reservada, na qual o Lambda pode encerrar completamente um ambiente após um período de inatividade. O diagrama a seguir ilustra isso comparando o ciclo de vida de um único ambiente de execução quando você configura a função usando a simultaneidade reservada em comparação com a simultaneidade provisionada.

O diagrama tem quatro pontos de interesse:

Time	Simultaneidade reservada	Simultaneidade provisionada
t1	Nada acontece.	O Lambda inicializa previamente uma instância do ambiente de execução.
t2	A solicitação 1 é realizada. O Lambda deverá inicializar uma nova instância do ambiente de execução.	A solicitação 1 é realizada. O Lambda usa a instância do ambiente inicializada previamente.
t3	Após algum período de inatividade, o Lambda encerra a instância ativa do ambiente.	Nada acontece.
t4	A solicitação 2 é realizada. O Lambda deverá inicializar uma nova instância do ambiente de execução.	A solicitação 2 é realizada. O Lambda usa a instância do ambiente inicializada previamente.

Para compreender melhor a simultaneidade provisionada, considere o diagrama a seguir:

Neste diagrama, você tem um limite de simultaneidade de mil na conta. Você decide fornecer 400 unidades de simultaneidade provisionada para function-orange. Todas as funções em sua conta, incluindo function-orange, podem usar as 600 unidades restantes de simultaneidade não reservada.

O diagrama tem cinco pontos de interesse:

• Em t1, function-orange começa a receber solicitações. Como o Lambda inicializou previamente 400 instâncias do ambiente de execução, está tudo pronto para a invocação imediata de function-orange.

• Em t2, function-orange atinge 400 solicitações simultâneas. Como resultado, function-orange não é executada com simultaneidade provisionada. No entanto, como ainda há simultaneidade não reservada disponível, o Lambda pode usar isso para lidar com solicitações adicionais da function-orange (não há controle de utilização). O Lambda deve criar novas instâncias para atender a essas solicitações e sua função pode apresentar latências de inicialização a frio.

• Em t3, function-orange retorna para 400 solicitações simultâneas após um breve pico no tráfego. O Lambda é novamente capaz de processar todas as solicitações sem latências de inicialização a frio.

• Em t4, as funções da conta sofrem um pico de tráfego. Esse pico pode ser consequência da function-orange ou de qualquer outra função em sua conta. O Lambda usa simultaneidade não reservada para processar essas solicitações.

• Em t5, as funções em sua conta atingem o limite máximo de simultaneidade de mil e sofrem controle de utilização.

O exemplo anterior considerou apenas a simultaneidade provisionada. Na prática, é possível definir a simultaneidade provisionada e a simultaneidade reservada em uma função. Será possível fazer isso se você tiver uma função que processa uma carga consistente de invocações durante a semana, mas rotineiramente apresenta picos de tráfego nos finais de semana. Nesse caso, você pode usar a simultaneidade provisionada para definir uma quantidade de linha de base de ambientes para processar as solicitações durante a semana e usar a simultaneidade reservada para processar os picos no final de semana. Considere o diagrama a seguir:

Neste diagrama, suponha que você configure 200 unidades de simultaneidade provisionada e 400 unidades de simultaneidade reservada para function-orange. Como você configurou a simultaneidade reservada, function-orange não pode usar nenhuma das 600 unidades de simultaneidade não reservada.

Este diagrama tem cinco pontos de interesse:

• Em t1, function-orange começa a receber solicitações. Como o Lambda inicializou previamente 200 instâncias do ambiente de execução, está tudo pronto para a invocação imediata de function-orange.

• Em t2, function-orange usa toda a simultaneidade provisionada. function-orange pode continuar atendendo a solicitações usando simultaneidade reservada, mas essas solicitações podem apresentar latências de inicialização a frio.

• Em t3, function-orange atinge 400 solicitações simultâneas. Como resultado, function-orange usa toda a simultaneidade reservada. Como function-orange não pode usar a simultaneidade não reservada, as solicitações começam a sofrer controle de utilização.

• Em t4, function-orange começa a receber menos solicitações e não está mais sob o controle de utilização.

• Em t5, function-orange diminui para 200 solicitações simultâneas, portanto, todas as solicitações podem novamente usar a simultaneidade provisionada (ou seja, sem latências de inicialização a frio).

Tanto a simultaneidade reservada quanto a provisionada são contabilizadas para o limite de simultaneidade da sua conta e cotas regionais. Em outras palavras, alocar a simultaneidade reservada e a provisionada pode afetar o grupo de simultaneidade disponível para outras funções. A configuração da simultaneidade provisionada gera cobranças em sua conta da Conta da AWS.

nota

Se a quantidade de simultaneidade provisionada nas versões e aliases de uma função se somar à simultaneidade reservada da função, todas as invocações serão executadas na simultaneidade provisionada. Essa configuração também tem o efeito de controlar a utilização da versão não publicada da função ($LATEST), o que impede que ela seja executada. Não é possível alocar mais simultaneidade provisionada do que a simultaneidade reservada para uma função.

Para gerenciar as configurações de simultaneidade provisionada para as funções, consulte Configurar a simultaneidade provisionada. Para automatizar a escalabilidade da simultaneidade provisionada com base em uma programação ou utilização de aplicações, consulte Gerenciar a escalabilidade provisionada com o Application Auto Scaling.

Como o Lambda aloca a simultaneidade provisionada

A simultaneidade provisionada não fica online imediatamente depois que você a configura. O Lambda começa a alocar a simultaneidade provisionada após um ou dois minutos de preparação. Em particular, o Lambda pode provisionar entre 500 e 3.000 ambientes de execução de uma vez, dependendo da região. Após essa intermitência inicial, o Lambda aloca 500 ambientes adicionais por minuto, independentemente da região, até que a solicitação seja atendida.

Por exemplo, suponha que o limite de simultaneidade da sua conta seja 10 mil. Além disso, suponha que às 10h no Leste dos EUA (Norte da Virgínia), você configure 5 mil unidades de simultaneidade provisionada para uma função. Veja como o Lambda pode alocar unidades de simultaneidade provisionada:

No diagrama anterior:

• Inicialmente, o Lambda pode provisionar no máximo 3 mil ambientes de execução, já que o limite inicial de simultaneidade de intermitência no Leste dos EUA (Norte da Virgínia) é de 3 mil.

• Às 10h: você solicita 5 mil unidades de simultaneidade provisionada para essa função. O Lambda não começa a provisionar ambientes de execução instantaneamente.

• Às 10h01: o Lambda começa provisionando 3 mil ambientes.

• De 10h02 até 10h05: o Lambda fornece 500 ambientes adicionais a cada minuto. Às 10h05, o Lambda termina de alocar 5 mil ambientes para sua função.

Quando você envia uma solicitação para alocar a simultaneidade provisionada, não pode acessar qualquer um desses ambientes até que o Lambda termine de alocá-los. Por exemplo: no cenário anterior, nenhuma das suas solicitações pode usar a simultaneidade provisionada até as 10h05, pois é nesse instante que o Lambda termina de alocar sua solicitação de 5 mil ambientes de execução.

Comparação entre a simultaneidade reservada e a simultaneidade provisionada

A tabela a seguir resume e compara as simultaneidades reservada e provisionada.

Tópico	Simultaneidade reservada	Simultaneidade provisionada
Definição	Número máximo de instâncias do ambiente de execução para a função.	Defina o número de instâncias do ambiente de execução pré-provisionadas para a função.
Comportamento de provisionamento	O Lambda provisiona novas instâncias sob demanda.	O Lambda provisiona as instâncias previamente (ou seja, antes que a função comece a receber solicitações).
Comportamento de inicialização a frio	Possibilidade de latência de inicialização a frio, pois o Lambda precisa criar novas instâncias sob demanda.	Não há latência de inicialização a frio, pois o Lambda não precisa criar instâncias sob demanda.
Comportamento de controle de utilização	Função sofre controle de utilização quando o limite de simultaneidade reservada é atingido.	Se a simultaneidade reservada não estiver definida: a função usará a simultaneidade não reservada quando o limite de simultaneidade provisionada for atingido. Se a simultaneidade reservada estiver definida: a função sofrerá controle de utilização quando o limite de simultaneidade reservada for atingido.
Comportamento padrão, se não for definido	A função usa a simultaneidade não reservada disponível em sua conta.	O Lambda não provisiona previamente nenhuma instância. Em vez disso, se a simultaneidade reservada não estiver definida: a função usará a simultaneidade não reservada disponível em sua conta. Se a simultaneidade reservada estiver definida: a função usará a simultaneidade reservada.
Definição de preço	Sem custos adicionais.	Incorre em custos adicionais.

Cotas de simultaneidade

O Lambda define cotas para a quantidade total de simultaneidade que é possível usar em todas as funções de uma região. Essas cotas existem em dois níveis:

• Em nível de conta, suas funções podem ter até mil unidades de simultaneidade por padrão. Para aumentar esse limite, consulte Requesting a quota increase (Como solicitar um aumento de cota) no Guia do usuário do Service Quotas.

• Em nível de função, é possível reservar até 900 unidades de simultaneidade para todas as funções por padrão. Independentemente do limite total de simultaneidade da conta, o Lambda sempre reserva cem unidades de simultaneidade para suas funções que não reservam explicitamente a simultaneidade. Por exemplo, se você aumentou o limite de simultaneidade da sua conta para 2 mil, poderá reservar até 1,9 mil unidades de simultaneidade em nível de função.

Para verificar sua cota atual de simultaneidade no nível da conta, use a AWS Command Line Interface (AWS CLI) para executar o seguinte comando:

aws lambda get-account-settings

Você observará um resultado parecido com o seguinte:

{
    "AccountLimit": {
        "TotalCodeSize": 80530636800,
        "CodeSizeUnzipped": 262144000,
        "CodeSizeZipped": 52428800,
        "ConcurrentExecutions": 1000,
        "UnreservedConcurrentExecutions": 900
    },
    "AccountUsage": {
        "TotalCodeSize": 410759889,
        "FunctionCount": 8
    }
}

ConcurrentExecutions é sua cota total de simultaneidade no nível da conta. UnreservedConcurrentExecutions é a quantidade de simultaneidade reservada que você ainda pode alocar para suas funções.

À medida que sua função recebe mais solicitações, o Lambda aumenta automaticamente a escala do número de ambientes de execução para processar essas solicitações até que seja atingido o limite de simultaneidade da sua conta. No entanto, para evitar que o limite de escalabilidade seja ultrapassado em resposta a picos repentinos de tráfego, o Lambda limita a velocidade do ajuste de escala das funções. Essa taxa de escalabilidade de simultaneidade é a taxa máxima na qual as funções em sua conta podem ser escaladas em resposta ao aumento de solicitações. Ou seja, a velocidade com que o Lambda é capaz de criar novos ambientes de execução. A taxa de escalabilidade de simultaneidade difere do limite de simultaneidade no nível da conta, que é a quantidade total de simultaneidade disponível para suas funções.

Em cada Região da AWS, e para cada função, sua taxa de escalabilidade de simultaneidade é de mil instâncias de ambiente de execução a cada dez segundos. Em outras palavras, a cada dez segundos, o Lambda pode alocar no máximo mil instâncias adicionais de ambiente de execução para cada uma das suas funções.

Normalmente, você não precisa se preocupar com esse limite. A taxa de escalabilidade do Lambda é suficiente para a maioria dos casos de uso.

É importante ressaltar que a taxa de escalabilidade de simultaneidade é um limite no nível da função. Isso significa que cada função da sua conta pode ajustar a escala independentemente de outras funções.

Para obter mais informações sobre comportamentos de escalabilidade, consulte Comportamento de escalabilidade do Lambda.