# Arquitetura da AWS Fargate para o Amazon ECS
O AWS Fargate é uma tecnologia que pode ser usada com o Amazon ECS para executar [contêineres](https://aws.amazon.com/containers/) sem a necessidade de gerenciar servidores ou clusters de instâncias do Amazon EC2. Com o AWS Fargate, não é mais necessário provisionar, configurar nem dimensionar os clusters de máquinas virtuais para executar contêineres. Isso elimina a necessidade de escolher tipos de servidor, decidir quando dimensionar clusters ou otimizar o agrupamento de clusters.
Ao executar tarefas e serviços com o Fargate, você empacota sua aplicação em contêineres, especifica os requisitos de CPU e de memória, define as políticas de rede e do IAM e inicia a aplicação. Cada tarefa do Fargate tem seu próprio limite de isolamento e não compartilha o kernel subjacente, os recursos de CPU, os recursos de memória nem a interface de rede elástica com outra tarefa. Você configura suas definições de tarefas para o Fargate configurando o parâmetro de definição de tarefa `requiresCompatibilities` como `FARGATE`. Para obter mais informações, consulte [Capacidade](task_definition_parameters.md#requires_compatibilities).
O Fargate oferece versões da plataforma para o Amazon Linux 2 (1.3.0), sistema operacional Bottlerocket (1.4.0) e as edições Full e Core do Microsoft Windows Server 2019. A menos que especificado de outra maneira, as informações são aplicáveis a todas as plataformas do Fargate.
Para obter informações sobre as regiões que oferecem suporte a contêineres de Linux no Fargate, consulte [Contêineres do Linux no AWS Fargate](AWS_Fargate-Regions.md#linux-regions).
Para obter informações sobre as regiões que oferecem suporte a contêineres de Windows no Fargate, consulte [Contêineres do Windows no AWS Fargate](AWS_Fargate-Regions.md#windows-regions).
## Instruções
Para obter informações sobre como começar a usar o console, consulte:
+ [Como criar uma tarefa do Linux no Amazon ECS para o Fargate](getting-started-fargate.md)
+ [Como criar uma tarefa do Amazon ECS Windows para o Fargate](Windows_fargate-getting_started.md)
Para obter informações sobre como começar a usar a AWS CLI, consulte:
+ [Criar uma tarefa do Linux do Amazon ECS para o Fargate com a AWS CLI](ECS_AWSCLI_Fargate.md)
+ [Criar uma tarefa do Windows do Amazon ECS para o Fargate com a AWS CLI](ECS_AWSCLI_Fargate_windows.md)
## Provedores de capacidade
Os seguintes provedores de capacidade estão disponíveis:
+ Fargate
+ Fargate Spot: executa tarefas tolerantes a interrupções do Amazon ECS com uma taxa de desconto em comparação ao preço do AWS Fargate. O Fargate Spot executa tarefas com capacidade adicional de computação. Quando a AWS precisar da capacidade de volta, suas tarefas serão interrompidas com um aviso de dois minutos. Para obter mais informações, consulte [Clusters do Amazon ECS para Fargate](fargate-capacity-providers.md).
## Definições de tarefa
As tarefas do Fargate não oferecem suporte a todos os parâmetros de definição de tarefa do Amazon ECS que estão disponíveis. Alguns parâmetros são totalmente incompatíveis e outros se comportam de maneira diferente nas tarefas do Fargate. Para obter mais informações, consulte [CPU e memória da tarefa](fargate-tasks-services.md#fargate-tasks-size).
## Versões da plataforma
As versões da plataforma do AWS Fargate são usadas para fazer referência a um ambiente de runtime para a infraestrutura de tarefas do Fargate. Trata-se de uma combinação da versão do kernel e do runtime do contêiner. Você seleciona uma versão da plataforma ao executar uma tarefa ou ao criar um serviço para manter várias tarefas idênticas.
Novas revisões de versões da plataforma são lançadas conforme o ambiente do runtime evolui, por exemplo, em caso de atualizações no kernel ou no sistema operacional, novos recursos, correções de erros ou atualizações de segurança. Uma versão da plataforma Fargate é atualizada por meio de uma nova revisão da versão da plataforma. Cada tarefa é executada em uma revisão de versão da plataforma durante seu ciclo de vida. Se você quiser usar a revisão mais recente da versão da plataforma, será necessário iniciar uma nova tarefa. Uma nova tarefa executada no Fargate sempre é executada na revisão mais recente de uma versão da plataforma, garantindo que as tarefas sejam sempre iniciadas em uma infraestrutura segura e corrigida.
Se houver um problema de segurança que afete uma versão existente da plataforma, a AWS vai criar uma nova revisão corrigida da versão da plataforma e retirar as tarefas em execução na revisão vulnerável. Em alguns casos, será possível receber notificações de que suas tarefas no Fargate foram programadas para retirada. Para obter mais informações, consulte [Retirada e manutenção de tarefas para o AWS Fargate no Amazon ECS](task-maintenance.md).
Para obter mais informações, consulte [Versões da plataforma do Fargate para o Amazon ECS](platform-fargate.md).
## Balanceamento de carga do serviço
O serviço do Amazon ECS no AWS Fargate pode ser configurado opcionalmente para usar o Elastic Load Balancing para distribuir o tráfego uniformemente entre as tarefas do serviço.
Os serviços do Amazon ECS no AWS Fargate oferecem suporte aos tipos balanceadores de carga Application Load Balancer, Network Load Balancer e Gateway Load Balancer. Application Load Balancers são usados para encaminhar o tráfego HTTP/HTTPS (ou camada 7). Os Network Load Balancers são usados para encaminhar o tráfego TCP ou UDP (ou camada 4). Para obter mais informações, consulte [Uso do balanceamento de carga para distribuir o tráfego de serviço do Amazon ECS](service-load-balancing.md).
Ao criar grupos de destino para esses serviços, você precisa 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. Para obter mais informações, consulte [Uso do balanceamento de carga para distribuir o tráfego de serviço do Amazon ECS](service-load-balancing.md).
O uso de um Network Load Balancer para encaminhar o tráfego UDP para tarefas do Amazon ECS no AWS Fargate só será compatível quando for usada a versão 1.4 da plataforma, ou posterior.
## Métricas de uso
É possível usar métricas de uso do CloudWatch para fornecer visibilidade sobre o uso dos recursos da sua conta. Use essas métricas para visualizar o uso do serviço atual nos gráficos e painéis do CloudWatch.
As métricas de uso do AWS Fargate correspondem às cotas de serviço da AWS. Também é possível configurar alarmes que alertem você quando o uso se aproximar de uma cota de serviço. Para obter mais informações sobre cotas de serviço do AWS Fargate, consulte [Endpoints e cotas do Amazon ECS](https://docs.aws.amazon.com/general/latest/gr/ecs-service.html) no *Referência geral da Amazon Web Services*.
Para obter mais informações sobre métricas de uso do AWS Fargate, consulte [Métricas de uso do AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/monitoring-fargate-usage.html).
# Considerações de segurança do Amazon ECS sobre quando usar o Fargate
Recomendamos que os clientes que buscam um forte isolamento para as tarefas usem o Fargate. O Fargate executa cada tarefa em um ambiente de virtualização de hardware. Isso garante que essas workloads em contêineres não compartilhem interfaces de rede, armazenamento temporário do Fargate, CPU ou memória com outras tarefas. Para obter mais informações, consulte [Security Overview of AWS Fargate](https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf).
# Práticas recomendadas de segurança do Fargate no Amazon ECS
Recomendamos que você leve em consideração as práticas recomendadas a seguir ao usar o AWS Fargate. Para obter orientação adicional, consulte [Visão geral de segurança do AWS Fargate](https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf).
## Uso do AWS KMS para criptografar o armazenamento temporário para o Fargate
Você deve ter seu armazenamento temporário criptografado por um AWS KMS ou por suas próprias chaves gerenciadas pelo cliente. Para tarefas hospedadas no Fargate usando a versão da plataforma `1.4.0` ou posterior, cada tarefa recebe 20 GiB de armazenamento efêmero. Para obter mais informações, consulte [chave gerenciada pelo cliente (CMK)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-storage-encryption.html). É possível aumentar a quantidade total de armazenamento temporário, até um máximo de 200 GiB, com a especificação do parâmetro `ephemeralStorage` na definição da tarefa. Para tais tarefas que foram iniciadas desde 28 de maio de 2020, o armazenamento efêmero é criptografado com um algoritmo de criptografia AES-256 usando uma chave de criptografia gerenciada pelo Fargate.
Para obter mais informações, consulte [Opções para o armazenamento de tarefas do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_data_volumes.html).
**Exemplo: iniciar uma tarefa na versão da plataforma Fargate 1.4.0 com criptografia de armazenamento efêmero**
O comando a seguir iniciará uma tarefa na versão da plataforma Fargate 1.4. Como essa tarefa é iniciada como parte do cluster, ela usa 20 GiB do armazenamento efêmero que é criptografado automaticamente.
```
aws ecs run-task --cluster clustername \
--task-definition taskdefinition:version \
--count 1
--launch-type "FARGATE" \
--platform-version 1.4.0 \
--network-configuration "awsvpcConfiguration={subnets=[subnetid],securityGroups=[securitygroupid]}" \
--region region
```
## Funcionalidade SYS\$1PTRACE para rastreamento de chamada de sistema do kernel com o Fargate
A configuração padrão dos recursos do Linux adicionados ou removidos do seu contêiner é fornecida pelo Docker.
As tarefas executadas no Fargate são compatíveis apenas com a adição do recurso kernel do `SYS_PTRACE`.
O vídeo apresentado abaixo mostra como usar esse recurso por meio do projeto [Falco](https://github.com/falcosecurity/falco) da Sysdig.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/OYGKjmFeLqI)
O código discutido no vídeo anterior pode ser encontrado no GitHub [aqui](https://github.com/paavan98pm/ecs-fargate-pv1.4-falco).
## Uso do Amazon GuardDuty com monitoramento de runtime para o Fargate
O Amazon GuardDuty é um serviço de detecção de ameaças que ajuda a proteger contas, contêineres, workloads e dados no ambiente da AWS. Usando modelos de machine learning (ML) e recursos de detecção de anomalias e ameaças, o GuardDuty monitora continuamente diferentes fontes de log e atividades de runtime para identificar e priorizar possíveis riscos de segurança e atividades maliciosas no seu ambiente.
O monitoramento de runtime no GuardDuty protege as workloads em execução no Fargate monitorando continuamente as atividades de log e rede da AWS para identificar comportamentos maliciosos ou não autorizados. O monitoramento de runtime usa um agente de segurança do GuardDuty leve e totalmente gerenciado que analisa o comportamento no host, como acesso a arquivos, execução de processos e conexões de rede. Isso inclui problemas como escalação de privilégios, uso de credenciais expostas, comunicação com endereços IP ou domínios maliciosos e a presença de malware nas instâncias e workloads de contêiner do Amazon EC2. Para obter mais informações, consulte [GuardDuty Runtime Monitoring](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html) no *Guia do usuário do GuardDuty*.
# Considerações de segurança do Fargate para o Amazon ECS
Cada tarefa tem uma capacidade de infraestrutura dedicada porque o Fargate executa cada workload em um ambiente virtual isolado. As workloads executadas no Fargate não compartilham interfaces de rede, armazenamento temporário, CPU ou memória com outras tarefas. É possível executar vários contêineres em uma tarefa, incluindo contêineres de aplicações e contêineres auxiliares, ou simplesmente arquivos associados. Um *arquivo associado* é um contêiner que é executado junto com um contêiner de aplicação em uma tarefa do Amazon ECS. Enquanto o contêiner da aplicação executa o código principal da aplicação, os processos executados em arquivos associados podem aumentar a aplicação. Os arquivos associados ajudam você a separar as funções da aplicação em contêineres dedicados, facilitando a atualização de partes da sua aplicação.
Os contêineres que fazem parte da mesma tarefa compartilham recursos para o tipo de inicialização do Fargate, uma vez que esses contêineres sempre serão executados no mesmo host e compartilharão recursos de computação. Esses contêineres também compartilham o armazenamento temporário fornecido pela Fargate. Os contêineres de Linux em uma tarefa compartilham namespaces de rede, incluindo o endereço IP e as portas de rede. Dentro de uma tarefa, os contêineres que pertencem à tarefa podem se intercomunicar por meio do host local.
O ambiente de runtime no Fargate impede que você use determinados recursos do controlador com suporte nas instâncias do EC2. Considere o seguinte ao arquitetar workloads para execução no Fargate:
+ Sem contêineres ou acesso privilegiados: recursos como contêineres ou acesso privilegiados estão atualmente indisponíveis no Fargate. Isso afetará casos de uso, como executar o Docker no Docker.
+ Acesso limitado aos recursos do Linux: o ambiente no qual os contêineres são executados no Fargate está bloqueado. Recursos adicionais do Linux, como CAP\$1SYS\$1ADMIN e CAP\$1NET\$1ADMIN, são restringidos para evitar um aumento de privilégios. O Fargate oferece suporte à adição do recurso [CAP\$1SYS\$1PTRACE](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#other_task_definition_params) do Linux às tarefas para permitir que as ferramentas de observabilidade e segurança implantadas na tarefa monitorem a aplicação em contêineres.
+ Sem acesso ao host subjacente: nem os clientes, nem os operadores da AWS podem se conectar a um host que execute workloads do cliente. É possível usar o ECS Exec para executar comandos em ou obter um shell para um contêiner em execução no Fargate. É possível usar o ECS exec para ajudar a coletar informações de diagnóstico para depuração. O Fargate também impede que os contêineres acessem os recursos do host subjacente, como o sistema de arquivos, dispositivos, a rede e o runtime do contêiner.
+ Rede: é possível usar grupos de segurança e ACLs de rede para controlar o tráfego de entrada e saída. As tarefas do Fargate recebem um endereço IP da sub-rede configurada em sua VPC.
# Versões da plataforma do Fargate para o Amazon ECS
As versões da plataforma do AWS Fargate são usadas para fazer referência a um ambiente de runtime para a infraestrutura de tarefas do Fargate. Trata-se de uma combinação da versão do kernel e do runtime do contêiner. Você seleciona uma versão da plataforma ao executar uma tarefa ou ao criar um serviço para manter várias tarefas idênticas.
Novas revisões de versões da plataforma são lançadas conforme o ambiente do runtime evolui, por exemplo, em caso de atualizações no kernel ou no sistema operacional, novos recursos, correções de erros ou atualizações de segurança. Uma versão da plataforma Fargate é atualizada por meio de uma nova revisão da versão da plataforma. Cada tarefa é executada em uma revisão de versão da plataforma durante seu ciclo de vida. Se você quiser usar a revisão mais recente da versão da plataforma, será necessário iniciar uma nova tarefa. Uma nova tarefa executada no Fargate sempre é executada na revisão mais recente de uma versão da plataforma, garantindo que as tarefas sejam sempre iniciadas em uma infraestrutura segura e corrigida.
Se houver um problema de segurança que afete uma versão existente da plataforma, a AWS vai criar uma nova revisão corrigida da versão da plataforma e retirar as tarefas em execução na revisão vulnerável. Em alguns casos, será possível receber notificações de que suas tarefas no Fargate foram programadas para retirada. Para obter mais informações, consulte [Retirada e manutenção de tarefas para o AWS Fargate no Amazon ECS](task-maintenance.md).
Você especifica a versão da plataforma ao executar uma tarefa ou implementar um serviço.
Considere o seguinte ao especificar uma versão de plataforma:
+ É possível especificar um número de versão específico, por exemplo, `1.4.0` ou `LATEST`.
A versão da plataforma Linux **MAIS RECENTE** é a `1.4.0`.
A versão da plataforma Windows **MAIS RECENTE** é a `1.0.0`.
+ Se você quiser atualizar a versão da plataforma para um serviço, crie uma implantação. Por exemplo, suponha que você tenha um serviço que executa tarefas na versão `1.3.0` da plataforma Linux. Para alterar o serviço para executar tarefas na plataforma Linux versão `1.4.0`, você pode atualizar seu serviço e especificar uma nova versão da plataforma. Suas tarefas serão reimplantadas com a versão mais recente da plataforma e a revisão mais recente da versão da plataforma. Para obter mais informações sobre implantações, consulte [Serviços do Amazon ECS](ecs_services.md).
+ Caso seu serviço seja expandido sem atualizar a versão da plataforma, essas tarefas receberão a versão especificada na implantação atual dele. Por exemplo, suponha que você tenha um serviço que executa tarefas na versão `1.3.0` da plataforma Linux. Se você aumentar a contagem desejada do serviço, o programador de serviços iniciará as novas tarefas usando a versão mais recente da plataforma, a revisão da versão `1.3.0` da plataforma.
+ As novas tarefas sempre são executadas na revisão mais recente de uma versão da plataforma. Isso garante que as tarefas estejam sempre em uma infraestrutura protegida e corrigida.
+ Os números de versão da plataforma para contêineres Linux e contêineres Windows no Fargate são independentes. Por exemplo, o comportamento, os recursos e o software usados na versão da plataforma `1.0.0` para contêineres de Windows no Fargate não são comparáveis aos da versão da plataforma `1.0.0` para contêineres de Linux no Fargate.
+ O seguinte é válido para versões da plataforma Windows para o Fargate.
As imagens de contêiner do Microsoft Windows Server devem ser criadas com base em uma versão específica do Windows Server. Você deve selecionar a mesma versão do Windows Server na `platformFamily` ao executar uma tarefa ou criar um serviço que corresponda à imagem de contêiner do Windows Server. Além disso, é possível fornecer uma `operatingSystemFamily` correspondente na definição da tarefa para evitar que as tarefas sejam executadas na versão errada do Windows. Para obter mais informações, consulte [Correspondência de versão do host do contêiner com versões de imagens do contêiner](https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility#matching-container-host-version-with-container-image-versions) no site Microsoft Learn.
# Migração para a versão da plataforma Linux 1.4.0 no Amazon ECS
Considere o seguinte ao migrar suas tarefas do Amazon ECS no Fargate da versão de plataforma `1.0.0`, `1.1.0`, `1.2.0` ou `1.3.0` para a versão de plataforma `1.4.0`. É prática recomendada confirmar se sua tarefa funciona corretamente na versão `1.4.0` da plataforma antes de migrar suas tarefas.
+ O comportamento de tráfego de rede de e para tarefas foi atualizado. A partir da versão 1.4.0 da plataforma, todas as tarefas do Amazon ECS no Fargate recebem uma única interface de rede elástica (conhecida como ENI de tarefa), e todo o tráfego de rede flui por essa ENI dentro da VPC. O tráfego é visível para você por meio dos logs de fluxo da VPC. Para obter mais informações, consulte [Opções de redes de tarefas do Amazon ECS para o Fargate](fargate-task-networking.md).
+ Se você usa endpoints da VPC de interface, considere o seguinte.
+ Para imagens de contêiner hospedadas com o Amazon ECR, os endpoints a seguir são necessários. Para obter mais informações, consulte [Endpoints da VPC de interface do Amazon ECR (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html) no *Guia do usuário do Amazon Elastic Container Registry*.
+ Endpoint da VPC do Amazon ECR **com.amazonaws.*region*.ecr.dkr**
+ Endpoint da VPC do Amazon ECR **com.amazonaws.*region*.ecr.api**
+ Endpoint do gateway do Amazon S3
+ Quando a definição da tarefa fizer referência a segredos do Secrets Manager para recuperar dados sigilosos para os contêineres, você deverá criar os endpoints da VPC de interface para o Secrets Manager. Para obter mais informações, consulte [Usar o Secrets Manager com Endpoints da VPC](https://docs.aws.amazon.com/secretsmanager/latest/userguide/vpc-endpoint-overview.html) no *Guia do usuário do AWS Secrets Manager*.
+ Quando a definição de tarefa fizer referência a parâmetros do Systems Manager Parameter Store para recuperar dados sigilosos para os contêineres, crie os endpoints da VPC de interface para o Systems Manager. Para obter mais informações, consulte [Melhorar a segurança das instâncias do EC2 usando endpoints da VPC para o Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html) no *Guia do usuário do AWS Systems Manager*.
+ O grupo de segurança da interface de rede elástica (ENI) associada à sua tarefa precisa das regras do grupo de segurança para permitir o tráfego entre a tarefa e os endpoints da VPC.
# Log de alterações da versão da plataforma Linux para o Fargate
Veja a seguir as versões da plataforma Linux disponíveis. Para obter informações sobre a substituição de versões anteriores da plataforma, consulte [Descontinuação da versão da plataforma Linux do AWS Fargate](platform-versions-retired.md).
## 1.4.0
Veja a seguir o changelog da versão da plataforma `1.4.0`.
+ A partir de 5 de novembro de 2020, qualquer nova tarefa do Amazon ECS lançada no Fargate usando a versão `1.4.0` da plataforma poderá usar os seguintes recursos:
+ Ao usar o Secrets Manager para armazenar dados sigilosos, você pode injetar uma chave JSON específica ou uma versão específica de um segredo como uma variável de ambiente ou em uma configuração de log. Para obter mais informações, consulte [Transferência de dados confidenciais para um contêiner do Amazon ECS](specifying-sensitive-data.md).
+ Especifique variáveis de ambiente em massa usando o parâmetro `environmentFiles` de definição de contêiner. Para obter mais informações, consulte [Transferência de uma variável de ambiente individual para um contêiner do Amazon ECS](taskdef-envfiles.md).
+ Tarefas executadas em uma VPC e em uma sub-rede habilitadas para IPv6 receberão um endereço IPv4 privado e um endereço IPv6. Para obter mais informações, consulte [Opções de rede de tarefas do Amazon ECS para o Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html).
+ O endpoint de metadados da tarefa versão 4 fornece metadados adicionais sobre a tarefa e o contêiner, incluindo o tipo de inicialização da tarefa, o nome do recurso da Amazon (ARN) do contêiner e o driver de log e as opções de driver de log usadas. Ao consultar o endpoint `/stats`, você também recebe dados estatísticos de taxa de rede para seus contêineres. Para obter mais informações, consulte [Task metadata endpoint version 4](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-metadata-endpoint-v4-fargate.html).
+ A partir de 30 de julho de 2020, qualquer nova tarefa do Amazon ECS iniciada no Fargate usando a versão `1.4.0` da plataforma poderá encaminhar o tráfego UDP usando um Network Load Balancer para tarefas do Amazon ECS no Fargate. Para obter mais informações, consulte [Uso do balanceamento de carga para distribuir o tráfego de serviço do Amazon ECS](service-load-balancing.md).
+ A partir de 28 de maio de 2020, qualquer nova tarefa do Amazon ECS iniciada no Fargate usando a versão `1.4.0` da plataforma terá seu armazenamento temporário criptografado com um algoritmo de criptografia AES-256 usando uma chave de criptografia gerenciada pela AWS. Para obter mais informações, consulte [Armazenamento efêmero de tarefas do Fargate para o Amazon ECS](fargate-task-storage.md) e [Opções de armazenamento para tarefas do Amazon ECS](using_data_volumes.md).
+ Adicionado suporte para usar volumes do sistema de arquivos do Amazon EFS para o armazenamento de tarefas persistentes. Para obter mais informações, consulte [Uso de volumes do Amazon EFS com o Amazon ECS](efs-volumes.md).
+ O armazenamento temporário de tarefas foi aumentado para no mínimo 20 GB para cada tarefa. Para obter mais informações, consulte [Armazenamento efêmero de tarefas do Fargate para o Amazon ECS](fargate-task-storage.md).
+ O comportamento de tráfego de rede de e para tarefas foi atualizado. A partir da versão 1.4.0 da plataforma, todas as tarefas do Fargate recebem uma única interface de rede elástica (conhecida como ENI de tarefa), e todo o tráfego de rede flui por essa ENI dentro da VPC e será visível por meio dos logs de fluxo da VPC. Para obter mais informações sobre redes para o tipo de inicialização do Amazon EC2, consulte [Opções de rede de tarefas do Amazon ECS para o EC2](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html). Para obter mais informações sobre redes para o Fargate, consulte [Opções de redes de tarefas do Amazon ECS para o Fargate](fargate-task-networking.md).
+ As ENIs de tarefas adicionam suporte para quadros jumbo. As interfaces de rede são configuradas com uma unidade de transmissão máxima (MTU), que se refere ao tamanho da maior carga útil que cabe em um único quadro. Quanto maior a MTU, maior será a carga útil do aplicativo que pode caber em um único quadro, o que reduz a sobrecarga por quadro e aumenta a eficiência. O suporte a quadros jumbo reduzirá a sobrecarga quando o caminho de rede entre a tarefa e o destino oferecer suporte a quadros jumbo, assim como todo o tráfego que permanece dentro da VPC.
+ O CloudWatch Container Insights inclui métricas de performance de rede para tarefas do Fargate. Para obter mais informações, consulte [Monitorar contêineres do Amazon ECS utilizando o Container Insights com observabilidade aprimorada](cloudwatch-container-insights.md).
+ Adicionado suporte para o endpoint de metadados de tarefas versão 4, que fornece informações adicionais para suas tarefas do Fargate, incluindo dados estatísticos da rede da tarefa e em qual zona de disponibilidade a tarefa está sendo executada. Para obter mais informações, consulte [Endpoint de metadados de tarefas do Amazon ECS versão 4](task-metadata-endpoint-v4.md) e [Endpoint de metadados de tarefas do Amazon ECS versão 4 para tarefas no Fargate](task-metadata-endpoint-v4-fargate.md).
+ Suporte adicionado para o parâmetro Linux `SYS_PTRACE` nas definições de contêiner. Para obter mais informações, consulte [Parâmetros do Linux](task_definition_parameters.md#container_definition_linuxparameters).
+ O agente de contêiner do Fargate substitui o uso do agente de contêiner do Amazon ECS do para todas as tarefas do Fargate. Normalmente, essa alteração não afeta a forma como suas tarefas são executadas.
+ O runtime do contêiner agora está usando containerd em vez do docker. Provavelmente, essa alteração não afeta a forma como suas tarefas são executadas. Você perceberá que algumas mensagens de erro provenientes do runtime do contêiner deixarão de mencionar o Docker e mostrarão erros mais gerais. Para obter mais informações, consulte [Mensagens de erro de tarefas interrompidas do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/stopped-task-error-codes.html).
+ Com base no Amazon Linux 2.
# Descontinuação da versão da plataforma Linux do AWS Fargate
**Importante**
Encerraremos o suporte à versão PV 1.3.0 no Fargate em 30 de junho de 2026. A partir de 15 de junho de 2026, a versão 1.3.0 da plataforma será considerada obsoleta. Dessa data em diante, você não poderá iniciar novas tarefas ou criar novos serviços configurados com a versão da plataforma 1.3.0, mas suas tarefas existentes continuarão em execução. Em 30 de junho de 2026, encerraremos todas as tarefas em execução restantes configuradas com a versão 1.3.0 da plataforma.
Para obter mais informações sobre como migrar para a versão 1.4 da plataforma, consulte [Migração para a versão da plataforma Linux 1.4.0 no Amazon ECS](platform-version-migration.md).
A tabela a seguir lista as versões da plataforma Linux que o AWS Fargate descontinuou ou que tiveram sua descontinuação programada. Essas versões de plataforma permanecem disponíveis até a data publicada da substituição.
Uma *data de atualização forçada* é fornecida para cada versão da plataforma com substituição programada. Na data de atualização forçada, qualquer serviço que usar a versão `LATEST` da plataforma e que for direcionado para uma versão da plataforma com substituição programada será atualizado por meio da opção de forçar nova implantação. Quando o serviço é atualizado usando a opção de forçar nova implantação, todas as tarefas executadas em uma versão da plataforma com substituição programada são interrompidas e novas tarefas são iniciadas usando a versão da plataforma para a qual a etiqueta `LATEST` aponta, naquele momento. Tarefas ou serviços autônomos com um conjunto explícito de versões de plataforma não são afetados pela data de atualização forçada.
Para obter mais informações sobre como migrar para a versão mais recente da plataforma, consulte [Migração para a versão da plataforma Linux 1.4.0 no Amazon ECS](platform-version-migration.md).
Quando uma versão da plataforma atingir a *data de descontinuação*, ela se tornará indisponível para novas tarefas ou serviços. Todas as tarefas ou serviços autônomos que usarem explicitamente uma versão obsoleta da plataforma continuarão a usar esta versão até que as tarefas sejam interrompidas. Após a data de substituição, qualquer versão obsoleta da plataforma não receberá mais atualizações de segurança ou correções de bugs.
| Versão da plataforma | Data da atualização forçada | Data da substituição |
| --- | --- | --- |
| 1.0.0 | 26 de outubro de 2020 | 14 de dezembro de 2020 |
| 1.1.0 | 26 de outubro de 2020 | 14 de dezembro de 2020 |
| 1.2.0 | 26 de outubro de 2020 | 14 de dezembro de 2020 |
| 1.3.0 | | 15 de junho de 2026 |
Para obter informações sobre as versões atuais da plataforma, consulte [Versões da plataforma do Fargate para o Amazon ECS](platform-fargate.md).
## Log de alterações das versões defasadas do Linux para o Fargate
### 1.3.0
Veja a seguir o changelog da versão da plataforma `1.3.0`.
+ A partir de 30 de setembro de 2019, qualquer nova tarefa do Fargate iniciada é compatível com o driver de log `awsfirelens`. Configure o FireLens para Amazon ECS para usar parâmetros de definição de tarefa para encaminhar logs para um serviço da AWS ou um destino da Rede de Parceiros da AWS (APN) para armazenamento e análise de log. Para obter mais informações, consulte [Envio de logs do Amazon ECS para um serviço da AWS ou para uma AWS Partner](using_firelens.md).
+ Adicionada a reciclagem de tarefas para as tarefas do Fargate, que é o processo de atualização das tarefas que fazem parte de um serviço do Amazon ECS. Para obter mais informações, consulte [Retirada e manutenção de tarefas para AWS Fargate no Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-maintenance.html).
+ A partir de 27 de março de 2019, todas as novas tarefas do Fargate iniciadas podem usar parâmetros adicionais de definição de tarefa que você usa para definir uma configuração de proxy, dependências para startup e desligamento de contêiner, além de um valor de tempo limite de início e interrupção por contêiner. Para obter mais informações, consulte [Configuração do proxy](task_definition_parameters.md#proxyConfiguration), [Dependência de contêiner](task_definition_parameters.md#container_definition_dependson) e [Tempos limite de contêiner](task_definition_parameters.md#container_definition_timeout).
+ A partir de 2 de abril de 2019, todas as novas tarefas do Fargate iniciadas oferecem suporte à injeção de dados sigilosos nos seus contêineres. Isso é feito armazenando seus dados sigilosos em segredos do AWS Secrets Manager ou em parâmetros do AWS Systems Manager Parameter Store e fazendo referência a eles na definição do contêiner. Para obter mais informações, consulte [Transferência de dados confidenciais para um contêiner do Amazon ECS](specifying-sensitive-data.md).
+ A partir de 1.º de maio de 2019, todas as novas tarefas do Fargate iniciadas oferecem suporte à referência a dados sigilosos na configuração de log de um contêiner usando o parâmetro `secretOptions` de definição do contêiner. Para obter mais informações, consulte [Transferência de dados confidenciais para um contêiner do Amazon ECS](specifying-sensitive-data.md).
+ A partir de 1.º de maio de 2019, todas as novas tarefas do Fargate que iniciadas oferecem suporte ao driver de log `splunk`, além do driver de log `awslogs`. Para obter mais informações, consulte [Armazenamento e registro](task_definition_parameters.md#container_definition_storage).
+ A partir de 9 de julho de 2019, todas as novas tarefas do Fargate iniciadas oferecem suporte ao CloudWatch Container Insights. Para obter mais informações, consulte [Monitorar contêineres do Amazon ECS utilizando o Container Insights com observabilidade aprimorada](cloudwatch-container-insights.md).
+ A partir de 3 de dezembro de 2019, há suporte para o provedor de capacidade Fargate Spot. Para obter mais informações, consulte [Clusters do Amazon ECS para Fargate](fargate-capacity-providers.md).
+ Com base no Amazon Linux 2.
### 1.2.0
Veja a seguir o changelog da versão da plataforma `1.2.0`.
**nota**
A versão `1.2.0` da plataforma não está mais disponível. Para obter informações sobre a substituição de versões anteriores da plataforma, consulte [Descontinuação da versão da plataforma Linux do AWS Fargate](#platform-versions-retired).
+ Adicionado suporte para autenticação de registro privado usando AWS Secrets Manager. Para obter mais informações, consulte [Uso de imagens de contêiner que não são da AWS no Amazon ECS](private-auth.md).
### 1.1.0
Veja a seguir o changelog da versão da plataforma `1.1.0`.
**nota**
A versão `1.1.0` da plataforma não está mais disponível. Para obter informações sobre a substituição de versões anteriores da plataforma, consulte [Descontinuação da versão da plataforma Linux do AWS Fargate](#platform-versions-retired).
+ Adicionado suporte para o endpoint de metadados de tarefa do Amazon ECS. Para obter mais informações, consulte [Metadados de tarefas do Amazon ECS disponíveis para tarefas no Fargate](fargate-metadata.md).
+ Inclusão de suporte às verificações de integridade do Docker nas definições de contêiner. Para obter mais informações, consulte [Verificação de integridade](task_definition_parameters.md#container_definition_healthcheck).
+ Adicionado suporte para a descoberta de serviços do Amazon ECS. Para obter mais informações, consulte [Uso da descoberta de serviços para conectar serviços do Amazon ECS com nomes DNS](service-discovery.md).
### 1.0.0
Veja a seguir o changelog da versão da plataforma `1.0.0`.
**nota**
A versão `1.0.0` da plataforma não está mais disponível. Para obter informações sobre a substituição de versões anteriores da plataforma, consulte [Descontinuação da versão da plataforma Linux do AWS Fargate](#platform-versions-retired).
+ Com base no Amazon Linux 2017.09.
+ Versão inicial.
# Log de alterações da versão da plataforma Windows para o Fargate
Veja a seguir as versões disponíveis da plataforma para contêineres do Windows.
## 1.0.0
Veja a seguir o changelog da versão da plataforma `1.0.0`.
+ Versão inicial para suporte nos seguintes sistemas operacionais Microsoft Windows Server:
+ Windows Server 2019 Full
+ Windows Server 2019 Core
+ Windows Server 2022 Full
+ Windows Server 2022 Core
# Considerações sobre contêineres do Windows no Fargate para o Amazon ECS
A seguir estão as diferenças e considerações que você deve saber ao executar contêineres do Windows no AWS Fargate.
Caso precise executar tarefas em contêineres do Linux e do Windows, é necessário criar definições de tarefas separadas em cada sistema operacional.
A AWS administra o gerenciamento de licenças do sistema operacional, de modo que você não precise de nenhuma licença adicional do Microsoft Windows Server.
Os contêineres do Windows no AWS Fargate oferecem suporte aos seguintes sistemas operacionais:
+ Windows Server 2019 Full
+ Windows Server 2019 Core
+ Windows Server 2022 Full
+ Windows Server 2022 Core
Os contêineres do Windows no AWS Fargate oferecem suporte ao driver awslogs. Para obter mais informações, consulte [Envio de logs do Amazon ECS para o CloudWatch](using_awslogs.md).
Não há suporte para os seguintes recursos em contêineres do Windows no Fargate:
+ Amazon FSx
+ Entroncamento ENI
+ gMSAs para contêineres do Windows
+ Integração de proxy e serviço App Mesh para tarefas
+ Integração do roteador de log Firelens para tarefas
+ Volumes do EFS
+ Volumes do EBS
+ Os seguintes parâmetros de definição de tarefa:
+ `maxSwap`
+ `swappiness`
+ `environmentFiles`
+ O provedor de capacidade Fargate Spot
+ Volumes de imagem
A opção `volume` do Dockerfile é ignorada. Em vez disso, use montagens bind na sua definição de tarefa. Para obter mais informações, consulte [Uso de montagens vinculadas com o Amazon ECS](bind-mounts.md).
+ Os parâmetros de CPU e memória ao nível de tarefa são ignorados para contêineres do Windows. É recomendável especificar recursos em nível de contêiner para contêineres do Windows.
+ memória para tarefa
+ mermoryReservation em contêineres
+ Políticas de reinicialização em contêineres
+ Não é possível atualizar a família de plataformas de um serviço.
# Comportamento dos contêineres Linux na extração de imagens de contêiner do Fargate para o Amazon ECS
Cada tarefa do Fargate é executada em sua própria instância de uso e de locatário únicos. Quando você executa contêineres do Linux no Fargate, as imagens de contêiner ou as camadas de imagens de contêiner não são armazenadas em cache na instância. Portanto, para cada imagem de contêiner definida na tarefa, a imagem de contêiner, em sua totalidade, precisa ser extraída do registro de imagem de contêiner para cada tarefa do Fargate. O tempo necessário para extrair as imagens está diretamente relacionado ao tempo dedicado para iniciar uma tarefa do Fargate.
Considere as informações apresentadas a seguir para otimizar o tempo de extração de imagens.
**Proximidade da imagem de contêiner**
Para reduzir o tempo necessário para efetuar o download das imagens de contêiner, localize os dados o mais próximo possível da computação. A extração de uma imagem de contêiner usando a Internet ou entre Regiões da AWS pode afetar o tempo de download. Recomendamos armazenar a imagem de contêiner na mesma região em que a tarefa será executada. Se você armazenar a imagem de contêiner no Amazon ECR, use um endpoint da VPC de interface para reduzir ainda mais o tempo de extração da imagem. Para obter mais informações, consulte [Amazon ECR interface VPC endpoints (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html) no *Guia do usuário do Amazon ECR*.
**Redução do tamanho da imagem de contêiner**
O tamanho de uma imagem de contêiner afeta diretamente o tempo de download. Reduzir o tamanho da imagem de contêiner ou o número de camadas da imagem de contêiner pode reduzir o tempo de download de uma imagem. Imagens base leves (como a imagem de contêiner mínima do Amazon Linux 2023) podem ser significativamente menores do que aquelas baseadas em imagens base do sistema operacional tradicional. Para obter mais informações sobre a imagem mínima, consulte [AL2023 Minimal container image](https://docs.aws.amazon.com/linux/al2023/ug/minimal-container.html) no *Guia do usuário do Amazon Linux 2023*.
**Algoritmos de compactação alternativos**
Geralmente, as camadas de imagem de contêiner são compactadas quando enviadas para um registro de imagem de contêiner. A compactação da camada de imagem de contêiner reduz a quantidade de dados que precisam ser transferidos pela rede e armazenados no registro de imagens de contêiner. Depois que uma camada de imagem de contêiner for baixada para uma instância pelo runtime do contêiner, essa camada será descompactada. O algoritmo de compactação usado e a quantidade de vCPUs disponíveis para o runtime afetam o tempo dedicado para descompactar a imagem de contêiner. No Fargate, é possível aumentar o tamanho da tarefa ou aproveitar o algoritmo de compactação zstd de maior desempenho para reduzir o tempo necessário para a descompactação. Para obter mais informações, consulte [ztsd](https://github.com/facebook/zstd) no GitHub. Para obter informações sobre como implementar as imagens para o Fargate, consulte [Reducing AWS Fargate Startup Times with zstd Compressed Container Images](https://aws.amazon.com/blogs/containers/reducing-aws-fargate-startup-times-with-zstd-compressed-container-images/).
**Imagens de contêiner de carregamento lento**
Para imagens de contêiner grandes (maiores do que 250 MB), pode ser ideal realizar o carregamento lento de uma imagem de contêiner em vez de efetuar o download da imagem de contêiner em sua totalidade. No Fargate, é possível usar o Seekable OCI (SOCI) para realizar o carregamento lento de uma imagem de contêiner de um registro de imagem de contêiner. Para obter mais informações, consulte [soci-snapshotter](https://github.com/awslabs/soci-snapshotter) no GitHub e [Carregamento lento de imagens de contêiner usando Seekable OCI (SOCI)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-tasks-services.html#fargate-tasks-soci-images).
# Comportamento dos contêineres Windows na extração de imagens de contêiner do Fargate para o Amazon ECS
O Windows para Fargate armazena em cache a imagem de base do núcleo do servidor do mês mais recente e do mês anterior fornecida pela Microsoft. Essas imagens correspondem aos patches de KB ou número de compilação atualizados a cada Patch Tuesday. Por exemplo, em 9 de abril de 2024, a Microsoft liberou a atualização KB5036896 (17763.5696) para o Windows Server 2019. A atualização KB do mês anterior, liberada em 12 de março de 2024, foi a KB5035849 (17763.5576). Portanto, para as plataformas `WINDOWS_SERVER_2019_CORE` e `WINDOWS_SERVER_2019_FULL` as seguintes imagens de contêiner foram armazenadas em cache:
+ `mcr.microsoft.com/windows/servercore:ltsc2019`
+ ` mcr.microsoft.com/windows/servercore:10.0.17763.5696`
+ `mcr.microsoft.com/windows/servercore:10.0.17763.5576`
Além disso, em 9 de abril de 2024, a Microsoft liberou a atualização KB5036909 (20348.2402) para o Windows Server 2022. A atualização KB do mês anterior, liberada em 12 de março de 2024, foi a KB5035857 (20348.2340). Portanto, nas plataformas `WINDOWS_SERVER_2022_CORE` e `WINDOWS_SERVER_2022_FULL`, as seguintes imagens de contêiner foram armazenadas em cache:
+ `mcr.microsoft.com/windows/servercore:ltsc2022`
+ `mcr.microsoft.com/windows/servercore:10.0.20348.2402`
+ `mcr.microsoft.com/windows/servercore:10.0.20348.2340`
# Armazenamento efêmero de tarefas do Fargate para o Amazon ECS
Quando provisionada, cada tarefa do Amazon ECS hospedada em contêineres Linux no AWS Fargate recebe o armazenamento temporário a seguir, para montagens bind. Isso pode ser montado e compartilhado entre os contêineres usando os parâmetros `volumes`, `mountPoints` e `volumesFrom` na definição da tarefa. Não há suporte para isso nos contêineres do Windows no AWS Fargate.
## Versões da plataforma de contêiner Linux do Fargate
### Versão 1.4.0 ou posterior
Por padrão, as tarefas do Amazon ECS hospedadas no Fargate usando a versão `1.4.0` ou posterior da plataforma recebem, no mínimo, 20 GiB de armazenamento temporário. A quantidade total de armazenamento temporário pode ser aumentada, até um máximo de 200 GiB. Para fazer isso, especifique o parâmetro `ephemeralStorage` na definição de tarefa.
A imagem de contêiner extraída, compactada e descompactada da tarefa é armazenada no armazenamento temporário. Para determinar a quantidade total de armazenamento temporário que sua tarefa precisa usar, subtraia a quantidade de armazenamento usada pela imagem do contêiner da quantidade total de armazenamento temporário em que a tarefa está alocada..
Para tarefas que usam a versão `1.4.0` ou posterior da plataforma iniciadas em 28 de maio de 2020 ou depois, o armazenamento temporário é criptografado com um algoritmo de criptografia AES-256. Esse algoritmo usa uma chave de criptografia pertencente à AWS ou você pode criar sua própria chave gerenciada pelo cliente. Para obter mais informações, consulte [Customer managed keys for AWS Fargate ephemeral storage](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-storage-encryption.html).
Para tarefas que usam uma versão `1.4.0` ou posterior da plataforma, lançadas a partir de 18 de novembro de 2022, o uso de armazenamento temporário é informado por meio do endpoint de metadados da tarefa. As aplicações nas suas tarefas podem consultar a versão 4 do endpoint de metadados da tarefa para obter o tamanho reservado de armazenamento temporário e a quantidade usada.
Além disso, o tamanho reservado do armazenamento temporário e a quantidade usada serão enviados ao Amazon CloudWatch Container Insights se você ativar o Container Insights.
**nota**
O Fargate reserva espaço no disco. Esse espaço é usado apenas pelo Fargate. Você não é cobrado por isso. Ele não é mostrado nessas métricas. Porém, você pode ver esse armazenamento adicional em outras ferramentas, como o `df`.
### Versão 1.3.0 ou anterior
Para as tarefas do Amazon ECS no Fargate que usam a versão `1.3.0` ou anterior da plataforma, cada tarefa recebe o armazenamento temporário a seguir.
+ 10 GB de armazenamento de camadas do Docker
**nota**
Essa quantidade inclui artefatos de imagem de contêiner compactados e não compactados.
+ Mais 4 GB para montagens de volume. Isso pode ser montado e compartilhado entre os contêineres usando os parâmetros `volumes`, `mountPoints` e `volumesFrom` na definição da tarefa.
## Versões da plataforma de contêiner Windows do Fargate
### Versão 1.0.0 ou posterior
Por padrão, as tarefas do Amazon ECS hospedadas no Fargate usando a versão `1.0.0` ou posterior da plataforma recebem, no mínimo, 20 GiB de armazenamento temporário. A quantidade total de armazenamento temporário pode ser aumentada, até um máximo de 200 GiB. Para fazer isso, especifique o parâmetro `ephemeralStorage` na definição de tarefa.
A imagem de contêiner extraída, compactada e descompactada da tarefa é armazenada no armazenamento temporário. Para determinar a quantidade total de armazenamento temporário que sua tarefa precisa usar, subtraia a quantidade de armazenamento usada pela imagem do contêiner da quantidade total de armazenamento temporário em que a tarefa está alocada..
Para obter mais informações, consulte [Uso de montagens vinculadas com o Amazon ECS](bind-mounts.md).
# Chaves gerenciadas pelo cliente para o armazenamento efêmero do AWS Fargate para o Amazon ECS
O AWS Fargate é compatível com chaves gerenciadas pelo cliente para criptografar dados para tarefas do Amazon ECS mantidas em armazenamento efêmero para ajudar clientes que estão sujeitos a regulamentações a seguir suas políticas internas de segurança. Os clientes ainda obtêm o benefício da tecnologia sem servidor do Fargate, ao mesmo tempo em que oferecem maior visibilidade da criptografia de armazenamento autogerenciada aos auditores de conformidade. Embora o Fargate tenha, por padrão, criptografia de armazenamento efêmero gerenciada pelo Fargate, os clientes também podem usar suas próprias chaves autogerenciadas ao criptografar dados confidenciais, como informações financeiras ou médicas.
Você pode importar suas próprias chaves para o AWS KMS ou criar as chaves no AWS KMS. Essas chaves autogerenciadas são armazenadas no AWS KMS e realizam as ações padrão do ciclo de vida do AWS KMS, como alternar, desativar e excluir. Você pode auditar o acesso e o uso das chaves nos logs do CloudTrail.
Por padrão, a chave KMS é compatível com 50.000 concessões por chave. O Fargate usa uma única concessão do AWS KMS por tarefa de chave gerenciada pelo cliente, sendo compatível com até 50.000 tarefas simultâneas para uma chave. Se quiser aumentar esse número, você pode solicitar um aumento de limite, que é aprovado caso a caso.
O Fargate não cobra nenhum adicional pelo uso de chaves gerenciadas pelo cliente. Você só paga o preço padrão pelo uso das chaves do AWS KMS para solicitações de armazenamento e de API.
**Topics**
+ [
# Criar uma chave de criptografia para o armazenamento efêmero do Fargate para o Amazon ECS
](fargate-create-storage-key.md)
+ [
# Gerenciar chaves AWS KMS para o armazenamento efêmero do Fargate para o Amazon ECS
](fargate-managing-kms-key.md)
# Criar uma chave de criptografia para o armazenamento efêmero do Fargate para o Amazon ECS
Crie uma chave gerenciada do cliente para criptografar dados armazenados no armazenamento temporário do Fargate.
**nota**
A criptografia de armazenamento efêmero do Fargate com chaves gerenciadas pelo cliente não está disponível para clusters de tarefas do Windows.
A criptografia do armazenamento efêmero do Fargate com chaves gerenciadas pelo cliente não está disponível nas `platformVersions` anteriores à versão `1.4.0`.
O Fargate reserva espaço em um armazenamento efêmero que só é usado pelo Fargate, e você não é cobrado por esse espaço. A alocação pode ser diferente nas tarefas de chave não gerenciadas pelo cliente, mas o espaço total permanece o mesmo. Você pode ver essa mudança em ferramentas como `df`.
Chaves de várias regiões não são compatíveis com armazenamento efêmero do Fargate.
Aliases de chaves do KMS não são compatíveis com armazenamento efêmero do Fargate.
Para criar um a chave gerenciada pelo cliente (CMK) para criptografar armazenamento efêmero para o Fargate no AWS KMS, siga estas etapas.
1. Navegue até [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms).
1. Siga as instruções de [Creating Keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) no [AWS Key Management Service Developer Guide](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html).
1. Ao criar sua chave AWS KMS, certifique-se de fornecer as permissões operacionais relevantes do AWS KMS ao serviço Fargate nas políticas de chave. As operações de API a seguir devem ser permitidas na política para usar a chave gerenciada pelo cliente com os recursos de cluster do Amazon ECS.
+ `kms:GenerateDataKeyWithoutPlainText`: chame `GenerateDataKeyWithoutPlainText` para gerar uma chave de dados criptografada a partir da chave AWS KMS fornecida.
+ `kms:CreateGrant`: adiciona uma concessão a uma chave gerenciada pelo cliente. Concede controle de acesso a uma chave AWS KMS especificada, o que permite acesso às operações de concessão que o Fargate do Amazon ECS requer. Para obter mais informações sobre [Utilizar concessões](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html), consulte o [Guia do desenvolvedor do AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html). Isso permite que o Fargate do Amazon ECS faça o seguinte:
+ Chame `Decrypt` para que o AWS KMS obtenha a chave de criptografia para descriptografar os dados do armazenamento efêmero.
+ Configure uma entidade principal aposentada para permitir que o serviço para `RetireGrant`.
+ `kms:DescribeKey`: fornece os detalhes da chave gerenciada pelo cliente para permitir que o Amazon ECS valide a chave se ela for simétrica e estiver habilitada.
O exemplo a seguir mostra uma política de chave AWS KMS que você aplicaria à chave de destino para criptografia. Para usar as instruções do exemplo de política, substitua os *espaços reservados para entrada do usuário* por suas próprias informações. Como sempre, configure apenas as permissões necessárias, mas você precisará fornecer o AWS KMS com permissões para pelo menos um usuário a fim de evitar erros.
```
{
"Sid": "Allow generate data key access for Fargate tasks.",
"Effect": "Allow",
"Principal": { "Service":"fargate.amazonaws.com" },
"Action": [
"kms:GenerateDataKeyWithoutPlaintext"
],
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:ecs:clusterAccount": [
"customerAccountId"
],
"kms:EncryptionContext:aws:ecs:clusterName": [
"clusterName"
]
}
},
"Resource": "*"
},
{
"Sid": "Allow grant creation permission for Fargate tasks.",
"Effect": "Allow",
"Principal": { "Service":"fargate.amazonaws.com" },
"Action": [
"kms:CreateGrant"
],
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:ecs:clusterAccount": [
"customerAccountId"
],
"kms:EncryptionContext:aws:ecs:clusterName": [
"clusterName"
]
},
"ForAllValues:StringEquals": {
"kms:GrantOperations": [
"Decrypt"
]
}
},
"Resource": "*"
},
{
"Sid": "Allow describe key permission for cluster operator - CreateCluster and UpdateCluster.",
"Effect": "Allow",
"Principal": { "AWS":"arn:aws:iam::customerAccountId:role/customer-chosen-role" },
"Action": [
"kms:DescribeKey"
],
"Resource": "*"
}
```
As tarefas do Fargate usam as chaves de contexto de criptografia `aws:ecs:clusterAccount` e `aws:ecs:clusterName` para operações criptográficas com a chave. Os clientes devem adicionar essas permissões para restringir o acesso a uma conta e/ou cluster específicos. Use o nome do cluster e não o ARN ao especificar o cluster.
Para obter mais informações, consulte [Contexto de criptografia](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context) no [Guia do desenvolvedor AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html).
Ao criar ou atualizar um cluster, você tem a opção usar a chave de condição `fargateEphemeralStorageKmsKeyId`. Essa chave de condição permite que os clientes tenham um controle mais granular das políticas do IAM. As atualizações da configuração `fargateEphemeralStorageKmsKeyId` só se aplicam a novas implantações do serviço.
O exemplo a seguir mostra como deixar que os clientes só concedam permissões a um conjunto específico de chaves AWS KMS aprovadas.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:CreateCluster",
"ecs:UpdateCluster"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"ecs:fargate-ephemeral-storage-kms-key": "arn:aws:kms:us-west-2:111122223333:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
}
}
]
}
```
------
O próximo exemplo mostra como negar tentativas de remover chaves AWS KMS que já estão associadas a um cluster.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": [
"ecs:CreateCluster",
"ecs:UpdateCluster"
],
"Resource": "*",
"Condition": {
"Null": {
"ecs:fargate-ephemeral-storage-kms-key": "true"
}
}
}
}
```
------
Os clientes podem ver se as tarefas não gerenciadas ou as tarefas de serviço estão criptografadas com a chave usando os comandos AWS CLI, `describe-tasks`, `describe-cluster` ou `describe-services`.
Para obter mais informações, consulte [Condition keys for AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html) in the [AWS KMS Developer Guide](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html).
------
#### [ Console de gerenciamento da AWS ]
1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).
1. Escolha **Clusters** no painel de navegação esquerdo, depois selecione **Criar cluster** no canto superior direito ou escolha um cluster existente. Para um cluster existente, escolha **Atualizar cluster** no canto superior direito.
1. Na seção **Criptografia** do fluxo de trabalho, você terá a opção de selecionar sua chave AWS KMS em **Armazenamento gerenciado** e **Armazenamento efêmero do Fargate**. Você também pode optar por **criar uma chave AWS KMS** aqui.
1. Escolha **Criar** quando terminar de criar o novo cluster ou **Atualizar**, se estiver atualizando um cluster existente.
------
#### [ AWS CLI ]
O exemplo a seguir mostra como criar um cluster e configurar o armazenamento efêmero do Fargate usando a AWS CLI (substitua os valores em *vermelho* pelos seus):
```
aws ecs create-cluster --cluster clusterName \
--configuration '{"managedStorageConfiguration":{"fargateEphemeralStorageKmsKeyId":"arn:aws:kms:us-west-2:012345678901:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"}}'
{
"cluster": {
"clusterArn": "arn:aws:ecs:us-west-2:012345678901:cluster/clusterName",
"clusterName": "clusterName",
"configuration": {
"managedStorageConfiguration": {
"fargateEphemeralStorageKmsKeyId": "arn:aws:kms:us-west-2:012345678901:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
},
"status": "ACTIVE",
"registeredContainerInstancesCount": 0,
"runningTasksCount": 0,
"pendingTasksCount": 0,
"activeServicesCount": 0,
"statistics": [],
"tags": [],
"settings": [],
"capacityProviders": [],
"defaultCapacityProviderStrategy": []
},
"clusterCount": 5
}
```
------
#### [ CloudFormation ]
O exemplo a seguir mostra como criar um cluster e configurar o armazenamento efêmero do Fargate usando a CloudFormation o (substitua os valores em *vermelho* pelos):
```
AWSTemplateFormatVersion: 2010-09-09
Resources:
MyCluster:
Type: AWS::ECS::Cluster
Properties:
ClusterName: "clusterName"
Configuration:
ManagedStorageConfiguration:
FargateEphemeralStorageKmsKeyId: "arn:aws:kms:us-west-2:012345678901:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
```
------
# Gerenciar chaves AWS KMS para o armazenamento efêmero do Fargate para o Amazon ECS
Depois de criar ou importar sua chave AWS KMS para criptografar o armazenamento efêmero do Fargate, você o gerencia como faria com qualquer outra chave AWS KMS.
**Alternância automática de chaves AWS KMS**
Você pode ativar a troca automática das chaves ou fazer isso manualmente. A troca automática da chave faz isso para você uma vez por ano, gerando novo material criptográfico para a chave. O AWS KMS também salva todas as versões anteriores do material criptográfico, para que você possa descriptografar dados que usaram as versões anteriores da chave. O AWS KMS não excluirá nenhum material que tenha sido trocado até você excluir a chave.
A troca automática é opcional e pode ser habilitada ou desabilitada a qualquer momento.
**Desativando ou revogando chaves AWS KMS**
Desabilitar uma chave gerenciada pelo cliente no AWS KMS não terá nenhum impacto na execução das tarefas e elas continuarão funcionando durante todo o ciclo de vida. Uma tarefa que usar a chave desabilitada ou revogada falhará porque não poderá acessar a chave. Você deve definir um alarme do CloudWatch ou similar para garantir que uma chave desabilitada nunca seja necessária para descriptografar dados já criptografados.
**Excluir chaves AWS KMS**
Excluir chaves deve ser sempre o último recurso e só deve ser usado se você tiver certeza de que a chave excluída nunca mais será necessária. Novas tarefas que tentarem usar a chave excluída falharão porque não conseguirão acessá-la. O AWS KMS recomenda desabilitar a chave em vez de excluí-la. Se você achar necessário excluir uma chave, sugerimos desativá-la primeiro e definir um alarme do CloudWatch para ter certeza de que ela não é necessária. Se resolver excluir uma chave, o AWS KMS dá a você pelo menos sete dias para mudar de ideia.
**Auditar acesso a chaves AWS KMS**
Você pode usar os logs do CloudTrail para auditar o acesso à sua chave AWS KMS. Você pode verificar as operações `CreateGrant`, `GenerateDataKeyWithoutPlaintext` e `Decrypt` do AWS KMS. Essas operações também mostram a `aws:ecs:clusterAccount` e o `aws:ecs:clusterName` como parte do `EncryptionContext` registrado em log do CloudTrail.
O exemplo a seguir mostra eventos do CloudTrail para `GenerateDataKeyWithoutPlaintext`, `GenerateDataKeyWithoutPlaintext (DryRun)`, `CreateGrant`, `CreateGrant (DryRun)` e `RetireGrant` (substitua os valores *em vermelho* pelos seus).
------
#### [ GenerateDataKeyWithoutPlaintext ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "ec2-frontend-api.amazonaws.com"
},
"eventTime": "2024-04-23T18:08:13Z",
"eventSource": "kms.amazonaws.com",
"eventName": "GenerateDataKeyWithoutPlaintext",
"awsRegion": "us-west-2",
"sourceIPAddress": "ec2-frontend-api.amazonaws.com",
"userAgent": "ec2-frontend-api.amazonaws.com",
"requestParameters": {
"numberOfBytes": 64,
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"encryptionContext": {
"aws:ecs:clusterAccount": "account-id",
"aws:ebs:id": "vol-xxxxxxx",
"aws:ecs:clusterName": "cluster-name"
}
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
#### [ GenerateDataKeyWithoutPlaintext (DryRun) ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "fargate.amazonaws.com"
},
"eventTime": "2024-04-23T18:08:11Z",
"eventSource": "kms.amazonaws.com",
"eventName": "GenerateDataKeyWithoutPlaintext",
"awsRegion": "us-west-2",
"sourceIPAddress": "fargate.amazonaws.com",
"userAgent": "fargate.amazonaws.com",
"errorCode": "DryRunOperationException",
"errorMessage": "The request would have succeeded, but the DryRun option is set.",
"requestParameters": {
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"dryRun": true,
"numberOfBytes": 64,
"encryptionContext": {
"aws:ecs:clusterAccount": "account-id",
"aws:ecs:clusterName": "cluster-name"
}
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
#### [ CreateGrant ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "ec2-frontend-api.amazonaws.com"
},
"eventTime": "2024-04-23T18:08:13Z",
"eventSource": "kms.amazonaws.com",
"eventName": "CreateGrant",
"awsRegion": "us-west-2",
"sourceIPAddress": "ec2-frontend-api.amazonaws.com",
"userAgent": "ec2-frontend-api.amazonaws.com",
"requestParameters": {
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"granteePrincipal": "fargate.us-west-2.amazonaws.com",
"operations": [
"Decrypt"
],
"constraints": {
"encryptionContextSubset": {
"aws:ecs:clusterAccount": "account-id",
"aws:ebs:id": "vol-xxxx",
"aws:ecs:clusterName": "cluster-name"
}
},
"retiringPrincipal": "ec2.us-west-2.amazonaws.com"
},
"responseElements": {
"grantId": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": false,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
#### [ CreateGrant (DryRun) ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "fargate.amazonaws.com"
},
"eventTime": "2024-04-23T18:08:11Z",
"eventSource": "kms.amazonaws.com",
"eventName": "CreateGrant",
"awsRegion": "us-west-2",
"sourceIPAddress": "fargate.amazonaws.com",
"userAgent": "fargate.amazonaws.com",
"errorCode": "DryRunOperationException",
"errorMessage": "The request would have succeeded, but the DryRun option is set.",
"requestParameters": {
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"granteePrincipal": "fargate.us-west-2.amazonaws.com",
"dryRun": true,
"operations": [
"Decrypt"
],
"constraints": {
"encryptionContextSubset": {
"aws:ecs:clusterAccount": "account-id",
"aws:ecs:clusterName": "cluster-name"
}
}
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": false,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
#### [ RetireGrant ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "AWS Internal"
},
"eventTime": "2024-04-20T18:37:38Z",
"eventSource": "kms.amazonaws.com",
"eventName": "RetireGrant",
"awsRegion": "us-west-2",
"sourceIPAddress": "AWS Internal",
"userAgent": "AWS Internal",
"requestParameters": null,
"responseElements": {
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"additionalEventData": {
"grantId": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
},
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": false,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
# Retirada e manutenção de tarefas para o AWS Fargate no Amazon ECS
A AWS é responsável por manter a infraestrutura subjacente do AWS Fargate. A AWS determina quando uma revisão da versão da plataforma precisa ser substituída por uma nova revisão da infraestrutura. Isso é conhecido como retirada de tarefas. A AWS envia uma notificação de retirada da tarefa quando uma revisão da versão da plataforma é retirada. Atualizamos rotineiramente nossas versões da plataforma com suporte para introduzir uma revisão contendo atualizações do software de runtime do Fargate e dependências subjacentes, como o sistema operacional e o runtime do contêiner. Quando uma revisão mais recente é disponibilizada, retiramos a revisão mais antiga para garantir que todas as workloads do cliente sejam executadas na revisão mais atualizada da versão da plataforma do Fargate. Quando uma revisão é retirada, todas as tarefas em execução nessa revisão são interrompidas.
As tarefas do Amazon ECS podem ser categorizadas como tarefas de serviço ou tarefas autônomas. As tarefas de serviço são implantadas como parte de um serviço e controladas pela programação do Amazon ECS. Para obter mais informações, consulte [Serviços do Amazon ECS](ecs_services.md). As tarefas autônomas são tarefas iniciadas pela API `RunTask` do Amazon ECS, diretamente ou por um agendador externo, como tarefas programadas (que são iniciadas pelo Amazon EventBridge), AWS Batch ou AWS Step Functions. Você não precisa realizar nenhuma ação em resposta à retirada de tarefas de suas tarefas de serviço porque o programador do Amazon ECS substitui automaticamente as tarefas.
Para tarefas autônomas, talvez seja necessário realizar um tratamento adicional em resposta à retirada da tarefa. Para obter mais informações, consulte [O Amazon ECS pode processar automaticamente as tarefas autônomas?](#task-retirement-standalone-tasks).
Para tarefas de serviço, você não precisa realizar nenhuma ação para a retirada da tarefa, a menos que queira substituí-las antes de a AWS fazê-lo. Quando o agendador do Amazon ECS interrompe as tarefas, ele usa `maximumPercent` e executa uma nova tarefa na tentativa de manter a contagem desejada do serviço. Siga as práticas recomendadas para minimizar o impacto da inativação de tarefas. O valor padrão `maximumPercent` para um serviço que usa o agendador de serviço REPLICA é 200%. Portanto, quando o AWS Fargate inicia a retirada de tarefas, o Amazon ECS primeiro agenda uma nova tarefa e espera que ela seja executada, antes de retirar uma tarefa antiga. Quando o valor `maximumPercent` é definido como 100%, o Amazon ECS interrompe a tarefa primeiro e, em seguida, a substitui.
Para a retirada autônoma da tarefa, a AWS interrompe a tarefa na data de retirada da tarefa ou após ela. O Amazon ECS não inicia uma tarefa de substituição quando uma tarefa é interrompida. Se precisar que essas tarefas continuem em execução, é necessário interromper a execução delas e iniciar uma tarefa substituta antes da hora indicada na notificação. Portanto, recomendamos que os clientes monitorem o estado das tarefas autônomas e, se necessário, implementem a lógica para substituir as tarefas interrompidas.
Quando uma tarefa é interrompida em qualquer um dos cenários, é possível executar `describe-tasks`. O `stoppedReason` na resposta é `ECS is performing maintenance on the underlying infrastructure hosting the task`.
A manutenção de tarefas se aplica quando uma revisão da nova versão da plataforma precisa ser substituída por uma nova. Se houver um problema com um host subjacente do Fargate, o Amazon ECS substitui o host sem um aviso de retirada da tarefa.
## Visão geral do aviso de retirada de tarefa
Quando a AWS marca uma revisão da versão da plataforma como precisando ser retirada, identificamos todas as tarefas que estão sendo executadas nessa revisão da versão da plataforma em todas as regiões.
A ilustração a seguir mostra o ciclo de vida de uma revisão da versão da plataforma Fargate, desde o lançamento de uma nova revisão até a retirada da revisão da plataforma.
![\[Diagrama mostrando o ciclo de vida de retirada de tarefas do Fargate.\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/images/fargate-task-retirement.png)
As informações a seguir fornecem detalhes.
+ Depois que uma nova revisão da versão da plataforma é lançada, todas as novas tarefas são agendadas nessa revisão.
+ As tarefas existentes que foram agendadas e executadas permanecem na revisão em que foram originalmente colocadas durante a tarefa e não são migradas para a nova revisão.
+ Novas tarefas, por exemplo, como parte de uma atualização de um serviço ou da retirada de tarefas do Fargate, são inseridas na revisão mais recente da versão da plataforma disponível no momento do lançamento.
As notificações de retirada de tarefa são enviadas por meio do Painel do AWS Health e para o endereço de e-mail registrado e incluem as seguintes informações:
+ A data de retirada da tarefa: a tarefa é interrompida nessa data ou após essa data.
+ Para tarefas autônomas, os IDs das tarefas.
+ Para tarefas de serviço, o ID do cluster em que o serviço é executado e os IDs do serviço.
+ As próximas etapas que você precisa seguir.
Normalmente, enviamos uma notificação de serviço e tarefas autônomas em cada Região da AWS. No entanto, em alguns casos, você pode receber mais de um evento para cada tipo de tarefa, por exemplo, quando há muitas tarefas a serem retiradas que ultrapassarão os limites nos mecanismos de notificação.
É possível identificar tarefas programadas para retirada das maneiras a seguir:
+ O Health Dashboard
As notificações AWS Health podem ser enviadas por meio do Amazon EventBridge para que um armazenamento de arquivamento, como o Amazon Simple Storage Service, execute ações automatizadas, como executar uma função do AWS Lambda, ou outros sistemas de notificação, como o Amazon Simple Notification Service. Para obter mais informações, consulte [Monitoramento de eventos do AWS Health com o Amazon EventBridge](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html). Para obter um exemplo de configuração do envio de notificações para o Amazon Chime, Slack, ou Microsoft Teams, consulte o repositório [AWS Health Aware](https://github.com/aws-samples/aws-health-aware) no GitHub.
Veja a seguir um exemplo de evento do EventBridge.
```
{
"version": "0",
"id": "3c268027-f43c-0171-7425-1d799EXAMPLE",
"detail-type": "AWS Health Event",
"source": "aws.health",
"account": "123456789012",
"time": "2023-08-16T23:18:51Z",
"region": "us-east-1",
"resources": [
"cluster|service",
"cluster|service"
],
"detail": {
"eventArn": "arn:aws:health:us-east-1::event/ECS/AWS_ECS_TASK_PATCHING_RETIREMENT/AWS_ECS_TASK_PATCHING_RETIREMENT_test1",
"service": "ECS",
"eventScopeCode": "ACCOUNT_SPECIFIC",
"communicationId": "7988399e2e6fb0b905ddc88e0e2de1fd17e4c9fa60349577446d95a18EXAMPLE",
"lastUpdatedTime": "Wed, 16 Aug 2023 23:18:52 GMT",
"eventRegion": "us-east-1",
"eventTypeCode": "AWS_ECS_TASK_PATCHING_RETIREMENT",
"eventTypeCategory": "scheduledChange",
"startTime": "Wed, 16 Aug 2023 23:18:51 GMT",
"endTime": "Fri, 18 Aug 2023 23:18:51 GMT",
"eventDescription": [
{
"language": "en_US",
"latestDescription": "\\nA software update has been deployed to Fargate which includes CVE patches or other critical patches. No action is required on your part. All new tasks launched automatically uses the latest software version. For existing tasks, your tasks need to be restarted in order for these updates to apply. Your tasks running as part of the following ECS Services will be automatically updated beginning Wed, 16 Aug 2023 23:18:51 GMT.\\n\\nAfter Wed, 16 Aug 2023 23:18:51 GMT, the ECS scheduler will gradually replace these tasks, respecting the deployment settings for your service. Typically, services should see little to no interruption during the update and no action is required. When AWS stops tasks, AWS uses the minimum healthy percent (1) and launches a new task in an attempt to maintain the desired count for the service. By default, the minimum healthy percent of a service is 100 percent, so a new task is started first before a task is stopped. Service tasks are routinely replaced in the same way when you scale the service or deploy configuration changes or deploy task definition revisions. If you would like to control the timing of this restart you can update the service before Wed, 16 Aug 2023 23:18:51 GMT, by running the update-service command from the ECS command-line interface specifying force-new-deployment for services using Rolling update deployment type. For example:\\n\\n$ aws ecs update-service -service service_name \\\n--cluster cluster_name -force-new-deployment\\n\\nFor services using Blue/Green deployment type with AWS CodeDeploy:\\nPlease refer to create-deployment document (2) and create new deployment using same task definition revision.\\n\\nFor further details on ECS deployment types, please refer to ECS Deployment Developer Guide (1).\\nFor further details on Fargate's update process, please refer to the AWS Fargate User Guide (3).\\nIf you have any questions or concerns, please contact AWS Support (4).\\n\\n(1) https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-types.html\\n(2) https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html\\n(3) https://docs.aws.amazon.com/AmazonECS/latest/userguide/task-maintenance.html\\n(4) https://aws.amazon.com/support\\n\\nA list of your affected resources(s) can be found in the 'Affected resources' tab in the 'Cluster/ Service' format in the AWS Health Dashboard. \\n\\n"
}
],
"affectedEntities": [
{
"entityValue": "arn:aws:ecs:eu-west-1:111222333444:task/examplecluster/00805ce1d81940b5a37398e5a2c23333"
},
{
"entityValue": "arn:aws:ecs:eu-west-1:111222333444:task/examplecluster/00805ce1d81940b5a37398e5a2c25555"
}
}
]
}
}
```
+ E-mail
Um email é enviado para o email registrado para obter o ID Conta da AWS.
Para obter informações sobre como se preparar para a retirada de tarefas, consulte [Prepare-se para a retirada de tarefas do AWS Fargate no Amazon ECS](prepare-task-retirement.md).
## Posso optar pela não retirada de tarefas?
Não. Como parte do modelo de responsabilidade compartilhada da AWS, a AWS é responsável por gerenciar e manter a infraestrutura subjacente do AWS Fargate. Isso inclui a realização de atualizações periódicas da plataforma para garantir a segurança e a estabilidade. Essas atualizações são aplicadas automaticamente pela AWS e não são algo que os clientes possam optar por não aceitar. Esse é um dos principais benefícios de usar um AWS Fargate em comparação com a execução de suas workloads em instâncias do EC2, a responsabilidade pela manutenção da plataforma subjacente é assumida pela AWS. Esse modelo permite que você se concentre em suas aplicações em vez da manutenção da infraestrutura. Ao aplicar automaticamente essas atualizações da plataforma, a AWS é capaz de manter o ambiente do Fargate atualizado e seguro, sem nenhuma ação exigida de você como cliente. Isso ajuda a fornecer um ambiente em contêineres confiável e seguro para executar suas workloads no Fargate.
## Posso receber notificações de retirada de tarefas por meio de outros serviços da AWS?
A AWS envia uma notificação de retirada da tarefa para o Health Dashboard e para o principal contato de e-mail na Conta da AWS. O Health Dashboard fornece várias integrações com outros serviços da AWS, incluindo o EventBridge. Você pode usar o EventBridge para automatizar a visibilidade dos avisos (por exemplo, encaminhar a mensagem para uma ferramenta de ChatOps). Para obter mais informações, consulte [Solution overview: Capturing task retirement notifications](https://aws.amazon.com/blogs/containers/improving-operational-visibility-with-aws-fargate-task-retirement-notifications/).
## Posso alterar a retirada de uma tarefa depois de programada?
Não. O cronograma é baseado no tempo de espera de retirada da tarefa, que tem um padrão de sete dias. Se precisar de mais tempo, você pode configurar o período de espera para 14 dias. Para obter mais informações, consulte [Etapa 2: capturar as notificações de retiradas de tarefas para alertar as equipes e tomar medidas](prepare-task-retirement.md#prepare-task-retirement-capture-task-events).
A partir de 18/12/2025, o Amazon ECS permite que você configure [janelas de eventos do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html) para suas tarefas do Fargate. Se você precisar de um controle preciso sobre o momento exato das retiradas de tarefas, por exemplo, programando-as nos finais de semana para evitar interrupções durante o horário comercial, você pode configurar janelas de eventos do Amazon EC2 para suas tarefas, serviços ou clusters. Consulte [Etapa 1: defina o tempo de espera da tarefa ou use as janelas de eventos do Amazon EC2.](prepare-task-retirement.md#prepare-task-retirement-set-time). Observe que a alteração nessa configuração se aplica às retiradas que serão programadas no futuro. As retiradas programadas atualmente não são afetadas. Além disso, quando você configura uma janela de eventos do Amazon EC2 para suas tarefas do Fargate, ela tem precedência sobre a configuração do tempo de espera de desativação da tarefa. Em caso de dúvidas, entre em contato com o Suporte.
## Como o Amazon ECS processa tarefas que fazem parte de um serviço?
Para tarefas de serviço, você não precisa realizar nenhuma ação em resposta à retirada de tarefas, a menos que queira substituí-las antes de a AWS fazê-lo. Quando o agendador do Amazon ECS interrompe as tarefas, ele usa a porcentagem mínima de integridade e executa uma nova tarefa na tentativa de manter a contagem desejada do serviço. Para minimizar o impacto da retirada de tarefas do Fargate, você deve seguir as práticas recomendadas do Amazon ECS ao implantar workloads. Por exemplo, ao implantar uma aplicação sem estado como um serviço do Amazon ECS, como um servidor Web ou de API, os clientes devem implantar várias réplicas de tarefas e defini-las como minimumHealthyPercent a 100%. Por padrão, a porcentagem mínima de integridade de um serviço é 100%. Portanto, quando o Fargate inicia a retirada de tarefas, o Amazon ECS primeiro agenda uma nova tarefa e espera que ela seja executada, antes de retirar uma tarefa antiga. As tarefas de serviço são substituídas rotineiramente como parte da retirada de tarefas da mesma forma quando você escala o serviço, implanta alterações de configuração ou implanta revisões de definição de tarefas. Para se preparar para o processo de retirada de tarefas, consulte [Prepare-se para a retirada de tarefas do AWS Fargate no Amazon ECS](prepare-task-retirement.md).
## O Amazon ECS pode processar automaticamente as tarefas autônomas?
Não. A AWS não consegue criar uma tarefa substituta para tarefas autônomas iniciadas por `RunTask`, tarefas programadas (por exemplo, por meio do Agendador do EventBridge), AWS Batch ou AWS Step Functions. O Amazon ECS gerencia somente tarefas que fazem parte de um serviço.
## Solução de problemas de disponibilidade do serviço durante a descontinuação da tarefa
Se o Amazon ECS não puder iniciar uma tarefa de substituição durante a descontinuação da tarefa, a disponibilidade do seu serviço poderá ser afetada. Isso pode ocorrer devido à configuração incorreta do cliente, como:
+ Perfis do IAM ausentes ou configurados incorretamente
+ Capacidade insuficiente nas sub-redes de destino
+ Configurações incorretas do grupo de segurança
+ Erros na definição das tarefas
Quando o Amazon ECS não consegue lançar tarefas de substituição, as tarefas descontinuadas são interrompidas sem substituição, reduzindo a capacidade disponível do seu serviço e potencialmente causando sua interrupção. Monitore a contagem de tarefas do seu serviço e as métricas do Amazon CloudWatch para garantir que as tarefas de substituição sejam lançadas com sucesso durante os eventos de descontinuação.
# Prepare-se para a retirada de tarefas do AWS Fargate no Amazon ECS
Para se preparar para a retirada da tarefa, execute as seguintes operações:
1. Defina o período de espera para retirada da tarefa ou use as janelas de eventos do Amazon EC2.
1. Capture notificações de retirada de tarefas para notificar os membros da equipe.
1. Você pode garantir que todas as tarefas dos seus serviços sejam executadas na revisão da versão mais recente da plataforma, ao atualizar o serviço com a opção de implantação forçada. Esta etapa é opcional.
## Etapa 1: defina o tempo de espera da tarefa ou use as janelas de eventos do Amazon EC2.
Você tem duas opções de configuração de conta para definir a hora em que o Fargate inicia as retiradas de tarefas: `fargateTaskRetirementWaitPeriod` e `fargateEventWindows`.
**Usar a configuração da conta fargateTaskRetirementWaitPeriod**
É possível configurar a hora em que o Fargate inicia a retirada da tarefa. O período de espera padrão é de 7 dias. Para workloads que exijam a aplicação imediata das atualizações, escolha a configuração imediata (`0`). Se precisar de mais tempo, configure a opção de `7` ou `14` dias.
Recomendamos que você escolha um período de espera mais curto para receber as revisões das versões da plataforma mais recentes mais cedo.
Configure o período de espera executando `put-account-setting-default` ou `put-account-setting` como usuário-raiz ou um usuário administrativo. Use a opção `fargateTaskRetirementWaitPeriod` para o `name` e a opção `value` definida como um dos valores a seguir:
+ `0`: A AWS envia a notificação e imediatamente começa a retirar as tarefas afetadas.
+ `7`: A AWS envia a notificação e aguarda 7 dias corridos antes de começar a retirar as tarefas afetadas. Esse é o padrão.
+ `14`: A AWS envia a notificação e aguarda 14 dias corridos antes de começar a retirar as tarefas afetadas.
Para obter mais informações, consulte [put-account-setting-default](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting-default.html) e [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html) na *Referência de API do Amazon Elastic Container Service*.
**Usar a configuração da conta fargateEventWindows**
A partir de 18/12/2025, o Amazon ECS permite que você configure [janelas de eventos do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html) para suas tarefas do Fargate. Se você precisar de um controle preciso sobre o momento exato das retiradas de tarefas, por exemplo, programando-as nos finais de semana para evitar interrupções durante o horário comercial, você pode configurar janelas de eventos do Amazon EC2 para suas tarefas, serviços ou clusters.
Quando você usa janelas de eventos, o Fargate garante que suas tarefas sejam executadas por pelo menos 3 dias antes de serem retiradas na próxima janela disponível, a menos que sejam interrompidas por ações iniciadas pelo usuário ou eventos críticos de integridade, como degradação do hardware subjacente.
Defina a configuração da conta `fargateEventWindows` como `enabled`. Você pode usar uma das seguintes APIs: `put-account-setting-default` ou `put-account-setting` como usuário-raiz ou usuário administrativo.
Cada janela de evento do Amazon EC2 deve estar aberta por pelo menos 4 horas por semana e cada intervalo de tempo deve ter pelo menos 2 horas de duração. Para grandes clusters e serviços, recomendamos configurar janelas de eventos com durações longas (8 horas ou mais) ou intervalos de tempo mais frequentes que ocorram pelo menos uma vez a cada 3 dias. Consulte mais detalhes sobre as janelas de eventos do Amazon EC2 no [guia do usuário](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html#event-windows-considerations). O AWS Fargate garante que suas tarefas sejam executadas por pelo menos 3 dias antes de serem retiradas, a menos que sejam interrompidas por ações iniciadas pelo usuário ou eventos críticos de integridade, como a degradação do hardware subjacente.
**Importante**
A substituição de tarefas na janela do evento é a melhor opção. Se você notar que as tarefas estão sendo retiradas fora das janelas do evento, considere expandir a duração (8 horas ou mais) ou aumentar a frequência (pelo menos uma vez a cada 3 dias).
Para aplicar janelas de eventos do Amazon EC2 às retiradas de suas tarefas do Fargate:
+ Defina a configuração da conta `fargateEventWindows` como `enabled`. Você pode usar uma das seguintes APIs: `put-account-setting-default` ou `put-account-setting` como usuário-raiz ou usuário administrativo. Observe que essa é uma habilitação única para o uso do atributo de janelas de eventos do Amazon EC2 para suas tarefas do Fargate.
+ Crie uma janela de eventos do Amazon EC2 por meio do console da AWS ou da AWS CLI. Para criar uma janela de eventos usando a CLI, use a API `create-instance-event-window` do EC2 com intervalos de tempo ou expressões cron. Anote o valor do `InstanceEventWindowId` na resposta.
```
aws ec2 create-instance-event-window \
--time-range StartWeekDay=monday,StartHour=2,EndWeekDay=wednesday,EndHour=8 \
--tag-specifications "ResourceType=instance-event-window,Tags=[{Key=K1,Value=V1" \
--name myEventWindowName
```
Como alternativa, você pode usar expressões cron ao criar janelas de eventos do EC2.
```
aws ec2 create-instance-event-window \
--cron-expression "* 21-23 * * 2,3" \
--tag-specifications "ResourceType=instance-event-window,Tags=[{Key=K1,Value=V1" \
--name myEventWindowName
```
+ Em seguida, você pode associar a janela do evento a serviços específicos, clusters ou a todas as tarefas em sua conta usando a API `associate-instance-event-window` do EC2.
+ Para tarefas de serviço do ECS
```
aws ec2 associate-instance-event-window \
--instance-event-window-id iew-0abcdef1234567890 \
--association-target "InstanceTags=[{Key=aws:ecs:serviceArn,Value=your-service-arn}]"
```
+ Para cluster do ECS
```
aws ec2 associate-instance-event-window \
--instance-event-window-id iew-0abcdef1234567890 \
--association-target "InstanceTags=[{Key=aws:ecs:clusterArn,Value=your-cluster-arn}]"
```
+ Para associar uma janela de eventos a todas as tarefas na conta
```
aws ec2 associate-instance-event-window \
--instance-event-window-id iew-0abcdef1234567890 \
--association-target "InstanceTags=[{Key=aws:ecs:fargateTask,Value=true}]"
```
Você pode usar mais de um par chave-valor para associar uma janela de eventos a vários serviços ou clusters.
O Fargate escolherá a janela do eventos para cada tarefa na seguinte ordem:
+ Se houver uma janela de eventos associada ao serviço da tarefa, ela será usada. Isso não se aplica a tarefas autônomas ou não gerenciadas.
+ Se houver uma janela de eventos associada ao cluster da tarefa, ela será usada.
+ Se houver uma janela de evento definida para todas as tarefas do Fargate, ela será usada.
+ A configuração `fargateTaskRetirementWaitPeriod` será usada se nenhuma das janelas de eventos corresponder à tarefa.
**Configurar janelas de eventos para manutenção de tarefas do Fargate**
Considere um caso em que você está executando vários serviços do ECS no Fargate com diferentes requisitos de disponibilidade. Você quer um controle preciso sobre as retiradas de tarefas. Você pode configurar várias janelas de eventos da seguinte forma:
+ **Manutenção padrão para todas as tarefas do Fargate**: crie uma janela de eventos para manutenção de rotina fora do horário de pico (diariamente da 0h às 4h) e associe-a a todas as tarefas do Fargate usando a tag ` aws:ecs:fargateTask`.
+ **Manutenção somente no fim de semana para o cluster de desenvolvimento**: para um cluster de desenvolvimento com serviços que podem tolerar interrupções nos finais de semana, crie uma janela de 24 horas no fim de semana (sábado e domingo, o dia todo) e associe-a ao cluster usando a tag `aws:ecs:clusterArn` com o ARN do seu cluster.
+ **Período restrito para serviços essenciais**: para um serviço de processamento de pagamentos de missão crítica que exige alto tempo de atividade durante a semana, restrinja a manutenção às primeiras horas da manhã do fim de semana (sábado e domingo, da 0h às 4h) e associe-a ao serviço específico usando a tag `aws:ecs:serviceArn` com o ARN do serviço.
Com essa configuração, o serviço de pagamento usa sua janela específica somente para fins de semana, os serviços e tarefas do cluster de desenvolvimento usam a janela de 24 horas do fim de semana e todas as demais tarefas do Fargate usam a janela de manutenção diária padrão.
Para obter mais informações, consulte [put-account-setting-default](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting-default.html) e [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html) na *Referência de API do Amazon Elastic Container Service*.
## Etapa 2: capturar as notificações de retiradas de tarefas para alertar as equipes e tomar medidas
Quando houver um retirada de tarefa próxima, a AWS envia uma notificação de retirada de tarefa para o Painel do AWS Health e para o contato de e-mail principal na Conta da AWS. O Painel do AWS Health fornece várias integrações com outros serviços da AWS, incluindo o Amazon EventBridge. É possível usar o EventBridge para criar automações a partir de uma notificação de retirada de tarefa, como aumentar a visibilidade da próxima retirada, ao encaminhar a mensagem para uma ferramenta ChatOps. AWS Health O Aware é um recurso que mostra o poder do Painel do AWS Health e como as notificações podem ser distribuídas por toda a organização. Você pode encaminhar uma notificação de retirada de tarefa para um aplicativo de bate-papo, como o Slack.
A ilustração a seguir mostra a visão geral da solução.
![\[Diagrama mostrando a solução Fargate para capturar avisos de retirada de tarefas do Fargate.\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/images/fargate-task-retirement-solution.png)
As informações a seguir fornecem detalhes.
+ O Fargate envia a notificação de retirada da tarefa para o Painel do AWS Health.
+ O Painel do AWS Health envia e-mail para o contato de e-mail principal na Conta da AWS e notifica o EventBridge.
+ O EventBridge tem uma regra que captura a notificação de retirada.
A regra de busca de eventos com o tipo de detalhe do evento: `"AWS Health Event" and the Event Detail Type Code: "AWS_ECS_TASK_PATCHING_RETIREMENT"`
+ A regra aciona uma função do Lambda que encaminha as informações para o Slack usando um webhook de entrada do Slack. Para obter mais informações, consulte [Webhooks de entrada](https://slack.com/marketplace/A0F7XDUAZ-incoming-webhooks).
Para ver um exemplo de código, consulte [Capturing AWS Fargate Task Retirement Notifications](https://github.com/aws-samples/capturing-aws-fargate-task-retirement-notifications/tree/main) no Github.
## Etapa 3: controlar a retirada de tarefas
Você não pode controlar o momento exato da retirada de uma tarefa, no entanto, você pode definir um tempo de espera. Se quiser controlar a retirada de tarefas de acordo com sua própria programação, é possível capturar o aviso de retirada da tarefa para primeiro entender a data de retirada da tarefa. Você pode então reimplantar seu serviço para iniciar retiradas de tarefas e, da mesma forma, substituir quaisquer tarefas autônomas. Para serviços que usam implantação contínua, você atualiza o serviço usando `update-service` com a opção `force-deployment` antes do horário de início da retirada.
O exemplo `update-service` a seguir usa a opção `force-deployment`.
```
aws ecs update-service —-service service_name \
--cluster cluster_name \
--force-new-deployment
```
Em serviços que usam a implantação azul/verde, você precisa criar uma implantação no AWS CodeDeploy. Para obter informações sobre como criar a implantação, consulte [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html) na *Referência da AWS Command Line Interface*.
# Regiões com suporte para Amazon ECS no AWS Fargate
Você pode usar as tabelas a seguir para verificar o suporte regional para contêineres do Linux no AWS Fargate e contêineres do Windows no AWS Fargate.
## Contêineres do Linux no AWS Fargate
Os contêineres do Linux do Amazon ECS no AWS Fargate são compatíveis com as seguintes Regiões da AWS. Os IDs das zonas de disponibilidade compatíveis são anotados quando aplicável.
| Nome da Região | Região |
| --- | --- |
| Leste dos EUA (Ohio) | us-east-2 |
| Leste dos EUA (Norte da Virgínia) | us-east-1 |
| Oeste dos EUA (Norte da Califórnia) | us-west-1 (somente `usw1-az1` e `usw1-az3`) |
| Oeste dos EUA (Oregon) | us-west-2 |
| Canadá (Central) | ca-central-1 |
| Oeste do Canadá (Calgary) | ca-west-1 |
| México (Central) | mx-central-1 |
| África (Cidade do Cabo) | af-south-1 |
| Ásia-Pacífico (Hong Kong) | ap-east-1 |
| Ásia-Pacífico (Mumbai) | ap-south-1 |
| Ásia-Pacífico (Tóquio) | ap-northeast-1 (somente `apne1-az1`, `apne1-az2` e `apne1-az4`) |
| Ásia-Pacífico (Seul) | ap-northeast-2 |
| Ásia-Pacífico (Osaka) | ap-northeast-3 |
| Ásia-Pacífico (Hyderabad) | ap-south-2 |
| Ásia-Pacífico (Singapura) | ap-southeast-1 |
| Ásia-Pacífico (Sydney) | ap-southeast-2 |
| Ásia-Pacífico (Tailândia) | ap-southeast-7 |
| Ásia-Pacífico (Jacarta) | ap-southeast-3 |
| Ásia-Pacífico (Melbourne) | ap-southeast-4 |
| Ásia-Pacífico (Malásia) | ap-southeast-5 |
| Canadá (Central) | ca-central-1 |
| Oeste do Canadá (Calgary) | ca-west-1 |
| China (Pequim) | cn-north-1 (somente `cnn1-az1` e `cnn1-az2`) |
| China (Ningxia) | cn-northwest-1 |
| Europa (Frankfurt) | eu-central-1 |
| Europa (Zurique) | eu-central-2 |
| Europa (Irlanda) | eu-west-1 |
| Europa (Londres) | eu-west-2 |
| Europa (Paris) | eu-west-3 |
| Europa (Milão) | eu-south-1 |
| Europa (Espanha) | eu-south-2 |
| Europa (Estocolmo) | eu-north-1 |
| América do Sul (São Paulo) | sa-east-1 |
| Israel (Tel Aviv) | il-central-1 |
| Oriente Médio (Barém) | me-south-1 |
| Oriente Médio (Emirados Árabes Unidos) | me-central-1 |
| AWS GovCloud (Leste dos EUA) | us-gov-east-1 |
| AWS GovCloud (Oeste dos EUA) | us-gov-west-1 |
## Contêineres do Windows no AWS Fargate
Os contêineres do Windows do Amazon ECS no AWS Fargate são compatíveis com as seguintes Regiões da AWS. Os IDs das zonas de disponibilidade compatíveis são anotados quando aplicável.
| Nome da Região | Região |
| --- | --- |
| Leste dos EUA (Ohio) | us-east-2 |
| Leste dos EUA (Norte da Virgínia) | us-east-1 (somente `use1-az1`, `use1-az2`, `use1-az4`, `use1-az5` e `use1-az6`) |
| Oeste dos EUA (N. da Califórnia) | us-west-1 (somente `usw1-az1` e `usw1-az3`) |
| Oeste dos EUA (Oregon) | us-west-2 |
| África (Cidade do Cabo) | af-south-1 |
| Ásia-Pacífico (Hong Kong) | ap-east-1 |
| Ásia-Pacífico (Mumbai) | ap-south-1 |
| Ásia-Pacífico (Hyderabad) | ap-south-2 |
| Ásia-Pacífico (Osaka) | ap-northeast-3 |
| Ásia-Pacífico (Seul) | ap-northeast-2 |
| Ásia-Pacífico (Singapura) | ap-southeast-1 |
| Ásia-Pacífico (Sydney) | ap-southeast-2 |
| Ásia-Pacífico (Melbourne) | ap-southeast-4 |
| Ásia-Pacífico (Malásia) | ap-southeast-5 |
| Ásia-Pacífico (Tóquio) | ap-northeast-1 (somente `apne1-az1`, `apne1-az2` e `apne1-az4`) |
| Canadá (Central) | ca-central-1 (somente `cac1-az1` e `cac1-az2`) |
| Oeste do Canadá (Calgary) | ca-west-1 |
| China (Pequim) | cn-north-1 (somente `cnn1-az1` e `cnn1-az2`) |
| China (Ningxia) | cn-northwest-1 |
| Europa (Frankfurt) | eu-central-1 |
| Europa (Zurique) | eu-central-2 |
| Europa (Irlanda) | eu-west-1 |
| Europa (Londres) | eu-west-2 |
| Europa (Paris) | eu-west-3 |
| Europa (Milão) | eu-south-1 |
| Europa (Espanha) | eu-south-2 |
| Europa (Estocolmo) | eu-north-1 |
| América do Sul (São Paulo) | sa-east-1 |
| Israel (Tel Aviv) | il-central-1 |
| Oriente Médio (Emirados Árabes Unidos) | me-central-1 |
| Oriente Médio (Bahrein) | me-south-1 |