# Como entender a 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](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-concurrency-limit-increase/) 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 conceitos de simultaneidade e 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. **Topics** + [ ## Compreender e visualizar a simultaneidade ](#understanding-concurrency) + [ ## Calcular a simultaneidade para uma função ](#calculating-concurrency) + [ ## Compreender a simultaneidade reservada e a simultaneidade provisionada ](#reserved-and-provisioned) + [ ## Entender simultaneidade e solicitações por segundo ](#concurrency-vs-requests-per-second) + [ ## Cotas de simultaneidade ](#concurrency-quotas) + [ # Configurar a simultaneidade reservada para uma função ](configuration-concurrency.md) + [ # Configurar a simultaneidade provisionada para uma função ](provisioned-concurrency.md) + [ # Comportamento de escalabilidade do Lambda ](scaling-behavior.md) + [ # Monitorar a simultaneidade ](monitoring-concurrency.md) ## Compreender e visualizar a simultaneidade O Lambda invoca sua função em um [ambiente de execução](lambda-runtime-environment.md) seguro e isolado. Para processar uma solicitação, o Lambda deve primeiro inicializar um ambiente de execução (a [Init phase](lambda-runtime-environment.md#runtimes-lifecycle-ib) [Fase de inicialização]) antes de usá-lo para invocar sua função (a [Invoke phase](lambda-runtime-environment.md#runtimes-lifecycle-invoke) [Fase de invocação]): ![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/concurrency-1-environment.png) **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. ![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/concurrency-2-two-requests.png) 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: ![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/concurrency-3-ten-requests.png) 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: | 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: ![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/concurrency-4-animation.gif) Ao paralisar a animação anterior em seis pontos distintos no tempo, obtemos o diagrama a seguir: ![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/concurrency-5-animation-summary.png) 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. ## Calcular a simultaneidade para uma função 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 ``` ## Compreender a simultaneidade reservada e a 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 sofrerão controle de utilização (ou seja, começarão a rejeitar solicitações) caso se esgote a capacidade de simultaneidade disponível. 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 definir o número máximo e mínimo de instâncias simultâneas para reservar uma parte da simultaneidade da 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. Quando uma função tem simultaneidade reservada, nenhuma outra função pode usar essa simultaneidade. + 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 define o número máximo e mínimo 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: ![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/concurrency-6-reserved-concurrency.png) 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 e mínima da 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. Além disso, a simultaneidade reservada atua como um limite máximo e mínimo: ela reserva a capacidade especificada exclusivamente para a função e, ao mesmo tempo, impede que ela ultrapasse esse limite. É 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 para uma função](configuration-concurrency.md). ### 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 [início a frio](lambda-runtime-environment.md#cold-start-latency). 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 runtimes do Java 11 ou do Java 17, também poderá usar o Lambda SnapStart para mitigar problemas de inicialização a frio sem custo adicional. O SnapStart usa snapshots em cache do ambiente de execução para melhorar significativamente o desempenho de inicialização. Você não pode usar o SnapStart e a simultaneidade provisionada na mesma versão da função. Para obter mais informações sobre os recursos, limitações e regiões compatíveis com o SnapStart, consulte [Aprimoramento da performance de inicialização com o Lambda SnapStart](snapstart.md). Ao usar a simultaneidade provisionada, o Lambda ainda recicla os ambientes de execução em segundo plano. Por exemplo, isso pode ocorrer [após uma falha de invocação](lambda-runtime-environment.md#runtimes-lifecycle-invoke-with-errors). 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. É importante ressaltar que, mesmo se você estiver usando a simultaneidade provisionada, ainda poderá enfrentar um atraso no início a frio se o Lambda tiver que redefinir o ambiente de execução. Por outro lado, ao usar simultaneidade reservada, 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. ![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/concurrency-7-reserved-vs-provisioned.png) O diagrama tem quatro pontos de interesse: | Hora | 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: ![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/concurrency-8-provisioned-concurrency.png) 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: ![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/concurrency-9-reserved-and-provisioned.png) 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](gettingstarted-limits.md). 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 uma função](provisioned-concurrency.md). Para automatizar a escalabilidade da simultaneidade provisionada com base em uma programação ou utilização de aplicações, consulte [Usar o ajuste de escala automático de aplicações para automatizar o gerenciamento da simultaneidade provisionada](provisioned-concurrency.md#managing-provisioned-concurency). ### 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. Para cada função, o Lambda pode provisionar até 6 mil ambientes de execução a cada minuto, independentemente da Região da AWS. Isso é exatamente igual à [taxa de escalabilidade de simultaneidade](scaling-behavior.md#scaling-rate) para funções. 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, se você solicitar 5 mil simultaneidades provisionadas, nenhuma das suas solicitações poderá usar a simultaneidade provisionada até que o Lambda conclua a alocação total dos 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. | | Preços | Sem custos adicionais. | Incorre em custos adicionais. | ## Entender simultaneidade e 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 todas as funções da sua conta, o Lambda impõe um limite de solicitações por segundo que é igual a dez vezes a simultaneidade da sua conta. Por exemplo, como o limite padrão de simultaneidade da conta é 1.000, as funções da sua conta podem lidar com, no máximo, 10.000 solicitações por segundo. Por exemplo, considere uma função com uma duração média de solicitação de 50 ms. Com 20.000 solicitações por segundo, esta é a simultaneidade dessa função: ``` Concurrency = (20,000 requests/second) * (0.05 second/request) = 1,000 ``` Com base nesse resultado, você poderia esperar que o limite de 1.000 para a simultaneidade da conta fosse suficiente para processar essa carga. Porém, como o limite é de 10.000 solicitações por segundo, a função só pode lidar com 10.000 solicitações por segundo do total de 20.000 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 solicitar um aumento do limite de simultaneidade da conta para 2 mil, pois isso aumentaria o limite total de solicitações por segundo para 20 mil. **nota** Com base nesse limite de solicitações por segundo, é incorreto dizer que cada ambiente de execução do Lambda só pode lidar com até 10 solicitações por segundo. Em vez de observar a carga em cada ambiente de execução individual, o Lambda considera apenas a simultaneidade geral e as solicitações gerais por segundo ao calcular suas cotas. ### 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 30.000 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 600: ``` Concurrency = (30,000 requests/second) * (0.02 seconds/request) = 600 ``` Por padrão, o limite de simultaneidade de 1.000 da conta parece suficiente para lidar com essa carga. Porém, o limite de 10.000 solicitações por segundo não é suficiente para lidar com as 30.000 solicitações recebidas por segundo. Para acomodar todas as 30.000 solicitações, você precisa solicitar um aumento do limite de simultaneidade da conta para 3.000 ou mais. O limite de solicitações por segundo se aplica a todas as cotas do Lambda que envolvem simultaneidade. Em outras palavras, ele se aplica às funções sob demanda síncronas, às funções que usam simultaneidade provisionada e ao [comportamento de escalação de simultaneidade](scaling-behavior.md). Por exemplo, aqui estão alguns cenários em que você deve considerar cuidadosamente os limites de simultaneidade e de solicitações por segundo: + Uma função que usa simultaneidade sob demanda pode experimentar um aumento contínuo de 500 simultaneidades a cada 10 segundos ou de 5.000 solicitações por segundo a cada 10 segundos, o que ocorrer primeiro. + Suponha que você tenha uma função que tenha uma alocação de simultaneidade provisionada de 10. Essa função passa para a simultaneidade sob demanda após 10 simultaneidades ou 100 solicitações por segundo, o que ocorrer primeiro. ## 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](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) (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. + Tanto no nível da conta quanto no nível da função, o Lambda também impõe um limite de solicitações por segundo igual a dez vezes a cota de simultaneidade correspondente. Por exemplo, isso se aplica a simultaneidade no nível de conta, a funções que usam simultaneidade sob demanda, a funções que usam simultaneidade provisionada e ao [comportamento de escalação de simultaneidade](scaling-behavior.md). Para obter mais informações, consulte [Entender simultaneidade e solicitações por segundo](#concurrency-vs-requests-per-second). 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 da conta podem reduzir a escala horizontalmente 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, a taxa de escalação de simultaneidade é de 1.000 instâncias do ambiente de execução a cada 10 segundos (ou 10.000 solicitações por segundo a cada 10 segundos).** Em outras palavras, a cada 10 segundos, o Lambda pode alocar no máximo 1.000 instâncias do ambiente de execução ou aceitar mais 10.000 solicitações por segundo para cada uma das 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 aplicado por 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](scaling-behavior.md). # Configurar a simultaneidade reservada para uma função No Lambda, [simultaneidade](lambda-concurrency.md) corresponde ao número de solicitações em andamento que a função está processando, no momento. Há dois tipos de controle de simultaneidade disponíveis: + Simultaneidade reservada: isso define o número máximo e mínimo de instâncias simultâneas alocadas à função. Quando uma função tem simultaneidade reservada, nenhuma outra função pode usar essa simultaneidade. A simultaneidade reservada é útil para garantir que suas funções mais críticas sempre tenham simultaneidade suficiente para lidar com as solicitações recebidas. Além disso, a simultaneidade reservada pode ser usada para limitar a simultaneidade e evitar a sobrecarga dos recursos subsequentes, como as conexões de banco de dados. A simultaneidade reservada atua como limite inferior e superior: ela reserva a capacidade especificada exclusivamente para a função e, ao mesmo tempo, impede que ela ultrapasse esse limite. Configurar a simultaneidade reservada para uma função não acarreta cobranças adicionais. + Simultaneidade provisionada: é o número de ambientes de execução inicializados previamente alocados para a função. Esses ambientes de execução estão prontos para responder imediatamente às solicitações de função de entrada. A simultaneidade provisionada é útil para reduzir as latências de inicialização a frio das funções e foi criada para tornar as funções disponíveis com tempos de resposta na ordem das dezenas de milissegundos. Geralmente, as workloads interativas são as que mais se beneficiam do recurso. São aplicações em que os usuários iniciam solicitações, como aplicações móveis e da Web, e que são mais sensíveis à latência. As workloads assíncronas, como pipelines de processamento de dados, costumam ser menos sensíveis à latência e, portanto, geralmente não precisam de simultaneidade provisionada. A configuração da simultaneidade provisionada gera cobranças na sua Conta da AWS. Este tópico detalha como gerenciar e configurar a simultaneidade reservada. Para uma visão geral conceitual desses dois tipos de controles de simultaneidade, consulte [Simultaneidade reservada e  simultaneidade provisionada](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#reserved-and-provisioned). Para obter informações, sobre a configuração da simultaneidade provisionada, consulte [Configurar a simultaneidade provisionada para uma função](provisioned-concurrency.md). **nota** As funções do Lambda vinculadas a um mapeamento da origem do evento do Amazon MQ têm uma simultaneidade máxima padrão. Para o Apache Active MQ, o número máximo de instâncias simultâneas é 5. Para o Rabbit MQ, o número máximo de instâncias simultâneas é 1. Definir a simultaneidade reservada ou provisionada para a função não altera esses limites. Para solicitar um aumento na simultaneidade máxima padrão ao usar o Amazon MQ, entre em contato com Suporte. **Topics** + [ ## Configurar a simultaneidade reservada ](#configuring-concurrency-reserved) + [ ## Estimar com precisão a simultaneidade reservada necessária para uma função ](#estimating-reserved-concurrency) ## Configurar a simultaneidade reservada Você pode definir configurações de simultaneidade reservada para uma função usando o console do Lambda ou a API do Lambda. **Para reservar simultaneidade para uma função (console)** 1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda. 1. Escolha a função para a qual você deseja reservar a simultaneidade. 1. Escolha **Configuration (Configuração)** e escolha **(Concurrency (Simultaneidade)**. 1. Em **Concurrency (Simultaneidade)**, selecione **Edit (Editar)**. 1. Selecione **Reserve concurrency (Reservar simultaneidade)**. Insira a quantidade de simultaneidade para reservar para a função. 1. Escolha **Salvar**. Você pode reservar até o valor da **simultaneidade da conta não reservada** menos 100. As 100 unidades restantes de simultaneidade se destinam a funções que não estão usando simultaneidade reservada. Por exemplo, se sua conta tiver um limite de simultaneidade de 1 mil, você não poderá reservar todas as 1 mil unidades de simultaneidade para uma única função. ![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/concurrency-reserve-over-limit.png) Reservar simultaneidade para uma função afeta o grupo de simultaneidades disponíveis para outras funções. Por exemplo, se você reservar 100 unidades de simultaneidade para `function-a`, outras funções da sua conta deverão compartilhar as 900 unidades restantes de simultaneidade, mesmo que `function-a` não use todas as 100 unidades de simultaneidade reservadas. Para controlar intencionalmente a utilização de uma função, defina a simultaneidade reservada como zero. Isso impede que sua função processe todos os eventos até que você remova o limite. Para configurar a simultaneidade reservada com a API do Lambda, use as operações da API a seguir. + [PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html) + [GetFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConcurrency.html) + [DeleteFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionConcurrency.html) Por exemplo, para configurar a simultaneidade reservada com a AWS Command Line Interface (CLI), use o comando `put-function-concurrency`. O comando a seguir reserva 100 unidades de simultaneidade para uma função denominada `my-function`: ``` aws lambda put-function-concurrency --function-name my-function \ --reserved-concurrent-executions 100 ``` Você observará um resultado parecido com o seguinte: ``` { "ReservedConcurrentExecutions": 100 } ``` ## Estimar com precisão a simultaneidade reservada necessária para uma função Se sua função estiver atendendo a tráfego no momento, você poderá visualizar facilmente as métricas de simultaneidade usando as [métricas do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html). Especificamente, a métrica `ConcurrentExecutions` apresenta o número de invocações simultâneas para cada função em sua conta. ![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/concurrency-concurrent-executions-metrics.png) O gráfico anterior sugere que essa função atende a uma média de cinco a dez solicitações simultâneas e atinge o pico de 20 solicitações em um dia típico. Suponha que existam muitas outras funções na sua conta. ** Se essa função for essencial para sua aplicação e você não desejar descartar solicitação alguma**, use um número maior ou igual a 20 como sua definição de simultaneidade reservada. Com alternativa, lembre-se de que você também pode [calcular a simultaneidade](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#calculating-concurrency) usando a fórmula a seguir: ``` Concurrency = (average requests per second) * (average request duration in seconds) ``` Multiplicar a média de solicitações por segundo pela duração média da solicitação em segundos fornece uma estimativa aproximada do quanto de simultaneidade você precisa reservar. É possível estimar a média de solicitações por segundo usando a métrica `Invocation` e a duração média da solicitação em segundos usando a métrica `Duration`. Consulte [Uso de métricas do CloudWatch com o Lambda](monitoring-metrics.md) para obter mais detalhes. Você deve se familiarizar também com as restrições de throughput upstream e downstream. Embora as funções do Lambda sejam dimensionadas perfeitamente com a carga, as dependências de upstream e downstream talvez não tenham os mesmos recursos de throughput. Se você precisar limitar até que ponto a função pode ser escalada, configure simultaneidade reservada na função. # Configurar a simultaneidade provisionada para uma função No Lambda, [simultaneidade](lambda-concurrency.md) corresponde ao número de solicitações em andamento que a função está processando, no momento. Há dois tipos de controle de simultaneidade disponíveis: + Simultaneidade reservada: isso define o número máximo e mínimo de instâncias simultâneas alocadas à função. Quando uma função tem simultaneidade reservada, nenhuma outra função pode usar essa simultaneidade. A simultaneidade reservada é útil para garantir que suas funções mais críticas sempre tenham simultaneidade suficiente para lidar com as solicitações recebidas. Além disso, a simultaneidade reservada pode ser usada para limitar a simultaneidade e evitar a sobrecarga dos recursos subsequentes, como as conexões de banco de dados. A simultaneidade reservada atua como limite inferior e superior: ela reserva a capacidade especificada exclusivamente para a função e, ao mesmo tempo, impede que ela ultrapasse esse limite. Configurar a simultaneidade reservada para uma função não acarreta cobranças adicionais. + Simultaneidade provisionada: é o número de ambientes de execução inicializados previamente alocados para a função. Esses ambientes de execução estão prontos para responder imediatamente às solicitações de função de entrada. A simultaneidade provisionada é útil para reduzir as latências de inicialização a frio das funções e foi criada para tornar as funções disponíveis com tempos de resposta na ordem das dezenas de milissegundos. Geralmente, as workloads interativas são as que mais se beneficiam do recurso. São aplicações em que os usuários iniciam solicitações, como aplicações móveis e da Web, e que são mais sensíveis à latência. As workloads assíncronas, como pipelines de processamento de dados, costumam ser menos sensíveis à latência e, portanto, geralmente não precisam de simultaneidade provisionada. A configuração da simultaneidade provisionada gera cobranças na sua Conta da AWS. Este tópico detalha como gerenciar e configurar a simultaneidade provisionada. Para uma visão geral conceitual desses dois tipos de controles de simultaneidade, consulte [Simultaneidade reservada e  simultaneidade provisionada](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#reserved-and-provisioned). Para obter mais informações sobre a configuração de simultaneidade reservada, consulte [Configurar a simultaneidade reservada para uma função](configuration-concurrency.md). **nota** As funções do Lambda vinculadas a um mapeamento da origem do evento do Amazon MQ têm uma simultaneidade máxima padrão. Para o Apache Active MQ, o número máximo de instâncias simultâneas é 5. Para o Rabbit MQ, o número máximo de instâncias simultâneas é 1. Definir a simultaneidade reservada ou provisionada para a função não altera esses limites. Para solicitar um aumento na simultaneidade máxima padrão ao usar o Amazon MQ, entre em contato com Suporte. **Topics** + [ ## Configurar a simultaneidade provisionada ](#configuring-provisioned-concurrency) + [ ## Estimar a simultaneidade provisionada necessária com precisão para uma função ](#estimating-provisioned-concurrency) + [ ## Otimizar o código da função ao usar a simultaneidade provisionada ](#optimizing-latency) + [ ## Usar variáveis de ambiente para visualizar e controlar o comportamento da simultaneidade provisionada ](#pc-environment-variables) + [ ## Entender o comportamento de log e cobrança com simultaneidade provisionada ](#pc-logging-behavior) + [ ## Usar o ajuste de escala automático de aplicações para automatizar o gerenciamento da simultaneidade provisionada ](#managing-provisioned-concurency) ## Configurar a simultaneidade provisionada Você pode definir configurações de simultaneidade provisionada para uma função usando o console do Lambda ou a API do Lambda. **Para alocar simultaneidade provisionada para uma função (console)** 1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda. 1. Escolha a função para a qual você deseja alocar a simultaneidade provisionada. 1. Escolha **Configuration (Configuração)** e escolha **(Concurrency (Simultaneidade)**. 1. Em **Provisioned concurrency configurations (Configurações de simultaneidade provisionada)**, escolha **Add configuration (Adicionar configuração)**. 1. Escolha o tipo de qualificador e o alias ou a versão. **nota** Você não pode usar simultaneidade provisionada com a versão \$1LATEST de qualquer função. Se a função tiver uma origem de evento, certifique-se de que a origem de evento aponte para o alias ou a versão correta da função. Caso contrário, a função não usará ambientes de simultaneidade provisionada. 1. Insira um número em **Simultaneidade provisionada**. 1. Escolha **Salvar**. Você pode configurar até a **Simultaneidade de conta não reservada** na sua conta, menos 100. As 100 unidades restantes de simultaneidade se destinam a funções que não estão usando simultaneidade reservada. Por exemplo, se sua conta tem um limite de simultaneidade de 1 mil e você não atribuiu qualquer simultaneidade reservada ou provisionada a qualquer uma das outras funções, você pode configurar no máximo 900 unidades de simultaneidade provisionada para uma única função. ![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/provisioned-concurrency-over-limit.png) Configurar simultaneidade provisionada para uma função causa um impacto no grupo de simultaneidades disponíveis para outras funções. Por exemplo, se você configurar 100 unidades de simultaneidade provisionada para a `function-a`, outras funções da sua conta deverão compartilhar as 900 unidades restantes de simultaneidade. Isso ocorrerá mesmo se a `function-a` não usar todas as 100 unidades. É possível alocar tanto a simultaneidade reservada como a provisionada para a mesma função. Nesses casos, a simultaneidade provisionada não pode exceder a simultaneidade reservada. Essa limitação se estende às versões da função. A simultaneidade máxima provisionada que você pode atribuir a uma versão de função específica é igual à simultaneidade reservada da função menos a simultaneidade provisionada em outras versões da função. Para configurar a simultaneidade provisionada com a API do Lambda, use as operações da API a seguir. + [PutProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutProvisionedConcurrencyConfig.html) + [GetProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetProvisionedConcurrencyConfig.html) + [ListProvisionedConcurrencyConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListProvisionedConcurrencyConfigs.html) + [DeleteProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteProvisionedConcurrencyConfig.html) Por exemplo, para configurar a simultaneidade provisionada com a AWS Command Line Interface (CLI), use o comando `put-provisioned-concurrency-config`. O comando a seguir aloca 100 unidades de simultaneidade provisionada para o alias `BLUE` de uma função chamada `my-function`: ``` aws lambda put-provisioned-concurrency-config --function-name my-function \ --qualifier BLUE \ --provisioned-concurrent-executions 100 ``` Você observará um resultado parecido com o seguinte: ``` { "Requested ProvisionedConcurrentExecutions": 100, "Allocated ProvisionedConcurrentExecutions": 0, "Status": "IN_PROGRESS", "LastModified": "2023-01-21T11:30:00+0000" } ``` ## Estimar a simultaneidade provisionada necessária com precisão para uma função Você pode visualizar as métricas de simultaneidade de qualquer função ativa usando as [métricas do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html). Especificamente, a métrica `ConcurrentExecutions` apresenta o número de invocações simultâneas para as funções da conta. ![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/concurrency-concurrent-executions-metrics.png) O gráfico anterior sugere que essa função atende a uma média de cinco a dez solicitações simultâneas em qualquer ocasião e atinge o pico de 20 solicitações. Suponha que existam muitas outras funções na sua conta. ** Se essa função for essencial para sua aplicação e você precisar de uma resposta de baixa latência em cada invocação**, configure pelo menos 20 unidades de simultaneidade provisionada. Lembre-se de que você também pode [calcular a simultaneidade](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#calculating-concurrency) usando a seguinte fórmula: ``` Concurrency = (average requests per second) * (average request duration in seconds) ``` Para estimar quanto de simultaneidade você precisa, multiplique a média de solicitações por segundo pela duração média das solicitações em segundos. É possível estimar a média de solicitações por segundo usando a métrica `Invocation` e a duração média da solicitação em segundos usando a métrica `Duration`. Quando você configura simultaneidade provisionada, o Lambda sugere a adição de uma reserva de 10% na quantidade de simultaneidade de que a função normalmente precisa. Por exemplo, se a função geralmente atinge o pico de 200 solicitações simultâneas, defina a simultaneidade provisionada como 220 (200 solicitações simultâneas \$1 10% = 220 de simultaneidade provisionada). ## Otimizar o código da função ao usar a simultaneidade provisionada Se você estiver usando simultaneidade provisionada, considere reestruturar o código da função para otimizar a baixa latência. Para funções que usam simultaneidade provisionada, o Lambda executa qualquer código de inicialização, como o carregamento de bibliotecas e a criação de instâncias de clientes) no momento da alocação. Portanto, é aconselhável mover o máximo de inicialização para fora do manipulador da função principal para evitar afetar a latência durante as invocações reais da função. Por outro lado, a inicialização de bibliotecas ou a criação de instâncias de clientes no código do manipulador principal significa que a função precisará executar isso toda vez que for invocada (isso ocorre independentemente de você estar ou não usando simultaneidade provisionada). Para invocações sob demanda, o Lambda pode precisar executar novamente o código de inicialização sempre que a função passar por uma inicialização a frio. Para essas funções, você pode optar por adiar a inicialização de um recurso específico até que a função precise dele. Por exemplo, considere o seguinte fluxo de controle para um manipulador do Lambda: ``` def handler(event, context): ... if ( some_condition ): // Initialize CLIENT_A to perform a task else: // Do nothing ``` No exemplo anterior, em vez de inicializar o `CLIENT_A` fora do manipulador principal, o desenvolvedor realizou a inicialização com a instrução `if`. Ao fazer isso, o Lambda só executará esse código se `some_condition` for satisfeito. Se o autor inicializar `CLIENT_A` fora do manipulador principal, o Lambda executará esse código em cada inicialização a frio. Isso pode aumentar a latência geral. Você pode medir as inicializações a frio durante o aumento de escala do Lambda adicionando o monitoramento do X-Ray à sua função. Uma função que usa a simultaneidade provisionada não apresenta comportamento de inicialização a frio, pois o ambiente de execução é preparado antes da invocação. No entanto, a simultaneidade provisionada deve ser aplicada a uma [versão ou alias específico](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html) de uma função, e não à versão \$1LATEST. Nos casos em que você continuar observando o comportamento de inicialização a frio, certifique-se de invocar a versão do alias com a simultaneidade provisionada configurada. ## Usar variáveis de ambiente para visualizar e controlar o comportamento da simultaneidade provisionada É possível que a função use toda a simultaneidade provisionada. O Lambda usa instâncias sob demanda para lidar com qualquer excesso de tráfego. Para determinar o tipo de inicialização que o Lambda usou para um ambiente específico, verifique o valor da variável de ambiente `AWS_LAMBDA_INITIALIZATION_TYPE`. Essa variável tem dois valores possíveis: `provisioned-concurrency` ou `on-demand`. O valor de `AWS_LAMBDA_INITIALIZATION_TYPE` é imutável e permanece constante durante toda a vida útil do ambiente. Para verificar o valor de uma variável de ambiente no código da função, consulte [Recuperar variáveis ​​de ambiente do Lambda](configuration-envvars.md#retrieve-environment-variables). Se você estiver usando os runtimes do .NET 8, poderá configurar a variável de ambiente `AWS_LAMBDA_DOTNET_PREJIT` para melhorar a latência das funções, mesmo se elas não usarem simultaneidade provisionada. O runtime do .NET emprega compilação e inicialização lentas para cada biblioteca que o código chama pela primeira vez. Como resultado, a primeira invocação de uma função do Lambda pode levar mais tempo do que as subsequentes. Para mitigar isso, é possível escolher um dos três valores para `AWS_LAMBDA_DOTNET_PREJIT`: + `ProvisionedConcurrency`: o Lambda executa a compilação JIT antecipada para todos os ambientes usando simultaneidade provisionada. Este é o valor padrão. + `Always`: o Lambda executa a compilação JIT antecipada para cada ambiente, mesmo que a função não use simultaneidade provisionada. + `Never`: o Lambda desativa a compilação JIT antecipada para todos os ambientes. ## Entender o comportamento de log e cobrança com simultaneidade provisionada Para instâncias de simultaneidade provisionada, o código de inicialização da função é executado durante a alocação e periodicamente, quando o Lambda recicla as instâncias do ambiente. O Lambda cobra pela inicialização mesmo que a instância de ambiente nunca processe uma solicitação. A simultaneidade provisionada é executada continuamente e gera um faturamento separado dos custos de inicialização e de invocação. Para obter mais detalhes, consulte [Preço do AWS Lambda](https://aws.amazon.com/lambda/pricing/). Quando você configura uma função do Lambda com simultaneidade provisionada, o Lambda pré-inicializa esse ambiente de execução para que ele esteja disponível antes das solicitações de invocação. O Lambda registra o [ campo Init Duration](lambda-runtime-environment.md#runtimes-lifecycle-ib) da função em um evento de logs [ platform-initReport](telemetry-schema-reference.md#platform-initReport) no formato de registro em log JSON toda vez que o ambiente é inicializado. Para ver esse evento de logs, configure seu [nível de log JSON](monitoring-cloudwatchlogs-logformat.md) para pelo menos `INFO`. Você também pode usar a [API de telemetria](telemetry-api-reference.md) para consumir eventos da plataforma em que o campo Init Duration é relatado. ## Usar o ajuste de escala automático de aplicações para automatizar o gerenciamento da simultaneidade provisionada Você pode usar o Application Auto Scaling para gerenciar a simultaneidade provisionada em uma programação ou com base na utilização. Se a função receber padrões previsíveis de tráfego, use ajuste de escala programado. Se você deseja que a função mantenha uma porcentagem de utilização específica, use uma política de ajuste de escala de rastreamento de destino. **nota** Se você usar o Application Auto Scaling para gerenciar a simultaneidade provisionada da sua função, certifique-se primeiro de [configurar um valor inicial de simultaneidade provisionada](#configuring-provisioned-concurrency). Se sua função não tiver um valor inicial de simultaneidade provisionada, o Application Auto Scaling pode não lidar adequadamente com a escalabilidade de funções. ### Escalabilidade programada Com o Application Auto Scaling, você pode definir sua própria programação de ajuste de escala de acordo com alterações de carga previsíveis. Para obter mais informações e exemplos, consulte [Ajuste de escala programado para o Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) no Guia do usuário do Application Auto Scaling e [Programar simultaneidade provisionada do AWS Lambda para picos recorrentes de uso](https://aws.amazon.com/blogs/compute/scheduling-aws-lambda-provisioned-concurrency-for-recurring-peak-usage/) no blog de computação da AWS. ### Monitoramento do objetivo Com o rastreamento de destino, o Application Auto Scaling cria e gerencia um conjunto de alarmes do CloudWatch com base na maneira como você define sua política de ajuste de escala. Quando esses alarmes são ativados, o Application Auto Scaling ajusta automaticamente a quantidade de ambientes alocados usando simultaneidade provisionada. Use rastreamento de destino para aplicações que não têm padrões de tráfego previsíveis. Para ajustar a escala da simultaneidade provisionada usando o rastreamento de destino, use as operações da API do Application Auto Scaling `RegisterScalableTarget` e `PutScalingPolicy`. Por exemplo, se você estiver usando a AWS Command Line Interface (CLI), siga estas etapas: 1. Registre o alias de uma função como um destino de escalabilidade. O exemplo a seguir registra o alias BLUE de uma função denominada `my-function`: ``` aws application-autoscaling register-scalable-target --service-namespace lambda \ --resource-id function:my-function:BLUE --min-capacity 1 --max-capacity 100 \ --scalable-dimension lambda:function:ProvisionedConcurrency ``` 1. Aplique uma política de escalabilidade ao destino. O exemplo a seguir configura o Application Auto Scaling para ajustar a configuração de simultaneidade provisionada para um alias a fim de manter a utilização próxima de 70%, mas é possível aplicar qualquer valor entre 10% e 90%. ``` aws application-autoscaling put-scaling-policy \ --service-namespace lambda \ --scalable-dimension lambda:function:ProvisionedConcurrency \ --resource-id function:my-function:BLUE \ --policy-name my-policy \ --policy-type TargetTrackingScaling \ --target-tracking-scaling-policy-configuration '{ "TargetValue": 0.7, "PredefinedMetricSpecification": { "PredefinedMetricType": "LambdaProvisionedConcurrencyUtilization" }}' ``` Você deve ver uma saída semelhante a: ``` { "PolicyARN": "arn:aws:autoscaling:us-east-2:123456789012:scalingPolicy:12266dbb-1524-xmpl-a64e-9a0a34b996fa:resource/lambda/function:my-function:BLUE:policyName/my-policy", "Alarms": [ { "AlarmName": "TargetTracking-function:my-function:BLUE-AlarmHigh-aed0e274-xmpl-40fe-8cba-2e78f000c0a7", "AlarmARN": "arn:aws:cloudwatch:us-east-2:123456789012:alarm:TargetTracking-function:my-function:BLUE-AlarmHigh-aed0e274-xmpl-40fe-8cba-2e78f000c0a7" }, { "AlarmName": "TargetTracking-function:my-function:BLUE-AlarmLow-7e1a928e-xmpl-4d2b-8c01-782321bc6f66", "AlarmARN": "arn:aws:cloudwatch:us-east-2:123456789012:alarm:TargetTracking-function:my-function:BLUE-AlarmLow-7e1a928e-xmpl-4d2b-8c01-782321bc6f66" } ] } ``` O Application Auto Scaling cria dois alarmes no CloudWatch. O primeiro alarme será acionado quando a utilização da simultaneidade provisionada exceder consistentemente 70%. Quando isso acontecer, o Application Auto Scaling alocará mais simultaneidade provisionada para reduzir a utilização. O segundo alarme será acionado quando a utilização for consistentemente inferior a 63% (90% da meta de 70%). Quando isso acontecer, o Application Auto Scaling reduzirá a simultaneidade provisionada do alias. **nota** O Lambda emite a métrica `ProvisionedConcurrencyUtilization` apenas quando sua função está ativa e recebendo solicitações. Durante períodos de inatividade, nenhuma métrica é emitida e seus alarmes de ajuste de escala automático entram no estado `INSUFFICIENT_DATA`. Como resultado, o ajuste de escala automático da aplicação não será capaz de ajustar a simultaneidade provisionada da sua função. Isso pode gerar cobranças inesperadas. No exemplo a seguir, uma função é dimensionada entre uma quantidade mínima e máxima de simultaneidade provisionada com base na utilização. ![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/features-scaling-provisioned-auto.png) **Legenda** + ![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/features-scaling-provisioned.instances.png) Instâncias de função + ![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/features-scaling-provisioned.open.png) Solicitações abertas + ![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/features-scaling-provisioned.provisioned.png) Simultaneidade provisionada + ![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/features-scaling-provisioned.standard.png)Simultaneidade padrão Quando o número de solicitações abertas aumenta, o Application Auto Scaling aumenta a simultaneidade provisionada em grandes etapas até atingir o máximo configurado. Depois disso, a função poderá continuar a ajustar a escala com base na simultaneidade padrão não reservada se você não tiver atingido o limite de simultaneidade da conta. Quando a utilização diminui e permanece baixa, o Application Auto Scaling diminui a simultaneidade provisionada em etapas periódicas menores. Os dois alarmes do Application Auto Scaling usam a estatística média por padrão. Funções que sofrem intermitências rápidas de tráfego podem não acionar esses alarmes. Por exemplo, suponha que a função do Lambda seja executada rapidamente (ou seja, entre 20 e 100 ms) e o tráfego ocorra em intermitências rápidas. Nesse caso, o número de solicitações excede a simultaneidade provisionada alocada durante a intermitência. No entanto, o Application Auto Scaling exige que a carga de intermitência seja mantida por pelo menos três minutos para provisionar ambientes adicionais. Além disso, os dois alarmes do CloudWatch exigem três pontos de dados que atinjam a média de destino para ativar a política de ajuste de escala automático. Se sua função apresentar picos rápidos de tráfego, o uso da estatística **Máxima** em vez da estatística **Média** pode ser mais eficaz no escalonamento da simultaneidade provisionada a fim de minimizar as inicializações a frio. Para obter mais informações sobre políticas de ajuste de escala de rastreamento de destino, consulte [Políticas de ajuste de escala de rastreamento de destino para o Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html). # Comportamento de escalabilidade do Lambda À 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 da conta podem reduzir a escala horizontalmente 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. ## Taxa de escalabilidade da simultaneidade **Em cada Região da AWS e para cada função, a taxa de escalação de simultaneidade é de 1.000 instâncias do ambiente de execução a cada 10 segundos (ou 10.000 solicitações por segundo a cada 10 segundos).** Em outras palavras, a cada 10 segundos, o Lambda pode alocar no máximo 1.000 instâncias do ambiente de execução ou aceitar mais 10.000 solicitações por segundo para cada uma das 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 aplicado por função. Isso significa que cada função da sua conta pode ajustar a escala independentemente de outras funções. **nota** Na prática, o Lambda faz o possível para reabastecer sua taxa de escalabilidade de simultaneidade continuamente, em vez de fazer uma única recarga de mil unidades a cada 10 segundos. O Lambda não acumula partes não utilizadas da taxa de escalabilidade de simultaneidade. Isso significa que sua taxa de escalabilidade será sempre de mil unidades simultâneas, no máximo. Por exemplo, se você não usar nenhuma das mil unidades de simultaneidade disponíveis em um intervalo de 10 segundos, não acumulará mil unidades adicionais para o próximo intervalo de 10 segundos. Sua taxa de escalabilidade de simultaneidade ainda será de mil no próximo intervalo de 10 segundos. Enquanto sua função continuar recebendo um número cada vez maior de solicitações, o Lambda ajustará a escala com a taxa mais rápida disponível para você, até o limite de simultaneidade da sua conta. Para limitar o valor de simultaneidade das funções individuais, é necessário [configurar a simultaneidade reservada](configuration-concurrency.md). Se a quantidade de solicitações recebidas for maior do que a capacidade da função de fazer o ajuste de escala ou se a função já estiver na simultaneidade máxima, as solicitações adicionais vão apresentar falha com um erro de controle de utilização (código de status 429). # Monitorar a simultaneidade O Lambda gera métricas do Amazon CloudWatch para ajudar você a monitorar a simultaneidade das funções. Este tópico explica essas métricas e como interpretá-las. **Topics** + [ ## Métricas gerais de simultaneidade ](#general-concurrency-metrics) + [ ## Métricas de simultaneidade provisionada ](#provisioned-concurrency-metrics) + [ ## Trabalhar com a métrica `ClaimedAccountConcurrency` ](#claimed-account-concurrency) ## Métricas gerais de simultaneidade Use as métricas a seguir para monitorar a simultaneidade das funções do Lambda. A granularidade de cada métrica é de um minuto. + `ConcurrentExecutions`: o número de invocações simultâneas ativas em um determinado ponto no tempo. O Lambda gera essa métrica para todas as funções, versões e aliases. Para qualquer função no console do Lambda, o Lambda exibe o grafo para `ConcurrentExecutions` nativamente na guia **Monitoramento**, em **Métricas**. Visualize essa métrica usando **MAX**. + `UnreservedConcurrentExecutions`: o número de invocações simultâneas ativas que estão usando a simultaneidade não reservada. O Lambda gera essa métrica em todas as funções de uma região. Visualize essa métrica usando **MAX**. + `ClaimedAccountConcurrency`: quantidade de simultaneidade que não está disponível para invocações sob demanda. `ClaimedAccountConcurrency` é igual a `UnreservedConcurrentExecutions` mais a quantidade de simultaneidade alocada (ou seja, a simultaneidade total reservada mais a simultaneidade total provisionada). Se `ClaimedAccountConcurrency` exceder o limite de simultaneidade da conta, você poderá [solicitar um limite maior de simultaneidade para a conta](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-concurrency-limit-increase/). Visualize essa métrica usando **MAX**. Para obter mais informações, consulte [Trabalhar com a métrica `ClaimedAccountConcurrency`](#claimed-account-concurrency). ## Métricas de simultaneidade provisionada Use as métricas a seguir para monitorar as funções do Lambda usando a simultaneidade provisionada. A granularidade de cada métrica é de um minuto. + `ProvisionedConcurrentExecutions`: o número de instâncias do ambiente de execução que estão ativamente processando uma invocação na simultaneidade provisionada. O Lambda gera essa métrica para cada versão e alias da função com a simultaneidade provisionada configurada. Visualize essa métrica usando **MAX**. `ProvisionedConcurrentExecutions` não é o mesmo que o número total de simultaneidade provisionada que você aloca. Por exemplo, suponha que você aloque 100 unidades de simultaneidade provisionada para uma versão de função. Durante um determinado minuto, se no máximo 50 desses 100 ambientes de execução estivessem lidando com invocações simultaneamente, o valor de **MAX** (`ProvisionedConcurrentExecutions`) seria 50. + `ProvisionedConcurrencyInvocations`: o número de vezes que o Lambda invoca o código da função usando a simultaneidade provisionada. O Lambda gera essa métrica para cada versão e alias da função com a simultaneidade provisionada configurada. Visualize essa métrica usando **SUM**. `ProvisionedConcurrencyInvocations` difere de `ProvisionedConcurrentExecutions` porque `ProvisionedConcurrencyInvocations` conta o número total de invocações, enquanto `ProvisionedConcurrentExecutions` conta o número de ambientes ativos. Para entender essa distinção, considere o seguinte cenário: ![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/concurrency-metrics-pc-executions-vs-invocations.png) Neste exemplo, suponha que você receba uma invocação por minuto e cada invocação leve dois minutos para ser concluída. Cada barra horizontal laranja representa uma única solicitação. Suponha que você aloque dez unidades de simultaneidade provisionada para essa função de forma que cada solicitação seja executada na simultaneidade provisionada. Entre os minutos 0 e 1, entra `Request 1`. **No minuto 1**, o valor de **MAX** (`ProvisionedConcurrentExecutions`) é 1, pois no máximo um ambiente de execução estava ativo durante o último minuto. O valor de **SUM** (`ProvisionedConcurrencyInvocations`) também é 1, pois uma nova solicitação foi recebida no último minuto. Entre os minutos 1 e 2, `Request 2` entra e `Request 1` continua em execução. **No minuto 2**, o valor de **MAX** (`ProvisionedConcurrentExecutions`) é 2, pois no máximo dois ambientes de execução estavam ativos durante o último minuto. Entretanto, o valor de **SUM** (`ProvisionedConcurrencyInvocations`) também é 1, pois  somente uma nova solicitação foi recebida durante o último minuto. Esse comportamento métrico continua até o final do exemplo. + `ProvisionedConcurrencySpilloverInvocations`: o número de vezes que o Lambda invoca a função na simultaneidade padrão (reservada ou não reservada) quando toda a simultaneidade provisionada está em uso. O Lambda gera essa métrica para cada versão e alias da função com a simultaneidade provisionada configurada. Visualize essa métrica usando **SUM**. O valor de `ProvisionedConcurrencyInvocations` \$1 `ProvisionedConcurrencySpilloverInvocations` deve ser igual ao número total de invocações da função (ou seja, a métrica `Invocations`). `ProvisionedConcurrencyUtilization`: a porcentagem de simultaneidade provisionada em uso (ou seja, o valor de `ProvisionedConcurrentExecutions` dividido pela quantidade total de simultaneidade provisionada alocada). O Lambda gera essa métrica para cada versão e alias da função com a simultaneidade provisionada configurada. Visualize essa métrica usando **MAX**. Por exemplo, suponha que você provisione 100 unidades de simultaneidade provisionada para uma versão de função. Durante um determinado minuto, se no máximo 60 desses 100 ambientes de execução estivessem processando invocações simultaneamente, o valor de **MAX** (`ProvisionedConcurrentExecutions`) seria 60 e o valor de **MAX** (`ProvisionedConcurrencyUtilization`) seria 0,6. Um valor alto para `ProvisionedConcurrencySpilloverInvocations` pode indicar que você precisa alocar simultaneidade provisionada adicional para a função. Como alternativa, você pode [configurar o Application Auto Scaling para processar o ajuste de escala automático da simultaneidade provisionada](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html#managing-provisioned-concurency) com base em limites predefinidos. Por outro lado, valores consistentemente baixos para `ProvisionedConcurrencyUtilization` podem indicar que você superalocou a simultaneidade provisionada para a função. ## Trabalhar com a métrica `ClaimedAccountConcurrency` O Lambda usa a métrica `ClaimedAccountConcurrency` para determinar a quantidade de simultaneidade que está disponível na sua conta para invocações sob demanda. O Lambda calcula `ClaimedAccountConcurrency` usando a seguinte fórmula: ``` ClaimedAccountConcurrency = UnreservedConcurrentExecutions + (allocated concurrency) ``` `UnreservedConcurrentExecutions` é o número de invocações simultâneas ativas que estão usando a simultaneidade não reservada. A simultaneidade alocada é a soma das duas partes a seguir (substituindo `RC` por “simultaneidade reservada” e `PC` por “simultaneidade provisionada”): + O total de `RC` em todas as funções em uma região. + O total de `PC` em todas as funções em uma região que usam `PC`, excluindo as funções que usam `RC`. **nota** Você não pode alocar mais `PC` do que `RC` para uma função. Portanto, a função `RC` é sempre maior ou igual à sua `PC`. Para calcular a contribuição para a simultaneidade alocada dessas funções com `PC` e `RC`, o Lambda considera apenas `RC`, que é o máximo das duas. O Lambda usa a métrica `ClaimedAccountConcurrency` em vez de `ConcurrentExecutions` para determinar a quantidade de simultaneidade que está disponível para invocações sob demanda. Embora a métrica `ConcurrentExecutions` seja útil para rastrear o número de invocações simultâneas ativas, ela nem sempre reflete a verdadeira disponibilidade de simultaneidade. Isso ocorre porque o Lambda também considera a simultaneidade reservada e a simultaneidade provisionada para determinar a disponibilidade. Para ilustrar `ClaimedAccountConcurrency`, considere um cenário em que você configura muitas simultaneidades reservadas e provisionadas nas funções que, em grande parte, não são usadas. No exemplo a seguir, suponha que o limite de simultaneidade da sua conta seja 1.000 e que você tenha duas funções principais na conta: `function-orange` e `function-blue`. Você aloca 600 unidades de simultaneidade reservada para `function-orange`. Você aloca 200 unidades de simultaneidade provisionada para `function-blue`. Suponha que, com o tempo, você implante funções adicionais e observe o seguinte padrão de tráfego: ![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/claimed-account-concurrency.png) No diagrama anterior, as linhas pretas indicam o uso real da simultaneidade ao longo do tempo, e a linha vermelha indica o valor de `ClaimedAccountConcurrency` ao longo do tempo. Em todo esse cenário, `ClaimedAccountConcurrency` no mínimo é 800, apesar da baixa utilização real da simultaneidade nas funções. Isso ocorre porque você alocou o total de 800 unidades de simultaneidade para `function-orange` e `function-blue`. Da perspectiva do Lambda, você “reivindicou” essa simultaneidade para uso, portanto você efetivamente só tem 200 unidades de simultaneidade restantes para outras funções. Para esse cenário, a simultaneidade alocada é 800 na fórmula `ClaimedAccountConcurrency`. Podemos, então, calcular o valor de `ClaimedAccountConcurrency` em vários pontos do diagrama: + Em `t1`, `ClaimedAccountConcurrency` é 800 (800 \$1 0 `UnreservedConcurrentExecutions`). + Em `t2`, `ClaimedAccountConcurrency` é 900 (800 \$1 100 `UnreservedConcurrentExecutions`). + Em `t3`, `ClaimedAccountConcurrency` é, novamente, 900 (800 \$1 100 `UnreservedConcurrentExecutions`). ### Configurar a métrica `ClaimedAccountConcurrency` no CloudWatch O Lambda emite a métrica `ClaimedAccountConcurrency` no CloudWatch. Use essa métrica com o valor de `SERVICE_QUOTA(ConcurrentExecutions)` para obter a utilização percentual da simultaneidade na conta, conforme mostrado na seguinte fórmula: ``` Utilization = (ClaimedAccountConcurrency/SERVICE_QUOTA(ConcurrentExecutions)) * 100% ``` A captura de tela a seguir ilustra como você pode representar graficamente essa fórmula no CloudWatch. A linha verde `claim_utilization` representa a utilização da simultaneidade nessa conta, que está em torno de 40%: ![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/claimed-account-concurrency-cloudwatch-graph.png) A captura de tela anterior também inclui um alarme do CloudWatch que entra no estado `ALARM` quando a utilização da simultaneidade excede 70%. Você poderá usar a métrica `ClaimedAccountConcurrency` associada a alarmes semelhantes para determinar proativamente quando poderá ser preciso solicitar um limite maior de simultaneidade para a conta.