# Uso do balanceamento de carga para distribuir o tráfego de serviço do Amazon ECS
O serviço Amazon ECS pode ser configurado opcionalmente para usar o Elastic Load Balancing para distribuir tráfego entre as tarefas do serviço igualmente.
**nota**
Quando você usa conjuntos de tarefas, todas as tarefas do conjunto devem ser configuradas para usar o Elastic Load Balancing ou para não usar o Elastic Load Balancing.
Os serviços do Amazon ECS hospedados no AWS Fargate oferecem suporte a Application Load Balancers, Network Load Balancers e Gateway Load Balancers. Use a tabela apresentada a seguir para descobrir qual tipo de balanceador de carga usar.
| Tipo de balanceador de carga | Uso para estes casos |
| --- | --- |
| Application Load Balancer | Roteamento do tráfego HTTP/HTTPS (ou da camada 7).Os application load balancers oferecem vários recursos que os tornam atrativos para uso com serviços do Amazon ECS: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/service-load-balancing.html) |
| Network Load Balancer | Roteamento do tráfego TCP ou UDP (ou da camada 4). |
| Balanceador de carga de gateway | Roteamento do tráfego TCP ou UDP (ou da camada 4). Use dispositivos virtuais, como firewalls, sistemas de detecção e prevenção de intrusão e sistemas de inspeção profunda de pacotes. |
Recomendamos usar Application Load Balancers nos serviços do Amazon ECS para aproveitar os recursos mais recentes, a menos que seu serviço exija um recurso que esteja disponível apenas com Network Load Balancers ou Gateway Load Balancers. Para obter mais informações sobre Elastic Load Balancing e as diferenças entre esses tipos de balanceadores de carga, consulte o [Guia do usuário do Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/).
Com o load balancer, você paga somente pelo que utilizar. Para obter mais informações, consulte [Preço do Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/pricing/).
# Otimização dos parâmetros de verificação de integridade do balanceador de carga para o Amazon ECS
Os balanceadores de carga encaminham solicitações apenas para os destinos íntegros nas zonas de disponibilidade do balanceador de carga. Cada destino é registrado em um grupo de destino. O balanceador de carga verifica a integridade de cada destino usando as configurações de verificação de integridade do grupo de destino. Após você registrar o destino, ele deverá ser aprovado por uma verificação de integridade para ser considerado íntegro. O Amazon ECS realiza o monitoramento do balanceador de carga. O balanceador de carga envia periodicamente verificações de integridade para o contêiner do Amazon ECS. O agente do Amazon ECS monitora e aguarda que o balanceador de carga informe sobre a integridade do contêiner. Ele faz isso antes de considerar que o contêiner está em um estado íntegro.
Dois parâmetros de verificação de integridade do Elastic Load Balancing afetam a velocidade de implantação:
+ Intervalo da verificação de integridade: determina o tempo aproximado, em segundos, entre verificações de integridade de um contêiner individual. Por padrão, o balanceador de carga verifica a cada 30 segundos.
Esse parâmetro é denominado:
+ `HealthCheckIntervalSeconds` na API do Elastic Load Balancing
+ **Intervalo** no console do Amazon EC2
+ Contagem de limites íntegros: determina o número de verificações de integridade consecutivas bem-sucedidas necessárias para que um contêiner não íntegro seja considerado íntegro. Por padrão, o balanceador de carga exige cinco verificações de integridade aprovadas antes de informar que o contêiner de destino está íntegro.
Esse parâmetro é denominado:
+ `HealthyThresholdCount` na API do Elastic Load Balancing
+ **Limite íntegro** no console do Amazon EC2
**Importante:** para destinos recém-registrados, é necessária apenas uma verificação de integridade bem-sucedida para considerar o destino íntegro, independentemente da configuração da contagem de limiar de integridade. A contagem de limiar de integridade só se aplica quando um destino estiver fazendo a transição de um estado não íntegro para um estado íntegro.
Com as configurações padrão, se um destino perder a integridade e então se recuperar, o tempo total para determinar a integridade de um contêiner será de 2 minutos e 30 segundos (`30 seconds * 5 = 150 seconds`).
Você pode acelerar o processo de verificação de integridade se o serviço for inicializado e estabilizado em menos de 10 segundos. Para acelerar o processo, reduza o intervalo de verificação de integridade e a contagem de limite de integridade.
+ `HealthCheckIntervalSeconds` (nome da API do Elastic Load Balancing) ou **Intervalo** (nome do console do Amazon EC2): 5
+ `HealthyThresholdCount` (nome da API do Elastic Load Balancing) ou **Limite íntegro** (nome do console do Amazon EC2): 2
Com essa configuração, o processo de verificação de integridade leva 10 segundos quando comparado ao padrão de 2 minutos e 30 segundos.
Para obter mais informações sobre os parâmetros de verificação de integridade do Elastic Load Balancing, consulte [Health checks for your target groups](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html) no *Guia do usuário do Elastic Load Balancing*.
# Otimização de parâmetros de drenagem da conexão do balanceador de carga para o Amazon ECS
Para permitir a otimização, os clientes mantêm uma conexão keep alive com o serviço de contêiner. Isto permite que solicitações subsequentes desse cliente reutilizem a conexão existente. Quando quiser interromper o tráfego de um contêiner, você notifica o balanceador de carga. O balanceador de carga verifica periodicamente se o cliente fechou a conexão keep-alive. O Amazon ECS monitora o balanceador de carga e aguarda que ele informe que a conexão keep alive está fechada (o destino está em um estado `UNUSED`).
A quantidade de tempo que o balanceador de carga aguarda para mover o destino para o estado `UNUSED` equivale ao atraso no cancelamento do registro. Você pode configurar o parâmetro do balanceador de carga a seguir para acelerar as implantações.
+ `deregistration_delay.timeout_seconds`: 300 (padrão)
Quando houver um serviço com um tempo de resposta inferior a 1 segundo, defina o parâmetro com o seguinte valor para que o balanceador de carga espere apenas cinco segundos antes de interromper a conexão entre o cliente e o serviço de backend:
+ `deregistration_delay.timeout_seconds`: 5
**nota**
Não defina o valor como cinco segundos quando tiver um serviço com solicitações de longa duração, como uploads lentos de arquivos ou conexões de fluxo.
## Capacidade de resposta do SIGTERM
O Amazon ECS primeiro envia um sinal de parada à tarefa para notificar que a aplicação precisa ser concluída e encerrada. Esse sinal pode ser definido na imagem do contêiner com a instrução STOPSIGNAL e terá como padrão SIGTERM. Em seguida, o Amazon ECS envia uma mensagem de SIGKILL. Quando as aplicações ignoram o SIGTERM, o serviço do Amazon ECS deve esperar para enviar o sinal de SIGKILL antes de encerrar o processo.
O tempo que o Amazon ECS espera para enviar a mensagem de SIGKILL é determinado pela seguinte opção de agente do Amazon ECS:
+ `ECS_CONTAINER_STOP_TIMEOUT`: 30 (padrão)
Para obter mais informações sobre o parâmetro do agente de contêiner, consulte [Amazon ECS Container Agent](https://github.com/aws/amazon-ecs-agent/blob/master/README.md) no GitHub.
Para acelerar o período de espera, defina o parâmetro do agente do Amazon ECS com o seguinte valor:
+ `ECS_CONTAINER_STOP_TIMEOUT`: 2
Se a aplicação levar mais de um segundo, multiplique o valor por dois e use esse número como valor.
Nesse caso, o Amazon ECS aguarda dois segundos para que o contêiner seja desligado e, em seguida, envia uma mensagem de SIGKILL quando a aplicação não é interrompida.
Você também pode modificar o código da aplicação para capturar o sinal de SIGTERM e reagir a ele. O seguinte exemplo está em JavaScript:
```
process.on('SIGTERM', function() {
server.close();
})
```
Esse código faz com que o servidor HTTP pare de receber novas solicitações, termine de responder a todas as solicitações em andamento e, em seguida, encerra o processo Node.js porque o loop de eventos não tem nada para fazer. Diante disso, se o processo levar apenas 500 ms para concluir as solicitações em andamento, ele é encerrado mais cedo, sem precisar esperar o tempo limite de encerramento e receber um SIGKILL.
# Uso de um Application Load Balancer do Amazon ECS
Um Application Load Balancer toma decisões de roteamento na camada da aplicação (HTTP/HTTPS), oferece suporte ao roteamento com base em caminho e pode encaminhar solicitações para uma ou mais portas em cada instância de contêiner no cluster. Os application load balancers oferecem suporte ao mapeamento de porta de host dinâmico. Por exemplo, se a definição de contêiner da tarefa especifica a porta 80 para uma porta de contêiner NGINX e a porta 0 para a porta do host, a porta do host é escolhida dinamicamente com base no intervalo de portas temporário da instância de contêiner (como entre 32768 e 61000 na AMI otimizado para Amazon ECS mais recente). Quando a tarefa é iniciada, o contêiner NGINX é registrado no Application Load Balancer como uma combinação entre o ID da instância e a porta, e o tráfego é distribuído para o ID da instância e para a porta correspondente a esse contêiner. Esse mapeamento dinâmico permite várias tarefas de um único serviço na mesma instância de contêiner. Para obter mais informações, consulte o [Guia do usuário para application load balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/).
Para obter informações sobre as práticas recomendadas para a definição de parâmetros a fim de acelerar as implantações, consulte:
+ [Otimização dos parâmetros de verificação de integridade do balanceador de carga para o Amazon ECS](load-balancer-healthcheck.md)
+ [Otimização de parâmetros de drenagem da conexão do balanceador de carga para o Amazon ECS](load-balancer-connection-draining.md)
Considere o seguinte ao usar Application Load Balancers com o Amazon ECS:
+ O Amazon ECS exige a função do IAM vinculada ao serviço, que fornece as permissões necessárias para registrar e cancelar o registro de destinos com o balanceador de carga quando as tarefas são criadas e interrompidas. Para obter mais informações, consulte [Uso de perfis vinculados ao serviço para o Amazon ECS](using-service-linked-roles.md).
+ Para serviços em uma configuração somente IPv6, você deve definir o tipo de endereço IP do grupo de destino do Application Load Balancer como `dualstack` ou `dualstack-without-public-ipv4`.
+ Para serviços com tarefas que usam o modo de rede `awsvpc`, ao criar um grupo de destino para o serviço, é necessário escolher `ip` como o tipo de destino, e não `instance`. Isso ocorre porque as tarefas que usam o modo de rede `awsvpc` estão associadas a uma interface de rede elástica, e não a uma instância do Amazon EC2.
+ Se o serviço requerer acesso a diversas portas com balanceamento de carga, como a porta 80 e a porta 443 para um serviço HTTP/HTTPS, será possível configurar dois receptores. Um listener é responsável pelo HTTPS que encaminha a solicitação para o serviço e outro listener que é responsável por redirecionar solicitações HTTP para a porta HTTPS apropriada. Para obter mais informações, consulte [Criar um listener no Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-listener.html) no *Guia do usuário dos Application Load Balancers*.
+ A configuração de sub-rede do load balancer deve incluir todas as zonas de disponibilidade nas quais as instâncias de contêiner residem.
+ Após você criar um serviço, a configuração do balanceador de carga não poderá ser alterada no Console de gerenciamento da AWS. É possível usar o AWS Copilot, o AWS CloudFormation, a AWS CLI ou o SDK para modificar a configuração do balanceador de carga somente para o controlador de implantação rolling do `ECS`, e não o AWS CodeDeploy azul/verde ou externo. Quando você adiciona, atualiza ou remove uma configuração de balanceador de carga, o Amazon ECS inicia uma nova implantação com a configuração atualizada do Elastic Load Balancing. Isso faz com que as tarefas se registrem e cancelem o registro dos balanceadores de carga. Recomendamos verificar isso em um ambiente de teste antes de atualizar a configuração do Elastic Load Balancing. Para obter informações sobre como modificar a configuração, consulte [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) na *Referência da API do Amazon Elastic Container Service*.
+ Caso a tarefa de um serviço não passe nos critérios de verificação de integridade do balanceador de carga, a tarefa é interrompida e reiniciada. Esse processo continuará até que o serviço alcance o número de tarefas em execução desejadas.
+ Caso você esteja enfrentando problemas com os serviços habilitados pelo balanceador de carga, consulte [Solução de problemas relacionados aos balanceadores de carga de serviço no Amazon ECS](troubleshoot-service-load-balancers.md).
+ Ao usar o tipo de destino `instance`, as tarefas e o balanceador de carga devem estar na mesma VPC. Ao usar o tipo de destino `ip`, há suporte para conectividade entre VPCs.
+ Use um grupo de destino exclusivo para cada serviço.
Usar o mesmo grupo de destino para vários serviços pode causar problemas durante a implantação do serviço.
+ Especifique grupos de destino que estejam associados a um Application Load Balancer.
Para obter informações sobre como criar um Application Load Balancer, consulte [Create an Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) em *Application Load Balancers*
# Uso de um Network Load Balancer no Amazon ECS
Um Network Load Balancer toma decisões de roteamento na camada de transporte (TCP/SSL). Ele pode lidar com milhões de solicitações por segundo. Após o load balancer receber uma conexão, ele seleciona um destino do grupo de destino para a regra padrão usando um algoritmo de roteamento de hash de fluxo. Ele tenta abrir uma conexão TCP para o destino selecionado na porta especificada na configuração do listener. Ele encaminha a solicitação sem modificar os cabeçalhos. Os network load balancers oferecem suporte ao mapeamento de porta de host dinâmico. Por exemplo, se a definição de contêiner da tarefa especifica a porta 80 para uma porta de contêiner NGINX e a porta 0 para a porta do host, a porta do host é escolhida dinamicamente com base no intervalo de portas temporário da instância de contêiner (como entre 32768 e 61000 na AMI otimizado para Amazon ECS mais recente). Quando a tarefa é inicializada, o contêiner NGINX é registrado no Network Load Balancer como uma combinação de ID e porta da instância, e o tráfego é distribuído para o ID e para a porta da instância correspondentes a este contêiner. Esse mapeamento dinâmico permite várias tarefas de um único serviço na mesma instância de contêiner. Para obter mais informações, consulte o [Guia do usuário de network load balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/).
Para obter informações sobre as práticas recomendadas para a definição de parâmetros a fim de acelerar as implantações, consulte:
+ [Otimização dos parâmetros de verificação de integridade do balanceador de carga para o Amazon ECS](load-balancer-healthcheck.md)
+ [Otimização de parâmetros de drenagem da conexão do balanceador de carga para o Amazon ECS](load-balancer-connection-draining.md)
Considere o seguinte ao usar Network Load Balancers com o Amazon ECS:
+ O Amazon ECS exige a função do IAM vinculada ao serviço, que fornece as permissões necessárias para registrar e cancelar o registro de destinos com o balanceador de carga quando as tarefas são criadas e interrompidas. Para obter mais informações, consulte [Uso de perfis vinculados ao serviço para o Amazon ECS](using-service-linked-roles.md).
+ Não é possível anexar mais de cinco grupos de destino a um serviço.
+ Para serviços em uma configuração somente IPv6, você deve definir o tipo de endereço IP do grupo de destino do Network Load Balancer como `dualstack`.
+ Para serviços com tarefas que usam o modo de rede `awsvpc`, ao criar um grupo de destino para o serviço, é necessário escolher `ip` como o tipo de destino, e não `instance`. Isso ocorre porque as tarefas que usam o modo de rede `awsvpc` estão associadas a uma interface de rede elástica, e não a uma instância do Amazon EC2.
+ A configuração de sub-rede do load balancer deve incluir todas as zonas de disponibilidade nas quais as instâncias de contêiner residem.
+ Após você criar um serviço, a configuração do balanceador de carga não poderá ser alterada no Console de gerenciamento da AWS. É possível usar o AWS Copilot, o AWS CloudFormation, a AWS CLI ou o SDK para modificar a configuração do balanceador de carga somente para o controlador de implantação rolling do `ECS`, e não o AWS CodeDeploy azul/verde ou externo. Quando você adiciona, atualiza ou remove uma configuração de balanceador de carga, o Amazon ECS inicia uma nova implantação com a configuração atualizada do Elastic Load Balancing. Isso faz com que as tarefas se registrem e cancelem o registro dos balanceadores de carga. Recomendamos verificar isso em um ambiente de teste antes de atualizar a configuração do Elastic Load Balancing. Para obter informações sobre como modificar a configuração, consulte [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) na *Referência da API do Amazon Elastic Container Service*.
+ Caso a tarefa de um serviço não passe nos critérios de verificação de integridade do balanceador de carga, a tarefa é interrompida e reiniciada. Esse processo continuará até que o serviço alcance o número de tarefas em execução desejadas.
+ Ao usar um Gateway Load Balancer configurado com endereços IP como destinos e a Preservação do IP do Cliente desativada, as solicitações parecem se originar do endereço IP privado do Gateway Load Balancers. Isso significa que, ao permitir solicitações de entrada e verificações de integridade no grupo de segurança de destino, os serviços protegidos por um Gateway Load Balancer ficam efetivamente expostos.
+ Para tarefas do Fargate, você deve usar a versão da plataforma `1.4.0` (Linux) ou `1.0.0` (Windows).
+ Caso você esteja enfrentando problemas com os serviços habilitados pelo balanceador de carga, consulte [Solução de problemas relacionados aos balanceadores de carga de serviço no Amazon ECS](troubleshoot-service-load-balancers.md).
+ Ao usar o tipo de destino `instance`, as tarefas e o balanceador de carga devem estar na mesma VPC. Ao usar o tipo de destino `ip`, há suporte para conectividade entre VPCs.
+ A preservação do endereço IP do cliente do Network Load Balancer é compatível com os destinos do Fargate.
+ Use um grupo de destino exclusivo para cada serviço.
Usar o mesmo grupo de destino para vários serviços pode causar problemas durante a implantação do serviço.
+ Você deve especificar grupos de destino que estejam associados a um Network Load Balancer.
Para obter informações sobre como criar um Network Load Balancer, consulte [Create a Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html) em *Network Load Balancers*
**Importante**
Se a definição de tarefa do serviço usar o modo de rede `awsvpc` (exigido para o Fargate), será preciso escolher `ip` como tipo de destino, e não `instance`. Isso ocorre porque as tarefas que usam o modo de rede `awsvpc` estão associadas a uma interface de rede elástica, e não a uma instância do Amazon EC2.
Você não pode registrar instâncias por ID de instância se eles tiverem os seguintes tipos de instância: C1, CC1, CC2, CG1, CG2, CR1, G1, G2, HI1, HS1, M1, M2, M3 e T1. É possível registrar instâncias desses tipos por endereço IP.
# Uso de um Gateway Load Balancer para o Amazon ECS
Um balanceador de carga de gateway opera na terceira camada do modelo Open Systems Interconnection (OSI), a camada de rede. Ele escuta todos os pacotes IP em todas as portas e encaminha o tráfego para o grupo de destino especificado na regra do listener. Ele mantém a perdurabilidade dos fluxos para um dispositivo de destino específico usando 5 tuplas (para fluxos TCP/UDP) ou 3 tuplas (para fluxos não TCP/UDP). Por exemplo, se a definição de contêiner da tarefa especifica a porta 80 para uma porta de contêiner NGINX e a porta 0 para a porta do host, a porta do host é escolhida dinamicamente com base no intervalo de portas temporário da instância de contêiner (como entre 32768 e 61000 na AMI otimizado para Amazon ECS mais recente). Quando a tarefa é iniciada, o contêiner NGINX é registrado no Gateway Load Balancer como uma combinação entre o ID da instância e a porta, e o tráfego é distribuído para o ID da instância e para a porta correspondente a esse contêiner. Esse mapeamento dinâmico permite várias tarefas de um único serviço na mesma instância de contêiner. Para obter mais informações, consulte [What is a Gateway Load Balancer?](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html) em *Gateway Load Balancers*.
Para obter informações sobre as práticas recomendadas para a definição de parâmetros a fim de acelerar as implantações, consulte:
+ [Otimização dos parâmetros de verificação de integridade do balanceador de carga para o Amazon ECS](load-balancer-healthcheck.md)
+ [Otimização de parâmetros de drenagem da conexão do balanceador de carga para o Amazon ECS](load-balancer-connection-draining.md)
Considere o seguinte ao usar Gateway Load Balancers com o Amazon ECS:
+ O Amazon ECS exige a função do IAM vinculada ao serviço, que fornece as permissões necessárias para registrar e cancelar o registro de destinos com o balanceador de carga quando as tarefas são criadas e interrompidas. Para obter mais informações, consulte [Uso de perfis vinculados ao serviço para o Amazon ECS](using-service-linked-roles.md).
+ Para serviços em uma configuração somente IPv6, você deve definir o tipo de endereço IP do grupo de destino do Gateway Load Balancer como `dualstack`.
+ Balanceadores de carga de gateway não são compatíveis com serviços com tarefas que não usam `awsvpc`, mas outro modo de rede.
+ A configuração de sub-rede do load balancer deve incluir todas as zonas de disponibilidade nas quais as instâncias de contêiner residem.
+ Após você criar um serviço, a configuração do balanceador de carga não poderá ser alterada no Console de gerenciamento da AWS. É possível usar o AWS Copilot, o AWS CloudFormation, a AWS CLI ou o SDK para modificar a configuração do balanceador de carga somente para o controlador de implantação rolling do `ECS`, e não o AWS CodeDeploy azul/verde ou externo. Quando você adiciona, atualiza ou remove uma configuração de balanceador de carga, o Amazon ECS inicia uma nova implantação com a configuração atualizada do Elastic Load Balancing. Isso faz com que as tarefas se registrem e cancelem o registro dos balanceadores de carga. Recomendamos verificar isso em um ambiente de teste antes de atualizar a configuração do Elastic Load Balancing. Para obter informações sobre como modificar a configuração, consulte [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) na *Referência da API do Amazon Elastic Container Service*.
+ Caso a tarefa de um serviço não passe nos critérios de verificação de integridade do balanceador de carga, a tarefa é interrompida e reiniciada. Esse processo continuará até que o serviço alcance o número de tarefas em execução desejadas.
+ Ao usar um Gateway Load Balancer configurado com endereços IP como destinos, as solicitações parecem se originar do endereço IP privado do Gateway Load Balancers. Isso significa que, ao permitir solicitações de entrada e verificações de integridade no grupo de segurança de destino, os serviços protegidos por um Gateway Load Balancer ficam efetivamente expostos.
+ Para tarefas do Fargate, você deve usar a versão da plataforma `1.4.0` (Linux) ou `1.0.0` (Windows).
+ Caso você esteja enfrentando problemas com os serviços habilitados pelo balanceador de carga, consulte [Solução de problemas relacionados aos balanceadores de carga de serviço no Amazon ECS](troubleshoot-service-load-balancers.md).
+ Ao usar o tipo de destino `instance`, as tarefas e o balanceador de carga devem estar na mesma VPC. Ao usar o tipo de destino `ip`, há suporte para conectividade entre VPCs.
+ Use um grupo de destino exclusivo para cada serviço.
Usar o mesmo grupo de destino para vários serviços pode causar problemas durante a implantação do serviço.
+ Você deve especificar grupos de destino associados a um Gateway Load Balancer.
Para obter informações sobre como criar um Gateway Load Balancer, consulte [Introdução a Gateway Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/getting-started.html) em *Gateway Load Balancers*
**Importante**
Se a definição de tarefa do serviço usar o modo de rede `awsvpc` (exigido para o Fargate), será preciso escolher `ip` como tipo de destino, e não `instance`. Isso ocorre porque as tarefas que usam o modo de rede `awsvpc` estão associadas a uma interface de rede elástica, e não a uma instância do Amazon EC2.
Você não pode registrar instâncias por ID de instância se eles tiverem os seguintes tipos de instância: C1, CC1, CC2, CG1, CG2, CR1, G1, G2, HI1, HS1, M1, M2, M3 e T1. É possível registrar instâncias desses tipos por endereço IP.
# Registrar vários grupos de destino em um serviço Amazon ECS
O serviço do Amazon ECS pode atender ao tráfego de vários balanceadores de carga e expor várias portas com balanceamento de carga quando você especificar vários grupos de destino em uma definição de serviço.
Para criar um serviço que especifique vários grupos de destino, é necessário criar o serviço usando a API do Amazon ECS, o SDK, a AWS CLI ou um modelo do CloudFormation. Depois que o serviço é criado, você pode visualizar o serviço e os grupos de destino registrados nele com o Console de gerenciamento da AWS. Você deve usar `[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)` para modificar a configuração do balanceador de carga de um serviço existente.
Vários grupos de destino podem ser especificados em uma definição de serviço usando o seguinte formato. Para obter a sintaxe completa de uma definição de serviço, consulte [Modelo de definição de serviço](sd-template.md).
```
"loadBalancers":[
{
"targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
"containerName":"container_name",
"containerPort":container_port
},
{
"targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
"containerName":"container_name",
"containerPort":container_port
}
]
```
## Considerações
Quando você especificar vários grupos de destino em uma definição de serviço, considere o seguinte.
+ Para serviços que usam um Application Load Balancer ou um Network Load Balancer, não é possível anexar mais de cinco grupos de destino a um serviço.
+ Especificar vários grupos de destino em uma definição de serviço só é compatível com as seguintes condições:
+ O serviço deve usar um Application Load Balancer ou um Network Load Balancer.
+ O serviço deve usar o tipo de controlador de implantação (`ECS`). Isso pode ser a implantação nativa/azul verde do Amazon ECS ou a implantação de atualização contínua.
+ Especificar vários grupos de destino é compatível com serviços que contêm tarefas que usam os tipos de inicialização do Fargate e do EC2.
+ Quando você criar um serviço que especifica vários grupos de destino, deverá ser criada a função vinculada ao serviço do Amazon ECS. A função é criada omitindo o parâmetro `role` nas solicitações de API ou a propriedade `Role` no CloudFormation. Para obter mais informações, consulte [Uso de perfis vinculados ao serviço para o Amazon ECS](using-service-linked-roles.md).
## Exemplos de definições de serviço
Veja a seguir alguns exemplos de casos de uso para especificar vários grupos de destino em uma definição de serviço. Para obter a sintaxe completa de uma definição de serviço, consulte [Modelo de definição de serviço](sd-template.md).
### Ter balanceadores de carga separados para tráfego interno e externo
No seguinte caso de uso, um serviço usa dois load balancers, um para tráfego interno e um segundo para tráfego voltado para a Internet, para o mesmo contêiner e porta.
```
"loadBalancers":[
//Internal ELB
{
"targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
"containerName":"nginx",
"containerPort":8080
},
//Internet-facing ELB
{
"targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
"containerName":"nginx",
"containerPort":8080
}
]
```
### Expor várias portas do mesmo contêiner
No seguinte caso de uso, um serviço usa um load balancer, mas expõe várias portas do mesmo contêiner. Por exemplo, um contêiner Jenkins pode expor a porta 8080 para a interface da Web do Jenkins e a porta 50000 para a API.
```
"loadBalancers":[
{
"targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
"containerName":"jenkins",
"containerPort":8080
},
{
"targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
"containerName":"jenkins",
"containerPort":50000
}
]
```
### Expor portas de vários contêineres
No seguinte caso de uso, um serviço usa um load balancer e dois grupos de destino para expor portas de contêineres separados.
```
"loadBalancers":[
{
"targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
"containerName":"webserver",
"containerPort":80
},
{
"targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
"containerName":"database",
"containerPort":3306
}
]
```