As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Diminua a latência para aplicações com tempos de inicialização longos usando pools ativos
Um pool ativo oferece a capacidade de diminuir a latência para suas aplicações que apresentam tempos de inicialização excepcionalmente longos, por exemplo, porque as instâncias precisam gravar grandes quantidades de dados no disco. Com os pools ativos, você não precisa mais provisionar excessivamente seus grupos do Auto Scaling para gerenciar a latência a fim de melhorar a performance das aplicações. Para obter mais informações, consulte a postagem do blog [Escalabilidade mais rápida de aplicações com pools ativos do EC2 Auto Scaling](https://aws.amazon.com/blogs/compute/scaling-your-applications-faster-with-ec2-auto-scaling-warm-pools/).
**Importante**
Criar um pool ativo quando ele não é necessário pode gerar custos desnecessários. Se o tempo da primeira inicialização não causar problemas de latência visíveis para sua aplicação, provavelmente não há necessidade de usar um pool ativo.
**Topics**
+ [Principais conceitos](#warm-pool-core-concepts)
+ [Pré-requisitos](#warm-pool-prerequisites)
+ [Atualização das instâncias em um pool ativo](#update-warm-pool)
+ [Recursos relacionados](#warm-pools-related-resources)
+ [Limitações](#warm-pools-limitations)
+ [Usar ganchos do ciclo de vida](warm-pool-instance-lifecycle.md)
+ [Criar um pool ativo para seu grupo do Auto Scaling](create-warm-pool.md)
+ [Visualizar status da verificação de integridade](warm-pools-health-checks-monitor-view-status.md)
+ [AWS CLI exemplos para trabalhar com piscinas aquecidas](examples-warm-pools-aws-cli.md)
## Principais conceitos
Antes de começar a usar, familiarize-se com os seguintes conceitos principais:
**Pool ativo**
Um pool ativo é um grupo de instâncias do EC2 pré-inicializadas que permanece ao lado de um grupo do Auto Scaling. Sempre que é necessário aumentar a escala da aplicação na horizontal, o grupo do Auto Scaling pode utilizar o pool ativo para atender à nova capacidade desejada. Isso o ajuda a garantir que as instâncias estejam prontas para começar rapidamente a servir o tráfego das aplicações, acelerando a resposta a um evento de aumento de escala na horizontal. Quando as instâncias deixam o pool ativo, elas passam a contar para a capacidade desejada do grupo. Isso é conhecido como *inicialização a quente*.
Enquanto as instâncias estão no pool quente, suas políticas de escalabilidade só são dimensionadas se o valor da métrica das instâncias que estão no estado `InService` for maior que o limite alto de alarme da política da escalabilidade (que é o mesmo que a utilização de destino de uma política de dimensionamento com monitoramento do objetivo).
**Tamanho do pool ativo**
Por padrão, o tamanho do pool ativo é calculado como a diferença entre a capacidade máxima do grupo do Auto Scaling e a capacidade desejada. Por exemplo, se a capacidade desejada do grupo do Auto Scaling for 6 e a capacidade máxima for 10, o tamanho do pool ativo será 4 quando você configurar o pool ativo pela primeira vez e o pool estiver inicializando.
Para especificar a capacidade máxima do grupo dinâmico separadamente, use a opção de especificação personalizada (`MaxGroupPreparedCapacity`) e defina um valor personalizado para ela que seja maior do que a capacidade atual do grupo. Se você fornecer um valor personalizado, o tamanho do grupo dinâmico será calculado como a diferença entre o valor personalizado e a capacidade desejada atual do grupo. Por exemplo, se a capacidade desejada do seu grupo do Auto Scaling for 6, se a capacidade máxima for 20 e se o valor personalizado for 8, o tamanho do seu grupo dinâmico será 2 quando você configurar o grupo dinâmico pela primeira vez e o grupo estiver sendo inicializado.
Talvez você só precise usar a opção de especificação personalizada (`MaxGroupPreparedCapacity`) ao trabalhar com grandes grupos do Auto Scaling para gerenciar os benefícios de custo de ter um grupo dinâmico. Por exemplo, talvez um grupo do Auto Scaling com 1.000 instâncias, uma capacidade máxima de 1.500 (para fornecer capacidade extra durante picos de tráfego de emergência) e um pool ativo de 100 instâncias seja uma estratégia melhor para ajudar você a atingir seus objetivos do que manter 500 instâncias reservadas para uso futuro no pool ativo.
**Tamanho mínimo do pool ativo**
Considere usar a configuração de tamanho mínimo (`MinSize`) para definir de modo estático o número mínimo de instâncias a serem mantidas no grupo de alta atividade. Não há tamanho mínimo definido por padrão. A configuração `MinSize` é útil quando você especifica `MaxGroupPreparedCapacity` para garantir que um número mínimo de instâncias seja mantido no grupo de alta atividade, mesmo quando a capacidade desejada do grupo do Auto Scaling for maior que `MaxGroupPreparedCapacity`.
**Estado da instância do grupo de alta atividade**
Você pode manter as instâncias no pool ativo em um de três estados: `Stopped`, `Running`, ou `Hibernated`. Manter as instâncias no estado `Stopped` é uma maneira eficaz de minimizar os custos. Com as instâncias interrompidas, você paga apenas pelos volumes usados e pelos endereços IP elásticos anexados às instâncias.
Você também pode manter as instâncias em um estado `Hibernated` para interromper instâncias sem excluir o conteúdo da memória (RAM). Quando uma instância é hibernada, isso sinaliza ao sistema operacional para salvar o conteúdo da RAM no volume raiz do Amazon EBS. Quando você inicia a instância novamente, o volume raiz é restaurado ao seu estado anterior, e o conteúdo da RAM é recarregado. Enquanto as instâncias estão em hibernação, você paga somente pelos volumes do EBS, incluindo armazenamento para o conteúdo da RAM e os endereços IP elásticos anexados às instâncias.
Também é possível manter instâncias em um estado `Running` no pool ativo, mas isso é altamente desaconselhável a fim de evitar a geração de cobranças desnecessárias. Quando as instâncias são interrompidas ou hibernadas, você economiza o custo das próprias instâncias. Você paga pelas instâncias somente quando elas são executadas.
**Ganchos do ciclo de vida**
Você usa [ganchos do ciclo de vida](warm-pool-instance-lifecycle.md) para colocar instâncias em um estado de espera para poder executar ações personalizadas nas instâncias. Ações personalizadas são executadas à medida que as instâncias são iniciadas ou antes de serem terminadas.
Em uma configuração de pool quente, os ganchos do ciclo de vida atrasam a interrupção ou hibernação das instâncias e a colocação em serviço durante um evento de expansão até que concluam a inicialização. Se você adicionar um pool ativo ao seu grupo do Auto Scaling sem um gancho do ciclo de vida, as instâncias que demorarem muito para concluir a inicialização poderão ser interrompidas ou hibernadas e, em seguida, colocadas em serviço durante um evento de aumento de escala na horizontal antes de estarem prontas.
**Política de reutilização de instâncias**
Por padrão, o Amazon EC2 Auto Scaling termina suas instâncias quando seu grupo do Auto Scaling reduz a escala na horizontal. Em seguida, ele inicia novas instâncias no pool ativo para substituir as instâncias que foram terminadas.
Se desejar devolver instâncias ao pool ativo, você poderá especificar uma política de reutilização de instâncias. Isso permite reutilizar instâncias que já estão configuradas para atender ao tráfego de aplicações. Para garantir que seu pool ativo não seja excessivamente provisionado, o Amazon EC2 Auto Scaling pode terminar instâncias no pool ativo para reduzir seu tamanho quando for maior do que o necessário, com base em suas configurações. Ao terminar instâncias no pool ativo, ele usa a [política de término padrão](ec2-auto-scaling-termination-policies.md#default-termination-policy) para escolher quais instâncias terminar primeiro.
Se você desejar hibernar instâncias em redução de escala na horizontal e houver instâncias existentes no grupo do Auto Scaling, elas deverão atender aos requisitos de hibernação de instâncias. Caso contrário, quando as instâncias forem devolvidas ao pool ativo, elas recuarão para serem interrompidas em vez de serem hibernadas.
No momento, só é possível especificar uma política de reutilização de instâncias usando a AWS CLI ou um SDK. Esse recurso não está disponível no console.
## Pré-requisitos
Antes de criar um pool ativo para seu grupo do Auto Scaling, decida como você usará ganchos do ciclo de vida para inicializar novas instâncias com um estado inicial apropriado.
Para realizar ações personalizadas em instâncias enquanto elas estão em estado de espera devido a um gancho do ciclo de vida, você tem duas opções:
+ Para cenários simples em que você deseja executar comandos em suas instâncias no início, você pode incluir um script de dados do usuário ao criar um modelo de execução ou configuração de execução para o grupo do Auto Scaling. Os scripts de dados do usuário são apenas scripts de shell normais ou diretivas do cloud-init init que são executadas pelo cloud-init quando as instâncias são iniciadas. O script também pode controlar quando as instâncias fazem a transição para o próximo estado usando o ID da instância na qual é executado. Se você já não estiver fazendo isso, atualize seu script para recuperar o ID da instância nos metadados da instância. Para obter mais informações, consulte [Acesso a metadados da instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html) no *Guia do usuário do Amazon EC2*.
**dica**
Para executar scripts de dados do usuário quando uma instância é reiniciada, os dados do usuário devem estar no formato MIME de várias partes e especificar o seguinte na seção `#cloud-config` dos dados do usuário:
```
#cloud-config
cloud_final_modules:
- [scripts-user, always]
```
+ Para cenários avançados em que você precisa de um serviço, como AWS Lambda fazer algo quando as instâncias entram ou saem do pool aquecido, você pode criar um gancho de ciclo de vida para seu grupo de Auto Scaling e configurar o serviço de destino para realizar ações personalizadas com base nas notificações do ciclo de vida. Para obter mais informações, consulte [Destinos de notificação compatíveis](warm-pool-instance-lifecycle.md#warm-pools-supported-notification-targets).
**Preparar instâncias para hibernação**
Para preparar instâncias do Auto Scaling para usar o estado de grupo `Hibernated`, crie um novo modelo de execução ou configuração de execução configurada corretamente para oferecer suporte à hibernação de instância, conforme descrito no tópico [Pré-requisitos de hibernação](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/hibernating-prerequisites.html) no *Guia do usuário do Amazon EC2 para instâncias do Linux*. Em seguida, associe o novo modelo de execução ou a configuração de execução ao grupo do Auto Scaling e inicie uma atualização de instância para substituir as instâncias associadas a um modelo de execução ou a uma configuração de execução anterior. Para obter mais informações, consulte [Use uma atualização de instância para atualizar instâncias em um grupo do Auto Scaling](asg-instance-refresh.md).
## Atualização das instâncias em um pool ativo
Para atualizar as instâncias em um pool ativo, você cria um novo modelo de execução ou configuração de execução e o associa ao grupo do Auto Scaling. Todas as novas instâncias serão iniciadas usando a nova AMI e outras atualizações especificadas no modelo de execução ou na configuração de execução, mas as instâncias existentes não serão afetadas.
Para forçar as instâncias do pool ativo de substituição a executar esse uso, o modelo de execução ou a configuração de execução, é possível iniciar uma atualização de instância para fazer uma atualização contínua de seu grupo. Uma atualização de instância substitui primeiro as instâncias `InService`. Em seguida, ela substitui as instâncias no pool ativo. Para obter mais informações, consulte [Use uma atualização de instância para atualizar instâncias em um grupo do Auto Scaling](asg-instance-refresh.md).
## Recursos relacionados
Você pode visitar nosso [GitHubrepositório](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples) para ver exemplos de ganchos de ciclo de vida para piscinas aquecidas.
## Limitações
+ Limitações do grupo de alta atividade para um grupo do Auto Scaling com tipos de instâncias mistos:
+ Não há suporte aos grupos de alta atividade com grupos de instâncias mistas ponderadas. Se seu grupo do Auto Scaling usa ponderação de instâncias, não será possível adicionar um grupo de alta atividade.
+ Os grupos de alta atividade não oferecem suporte a instâncias spot em grupos de instâncias mistas. Sua política de instâncias mistas deve ser configurada para instâncias sob demanda somente ao usar grupos de alta atividade.
+ Ao usar grupos de alta atividade com grupos de instâncias mistas em estado de hibernação, será necessário configurar `HibernationOptions` em seu modelo de execução.
+ O Amazon EC2 Auto Scaling pode colocar uma instância em um estado `Stopped` ou `Hibernated` somente quando ele tem um volume do Amazon EBS como dispositivo raiz. Instâncias que usam armazenamento de instâncias para o dispositivo raiz não podem ser interrompidas ou hibernadas.
+ O Amazon EC2 Auto Scaling poderá colocar uma instância em um estado `Hibernated` somente se atender a todos os requisitos listados no tópico [Pré-requisitos de hibernação](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/hibernating-prerequisites.html) no *Guia do usuário do Amazon EC2 para instâncias do Linux*.
+ Se o pool ativo se esgotar em meio a um evento aumento de escala horizontal, as instâncias serão iniciadas diretamente no grupo do Auto Scaling (uma *inicialização de baixa atividade*). Uma inicialização de baixa atividade também poderá ocorrer se uma zona de disponibilidade estiver sem capacidade.
+ Se uma instância dentro do grupo dinâmico encontrar um problema durante o processo de execução, impedindo-a de atingir o estado `InService`, a instância será considerada uma execução defeituosa e será terminada. Isso se aplica independentemente da causa subjacente, como um erro de capacidade insuficiente ou qualquer outro fator.
+ Se você tentar usar pools ativos com um grupo de nós gerenciados do Amazon Elastic Kubernetes Service (Amazon EKS), as instâncias que ainda estão sendo inicializadas poderão se registrar no cluster do Amazon EKS. Como resultado, o cluster pode agendar trabalhos em uma instância enquanto se prepara para ser interrompido ou hibernado.
+ Da mesma forma, se você tentar usar um pool ativo com um cluster do Amazon ECS, as instâncias poderão se registrar no cluster antes que a inicialização seja concluída. Para resolver esse problema, é necessário configurar um modelo de inicialização ou uma configuração de inicialização que inclua uma variável de configuração de agente especial nos dados do usuário. Para obter mais informações, consulte [Using a warm pool for your Auto Scaling group](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/asg-capacity-providers.html#using-warm-pool) (Usar um grupo de alta atividade para o grupo do Auto Scaling) no *Amazon Elastic Container Service Developer Guide* (Guia do desenvolvedor do Amazon Elastic Container Service).
# Usar ganchos do ciclo de vida com um grupo dinâmico no grupo do Auto Scaling
As instâncias em um pool ativo mantêm seu próprio ciclo de vida independente para ajudar você a criar a ação personalizada apropriada para cada transição. Esse ciclo de vida foi desenvolvido para ajudar você a invocar ações em um serviço-alvo (por exemplo, uma função do Lambda) enquanto uma instância ainda está sendo inicializada e antes de ser colocada em serviço.
**nota**
As operações de API que você usa para adicionar e gerenciar ganchos do ciclo de vida e concluir ações do ciclo de vida não são alteradas. Somente o ciclo de vida da instância é alterado.
Para obter mais informações sobre a adição de um gancho do ciclo de vida, consulte [Preparar para adicionar um gancho do ciclo de vida a um grupo do Auto Scaling](adding-lifecycle-hooks.md). Para obter mais informações sobre a conclusão de uma ação do ciclo de vida, consulte [Concluir uma ação do ciclo de vida em um grupo do Auto Scaling](completing-lifecycle-hooks.md).
Para instâncias que entram no pool ativo, talvez você precise de um gancho do ciclo de vida por um dos seguintes motivos:
+ Você deseja iniciar instâncias do EC2 via uma AMI que demora muito para concluir a inicialização.
+ Você deseja executar scripts de dados do usuário para inicializar as instâncias do EC2.
Para instâncias que saem do pool ativo, talvez você precise de um gancho do ciclo de vida por um dos seguintes motivos:
+ Você pode usar algum tempo extra para preparar instâncias do EC2 para uso. Por exemplo, você pode ter serviços que devem ser iniciados quando uma instância é reiniciada antes que a aplicação possa funcionar corretamente.
+ Você deseja preencher previamente os dados de cache para que um novo servidor não seja iniciado com um cache vazio.
+ Você deseja registrar novas instâncias como instâncias gerenciadas com seu serviço de gerenciamento de configuração.
## Transições de estado do ciclo de vida para instâncias em um pool ativo
Uma instância do Auto Scaling pode fazer a transição por muitos estados como parte de seu ciclo de vida.
O diagrama a seguir mostra a transição entre estados do Auto Scaling quando você usa um pool ativo:
![\[As transições de estado do ciclo de vida para instâncias em um pool ativo.\]](http://docs.aws.amazon.com/pt_br/autoscaling/ec2/userguide/images/warm-pools-lifecycle-diagram.png)
¹ Esse estado varia de acordo com a configuração do estado do pool ativo. Se o estado do grupo estiver definido como `Running`, então esse estado será `Warmed:Running`, em vez disso. Se o estado do grupo estiver definido como `Hibernated`, então esse estado será `Warmed:Hibernated`, em vez disso.
Ao adicionar ganchos do ciclo de vida, considere o seguinte:
+ Quando um gancho do ciclo de vida é configurado para a ação `autoscaling:EC2_INSTANCE_LAUNCHING` do ciclo de vida, uma instância recém-iniciada faz uma primeira pausa para realizar uma ação personalizada quando atinge o estado `Warmed:Pending:Wait` e, novamente, quando a instância for reiniciada e atingir o estado `Pending:Wait`.
+ Quando um gancho do ciclo de vida é configurado para a ação `EC2_INSTANCE_TERMINATING` do ciclo de vida, uma instância em encerramento faz uma pausa para realizar uma ação personalizada quando atinge o estado `Terminating:Wait`. No entanto, se você especificar uma política de reutilização de instâncias para retornar instâncias ao pool ativo na operação de redução da escala horizontalmente em vez de encerrá-las, uma instância que estiver retornando ao pool ativo fará uma pausa para realizar uma ação personalizada no estado `Warmed:Pending:Wait` para a ação do ciclo de vida `EC2_INSTANCE_TERMINATING`.
+ Se a demanda em sua aplicação esgotar o pool ativo, o Amazon EC2 Auto Scaling poderá iniciar instâncias diretamente no grupo do Auto Scaling se o grupo ainda não tiver atingido sua capacidade máxima. Se as instâncias forem executadas diretamente no grupo, elas só serão pausadas para realizar uma ação personalizada no estado `Pending:Wait`.
+ Para controlar por quanto tempo uma instância permanece em um estado de espera antes de fazer a transição para o próximo estado, configure sua ação personalizada para usar o comando **complete-lifecycle-action**. Com os ganchos do ciclo de vida, as instâncias permanecem em estado de espera até que você notifique o Amazon EC2 Auto Scaling de que a ação especificada do ciclo de vida foi concluída, ou até que o período de tempo limite termine (uma hora, por padrão).
A seguir, um resumo do fluxo para um evento de aumento da escala na horizontal.
![\[Um diagrama de fluxo de aumento da escala na horizontal.\]](http://docs.aws.amazon.com/pt_br/autoscaling/ec2/userguide/images/warm-pools-scale-out-event-diagram.png)
Quando as instâncias atingem um estado de espera, o Amazon EC2 Auto Scaling envia uma notificação. Exemplos dessas notificações estão disponíveis na EventBridge seção deste guia. Para obter mais informações, consulte [Exemplos de eventos e padrões de pool ativo](warm-pools-eventbridge-events.md).
## Destinos de notificação compatíveis
O Amazon EC2 Auto Scaling oferece suporte para definir qualquer um dos seguintes destinos como destinos de notificação para notificações do ciclo de vida:
+ EventBridge regras
+ Tópicos do Amazon SNS
+ Filas do Amazon SQS
+ AWS Lambda funções
**Importante**
Se você tiver um script de dados do usuário (cloud-init) no modelo de execução ou na configuração de execução que configura as instâncias quando elas são iniciadas, você não precisará receber notificações para realizar ações personalizadas nas instâncias que estão sendo iniciadas ou reiniciadas.
As seções a seguir contêm links para a documentação que descreve como configurar destinos de notificação:
**EventBridge regras** — Para executar código quando o Amazon EC2 Auto Scaling coloca uma instância em estado de espera, você pode EventBridge criar uma regra e especificar uma função Lambda como destino. Para invocar diferentes funções do Lambda com base em notificações do ciclo de vida diferentes, você pode criar várias regras e associar cada regra a um padrão de evento específico e função do Lambda. Para obter mais informações, consulte [Crie EventBridge regras para eventos em piscinas aquecidas](warm-pool-events-eventbridge-rules.md).
**Tópicos do Amazon SNS**: para receber uma notificação quando uma instância é colocada em um estado de espera, você cria um tópico do Amazon SNS e, em seguida, configura a filtragem de mensagens do Amazon SNS para entregar notificações do ciclo de vida de forma diferente com base em um atributo de mensagem. Para obter mais informações, consulte [Receba notificações usando o Amazon SNS](prepare-for-lifecycle-notifications.md#sns-notifications).
**Filas do Amazon SQS**: para configurar um ponto de entrega para notificações do ciclo de vida em que um consumidor relevante possa buscá-las e processá-las, é possível criar uma fila do Amazon SQS e um consumidor de fila que processe mensagens da fila SQS. Se você quiser que o consumidor da fila processe notificações do ciclo de vida de forma diferente com base em um atributo da mensagem, você também deverá configurar o consumidor da fila para analisar a mensagem e, em seguida, agir sobre a mensagem quando um atributo específico corresponder ao valor desejado. Para obter mais informações, consulte [Receba notificações usando o Amazon SQS](prepare-for-lifecycle-notifications.md#sqs-notifications).
**AWS Lambda funções** — Para executar código personalizado quando o Amazon EC2 Auto Scaling coloca uma instância em estado de espera, você pode especificar uma função Lambda como destino da notificação. A função Lambda é invocada com dados de notificação do ciclo de vida, permitindo que você execute ações personalizadas, como configuração de instância, configuração de aplicativos ou integração com outros serviços. AWS É necessário configurar a política baseada em recursos da função do Lambda para permitir que o perfil vinculado ao serviço do Auto Scaling invoque a função. Para obter mais informações, consulte [Encaminhe notificações AWS Lambda diretamente para](prepare-for-lifecycle-notifications.md#lambda-notification).
# Criar um pool ativo para seu grupo do Auto Scaling
Este tópico descreve como criar um pool ativo para seu grupo do Auto Scaling.
**Importante**
Antes de continuar, preencha os [pré-requisitos](ec2-auto-scaling-warm-pools.md#warm-pool-prerequisites) para criar um pool ativo e confirme se você criou um gancho do ciclo de vida para o grupo do Auto Scaling.
## Criar um pool ativo
Use o procedimento a seguir para criar um pool ativo para o grupo do Auto Scaling.
**Para criar um pool ativo (console)**
1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)e escolha **Auto Scaling Groups** no painel de navegação.
1. Marque a caixa de seleção ao lado de um grupo existente.
Um painel dividido é aberto na parte inferior da página.
1. Selecione a guia **Instance management** (Gerenciamento de instâncias).
1. Em **Warm pool** (pool ativo), escolha **Create warm pool** (Criar pool ativo).
1. Para configurar um pool ativo, faça o seguinte:
1. Em **Warm pool instance state** (Estado da instância do pool de alta atividade), escolha para qual estado você deseja fazer a transição das instâncias quando elas entrarem no pool ativo. O padrão é `Stopped`.
1. Em **Minimum warm pool size** (Tamanho mínimo do pool ativo), insira o número mínimo de instâncias que serão mantidas no pool ativo.
1. Para a **reutilização de instâncias**, marque a caixa de seleção **Reutilizar em redução da escala horizontalmente** para permitir que as instâncias no grupo do Auto Scaling retornem ao grupo dinâmico em redução da escala horizontalmente.
1. Para o **Tamanho do grupo dinâmico**, escolha uma das opções disponíveis:
+ **Especificação padrão**: O tamanho do grupo dinâmico é determinado pela diferença entre a capacidade máxima e a desejada do grupo do Auto Scaling. Essa opção simplifica o gerenciamento do grupo dinâmico. Depois de criar o grupo dinâmico, seu tamanho pode ser facilmente atualizado, bastando ajustar a capacidade máxima do grupo.
+ **Especificação personalizada**: O tamanho do grupo dinâmico é determinado pela diferença entre um valor personalizado e a capacidade desejada do grupo do Auto Scaling. Essa opção lhe dá flexibilidade para gerenciar o tamanho de seu grupo dinâmico independentemente da capacidade máxima do grupo.
1. Consulte a seção **Tamanho estimado do grupo dinâmico com base nas configurações atuais** para confirmar como a especificação padrão ou personalizada se aplica ao tamanho do esse grupo. Lembre-se de que o tamanho do grupo dinâmico depende da capacidade desejada do grupo do Auto Scaling, que será alterada se o grupo for escalado.
1. Escolha **Criar**.
## Seleção do tipo de instância com grupos de instâncias mistas
O Auto Scaling prioriza os tipos de instância que já estejam no grupo de alta atividade durante eventos de escalabilidade quando seu grupo está configurado com uma política de instâncias mistas. Comportamento da execução:
1. O Auto Scaling tenta iniciar instâncias usando os tipos de instância disponíveis no grupo de alta atividade.
1. Se a inicialização a quente falhar, o Auto Scaling tentará a inicialização a frio usando todos os tipos de instâncias restantes em sua política de instâncias mistas.
**Example**
**Exemplo**
Se você configurar seu grupo do Auto Scaling com 10 tipos de instâncias e seu grupo de alta atividade contiver 6 desses tipos de instâncias. Durante o aumento da escala na horizontal, o Auto Scaling primeiro experimenta os 6 tipos de instâncias do grupo de alta atividade. Se não obtiver êxito, o Auto Scaling tentará todos os tipos de instância configurados por meio de inicialização a frio.
Isso oferece benefícios de desempenho de grupo de alta atividade sempre que possível, mantendo a flexibilidade de sua configuração completa de instâncias mistas.
## Excluir um grupo de alta atividade
Quando você não precisar mais do pool ativo, use o procedimento a seguir para excluí-lo.
**Para excluir o grupo de alta atividade (console)**
1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)e escolha **Auto Scaling Groups** no painel de navegação.
1. Marque a caixa de seleção ao lado de um grupo existente.
Um painel dividido é aberto na parte inferior da página.
1. Selecione a guia **Instance management** (Gerenciamento de instâncias).
1. Em **Warm pool** (pool ativo), escolha **Actions** (Ações), **Delete** (Excluir).
1. Quando a confirmação for solicitada, escolha **Excluir**.
# Visualizar o status e o motivo de falhas da verificação de integridade
As verificações de integridade permitem que o Amazon EC2 Auto Scaling determine quando uma instância não está íntegra e deve ser terminada. Para instâncias de pool ativo mantidas em um estado `Stopped`, ele emprega o conhecimento que o Amazon EBS tem da disponibilidade de uma instância `Stopped` para identificar instâncias não íntegras. Ele faz isso chamando a API `DescribeVolumeStatus` para determinar o status do volume do EBS anexado à instância. Para instâncias de pool ativo mantidas em um estado `Running`, ele depende das verificações de status do EC2 para determinar a integridade da instância. Embora não haja período de carência de verificação de integridade para instâncias de pools ativos, o Amazon EC2 Auto Scaling não começará a verificar a integridade da instância até que o gancho do ciclo de vida seja concluído.
Quando uma instância não está íntegra, o Amazon EC2 Auto Scaling a exclui automaticamente e cria uma nova instância para substituí-la. Geralmente, as instâncias são terminadas dentro de alguns minutos após a falha na verificação de integridade. Para obter mais informações, consulte [Veja o motivo das falhas na verificação de integridade](replace-unhealthy-instance.md).
Verificações de integridade personalizadas também são aceitas. Isso poderá ser útil se você tiver seu próprio sistema de verificação de integridade capaz de detectar a integridade de uma instância e enviar essas informações para o Amazon EC2 Auto Scaling. Para obter mais informações, consulte [Configuração de uma verificação de integridade personalizada para seu grupo do Auto Scaling](set-up-a-custom-health-check.md).
No console do Amazon EC2 Auto Scaling, é possível visualizar o status (íntegra ou não íntegra) das instâncias do pool ativo. Você também pode ver o estado de saúde deles usando o AWS CLI ou um dos SDKs.
**Para visualizar o status das instâncias do grupo de alta atividade (console)**
1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)e escolha **Auto Scaling Groups** no painel de navegação.
1. Marque a caixa de seleção ao lado do grupo do Auto Scaling.
Um painel dividido é aberto na parte inferior da página **Auto Scaling groups** (Grupos do Auto Scaling).
1. Na guia **Instance management** (Gerenciamento de instâncias), em **Warm pool instances** (Instâncias do pool ativo), a coluna **Lifecycle** (Ciclo de vida) contém o estado das instâncias.
A coluna **Health status** (Status da integridade) mostra a avaliação da integridade da instância feita pelo Amazon EC2 Auto Scaling.
**nota**
As novas instâncias começam íntegras. Até que o gancho do ciclo de vida seja concluído, a integridade de uma instância não será verificada.
**Para visualizar o motivo das falhas de verificação de integridade (console)**
1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)e escolha **Auto Scaling Groups** no painel de navegação.
1. Marque a caixa de seleção ao lado do grupo do Auto Scaling.
Um painel dividido é aberto na parte inferior da página **Auto Scaling groups** (Grupos do Auto Scaling).
1. Na guia **Activity** (Atividade), em **Activity history** (Histórico de atividades), a coluna **Status** mostra se o seu grupo do Auto Scaling iniciou ou terminou instâncias com êxito.
Se ele terminou quaisquer instâncias não íntegras, a coluna **Cause** (Causa) mostrará a data e a hora do término e o motivo da falha na verificação de integridade. Por exemplo, "At 2021-04-01T21:48:35Z an instance was taken out of service in response to EBS volume health check failure" (Em 2021-04-01T 21:48:35 Z uma instância foi retirada de serviço em resposta a falha na verificação de integridade do volume do EBS).
**Para visualizar o status das instâncias do pool ativo (AWS CLI)**
Visualize a piscina aquecida de um grupo de Auto Scaling usando o comando a seguir [describe-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-warm-pool.html).
```
aws autoscaling describe-warm-pool --auto-scaling-group-name my-asg
```
Saída de exemplo.
```
{
"WarmPoolConfiguration": {
"MinSize": 0,
"PoolState": "Stopped"
},
"Instances": [
{
"InstanceId": "i-0b5e5e7521cfaa46c",
"InstanceType": "t2.micro",
"AvailabilityZone": "us-west-2a",
"LifecycleState": "Warmed:Stopped",
"HealthStatus": "Healthy",
"LaunchTemplate": {
"LaunchTemplateId": "lt-08c4cd42f320d5dcd",
"LaunchTemplateName": "my-template-for-auto-scaling",
"Version": "1"
}
},
{
"InstanceId": "i-0e21af9dcfb7aa6bf",
"InstanceType": "t2.micro",
"AvailabilityZone": "us-west-2a",
"LifecycleState": "Warmed:Stopped",
"HealthStatus": "Healthy",
"LaunchTemplate": {
"LaunchTemplateId": "lt-08c4cd42f320d5dcd",
"LaunchTemplateName": "my-template-for-auto-scaling",
"Version": "1"
}
}
]
}
```
**Para visualizar o motivo das falhas de verificação de integridade (AWS CLI)**
Use o seguinte comando [describe-scaling-activities](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-scaling-activities.html):
```
aws autoscaling describe-scaling-activities --auto-scaling-group-name my-asg
```
Esta é uma resposta de exemplo, em que `Description` indica que seu grupo do Auto Scaling encerrou uma instância e `Cause` indica o motivo da falha na verificação de integridade.
As ações de escalabilidade são ordenadas por horário de início. As atividades ainda em andamento são descritas primeiro.
```
{
"Activities": [
{
"ActivityId": "4c65e23d-a35a-4e7d-b6e4-2eaa8753dc12",
"AutoScalingGroupName": "my-asg",
"Description": "Terminating EC2 instance: i-04925c838b6438f14",
"Cause": "At 2021-04-01T21:48:35Z an instance was taken out of service in response to EBS volume health check failure.",
"StartTime": "2021-04-01T21:48:35.859Z",
"EndTime": "2021-04-01T21:49:18Z",
"StatusCode": "Successful",
"Progress": 100,
"Details": "{\"Subnet ID\":\"subnet-5ea0c127\",\"Availability Zone\":\"us-west-2a\"...}",
"AutoScalingGroupARN": "arn:aws:autoscaling:us-west-2:123456789012:autoScalingGroup:283179a2-f3ce-423d-93f6-66bb518232f7:autoScalingGroupName/my-asg"
},
...
]
}
```
# Exemplos para criar e gerenciar piscinas aquecidas com o AWS CLI
Você pode criar e gerenciar piscinas aquecidas usando o Console de gerenciamento da AWS, AWS Command Line Interface (AWS CLI) ou SDKs.
Os exemplos a seguir mostram como criar e gerenciar pools ativos usando a AWS CLI.
**Topics**
+ [Exemplo 1: manter instâncias no estado `Stopped`](#warm-pool-configuration-ex1)
+ [Exemplo 2: manter instâncias no estado `Running`](#warm-pool-configuration-ex2)
+ [Exemplo 3: manter instâncias no estado `Hibernated`](#warm-pool-configuration-ex3)
+ [Exemplo 4: retornar instâncias para o pool ativo ao reduzir a escala na horizontal](#warm-pool-configuration-ex4)
+ [Exemplo 5: especificar o número mínimo de instâncias no pool ativo](#warm-pool-configuration-ex5)
+ [Exemplo 6: Definir o tamanho do grupo dinâmico usando uma especificação personalizada.](#warm-pool-configuration-ex6)
+ [Exemplo 7: definir um tamanho de pool ativo absoluto](#warm-pool-configuration-ex7)
+ [Exemplo 8: exclusão um pool ativo](#delete-warm-pool-cli)
## Exemplo 1: manter instâncias no estado `Stopped`
O [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html)exemplo a seguir cria um pool aquecido que mantém as instâncias em um `Stopped` estado.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped
```
## Exemplo 2: manter instâncias no estado `Running`
O [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html)exemplo a seguir cria um pool aquecido que mantém as instâncias em um `Running` estado em vez de em um `Stopped` estado.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Running
```
## Exemplo 3: manter instâncias no estado `Hibernated`
O [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html)exemplo a seguir cria um pool aquecido que mantém as instâncias em um `Hibernated` estado em vez de em um `Stopped` estado. Isso permite interromper instâncias sem excluir o conteúdo da memória (RAM).
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Hibernated
```
## Exemplo 4: retornar instâncias para o pool ativo ao reduzir a escala na horizontal
O [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html)exemplo a seguir cria um pool aquecido que mantém as instâncias em um `Stopped` estado e inclui a `--instance-reuse-policy` opção. O valor da política de reutilização de instâncias `'{"ReuseOnScaleIn": true}'` informa ao Amazon EC2 Auto Scaling para devolver as instâncias ao pool ativo quando o grupo do Auto Scaling reduz a escala na horizontal.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --instance-reuse-policy '{"ReuseOnScaleIn": true}'
```
## Exemplo 5: especificar o número mínimo de instâncias no pool ativo
O [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html)exemplo a seguir cria um pool aquecido que mantém no mínimo 4 instâncias, para que haja pelo menos 4 instâncias disponíveis para lidar com picos de tráfego.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --min-size 4
```
## Exemplo 6: Definir o tamanho do grupo dinâmico usando uma especificação personalizada.
Por padrão, o Amazon EC2 Auto Scaling gerencia o tamanho do seu grupo dinâmico como a diferença entre a capacidade máxima e a desejada do grupo do Auto Scaling. No entanto, você pode gerenciar o tamanho do grupo dinâmico independentemente da sua capacidade máxima, usando a opção `--max-group-prepared-capacity`.
O [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html)exemplo a seguir cria um pool aquecido e define o número máximo de instâncias que podem existir simultaneamente no pool aquecido e no grupo Auto Scaling. Se o grupo tiver uma capacidade desejada de 800, o grupo dinâmico terá inicialmente um tamanho de 100 ao ser inicializado após a execução desse comando.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --max-group-prepared-capacity 900
```
Para manter um número mínimo de instâncias no pool ativo, inclua a opção `--min-size` com o comando, da seguinte forma.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --max-group-prepared-capacity 900 --min-size 25
```
## Exemplo 7: definir um tamanho de pool ativo absoluto
Se você definir os mesmos valores para as opções `--max-group-prepared-capacity` e `--min-size`, o pool ativo terá um tamanho absoluto. O [put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html)exemplo a seguir cria um pool quente que mantém um tamanho constante de pool quente de 10 instâncias.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --min-size 10 --max-group-prepared-capacity 10
```
## Exemplo 8: exclusão um pool ativo
Use o [delete-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-warm-pool.html)comando a seguir para excluir uma piscina aquecida.
```
aws autoscaling delete-warm-pool --auto-scaling-group-name my-asg
```
Se houver instâncias no pool aquecido ou se atividades de escalonamento estiverem em andamento, use o [delete-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-warm-pool.html)comando com a `--force-delete` opção. Essa opção também terminará as instâncias do Amazon EC2 e quaisquer ações do ciclo de vida pendentes.
```
aws autoscaling delete-warm-pool --auto-scaling-group-name my-asg --force-delete
```