

# Projetar sua aplicação para o Amazon ECS
<a name="application_architecture"></a>

Você arquiteta a aplicação criando uma definição de tarefa para ela. A definição da tarefa contém os parâmetros que definem as informações sobre a aplicação, incluindo:
+ A capacidade a ser usada, que determina a infraestrutura na qual as tarefas são hospedadas.

  Ao usar o provedor de capacidade do EC2, você também escolhe o tipo de instância. Ao usar o provedor de capacidade de instâncias gerenciadas do Amazon ECS, você pode fornecer requisitos de instância para que o Amazon ECS gerencie a capacidade computacional. Em alguns tipos de instância, como GPU, é necessário definir parâmetros específicos. Para obter mais informações, consulte [Casos de uso de definição de tarefa do Amazon ECS](use-cases.md).
+ A imagem de contêiner, que contém o código da aplicação e todas as dependências que o código da aplicação requer para ser executado.
+ O modo de rede a ser usado para os contêineres na sua tarefa.

  O modo de rede determina como a tarefa se comunica pela rede.

  Em tarefas executadas nas instâncias do EC2 e nas instâncias gerenciadas do Amazon ECS, há várias opções, mas recomendamos usar o modo de rede `awsvpc`. O modo de rede `awsvpc` simplifica a rede de contêineres, oferecendo mais controle sobre como as aplicações se comunicam entre si e com outros serviços dentro das VPCs. 

  Em tarefas executadas no Fargate, você deve usar o modo de rede `awsvpc`.
+ A configuração de registro em log a ser usada nas tarefas.
+ Quaisquer volumes de dados que são usados com os contêineres na tarefa.

Para obter uma lista completa de parâmetros de definição de tarefa, consulte [Parâmetros de definição de tarefa do Amazon ECS para o Fargate](task_definition_parameters.md).

Use as diretrizes a seguir ao criar suas definições de tarefas:
+ Use cada família de definição de tarefas para apenas uma finalidade comercial.

  Se você agrupar vários tipos de contêineres de aplicações na mesma definição de tarefa, não poderá escalar esses contêineres de forma independente. Por exemplo, um site e uma API normalmente exigem padrões de escalabilidade diferentes. À medida que o tráfego aumenta, você talvez vá precisar de um número diferente de contêineres da Web do que o de contêineres de API. Se esses dois contêineres forem implantados na mesma definição de tarefa, todas as tarefas executarão o mesmo número de contêineres da Web e contêineres de API.
+ Combine cada versão da aplicação com uma revisão de definição de tarefa dentro de uma família de definição de tarefa.

  Dentro de uma família de definições de tarefas, cada revisão de definição de tarefa representa um snapshot pontual das configurações de uma imagem de contêiner específica. Isso é semelhante à forma como o contêiner é um snapshot de todos os componentes que são necessários para executar uma versão específica do código da sua aplicação.

  Crie um mapeamento individual entre uma versão do código da aplicação, uma tag de imagem de contêiner e uma revisão da definição da tarefa. Um processo de lançamento típico envolve um git commit que é transformado em uma imagem de contêiner com tag atribuída do SHA do git commit. Em seguida, essa tag de imagem de contêiner recebe sua própria revisão de definição de tarefa do Amazon ECS. Por último, o serviço do Amazon ECS é atualizado para implantar a nova revisão da definição da tarefa.
+ Use perfis do IAM diferentes para cada família de definição de tarefa.

  Defina cada definição de tarefa com seu próprio perfil do IAM. Implemente essa prática e forneça a cada componente de negócio sua própria família de definições de tarefas. Ao implementar essas duas práticas recomendadas, é possível limitar o acesso que cada serviço tem aos recursos da sua conta da AWS. Por exemplo, é possível conceder acesso ao seu serviço de autenticação para se conectar ao seu banco de dados de senhas. Ao mesmo tempo, você também pode garantir que somente o serviço de pedidos tenha acesso às informações de pagamento do cartão de crédito.

# Práticas recomendadas para tamanhos de tarefas do Amazon ECS
<a name="capacity-tasksize"></a>

 Os tamanhos de contêineres e tarefas são essenciais para o planejamento de ajuste de escala e de capacidade. No Amazon ECS, CPU e memória são as duas métricas de recursos usadas para capacidade. A CPU é medida em unidades de 1/1024 de uma vCPU completa (1.024 unidades são iguais a 1 vCPU inteira). A memória é medida em mebibytes. Na definição da tarefa, é possível configurar reservas e limites de recursos.

Ao configurar uma reserva, você está definindo a quantidade mínima de recursos que uma tarefa exige. Sua tarefa recebe, pelo menos, a quantidade de recursos solicitada. A aplicação pode conseguir usar mais CPU ou memória do que a reserva declarada. No entanto, isso está sujeito a quaisquer limites que também foram declarados. Usar mais do que a quantidade da reserva é conhecido como intermitência. No Amazon ECS, as reservas são garantidas. Por exemplo, se você usar instâncias do Amazon EC2 para fornecer capacidade, o Amazon ECS não coloca uma tarefa em uma instância em que a reserva não possa ser atendida.

Um limite é a quantidade máxima de unidades de CPU ou memória que o contêiner ou a tarefa pode usar. Qualquer tentativa de usar mais CPU além desse limite resulta em controle de utilização. Qualquer tentativa de usar mais memória faz com que o contêiner seja interrompido.

Escolher esses valores pode ser um desafio. Isso ocorre porque os valores mais adequados para a aplicação dependem muito dos requisitos de recursos da aplicação. Testar a carga da aplicação é a chave para um planejamento bem-sucedido dos requisitos de recursos e para uma melhor compreensão dos requisitos da aplicação.

## Aplicações sem estado
<a name="capacity-tasksize-stateless"></a>

Em aplicações sem estado que escalam horizontalmente, como uma aplicação por trás de um balanceador de carga, recomendamos primeiro determinar a quantidade de memória que a aplicação consome ao atender às solicitações. Para isso, você pode usar ferramentas tradicionais, como `ps` ou `top`, ou soluções de monitoramento, como o CloudWatch Container Insights.

Ao determinar uma reserva de CPU, considere como você deseja escalar a aplicação para atender às suas necessidades de negócios. Você pode usar reservas de CPU menores, como 256 unidades de CPU (ou 1/4 de vCPU), para aumentar a escala horizontalmente de uma forma refinada que minimize os custos. Porém, elas podem não ser escaladas com rapidez suficiente para atender a picos significativos na demanda. Você pode usar reservas maiores de CPU para aumentar e reduzir a escala horizontalmente com mais rapidez e, portanto, atender aos picos de demanda com mais rapidez. No entanto, reservas maiores de CPU são mais caras.

## Outros aplicativos
<a name="capacity-tasksize-other"></a>

Em aplicações que não são escaláveis horizontalmente, como operadores únicos ou servidores de banco de dados, a capacidade disponível e o custo representam suas considerações mais importantes. Você deve escolher a quantidade de memória e CPU com base na necessidade indicada pelo teste de carga para fornecer um tráfego que atinja seu objetivo no nível de serviço. O Amazon ECS garante que a aplicação seja colocada em um host com capacidade adequada.

# Rede de tarefas do Amazon ECS para instâncias gerenciadas do Amazon ECS
<a name="managed-instance-networking"></a>

O comportamento da rede das tarefas do Amazon ECS executadas em instâncias gerenciadas do Amazon ECS é determinado pelo *modo de rede* especificado na definição da tarefa. Especifique um modo de rede na definição da tarefa. Você não poderá executar tarefas nas instâncias gerenciadas do Amazon ECS usando uma definição de tarefa que não especifique um modo de rede. As instâncias gerenciadas do Amazon ECS oferecem suporte aos seguintes modos de rede, garantindo compatibilidade com versões anteriores para migrar workloads do Fargate ou do Amazon ECS no Amazon EC2:


| Modo de rede | Descrição | 
| --- | --- | 
|  `awsvpc`  |  Cada tarefa recebe sua própria interface de rede elástica (ENI) e endereço IPv4 privado. Isso fornece as mesmas propriedades de rede que as instâncias do Amazon EC2 e é compatível com as tarefas tradicionais do Fargate. Usa entroncamento ENI para alta densidade de tarefas.  | 
|  `host`  |  As tarefas compartilham diretamente o namespace de rede do host. A rede de contêineres está vinculada à instância host subjacente.  | 

## Usar uma VPC no modo somente IPv6
<a name="managed-instances-networking-ipv6-only"></a>

Em uma configuração somente IPv6, suas tarefas do Amazon ECS se comunicam exclusivamente via IPv6. Para configurar VPCs e sub-redes para uma configuração somente IPv6, adicione um bloco CIDR IPv6 à VPC e crie sub-redes que incluam apenas um bloco CIDR IPv6. Para obter mais informações, consulte [Adicionar suporte IPv6 para sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6-add.html) e [Criar uma sub-rede](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html) no *Guia do usuário da Amazon VPC*. Atualize também as tabelas de rotas com destinos IPv6 e configure grupos de segurança com regras IPv6. Para obter mais informações, consulte [Configurar tabelas de rotas](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) e [Configurar regras de grupo de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) no *Guia do usuário da Amazon VPC*.

As seguintes considerações se aplicam:
+ Você pode atualizar um serviço somente IPv4 ou de pilha dupla do Amazon ECS para uma configuração somente IPv6 atualizando o serviço diretamente para usar sub-redes somente IPv6 ou criando um serviço somente IPv6 paralelo e usando implantações azul-verde do Amazon ECS para transferir o tráfego para o novo serviço. Para obter mais informações sobre implantações azul/verde do Amazon ECS, consulte [Implantações azuis/verdes do Amazon ECS](deployment-type-blue-green.md).
+ Um serviço somente IPv6 do Amazon ECS deve usar balanceadores de carga de pilha dupla com grupos-de destino IPv6. Se você estiver migrando um serviço do Amazon ECS existente que está por trás de um Application Load Balancer ou de um Network Load Balancer, será possível criar um novo balanceador de carga de pilha dupla e transferir o tráfego do balanceador de carga antigo ou atualizar o tipo de endereço IP do balanceador de carga existente.

   Para obter mais informações sobre Network Load Balancers consulte [Criar um Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html) e [Atualizar os tipos de endereço IP do seu Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-ip-address-type.html) no *Guia do usuário para Network Load Balancers*. Para obter mais informações sobre Application Load Balancers, consulte [Criar um Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) e [Atualizar os tipos de endereço IP do seu Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-ip-address-type.html) no *Guia do usuário para Application Load Balancers*.
+ Para tarefas do Amazon ECS em uma configuração somente IPv6 para se comunicar com endpoints somente IPv4, você pode configurar DNS64 e NAT64 para converter endereços de rede de IPv6 para IPv4. Para obter mais informações, consulte [DNS64 e NAT64](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-nat64-dns64.html), no *Guia do usuário da Amazon VPC*.
+ As workloads do Amazon ECS em uma configuração somente IPv6 devem usar endpoints de URI de imagem de pilha dupla do Amazon ECR ao extrair imagens do Amazon ECR. Para obter mais informações, consulte [Como começar a fazer solicitações via IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) no *Guia do usuário do Amazon Elastic Container Registry*.
**nota**  
O Amazon ECR não oferece suporte a endpoints da VPC de interface de pilha dupla que as tarefas de uma configuração somente IPv6 possam usar. Para obter mais informações, consulte [Como começar a fazer solicitações via IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) no *Guia do usuário do Amazon Elastic Container Registry*.
+ Não há suporte para o Amazon ECS Exec em uma configuração somente IPv6.

# Alocar uma interface de rede para tarefas nas instâncias gerenciadas do Amazon ECS
<a name="managed-instances-awsvpc-mode"></a>

 O uso do modo de rede `awsvpc` nas instâncias gerenciadas do Amazon ECS simplifica a rede de contêineres porque você tem mais controle sobre como as aplicações se comunicam entre si e com outros serviços dentro das VPCs. O modo de rede `awsvpc` também fornece maior segurança para os contêineres, permitindo que você use grupos de segurança e ferramentas de monitoramento de rede em um nível mais granular dentro das tarefas.

Por padrão, cada instância gerenciada do Amazon ECS tem uma interface de rede elástica (ENI) de tronco conectada durante a inicialização como ENI primária quando o tipo de instância aceita entroncamento. Para obter mais informações sobre tipos de instância que oferecem suporte ao entroncamento ENI, consulte [Instâncias compatíveis para aumentar as interfaces de rede de contêineres do Amazon ECS.](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/eni-trunking-supported-instance-types.html)

**nota**  
Quando o tipo de instância escolhido não for compatível com ENIs de tronco, a instância será inicializada com uma ENI normal.

Cada tarefa executada na instância recebe sua própria ENI anexada à ENI do tronco, com um endereço IP privado primário. Se a VPC estiver configurada para o modo de pilha dupla e você usar uma sub-rede com um bloco CIDR IPv6, a ENI também receberá um endereço IPv6. Ao usar uma sub-rede pública, você tem a opção de atribuir um endereço IP público à ENI primária da instância gerenciada do Amazon ECS habilitando o endereçamento público IPv4 para a sub-rede. Para obter mais informações, consulte [Modificar os atributos de endereçamento IP da sua sub-rede](https://docs.aws.amazon.com//vpc/latest/userguide/subnet-public-ip.html) no *Guia do usuário da Amazon VPC*. Uma tarefa só pode ter uma ENI associada a ela de cada vez. 

 Os contêineres que pertencem à mesma tarefa também podem se comunicar por meio da interface `localhost`. Para obter mais informações sobre VPCs e sub-redes, consulte [Como a Amazon VPC funciona](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html) no *Guia do usuário da Amazon VPC*

As seguintes operações usam a ENI primária anexada à instância:
+ **Downloads de imagens**: as imagens de contêiner são baixadas do Amazon ECR por meio da ENI principal.
+ **Recuperação de segredos**: os segredos e outras credenciais do Secrets Manager são recuperados por meio da ENI primária.
+ **Uploads de logs**: os logs são enviados por upload para o CloudWatch por meio da ENI primária.
+ **Downloads de arquivos de ambiente**: os arquivos de ambiente são baixados por meio da ENI principal.

O tráfego da aplicação flui pela ENI da tarefa.

Como cada tarefa tem sua própria ENI, você pode usar recursos de rede, como os logs de fluxo de VPC, que podem ser usados para monitorar o tráfego de e para suas tarefas. Para obter mais informações, consulte [Logs de fluxo da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) no *Guia do usuário do Amazon Virtual Private Cloud*.

Você também pode utilizar AWS PrivateLink. É possível configurar um endpoint de interface VPC para que você possa acessar APIs do Amazon ECS por meio de endereços IP privados. AWS PrivateLink restringe todo o tráfego de rede entre sua VPC e o Amazon ECS para a rede da Amazon. Você não precisa de um gateway da Internet, de um dispositivo NAT ou de um gateway privado virtual. Para obter mais informações, consulte [Endpoints da VPC da interface do Amazon ECS (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html).

O modo de rede `awsvpc` também permite que você utilize o Amazon VPC Traffic Mirroring para segurança e monitoramento do tráfego de rede ao usar tipos de instância que não têm ENIs de tronco anexadas. Para obter mais informações, consulte [O que é Traffic Mirroring](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html) no *Guia do Amazon VPC Traffic Mirroring*.

## Considerações sobre o modo `awsvpc`
<a name="managed-instances-awsvpc-considerations"></a>
+ As tarefas exigem o perfil vinculado ao serviço do Amazon ECS para o gerenciamento da ENI. Esse perfil é criado automaticamente quando você cria um cluster ou um serviço.
+ As ENIs de tarefas são gerenciados pelo Amazon ECS e não podem ser desanexados ou modificados manualmente.
+ A atribuição de um endereço IP público à ENI de tarefa usando `assignPublicIp` ao executar uma tarefa autônoma (`RunTask`), criar ou atualizar um serviço (`CreateService`/`UpdateService`) não é compatível.
+ Quando você configurar a rede `awsvpc` no nível da tarefa, use a mesma VPC especificada como parte do modelo de inicialização do provedor de capacidade de instâncias gerenciadas do Amazon ECS. Você pode usar sub-redes e grupos de segurança diferentes dos especificados no modelo de inicialização.
+ Para tarefas no modo de rede `awsvpc`, use o tipo de destino `ip` ao configurar grupos de destino do balanceador de carga. O Amazon ECS gerencia automaticamente o registro do grupo de destino para os modos de rede compatíveis.

## Usar uma VPC no modo de pilha dupla
<a name="managed-instance-networking-vpc-dual-stack"></a>

Ao usar uma VPC no modo de pilha dupla, as tarefas podem se comunicar por IPv4, IPv6 ou ambos. Os endereços IPv4 e IPv6 são independentes um do outro. Portanto, é preciso configurar o encaminhamento e a segurança na VPC separadamente para IPv4 e IPv6. Para obter mais informações sobre como configurar a VPC para o modo de pilha dupla, consulte [Migrar para IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) no *Guia do usuário da Amazon VPC*.

Se tiver configurado sua VPC com um gateway da Internet ou um gateway da Internet somente saída, será possível utilizar sua VPC no modo de pilha dupla. Fazendo isso, as tarefas que obtêm um endereço IPv6 podem acessar a Internet por meio de um gateway da Internet ou um gateway da Internet somente saída. Gateways NAT são opcionais. Para obter mais informações, consulte [Gateways da Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) e [Gateways da Internet](https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html) somente de saída no *Guia do usuário da Amazon VPC*.

As tarefas do Amazon ECS receberão um endereço IPv6 se as seguintes condições forem atendidas:
+ A instância gerenciada do Amazon ECS que hospeda a tarefa está usando a versão `1.45.0` ou posterior do agente de contêiner. Para obter informações sobre como verificar a versão do agente que a instância está usando e atualizá-la, se necessário, consulte [Atualizar o agente de contêiner do Amazon ECS](ecs-agent-update.md).
+ A configuração `dualStackIPv6` da conta está habilitada. Para obter mais informações, consulte [Acesso aos recursos do Amazon ECS com as configurações de conta](ecs-account-settings.md).
+ Sua tarefa está usando o modo de rede `awsvpc`.
+ Sua VPC e sua sub-rede estão configuradas para IPv6. A configuração inclui as interfaces de rede criadas na sub-rede especificada. Para obter mais informações sobre como configurar a VPC para o modo de pilha dupla, consulte [Migrar para IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) e [Modificar o atributo de endereçamento IPv6 para a sub-rede](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-ipv6) no *Guia do usuário da Amazon VPC*.

# Modo de rede do host
<a name="managed-instances-host-modes"></a>

No modo `host`, as tarefas compartilham diretamente o namespace de rede do host. A configuração de rede do contêiner está vinculada à instância host subjacente das instâncias gerenciadas do Amazon ECS que você especifica usando o parâmetro `networkConfiguration` ao criar um provedor de capacidade de instâncias gerenciadas do Amazon ECS.``

Existem desvantagens significativas em usar esse modo de rede. Você não pode executar mais do que uma única instanciação de uma tarefa em cada host. Isso ocorre porque somente a primeira tarefa pode ser vinculada à porta necessária na instância do Amazon EC2. Também não há como remapear uma porta de contêiner quando ela estiver usando o modo de rede `host`. Por exemplo, se uma aplicação precisar escutar um determinado número de porta, você não poderá remapear o número da porta diretamente. Em vez disso, você deverá gerenciar quaisquer conflitos de portas alterando a configuração da aplicação.

Também há implicações de segurança com o uso do modo de rede `host`. Esse modo permite que os contêineres representem o host e permite que os contêineres se conectem a serviços de rede de loopback privados no host.

Use o modo host somente quando precisar de acesso direto à rede do host ou ao migrar aplicações que exijam acesso de rede do host.

# Opções da rede de tarefas do Amazon ECS para o EC2
<a name="task-networking"></a>

O comportamento de rede das tarefas do Amazon ECS hospedadas em instâncias do Amazon EC2 depende do *modo de rede* especificado na definição de tarefa. Recomendamos que você use o modo de rede `awsvpc`, a menos que tenha uma necessidade específica de usar um modo de rede diferente.

Veja a seguir os modos de rede disponíveis.


| Modo de rede | Contêineres do Linux no EC2 | Contêineres do Windows no EC2 | Descrição | 
| --- | --- | --- | --- | 
|  `awsvpc`  |  Sim  |  Sim  |  A tarefa recebe sua própria interface de rede elástica (ENI) e um endereço IPv4 ou IPv6 privado primário. Isso dá à tarefa as mesmas propriedades de rede que as instâncias do Amazon EC2.  | 
|  `bridge`  |  Sim  |  Não  |  A tarefa usa a rede virtual integrada do Docker no Linux, que é executada em cada instância do Amazon EC2 que hospeda a tarefa. A rede virtual integrada no Linux usa o driver de rede `bridge` do Docker. Esse é o modo de rede padrão no Linux quando um modo de rede não é especificado na definição de tarefa.  | 
|  `host`  |  Sim  |  Não  |  A tarefa usa a rede do host que ignora a rede virtual integrada do Docker mapeando as portas do contêiner diretamente para a ENI da instância do Amazon EC2 que hospeda a tarefa. Os mapeamentos dinâmicos de portas não podem ser usados nesse modo de rede. Um contêiner em uma definição de tarefa que use esse modo deve especificar um número de `hostPort` específico. Um número de porta em um host não pode ser usado por várias tarefas. Como resultado, não é possível executar várias tarefas da mesma definição de tarefa em uma única instância do Amazon EC2.  | 
|  `none`  |  Sim  |  Não  |  A tarefa não tem conectividade com rede externa.  | 
|  `default`  |  Não  |  Sim  |  A tarefa usa a rede virtual integrada do Docker no Windows, que é executada em cada instância do Amazon EC2 que hospeda a tarefa. A rede virtual integrada no Windows usa o driver de rede `nat` do Docker. Esse é o modo de rede padrão no Windows quando um modo de rede não é especificado na definição de tarefa.  | 

Para obter mais informações sobre as redes do Docker no Linux, consulte [Networking overview](https://docs.docker.com/engine/network/) na *documentação do Docker*.

Para obter mais informações sobre as redes do Docker no Windows, consulte [Windows container networking](https://learn.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture) na *documentação sobre containers no Windows* da Microsoft.

## Usar uma VPC no modo somente IPv6
<a name="networking-ipv6-only"></a>

Em uma configuração somente IPv6, suas tarefas do Amazon ECS se comunicam exclusivamente via IPv6. Para configurar VPCs e sub-redes para uma configuração somente IPv6, adicione um bloco CIDR IPv6 à VPC e crie novas sub-redes que incluam somente um bloco CIDR IPv6. Para obter mais informações, consulte [Adicionar suporte IPv6 para sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6-add.html) e [Criar uma sub-rede](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html) no *Guia do usuário da Amazon VPC*.

Atualize também as tabelas de rotas com destinos IPv6 e configure grupos de segurança com regras IPv6. Para obter mais informações, consulte [Configurar tabelas de rotas](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) e [Configurar regras de grupo de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) no *Guia do usuário da Amazon VPC*.

As seguintes considerações se aplicam:
+ Você pode atualizar um serviço somente IPv4 ou de pilha dupla do Amazon ECS para uma configuração somente IPv6 atualizando o serviço diretamente para usar sub-redes somente IPv6 ou criando um serviço somente IPv6 paralelo e usando implantações azul-verde do Amazon ECS para transferir o tráfego para o novo serviço. Para obter mais informações sobre implantações azul/verde do Amazon ECS, consulte [Implantações azuis/verdes do Amazon ECS](deployment-type-blue-green.md).
+ Um serviço somente IPv6 do Amazon ECS deve usar balanceadores de carga de pilha dupla com grupos-de destino IPv6. Se você estiver migrando um serviço do Amazon ECS existente que está por trás de um Application Load Balancer ou de um Network Load Balancer, será possível criar um novo balanceador de carga de pilha dupla e transferir o tráfego do balanceador de carga antigo ou atualizar o tipo de endereço IP do balanceador de carga existente.

  Para obter mais informações sobre Network Load Balancers consulte [Criar um Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html) e [Atualizar os tipos de endereço IP do seu Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-ip-address-type.html) no *Guia do usuário para Network Load Balancers*. Para obter mais informações sobre Application Load Balancers, consulte [Criar um Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) e [Atualizar os tipos de endereço IP do seu Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-ip-address-type.html) no *Guia do usuário para Application Load Balancers*.
+ Não há suporte para a configuração somente IPv6 no Windows. Use as AMIs do Linux otimizadas para o Amazon ECS para executar tarefas em uma configuração somente IPv6. Para obter mais informações sobre as AMIs do Linux otimizadas para o Amazon ECS, consulte [AMIs do Linux otimizadas para o Amazon ECS](ecs-optimized_AMI.md).
+ Ao iniciar uma instância de contêiner para executar tarefas em uma configuração somente IPv6, você deve definir um endereço IPv6 primário para a instância usando o parâmetro `--enable-primary-ipv6` do EC2.
**nota**  
Sem um endereço IPv6 primário, as tarefas executadas na instância de contêiner nos modos de rede host ou ponte não serão registradas nos balanceadores de carga ou no AWS Cloud Map.

  Para obter mais informações sobre `--enable-primary-ipv6` para executar instâncias do Amazon EC2, consulte [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) na *Referência de comandos da AWS CLI*.

  Para obter mais informações sobre como inicializar instâncias de contêiner usando o Console de gerenciamento da AWS, consulte [Iniciar uma instância de contêiner do Linux do Amazon ECS](launch_container_instance.md).
+ Por padrão, o agente de contêiner do Amazon ECS tentará detectar a compatibilidade da instância de contêiner com uma configuração somente IPv6 examinando as rotas IPv4 e IPv6 padrão da instância. Para substituir esse comportamento, você pode definir o parâmetro ` ECS_INSTANCE_IP_COMPATIBILITY` como `ipv4` ou `ipv6` no arquivo `/etc/ecs/ecs.config` da instância.
+ As tarefas devem usar a versão `1.99.1` ou posterior do agente de contêiner. Para obter informações sobre como verificar a versão do agente que a instância está usando e atualizá-la, se necessário, consulte [Atualizar o agente de contêiner do Amazon ECS](ecs-agent-update.md).
+ Para tarefas do Amazon ECS em uma configuração somente IPv6 para se comunicar com endpoints somente IPv4, você pode configurar DNS64 e NAT64 para converter endereços de rede de IPv6 para IPv4. Para obter mais informações, consulte [DNS64 e NAT64](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-nat64-dns64.html), no *Guia do usuário da Amazon VPC*.
+ As workloads do Amazon ECS em uma configuração somente IPv6 devem usar endpoints de URI de imagem de pilha dupla do Amazon ECR ao extrair imagens do Amazon ECR. Para obter mais informações, consulte [Como começar a fazer solicitações via IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) no *Guia do usuário do Amazon Elastic Container Registry*.
**nota**  
O Amazon ECR não oferece suporte a endpoints da VPC de interface de pilha dupla que as tarefas de uma configuração somente IPv6 possam usar. Para obter mais informações, consulte [Como começar a fazer solicitações via IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) no *Guia do usuário do Amazon Elastic Container Registry*.
+ Não há suporte para o Amazon ECS Exec em uma configuração somente IPv6.

### Regiões da AWS que são compatíveis com o modo somente IPv6 no Amazon ECS
<a name="networking-ipv6-only-regions"></a>

Você pode executar tarefas em uma configuração somente IPv6 nas seguintes regiões da AWS em que o Amazon ECS está disponível:
+ Leste dos EUA (Ohio)
+ Leste dos EUA (Norte da Virgínia)
+ Oeste dos EUA (N. da Califórnia)
+ Oeste dos EUA (Oregon)
+ África (Cidade do Cabo)
+ Ásia-Pacífico (Hong Kong)
+ Ásia-Pacífico (Hyderabad)
+ Ásia-Pacífico (Jacarta)
+ Ásia-Pacífico (Melbourne)
+ Ásia-Pacífico (Mumbai)
+ Ásia-Pacífico (Osaka)
+ Ásia-Pacífico (Seul)
+ Ásia-Pacífico (Singapura)
+ Ásia-Pacífico (Sydney)
+ Ásia-Pacífico (Tóquio)
+ Canadá (Central)
+ Oeste do Canadá (Calgary)
+ China (Pequim)
+ China (Ningxia)
+ Europa (Frankfurt)
+ Europa (Londres)
+ Europa (Milão)
+ Europe (Paris)
+ Europa (Espanha)
+ Israel (Tel Aviv)
+ Oriente Médio (Bahrein)
+ Oriente Médio (Emirados Árabes Unidos)
+ América do Sul (São Paulo)
+ AWS GovCloud (Leste dos EUA)
+ AWS GovCloud (Oeste dos EUA)

# Alocar uma interface de rede para uma tarefa do Amazon ECS
<a name="task-networking-awsvpc"></a>

Os recursos de redes de tarefas fornecidos pelo modo de rede `awsvpc` dão às tarefas do Amazon ECS as mesmas propriedades de redes que as instâncias do Amazon EC2. Usar o modo de rede `awsvpc` simplifica a rede de contêineres. Você tem mais controle sobre como as aplicações se comunicam entre si e com outros serviços dentro das VPCs. O modo de rede `awsvpc` também fornece maior segurança para os contêineres, permitindo que você use grupos de segurança e ferramentas de monitoramento de rede em um nível mais granular dentro das tarefas. Você também pode usar outros recursos de rede do Amazon EC2, como o VPC Flow Logs, para monitorar o tráfego que entra e sai das tarefas. Além disso, os contêineres que pertencem à mesma tarefa podem se comunicar por meio da interface `localhost`.

A interface de rede elástica (ENI) da tarefa é um recurso totalmente gerenciado do Amazon ECS. O Amazon ECS cria a ENI e a anexa à instância host do Amazon EC2 host com o grupo de segurança especificado. A tarefa envia e recebe tráfego de rede na ENI da mesma maneira que as instâncias do Amazon EC2 fazem com suas interfaces de rede primárias. A cada ENI de tarefa é atribuído um endereço IPv4 privado, por padrão. Se a VPC estiver habilitada para o modo de pilha dupla e você usar uma sub-rede com um bloco CIDR IPv6, a ENI da tarefa também receberá um endereço IPv6. Cada tarefa pode ter apenas uma ENI. 

Essas ENIs ficam visíveis no console do Amazon EC2 para sua conta. Sua conta não pode desanexar ou modificar as ENIs. Isso visa a evitar a exclusão acidental de uma ENI associada a uma tarefa em execução. É possível visualizar as informações do anexo da ENI para tarefas no console do Amazon ECS ou com a operação da API [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html). Quando a tarefa for interrompida ou se o serviço sofrer redução de escala vertical, a ENI da tarefa será desvinculada e excluída.

Quando precisar aumentar a densidade da ENI, use a configuração de conta `awsvpcTrunking`. O Amazon ECS também cria e anexa uma interface de rede “tronco” para a instância de contêiner. A rede tronco é totalmente gerenciada pelo Amazon ECS. A ENI do tronco é excluída quando você encerra ou cancela o registro da instância de contêiner do cluster do Amazon ECS. Para obter mais informações sobre a configuração de conta de `awsvpcTrunking`, consulte [Pré-requisitos](container-instance-eni.md#eni-trunking-launching).

Você especifica `awsvpc` no parâmetro `networkMode` da definição de tarefa. Para obter mais informações, consulte [Modo de rede](task_definition_parameters.md#network_mode). 

Depois, ao executar uma tarefa ou criar um serviço, use o parâmetro `networkConfiguration` que inclui uma ou mais sub-redes para colocar as tarefas e um ou mais grupos de segurança para anexar a uma ENI. Para obter mais informações, consulte [Configuração de rede](service_definition_parameters.md#sd-networkconfiguration). As tarefas são posicionadas em instâncias do Amazon EC2 nas mesmas zonas de disponibilidade que as dessas sub-redes e os grupos de segurança especificados são associados à ENI provisionada para a tarefa.

## Considerações sobre o Linux
<a name="linux"></a>

 Considere o seguinte ao utilizar o sistema operacional Linux.
+ Se você usar uma instância p5.48xlarge no modo `awsvpc`, não será possível executar mais de uma tarefa na instância.
+ As tarefas e os serviços que usam o modo de rede `awsvpc` exigem que a função vinculada ao serviço do Amazon ECS forneça ao Amazon ECS as permissões para fazer chamadas a outros serviços da AWS em seu nome. Essa função será automaticamente criada quando você criar um cluster ou se criar ou atualizar um serviço no Console de gerenciamento da AWS. Para obter mais informações, consulte [Uso de perfis vinculados ao serviço para o Amazon ECS](using-service-linked-roles.md). Você também pode criar a função vinculada ao serviço com o seguinte comando da AWS CLI:

  ```
  aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name ecs.amazonaws.com
  ```
+ A instância do Linux do Amazon EC2 requer a versão `1.15.0` ou posterior do agente de contêiner para executar tarefas que usam o modo de rede `awsvpc`. Se você estiver usando a AMI do Linux otimizada para o Amazon ECS, sua instância também precisará, pelo menos, da versão `1.15.0-4` do pacote `ecs-init`.
+ O Amazon ECS preenche o nome de host da tarefa usando a rede de tarefas com um nome de host DNS (interno) fornecido pela Amazon quando as opções `enableDnsHostnames` e `enableDnsSupport` estão habilitadas na sua VPC. Se essas opções não estiverem habilitadas, o nome de host DNS da tarefa será definido como um nome de host aleatório. Para obter mais informações sobre as configurações de DNS para uma VPC, consulte [Usar DNS com sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) no *Guia do usuário da Amazon VPC*.
+ Cada tarefa do Amazon ECS que usa o modo de rede `awsvpc` recebe sua própria interface de rede elástica (ENI), que está anexada à instância do Amazon EC2 que a hospeda. Existe uma cota padrão para o número de interfaces de rede que é possível anexar a uma instância Linux do Amazon EC2. A interface de rede primária conta para essa cota. Por exemplo, por padrão, uma instância `c5.large` só pode ter até três ENIs associadas a ela. A interface de rede primária da instância conta como uma. É possível associar mais duas ENIs à instância. Como cada tarefa que usa o modo de rede `awsvpc` exige uma ENI, em geral, você pode executar somente duas dessas tarefas nesse tipo de instância. Para obter mais informações sobre os limites de ENI padrão para cada tipo de instância, consulte [Endereços IP por interface de rede por tipo de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI) no *Guia do usuário do Amazon EC2*.
+ O Amazon ECS oferece suporte ao lançamento de instâncias do Linux do Amazon EC2 usando tipos de instâncias compatíveis, com maior densidade de ENI. Quando você aceitar a configuração de conta `awsvpcTrunking` e registrar instâncias do Linux do Amazon EC2 usando esses tipos de instância no seu cluster, estas instâncias terão cotas de ENI mais altas. Utilizar essas instâncias com a cota mais alta significa que é possível colocar mais tarefas em cada instância Linux do Amazon EC2. Para usar a maior densidade de ENI com o recurso de entroncamento, sua instância do Amazon EC2 deve usar a versão `1.28.1` ou posterior do agente de contêiner. Se você estiver usando a AMI otimizada para o Amazon ECS, sua instância precisará, pelo menos, da versão `1.28.1-2` do pacote `ecs-init`. Para obter mais informações sobre como optar pela configuração de conta `awsvpcTrunking`, consulte [Acesso aos recursos do Amazon ECS com as configurações de conta](ecs-account-settings.md). Para obter mais informações sobre o entroncamento de ENI, consulte [Aumento das interfaces de rede de instâncias de contêiner do Linux no Amazon ECS](container-instance-eni.md).
+ Ao hospedar tarefas que usam o modo de rede `awsvpc` em instâncias do Linux do Amazon EC2, suas ENIs de tarefa não recebem endereços IP públicos. Para acessar a Internet, as tarefas devem ser executadas em uma sub-rede privada configurada para usar um gateway NAT. Para obter mais informações, consulte [Gateways NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) no *Guia do usuário da Amazon VPC*. O acesso à rede de entrada deve ocorrer de dentro da VPC que usa o endereço IP privado ou roteado por um balanceador de carga de dentro da VPC. As tarefas inicializadas em sub-redes públicas não têm acesso à Internet.
+ O Amazon ECS reconhece somente as ENIs que ele anexa às suas instâncias Linux do Amazon EC2. Se você tiver anexado ENIs manualmente às suas instâncias, o Amazon ECS poderá tentar adicionar uma tarefa a uma instância que não tenha adaptadores de rede suficientes. Isso pode fazer com que a tarefa atinja o tempo limite, passe para um status em desprovisionamento e, em seguida, para um status de interrompida. Recomendamos que você não anexe ENIs às suas instâncias manualmente.
+ As instâncias do Linux do Amazon EC2 devem ser registradas com o recurso `ecs.capability.task-eni` para serem consideradas para posicionamento de tarefas com o modo de rede `awsvpc`. As instâncias que executam a versão `1.15.0-4` ou posterior do `ecs-init` são automaticamente registradas com esse atributo.
+ As ENIs criadas e anexadas às suas instâncias do Linux do Amazon EC2 não podem ser desvinculadas manualmente nem modificadas pela sua conta. Isso visa a evitar a exclusão acidental de uma ENI associada a uma tarefa em execução. Para liberar as ENIs para uma tarefa, interrompa-a.
+ Há um limite de 16 sub-redes e 5 grupos de segurança que podem ser especificados na `awsVpcConfiguration` ao executar uma tarefa ou ao criar um serviço que usa o modo de rede `awsvpc`. Para obter mais informações, consulte [AwsVpcConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AwsVpcConfiguration.html) na *Referência da API de serviço do contêiner do Amazon Elastic Container Service*.
+ Quando uma tarefa é iniciada com o modo de rede `awsvpc`, o agente de contêiner do Amazon ECS cria um contêiner `pause` adicional para cada tarefa antes de iniciar os contêineres na definição de tarefa. Em seguida, ele configura o namespace de rede do contêiner `pause` ao executar os plug-ins do CNI [amazon-ecs-cni-plugins](https://github.com/aws/amazon-ecs-cni-plugins). O agente inicia então o restante dos contêineres na tarefa para que eles compartilhem a pilha de rede do contêiner `pause`. Isso significa que todos os contêineres em uma tarefa são endereçáveis por endereços IP da ENI, e que eles podem se comunicar entre eles por meio da interface `localhost`.
+ Serviços com tarefas que usam o modo de rede `awsvpc` oferecem suporte somente a Application Load Balancers e Network Load Balancers. Ao criar grupos de destino para esses serviços, você precisa escolher `ip` como o tipo de destino. Não use `instance`. Isso ocorre porque as tarefas que usam o modo de rede `awsvpc` são associadas a uma ENI, não a uma instância do Linux 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).
+ Se a sua VPC for atualizada para alterar o conjunto de opções de DHCP que ela utiliza, não será possível aplicar essas alterações às tarefas existentes. Inicie novas tarefas com essas alterações aplicadas, verifique se elas estão funcionando corretamente e, em seguida, interrompa tarefas existentes para modificar essas configurações de rede com segurança.

## Considerações sobre Windows
<a name="windows"></a>

 Veja a seguir considerações quando for usado o sistema operacional Windos.
+ Instâncias de contêiner que usam a AMI do Windows Server 2016 otimizada para o Amazon ECS não podem hospedar tarefas que usam o modo de rede `awsvpc`. Se você tiver um cluster que contém AMIs do Windows Server 2016 otimizadas para o Amazon ECS e AMIs do Windows compatíveis com o modo de rede `awsvpc`, tarefas que usam o modo de rede `awsvpc` não serão iniciadas nas instâncias do Windows Server 2016. Em vez disso, elas são iniciadas em instâncias com suporte para o modo de rede `awsvpc`.
+ Sua instância do Windows do Amazon EC2 requer a versão `1.57.1` ou posterior do agente de contêiner para usar métricas do CloudWatch para contêineres do Windows que usem o modo de rede `awsvpc`.
+ As tarefas e os serviços que usam o modo de rede `awsvpc` exigem que a função vinculada ao serviço do Amazon ECS forneça ao Amazon ECS as permissões para fazer chamadas a outros serviços da AWS em seu nome. Essa função será criada automaticamente quando você criar um cluster ou se criar ou atualizar um serviço no Console de gerenciamento da AWS. Para obter mais informações, consulte [Uso de perfis vinculados ao serviço para o Amazon ECS](using-service-linked-roles.md). Também é possível criar a função vinculada ao serviço com o comando da AWS CLI a seguir.

  ```
  aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name ecs.amazonaws.com
  ```
+ Sua instância do Windows do Amazon EC2 requer a versão `1.54.0` ou posterior do agente de contêiner para executar tarefas que usam o modo de rede `awsvpc`. Ao inicializar a instância, você deve configurar as opções necessárias para o modo de rede `awsvpc`. Para obter mais informações, consulte [Inicialização de instâncias de contêiner do Windows no Amazon ECS para transmitir dados](bootstrap_windows_container_instance.md).
+ O Amazon ECS preenche o nome de host da tarefa usando a rede de tarefas com um nome de host DNS (interno) fornecido pela Amazon quando as opções `enableDnsHostnames` e `enableDnsSupport` estão habilitadas na sua VPC. Se essas opções não estiverem habilitadas, o nome de host DNS da tarefa será um nome de host aleatório. Para obter mais informações sobre as configurações de DNS para uma VPC, consulte [Usar DNS com sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) no *Guia do usuário da Amazon VPC*.
+ Cada tarefa do Amazon ECS que usa o modo de rede `awsvpc` recebe sua própria interface de rede elástica (ENI), que está anexada à instância do Windows do Amazon EC2 que a hospeda. Existe uma cota padrão para o número de interfaces de rede que é possível anexar a uma instância Windows do Amazon EC2. A interface de rede primária conta para essa cota. Por exemplo, por padrão, uma instância `c5.large` só pode ter até três ENIs associadas a ela. A interface de rede primária da instância conta como uma delas. É possível associar mais duas ENIs à instância. Como cada tarefa que usa o modo de rede `awsvpc` exige uma ENI, em geral, você pode executar somente duas dessas tarefas nesse tipo de instância. Para obter mais informações sobre os limites de ENI padrão para cada tipo de instância, consulte [Endereços IP por interface de rede por tipo de instância](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-eni.html#AvailableIpPerENI) no *Guia do usuário do Amazon EC2*.
+ Ao hospedar tarefas que usam o modo de rede `awsvpc` em instâncias do Windows do Amazon EC2, suas ENIs de tarefa não recebem endereços IP públicos. Para acessar a Internet, inicie tarefas em uma sub-rede privada configurada para usar um gateway NAT. Para obter mais informações, consulte [Gateways NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) no *Guia do usuário da Amazon VPC*. O acesso à rede de entrada deve ocorrer de dentro da VPC usando o endereço IP privado ou roteado por um load balancer de dentro da VPC. As tarefas inicializadas em sub-redes públicas não têm acesso à Internet.
+ O Amazon ECS reconhece somente as ENIs que ele anexa às suas instâncias Windows do Amazon EC2. Se você tiver anexado ENIs manualmente às suas instâncias, o Amazon ECS poderá tentar adicionar uma tarefa a uma instância que não tenha adaptadores de rede suficientes. Isso pode fazer com que a tarefa atinja o tempo limite, passe para um status em desprovisionamento e, em seguida, para um status de interrompida. Recomendamos que você não anexe ENIs às suas instâncias manualmente.
+ As instâncias do Windows do Amazon EC2 devem ser registradas com o recurso `ecs.capability.task-eni` para serem consideradas para posicionamento de tarefas com o modo de rede `awsvpc`. 
+  É possível modificar ou desanexar manualmente as ENIs criadas e anexadas às suas instâncias do Windows do Amazon EC2. Isso evita que você exclua acidentalmente uma ENI associada a uma tarefa em execução. Para liberar as ENIs para uma tarefa, interrompa-a.
+  É possível especificar até 16 sub-redes e 5 grupos de segurança em `awsVpcConfiguration` ao executar uma tarefa ou criar um serviço que usa o modo de rede `awsvpc`. Para obter mais informações, consulte [AwsVpcConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AwsVpcConfiguration.html) na *Referência da API de serviço do contêiner do Amazon Elastic Container Service*.
+ Quando uma tarefa é iniciada com o modo de rede `awsvpc`, o agente de contêiner do Amazon ECS cria um contêiner `pause` adicional para cada tarefa antes de iniciar os contêineres na definição de tarefa. Em seguida, ele configura o namespace de rede do contêiner `pause` ao executar os plug-ins do CNI [amazon-ecs-cni-plugins](https://github.com/aws/amazon-ecs-cni-plugins). O agente inicia então o restante dos contêineres na tarefa para que eles compartilhem a pilha de rede do contêiner `pause`. Isso significa que todos os contêineres em uma tarefa são endereçáveis por endereços IP da ENI, e que eles podem se comunicar entre eles por meio da interface `localhost`.
+ Serviços com tarefas que usam o modo de rede `awsvpc` oferecem suporte somente a Application Load Balancers e Network Load Balancers. 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` são associadas a uma ENI, não a uma instância do Windows 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).
+ Se a sua VPC for atualizada para alterar o conjunto de opções de DHCP que ela utiliza, não será possível aplicar essas alterações às tarefas existentes. Inicie novas tarefas com essas alterações aplicadas, verifique se elas estão funcionando corretamente e, em seguida, interrompa tarefas existentes para modificar essas configurações de rede com segurança.
+ Não há suporte para os seguintes recursos quando você usa o modo de rede `awsvpc` em uma configuração de EC2 do Windows:
  + Configuração de pilha dupla
  + IPv6
  + Entroncamento ENI

## Usar uma VPC no modo de pilha dupla
<a name="task-networking-vpc-dual-stack"></a>

Ao usar uma VPC no modo de pilha dupla, as tarefas podem se comunicar por IPv4, IPv6 ou ambos. Os endereços IPv4 e IPv6 são independentes um do outro. Portanto, é preciso configurar o encaminhamento e a segurança na VPC separadamente para IPv4 e IPv6. Para obter mais informações sobre como configurar a VPC para o modo de pilha dupla, consulte [Migrar para IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) no *Guia do usuário da Amazon VPC*.

Se tiver configurado sua VPC com um gateway da Internet ou um gateway da Internet somente saída, será possível utilizar sua VPC no modo de pilha dupla. Fazendo isso, as tarefas que obtêm um endereço IPv6 podem acessar a Internet por meio de um gateway da Internet ou um gateway da Internet somente saída. Gateways NAT são opcionais. Para obter mais informações, consulte [Gateways da Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) e [Gateways da Internet](https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html) somente de saída no *Guia do usuário da Amazon VPC*.

As tarefas do Amazon ECS receberão um endereço IPv6 se as seguintes condições forem atendidas:
+ A instância Linux do Amazon EC2 que hospeda a tarefa está usando a versão `1.45.0` ou posterior do agente de contêiner. Para obter informações sobre como verificar a versão do agente que a instância está usando e atualizá-la, se necessário, consulte [Atualizar o agente de contêiner do Amazon ECS](ecs-agent-update.md).
+ A configuração `dualStackIPv6` da conta está habilitada. Para obter mais informações, consulte [Acesso aos recursos do Amazon ECS com as configurações de conta](ecs-account-settings.md).
+ Sua tarefa está usando o modo de rede `awsvpc`.
+ Sua VPC e sua sub-rede estão configuradas para IPv6. A configuração inclui as interfaces de rede criadas na sub-rede especificada. Para obter mais informações sobre como configurar a VPC para o modo de pilha dupla, consulte [Migrar para IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) e [Modificar o atributo de endereçamento IPv6 para a sub-rede](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-ipv6) no *Guia do usuário da Amazon VPC*.

# Mapeie as portas de contêiner do Amazon ECS para a interface de rede de instância do EC2
<a name="networking-networkmode-host"></a>

Só há suporte para o modo de rede `host` com tarefas do Amazon ECS hospedadas em instâncias do Amazon EC2. Não há suporte com o uso do Amazon ECS no Fargate.

O modo de rede `host` é o modo de rede mais básico com suporte no Amazon ECS. Com o uso do modo host, a rede do contêiner é vinculada diretamente ao host subjacente que está executando o contêiner.

![\[Diagrama que mostra a arquitetura de uma rede com contêineres usando o modo de rede host.\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/images/networkmode-host.png)


Suponha que você esteja executando um contêiner Node.js com uma aplicação Express que escuta em uma porta `3000` semelhante à ilustrada no diagrama anterior. Quando o modo de rede `host` é usado, o contêiner recebe tráfego na porta 3000 usando o endereço IP da instância de host subjacente do Amazon EC2. Não é recomendável usar esse modo.

Existem desvantagens significativas em usar esse modo de rede. Você não pode executar mais do que uma única instanciação de uma tarefa em cada host. Isso ocorre porque somente a primeira tarefa pode ser vinculada à porta necessária na instância do Amazon EC2. Também não há como remapear uma porta de contêiner quando ela estiver usando o modo de rede `host`. Por exemplo, se uma aplicação precisar escutar um determinado número de porta, você não poderá remapear o número da porta diretamente. Em vez disso, você deverá gerenciar quaisquer conflitos de portas alterando a configuração da aplicação.

Também há implicações de segurança com o uso do modo de rede `host`. Esse modo permite que os contêineres representem o host e permite que os contêineres se conectem a serviços de rede de loopback privados no host.

# Usar a rede virtual do Docker para tarefas do Linux no Amazon ECS
<a name="networking-networkmode-bridge"></a>

Só há suporte para o modo de rede `bridge` com tarefas do Amazon ECS hospedadas em instâncias do Amazon EC2.

Com o modo `bridge`, você está usando uma ponte de rede virtual para criar uma camada entre o host e a rede do contêiner. Dessa forma, é possível criar mapeamentos de portas que remapeiem uma porta de host para uma porta de contêiner. Os mapeamentos podem ser estáticos ou dinâmicos.

![\[Diagrama que mostra a arquitetura de uma rede usando o modo de rede bridge com mapeamento de portas estático.\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/images/networkmode-bridge.png)


Com um mapeamento estático de portas, é possível definir explicitamente qual porta de host deseja mapear para uma porta de contêiner. Usando o exemplo acima, a porta `80` do host está sendo mapeada para a porta `3000` do contêiner. Para se comunicar com a aplicação em contêiner, você envia tráfego para a porta `80` no endereço IP da instância do Amazon EC2. Do ponto de vista da aplicação em contêineres, ela vê esse tráfego de entrada na porta `3000`.

Se você quiser alterar apenas a porta de tráfego, os mapeamentos de portas estáticos são adequados. No entanto, isso ainda tem a mesma desvantagem de usar o modo de rede `host`. Você não pode executar mais do que uma única instanciação de uma tarefa em cada host. Isso ocorre porque um mapeamento estático de portas permite que apenas um único contêiner seja mapeado para a porta 80.

Para resolver esse problema, considere usar o modo de rede `bridge` com um mapeamento dinâmico de portas, conforme mostrado no diagrama a seguir.

![\[Diagrama que mostra a arquitetura de uma rede usando o modo de rede bridge com mapeamento de portas dinâmico.\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/images/networkmode-bridge-dynamic.png)


Ao não especificar uma porta host no mapeamento de portas, é possível fazer com que o Docker escolha uma porta aleatória e não usada do intervalo de portas temporárias e a atribua como porta host pública para o contêiner. Por exemplo, a aplicação Node.js receptora na porta `3000` do contêiner pode receber uma porta aleatória de número alto, como `47760`, no host do Amazon EC2. Isso significa que é possível executar várias cópias desse contêiner no host. Além disso, cada contêiner pode ter sua própria porta atribuída no host. Cada cópia do contêiner recebe tráfego na porta `3000`. Contudo, os clientes que enviam tráfego para esses contêineres usam as portas de host atribuídas aleatoriamente.

O Amazon ECS ajuda você a acompanhar as portas atribuídas aleatoriamente para cada tarefa. Isso é feito atualizando automaticamente os grupos-alvo do balanceador de carga e a descoberta de serviços do AWS Cloud Map para ter a lista de portas e endereços IP de tarefas. Isso facilita o uso de serviços em operação usando o modo `bridge` com portas dinâmicas.

No entanto, uma desvantagem de se usar o modo de rede `bridge` é que é difícil bloquear as comunicações entre serviços. Como os serviços podem ser atribuídos a qualquer porta aleatória e não usada, é necessário abrir amplos intervalos de portas entre os hosts. Contudo, não é fácil criar regras específicas para que um determinado serviço só possa se comunicar com outro serviço específico. Os serviços não têm portas específicas para usar nas regras de rede de grupos de segurança.

## Configurar o modo de rede ponte para workloads somente IPv6
<a name="networking-networkmode-bridge-ipv6-only"></a>

Para configurar o modo `bridge` para comunicação via IPv6, você deve atualizar as configurações do daemon do Docker. Atualize `/etc/docker/daemon.json` com o seguinte:

```
{
  "ipv6": true,
  "fixed-cidr-v6": "2001:db8:1::/64",
  "ip6tables": true,
  "experimental": true
}
```

Depois de atualizar as configurações do daemon do Docker, você precisará reiniciar o daemon.

**nota**  
Quando você atualiza e reinicia o daemon, o Docker ativa o encaminhamento IPv6 na instância, o que pode resultar na perda de rotas padrão nas instâncias que usam uma AMI do Amazon Linux 2. Para evitar isso, use o comando a seguir para adicionar uma rota padrão por meio do gateway IPv6 da sub-rede.  

```
ip route add default via FE80:EC2::1 dev eth0 metric 100
```

# Opções de redes de tarefas do Amazon ECS para o Fargate
<a name="fargate-task-networking"></a>

Por padrão, todas as tarefas do Amazon ECS no Fargate recebem uma interface de rede elástica (ENI) com um endereço IP privado primário. Ao usar uma sub-rede pública, você pode opcionalmente atribuir um endereço IP público à ENI da tarefa. Se a VPC estiver configurada para o modo de pilha dupla e você usar uma sub-rede com um bloco CIDR IPv6, a ENI da tarefa também receberá um endereço IPv6. Uma tarefa só pode ter uma ENI associada a ela de cada vez. Os contêineres que pertencem à mesma tarefa também podem se comunicar por meio da interface `localhost`. Para obter mais informações sobre VPCs e sub-redes, consulte [Como a Amazon VPC funciona](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html) no *Guia do usuário da Amazon VPC*.

Para que uma tarefa no Fargate possa extrair uma imagem de contêiner, a tarefa deve ter uma rota para a Internet. Veja a seguir como verificar se a sua tarefa tem uma rota para a Internet.
+ Quando você usa uma sub-rede pública, pode atribuir um endereço IP público à ENI da tarefa.
+ Ao usar uma sub-rede privada, a sub-rede pode ter um gateway NAT anexado.
+ Ao usar imagens de contêiner hospedadas no Amazon ECR, você pode configurar o Amazon ECR para usar um endpoint da VPC de interface e a extração da imagem ocorre no endereço IPv4 privado da tarefa. 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*.

Como cada tarefa tem sua própria ENI, você pode usar recursos de rede, como os logs de fluxo de VPC, que podem ser usados para monitorar o tráfego de e para suas tarefas. Para obter mais informações, consulte [Logs de fluxo da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) no *Guia do usuário do Amazon Virtual Private Cloud*.

Você também pode utilizar AWS PrivateLink. É possível configurar um endpoint de interface VPC para que você possa acessar APIs do Amazon ECS por meio de endereços IP privados. AWS PrivateLink restringe todo o tráfego de rede entre sua VPC e o Amazon ECS para a rede da Amazon. Você não precisa de um gateway da Internet, de um dispositivo NAT ou de um gateway privado virtual. Para obter mais informações, consulte [Endpoints da VPC da interface do Amazon ECS (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html).

Consulte exemplos de como usar o recurso `NetworkConfiguration` com o CloudFormation, consulte [Exemplos de modelos do CloudFormation para o Amazon ECS](working-with-templates.md).

As ENIs que são criadas são totalmente gerenciadas pelo AWS Fargate. Além disso, existe uma política do IAM associada que é utilizada para conceder permissões para o Fargate. Para tarefas que usam a versão `1.4.0` ou posterior da plataforma do Fargate, a tarefa recebe uma única ENI (conhecida como ENI de tarefa), e todo o tráfego de rede flui por essa ENI dentro da VPC. Esse tráfego é registrado nos seus logs de fluxo da VPC. Para tarefas que usam a versão `1.3.0` e anterior da plataforma, além da ENI de tarefa, a tarefa também recebe uma ENI de propriedade do Fargate separada, que é usada para algum tráfego de rede que não é visível nos logs de fluxo da VPC. A tabela a seguir descreve o comportamento do tráfego de rede e a política do IAM necessária para cada versão da plataforma.


|  Ação  |  Fluxo de tráfego com versão `1.3.0` e anterior da plataforma Linux  |  Fluxo de tráfego com versão da plataforma Linux `1.4.0`  |  Fluxo de tráfego com versão da plataforma Windows `1.0.0`  |  Permissão do IAM  | 
| --- | --- | --- | --- | --- | 
|  Recuperar credenciais de login do Amazon ECR  |  ENI de propriedade do Fargate  |  ENI de tarefa  |  ENI de tarefa  |  Função do IAM de execução de tarefas  | 
|  Extração de imagem  |  ENI de tarefa  |  ENI de tarefa  |  ENI de tarefa  |  Função do IAM de execução de tarefas  | 
|  Como enviar logs por meio de um driver de log  |  ENI de tarefa  |  ENI de tarefa  |  ENI de tarefa  |  Função do IAM de execução de tarefas  | 
|  Enviar logs pelo FireLens para Amazon ECS  |  ENI de tarefa  |  ENI de tarefa  |  ENI de tarefa  |  Função do IAM de tarefa  | 
|  Recuperar segredos do Secrets Manager ou Systems Manager  |  ENI de propriedade do Fargate  |  ENI de tarefa  |  ENI de tarefa  |  Função do IAM de execução de tarefas  | 
|  Tráfego do sistema de arquivos do Amazon EFS  |  Indisponível  |  ENI de tarefa  |  ENI de tarefa  |  Função do IAM de tarefa  | 
|  Tráfego de aplicativos  |  ENI de tarefa  |  ENI de tarefa  |  ENI de tarefa  |  Função do IAM de tarefa  | 

## Considerações
<a name="fargate-task-networking-considerations"></a>

Considere o seguinte ao usar redes de tarefas:
+ É necessário que a função vinculada ao serviço do Amazon ECS forneça ao Amazon ECS as permissões para fazer chamadas a outros serviços da AWS em seu nome. Essa função será criada quando você criar um cluster ou se criar ou atualizar um serviço no Console de gerenciamento da AWS. Para obter mais informações, consulte [Uso de perfis vinculados ao serviço para o Amazon ECS](using-service-linked-roles.md). Também é possível criar a função vinculada ao serviço usando o comando da AWS CLI a seguir.

  ```
  aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name ecs.amazonaws.com
  ```
+ O Amazon ECS preenche o nome de host da tarefa usando a rede de tarefas com um nome de host DNS (interno) fornecido pela Amazon quando as opções `enableDnsHostnames` e `enableDnsSupport` estão habilitadas na sua VPC. Se essas opções não estiverem habilitadas, o nome de host DNS da tarefa será definido como um nome de host aleatório. Para obter mais informações sobre as configurações de DNS para uma VPC, consulte [Usar DNS com sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) no *Guia do usuário da Amazon VPC*.
+ É possível especificar até 16 sub-redes e 5 grupos de segurança para `awsVpcConfiguration`. Para obter mais informações, consulte [AwsVpcConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AwsVpcConfiguration.html) na *Referência da API de serviço do contêiner do Amazon Elastic Container Service*.
+ Você não pode desanexar ou modificar manualmente as ENIs criadas e anexadas pelo Fargate. Isso visa a evitar a exclusão acidental de uma ENI associada a uma tarefa em execução. Para liberar as ENIs para uma tarefa, interrompa-a.
+ Se uma sub-rede de VPC for atualizada para alterar o conjunto de opções de DHCP que ela utiliza, não será possível aplicar essas alterações às tarefas existentes que usarem a VPC. Inicie novas tarefas, que receberão a nova configuração para uma migração tranquila ao testar a nova alteração e, em seguida, interrompa as antigas caso nenhuma reversão seja necessária.
+ O seguinte se aplica às tarefas executadas na plataforma Fargate versão `1.4.0` ou posterior para Linux, ou `1.0.0` para Windows. Tarefas iniciadas em sub-redes de pilha dupla recebem um endereço IPv4 e um endereço IPv6. As tarefas inicializadas em sub-redes somente IPv6 recebem apenas um endereço IPv6.
+ Para tarefas que utilizam versão da plataforma `1.4.0` ou posterior para Linux ou `1.0.0` para Windows, as ENIs de tarefas oferecem suporte a frames 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 reduz a sobrecarga quando o caminho de rede entre a tarefa e o destino oferece suporte a quadros jumbo.
+ Os serviços com tarefas que usam o Fargate só oferecem suporte ao Application Load Balancer e ao Network Load Balancer. Não há suporte para Classic Load Balancers. Ao criar grupos de destino, você precisa escolher `ip` como o tipo de destino, e não `instance`. 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).

## Usar uma VPC no modo de pilha dupla
<a name="fargate-task-networking-vpc-dual-stack"></a>

Ao usar uma VPC no modo de pilha dupla, suas tarefas podem se comunicar por IPv4, IPv6 ou ambos. Os endereços IPv4 e IPv6 são independentes um do outro e você pode configurar o roteamento e a segurança na VPC separadamente para IPv4 e IPv6. Para obter mais informações sobre como configurar a VPC para o modo de pilha dupla, consulte [Migrar para IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) no *Guia do usuário da Amazon VPC*.

As tarefas do Amazon ECS no Fargate receberão um endereço IPv6 se as seguintes condições forem atendidas:
+ A configuração de conta `dualStackIPv6` do Amazon ECS está ativada (`enabled`) para que a entidade principal do IAM execute as tarefas na região em que você está executando suas tarefas. Essa configuração só pode ser modificada usando a API ou a AWS CLI. Você tem a opção de ativar essa configuração para uma entidade principal do IAM específica na conta ou para toda a conta, definindo a configuração padrão da conta. Para obter mais informações, consulte [Acesso aos recursos do Amazon ECS com as configurações de conta](ecs-account-settings.md).
+ Sua VPC e sua sub-rede estão habilitadas para IPv6. Para obter mais informações sobre como configurar a VPC para o modo de pilha dupla, consulte [Migrar para IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) no *Guia do usuário da Amazon VPC*.
+ Sua sub-rede está habilitada para atribuição automática de endereços IPv6. Para obter mais informações sobre como configurar sua sub-rede, consulte [Modificar o atributo de endereçamento IPv6 para a sua sub-rede](https://docs.aws.amazon.com/vpc/latest/userguide/modify-subnets.html) no *Guia do usuário da Amazon VPC*.
+ A tarefa ou o serviço utiliza a versão `1.4.0` ou posterior da plataforma Fargate para Linux.

Para tarefas do Amazon ECS no Fargate executadas em uma VPC no modo de pilha dupla, para se comunicar com serviços de dependência usados no processo de execução de tarefas, como ECR, SSM e SecretManager, a tabela de rotas da sub-rede pública precisa de uma rota IPv4 (0.0.0.0/0) para um gateway de internet e a tabela de rotas da sub-rede privada precisa de uma rota IPv4 (0.0.0.0/0) para um Gateway NAT. Para obter mais informações, consulte [gateways da internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) e [Gateways NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) no *Guia do usuário da Amazon VPC*. 

Para ver exemplos de como configurar uma VPC de pilha dupla, consulte [Exemplo de configuração VPC de pilha dupla](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6-example.html). 

## Usar uma VPC no modo somente IPv6
<a name="fargate-task-networking-vpc-ipv6-only"></a>

Em uma configuração somente IPv6, suas tarefas do Amazon ECS se comunicam exclusivamente via IPv6. Para configurar VPCs e sub-redes para uma configuração somente IPv6, adicione um bloco CIDR IPv6 à VPC e crie sub-redes que incluam apenas um bloco CIDR IPv6. Para obter mais informações, consulte [Adicionar suporte IPv6 para sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6-add.html) e [Criar uma sub-rede](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html) no *Guia do usuário da Amazon VPC*. Atualize também as tabelas de rotas com destinos IPv6 e configure grupos de segurança com regras IPv6. Para obter mais informações, consulte [Configurar tabelas de rotas](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) e [Configurar regras de grupo de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) no *Guia do usuário da Amazon VPC*.

As seguintes considerações se aplicam:
+ Você pode atualizar um serviço somente IPv4 ou de pilha dupla do Amazon ECS para uma configuração somente IPv6 atualizando o serviço diretamente para usar sub-redes somente IPv6 ou criando um serviço somente IPv6 paralelo e usando implantações azul-verde do Amazon ECS para transferir o tráfego para o novo serviço. Para obter mais informações sobre implantações azul/verde do Amazon ECS, consulte [Implantações azuis/verdes do Amazon ECS](deployment-type-blue-green.md).
+ Um serviço somente IPv6 do Amazon ECS deve usar balanceadores de carga de pilha dupla com grupos-de destino IPv6. Se você estiver migrando um serviço do Amazon ECS existente que está por trás de um Application Load Balancer ou de um Network Load Balancer, será possível criar um novo balanceador de carga de pilha dupla e transferir o tráfego do balanceador de carga antigo ou atualizar o tipo de endereço IP do balanceador de carga existente.

   Para obter mais informações sobre Network Load Balancers consulte [Criar um Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html) e [Atualizar os tipos de endereço IP do seu Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-ip-address-type.html) no *Guia do usuário para Network Load Balancers*. Para obter mais informações sobre Application Load Balancers, consulte [Criar um Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) e [Atualizar os tipos de endereço IP do seu Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-ip-address-type.html) no *Guia do usuário para Application Load Balancers*.
+ Não há suporte para a configuração somente IPv6 no Windows.
+ Para tarefas do Amazon ECS em uma configuração somente IPv6 para se comunicar com endpoints somente IPv4, você pode configurar DNS64 e NAT64 para converter endereços de rede de IPv6 para IPv4. Para obter mais informações, consulte [DNS64 e NAT64](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-nat64-dns64.html), no *Guia do usuário da Amazon VPC*.
+ A configuração somente IPv6 é compatível com a versão da plataforma `1.4.0` ou posterior do Fargate.
+ As workloads do Amazon ECS em uma configuração somente IPv6 devem usar endpoints de URI de imagem de pilha dupla do Amazon ECR ao extrair imagens do Amazon ECR. Para obter mais informações, consulte [Como começar a fazer solicitações via IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) no *Guia do usuário do Amazon Elastic Container Registry*.
**nota**  
O Amazon ECR não oferece suporte a endpoints da VPC de interface de pilha dupla que as tarefas de uma configuração somente IPv6 possam usar. Para obter mais informações, consulte [Como começar a fazer solicitações via IPv6](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr-requests.html#ipv6-access-getting-started) no *Guia do usuário do Amazon Elastic Container Registry*.
+ Não há suporte para o Amazon ECS Exec em uma configuração somente IPv6.
+ O Amazon CloudWatch não oferece suporte a um endpoint FIPS de pilha dupla que possa ser usado para monitorar as tarefas do Amazon ECS em configurações somente IPv6 que usam conformidade com FIPS-140. Para obter mais informações sobre FIPS-140, consulte [Padrão Federal de Processamento de Informações (FIPS-140) do AWS Fargate](ecs-fips-compliance.md).

### Regiões da AWS que são compatíveis com o modo somente IPv6 no Amazon ECS
<a name="fargate-task-networking-ipv6-only-regions"></a>

Você pode executar tarefas em uma configuração somente IPv6 nas seguintes Regiões da AWS em que o Amazon ECS está disponível:
+ Leste dos EUA (Ohio)
+ Leste dos EUA (Norte da Virgínia)
+ Oeste dos EUA (N. da Califórnia)
+ Oeste dos EUA (Oregon)
+ África (Cidade do Cabo)
+ Ásia-Pacífico (Hong Kong)
+ Ásia-Pacífico (Hyderabad)
+ Ásia-Pacífico (Jacarta)
+ Ásia-Pacífico (Melbourne)
+ Ásia-Pacífico (Mumbai)
+ Ásia-Pacífico (Osaka)
+ Ásia-Pacífico (Seul)
+ Ásia-Pacífico (Singapura)
+ Ásia-Pacífico (Sydney)
+ Ásia-Pacífico (Tóquio)
+ Canadá (Central)
+ Oeste do Canadá (Calgary)
+ China (Pequim)
+ China (Ningxia)
+ Europa (Frankfurt)
+ Europa (Londres)
+ Europa (Milão)
+ Europe (Paris)
+ Europa (Espanha)
+ Israel (Tel Aviv)
+ Oriente Médio (Bahrein)
+ Oriente Médio (Emirados Árabes Unidos)
+ América do Sul (São Paulo)
+ AWS GovCloud (Leste dos EUA)
+ AWS GovCloud (Oeste dos EUA)

# Opções de armazenamento para tarefas do Amazon ECS
<a name="using_data_volumes"></a>

O Amazon ECS fornece opções de armazenamento de dados flexíveis, econômicas e fáceis de usar, dependendo das suas necessidades.. O Amazon ECS oferece suporte às seguintes opções de volume de dados para contêineres:


| Volume de dados | Capacidade compatível | Sistemas operacionais compatíveis | Persistência de armazenamento | Casos de uso | 
| --- | --- | --- | --- | --- | 
| Amazon Elastic Block Store (Amazon EBS) | Fargate, Amazon EC2, instâncias gerenciadas do Amazon ECS | Linux, Windows (somente no Amazon EC2) | Pode ser persistido quando anexado a uma tarefa autônoma. Temporário quando anexado a uma tarefa mantida por um serviço. | Os volumes do Amazon EBS fornecem armazenamento em blocos econômico, durável e de alto desempenho para workloads em contêineres com uso intenso de dados. Os casos de uso comuns incluem workloads transacionais, como bancos de dados, áreas de trabalho virtuais e volumes raiz, e workloads com alto throughput, como processamento de logs e workloads ETL. Para obter mais informações, consulte [Uso de volumes do Amazon EBS com o Amazon ECS](ebs-volumes.md). | 
| Amazon Elastic File System (Amazon EFS) | Fargate, Amazon EC2, instâncias gerenciadas do Amazon ECS | Linux | Persistente | Os volumes do Amazon EFS fornecem armazenamento de arquivos compartilhado simples, escalável e persistente para uso com tarefas do Amazon ECS, que cresce e diminui automaticamente à medida que arquivos são adicionados e removidos. Os volumes do Amazon EFS oferecem suporte à concorrência e são úteis para aplicações em contêineres que escalam horizontalmente e precisam de funcionalidades de armazenamento, como baixa latência, alto throughput e consistência de leitura após gravação. Os casos de uso comuns incluem workloads, como data analytics, processamento de mídia, gerenciamento de conteúdo e distribuição pela Web. Para obter mais informações, consulte [Uso de volumes do Amazon EFS com o Amazon ECS](efs-volumes.md). | 
| Amazon FSx para Windows File Server | Amazon EC2 | Windows | Persistente | Os volumes do FSx para Windows File Server fornecem servidores de arquivos do Windows totalmente gerenciados que podem ser usados para provisionar tarefas do Windows que precisam de armazenamento de arquivos persistente, distribuído, compartilhado e estático. Casos de uso comuns incluem aplicações .NET que podem exigir pastas locais como armazenamento persistente para salvar as saídas da aplicação. O Amazon FSx para Windows File Server oferece uma pasta local no contêiner que permite a leitura e gravação de vários contêineres no mesmo sistema de arquivos apoiado por um compartilhamento SMB. Para obter mais informações, consulte [Uso de volumes do FSx para Windows File Server com Amazon ECS](wfsx-volumes.md). | 
| Amazon FSx para NetApp ONTAP | Amazon EC2 | Linux | Persistente | Os volumes do Amazon FSx para NetApp ONTAP fornecem sistemas de arquivos NetApp ONTAP totalmente gerenciados que podem ser usar para provisionar suas tarefas Linux que precisam de armazenamento de arquivos compartilhado persistente, de alta performance e rico em recursos. O Amazon FSx para NetApp ONTAP oferece suporte aos protocolos NFS e SMB e fornece recursos de nível corporativo, como snapshots, clonagem e desduplicação de dados. Os casos de uso comuns incluem workloads de computação de alta performance, repositórios de conteúdo e aplicações que exigem armazenamento compartilhado compatível com POSIX. Para obter mais informações, consulte [Montar sistemas de arquivos do Amazon FSx para NetApp ONTAP a partir de contêineres do Amazon ECS](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/mount-ontap-ecs-containers.html). | 
| Volumes do Docker | Amazon EC2 | Windows, Linux | Persistente | Os volumes do Docker são um recurso de runtime do contêiner do Docker que permite que os contêineres persistam os dados montando um diretório no sistema de arquivos do host. Drivers de volume do Docker (também conhecidos como plug-ins) são usados para integrar os volumes do contêiner com os sistemas de armazenamento externos. Os volumes do Docker podem ser gerenciados por drivers de terceiros ou pelo driver local integrado. Casos de uso comuns para volumes do Docker incluem fornecer volumes de dados persistentes ou compartilhar volumes em diferentes locais em diferentes contêineres na mesma instância de contêiner. Para obter mais informações, consulte [Uso de volumes do Docker com o Amazon ECS](docker-volumes.md). | 
| Montagens bind | Fargate, Amazon EC2, instâncias gerenciadas do Amazon ECS | Windows, Linux | Temporário | As montagens vinculadas consistem em um arquivo ou diretório no host, como uma instância do Amazon EC2 ou o AWS Fargate, que é montado em um contêiner. Casos de uso comuns para montagens vinculadas incluem compartilhar um volume de um contêiner de origem com outros contêineres na mesma tarefa ou montar um volume de host ou um volume vazio em um ou mais contêineres. Para obter mais informações, consulte [Uso de montagens vinculadas com o Amazon ECS](bind-mounts.md). | 

# Uso de volumes do Amazon EBS com o Amazon ECS
<a name="ebs-volumes"></a>

Os volumes do Amazon Elastic Block Store (Amazon EBS) fornecem armazenamento em bloco de alta disponibilidade, econômico, durável e de alta performance para workloads com uso intenso de dados. Os volumes do Amazon EBS podem ser usados com tarefas do Amazon ECS em aplicações de alto throughput e uso intenso de transações. Para obter mais informações sobre volumes do Amazon EBS, consulte [Amazon EBS volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes.html) no *Guia do usuário do Amazon EBS*.

Os volumes do Amazon EBS anexados às tarefas do Amazon ECS são gerenciados pelo Amazon ECS em seu nome. Durante a execução de tarefas autônomas, você pode fornecer a configuração que será usada para anexar um volume do EBS à tarefa. Durante a criação ou atualização do serviço, você pode fornecer a configuração que será usada para anexar um volume do EBS por tarefa a cada tarefa gerenciada pelo serviço do Amazon ECS. Você pode configurar volumes novos e vazios para anexação ou usar snapshots para carregar dados de volumes existentes.

**nota**  
Ao usar snapshots para configurar volumes, você pode especificar uma `volumeInitializationRate`, em MiB/s, no qual os dados são buscados do snapshot para criar volumes totalmente inicializados em um período previsível. Para obter mais informações sobre a inicialização de volumes, consulte [Inicializar volumes do Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/initalize-volume.html) no *Guia do usuário do Amazon EBS*. Para obter mais informações sobre a configuração de volumes do Amazon EBS, consulte [Adiar a configuração de volumes para o momento da inicialização na definição de tarefa do Amazon ECS](specify-ebs-config.md) e [Especificar a configuração de volumes do Amazon EBS na implantação do Amazon ECS](configure-ebs-volume.md).

A configuração de volume é adiada para o horário de inicialização usando o parâmetro `configuredAtLaunch` na definição da tarefa. Ao fornecer a configuração de volume no momento da inicialização em vez de na definição da tarefa, você cria definições de tarefas que não estão restritas a um tipo específico de volume de dados ou a configurações específicas de volume do EBS. Em seguida, você pode reutilizar as definições de tarefas em diferentes ambientes de runtime. Por exemplo, você pode fornecer mais throughput durante a implantação para as workloads de produção do que para os ambientes de pré-produção.

 Os volumes do Amazon EBS anexados às tarefas podem ser criptografados com chaves AWS Key Management Service (AWS KMS) para proteger seus dados. Para obter mais informações, consulte, [Criptografar dados armazenados em volumes do Amazon EBS para tarefas do Amazon ECS](ebs-kms-encryption.md).

Para monitorar o desempenho do volume, você também pode usar as métricas do Amazon CloudWatch. Para obter mais informações sobre as métricas do Amazon ECS para volumes do Amazon EBS, consulte [Métricas do CloudWatch do Amazon ECS](available-metrics.md) e [Métricas do Amazon ECS Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-ECS.html).

A anexação de um volume do Amazon EBS a uma tarefa é compatível com todas as [Regiões da AWS](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html?icmpid=docs_homepage_addtlrcs#region) de empresas comerciais e na China que oferecem suporte ao Amazon ECS.

## Sistemas operacionais e capacidade compatíveis
<a name="ebs-volumes-configuration"></a>

A tabela a seguir fornece as configurações compatíveis de sistema operacional e capacidade.


| Capacidade | Linux  | Windows | 
| --- | --- | --- | 
| Fargate |  Os volumes do Amazon EBS são compatíveis com a versão da plataforma 1.4.0 ou posterior (Linux). Para obter mais informações, consulte [Versões da plataforma do Fargate para o Amazon ECS](platform-fargate.md). | Não compatível | 
| EC2 | Há suporte para volumes do Amazon EBS nas tarefas hospedadas em instâncias baseadas em Nitro com imagens de máquina da Amazon (AMIs) otimizadas para o Amazon ECS. Para obter mais informações sobre os tipos de instância, consulte [Tipos de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) no Guia do usuário do Amazon EC2. Os volumes do Amazon EBS são compatíveis com a AMI otimizada para ECS `20231219` ou posterior. Para obter mais informações, consulte [Recuperar os metadados da AMI otimizada para Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/retrieve-ecs-optimized_AMI.html). | Tarefas hospedadas em instâncias baseadas em Nitro com imagens de máquina da Amazon (AMIs) otimizadas para Amazon ECS. Para obter mais informações sobre os tipos de instância, consulte [Tipos de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) no Guia do usuário do Amazon EC2. Os volumes do Amazon EBS são compatíveis com a AMI otimizada para ECS `20241017` ou posterior. Para obter mais informações, consulte [Recuperar os metadados da AMI do Windows otimizada para Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/retrieve-ecs-optimized_windows_AMI.html). | 
| Instâncias gerenciadas do Amazon ECS | Os volumes do Amazon EBS são compatíveis com tarefas hospedadas em instâncias gerenciadas do Amazon ECS no Linux. | Não compatível | 

## Considerações
<a name="ebs-volume-considerations"></a>

 Considere o seguinte ao usar volumes do Amazon EBS:
+ Não é possível configurar volumes do Amazon EBS para serem anexados às tarefas do Fargate para Amazon ECS nas zonas de disponibilidade `use1-az3`.
+ O tipo de volume magnético (`standard`) do Amazon EBS não é compatível com tarefas hospedadas no Fargate. Para obter mais informações sobre os tipos de volumes do Amazon EBS, consulte [Amazon EBS volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html) no *Guia do usuário do Amazon EC2*.
+ Um perfil do IAM na infraestrutura do Amazon ECS é necessário ao criar um serviço ou uma tarefa autônoma que esteja configurando um volume na implantação. Você pode anexar a política do IAM `AmazonECSInfrastructureRolePolicyForVolumes` gerenciada pela AWS ao perfil ou usar a política gerenciada como um guia para criar e anexar sua própria política com permissões que atendam às suas necessidades específicas. Para obter mais informações, consulte [Perfil do IAM de infraestrutura do Amazon ECS](infrastructure_IAM_role.md).
+ Você pode anexar, no máximo, um volume do Amazon EBS a cada tarefa do Amazon ECS, e ele deve ser novo. Não é possível anexar um volume existente do Amazon EBS a uma tarefa. No entanto, você pode configurar um novo volume do Amazon EBS na implantação usando o snapshot de um volume existente.
+ Para usar os volumes do Amazon EBS com os serviços do Amazon ECS, o controlador de implantação deve ser `ECS`. Tanto a estratégia de implantação azul/verde como a contínua são compatíveis ao usar esse controlador de implantação.
+ Para que um contêiner na tarefa grave no volume montado do Amazon EBS, ele deve ter permissões apropriadas do sistema de arquivos. Quando você especifica um usuário não raiz em sua definição de contêiner, o Amazon ECS configura automaticamente o volume com permissões baseadas em grupo que permitem que o usuário especificado leia e grave no volume. Se nenhum usuário for especificado, o contêiner será executado como raiz e terá acesso total ao volume.
+ O Amazon ECS adiciona automaticamente as tags reservadas `AmazonECSCreated` e `AmazonECSManaged` ao volume anexado. Se você remover essas tags do volume, o Amazon ECS não poderá gerenciá-lo em seu nome. Para obter mais informações sobre marcação de volumes do Amazon EBS, consulte [Tagging Amazon EBS volumes](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/specify-ebs-config.html#ebs-volume-tagging). Para obter mais informações sobre marcação de recursos do Amazon ECS, consulte [Tagging your Amazon ECS resources](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html).
+ Não há suporte para o provisionamento de volumes usando um snapshot de um volume do Amazon EBS que contém partições.
+ Os volumes anexados às tarefas gerenciadas por um serviço não são preservados e sempre são excluídos após o encerramento da tarefa.
+ Não é possível configurar volumes do Amazon EBS para anexar tarefas do Amazon ECS em execução no AWS Outposts.

# Comportamento de usuário não raiz
<a name="ebs-non-root-behavior"></a>

Quando você especifica um usuário não raiz em sua definição de contêiner, o Amazon ECS configura automaticamente o volume do Amazon EBS com permissões baseadas em grupo que permitem que o usuário especificado leia e grave no volume. O volume é montado com as seguintes características:
+ O volume pertence ao usuário-raiz e ao grupo-raiz.
+ As permissões de grupo são definidas para permitir acesso de leitura e gravação.
+ O usuário não raiz é adicionado ao grupo apropriado para acessar o volume.

Siga estas práticas recomendadas ao usar volumes do Amazon EBS com contêineres não raiz:
+ Use IDs de usuário (UIDs) e IDs de grupo (GIDs) consistentes em todas as imagens de contêiner para garantir permissões consistentes.
+ Crie previamente diretórios de ponto de montagem na imagem do contêiner e defina a propriedade e as permissões apropriadas.
+ Teste seus contêineres com volumes do Amazon EBS em um ambiente de desenvolvimento para confirmar se as permissões do sistema de arquivos funcionam conforme o esperado.
+ Se vários contêineres na mesma tarefa compartilharem um volume, certifique-se de que eles usem UIDs/GIDs compatíveis ou montem o volume com expectativas de acesso consistentes.

# Adiar a configuração de volumes para o momento da inicialização na definição de tarefa do Amazon ECS
<a name="specify-ebs-config"></a>

Para configurar um volume do Amazon EBS para anexar à tarefa, você deve especificar a configuração do ponto de montagem na definição da tarefa e nomear o volume. Você também deve definir `configuredAtLaunch` como `true` porque os volumes do Amazon EBS não podem ser configurados para anexação na definição da tarefa. Em vez disso, os volumes do Amazon EBS são configurados para associação durante a implantação.

Para registrar a definição de tarefa usando a AWS Command Line Interface (AWS CLI), salve o modelo como arquivo JSON e passe o arquivo como entrada para o comando `[register-task-definition](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html)`. 

Para criar e registrar uma definição de tarefa usando o Console de gerenciamento da AWS, consulte [Criar uma definição de tarefa do Amazon ECS usando o console](create-task-definition.md).

A definição de tarefa a seguir mostra a sintaxe dos objetos `mountPoints` e `volumes` na definição de tarefa. Para obter mais informações sobre os parâmetros de definição de tarefa, consulte [Parâmetros de definição de tarefa do Amazon ECS para o Fargate](task_definition_parameters.md). Para usar esse exemplo, substitua os `user input placeholders` por suas próprias informações.

## Linux
<a name="linux-example"></a>

```
{
    "family": "mytaskdef",
    "containerDefinitions": [
        {
            "name": "nginx",
            "image": "public.ecr.aws/nginx/nginx:latest",
            "networkMode": "awsvpc",
           "portMappings": [
                {
                    "name": "nginx-80-tcp",
                    "containerPort": 80,
                    "hostPort": 80,
                    "protocol": "tcp",
                    "appProtocol": "http"
                }
            ],
            "mountPoints": [
                {
                    "sourceVolume": "myEBSVolume",
                    "containerPath": "/mount/ebs",
                    "readOnly": true
                }
            ]
        }
    ],
    "volumes": [
        {
            "name": "myEBSVolume",
            "configuredAtLaunch": true
        }
    ],
    "requiresCompatibilities": [
        "FARGATE", "EC2"
    ],
    "cpu": "1024",
    "memory": "3072",
    "networkMode": "awsvpc"
}
```

## Windows
<a name="windows-example"></a>

```
{
    "family": "mytaskdef",
     "memory": "4096",
     "cpu": "2048",
    "family": "windows-simple-iis-2019-core",
    "executionRoleArn": "arn:aws:iam::012345678910:role/ecsTaskExecutionRole",
    "runtimePlatform": {"operatingSystemFamily": "WINDOWS_SERVER_2019_CORE"},
    "requiresCompatibilities": ["EC2"]
    "containerDefinitions": [
        {
             "command": ["New-Item -Path C:\\inetpub\\wwwroot\\index.html -Type file -Value '<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>Congratulations!</h2> <p>Your application is now running on a container in Amazon ECS.</p>'; C:\\ServiceMonitor.exe w3svc"],
            "entryPoint": [
                "powershell",
                "-Command"
            ],
            "essential": true,
            "cpu": 2048,
            "memory": 4096,
            "image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019",
            "name": "sample_windows_app",
            "portMappings": [
                {
                    "hostPort": 443,
                    "containerPort": 80,
                    "protocol": "tcp"
                }
            ],
            "mountPoints": [
                {
                    "sourceVolume": "myEBSVolume",
                    "containerPath": "drive:\ebs",
                    "readOnly": true
                }
            ]
        }
    ],
    "volumes": [
        {
            "name": "myEBSVolume",
            "configuredAtLaunch": true
        }
    ],
    "requiresCompatibilities": [
        "FARGATE", "EC2"
    ],
    "cpu": "1024",
    "memory": "3072",
    "networkMode": "awsvpc"
}
```

`mountPoints`  
Tipo: Matriz de objeto  
Obrigatório: não  
Os pontos de montagem dos volumes de dados no contêiner. Esse parâmetro é mapeado em `Volumes` na API create-container do Docker na opção `--volume` de execução do docker.  
Os contêineres do Windows podem montar diretórios inteiros na mesma unidade como `$env:ProgramData`. Os contêineres do Windows não podem montar diretórios em uma unidade diferente, e os pontos de montagem não podem ser usados ​​entre unidades. Você deve especificar pontos de montagem para anexar um volume do Amazon EBS diretamente a uma tarefa do Amazon ECS.    
`sourceVolume`  
Tipo: string  
Exigido: Sim, quando `mountPoints` são usados  
O nome do volume a ser montado.  
`containerPath`  
Tipo: string  
Exigido: Sim, quando `mountPoints` são usados  
O caminho no contêiner onde o volume será montado.  
`readOnly`  
Tipo: booliano  
Obrigatório: não  
Caso o valor seja `true`, o contêiner tem acesso somente leitura ao volume. Caso esse valor seja `false`, o contêiner pode gravar no volume. O valor padrão é `false`.  
Para tarefas executadas em instâncias do EC2 que executam o sistema operacional Windows, deixe o valor como o padrão de `false`.

`name`  
Tipo: string  
Obrigatório: não  
O nome do volume. São permitidos até 255 letras (caixa alta e baixa), números, hífens (`-`) e sublinhados (`_`). Esse nome é referenciado no parâmetro `sourceVolume` do objeto `mountPoints` de definição do contêiner.

`configuredAtLaunch`  
Tipo: booliano  
Obrigatório: sim, quando você deseja anexar um volume do EBS diretamente a uma tarefa.  
Especifica se um volume é configurável na execução. Quando definido como `true`, você pode configurar o volume ao executar uma tarefa autônoma ou ao criar ou atualizar um serviço. Quando definido como `false`, não será possível fornecer outra configuração de volume na definição da tarefa. Esse parâmetro deve ser fornecido e definido como `true` para configurar um volume do Amazon EBS para anexar a uma tarefa.

# Criptografar dados armazenados em volumes do Amazon EBS para tarefas do Amazon ECS
<a name="ebs-kms-encryption"></a>

Você pode usar o AWS Key Management Service (AWS KMS) para criar e gerenciar chaves criptográficas que protegem seus dados. Os volumes do Amazon EBS são criptografados em repouso usando o AWS KMS keys. Os seguintes tipos de dados são criptografados:
+ Dados armazenados em repouso no volume
+ E/S de disco
+ Snapshots criados no volume
+ Novos volumes criados de snapshots criptografados

Os volumes do Amazon EBS associados a tarefas podem ser criptografados usando uma Chave gerenciada pela AWS padrão com o alias `alias/aws/ebs` ou uma chave simétrica gerenciada pelo cliente especificada na configuração do volume. As Chaves gerenciadas pela AWS padrão são exclusivas para cada Conta da AWS por Região da AWS e são criadas automaticamente. Para criar uma chave simétrica gerenciada pelo cliente, siga as etapas em [Creating symmetric encryption KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk) no *Guia do desenvolvedor do AWS KMS*.

É possível configurar a criptografia do Amazon EBS por padrão para que todos os novos volumes criados e anexados a uma Região da AWS específica sejam criptografados usando a chave do KMS especificada para a sua conta. Para obter mais informações sobre criptografia do Amazon EBS e criptografia por padrão, consulte [Criptografia do Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html) no *Guia do usuário do Amazon EBS*.

## Comportamento de instâncias gerenciadas do Amazon ECS
<a name="managed-instances"></a>

Criptografe volumes do Amazon EBS habilitando a criptografia, usando a criptografia por padrão ou habilitando a criptografia ao criar um volume que deseja criptografar. Para obter informações sobre como habilitar a criptografia por padrão (no nível da conta), consulte [Criptografia por padrão](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html) no *Guia do usuário do Amazon EBS*.

É possível configurar uma combinação qualquer dessas chaves. A ordem de precedência das chaves do KMS é a seguinte:

1. A chave do KMS especificada na configuração do volume. Quando você especifica uma chave KMS na configuração de volume, ela substitui o padrão do Amazon EBS e qualquer chave KMS especificada no nível da conta.

1. A chave KMS especificada no nível da conta. Quando você especifica uma chave do KMS para criptografia no nível de cluster do armazenamento gerenciado do Amazon ECS, ela substitui a criptografia padrão do Amazon EBS, mas não substitui nenhuma chave do KMS especificada na configuração do volume.

1. Criptografia padrão do Amazon EBS. A criptografia padrão se aplica quando você não especifica uma chave KMS no nível da conta ou uma chave na configuração de volume. Se você habilitar a criptografia do Amazon EBS por padrão, o padrão será a chave do KMS que você especifica para criptografia por padrão. Caso contrário, o padrão é o Chave gerenciada pela AWS com o alias `alias/aws/ebs`.
**nota**  
Se você definir `encrypted` como `false` na configuração de volume, não especificar nenhuma chave KMS no nível da conta e habilitar a criptografia do Amazon EBS por padrão, o volume ainda será criptografado com a chave especificada para a criptografia do Amazon EBS por padrão.

## Comportamento de instâncias gerenciadas não do Amazon ECS
<a name="non-managed-instances"></a>

Você também pode configurar a criptografia em nível de cluster do Amazon ECS para armazenamento gerenciado do Amazon ECS ao criar ou atualizar um cluster. A criptografia no nível do cluster tem efeito no nível da tarefa e pode ser usada para criptografar os volumes do Amazon EBS anexados a cada tarefa executada em um cluster específico usando a chave KMS especificada. Para obter mais informações sobre como configurar a criptografia no nível do cluster para cada tarefa, consulte [ManagedStorageConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedStorageConfiguration.html) na *Referência da API do Amazon ECS*.

É possível configurar uma combinação qualquer dessas chaves. A ordem de precedência das chaves do KMS é a seguinte:

1. A chave do KMS especificada na configuração do volume. Quando você especifica uma chave KMS na configuração do volume, ela substitui o padrão do Amazon EBS e qualquer chave do KMS especificada no nível do cluster.

1. A chave do KMS especificada no nível do cluster. Quando você especifica uma chave do KMS para criptografia no nível de cluster do armazenamento gerenciado do Amazon ECS, ela substitui a criptografia padrão do Amazon EBS, mas não substitui nenhuma chave do KMS especificada na configuração do volume.

1. Criptografia padrão do Amazon EBS. A criptografia padrão se aplica quando você não especifica uma chave do KMS em nível do cluster ou uma chave na configuração do volume. Se você habilitar a criptografia do Amazon EBS por padrão, o padrão será a chave do KMS que você especifica para criptografia por padrão. Caso contrário, o padrão é o Chave gerenciada pela AWS com o alias `alias/aws/ebs`.
**nota**  
Se você definir `encrypted` como `false` na configuração do volume, não especificar nenhuma chave do KMS em nível de cluster e habilitar a criptografia do Amazon EBS por padrão, o volume ainda será criptografado com a chave especificada para a criptografia do Amazon EBS por padrão.

## Política de chave do KMS gerenciada pelo cliente
<a name="ebs-kms-encryption-policy"></a>

Para criptografar um volume do EBS anexado à tarefa usando uma chave gerenciada pelo cliente, você deve configurar sua política de chave do KMS para garantir que o perfil do IAM usado na configuração do volume tenha as permissões necessárias para usar a chave. A política de chave deve incluir as permissões `kms:CreateGrant` e `kms:GenerateDataKey*`. As permissões `kms:ReEncryptTo` e `kms:ReEncryptFrom` são necessárias para criptografar volumes criados usando snapshots. Se quiser configurar e criptografar somente volumes novos e vazios para anexação, você pode excluir as permissões `kms:ReEncryptTo` e `kms:ReEncryptFrom`. 

O trecho JSON a seguir mostra as instruções de política de chave que você pode anexar à sua política de chave do KMS. O uso dessas instruções fornecerá acesso ao Amazon ECS para usar a chave para criptografar o volume do EBS. Para usar os exemplos de instruções de política, substitua os `user input placeholders` por suas próprias informações. Como sempre, configure apenas as permissões de que você precisa.

```
{
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/ecsInfrastructureRole" },
      "Action": "kms:DescribeKey",
      "Resource":"*"
    },
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/ecsInfrastructureRole" },
      "Action": [
      "kms:GenerateDataKey*",
      "kms:ReEncryptTo",
      "kms:ReEncryptFrom"
      ],
      "Resource":"*",
      "Condition": {
        "StringEquals": {
          "kms:CallerAccount": "aws_account_id",
          "kms:ViaService": "ec2.region.amazonaws.com"
        },
        "ForAnyValue:StringEquals": {
          "kms:EncryptionContextKeys": "aws:ebs:id"
        }
      }
    },
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/ecsInfrastructureRole" },
      "Action": "kms:CreateGrant",
      "Resource":"*",
      "Condition": {
        "StringEquals": {
          "kms:CallerAccount": "aws_account_id",
          "kms:ViaService": "ec2.region.amazonaws.com"
        },
        "ForAnyValue:StringEquals": {
          "kms:EncryptionContextKeys": "aws:ebs:id"
        },
        "Bool": {
          "kms:GrantIsForAWSResource": true
        }
      }
    }
```

Para obter mais informações sobre políticas e permissões de chave, consulte [Key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) e [AWS KMS permissions](https://docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html) no *Guia do desenvolvedor do AWS KMS*. Para solucionar problemas de anexação de volumes do EBS relacionados às permissões de chave, consulte [Solução de problemas de anexações de volumes do Amazon EBS às tarefas do Amazon ECS](troubleshoot-ebs-volumes.md).

# Especificar a configuração de volumes do Amazon EBS na implantação do Amazon ECS
<a name="configure-ebs-volume"></a>

Depois de registrar uma definição de tarefa com o parâmetro `configuredAtLaunch` definido como `true`, você pode configurar um volume do Amazon EBS na implantação ao executar uma tarefa autônoma ou ao criar ou atualizar um serviço. Para obter mais informações sobre como adiar a configuração de volume para o momento da inicialização usando o parâmetro `configuredAtLaunch`, consulte [Adiar a configuração de volumes para o momento da inicialização na definição de tarefa do Amazon ECS](specify-ebs-config.md).

Para configurar um volume, você pode usar as APIs do Amazon ECS ou passar um arquivo JSON como entrada para os seguintes comandos da AWS CLI:
+ `[run-task](https://docs.aws.amazon.com/cli/latest/reference/ecs/run-task.html)` para executar uma tarefa autônoma do ECS.
+ `[start-task](https://docs.aws.amazon.com/cli/latest/reference/ecs/start-task.html)` para executar uma tarefa autônoma do ECS em uma instância de contêiner específica. Esse comando não é aplicável às tarefas do Fargate.
+ `[create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html)` para criar um serviço do ECS.
+ `[update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html)` para atualizar um serviço existente.

**nota**  
Para que um contêiner na tarefa grave no volume montado do Amazon EBS, ele deve ter permissões apropriadas do sistema de arquivos. Quando você especifica um usuário não raiz em sua definição de contêiner, o Amazon ECS configura automaticamente o volume com permissões baseadas em grupo que permitem que o usuário especificado leia e grave no volume. Se nenhum usuário for especificado, o contêiner será executado como raiz e terá acesso total ao volume.

 Você também pode configurar um volume do Amazon EBS usando o Console de gerenciamento da AWS. Para obter mais informações, consulte [Execução de uma aplicação como uma tarefa do Amazon ECS](standalone-task-create.md), [Criação de uma implantação de atualização contínua do Amazon ECS](create-service-console-v2.md) e [Atualizar um serviço do Amazon ECS](update-service-console-v2.md).

O trecho JSON a seguir mostra todos os parâmetros de um volume do Amazon EBS que podem ser configurados na implantação. Para usar esses parâmetros na configuração de volume, substitua os `user input placeholders` por suas próprias informações. Para obter mais informações sobre esses parâmetros, consulte [Volume configurations](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html#sd-volumeConfigurations).

```
"volumeConfigurations": [
        {
            "name": "ebs-volume", 
            "managedEBSVolume": {
                "encrypted": true, 
                "kmsKeyId": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab", 
                "volumeType": "gp3", 
                "sizeInGiB": 10, 
                "snapshotId": "snap-12345", 
                "volumeInitializationRate":100,
                "iops": 3000, 
                "throughput": 125, 
                "tagSpecifications": [
                    {
                        "resourceType": "volume", 
                        "tags": [
                            {
                                "key": "key1", 
                                "value": "value1"
                            }
                        ], 
                        "propagateTags": "NONE"
                    }
                ], 
                "roleArn": "arn:aws:iam::1111222333:role/ecsInfrastructureRole", 
                 "terminationPolicy": {
                    "deleteOnTermination": true//can't be configured for service-managed tasks, always true 
                },
                "filesystemType": "ext4"
            }
        }
    ]
```

**Importante**  
Certifique-se de que o `volumeName` especificado na configuração seja o mesmo `volumeName` especificado na definição de tarefa.

Para obter informações sobre como verificar o status de anexação de volumes, consulte [Solução de problemas de anexações de volumes do Amazon EBS às tarefas do Amazon ECS](troubleshoot-ebs-volumes.md). Para obter informações sobre o perfil do AWS Identity and Access Management (IAM) na infraestrutura do Amazon ECS necessário para a anexação de volumes do EBS, consulte [Perfil do IAM de infraestrutura do Amazon ECS](infrastructure_IAM_role.md).

Veja a seguir exemplos de trechos JSON que mostram a configuração dos volumes do Amazon EBS. Esses exemplos podem ser usados salvando os trechos em arquivos JSON e passando os arquivos como parâmetros (usando o parâmetro `--cli-input-json file://filename`) para comandos da AWS CLI. Substitua `user input placeholders` por suas próprias informações.

## Configuração de um volume para uma tarefa autônoma
<a name="ebs-run-task"></a>

O trecho a seguir mostra a sintaxe para configurar volumes do Amazon EBS para anexação a uma tarefa autônoma. O trecho JSON a seguir mostra a sintaxe para definir as configurações de `volumeType`, `sizeInGiB`, `encrypted` e `kmsKeyId`. A configuração especificada no arquivo JSON é usada para criar e anexar um volume do EBS à tarefa autônoma.

```
{
   "cluster": "mycluster",
   "taskDefinition": "mytaskdef",
   "volumeConfigurations": [
        {
            "name": "datadir",
            "managedEBSVolume": {
                "volumeType": "gp3",
                "sizeInGiB": 100,
                "roleArn":"arn:aws:iam::1111222333:role/ecsInfrastructureRole",
                "encrypted": true,
                "kmsKeyId": "arn:aws:kms:region:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"
            }
        }
   ]
}
```

## Configuração de um volume na criação do serviço
<a name="ebs-create-service"></a>

O trecho a seguir mostra a sintaxe para configurar volumes do Amazon EBS para anexação a tarefas gerenciadas por um serviço. Os volumes são baseados no snapshot especificado usando o parâmetro `snapshotId` a uma taxa de 200 MiB/s. A configuração especificada no arquivo JSON é usada para criar e anexar um volume do EBS a cada tarefa gerenciada pelo serviço.

```
{
   "cluster": "mycluster",
   "taskDefinition": "mytaskdef",
   "serviceName": "mysvc",
   "desiredCount": 2,
   "volumeConfigurations": [
        {
            "name": "myEbsVolume",
            "managedEBSVolume": {
              "roleArn":"arn:aws:iam::1111222333:role/ecsInfrastructureRole",
              "snapshotId": "snap-12345",
              "volumeInitializationRate": 200
            }
        }
   ]
}
```

## Configuração de um volume na atualização do serviço
<a name="ebs-update-service"></a>

O trecho JSON a seguir mostra a sintaxe para atualizar um serviço que anteriormente não tinha volumes do Amazon EBS configurados para anexar a tarefas. Você deve fornecer o ARN de uma revisão de definição de tarefa com `configuredAtLaunch` definido como `true`. O trecho JSON a seguir mostra a sintaxe para definir `volumeType`, `sizeInGiB`, `throughput` e `iops` e as configurações de `filesystemType`. Essa configuração é usada para criar e anexar um volume do EBS a cada tarefa gerenciada pelo serviço.

```
{
   "cluster": "mycluster",
   "taskDefinition": "mytaskdef",
   "service": "mysvc",
   "desiredCount": 2,
   "volumeConfigurations": [
        {
            "name": "myEbsVolume",
            "managedEBSVolume": {
              "roleArn":"arn:aws:iam::1111222333:role/ecsInfrastructureRole",
               "volumeType": "gp3",
                "sizeInGiB": 100,
                 "iops": 3000, 
                "throughput": 125, 
                "filesystemType": "ext4"
            }
        }
   ]
}
```

### Configuração de um serviço para não utilizar mais os volumes do Amazon EBS
<a name="ebs-service-disable-ebs"></a>

O trecho JSON a seguir mostra a sintaxe para atualizar um serviço para não utilizar mais os volumes do Amazon EBS. Você deve fornecer o ARN de uma definição de tarefa com `configuredAtLaunch` definido como `false` ou de uma definição de tarefa sem o parâmetro `configuredAtLaunch`. Você também deve fornecer um objeto `volumeConfigurations` vazio.

```
{
   "cluster": "mycluster",
   "taskDefinition": "mytaskdef",
   "service": "mysvc",
   "desiredCount": 2,
   "volumeConfigurations": []
}
```

## Política de encerramento para volumes do Amazon EBS
<a name="ebs-volume-termination-policy"></a>

Quando uma tarefa do Amazon ECS é encerrada, o Amazon ECS usa o valor de `deleteOnTermination` para determinar se o volume do Amazon EBS associado à tarefa encerrada deve ser excluído. Por padrão, os volumes do EBS anexados às tarefas são excluídos quando a tarefa é encerrada. Em tarefas autônomas, você pode alterar essa configuração para preservar o volume após o encerramento da tarefa.

**nota**  
Os volumes anexados às tarefas gerenciadas por um serviço não são preservados e sempre são excluídos após o encerramento da tarefa.

## Tags em volumes do Amazon EBS
<a name="ebs-volume-tagging"></a>

Você pode marcar volumes do Amazon EBS usando o objeto `tagSpecifications`. Usando o objeto, você pode fornecer suas próprias tags e definir a propagação delas na definição da tarefa ou do serviço, dependendo se o volume está anexado a uma tarefa autônoma ou a uma tarefa em um serviço. O número máximo de tags que podem ser anexadas a um volume é 50.

**Importante**  
O Amazon ECS anexa automaticamente as tags reservadas `AmazonECSCreated` e `AmazonECSManaged` a um volume do Amazon EBS. Isso significa que você pode controlar a anexação de no máximo 48 tags adicionais a um volume. Essas tags adicionais podem ser definidas pelo usuário, gerenciadas pelo ECS ou propagadas.

Se quiser adicionar tags gerenciadas pelo Amazon ECS ao volume, você deve definir `enableECSManagedTags` como `true` na chamada de `UpdateService`, `CreateService`, `RunTask` ou `StartTask`. Se você ativar as tags gerenciadas pelo Amazon ECS, o Amazon ECS marca o volume automaticamente com informações de cluster e serviço (`aws:ecs:clusterName` e `aws:ecs:serviceName`). Para obter mais informações sobre marcação de recursos do Amazon ECS, consulte [Tagging your Amazon ECS resources](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html).

O trecho JSON a seguir mostra a sintaxe para marcar cada volume do Amazon EBS anexado a cada tarefa em um serviço com uma tag definida pelo usuário. Para usar esse exemplo para criar um serviço, substitua os `user input placeholders` pelas suas próprias informações.

```
{
   "cluster": "mycluster",
   "taskDefinition": "mytaskdef",
   "serviceName": "mysvc",
   "desiredCount": 2,
   "enableECSManagedTags": true,
   "volumeConfigurations": [
        {
            "name": "datadir",
            "managedEBSVolume": {
                "volumeType": "gp3",
                "sizeInGiB": 100,
                 "tagSpecifications": [
                    {
                        "resourceType": "volume", 
                        "tags": [
                            {
                                "key": "key1", 
                                "value": "value1"
                            }
                        ], 
                        "propagateTags": "NONE"
                    }
                ],
                "roleArn":"arn:aws:iam:1111222333:role/ecsInfrastructureRole",
                "encrypted": true,
                "kmsKeyId": "arn:aws:kms:region:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"
            }
        }
   ]
}
```

**Importante**  
Você deve especificar um tipo de recurso de `volume` para marcar os volumes do Amazon EBS.

# Desempenho de volumes do Amazon EBS para tarefas sob demanda do Fargate
<a name="ebs-fargate-performance-limits"></a>

As IOPS e o throughput básico de volume do Amazon EBS disponíveis para uma tarefa sob demanda do Fargate dependem do total de unidades de CPU solicitadas para a tarefa. Se você solicitar 0,25, 0,5 ou 1 unidade de CPU virtual (vCPU) para a tarefa do Fargate, recomendamos configurar um volume SSD de uso geral (`gp2` ou `gp3`) ou um volume de unidade de disco rígido (HDD) (`st1` ou `sc1`). Se você solicitar mais de 1 vCPU para a tarefa do Fargate, os limites básicos de desempenho a seguir se aplicam a um volume do Amazon EBS anexado à tarefa. Você pode obter temporariamente um desempenho do EBS superior aos limites a seguir. No entanto, é recomendável planejar a workload com base nesses limites.


| Unidades de CPU solicitadas (em vCPUs) | IOPS básicas do Amazon EBS (E/S de 16 KiB) | Throughput básico do Amazon EBS (em MiBps, E/S de 128 KiB) | Largura de banda básica (Mbps) | 
| --- | --- | --- | --- | 
| 2 | 3.000 | 75 | 360 | 
| 4 | 5.000 | 120 | 1.150 | 
| 8 | 10.000 | 250 | 2.300 | 
| 16 | 15.000 | 500 | 4,500 | 

**nota**  
 Ao configurar um volume do Amazon EBS para ser anexado a uma tarefa do Fargate, o limite de performance do Amazon EBS para a tarefa do Fargate é compartilhado entre o armazenamento temporário da tarefa e o volume anexado.

# Desempenho dos volumes do Amazon EBS para tarefas do EC2
<a name="ebs-fargate-performance-limits-ec2"></a>

O Amazon EBS fornece tipos de volume que diferem em características de performance e preço para que você possa adaptar o custo e a performance de armazenamento às necessidades das aplicações. Para obter informações sobre performance, incluindo IOPS por volume e throughput por volume, consulte [Tipos de volume do Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html) no *Guia do usuário do Amazon Elastic Block Store*.

# Performance de volumes do Amazon EBS para tarefas de instâncias gerenciadas do Amazon ECS
<a name="ebs-managed-instances-performance"></a>

O Amazon EBS fornece tipos de volume que diferem em características de performance e preço para que você possa adaptar o custo e a performance de armazenamento às necessidades das aplicações. Para obter informações sobre performance, incluindo IOPS por volume e throughput por volume, consulte [Tipos de volume do Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html) no *Guia do usuário do Amazon Elastic Block Store*.

# Solução de problemas de anexações de volumes do Amazon EBS às tarefas do Amazon ECS
<a name="troubleshoot-ebs-volumes"></a>

Talvez seja necessário solucionar problemas ou verificar a anexação dos volumes do Amazon EBS às tarefas do Amazon ECS.

## Verificação do status de anexação de volumes
<a name="troubleshoot-ebs-volumes-location"></a>

Você pode usar o Console de gerenciamento da AWS para visualizar o status de anexação de um volume do Amazon EBS a uma tarefa do Amazon ECS. Se a tarefa for iniciada e a anexação falhar, você também verá um motivo do status que pode ser usado para solucionar problemas. O volume criado será excluído e a tarefa será interrompida. Para obter mais informações sobre os motivos de status, consulte [Motivos do status para anexação do volume do Amazon EBS às tarefas do Amazon ECS](troubleshoot-ebs-volumes-scenarios.md).

**Para visualizar o status de anexação e o motivo do status de um volume usando o console**

1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Na página **Clusters**, escolha o cluster em que a tarefa está sendo executada. A página de detalhes do cluster é exibida.

1. Na página de detalhes do cluster, escolha a guia **Tarefas**.

1. Escolha a tarefa cujo status de anexação de volumes você deseja visualizar. Talvez seja necessário usar **Filtrar o status desejado** e escolher **Interrompida** se a tarefa que você deseja examinar tiver sido interrompida.

1. Na página de detalhes da tarefa, escolha a guia **Volumes**. Você poderá ver o status de anexação do volume do Amazon EBS em **Status do anexo**. Se o volume apresentar falhas ao ser anexado à tarefa, você poderá escolher o status em **Status do anexo** para exibir a causa da falha.

Você também pode visualizar o status de anexação de volumes de uma tarefa e o motivo associado do status usando a API [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html).

## Falhas de serviço e tarefas
<a name="service-task-failures"></a>

Você pode encontrar falhas em serviços ou tarefas que não são específicas dos volumes do Amazon EBS e que podem afetar a anexação do volume. Para obter mais informações, consulte
+ [Mensagens de evento de serviço](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-event-messages.html)
+ [Códigos de erro de tarefas interrompidas](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/stopped-task-error-codes.html)
+ [Motivos de falha da API](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/api_failures_messages.html)

# O contêiner não pode gravar no volume do Amazon EBS
<a name="troubleshoot-non-root-container"></a>

Usuário não root sem as permissões corretas  
Quando você especifica um usuário não raiz em sua definição de contêiner, o Amazon ECS configura automaticamente o volume com permissões baseadas em grupo que permitem o acesso de gravação. No entanto, se você ainda estiver enfrentando problemas de permissão:  
+ Verifique se o parâmetro `user` está especificado corretamente na definição de contêiner usando o formato `uid:gid` (por exemplo,`1001:1001`).
+ Certifique-se de que a imagem do contêiner não substitua as permissões do usuário após a montagem do volume.
+ Verifique se sua aplicação está sendo executada com o ID de usuário esperado examinando os logs do contêiner ou usando o Amazon ECS Exec para inspecionar o contêiner em execução.

Usuário-root com problemas de permissão  
Se nenhum usuário for especificado em sua definição de contêiner, o contêiner será executado como raiz e deverá ter acesso total ao volume. Se você estiver enfrentando problemas:  
+ Verifique se o volume está montado corretamente conferindo os pontos de montagem dentro do contêiner.
+ Garanta que volume não esteja configurado como somente leitura na configuração de ponto de montagem.

Tarefas de vários contêineres com diferentes usuários  
Em tarefas com vários contêineres sendo executados como usuários diferentes, o Amazon ECS gerencia automaticamente as permissões de grupo para permitir que todos os usuários especificados gravem no volume. Se os contêineres não puderem gravar:  
+ Verifique se todos os contêineres que exigem acesso de gravação têm o parâmetro `user` configurado corretamente.
+ Verifique se o volume está montado em todos os contêineres que precisam acessá-lo.

Para obter mais informações sobre como configurar usuários em definições de contêiner, consulte [ Parâmetros de definição de tarefa do Amazon ECS para o Fargate ](https://docs.aws.amazon.com/./task_definition_parameters.html). 

# Motivos do status para anexação do volume do Amazon EBS às tarefas do Amazon ECS
<a name="troubleshoot-ebs-volumes-scenarios"></a>

Use a referência a seguir para corrigir problemas que você possa encontrar na forma de motivos de status no Console de gerenciamento da AWS ao configurar volumes do Amazon EBS para anexação às tarefas do Amazon ECS. Para obter mais informações sobre como localizar esses motivos de status no console, consulte [Verificação do status de anexação de volumes](troubleshoot-ebs-volumes.md#troubleshoot-ebs-volumes-location).

O ECS não conseguiu assumir o perfil de infraestrutura do ECS configurado 'arn:aws:iam::*111122223333*:role/*ecsInfrastructureRole*'. Verifique se o perfil que está sendo passado tem a relação de confiança adequada com o Amazon ECS  
Esse motivo de status aparece nos cenários a seguir.  
+  Você fornece um perfil do IAM sem a política de confiança necessária anexada. O Amazon ECS não poderá acessar o perfil do IAM de infraestrutura do Amazon ECS fornecida se o perfil não tiver a política de confiança necessária. A tarefa pode ficar presa no estado `DEPROVISIONING`. Para obter mais informações sobre a política de confiança necessária, consulte [Perfil do IAM de infraestrutura do Amazon ECS](infrastructure_IAM_role.md).
+ O usuário do IAM não tem permissão para passar o perfil de infraestrutura do Amazon ECS para o Amazon ECS. A tarefa pode ficar presa no estado `DEPROVISIONING`. Para evitar esse problema, você pode anexar a permissão `PassRole` ao usuário. Para obter mais informações, consulte [Perfil do IAM de infraestrutura do Amazon ECS](infrastructure_IAM_role.md).
+ O perfil do IAM não tem as permissões necessárias para anexação de volumes do Amazon EBS. A tarefa pode ficar presa no estado `DEPROVISIONING`. Para obter mais informações sobre as permissões específicas necessárias para anexação de volumes do Amazon EBS às tarefas, consulte [Perfil do IAM de infraestrutura do Amazon ECS](infrastructure_IAM_role.md).
Você também pode ver essa mensagem de erro devido a um atraso na propagação do perfil. Se tentar usar o perfil novamente depois de esperar alguns minutos não resolver o problema, você pode ter configurado incorretamente a política de confiança do perfil.

O ECS não conseguiu configurar o volume do EBS. IdempotentParameterMismatch” encontrado; “O token do cliente que você forneceu está associado a um recurso que já foi excluído. Use um token de cliente diferente."  
Os seguintes cenários envolvendo a chave do AWS KMS podem fazer com que uma mensagem de `IdempotentParameterMismatch` apareça:  
+ Você especifica um ARN, ID ou alias da chave do KMS que não é válido. Nesse cenário, a tarefa pode parecer ter sido executada com êxito, mas ela falhará, porque a AWS autentica a chave do KMS de forma assíncrona. Para obter mais informações, consulte [Amazon EBS encryption](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html) no *Guia do usuário do Amazon EC2*.
+ Você fornece uma chave gerenciada pelo cliente sem as permissões para que o perfil do IAM de infraestrutura do Amazon ECS use a chave para criptografia. Para evitar problemas na permissão da política de chave, consulte o exemplo política de chave do AWS KMS em [Data encryption for Amazon EBS volumes](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ebs-volumes.html#ebs-kms-encryption).
Você pode configurar o Amazon EventBridge para enviar eventos de volumes do Amazon EBS e eventos de alteração do estado de tarefas do Amazon ECS para um destino, como grupos do Amazon CloudWatch. Em seguida, você pode usar esses eventos para identificar o problema específico relacionado à chave gerenciada pelo cliente que afetou a anexação do volume. Para obter mais informações, consulte  
+  [Como posso criar um grupo de logs do CloudWatch para usar como destino para uma regra do EventBridge?](https://repost.aws/knowledge-center/cloudwatch-log-group-eventbridge) no AWS re:Post.
+ [Task state change events](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html#ecs_task_events).
+ [Eventos do Amazon EventBridge para Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-cloud-watch-events.html) no *Guia do usuário do Amazon EBS*.

O ECS atingiu o tempo limite ao configurar a anexação de volumes do EBS à tarefa.  
Os cenários a seguir, relacionados ao formato do sistema de arquivos, resultam nessa mensagem.  
+ O formato do sistema de arquivos que você especifica durante a configuração não é compatível com o [sistema operacional da tarefa](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RuntimePlatform.html).
+ Você configura um volume do Amazon EBS para ser criado de um snapshot, e o formato do sistema de arquivos do snapshot não é compatível com o sistema operacional da tarefa. Em volumes criados de um snapshot, você deve especificar o mesmo tipo de sistema de arquivos que o volume estava usando quando o snapshot foi criado.
Você pode utilizar os logs do agente de contêiner do Amazon ECS para solucionar essa mensagem em tarefas EC2. Para obter mais informações, consulte [Amazon ECS log file locations](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/logs.html) e [Amazon ECS log collector](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-logs-collector.html).

# Uso de volumes do Amazon EFS com o Amazon ECS
<a name="efs-volumes"></a>

O Amazon Elastic File System (Amazon EFS) oferece armazenamento simples e escalável de arquivos para uso com tarefas do Amazon ECS. Com o Amazon EFS, a capacidade de armazenamento é elástica. Ela aumenta e diminui automaticamente à medida que arquivos são adicionados e removidos. Suas aplicações poderão ter o armazenamento que precisarem e quando precisarem.

Use os sistemas de arquivos do Amazon EFS com o Amazon ECS para exportar dados do sistema de arquivos em sua frota de instâncias de contêiner. Desse modo, suas tarefas terão acesso ao mesmo armazenamento persistente, não importa a instância em que estejam. Suas definições de tarefa devem fazer referências a montagens de volume na instância de contêiner para usar o sistema de arquivos.

Para ver um tutorial, consulte [Configurar os sistemas de arquivos do Amazon EFS para o Amazon ECS usando o console](tutorial-efs-volumes.md).

## Considerações
<a name="efs-volume-considerations"></a>

 Considere o seguinte ao usar volumes do Amazon EFS:
+ Para tarefas executadas no EC2, o suporte do sistema de arquivos do Amazon EFS foi adicionado como visualização prévia pública com a versão `20191212` da AMI otimizada para o Amazon ECS com a versão 1.35.0 do agente de contêiner. No entanto, o suporte ao sistema de arquivos do Amazon EFS se tornou disponível para o público com a versão `20200319` da AMI otimizada para Amazon ECS com a versão 1.38.0 do agente de contêiner, que continha os recursos de ponto de acesso do Amazon EFS e de autorização do IAM. Recomendamos o uso da versão `20200319` ou posterior da AMI otimizada para Amazon ECS ou posterior para usar esses recursos. Para obter mais informações, consulte [AMIs do Linux otimizadas para o Amazon ECS](ecs-optimized_AMI.md).
**nota**  
Se você criar sua própria AMI, deverá usar o agente de contêiner 1.38.0 ou posterior, `ecs-init` versão 1.38.0-1 ou posterior e executar os comandos a seguir na instância do Amazon EC2 para habilitar o plug-in de volume do Amazon ECS. Os comandos dependem de você estar usando o Amazon Linux 2 ou o Amazon Linux como imagem base.  
Amazon Linux 2  

  ```
  yum install amazon-efs-utils
  systemctl enable --now amazon-ecs-volume-plugin
  ```
Amazon Linux  

  ```
  yum install amazon-efs-utils
  sudo shutdown -r now
  ```
+ Para tarefas hospedadas no Fargate, os sistemas de arquivos do Amazon EFS são compatíveis com a versão 1.4.0 ou posterior (Linux) da plataforma. Para obter mais informações, consulte [Versões da plataforma do Fargate para o Amazon ECS](platform-fargate.md).
+ Ao usar volumes do Amazon EFS para tarefas hospedadas no Fargate, o Fargate cria um contêiner do supervisor responsável pelo gerenciamento do volume do Amazon EFS. O contêiner do supervisor usa uma pequena quantidade de memória da tarefa e CPU. O contêiner supervisor fica visível ao consultar a versão 4 do endpoint de metadados de tarefa. Além disso, ele é visível no CloudWatch Container Insights como o nome de contêiner `aws-fargate-supervisor`. Para obter mais informações ao usar o EC2, consulte [Endpoint de metadados de tarefas do Amazon ECS versão 4](task-metadata-endpoint-v4.md). Para obter mais informações ao usar o Fargate, consulte [Endpoint de metadados de tarefas do Amazon ECS versão 4 para tarefas no Fargate](task-metadata-endpoint-v4-fargate.md).
+ Não há suporte para o uso de volumes do Amazon EFS ou a especificação de um `EFSVolumeConfiguration` em instâncias externas.
+ O uso de volumes do Amazon EFS é compatível com tarefas executadas em instâncias gerenciadas do Amazon ECS.
+ Recomendamos que você defina o parâmetro `ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION` no arquivo de configuração do agente como um valor menor do que o padrão (cerca de 1 hora). Essa alteração ajuda a evitar a expiração da credencial de montagem do EFS e permite limpar as montagens que não estão em uso.  Para obter mais informações, consulte [Configuração do agente de contêiner do Amazon ECS](ecs-agent-config.md).

## Uso dos pontos de acesso do Amazon EFS
<a name="efs-volume-accesspoints"></a>

Os pontos de acesso do Amazon EFS são pontos de entrada específicos da aplicação para um sistema de arquivos do EFS para gerenciar o acesso de aplicações a conjuntos de dados compartilhados. Para obter mais informações sobre pontos de acesso do Amazon EFS e como controlar o acesso a eles, consulte [Trabalhar com pontos de acesso do Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html) no *Guia do usuário do Amazon Elastic File System*.

Os pontos de acesso podem impor uma identidade de usuário, inclusive grupos POSIX do usuário, para todas as solicitações do sistema de arquivamento feitas por meio do ponto de acesso. Pontos de acesso também podem impor um diretório raiz distinto para o sistema de arquivos. Isso é feito para que os clientes apenas possam acessar dados no diretório definido ou em seus subdiretórios.

**nota**  
Ao criar um ponto de acesso do EFS, você especifica um caminho no sistema de arquivos para servir como o diretório raiz. Ao fazer referência ao sistema de arquivos do EFS com um ID de ponto de acesso em sua definição de tarefa do Amazon ECS, o diretório raiz deve ser omitido ou definido como `/`, o que impõe o caminho definido no ponto de acesso do EFS.

É possível usar uma função do IAM da tarefa do Amazon ECS para obrigar que aplicações específicas usem um ponto de acesso específico. Ao combinar políticas do IAM com pontos de acesso, você pode fornecer facilmente acesso seguro a conjuntos de dados específicos para as suas aplicações. Para obter mais informações sobre como usar perfis do IAM de tarefa, consulte [Perfil do IAM para tarefas do Amazon ECS](task-iam-roles.md).

# Práticas recomendadas para usar volumes do Amazon EFS com o Amazon ECS
<a name="efs-best-practices"></a>

Anote as práticas recomendadas a seguir ao usar o Amazon EFS com o Amazon ECS.

## Controles de segurança e acesso para volumes do Amazon EFS
<a name="storage-efs-security"></a>

O Amazon EFS oferece recursos de controle de acesso para garantir que os dados armazenados em um sistema de arquivos do Amazon EFS estejam seguros e acessíveis somente em aplicações que precisam deles. Você pode proteger os dados habilitando a criptografia em repouso e em trânsito. Para obter mais informações, consulte [Criptografia de dados no Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html) no *Manual do usuário do Amazon Elastic File System*.

Além da criptografia de dados, você pode usar o Amazon EFS para restringir o acesso a um sistema de arquivos. Há três maneiras de implementar o controle de acesso no EFS.
+ **Grupos de segurança**: com os destinos de montagem do Amazon EFS, você pode configurar um grupo de segurança usado para permitir e negar tráfego de rede. É possível configurar o grupo de segurança anexado ao Amazon EFS para permitir o tráfego do NFS (porta 2049) do grupo de segurança que está conectado às instâncias do Amazon ECS ou, ao usar o modo de rede `awsvpc`, da tarefa do Amazon ECS.
+ **IAM**: você pode restringir o acesso a um sistema de arquivos do Amazon EFS usando o IAM. Quando configuradas, as tarefas do Amazon ECS exigem um perfil do IAM para acessar o sistema de arquivos e montar um sistema de arquivos do EFS. Para obter mais informações, consulte [Usar o IAM para controlar o acesso de dados do system de arquivos](https://docs.aws.amazon.com/efs/latest/ug/iam-access-control-nfs-efs.html) no *Guia do usuário do Amazon Elastic File System*.

  As políticas do IAM também podem impor condições predefinidas, como exigir que um cliente use TLS ao se conectar a um sistema de arquivos do Amazon EFS. Para obter mais informações, consulte [Amazon EFS condition keys for clients](https://docs.aws.amazon.com/efs/latest/ug/iam-access-control-nfs-efs.html#efs-condition-keys-for-nfs) no *Guia do usuário do Amazon Elastic File System*.
+ **Pontos de acesso do Amazon EFS**: os pontos de acesso do Amazon EFS são pontos de entrada específicos da aplicação em um sistema de arquivos do Amazon EFS. Você pode usar os pontos de acesso para impor uma identidade de usuário, incluindo grupos POSIX do usuário, a todas as solicitações do sistema de arquivos feitas por meio do ponto de acesso. Pontos de acesso também podem impor um diretório raiz distinto para o sistema de arquivos. Isso é feito para que os clientes só possam acessar dados no diretório especificado ou em seus subdiretórios.

### Políticas do IAM
<a name="storage-efs-security-iam"></a>

É posssível usar políticas do IAM para controlar o acesso ao sistema de arquivos do Amazon EFS.

É possível especificar as ações a seguir para clientes NFS em um sistema de arquivos usando uma política de sistema de arquivos.


| Ação | Descrição | 
| --- | --- | 
|  `elasticfilesystem:ClientMount`  |  Fornece acesso somente leitura a um sistema de arquivos para um cliente NFS.  | 
|  `elasticfilesystem:ClientWrite`  |  Fornece permissões de gravação em um sistema de arquivos.  | 
|  `elasticfilesystem:ClientRootAccess`  |  Fornece o uso do usuário raiz ao acessar um sistema de arquivos.  | 

Você precisa especificar cada ação em uma política. É possível definir políticas das seguintes maneiras:
+ Baseada no cliente: anexe a política ao perfil da tarefa

  Defina a opção **Autorização do IAM** ao criar a definição da tarefa. 
+ Baseada em recursos: anexe a política ao sistema de arquivos do Amazon EFS

  Se a política baseada em recursos não existir, por padrão, na criação do sistema de arquivos, o acesso será concedido a todas as entidades principais (\$1). 

Quando você define a opção **Autorização do IAM**, mesclamos a política associada ao perfil da tarefa e a baseada em recursos do Amazon EFS. A opção **Autorização do IAM** passa a identidade da tarefa (o perfil da tarefa) com a política para o Amazon EFS. Isso permite que a política baseada em recursos do Amazon EFS tenha contexto para o usuário ou perfil do IAM especificado na política. Se você não definir a opção, a política em nível de recurso do Amazon EFS identificará o usuário do IAM como "anônimo".

Considere implementar todos os três controles de acesso em um sistema de arquivos do Amazon EFS para obter segurança máxima. Por exemplo, você pode configurar o grupo de segurança anexado a um ponto de montagem do Amazon EFS para permitir somente a entrada de tráfego do NFS de um grupo de segurança associado à instância de contêiner ou tarefa do Amazon ECS. Além disso, você pode configurar o Amazon EFS para exigir um perfil do IAM para acessar o sistema de arquivos, mesmo que a conexão seja originada de um grupo de segurança permitido. Por último, você pode usar os pontos de acesso do Amazon EFS para impor permissões de usuário POSIX e especificar diretórios raiz para aplicações.

O trecho de definição de tarefa a seguir mostra como montar um sistema de arquivos do Amazon EFS usando um ponto de acesso.

```
"volumes": [
    {
      "efsVolumeConfiguration": {
        "fileSystemId": "fs-1234",
        "authorizationConfig": {
          "accessPointId": "fsap-1234",
          "iam": "ENABLED"
        },
        "transitEncryption": "ENABLED",
        "rootDirectory": ""
      },
      "name": "my-filesystem"
    }
]
```

## Performance de volumes do Amazon EFS
<a name="storage-efs-performance"></a>

O Amazon EFS oferece dois modos de desempenho: uso geral e E/S máxima. O uso geral é adequado para aplicações sensíveis à latência, como sistemas de gerenciamento de conteúdo e ferramentas de CI/CD. Por outro lado, os sistemas de arquivos com E/S máxima são adequados para workloads como data analytics, processamento de mídia e machine learning. Essas workloads precisam realizar operações paralelas de centenas ou até milhares de contêineres e exigem o maior throughput agregado e IOPS possíveis. Para obter mais informações, consulte [Amazon EFS performance modes](https://docs.aws.amazon.com/efs/latest/ug/performance.html#performancemodes) no *Guia do usuário do Amazon Elastic File System*.

Algumas workloads sensíveis à latência exigem os níveis mais altos de E/S fornecidos pelo modo de desempenho de E/S máxima e a latência mais baixa fornecida pelo modo de desempenho de uso geral. Para esse tipo de workload, recomendamos a criação de vários sistemas de arquivos do modo de desempenho de uso geral. Nesse caso, recomendamos distribuir a workload da aplicação em todos esses sistemas de arquivos, desde que a workload e as aplicações possam oferecer suporte a ela.

## Throughput dos volumes do Amazon EFS
<a name="storage-efs-performance-throughput"></a>

Todos os sistemas de arquivos do Amazon EFS têm um throughput associado medido, determinado pela quantidade de throughput provisionado para sistemas de arquivos que usam *Throughput provisionado* ou pela quantidade de dados armazenados na classe de armazenamento EFS Standard ou One Zone para sistemas de arquivos que usam *Throughput intermitente*. Para obter mais informações, consulte [Understanding metered throughput](https://docs.aws.amazon.com/efs/latest/ug/performance.html#read-write-throughput) no *Guia do usuário do Amazon Elastic File System*.

O modo de throughput padrão dos sistemas de arquivos do Amazon EFS é o modo intermitente. Com o modo intermitente, o throughput disponível para um sistema de arquivos aumenta ou reduz a escala verticalmente à medida que o sistema de arquivos cresce. Como workloads baseadas em arquivos costumam apresentar picos, exigindo altos níveis de throughput por um tempo e níveis mais baixos de throughput no restante, o Amazon EFS foi criado para intermitência, permitindo altos níveis de throughput por alguns períodos. Além disso, como várias workloads exigem muita leitura, as operações de leitura são medidas na proporção de 1:3 em relação a outras operações de NFS (como gravação). 

Todos os sistemas de arquivos do Amazon EFS oferecem um desempenho básico consistente de 50 MB/s para cada TB de armazenamento no Amazon EFS Standard ou Amazon EFS One Zone. Todos os sistemas de arquivos (independentemente do tamanho) podem gerar intermitências a 100 MiB/s. Sistemas de arquivos com mais de 1 TB de armazenamento EFS Standard ou EFS One Zone podem gerar intermitência a 100 MB/s para cada TB. Como as operações de leitura são medidas na proporção de 1:3, você pode gerar até 300 MiBs/s para cada TiB de throughput de leitura. Conforme você adiciona dados ao sistema de arquivos, o throughput máximo disponível para ele é escalado de forma linear e automática com seu armazenamento na classe Amazon EFS Standard. Se precisar de mais throughput do que pode obter com a quantidade de dados armazenados, você pode configurar o throughput provisionado de acordo com a quantidade específica que a workload exige.

O throughput do sistema de arquivos é compartilhado por todas as instâncias do Amazon EC2 conectadas a um sistema de arquivos. Por exemplo, um sistema de arquivos de 1 TB que atinge intermitência a 100 MB/s de throughput pode gerar 100 MB/s de uma única instância do Amazon EC2, cada uma com 10 MB/s. Para obter mais informações, consulte [Modos de performance](https://docs.aws.amazon.com/efs/latest/ug/performance.html) no *Guia do usuário do Amazon Elastic File System*.

## Otimização de custos para volumes do Amazon EFS
<a name="storage-efs-costopt"></a>

O Amazon EFS simplifica o ajuste de escala do armazenamento para você. Os sistemas de arquivos do Amazon EFS crescem automaticamente à medida que você adiciona mais dados. Principalmente com o modo *Throughput intermitente* do Amazon EFS, o throughput no Amazon EFS escala à medida que o tamanho do sistema de arquivos na classe de armazenamento padrão aumenta. Para melhorar o throughput sem pagar um custo adicional pelo throughput provisionado em um sistema de arquivos do EFS, você pode compartilhar um sistema de arquivos do Amazon EFS com várias aplicações. Usando pontos de acesso do Amazon EFS, você pode implementar o isolamento de armazenamento em sistemas de arquivos compartilhados do Amazon EFS. Ao fazer isso, mesmo que as aplicações ainda compartilhem o mesmo sistema de arquivos, elas não podem acessar os dados a menos que você as autorize.

À medida que os dados crescem, o Amazon EFS ajuda você a mover automaticamente arquivos acessados com pouca frequência para uma classe de armazenamento inferior. A classe de armazenamento Amazon EFS Standard-Infrequent Access (IA) reduz os custos de armazenamento de arquivos que não são acessados todos os dias. O EFS faz isso sem sacrificar a alta disponibilidade, a alta durabilidade, a elasticidade e o acesso ao sistema de arquivos POSIX que o Amazon EFS fornece. Para obter mais informações, consulte [Classes de armazenamento do Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/features.html) no *Guia do usuário do Amazon Elastic File System*.

Considere usar as políticas de ciclo de vida do Amazon EFS para economizar dinheiro transferindo automaticamente arquivos acessados com pouca frequência para o armazenamento Amazon EFS IA. Para obter mais informações, consulte [Amazon EFS lifecycle management](https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html) (Gerenciamento de ciclo de vida do Amazon EFS) no *Guia do usuário do Amazon Elastic File System*.

Ao criar um sistema de arquivos do Amazon EFS, você pode escolher se o Amazon EFS replica seus dados em várias zonas de disponibilidade (padrão) ou os armazena de forma redundante em uma única zona de disponibilidade. A classe de armazenamento Amazon EFS One Zone pode reduzir os custos de armazenamento em uma margem significativa em comparação com as classes de armazenamento Amazon EFS Standard. Considere usar a classe de armazenamento Amazon EFS One Zone para workloads que não exigem resiliência Multi-AZ. Você pode reduzir ainda mais o custo do armazenamento Amazon EFS One Zone transferindo arquivos acessados com pouca frequência para o Amazon EFS One Zone-Infrequent Access. Para obter mais informações, consulte o [Amazon EFS Infrequent Access](https://aws.amazon.com/efs/features/infrequent-access/).

## Proteção de dados de volume do Amazon EFS
<a name="storage-efs-dataprotection"></a>

O Amazon EFS armazena os dados de forma redundante em várias zonas de disponibilidade em sistemas de arquivos que usam classes de armazenamento padrão. Ao selecionar as classes de armazenamento Amazon EFS One Zone, seus dados são armazenados de forma redundante em uma única zona de disponibilidade. Além disso, o Amazon EFS foi projetado para fornecer 99,999999999% (11 noves) de durabilidade em um determinado ano.

Como em qualquer ambiente, é uma prática recomendada ter um backup e criar proteções contra a exclusão acidental. Para dados do Amazon EFS, essa prática recomendada inclui um backup funcional e testado regularmente usando o AWS Backup. Os sistemas de arquivos que usam as classes de armazenamento Amazon EFS One Zone são configurados para fazer backup automático dos arquivos por padrão na criação do sistema de arquivos, a menos que você desabilite essa funcionalidade. Para obter mais informações, consulte [Backup de sistemas de arquivos EFS](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html) no *Guia do usuário do Amazon Elastic File System*.

# Especificar um sistema de arquivos do Amazon EFS na definição de tarefa do Amazon ECS
<a name="specify-efs-config"></a>

Para usar volumes do sistema de arquivos do Amazon EFS para seus contêineres, você deve especificar as configurações de volume e ponto de montagem na definição de tarefa. O trecho JSON de definição de tarefa a seguir mostra a sintaxe para os objetos `volumes` e `mountPoints` de um contêiner.

```
{
    "containerDefinitions": [
        {
            "name": "container-using-efs",
            "image": "public.ecr.aws/amazonlinux/amazonlinux:latest",
            "entryPoint": [
                "sh",
                "-c"
            ],
            "command": [
                "ls -la /mount/efs"
            ],
            "mountPoints": [
                {
                    "sourceVolume": "myEfsVolume",
                    "containerPath": "/mount/efs",
                    "readOnly": true
                }
            ]
        }
    ],
    "volumes": [
        {
            "name": "myEfsVolume",
            "efsVolumeConfiguration": {
                "fileSystemId": "fs-1234",
                "rootDirectory": "/path/to/my/data",
                "transitEncryption": "ENABLED",
                "transitEncryptionPort": integer,
                "authorizationConfig": {
                    "accessPointId": "fsap-1234",
                    "iam": "ENABLED"
                }
            }
        }
    ]
}
```

`efsVolumeConfiguration`  
Tipo: Objeto  
Obrigatório: não  
Esse parâmetro é especificado quando volumes Amazon EFS são usados.    
`fileSystemId`  
Tipo: String  
Exigido: sim  
A ID do sistema de arquivamento Amazon EFS a ser usada.  
`rootDirectory`  
Tipo: string  
Obrigatório: Não  
O diretório dentro do sistema de arquivamento Amazon EFS a ser montado como diretório raiz dentro do host. Caso esse parâmetro seja omitido, a raiz do volume Amazon EFS será usada. Especificar `/` tem o mesmo efeito que omitir esse parâmetro.  
Se um ponto de acesso do EFS for especificado no `authorizationConfig`, o parâmetro do diretório raiz deverá ser omitido ou definido como `/`, o que imporá o caminho definido no ponto de acesso do EFS.  
`transitEncryption`  
Tipo: string  
Valores válidos: `ENABLED` \$1 `DISABLED`  
Obrigatório: não  
Especifica se a criptografia deve ou não ser habilitada para dados do Amazon EFS em trânsito entre o host do Amazon ECS e o servidor do Amazon EFS. A criptografia de trânsito deverá ser habilitada se a autorização do IAM do Amazon EFS for usada. Se o parâmetro for omitido, o valor padrão `DISABLED` será usado. Para obter mais informações, consulte [Criptografar dados em trânsito](https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html) no *Guia do usuário do Amazon Elastic File System*.  
`transitEncryptionPort`  
Tipo: inteiro  
Obrigatório: não  
A porta a ser usada ao enviar dados criptografados entre o host do Amazon ECS e o servidor do Amazon EFS. Se você não especificar uma porta de criptografia em trânsito, será usada a estratégia de seleção de porta usada pelo assistente de montagem do Amazon EFS. Para mais informações, consulte [Auxiliar de Montagem EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-mount-helper.html) no *Guia de Usuário Amazon Elastic File System*.  
`authorizationConfig`  
Tipo: Objeto  
Obrigatório: Não  
Detalhes de configuração de autorização do sistema de arquivamento Amazon EFS.    
`accessPointId`  
Tipo: Sequência  
Obrigatório: não  
ID do ponto de acesso a ser usado. Se um ponto de acesso for especificado, o valor do diretório raiz no `efsVolumeConfiguration` deve ser omitido ou definido como `/`, que impõe o caminho definido no ponto de acesso do EFS. Se um ponto de acesso for usado, a criptografia em trânsito deverá ser habilitada em `EFSVolumeConfiguration`. Para mais informações, consulte [Trabalhando com Pontos de Acesso Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html) no *Guia de Usuário Amazon Elastic File System*.  
`iam`  
Tipo: string  
Valores válidos: `ENABLED` \$1 `DISABLED`  
Obrigatório: não  
 Especifica se é necessário ou não usar o perfil do IAM para a tarefa do Amazon ECS estabelecida em uma definição de tarefa ao montar o sistema de arquivos do Amazon EFS. Em caso positivo, a criptografia de trânsito deve estar habilitada em `EFSVolumeConfiguration`. Se o parâmetro for omitido, o valor padrão `DISABLED` será usado. Para obter mais informações, consulte [Funções do IAM para tarefas](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html).

# Configurar os sistemas de arquivos do Amazon EFS para o Amazon ECS usando o console
<a name="tutorial-efs-volumes"></a>

Saiba como usar os sistemas de arquivos do Amazon Elastic File System (Amazon EFS) com o Amazon ECS.

## Etapa 1: criar um cluster do Amazon ECS
<a name="efs-create-cluster"></a>

Use as etapas a seguir para criar um cluster do Amazon ECS. 

**Para criar um novo cluster (console do Amazon ECS)**

Antes de começar, atribua a permissão apropriada do IAM. Para obter mais informações, consulte [Exemplos de clusters do Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies).

1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Na barra de navegação, selecione a Região a ser usada.

1. No painel de navegação, escolha **Clusters**.

1. Na página **Clusters**, escolha **Create Cluster** (Criar cluster).

1. Em **Configuração do cluster**, em **Nome do cluster**, insira `EFS-tutorial` para o nome do cluster.

1. (Opcional) Para alterar a VPC e as sub-redes onde suas tarefas e serviços são iniciados, em **Networking** (Redes), execute qualquer uma das operações a seguir:
   + Para remover uma sub-rede, em **Subnets** (Sub-redes), escolha **X** para cada sub-rede que você deseja remover.
   + Para alterar para uma VPC diferente do **padrão**, em **VPC**, escolha uma **VPC** existente e depois, em **Sub-redes**, selecione cada sub-rede.

1.  Para adicionar instâncias do Amazon EC2 ao seu cluster, expanda **Infraestrutura** e selecione **Instâncias do Amazon EC2**. Em seguida, configure o grupo do Auto Scaling que atua como o provedor de capacidade:

   1. Para criar um grupo do Auto Scaling, a partir de **Auto Scaling group (ASG)** (Grupo do Auto Scaling (ASG)), selecione **Create new group** (Criar novo grupo) e, em seguida, forneça os seguintes detalhes sobre o grupo:
     + Em **Sistema/arquitetura operacional**, escolha Amazon Linux 2.
     + Em **EC2 instance type (Tipo de instância do EC2)**, escolha `t2.micro`.

        Em **SSH key pair** (Par de chaves de SSH), escolha o par que prova sua identidade quando você se conecta à instância.
     + Em **Capacidade**, insira `1`.

1. Escolha **Criar**.

## Etapa 2: criar um grupo de segurança para instâncias do Amazon EC2 e o sistema de arquivos Amazon EFS
<a name="efs-security-group"></a>

Nesta etapa, você criará um grupo de segurança para suas instâncias do Amazon EC2 que permite tráfego de rede de entrada na porta 80 e seu sistema de arquivos Amazon EFS que permite o acesso de entrada das suas instâncias de contêiner. 

Crie um grupo de segurança para suas instâncias do Amazon EC2 com as opções a seguir:
+ **Nome do grupo de segurança**: um nome exclusivo para seu grupo de segurança.
+ **VP**: a VPC identificada anteriormente para o cluster.
+ **Regra de entrada**
  + **Tipo**: **HTTP**
  + **Origem** - **0.0.0.0/0**.

Crie um grupo de segurança seu sistema de arquivos Amazon EFS com as opções a seguir:
+ **Nome do grupo de segurança**: um nome exclusivo para seu grupo de segurança. Por exemplo, `EFS-access-for-sg-dc025fa2`.
+ **VP**: a VPC identificada anteriormente para o cluster.
+ **Regra de entrada**
  + **Tipo**: **NFS**
  + **Origem**: **Personalizada** com o ID do grupo de segurança que você criou para suas instâncias.

Para obter informações sobre como criar um grupo de segurança, consulte [Criar um grupo de segurança para sua instância do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-security-group.html) no *Guia do usuário do Amazon EC2*.

## Etapa 3: criar um sistema de arquivos do Amazon EFS
<a name="efs-create-filesystem"></a>

Nesta etapa, você cria um sistema de arquivos do Amazon EFS.

**Para criar um sistema de arquivos do Amazon EFS para tarefas do Amazon ECS.**

1. Abra o console do Amazon Elastic File System em [https://console.aws.amazon.com/efs/](https://console.aws.amazon.com/efs/).

1. Escolha **Create file system (Criar sistema de arquivos)**.

1. Insira um nome para seu sistema de arquivos e escolha a VPC na qual suas instâncias de contêiner estão hospedadas. Por padrão, cada sub-rede na VPC especificada recebe um destino de montagem que usa o grupo de segurança padrão para essa VPC. Em seguida, escolha **Personalizar**.
**nota**  
Este tutorial pressupõe que o sistema de arquivos do Amazon EFS, o cluster do Amazon ECS, as instâncias de contêiner e as tarefas estejam na mesma VPC. Para obter mais informações sobre a montagem de um sistema de arquivos em uma VPC diferente, consulte [Walkthrough: Mount a file system from a different VPC](https://docs.aws.amazon.com/efs/latest/ug/efs-different-vpc.html) no *Guia do usuário do Amazon EFS*.

1. Na página **Configurações do sistema de arquivos**, defina as configurações opcionais e, em **Configurações de performance**, escolha o modo de throughput **Intermitente** para seu sistema de arquivos. Depois de definir as configurações, selecione **Avançar**.

   1. (Opcional) Adicione tags ao sistema de arquivos. Por exemplo, você pode especificar um nome exclusivo para o sistema de arquivos inserindo esse nome na coluna **Value (Valor)** ao lado da chave **Name (Nome)**.

   1. (Opcional) Habilite o gerenciamento do ciclo de vida para economizar dinheiro em armazenamento acessado com pouca frequência. Para obter mais informações, consulte [Gerenciamento de ciclo de vida do EFS](https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html) no *Guia do usuário do Amazon Elastic File System*.

   1. (Opcional) Habilitar criptografia. Marque a caixa de seleção para habilitar a criptografia do sistema de arquivos do Amazon EFS em repouso.

1. Na página **Acesso à rede**, em **Montar destinos**, substitua a configuração do grupo de segurança existente para cada zona de disponibilidade pelo grupo de segurança que você criou para o sistema de arquivos [Etapa 2: criar um grupo de segurança para instâncias do Amazon EC2 e o sistema de arquivos Amazon EFS](#efs-security-group) e escolha **Avançar**.

1.  Não é preciso configurar a **Política do sistema de arquivos** para este tutorial, de modo que é possível pular a seção escolhendo **Avançar**.

1. Revise as opções do sistema de arquivos e escolha **Criar** para concluir o processo.

1. Na tela **Sistemas de arquivo**, registre o **ID do sistema de arquivos**. Na próxima etapa, você fará referência a esse valor na definição de tarefa do Amazon ECS.

## Etapa 4: adicionar conteúdo ao sistema de arquivos do Amazon EFS
<a name="efs-add-content"></a>

Nesta etapa, você monta o sistema de arquivos do Amazon EFS em uma instância do Amazon EC2 e adiciona conteúdo a ela. Esta etapa é para fins de teste neste tutorial, a fim de ilustrar a natureza persistente dos dados. Ao usar esse recurso, você normalmente teria sua aplicação ou outro método de gravação de dados no seu sistema de arquivos do Amazon EFS.

**Para criar uma instância do Amazon EC2 e montar o sistema de arquivos do Amazon EFS**

1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. Escolha **Executar instância**.

1. Em **Imagens de aplicações e sistemas operacionais (imagem de máquina da Amazon)**, selecione a **AMI do Amazon Linux 2 (HVM)**.

1. Em **Tipo de instância**, mantenha o tipo de instância padrão, `t2.micro`.

1.  Em **Par de chaves (login)**, selecione um par de chaves para acesso por SSH à instância.

1. Em **Configurações de rede**, selecione a VPC especificada para o sistema de arquivos Amazon EFS e o cluster do Amazon ECS. Selecione uma sub-rede e o grupo de segurança da instância criado em [Etapa 2: criar um grupo de segurança para instâncias do Amazon EC2 e o sistema de arquivos Amazon EFS](#efs-security-group). Configure o grupo de segurança da instância. Verifique se **Atribuir automaticamente IP público** está habilitado.

1. Em **Configurar armazenamento**, escolha o botão **Editar** para sistemas de arquivos e, em seguida, escolha **EFS**. Selecione o sistema de arquivos que você criou em [Etapa 3: criar um sistema de arquivos do Amazon EFS](#efs-create-filesystem). Opcionalmente, é possível alterar o ponto de montagem ou deixar o valor padrão.
**Importante**  
É necessário selecionar uma sub-rede antes de adicionar um sistema de arquivos à instância.

1. Desmarque **Criar e anexar grupos de segurança automaticamente**. Deixe a outra caixa de seleção marcada. Selecione **Add shared file system** (Adicionar sistema de arquivos compartilhado).

1. Em **Advanced Details** (Detalhes avançados), certifique-se de que o script de dados do usuário seja preenchido automaticamente com as etapas de montagem do sistema de arquivos do Amazon EFS.

1.  Em **Resumo**, verifique se o **Número de instâncias** é **1**. Escolha **Iniciar instância**.

1. Na página **Iniciar uma instância** escolha **Visualizar todas instâncias** para ver o status das suas instâncias. Inicialmente, o **Estado da instância** é `PENDING`. Depois que o estado mudar para `RUNNING` e a instância passar por todas as verificações de status, a instância estará pronta para uso.

Agora, você se conecta à instância do Amazon EC2 e adiciona conteúdo ao sistema de arquivos do Amazon EFS.

**Para conectar-se à instância do Amazon EC2 e adicionar conteúdo ao sistema de arquivos do Amazon EFS**

1. SSH para a instância do Amazon EC2 que você criou. Para obter mais informações, consulte [Conectar-se à instância do Linux usando SSH](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html) no *Guia do usuário do Amazon EC2*.

1. Na janela do terminal, execute o comando **df -T** para verificar se o sistema de arquivos Amazon EFS está montado. Na saída a seguir, destacamos a montagem do sistema de arquivos do Amazon EFS.

   ```
   $ df -T
   Filesystem     Type            1K-blocks    Used        Available Use% Mounted on
   devtmpfs       devtmpfs           485468       0           485468   0% /dev
   tmpfs          tmpfs              503480       0           503480   0% /dev/shm
   tmpfs          tmpfs              503480     424           503056   1% /run
   tmpfs          tmpfs              503480       0           503480   0% /sys/fs/cgroup
   /dev/xvda1     xfs               8376300 1310952          7065348  16% /
   127.0.0.1:/    nfs4     9007199254739968       0 9007199254739968   0% /mnt/efs/fs1
   tmpfs          tmpfs              100700       0           100700   0% /run/user/1000
   ```

1. Navegue até o diretório no qual o sistema de arquivos do Amazon EFS está montado. No exemplo acima, ele é `/mnt/efs/fs1`.

1. Crie um arquivo chamado `index.html` com o seguinte conteúdo:

   ```
   <html>
       <body>
           <h1>It Works!</h1>
           <p>You are using an Amazon EFS file system for persistent container storage.</p>
       </body>
   </html>
   ```

## Etapa 5: criar uma definição de tarefa
<a name="efs-task-def"></a>

A definição de tarefa a seguir cria um volume de dados chamado `efs-html`. O contêiner `nginx` monta o volume de dados do host na raiz de NGINX, `/usr/share/nginx/html`.

**Para criar uma nova definição de tarefa usando o console do Amazon ECS**

1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. No painel de navegação, escolha **Task definitions** (Definições de tarefa).

1. Escolha **Create new task definition** (Criar nova definição de tarefa), **Create new task definition with JSON** (Criar nova definição de tarefa com JSON).

1. Na caixa do editor JSON, copie e cole o seguinte texto JSON, substituindo `fileSystemId` pelo ID do sistema de arquivos do Amazon EFS.

   ```
   {
       "containerDefinitions": [
           {
               "memory": 128,
               "portMappings": [
                   {
                       "hostPort": 80,
                       "containerPort": 80,
                       "protocol": "tcp"
                   }
               ],
               "essential": true,
               "mountPoints": [
                   {
                       "containerPath": "/usr/share/nginx/html",
                       "sourceVolume": "efs-html"
                   }
               ],
               "name": "nginx",
               "image": "public.ecr.aws/docker/library/nginx:latest"
           }
       ],
       "volumes": [
           {
               "name": "efs-html",
               "efsVolumeConfiguration": {
                   "fileSystemId": "fs-1324abcd",
                   "transitEncryption": "ENABLED"
               }
           }
       ],
       "family": "efs-tutorial",
       "executionRoleArn":"arn:aws:iam::111122223333:role/ecsTaskExecutionRole"
   }
   ```
**nota**  
O perfil do IAM de execução de tarefas do Amazon ECS não exige nenhuma permissão específica relacionada ao Amazon EFS para montar um sistema de arquivos do Amazon EFS. Por padrão, se a política baseada em recursos do Amazon EFS não existir, o acesso será concedido a todas as entidades principais (\$1) na criação do sistema de arquivos.  
O perfil da tarefa do Amazon ECS será necessário apenas se a “autorização do IAM para EFS” estiver habilitada na definição da tarefa do Amazon ECS. Quando habilitada, a identidade do perfil da tarefa deverá ter o acesso permitido ao sistema de arquivos do Amazon EFS na política baseada em recursos do Amazon EFS, e o acesso anônimo deverá ser desabilitado.

1. Escolha **Criar**.

## Etapa 6: executar uma tarefa e visualizar os resultados
<a name="efs-run-task"></a>

Agora que o sistema de arquivos do Amazon EFS foi criado e há conteúdo da Web para o contêiner NGINX atender, você pode executar uma tarefa usando a definição de tarefa criada. Os servidores web do NGINX fornecem sua página HTML simples. Se você atualizar o conteúdo no sistema de arquivos do Amazon EFS, essas alterações serão propagadas para todos os contêineres que também tenham montado este sistema de arquivos.

A tarefa é executada na sub-rede que você definiu para o cluster.

**Para executar uma tarefa e visualizar os resultados usando o console**

1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Na página **Clusters**, selecione o cluster que contém a tarefa autônoma.

   Determine o recurso no qual você inicia o serviço.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/tutorial-efs-volumes.html)

1. (Opcional) Escolha como a tarefa programada é distribuída em toda a infraestrutura do cluster. Expanda **Compute configuration** (Configuração de computação) e realize estas ações:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonECS/latest/developerguide/tutorial-efs-volumes.html)

1. Em **Application type** (Tipo de aplicação), escolha **Task** (Tarefa).

1. Em **Definição de tarefa**, escolha a definição de tarefa `efs-tutorial` que você criou anteriormente.

1. Em **Tarefas desejadas**, insira `1`.

1. Escolha **Criar**.

1. Na página **Cluster**, escolha **Infraestrutura**.

1. Em **Instâncias de contêiner**, escolha a instância de contêiner com a qual deseja estabelecer conexão.

1. Na página **Instância de contêiner**, Em **Redes**, registre o **IP público** para sua instância.

1. Abra um navegador e insira o endereço IP público. Você deve ver a mensagem a seguir:

   ```
   It works!
   You are using an Amazon EFS file system for persistent container storage.
   ```
**nota**  
Se você não vir a mensagem, verifique se o grupo de segurança para suas instâncias de contêiner permite o tráfego de rede de entrada na porta 80 e se o grupo de segurança do seu sistema de arquivos permite acesso de entrada a partir da instância de contêiner.

# Uso de volumes do FSx para Windows File Server com Amazon ECS
<a name="wfsx-volumes"></a>

O FSx para Windows File Server fornece servidores de arquivos Windows totalmente gerenciados, baseados em um sistema de arquivos Windows. Ao usar o FSx for Windows File Server junto com o ECS, você pode provisionar tarefas do Windows com armazenamento de arquivos persistente, distribuído, compartilhado e estático. Para obter mais informações, consulte o [O que é FSx for Windows File Server?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html).

**nota**  
As instâncias do EC2 que usam a AMI completa do Windows Server 2016 otimizada para o Amazon ECS não oferecem suporte a volumes de tarefas do ECS do FSx for Windows File Server.  
Não é possível usar volumes do FSx para Windows File Server em contêineres do Windows na configuração do Fargate. Em vez disso, você pode [modificar os contêineres para montá-los no startup](https://aws.amazon.com/blogs/containers/use-smb-storage-with-windows-containers-on-aws-fargate/).

É possível usar o FSx for Windows File Server para implantar workloads do Windows que exigem acesso ao armazenamento externo compartilhado, ao armazenamento regional de alta disponibilidade ou ao armazenamento de alta throughput. É possível montar um ou mais volumes do sistema de arquivos do FSx para Windows File Server em um contêiner do Amazon ECS executado em uma instância do Amazon ECS. É possível compartilhar volumes do sistema de arquivos do FSx para Windows File Server entre vários contêineres do Amazon ECS em uma única tarefa do Amazon ECS.

Para permitir o uso do FSx para Windows File Server com o ECS, inclua o ID do sistema de arquivos FSx para Windows File Server e as informações relacionadas em uma definição de tarefa. Isso está no exemplo a seguir de trecho JSON de definição de tarefa. Antes de criar e executar uma definição de tarefa, você precisa do seguinte.
+ Uma instância Windows do EC2 do ECS que é unida a um domínio válido. Ela pode ser hospedada por um [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html), Active Directory on-premises ou Active Directory auto-hospedado no Amazon EC2.
+ Um segredo do AWS Secrets Manager ou um parâmetro do Systems Manager que contém as credenciais usadas para associação ao domínio do Active Directory e anexar o sistema de arquivos do FSx para Windows File Server. Os valores de credencial são as credenciais de nome e senha que você inseriu ao criar o diretório ativo.

Para ver um tutorial relacionado, consulte [Saiba como configurar sistemas de arquivos do FSx para Windows File Server para o Amazon ECS](tutorial-wfsx-volumes.md).

## Considerações
<a name="wfsx-volume-considerations"></a>

Considere o seguinte ao usar volumes do FSx for Windows File Server.
+ Os volumes do FSx for Windows File Server são suportados nativamente pelo Amazon ECS em instâncias do Amazon EC2 com Windows — o Amazon ECS gerencia automaticamente a montagem por meio da configuração da definição de tarefa.

  Em instâncias do Amazon EC2 no Linux, o Amazon ECS não consegue montar automaticamente volumes do FSx for Windows File Server por meio de definições de tarefa. No entanto, é possível montar manualmente um compartilhamento de arquivos do Amazon FSx para Windows File Server em uma instância do EC2 do Linux no nível do host e, em seguida, fazer a montagem por ligação desse caminho nos seus contêineres do Amazon ECS. Para obter mais informações, consulte [Montar compartilhamentos de arquivos do Amazon FSx a partir do Linux](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/map-shares-linux.html).
**Importante**  
Esta é uma configuração autogerenciada. Para obter orientações sobre como montar e manter compartilhamentos de arquivos do FSx para Windows File Server no Linux, consulte a documentação do [FSx para Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/).
**Importante**  
Ao utilizar um compartilhamento do Amazon FSx for Windows File Server montado manualmente em instâncias do Amazon EC2 do Linux, o Amazon ECS e o FSx para Windows File Server operam de forma independente — o Amazon ECS não monitora a montagem do Amazon FSx, e o FSx for Windows File Server não rastreia o posicionamento das tarefas do Amazon ECS nem os eventos do ciclo de vida. É de sua responsabilidade garantir a conectividade de rede entre suas instâncias de contêiner do Amazon ECS e o sistema de arquivos Amazon FSx, implementar verificações de integridade de montagem e gerenciar a lógica de reconexão para lidar com eventos de failover.
+ O FSx for Windows File Server com o Amazon ECS não oferece suporte ao AWS Fargate.
+ O FSx for Windows File Server com o Amazon ECS não é compatível com instâncias gerenciadas do Amazon ECS.
+ O FSx for Windows File Server com o Amazon ECS, com modo de rede `awsvpc`, exige a versão `1.54.0` ou posterior do agente de contêiner.
+ O número máximo de letras de unidade que podem ser usadas para uma tarefa do Amazon ECS é 23. Cada tarefa com um volume do FSx for Windows File Server obtém uma letra de unidade atribuída a ela.
+ Por padrão, o tempo de limpeza de recursos de tarefas é de três horas após o término da tarefa. Mesmo que nenhuma tarefa o use, um mapeamento de arquivos criado por uma tarefa persiste por três horas. O tempo de limpeza padrão pode ser configurado usando a variável de ambiente do Amazon ECS `ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION`. Para obter mais informações, consulte [Configuração do agente de contêiner do Amazon ECS](ecs-agent-config.md).
+ Normalmente, as tarefas somente são executadas na mesma VPC do sistema de arquivos do FSx for Windows File Server. No entanto, é possível ter suporte entre VPCs se houver uma conectividade de rede estabelecida entre a VPC do cluster do Amazon ECS e o sistema de arquivos do FSx for Windows File Server por meio de emparelhamento da VPC.
+ Controle o acesso a um sistema de arquivos do FSx for Windows File Server no nível da rede configurando os grupos de segurança da VPC. Somente as tarefas hospedadas em instâncias do EC2, associadas ao domínio do Active Directory com grupos de segurança do Active Directory configurados corretamente, podem acessar o compartilhamento de arquivos do FSx para Windows File Server. Se os grupos de segurança estiverem configurados incorretamente, o Amazon ECS falhará na inicialização da tarefa e apresentará a seguinte mensagem de erro: ”.: `unable to mount file system fs-id`.” 
+ O FSx for Windows File Server é integrado ao AWS Identity and Access Management (IAM) para controlar as ações que os usuários e grupos do IAM podem executar em recursos específicos do FSx for Windows File Server. Com autorização do cliente, os clientes podem definir funções do IAM que permitem ou negam acesso a sistemas de arquivos específicos do FSx for Windows File Server, opcionalmente exigir acesso somente leitura e, opcionalmente, permitir ou impedir acesso raiz ao sistema de arquivos do cliente. Para obter mais informações, consulte [Segurança](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/security.html) no Guia do usuário do Amazon FSx for Windows.

# Práticas recomendadas ao usar o FSx para Windows File Server com o Amazon ECS
<a name="wfsx-best-practices"></a>

Anote as práticas recomendadas a seguir ao usar o FSx para Windows File Server com o Amazon ECS.

## Segurança e controles de acesso para o FSx para Windows File Server
<a name="wfsx-security-access-controls"></a>

O FSx para Windows File Server oferece os recursos de controle de acesso a seguir, usados para garantir que os dados armazenados em um sistema de arquivos do FSx para Windows File Server estejam seguros e acessíveis somente pelas aplicações que precisam deles.

### Criptografia de dados para volumes do FSx para Windows File Server
<a name="storage-fsx-security-encryption"></a>

O FSx para Windows File Server oferece suporte a duas formas de criptografia para sistemas de arquivos. São elas a criptografia de dados em trânsito e a criptografia em repouso. A criptografia de dados em trânsito é compatível com compartilhamentos de arquivos mapeados em uma instância de contêiner que seja compatível com o protocolo SMB 3.0 ou mais recente. A criptografia de dados em repouso é habilitada automaticamente ao criar um sistema de arquivos do Amazon FSx. O Amazon FSx criptografa automaticamente os dados em trânsito usando a criptografia SMB à medida que você acessa seu sistema de arquivos, sem a necessidade de modificar suas aplicações. Para obter mais informações, consulte [Data encryption in Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/encryption.html) no *Guia do usuário do Amazon FSx para Windows File Server*.

### Uso de ACLs do Windows para controle de acesso em nível de pasta
<a name="storage-fsx-security-access"></a>

A instância do Windows para Amazon EC2 acessa os compartilhamentos de arquivos do Amazon FSx usando as credenciais do Active Directory. Ela usa listas de controle de acesso (ACLs) padrão do Windows para controle de acesso refinado em nível de arquivo e pasta. Você pode criar várias credenciais, cada uma para uma pasta específica dentro do compartilhamento que mapeia para uma tarefa específica.

No exemplo a seguir, a tarefa tem acesso à pasta `App01` usando uma credencial salva no Secrets Manager. Seu nome do recurso da Amazon (ARN) é `1234`.

```
"rootDirectory": "\\path\\to\\my\\data\App01",
"credentialsParameter": "arn-1234",
"domain": "corp.fullyqualified.com",
```

Em outro exemplo, uma tarefa tem acesso à pasta `App02` usando uma credencial salva no Secrets Manager. Seu ARN é `6789`.

```
"rootDirectory": "\\path\\to\\my\\data\App02",
"credentialsParameter": "arn-6789",
"domain": "corp.fullyqualified.com",
```

# Especificar um sistema de arquivos do FSx para Windows File Server em uma definição de tarefa do Amazon ECS
<a name="specify-wfsx-config"></a>

Para usar volumes do sistema de arquivos do FSx for Windows File Server para seus contêineres, especifique as configurações de volume e ponto de montagem na definição de tarefa. O trecho JSON de definição de tarefa a seguir mostra a sintaxe para os objetos `volumes` e `mountPoints` de um contêiner.

```
{
    "containerDefinitions": [
        {
            "entryPoint": [
                "powershell",
                "-Command"
            ],
            "portMappings": [],
            "command": ["New-Item -Path C:\\fsx-windows-dir\\index.html -ItemType file -Value '<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>It Works!</h2> <p>You are using Amazon FSx for Windows File Server file system for persistent container storage.</p>' -Force"],
            "cpu": 512,
            "memory": 256,
            "image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019",
            "essential": false,
            "name": "container1",
            "mountPoints": [
                {
                    "sourceVolume": "fsx-windows-dir",
                    "containerPath": "C:\\fsx-windows-dir",
                    "readOnly": false
                }
            ]
        },
        {
            "entryPoint": [
                "powershell",
                "-Command"
            ],
            "portMappings": [
                {
                    "hostPort": 443,
                    "protocol": "tcp",
                    "containerPort": 80
                }
            ],
            "command": ["Remove-Item -Recurse C:\\inetpub\\wwwroot\\* -Force; Start-Sleep -Seconds 120; Move-Item -Path C:\\fsx-windows-dir\\index.html -Destination C:\\inetpub\\wwwroot\\index.html -Force; C:\\ServiceMonitor.exe w3svc"],
            "mountPoints": [
                {
                    "sourceVolume": "fsx-windows-dir",
                    "containerPath": "C:\\fsx-windows-dir",
                    "readOnly": false
                }
            ],
            "cpu": 512,
            "memory": 256,
            "image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019",
            "essential": true,
            "name": "container2"
        }
    ],
    "family": "fsx-windows",
    "executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole",
    "volumes": [
        {
            "name": "fsx-windows-dir",
            "fsxWindowsFileServerVolumeConfiguration": {
                "fileSystemId": "fs-0eeb5730b2EXAMPLE",
                "authorizationConfig": {
                    "domain": "example.com",
                    "credentialsParameter": "arn:arn-1234"
                },
                "rootDirectory": "share"
            }
        }
    ]
}
```

`FSxWindowsFileServerVolumeConfiguration`  
Tipo: Objeto  
Obrigatório: não  
Esse parâmetro é especificado quando você está usando o sistema de arquivos do [FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) para armazenamento de tarefas.    
`fileSystemId`  
Tipo: String  
Exigido: sim  
O ID do sistema de arquivos do FSx for Windows File Server a ser usado.  
`rootDirectory`  
Tipo: String  
Exigido: sim  
O diretório no sistema de arquivos do FSx for Windows File Server que deve ser montado como o diretório raiz dentro do host.  
`authorizationConfig`    
`credentialsParameter`  
Tipo: String  
Exigido: sim  
As opções de credencial de autorização:  
+ Nome do recurso da Amazon (ARN) de um segredo do [Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html).
+ Nome do recurso da Amazon (ARN) de um parâmetro do [Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html).  
`domain`  
Tipo: String  
Exigido: sim  
Um nome de domínio totalmente qualificado hospedado por um diretório do [AWS Directory Service for Microsoft Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) (AWS Managed Microsoft AD) ou por um Active Directory do EC2 auto-hospedado.

## Métodos para o armazenamento de credenciais de volume do FSx para Windows File Server
<a name="creds"></a>

Existem dois métodos diferentes de armazenamento de credenciais para uso com o parâmetro de credenciais.
+ **AWS Secrets Manager Segredo do**

  Essa credencial pode ser criada no console do AWS Secrets Manager usando a categoria *Other type of secret* (Outro tipo de segredo). Você adiciona uma linha para cada par chave-valor, nome de usuário/administrador e senha/*senha*.
+ **Parâmetro do Systems Manager**

  Essa credencial pode ser criada no console de parâmetros do Systems Manager inserindo texto no formulário mostrado no trecho do código de exemplo a seguir.

  ```
  {
    "username": "admin",
    "password": "password"
  }
  ```

O `credentialsParameter` no parâmetro `FSxWindowsFileServerVolumeConfiguration` da definição de tarefa mantém o ARN do segredo ou o ARN do parâmetro do Systems Manager. Para obter mais informações, consulte [O que é o AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) no *Guia do usuário do Secrets Manager* e [Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) no *Guia do usuário do Systems Manager*.

# Saiba como configurar sistemas de arquivos do FSx para Windows File Server para o Amazon ECS
<a name="tutorial-wfsx-volumes"></a>

Saiba como iniciar uma instância do Windows otimizada para o Amazon ECS que hospeda um sistema de arquivos do FSx para Windows File Server e contêineres que podem acessar o sistema de arquivos. Para fazer isso, você primeiro criará um Microsoft Active Directory gerenciado pela AWS do Directory Service. Em seguida, você cria um sistema de arquivos do FSx para Windows File Server e um cluster com uma instância do Amazon EC2 e uma definição de tarefa. Configure a definição de tarefa para os contêineres usarem o sistema de arquivos do FSx for Windows File Server. Finalmente, teste o sistema de arquivos.

Entre 20 e 45 minutos são necessários toda vez que você inicia ou exclui o Active Directory ou o sistema de arquivos do FSx for Windows File Server. Esteja preparado para reservar pelo menos 90 minutos para concluir o tutorial ou conclua o tutorial em algumas sessões.

## Pré-requisitos para o tutorial
<a name="wfsx-prerequisites"></a>
+ Um usuário administrativo. Consulte [Configuração para usar o Amazon ECS](get-set-up-for-amazon-ecs.md).
+ (Opcional) Um par de chaves `PEM` para se conectar à instância do Windows do EC2 por acesso RDP. Para obter informações sobre como criar pares de chaves, consulte [Pares de chaves do Amazon EC2 e instâncias do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) no *Guia do usuário do Amazon EC2*.
+ Uma VPC com pelo menos uma sub-rede pública e uma privada e um grupo de segurança. É possível usar a VPC padrão. Você não precisa de um gateway ou dispositivo NAT. O Directory Service não oferece suporte à conversão de endereços de rede (NAT) com o Active Directory. Para que isso funcione, o Active Directory, o sistema de arquivos do FSx for Windows File Server, o cluster do ECS e a instância do EC2 devem estar localizados na VPC. Para obter mais informações sobre VPCs e Active Directories, consulte [Criar uma VPC](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html) e [Pré-requisitos para criar um Microsoft AD gerenciado pela AWS](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started.html#ms_ad_getting_started_prereqs).
+ As permissões do IAM ecsInstanceRole e ecsTaskExecutionRole estão associadas à sua conta. Esses perfis vinculados ao serviço permitem que os serviços façam chamadas de API e acessem contêineres, segredos, diretórios e servidores de arquivos em seu nome.

## Etapa 1: criar funções de acesso do IAM
<a name="iam-roles"></a>

**Crie um cluster com o Console de gerenciamento da AWS.**

1. Consulte [Função do IAM de instância de contêiner do Amazon ECS](instance_IAM_role.md) para verificar se você tem uma ecsInstanceRole e ver como será possível criar uma, caso não tenha.

1. Recomendamos que as políticas de função sejam personalizadas para permissões mínimas em um ambiente de produção real. Com a finalidade de trabalhar neste tutorial, verifique se a política gerenciada pela AWS a seguir está anexada a ecsInstanceRole. Anexe a política, caso ela ainda não esteja anexada.
   + AmazonEC2ContainerServiceforEC2Role
   + AmazonSSMManagedInstanceCore
   + AmazonSSMDirectoryServiceAccess

   Para anexar políticas gerenciadas pela AWS

   1. Abra o [console do IAM](https://console.aws.amazon.com//iam/).

   1. No painel de navegação, selecione **Roles**.

   1. Escolha um **perfil gerenciado da AWS**.

   1. Escolha **Permissões, Anexar políticas**.

   1. Para restringir as políticas disponíveis a serem anexadas, use **Filter**.

   1. Selecione a política apropriada e escolha **Attach policy** (Anexar política).

1. Consulte [Função do IAM de execução de tarefas do Amazon ECS](task_execution_IAM_role.md) para verificar se você tem uma ecsTaskExecutionRole e ver como será possível criar uma, caso não tenha.

   Recomendamos que as políticas de função sejam personalizadas para permissões mínimas em um ambiente de produção real. Com a finalidade de trabalhar neste tutorial, verifique se as políticas gerenciadas pela AWS a seguir estão anexadas a ecsTaskExecutionRole Anexe as políticas, caso elas ainda não estejam anexadas. Use o procedimento indicado na seção anterior para anexar as políticas gerenciadas pela AWS.
   + SecretsManagerReadWrite
   + AmazonFSxReadOnlyAccess
   + AmazonSSMReadOnlyAccess
   + AmazonECSTaskExecutionRolePolicy

## Etapa 2: criar o Windows Active Directory (AD)
<a name="wfsx-create-ads"></a>

1. Siga as etapas descritas em [Criar seu Microsoft AD gerenciado pela AWS](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started.html#ms_ad_getting_started_create_directory) no *Guia de administração do AWS Directory Service*. Use a VPC que você designou para este tutorial. Na etapa 3 de *Criar seu Microsoft AD gerenciado pela AWS*, salve o nome do usuário e a senha de administrador para uso em uma etapa posterior. Além disso, anote o nome de DNS totalmente qualificado para etapas futuras. É possível concluir a etapa a seguir enquanto o Active Directory está sendo criado.

1. Crie um segredo do AWS Secrets Manager a ser usado nas etapas a seguir. Para obter mais informações, consulte [Conceitos básicos do Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html#get-started) no *Guia do usuário do AWS Secrets Manager*.

   1. Abra o [console do Secrets Manager](https://console.aws.amazon.com//secretsmanager/).

   1. Clique em **Store a new secret** (Armazenar um novo segredo).

   1. Selecione **Other type of secrets** (Outro tipo de segredos).

   1. Em **Secret key/value** (Chave/valor secreto), na primeira linha, crie uma chave **username** com valor **admin**. Clique em **\$1 Add row** (\$1 Adicionar linha).

   1. Na nova linha, crie uma chave **password**. Em valor, digite a senha inserida na Etapa 3 de *Criar seu diretório do AD gerenciado pela AWS*.

   1. Clique no botão **Next** (Avançar).

   1. Forneça um nome e uma descrição do segredo. Clique em **Next**.

   1. Clique em **Next**. Clique em **Store** (Armazenar).

   1. Na lista da página **Segredos**, clique no segredo que você acabou de criar.

   1. Salve o ARN do novo segredo para uso nas próximas etapas,

   1. É possível ir para a próxima etapa enquanto seu Active Directory está sendo criado.

## Etapa 3: verificar e atualizar o grupo de segurança
<a name="wfsx-sg"></a>

Nesta etapa, você verificará e atualizará as regras do grupo de segurança que você estiver usando. Para isso, você pode usar o grupo de segurança padrão que foi criado para a VPC.

**Verifique e atualize o grupo de segurança.**

Você precisa criar ou editar o grupo de segurança para enviar dados de e para as portas, que são descritas em [Grupos de segurança da Amazon VPC](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/limit-access-security-groups.html#fsx-vpc-security-groups) no *Guia do usuário do FSx for Windows File Server*. É possível fazer isso criando a regra de entrada do grupo de segurança mostrada na primeira linha da tabela de regras de entrada a seguir. Essa regra permite tráfego de entrada de interfaces de rede (e das instâncias associadas) atribuídas ao grupo de segurança. Todos os recursos de nuvem criados estão dentro da mesma VPC e anexados ao mesmo grupo de segurança. Portanto, essa regra permite o tráfego entre o sistema de arquivos do FSx for Windows File Server, o Active Directory e a instância do ECS conforme necessário. As outras regras de entrada permitem que o tráfego atenda ao site e ao acesso RDP para conexão à instância do ECS.

A tabela a seguir mostra quais regras de entrada do grupo de segurança são necessárias para este tutorial.


| Tipo | Protocolo | Intervalo de portas | Origem | 
| --- | --- | --- | --- | 
|  Todo o tráfego  |  Tudo  |  Todos  |  *sg-securitygroup*  | 
|  HTTPS  |  TCP  |  443  |  0.0.0.0/0  | 
|  RDP  |  TCP  |  3389  |  endereço IP do seu laptop  | 

A tabela a seguir mostra quais regras de saída do grupo de segurança são necessárias para este tutorial.


| Tipo | Protocolo | Intervalo de portas | Destino | 
| --- | --- | --- | --- | 
|  Todo o tráfego  |  Tudo  |  Tudo  |  0.0.0.0/0  | 

1. Abra o [Console do EC2](https://console.aws.amazon.com//ec2/) e selecione **Security groups** (Grupos de segurança) no menu à esquerda.

1. Na lista de grupos de segurança exibida, marque a caixa de seleção à esquerda do grupo de segurança que você está usando para este tutorial.

   Os detalhes do security group são exibidos.

1. Edite as regras de entrada e saída selecionando as guias **Regras de entrada** ou **Regras de saída** e clicando nos botões **Editar regras de entrada** ou **Editar regras de saída**. Edite as regras para corresponder às regras exibidas nas tabelas anteriores. Depois de criar a instância do EC2 posteriormente neste tutorial, edite a origem RDP da regra de entrada com o endereço IP público da instância do EC2, conforme descrito em [Conectar-se à sua instância do Windows usando RDP](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecting_to_windows_instance.html) no *Guia do usuário do Amazon EC2*.

## Etapa 4: criar um sistema de arquivos do FSx for Windows File Server
<a name="wfsx-create-fsx"></a>

Depois que o grupo de segurança for verificado e atualizado e o Active Directory for criado e estiver no status ativo, crie o sistema de arquivos do FSx for Windows File Server na mesma VPC do Active Directory. Use as etapas a seguir para criar um sistema de arquivos do FSx for Windows File Server para as tarefas do Windows.

**Crie seu primeiro sistema de arquivos.**

1. Abra o [console do Amazon FSx](https://console.aws.amazon.com//fsx/).

1. No painel, escolha **Create file system** (Criar sistema de arquivos) para iniciar o assistente de criação de sistemas de arquivos.

1. Na página **Selecionar tipo de sistema de arquivos**, escolha **FSx para Windows File Server** e, em seguida, selecione **Next** (Avançar). A página **Criar sistema de arquivos** é exibida.

1. Na seção **Detalhes do sistema de arquivos**, forneça um nome para o sistema de arquivos. Nomear seus sistemas de arquivos torna mais fácil encontrar e gerenciar seus sistemas. Podem ser usados até 256 caracteres Unicode. Os caracteres permitidos são letras, números, espaços e os caracteres especiais sinal de mais (\$1). sinal de menos (-), sinal de igual (=), ponto (.), sublinhado (\$1), dois-pontos (:) e barra (/).

1. Em **Deployment type** (Tipo de implantação), escolha **Single-AZ** para implantar um sistema de arquivos implantado em uma única zona de disponibilidade. *Single-AZ 2* é a geração mais recente de sistemas de arquivos de zona de disponibilidade única. É compatível com armazenamento SSD e HDD.

1. Em **Storage type** (Tipo de armazenamento), escolha **HDD**.

1. Em **Storage capacity** (Capacidade de armazenamento), insira a capacidade mínima de armazenamento. 

1. Mantenha a **Capacidade de Throughput** na configuração padrão.

1. Na seção **Rede e segurança**, escolha a mesma Amazon VPC que você escolheu para o diretório do Directory Service.

1. Em **VPC Security Groups** (Grupos de segurança da VPC), escolha o grupo de segurança que você verificou na *Etapa 3: verificar e atualizar o grupo de segurança*.

1. Em **Windows authentication** (Autenticação do Windows), escolha **AWS Managed Microsoft Active Directory** (Microsoft Active Directory gerenciado pela ) e, depois, escolha o diretório do Directory Service na lista.

1. Em **Encryption** (Criptografia), mantenha a configuração padrão da **Encryption key** (Chave de criptografia) como **aws/fsx (default)**.

1. Mantenha as configurações padrão para **Preferências de manutenção**.

1. Clique no botão **Next** (Avançar).

1. Verifique a configuração do sistema de arquivos mostrada na página **Criar sistema de arquivos**. Para sua referência, anote quais configurações do sistema de arquivos você pode modificar após a criação do sistema de arquivos. Escolha **Create file system (Criar sistema de arquivos)**. 

1. Anote o ID do sistema de arquivos. Você precisará usá-lo em uma etapa posterior.

   É possível seguir para as próximas etapas para criar um cluster e uma instância do EC2 enquanto o sistema de arquivos do FSX for Windows File Server está sendo criado.

## Etapa 5: criar um cluster do Amazon ECS
<a name="wfsx-create-cluster"></a>

**Criar um cluster usando o console do Amazon ECS**

1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Na barra de navegação, selecione a Região a ser usada.

1. No painel de navegação, escolha **Clusters**.

1. Na página **Clusters**, escolha **Create Cluster** (Criar cluster).

1. Em **Configuração do cluster)**, para **Nome do cluster**, insira **windows-fsx-cluster**.

1. Expanda **Infraestrutura**, desmarque AWS Fargate (tecnologia sem servidor) e selecione **Instâncias do Amazon EC2**.

   1. Para criar um grupo do Auto Scaling, a partir de **Auto Scaling group (ASG)** (Grupo do Auto Scaling (ASG)), selecione **Create new group** (Criar novo grupo) e, em seguida, forneça os seguintes detalhes sobre o grupo:
     + Em **Sistema operacional/Arquitetura**, escolha **Windows Server 2019 Core**.
     + Em **Tipo de instância do EC2**, escolha t2.medium ou t2.micro.

1. Escolha **Criar**.

## Etapa 6: criar uma instância do Amazon ECS otimizada para o Amazon EC2
<a name="wfsx-create-instance"></a>

Crie uma instância de contêiner do Windows do Amazon ECS.

**Para criar uma instância do Amazon ECS**

1. Use o comando `aws ssm get-parameters` para recuperar o nome da AMI para a região que hospeda sua VPC. Para obter mais informações, consulte [Recuperar os metadados da AMI otimizada para Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/retrieve-ecs-optimized_windows_AMI.html).

1. Use o console do Amazon EC2 para iniciar a instância.

   1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

   1. Na barra de navegação, selecione a Região a ser usada.

   1. No **Painel do EC2**, escolha **Launch Instance** (Iniciar instância).

   1. Em **Name (Nome)**, insira um nome exclusivo.

   1. Em **Imagens de aplicações e SO (Amazon Machine Image)**, no campo **pesquisar**, insira o nome da AMI que você recuperou.

   1. Em **Tipo de instância**, escolha t2.medium ou t2.micro.

   1. Em **Key pair (login)** (Par de chaves [login]), escolha um par de chaves. Se você não especificar um par de chaves, você 

   1. Em **Configurações de rede**, para **VPC** e **sub-rede**, escolha sua VPC e uma sub-rede pública.

   1. Em **Network settings** (Configurações de rede), em **Security group** (Grupo de segurança), selecione um grupo de segurança existente ou crie outro. Certifique-se de que o grupo de segurança escolhido tenha as regras de entrada e saída definidas em [Pré-requisitos para o tutorial](#wfsx-prerequisites)

   1. Em **Network settings** (Configurações de rede), em **Auto-assign Public IPC** (Atribuir IP público automaticamente), selecione **Enable** (Habilitar). 

   1. Expanda **Detalhes avançados**, e em **Associar diretório a domínio**, selecione o ID do Active Directory que você criou. Esse domínio se junta ao AD quando a instância do EC2 é iniciada.

   1. Em **Advanced details** (Detalhes avançados), em **IAM instance profile** (Perfil de instância do IAM), escolha **ecsInstanceRole**.

   1. Configure a instância de contêiner do Amazon ECS com os dados de usuário a seguir. Em **Advanced Details** (Detalhes avançados), cole o seguinte script no campo **User data** (Dados do usuário), substituindo *cluster\$1name* pelo nome do cluster.

      ```
      <powershell>
      Initialize-ECSAgent -Cluster windows-fsx-cluster -EnableTaskIAMRole
      </powershell>
      ```

   1. Quando estiver pronto, selecione o campo de confirmação e, então, escolha **Launch Instances**. 

   1. Uma página de confirmação informa que sua instância está sendo executada. Selecione **Visualizar instâncias** para fechar a página de confirmação e voltar ao console.

1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. No painel de navegação, escolha **Clusters** e, em seguida, escolha **windows-fsx-cluster**.

1. Selecione a guia **Infraestrutura** e verifique se a sua instância foi registrada no cluster **windows-fsx-cluster**.

## Etapa 7: registrar uma definição de tarefa do Windows
<a name="register_windows_task_def"></a>

Para executar contêineres do Windows no cluster do Amazon ECS, você deve registrar uma definição de tarefa. O exemplo de definição de tarefa a seguir exibe uma página da Web simples. A tarefa inicia dois contêineres que têm acesso ao sistema de arquivos do FSx. O primeiro contêiner grava um arquivo HTML no sistema de arquivos. O segundo contêiner baixa o arquivo HTML do sistema de arquivos e serve a página da Web.

1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. No painel de navegação, escolha **Task definitions** (Definições de tarefa).

1. Escolha **Create new task definition** (Criar nova definição de tarefa), **Create new task definition with JSON** (Criar nova definição de tarefa com JSON).

1. NA caixa do editor JSON, substitua os valores do seu perfil de execução da tarefa e os detalhes sobre o sistema de arquivos FSx e, em seguida, escolha **Salvar**.

   ```
   {
       "containerDefinitions": [
           {
               "entryPoint": [
                   "powershell",
                   "-Command"
               ],
               "portMappings": [],
               "command": ["New-Item -Path C:\\fsx-windows-dir\\index.html -ItemType file -Value '<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>It Works!</h2> <p>You are using Amazon FSx for Windows File Server file system for persistent container storage.</p>' -Force"],
               "cpu": 512,
               "memory": 256,
               "image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019",
               "essential": false,
               "name": "container1",
               "mountPoints": [
                   {
                       "sourceVolume": "fsx-windows-dir",
                       "containerPath": "C:\\fsx-windows-dir",
                       "readOnly": false
                   }
               ]
           },
           {
               "entryPoint": [
                   "powershell",
                   "-Command"
               ],
               "portMappings": [
                   {
                       "hostPort": 443,
                       "protocol": "tcp",
                       "containerPort": 80
                   }
               ],
               "command": ["Remove-Item -Recurse C:\\inetpub\\wwwroot\\* -Force; Start-Sleep -Seconds 120; Move-Item -Path C:\\fsx-windows-dir\\index.html -Destination C:\\inetpub\\wwwroot\\index.html -Force; C:\\ServiceMonitor.exe w3svc"],
               "mountPoints": [
                   {
                       "sourceVolume": "fsx-windows-dir",
                       "containerPath": "C:\\fsx-windows-dir",
                       "readOnly": false
                   }
               ],
               "cpu": 512,
               "memory": 256,
               "image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019",
               "essential": true,
               "name": "container2"
           }
       ],
       "family": "fsx-windows",
       "executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole",
       "volumes": [
           {
               "name": "fsx-windows-dir",
               "fsxWindowsFileServerVolumeConfiguration": {
                   "fileSystemId": "fs-0eeb5730b2EXAMPLE",
                   "authorizationConfig": {
                       "domain": "example.com",
                       "credentialsParameter": "arn:arn-1234"
                   },
                   "rootDirectory": "share"
               }
           }
       ]
   }
   ```

## Etapa 8: executar uma tarefa e visualizar os resultados
<a name="wfsx-run-task"></a>

Antes de executar a tarefa, verifique se o status do sistema de arquivos do FSx for Windows File Server está **Available** (Disponível). Depois que ele estiver disponível, será possível executar uma tarefa usando a definição de tarefa criada. A tarefa começa ao criar contêineres que embaralham um arquivo HTML entre eles usando o sistema de arquivos. Após o embaralhamento, um servidor Web atende à página HTML simples.

**nota**  
Talvez você não seja capaz de se conectar ao site a partir de uma VPN.

**Execute uma tarefa e veja os resultados no console do Amazon ECS.**

1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. No painel de navegação, escolha **Clusters** e, em seguida, escolha **windows-fsx-cluster**.

1. Escolha a guia **Tarefas** e, em seguida, escolha **Executar nova tarefa**.

1. Em **Launch Type**, selecione **EC2**.

1. Em Configuração de implantação, para **Definição de tarefa**, escolha **fsx-windows** e, em seguida, escolha **Criar**.

1. Quando o status da tarefa for **EM EXECUÇÃO**, escolha o ID da tarefa.

1. Em **Contêineres**, quando o status do contêiner1 for **INTERROMPIDO**, selecione contêiner2 para ver os detalhes do contêiner.

1.  Em **Detalhes de contêiner para o contêiner2**, selecione **Ligações de rede** e clique no endereço IP externo associado ao contêiner. O navegador abrirá e exibirá a mensagem a seguir.

   ```
   Amazon ECS Sample App
   It Works! 
   You are using Amazon FSx for Windows File Server file system for persistent container storage.
   ```
**nota**  
Pode demorar alguns minutos para que a mensagem seja exibida. Se você não vir a mensagem após alguns minutos, certifique-se de que as execuções não estejam ocorrendo em uma VPN e de que o grupo de segurança das instâncias de contêiner permita o tráfego HTTP da rede de entrada na porta 443.

## Etapa 9: limpar
<a name="wfsx-cleanup"></a>

**nota**  
Demora de 20 a 45 minutos para excluir o sistema de arquivos do FSx for Windows File Server ou o AD. Você deve aguardar até que as operações de exclusão do sistema de arquivos do FSx for Windows File Server sejam concluídas antes de iniciar as operações de exclusão do AD.

**Exclua o sistema de arquivos do FSx for Windows File Server**

1. Abra o [console do Amazon FSx](https://console.aws.amazon.com//fsx/).

1. Escolha o botão de opção à esquerda do sistema de arquivos do FSx for Windows File Server que você acabou de criar.

1. Escolha **Ações**.

1. Selecione **Delete file system** (Excluir sistema de arquivos).

**Excluir AD.**

1. Abra o [console do Directory Service](https://console.aws.amazon.com//directoryservicev2/).

1. Escolha o botão de opção à esquerda do AD que você acabou de criar.

1. Escolha **Ações**.

1. Selecione **Delete directory** (Excluir diretório).

**Excluir o cluster.**

1. Abra o console em [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. No painel de navegação, escolha **Clusters** e, em seguida, escolha **windows-fsx-cluster**.

1. Escolha **Delete Cluster (Excluir cluster)**.

1. Insira a frase e, em seguida, escolha **Excluir**.

**Encerra a instância do EC2.**

1. Abra o [console do Amazon EC2](https://console.aws.amazon.com//ec2/).

1. No menu à esquerda, selecione **Instances** (Instâncias).

1. Marque a caixa de seleção à esquerda da instância do EC2 que você criou.

1. Clique no **Estado da instância**, **Encerrar instância**.

**Excluir segredo.**

1. Abra o [console do Secrets Manager](https://console.aws.amazon.com//secretsmanager/).

1. Selecione o segredo que você criou para esta demonstração.

1. Clique em **Actions** (Ações)

1. Selecione **Delete secret** Excluir segredo).

# Uso de volumes do Docker com o Amazon ECS
<a name="docker-volumes"></a>

Ao usar os volumes do Docker, o driver `local` integrado ou um driver de volume de terceiros poderão ser usados. Os volumes do Docker são gerenciados pelo Docker e um diretório é criado em `/var/lib/docker/volumes` na instância de contêiner que contém os dados de volume.

Para usar os volumes do Docker, especifique uma `dockerVolumeConfiguration` em sua definição de tarefa. Para obter mais informações, consulte [Volumes](https://docs.docker.com/engine/storage/volumes/) na documentação do Docker.

Alguns casos de uso comuns para os volumes do Docker são os seguintes:
+ Para fornecer volumes de dados persistentes para uso com contêineres
+ Para compartilhar um volume de dados definido em locais diferentes em contêineres diferentes na mesma instância de contêiner
+ Para definir um volume de dados não persistente e vazio, além de montá-lo em vários contêineres na mesma tarefa
+ Para fornecer um volume de dados para sua tarefa gerenciada por um driver de terceiros

## Considerações sobre o uso de volumes do Docker
<a name="docker-volume-considerations"></a>

Considere o seguinte ao usar volumes do Docker:
+ Só há suporte para os volumes do Docker com o uso do tipo de inicialização do EC2 ou instâncias externas.
+ Os contêineres do Windows só são compatíveis com o uso do driver `local`.
+ Se um driver de terceiros for usado, verifique se ele está instalado e ativo na instância do contêiner antes que o agente de contêiner seja iniciado. Se o driver de terceiros não estiver ativo antes da inicialização do agente, será possível reiniciar o agente do contêiner usando um dos comandos a seguir:
  + Para a AMI do Amazon Linux 2 otimizada para o Amazon ECS:

    ```
    sudo systemctl restart ecs
    ```
  + Para a AMI do Amazon Linux otimizada para o Amazon ECS:

    ```
    sudo stop ecs && sudo start ecs
    ```

Para obter informações sobre como especificar um volume do Docker em uma definição de tarefa, consulte [Especificar um volume do Docker em uma definição de tarefa do Amazon ECS](specify-volume-config.md).

# Especificar um volume do Docker em uma definição de tarefa do Amazon ECS
<a name="specify-volume-config"></a>

Antes de seus contêineres poderem usar volumes de dados, você deve especificar as configurações de volume e ponto de montagem em sua definição de tarefa. Esta seção descreve a configuração do volume de um contêiner. Para tarefas que usam um volume do Docker, especifique um `dockerVolumeConfiguration`. Para tarefas que usam um volume de host de montagem bind, especifique um `host` e `sourcePath` opcional.

O JSON de definição de tarefa a seguir mostra a sintaxe para os objetos `volumes` e `mountPoints` de um contêiner.

```
{
    "containerDefinitions": [
        {
            "mountPoints": [
                {
                    "sourceVolume": "string",
                    "containerPath": "/path/to/mount_volume",
                    "readOnly": boolean
                }
            ]
        }
    ],
    "volumes": [
        {
            "name": "string",
            "dockerVolumeConfiguration": {
                "scope": "string",
                "autoprovision": boolean,
                "driver": "string",
                "driverOpts": {
                    "key": "value"
                },
                "labels": {
                    "key": "value"
                }
            }
        }
    ]
}
```

`name`  
Tipo: string  
Obrigatório: não  
O nome do volume. São permitidos até 255 letras (caixa alta e baixa), números, hífens (`-`) e sublinhados (`_`). Esse nome é referenciado no parâmetro `sourceVolume` do objeto `mountPoints` de definição do contêiner.

`dockerVolumeConfiguration`  
Tipo: objeto [DockerVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DockerVolumeConfiguration.html)  
Obrigatório: não  
Esse parâmetro é especificado ao usar volumes do Docker. Os volumes do Docker só são compatíveis ao executar tarefas em instâncias do EC2. Os contêineres do Windows só são compatíveis com o uso do driver `local`. Para usar montagens bind, em vez disso, especifique um `host`.    
`scope`  
Tipo: string  
Valores válidos: `task` \$1 `shared`  
Obrigatório: não  
O escopo para o volume do Docker, que determina o ciclo de vida. Os volumes do Docker que são delimitados para uma `task` são provisionados automaticamente quando a tarefa é iniciada e destruídos quando a tarefa é interrompida. Volumes do Docker delimitados como `shared` são mantidos após a interrupção da tarefa.  
`autoprovision`  
Tipo: booliano  
Valor padrão: `false`  
Obrigatório: não  
Se o valor for `true`, o volume de Docker será criado se ele ainda não existir. Esse campo só será usado se `scope` for `shared`. Se `scope` for `task`, esse parâmetro deverá ser omitido.  
`driver`  
Tipo: string  
Obrigatório: não  
O driver do volume do Docker a ser usado. O valor do driver deve corresponder ao nome do driver fornecido pelo Docker porque esse nome é usado no posicionamento de tarefas. Se o driver foi instalado usando a CLI de plug-in do Docker, use `docker plugin ls` para recuperar o nome do driver na instância de contêiner. Se o driver foi instalado usando outro método, use a descoberta de plug-in do Docker para recuperar o nome do driver.  
`driverOpts`  
Tipo: string  
Obrigatório: não  
Um mapa de opções específicas do driver do Docker pelas quais passar. Esse parâmetro é mapeado para `DriverOpts` na seção Criar um volume da API remota do Docker.  
`labels`  
Tipo: string  
Obrigatório: não  
Metadados personalizados para adicionar ao volume do Docker.

`mountPoints`  
Tipo: Matriz de objeto  
Obrigatório: não  
Os pontos de montagem dos volumes de dados no contêiner. Esse parâmetro é mapeado em `Volumes` na API create-container do Docker na opção `--volume` de execução do docker.  
Os contêineres do Windows podem montar diretórios inteiros na mesma unidade como `$env:ProgramData`. Os contêineres do Windows não podem montar diretórios em uma unidade diferente, e os pontos de montagem não podem ser usados ​​entre unidades. Você deve especificar pontos de montagem para anexar um volume do Amazon EBS diretamente a uma tarefa do Amazon ECS.    
`sourceVolume`  
Tipo: string  
Exigido: Sim, quando `mountPoints` são usados  
O nome do volume a ser montado.  
`containerPath`  
Tipo: string  
Exigido: Sim, quando `mountPoints` são usados  
O caminho no contêiner onde o volume será montado.  
`readOnly`  
Tipo: booliano  
Obrigatório: não  
Caso o valor seja `true`, o contêiner tem acesso somente leitura ao volume. Caso esse valor seja `false`, o contêiner pode gravar no volume. O valor padrão é `false`.  
Para tarefas executadas em instâncias do EC2 que executam o sistema operacional Windows, deixe o valor como o padrão de `false`.

# Exemplos de volume do Docker para o Amazon ECS
<a name="docker-volume-examples"></a>

Os exemplos a seguir mostram como fornecer armazenamento temporário para um contêiner, como fornecer um volume compartilhado para vários contêineres e como fornecer armazenamento persistente NFS para um contêiner.

**Para fornecer armazenamento temporário em um contêiner usando um volume do Docker**

Neste exemplo, um contêiner utiliza um volume de dados vazio que é descartado após o término da tarefa. Um exemplo de caso de uso é que você pode ter um contêiner que precisa acessar algum local de armazenamento de arquivos temporários durante uma tarefa. Essa tarefa pode ser realizada usando um volume do Docker.

1. Na seção `volumes` de definição de tarefa, defina um volume de dados com os valores `name` e `DockerVolumeConfiguration`. Neste exemplo, especificamos o escopo como `task` para que o volume seja excluído depois que a tarefa é interrompida e use o driver `local` integrado.

   ```
   "volumes": [
       {
           "name": "scratch",
           "dockerVolumeConfiguration" : {
               "scope": "task",
               "driver": "local",
               "labels": {
                   "scratch": "space"
               }
           }
       }
   ]
   ```

1. Na seção `containerDefinitions`, defina um contêiner com valores `mountPoints` que faz referência ao nome do volume definido e o valor `containerPath` para montar o volume no contêiner.

   ```
   "containerDefinitions": [
       {
           "name": "container-1",
           "mountPoints": [
               {
                 "sourceVolume": "scratch",
                 "containerPath": "/var/scratch"
               }
           ]
       }
   ]
   ```

**Para fornecer armazenamento persistente para vários contêiner usando um volume do Docker**

Neste exemplo, você quer um volume compartilhado para vários contêineres usarem e deseja que ele persista após a interrupção de qualquer tarefa única que o esteja usando. O driver `local` integrado está sendo usado. Isso acontece para que o volume permaneça vinculado ao ciclo de vida da instância de contêiner.

1. Na seção `volumes` de definição de tarefa, defina um volume de dados com os valores `name` e `DockerVolumeConfiguration`. Neste exemplo, especifique um escopo `shared` de forma que o volume persista e defina a provisão automática como `true`. Isso acontece para que o volume seja criado para uso. Então, utilize também o driver `local` incorporado.

   ```
   "volumes": [
       {
           "name": "database",
           "dockerVolumeConfiguration" : {
               "scope": "shared",
               "autoprovision": true,
               "driver": "local",
               "labels": {
                   "database": "database_name"
               }
           }
       }
   ]
   ```

1. Na seção `containerDefinitions`, defina um contêiner com valores `mountPoints` que faz referência ao nome do volume definido e o valor `containerPath` para montar o volume no contêiner.

   ```
   "containerDefinitions": [
       {
           "name": "container-1",
           "mountPoints": [
           {
             "sourceVolume": "database",
             "containerPath": "/var/database"
           }
         ]
       },
       {
         "name": "container-2",
         "mountPoints": [
           {
             "sourceVolume": "database",
             "containerPath": "/var/database"
           }
         ]
       }
     ]
   ```

**Para fornecer armazenamento NFS persistente para um contêiner usando um volume do Docker**

 Neste exemplo, um contêiner utiliza um volume de dados do NFS que é montado automaticamente quando a tarefa é iniciada e desmontado quando a tarefa é interrompida. Isso usa o driver `local` integrado do Docker. Um exemplo de caso de uso: você pode ter um armazenamento NFS local e precisa acessá-lo por meio de uma tarefa do ECS Anywhere. Isso pode ser feito usando uma opção de volume do Docker com driver NFS.

1. Na seção `volumes` de definição de tarefa, defina um volume de dados com os valores `name` e `DockerVolumeConfiguration`. Neste exemplo, especifique um escopo de `task` para que o volume seja desmontado após o término da tarefa. Use o driver `local` e configure o `driverOpts` com as opções `type`, `device` e `o` de acordo. Substitua `NFS_SERVER` pelo endpoint do servidor NFS.

   ```
   "volumes": [
          {
              "name": "NFS",
              "dockerVolumeConfiguration" : {
                  "scope": "task",
                  "driver": "local",
                  "driverOpts": {
                      "type": "nfs",
                      "device": "$NFS_SERVER:/mnt/nfs",
                      "o": "addr=$NFS_SERVER"
                  }
              }
          }
      ]
   ```

1. Na seção `containerDefinitions`, defina um contêiner com valores `mountPoints` que faça referência ao nome do volume definido e o valor `containerPath` para montar o volume no contêiner.

   ```
   "containerDefinitions": [
          {
              "name": "container-1",
              "mountPoints": [
                  {
                    "sourceVolume": "NFS",
                    "containerPath": "/var/nfsmount"
                  }
              ]
          }
      ]
   ```

# Uso de montagens vinculadas com o Amazon ECS
<a name="bind-mounts"></a>

Com montagens vinculadas, um arquivo ou diretório em um host, como uma instância do Amazon EC2, é montado em um contêiner. As montagens bind são compatíveis com tarefas hospedadas em instâncias do Fargate e do Amazon EC2. Montagens vinculadas estão associadas ao ciclo de vida do contêiner que as usa. A partir do momento em que todos os contêineres que utilizam uma montagem bind forem interrompidos, por exemplo, quando uma tarefa é interrompida, os dados serão removidos. Para tarefas hospedadas em instâncias do Amazon EC2, os dados podem ser vinculados ao ciclo de vida da instância do Amazon EC2 do host especificando um `host` e um valor opcional de `sourcePath` na definição de tarefa. Para obter mais informações, consulte [Montagens bind](https://docs.docker.com/engine/storage/bind-mounts/) na documentação do Docker.

Veja a seguir alguns casos de uso comuns de montagens bind.
+ Para fornecer um volume de dados vazio para ser montado em um ou mais contêineres.
+ Para montar um volume de dados de host em um ou mais contêineres.
+ Para compartilhar um volume de dados de um contêiner de origem com outros contêineres na mesma tarefa.
+ Para expor um caminho e seu conteúdo de um Dockerfile para um ou mais contêineres.

## Considerações quando forem usadas montagens bind
<a name="bind-mount-considerations"></a>

Ao usar montagens bind, considere o seguinte.
+ Por padrão, as tarefas hospedadas no AWS Fargate usando a versão da plataforma `1.4.0` ou posterior (Linux) ou `1.0.0` ou posterior (Windows) recebem, no mínimo, 20 GiB de armazenamento temporário para montagens vinculadas. É 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 expor arquivos de um Dockerfile a um volume de dados quando uma tarefa é executada, o plano de dados do Amazon ECS procura uma diretiva `VOLUME`. Se o caminho absoluto especificado na diretiva `VOLUME` é o mesmo que o `containerPath` especificado na definição de tarefa, os dados no caminho da diretiva `VOLUME` são copiados para o volume de dados. No exemplo de Dockerfile a seguir, um arquivo denominado `examplefile` do diretório `/var/log/exported` é gravado no host e, em seguida, montado no contêiner.

  ```
  FROM public.ecr.aws/amazonlinux/amazonlinux:latest
  RUN mkdir -p /var/log/exported
  RUN touch /var/log/exported/examplefile
  VOLUME ["/var/log/exported"]
  ```

  Por padrão, as permissões de volume são definidas como `0755` e o proprietário como `root`. É possível personalizar essas permissões no Dockerfile. O exemplo a seguir define o proprietário do diretório como `node`.

  ```
  FROM public.ecr.aws/amazonlinux/amazonlinux:latest
  RUN yum install -y shadow-utils && yum clean all
  RUN useradd node
  RUN mkdir -p /var/log/exported && chown node:node /var/log/exported
  RUN touch /var/log/exported/examplefile
  USER node
  VOLUME ["/var/log/exported"]
  ```
+ Para tarefas hospedadas em instâncias do Amazon EC2, quando um`host` e `sourcePath` não são especificados, o daemon do Docker gerencia a montagem bind para você. Quando nenhum contêiner fizer referência a essa montagem bind, o serviço de limpeza de tarefas do agente de contêiner do Amazon ECS acabará excluindo-a. Isso ocorre por padrão três horas após o encerramento do contêiner. Porém, é possível configurar essa duração com a variável de agente `ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION`. Para obter mais informações, consulte [Configuração do agente de contêiner do Amazon ECS](ecs-agent-config.md). Se você precisar que esses dados persistam além do ciclo de vida do contêiner, especifique um valor `sourcePath` para a montagem bind.
+ Para tarefas hospedadas em instâncias gerenciadas do Amazon ECS, partes do sistema de arquivos raiz são somente de leitura. As montagens de ligação de leitura/gravação devem utilizar diretórios graváveis, como `/var` para dados persistentes ou `/tmp` para dados temporários. A tentativa de criar montagens vinculadas de leitura/gravação em outros diretórios faz com que a tarefa não seja iniciada, gerando um erro semelhante ao seguinte:

  ```
  error creating empty volume: error while creating volume path '/path': mkdir /path: read-only file system
  ```

  Montagens de associação somente leitura (configuradas com `"readOnly": true` no parâmetro `mountPoints`) podem apontar para qualquer diretório acessível no host.

  Para visualizar uma lista completa dos caminhos graváveis, você pode executar uma tarefa em uma Instância Gerenciada do Amazon ECS e usar o comando para inspecionar a tabela de montagens da instância. Crie uma definição de tarefa com as seguintes configurações para acessar o sistema de arquivos do host:

  ```
  {
      "pidMode": "host",
      "containerDefinitions": [{
          "privileged": true,
          ...
      }]
  }
  ```

  Em seguida, execute os seguintes comandos dentro do contêiner:

  ```
  # List writable mounts
  cat /proc/1/root/proc/1/mounts | awk '$4 ~ /^rw,/ || $4 == "rw" {print $2}' | sort
  
  # List read-only mounts
  cat /proc/1/root/proc/1/mounts | awk '$4 ~ /^ro,/ || $4 == "ro" {print $2}' | sort
  ```
**Importante**  
A configuração `privileged` concede ao contêiner recursos estendidos no host, equivalentes ao acesso root. Neste exemplo, ele é utilizado para examinar a tabela de montagens do host para fins de diagnóstico. Para obter mais informações, consulte [Evitar executar contêineres como privilegiados (Amazon EC2)](security-tasks-containers.md#security-tasks-containers-recommendations-avoid-privileged-containers).

  Para obter mais informações sobre como executar comandos de forma interativa em contêineres, consulte [Monitoramento de contêineres do Amazon ECS com o ECS Exec](ecs-exec.md).

# Especificar uma montagem associada em uma definição de tarefa do Amazon ECS
<a name="specify-bind-mount-config"></a>

Em tarefas do Amazon ECS hospedadas em instâncias do Fargate ou do Amazon EC2, o trecho JSON de definição de tarefa a seguir mostra a sintaxe dos objetos `volumes`, `mountPoints` e `ephemeralStorage` para uma definição de tarefa.

```
{
   "family": "",
   ...
   "containerDefinitions" : [
      {
         "mountPoints" : [
            {
               "containerPath" : "/path/to/mount_volume",
               "sourceVolume" : "string"
            }
          ],
          "name" : "string"
       }
    ],
    ...
    "volumes" : [
       {
          "name" : "string"
       }
    ],
    "ephemeralStorage": {
	   "sizeInGiB": integer
    }
}
```

Para tarefas do Amazon ECS que são hospedadas em instâncias do Amazon EC2, é possível utilizar o parâmetro `host` e um `sourcePath` ao especificar detalhes do volume da tarefa. Quando especificado, ele associa a montagem bind ao ciclo de vida da tarefa no lugar do contêiner.

```
"volumes" : [
    {
        "host" : {
            "sourcePath" : "string"
        },
        "name" : "string"
    }
]
```

A seguir, é descrito em mais detalhes cada parâmetro de definição de tarefa.

`name`  
Tipo: string  
Obrigatório: não  
O nome do volume. São permitidos até 255 letras (caixa alta e baixa), números, hífens (`-`) e sublinhados (`_`). Esse nome é referenciado no parâmetro `sourceVolume` do objeto `mountPoints` de definição do contêiner.

`host`  
Obrigatório: não  
O parâmetro `host` é usado para vincular o ciclo de vida da montagem bind à instância host do Amazon EC2, em vez da tarefa, e onde ela está armazenada. Caso o parâmetro `host` esteja vazio, o daemon do Docker atribui um caminho host para o volume de dados, mas os dados não têm garantia de persistir depois que os contêineres associados deixarem de ser executados.  
Os contêineres do Windows podem montar diretórios inteiros na mesma unidade como `$env:ProgramData`.  
O parâmetro `sourcePath` é compatível apenas quando se utilizam tarefas hospedadas em instâncias do Amazon EC2 ou em instâncias gerenciadas do Amazon ECS.  
`sourcePath`  
Tipo: string  
Obrigatório: não  
Quando o parâmetro `host` é usado, especifique um `sourcePath` para declarar o caminho na instância host do Amazon EC2 que é apresentada ao contêiner. Caso esse parâmetro esteja vazio, o daemon do Docker atribui um caminho host para você. Caso o parâmetro `host` contenha um local de arquivo `sourcePath`, o volume de dados persistirá no local especificado na instância host do Amazon EC2 até você excluí-lo manualmente. Caso o valor `sourcePath` não exista na instância host do Amazon EC2, o daemon do Docker o criará. Caso o local exista, o conteúdo da pasta do caminho de origem é exportado.

`mountPoints`  
Tipo: Matriz de objeto  
Obrigatório: não  
Os pontos de montagem dos volumes de dados no contêiner. Esse parâmetro é mapeado em `Volumes` na API create-container do Docker na opção `--volume` de execução do docker.  
Os contêineres do Windows podem montar diretórios inteiros na mesma unidade como `$env:ProgramData`. Os contêineres do Windows não podem montar diretórios em uma unidade diferente, e os pontos de montagem não podem ser usados ​​entre unidades. Você deve especificar pontos de montagem para anexar um volume do Amazon EBS diretamente a uma tarefa do Amazon ECS.    
`sourceVolume`  
Tipo: string  
Exigido: Sim, quando `mountPoints` são usados  
O nome do volume a ser montado.  
`containerPath`  
Tipo: string  
Exigido: Sim, quando `mountPoints` são usados  
O caminho no contêiner onde o volume será montado.  
`readOnly`  
Tipo: booliano  
Obrigatório: não  
Caso o valor seja `true`, o contêiner tem acesso somente leitura ao volume. Caso esse valor seja `false`, o contêiner pode gravar no volume. O valor padrão é `false`.  
Para tarefas executadas em instâncias do EC2 que executam o sistema operacional Windows, deixe o valor como o padrão de `false`.

`ephemeralStorage`  
Tipo: Objeto  
Obrigatório: não  
A quantidade de armazenamento temporário a ser alocada para a tarefa. Esse parâmetro é usado para expandir a quantidade total de armazenamento temporário, além da quantidade padrão, para tarefas hospedadas no AWS Fargate, usando a versão `1.4.0` ou posterior (Linux) ou `1.0.0` ou posterior (Windows) da plataforma.  
É possível usar a CLI do Copilot, o CloudFormation, o AWS SDK ou a CLI para especificar o armazenamento temporário para uma montagem bind.

# Exemplos de montagem de associação para o Amazon ECS
<a name="bind-mount-examples"></a>

Os exemplos a seguir abrangem casos de uso comuns de uma montagem bind para contêineres.

**Para alocar uma quantidade maior de espaço de armazenamento temporário para uma tarefa do Fargate**

Para tarefas do Amazon ECS hospedadas no Fargate usando a versão `1.4.0` ou posterior (Linux) ou `1.0.0` (windows) da plataforma, você pode alocar mais do que a quantidade padrão de armazenamento temporário para os contêineres da tarefa que serão usados. Esse exemplo pode ser incorporado aos outros exemplos para alocar mais armazenamento temporário para suas tarefas do Fargate.
+ Na definição da tarefa, defina um objeto `ephemeralStorage`. O `sizeInGiB` deve ser um número inteiro entre os valores de `21` e `200` e é expresso em GiB.

  ```
  "ephemeralStorage": {
      "sizeInGiB": integer
  }
  ```

**Para fornecer um volume de dados vazio para um ou mais contêineres**

Em alguns casos, você pode querer fornecer aos contêineres de uma tarefa algum espaço temporário. Por exemplo, você pode ter dois contêineres de banco de dados que precisam acessar o mesmo local de armazenamento de arquivos temporários durante uma tarefa. Isso pode ser feito usando uma montagem bind.

1. Na seção `volumes` da definição de tarefa, defina uma montagem bind com o nome `database_scratch`.

   ```
     "volumes": [
       {
         "name": "database_scratch"
       }
     ]
   ```

1. Na seção `containerDefinitions`, crie as definições de contêiner de banco de dados. Isso deve ser feito para que elas montem o volume.

   ```
   "containerDefinitions": [
       {
         "name": "database1",
         "image": "my-repo/database",
         "cpu": 100,
         "memory": 100,
         "essential": true,
         "mountPoints": [
           {
             "sourceVolume": "database_scratch",
             "containerPath": "/var/scratch"
           }
         ]
       },
       {
         "name": "database2",
         "image": "my-repo/database",
         "cpu": 100,
         "memory": 100,
         "essential": true,
         "mountPoints": [
           {
             "sourceVolume": "database_scratch",
             "containerPath": "/var/scratch"
           }
         ]
       }
     ]
   ```

**Para expor um caminho e seu conteúdo em um Dockerfile para um contêiner**

Neste exemplo, você tem um Dockerfile que grava dados que você quer montar em um contêiner. Este exemplo funciona para tarefas hospedadas em instâncias do Fargate ou do Amazon EC2.

1. Crie um Dockerfile. O exemplo a seguir usa a imagem pública do contêiner do Amazon Linux 2 e cria um arquivo denominado `examplefile` no diretório `/var/log/exported`que queremos montar dentro do contêiner. A diretiva `VOLUME` deve especificar um caminho absoluto.

   ```
   FROM public.ecr.aws/amazonlinux/amazonlinux:latest
   RUN mkdir -p /var/log/exported
   RUN touch /var/log/exported/examplefile
   VOLUME ["/var/log/exported"]
   ```

   Por padrão, as permissões de volume são definidas como `0755` e o proprietário como `root`. Essas permissões podem ser alteradas no Dockerfile. No exemplo a seguir, o proprietário do diretório `/var/log/exported` é definido como `node`.

   ```
   FROM public.ecr.aws/amazonlinux/amazonlinux:latest
   RUN yum install -y shadow-utils && yum clean all
   RUN useradd node
   RUN mkdir -p /var/log/exported && chown node:node /var/log/exported					    
   USER node
   RUN touch /var/log/exported/examplefile
   VOLUME ["/var/log/exported"]
   ```

1. Na seção `volumes` da definição da tarefa, defina um volume com o nome `application_logs`.

   ```
     "volumes": [
       {
         "name": "application_logs"
       }
     ]
   ```

1. Na seção `containerDefinitions`, crie as definições do contêiner da aplicação. Isso deve ser feito para que elas montem o armazenamento. O valor `containerPath` deve corresponder ao caminho absoluto especificado na diretiva `VOLUME` do Dockerfile.

   ```
     "containerDefinitions": [
       {
         "name": "application1",
         "image": "my-repo/application",
         "cpu": 100,
         "memory": 100,
         "essential": true,
         "mountPoints": [
           {
             "sourceVolume": "application_logs",
             "containerPath": "/var/log/exported"
           }
         ]
       },
       {
         "name": "application2",
         "image": "my-repo/application",
         "cpu": 100,
         "memory": 100,
         "essential": true,
         "mountPoints": [
           {
             "sourceVolume": "application_logs",
             "containerPath": "/var/log/exported"
           }
         ]
       }
     ]
   ```

**Para fornecer um volume de dados vazio para um contêiner vinculado ao ciclo de vida da instância host do Amazon EC2**

Para tarefas hospedadas em instâncias do Amazon EC2, você pode usar montagens bind e ter os dados vinculados ao ciclo de vida da instância host do Amazon EC2. É possível fazer isso usando o parâmetro `host` e especificando um valor `sourcePath`. Todos os arquivos existentes em `sourcePath` são apresentados aos contêineres no valor `containerPath`. Todos os arquivos que são gravados no valor `containerPath` são gravados no valor `sourcePath` na instância do host do Amazon EC2.
**Importante**  
O Amazon ECS não sincroniza seu armazenamento entre instâncias do Amazon EC2. As tarefas que usam armazenamento persistente podem ser colocadas em qualquer instância do Amazon EC2, no cluster que tiver capacidade disponível. Se suas tarefas exigirem armazenamento persistente após a interrupção e a reinicialização, sempre especifique a mesma instância do Amazon EC2 no momento da inicialização da tarefa com o comando [start-task](https://docs.aws.amazon.com/cli/latest/reference/ecs/start-task.html) da AWS CLI. Também podem ser usados volumes do Amazon EFS para armazenamento persistente. Para obter mais informações, consulte [Uso de volumes do Amazon EFS com o Amazon ECS](efs-volumes.md).

1. Na seção `volumes` da definição de tarefa, defina uma montagem bind com os valores `name` e `sourcePath`. No exemplo a seguir, a instância host do Amazon EC2 contém dados em `/ecs/webdata` que você quer montar no contêiner.

   ```
     "volumes": [
       {
         "name": "webdata",
         "host": {
           "sourcePath": "/ecs/webdata"
         }
       }
     ]
   ```

1. Na seção `containerDefinitions`, defina um contêiner com um valor `mountPoints` que faça referência ao nome da montagem bind definida e ao valor `containerPath` para montar a montagem bind no contêiner.

   ```
     "containerDefinitions": [
       {
         "name": "web",
         "image": "public.ecr.aws/docker/library/nginx:latest",
         "cpu": 99,
         "memory": 100,
         "portMappings": [
           {
             "containerPort": 80,
             "hostPort": 80
           }
         ],
         "essential": true,
         "mountPoints": [
           {
             "sourceVolume": "webdata",
             "containerPath": "/usr/share/nginx/html"
           }
         ]
       }
     ]
   ```

**Para montar um volume definido em vários contêineres em diferentes locais**

É possível definir um volume de dados em uma definição de tarefa e montar esse volume em locais diferentes em diferentes contêineres. Por exemplo, seu contêiner host tem uma pasta de dados de site em `/data/webroot`. É possível montar esse volume de dados como somente leitura em dois servidores Web diferentes com raízes de documentos distintas.

1. Na seção `volumes` de definição de tarefa, defina um volume de dados com o nome `webroot` e o caminho de origem `/data/webroot`.

   ```
     "volumes": [
       {
         "name": "webroot",
         "host": {
           "sourcePath": "/data/webroot"
         }
       }
     ]
   ```

1. Na seção `containerDefinitions`, defina um contêiner para cada servidor da Web com valores `mountPoints` que associam o volume `webroot` com o valor `containerPath` apontando para a raiz do documento desse contêiner.

   ```
     "containerDefinitions": [
       {
         "name": "web-server-1",
         "image": "my-repo/ubuntu-apache",
         "cpu": 100,
         "memory": 100,
         "portMappings": [
           {
             "containerPort": 80,
             "hostPort": 80
           }
         ],
         "essential": true,
         "mountPoints": [
           {
             "sourceVolume": "webroot",
             "containerPath": "/var/www/html",
             "readOnly": true
           }
         ]
       },
       {
         "name": "web-server-2",
         "image": "my-repo/sles11-apache",
         "cpu": 100,
         "memory": 100,
         "portMappings": [
           {
             "containerPort": 8080,
             "hostPort": 8080
           }
         ],
         "essential": true,
         "mountPoints": [
           {
             "sourceVolume": "webroot",
             "containerPath": "/srv/www/htdocs",
             "readOnly": true
           }
         ]
       }
     ]
   ```

**Para montar volumes de outro contêiner usando `volumesFrom`**

Para tarefas hospedadas em instâncias do Amazon EC2, é possível definir um ou mais volumes em um contêiner e, em seguida, usar o parâmetro `volumesFrom` em uma definição de contêiner diferente (dentro da mesma tarefa) para montar todos os volumes do `sourceContainer` em seus pontos de montagem definidos originalmente. O parâmetro `volumesFrom` se aplica a volumes determinados na definição de tarefa, e os que são incorporados na imagem com um Dockerfile.

1. (Opcional) Para compartilhar um volume incorporado em uma imagem, utilize a instrução `VOLUME` no arquivo Dockerfile. O Dockerfile de exemplo a seguir usa uma imagem `httpd` e, em seguida, adiciona um volume e monta-o em `dockerfile_volume` na raiz do documento Apache. É a pasta usada pelo servidor Web `httpd`.

   ```
   FROM httpd
   VOLUME ["/usr/local/apache2/htdocs/dockerfile_volume"]
   ```

   É possível incorporar uma imagem com esse Dockerfile e enviá-la para um repositório, como o Docker Hub, e usá-la em sua definição de tarefa. A imagem de exemplo `my-repo/httpd_dockerfile_volume` usada nas etapas a seguir foi criada com o Dockerfile anterior.

1. Crie uma definição de tarefa que defina seus outros volumes e pontos de montagem para os contêineres. Nesta seção `volumes` de exemplo, você cria um volume vazio chamado `empty`, que o daemon do Docker gerencia. Há também um volume host definido que se chama `host_etc`. Ele exporta a pasta `/etc` na instância de contêiner host.

   ```
   {
     "family": "test-volumes-from",
     "volumes": [
       {
         "name": "empty",
         "host": {}
       },
       {
         "name": "host_etc",
         "host": {
           "sourcePath": "/etc"
         }
       }
     ],
   ```

   Na seção definições de contêiner, crie um contêiner que monte os volumes definidos anteriormente. Neste exemplo, o contêiner `web` monta os volumes `empty` e `host_etc`. Este é o contêiner que utiliza a imagem criada com um volume no Dockerfile.

   ```
   "containerDefinitions": [
       {
         "name": "web",
         "image": "my-repo/httpd_dockerfile_volume",
         "cpu": 100,
         "memory": 500,
         "portMappings": [
           {
             "containerPort": 80,
             "hostPort": 80
           }
         ],
         "mountPoints": [
           {
             "sourceVolume": "empty",
             "containerPath": "/usr/local/apache2/htdocs/empty_volume"
           },
           {
             "sourceVolume": "host_etc",
             "containerPath": "/usr/local/apache2/htdocs/host_etc"
           }
         ],
         "essential": true
       },
   ```

   Crie outro contêiner que use `volumesFrom` para montar todos os volumes que estão associados com o contêiner `web`. Todos os volumes no contêiner `web` também são montados no contêiner `busybox`. Isso inclui o volume especificado no Dockerfile que foi utilizado para criar a imagem `my-repo/httpd_dockerfile_volume`.

   ```
       {
         "name": "busybox",
         "image": "busybox",
         "volumesFrom": [
           {
             "sourceContainer": "web"
           }
         ],
         "cpu": 100,
         "memory": 500,
         "entryPoint": [
           "sh",
           "-c"
         ],
         "command": [
           "echo $(date) > /usr/local/apache2/htdocs/empty_volume/date && echo $(date) > /usr/local/apache2/htdocs/host_etc/date && echo $(date) > /usr/local/apache2/htdocs/dockerfile_volume/date"
         ],
         "essential": false
       }
     ]
   }
   ```

   Quando essa tarefa é executada, os dois contêineres montam os volumes, e o `command` no contêiner `busybox` grava a data e a hora em um arquivo. Esse arquivo se chama `date` em cada uma das pastas de volume. As pastas ficam visíveis no site exibido pelo contêiner `web`.
**nota**  
Como o contêiner `busybox` executa um comando rápido e, em seguida, é encerrado, ele deve ser definido como `"essential": false` na definição do contêiner. Caso contrário, ele interromperá toda a tarefa quando for encerrado.

# Gerenciar o espaço de memória de troca de contêiner no Amazon ECS
<a name="container-swap"></a>

Com o Amazon ECS, você pode controlar o uso do espaço de memória de troca em suas instâncias do Amazon EC2 baseadas em Linux no nível de contêiner. Utilizando uma configuração de troca de contêiner, cada contêiner de uma definição de tarefa pode ter a troca habilitada ou desabilitada. Para aqueles com troca habilitada, a quantidade máxima de espaço de troca utilizada pode ser limitada. Por exemplo, contêineres críticos para latência podem ter a troca desabilitada. Por outro lado, contêineres com altas demandas de memória transitória podem ter a troca habilitada para reduzir as chances de erros de falta de memória quando o contêiner está sob carga.

A configuração de troca para um contêiner é gerenciada pelos seguintes parâmetros de definição de contêiner.

`maxSwap`  
A quantidade total de memória de troca (em MiB) que um contêiner pode usar. Esse parâmetro será convertido na opção `--memory-swap` para execução do docker em que o valor é a soma da memória do contêiner mais o valor de `maxSwap`.  
Se um valor `maxSwap` de `0` for especificado, o contêiner não usará a troca. Os valores aceitos são `0` ou qualquer número inteiro positivo. Se o parâmetro `maxSwap` for omitido, o contêiner usará a configuração de troca para a instância de contêiner na qual ele está sendo executado. Um valor `maxSwap` deve ser definido para que o parâmetro `swappiness` seja usado.

`swappiness`  
É possível usar isso para ajustar o comportamento de troca de memória de um contêiner. Um valor `swappiness` igual a `0` faz com que a troca não ocorra, a menos que ela seja necessária. Um valor `swappiness` de `100` fará com que as páginas sejam trocadas de forma agressiva. Os valores aceitos são números inteiros entre `0` e `100`. Se o parâmetro `swappiness` não for especificado, será usado um valor padrão de `60`. Se nenhum valor for especificado para `maxSwap`, esse parâmetro será ignorado. Esse parâmetro é mapeado para a opção `--memory-swappiness` de execução do docker.

No exemplo abaixo, é fornecida a sintaxe JSON.

```
"containerDefinitions": [{
        ...
        "linuxParameters": {
            "maxSwap": integer,
            "swappiness": integer
        },
        ...
}]
```

## Considerações
<a name="container-swap-considerations"></a>

Considere o seguinte ao usar uma configuração de troca de contêiner.
+ O espaço de troca deve ser habilitado e alocado na instância do Amazon EC2 que hospeda suas tarefas para os contêineres usarem. As AMIs otimizadas para o Amazon ECS não têm a troca habilitada por padrão. É necessário habilitar a troca na instância para usar esse atributo. Para obter mais informações, consulte [Volumes de troca de armazenamento de instâncias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-store-swap-volumes.html) no *Manual do usuário do Amazon EC2* ou [Como alocar memória para atuar como espaço de troca em uma instância do Amazon EC2?](https://repost.aws/knowledge-center/ec2-memory-swap-file).
+ Os parâmetros de definição de contêiner do espaço de troca são compatíveis apenas com definições de tarefa que especificam o EC2. Esses parâmetros não são compatíveis com definições de tarefa destinadas somente ao uso do Amazon ECS no Fargate.
+ Esse recurso é compatível somente com contêineres do Linux. No momento, não há compatibilidade com contêineres do Windows.
+ Se os parâmetros `maxSwap` e `swappiness` de definição de contêiner forem omitidos de uma definição de tarefa, cada contêiner terá um valor `swappiness` padrão de `60`. Além disso, o limite de uso total de trocas é de duas vezes a memória do contêiner.
+ Se você estiver usando tarefas no Amazon Linux 2023, não haverá suporte para o parâmetro `swappiness`.

# Diferenças de definição de tarefa do Amazon ECS para instâncias gerenciadas do Amazon ECS
<a name="managed-instances-tasks-services"></a>

Para usar as instâncias gerenciadas do Amazon ECS, configure a definição de tarefa para usar o tipo de inicialização de instâncias gerenciadas do Amazon ECS. Há considerações adicionais ao usar instâncias gerenciadas do Amazon ECS.

## Parâmetros de definição de tarefa
<a name="managed-instances-task-parameters"></a>

As tarefas que usam instâncias gerenciadas do Amazon ECS oferecem suporte à maioria dos parâmetros de definição de tarefa do Amazon ECS que estão disponíveis. No entanto, alguns parâmetros têm comportamentos ou limitações específicos quando usados com tarefas de instâncias gerenciadas do Amazon ECS.

Os seguintes parâmetros de definição de tarefa não são válidos nas tarefas das instâncias gerenciadas do Amazon ECS:
+ `disableNetworking`
+ `dnsSearchDomains`
+ `dnsServers`
+ `dockerLabels`
+ `dockerSecurityOptions`
+ `dockerVolumeConfiguration`
+ `ephemeralStorage`
+ `extraHosts`
+ `fsxWindowsFileServerVolumeConfiguration`
+ `hostname`
+ `inferenceAccelerator`
+ `ipcMode`
+ `links`
+ `maxSwap`
+ `proxyConfiguration`
+ `sharedMemorySize`
+ `sourcepath`Volumes do 
+ `swappiness`
+ `tmpfs`

Os seguintes parâmetros de definição de tarefa são válidos nas tarefas das instâncias gerenciadas do Amazon ECS, mas têm limitações que devem ser observadas:
+ `networkConfiguration`: as instâncias gerenciadas do Amazon ECS usam o modo de rede `awsvpc` ou `host`.
+ `placementConstraints`: os atributos de restrição a seguir são compatíveis.
  + `ecs.subnet-id`
  + `ecs.availability-zone`
  + `ecs.instance-type`
  + `ecs.cpu-architecture`
+ `requiresCompatibilities`: deve incluir `MANAGED_INSTANCES` para garantir que a definição de tarefa seja compatível com as instâncias gerenciadas do Amazon ECS.
+ `resourceRequirement`: não há suporte para `InferenceAccelerator`.
+ `operatingSystemFamily`: as instâncias gerenciadas do Amazon ECS usam `LINUX`.
+ `volumes`: ao utilizar montagens de ligação com um `sourcePath`, o caminho deve apontar para um diretório gravável no host. Algumas partes do sistema de arquivos da Instância Gerenciada do Amazon ECS são somente leitura. Os diretórios graváveis incluem `/var` e `/tmp`. Para obter mais informações, consulte [Uso de montagens vinculadas com o Amazon ECS](bind-mounts.md).

Para garantir que sua definição de tarefa seja válida para uso com as instâncias gerenciadas do Amazon ECS, é possível especificar o seguinte ao registrar a definição de tarefa: 
+ No Console de gerenciamento da AWS, para o campo **Requires Compatibilities (Requer compatibilidades)**, especifique `MANAGED_INSTANCES`.
+ Na AWS CLI, especifique a opção `--requires-compatibilities`.
+ Na API do Amazon ECS, especifique o sinalizador `requiresCompatibilities`.

# Diferenças de definição de tarefa do Amazon ECS para o Fargate
<a name="fargate-tasks-services"></a>

Para usar o Fargate, você precisa configurar a definição de tarefa para usar o tipo de execução do Fargate. Há considerações adicionais ao usar o Fargate.

## Parâmetros de definição de tarefa
<a name="fargate-task-parameters"></a>

As tarefas que usam o Fargate não são compatíveis com 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.

Os seguintes parâmetros de definição de tarefa não são válidos nas tarefas do Fargate:
+ `disableNetworking`
+ `dnsSearchDomains`
+ `dnsServers`
+ `dockerSecurityOptions`
+ `extraHosts`
+ `gpu`
+ `ipcMode`
+ `links`
+ `placementConstraints`
+ `privileged`
+ `maxSwap`
+ `swappiness`

Os seguintes parâmetros de definição de tarefa são válidos em tarefas do Fargate, mas têm limitações que devem ser observadas:
+ `linuxParameters`: ao definir opções específicas do Linux que são aplicadas ao contêiner, para `capabilities`, o único recurso possível de ser adicionado é `CAP_SYS_PTRACE`. Os parâmetros `devices`, `sharedMemorySize` e `tmpfs` não têm suporte. Para obter mais informações, consulte [Parâmetros do Linux](task_definition_parameters.md#container_definition_linuxparameters).
+ `volumes`: as tarefas do Fargate só oferecem suporte aos volumes do host de montagem bind e, portanto, não há suporte para o parâmetro `dockerVolumeConfiguration`. Para obter mais informações, consulte [Volumes](task_definition_parameters.md#volumes).
+ `cpu`: para contêineres do Windows no AWS Fargate, o valor não pode ser menor que 1 vCPU.
+ `networkConfiguration`: as tarefas do Fargate sempre usam o modo de rede `awsvpc`.

Para garantir que sua definição de tarefa seja válida para uso com o Fargate, é possível especificar o seguinte quando você registrar a definição de tarefa: 
+ No Console de gerenciamento da AWS, para o campo **Requires Compatibilities (Requer compatibilidades)**, especifique `FARGATE`.
+ Na AWS CLI, especifique a opção `--requires-compatibilities`.
+ Na API do Amazon ECS, especifique o sinalizador `requiresCompatibilities`.

## Arquiteturas e sistemas operacionais
<a name="fargate-task-os"></a>

Quando você configura uma definição de tarefa e de contêiner para AWS Fargate, você deve especificar o sistema operacional que o contêiner executa. Há suporte para os seguintes sistemas operacionais para AWS Fargate:
+ Amazon Linux 2
**nota**  
Os contêineres do Linux usam apenas o kernel e a configuração do kernel do sistema operacional do host. Por exemplo, a configuração do kernel inclui os controles do sistema `sysctl`. Uma imagem de contêiner de Linux pode ser criada a partir de uma imagem base que contenha os arquivos e programas de qualquer distribuição do Linux. Se a arquitetura da CPU corresponder, será possível executar contêineres a partir de qualquer imagem de contêiner de Linux em qualquer sistema operacional.
+ Windows Server 2019 Full
+ Windows Server 2019 Core
+ Windows Server 2022 Full
+ Windows Server 2022 Core

Quando você executar contêineres do Windows no AWS Fargate, você deverá ter uma arquitetura de CPU X86\$164.

Quando você executar contêineres do Linux no AWS Fargate, você pode usar a arquitetura de CPU X86\$164 ou a arquitetura ARM64 para suas aplicações baseadas em ARM. Para obter mais informações, consulte [Definições de tarefa do Amazon ECS para workloads do ARM de 64 bits](ecs-arm64.md).

## CPU e memória da tarefa
<a name="fargate-tasks-size"></a>

As definições de tarefa do Amazon ECS para AWS Fargate exigem que você especifique a CPU e a memória no nível da tarefa. A maioria dos casos de uso são atendidos com a especificação desses recursos somente no nível de tarefa. A tabela a seguir mostra as combinações válidas para CPU e memória em nível de tarefa. É possível especificar valores de memória na definição de tarefa como uma string em MiB ou GB. Por exemplo, você pode especificar um valor de memória como `3072` em MiB ou `3 GB` em GB. Você pode especificar valores de CPU no arquivo JSON como uma string em unidades de CPU ou em CPUs virtuais (vCPUs). Por exemplo, você pode especificar um valor de CPU como `1024` em unidades de CPU ou `1 vCPU` em vCPUs.


|  Valor de CPU  |  Valor de memória  |  Sistemas operacionais com suporte para o AWS Fargate  | 
| --- | --- | --- | 
|  256 (0,25 vCPU)  |  512 MiB, 1 GB, 2 GB  |  Linux  | 
|  512 (0,5 vCPU)  |  1 GB, 2 GB, 3 GB, 4 GB  |  Linux  | 
|  1024 (1 vCPU)  |  2 GB, 3 GB, 4 GB, 5 GB, 6 GB, 7 GB, 8 GB  |  Linux, Windows  | 
|  2048 (2 vCPU)  |  Entre 4 GB e 16 GB em incrementos de 1 GB  |  Linux, Windows  | 
|  4096 (4 vCPU)  |  Entre 8 GB e 30 GB em incrementos de 1 GB  |  Linux, Windows  | 
|  8192 (8 vCPU)  Essa opção requer a plataforma Linux `1.4.0` ou posterior.   |  Entre 16 GB e 60 GB em incrementos de 4 GB  |  Linux  | 
|  16384 (16 vCPU)  Essa opção requer a plataforma Linux `1.4.0` ou posterior.   |  Entre 32 GB e 120 GB em incrementos de 8 GB  |  Linux  | 

## Redes de tarefas
<a name="fargate-tasks-services-networking"></a>

As tarefas do Amazon ECS para AWS Fargate exigem o modo de rede `awsvpc`, que fornece uma interface de rede elástica para cada tarefa. Ao executar uma tarefa ou criar um serviço com esse modo de rede, você deve especificar uma ou mais sub-redes para anexar à interface de rede e um ou mais security groups para aplicar à interface de rede. 

Se você estiver usando sub-redes públicas, decida se um endereço IP público será fornecido à interface de rede. Para uma tarefa do Fargate em uma sub-rede pública, para extrair imagens do contêiner, será preciso que um endereço IP público seja atribuído à interface de rede elástica da tarefa, com uma rota para a Internet ou um gateway NAT que possa encaminhar as solicitações para a Internet. Para que uma tarefa do Fargate em uma sub-rede privada extraia imagens de contêiner, é necessário um gateway NAT na sub-rede para encaminhar solicitações para a Internet. Ao hospedar imagens de contêiner no Amazon ECR, você pode configurar o Amazon ECR para usar um endpoint da VPC de interface. Nesse caso, o endereço IPv4 privado da tarefa é usado para a extração da imagem. Para obter mais informações sobre endpoints de interface do Amazon ECR, 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*.

Este é um exemplo da seção `networkConfiguration` para um serviço do Fargate:

```
"networkConfiguration": { 
   "awsvpcConfiguration": { 
      "assignPublicIp": "ENABLED",
      "securityGroups": [ "sg-12345678" ],
      "subnets": [ "subnet-12345678" ]
   }
}
```

## Limites de recursos de tarefa
<a name="fargate-resource-limits"></a>

As definições de tarefa do Amazon ECS para contêineres do Linux no AWS Fargate oferecem suporte ao parâmetro `ulimits` para definir os limites de recursos a serem estabelecidos para um contêiner.

As definições de tarefa do Amazon ECS para Windows no AWS Fargate não oferecem suporte ao parâmetro `ulimits` para definir os limites de recursos a serem estabelecidos para um contêiner.

As tarefas do Amazon ECS hospedadas no Fargate usam os valores de limite de recursos padrão limitados pelo sistema operacional, com exceção do parâmetro de limite de recursos `nofile`. O limite de recursos `nofile` define uma restrição sobre o número de arquivos abertos que um contêiner pode usar. No Fargate, o limite flexível padrão de `nofile` é ` 65535`, e o limite rígido é `65535`. É possível definir os valores de ambos os limites até `1048576`.

Veja a seguir um exemplo de trecho de definição de tarefa que mostra como definir um limite `nofile` personalizado que tenha sido duplicado:

```
"ulimits": [
    {
       "name": "nofile",
       "softLimit": 2048,
       "hardLimit": 8192
    }
]
```

Para obter mais informações sobre os outros limites de recursos que podem ser ajustados, consulte [Limites de recurso](task_definition_parameters.md#container_definition_limits).

## Registro em log
<a name="fargate-tasks-logging"></a>

### Registro em log de eventos
<a name="fargate-event-logging"></a>

O Amazon ECS registra em log as ações que realiza no EventBridge. É possível usar os eventos do Amazon ECS para o Eventbridge receber notificações quase em tempo real quanto ao estado atual dos clusters, serviços e tarefas do Amazon ECS. Além disso, é possível automatizar ações para responder a esses eventos. Para obter mais informações, consulte [Automatização de respostas a erros do Amazon ECS usando o EventBridge](cloudwatch_event_stream.md).

### Registro em log do ciclo de vida da tarefa
<a name="fargate-task-status"></a>

As tarefas executadas no Fargate publicam registros de data e hora para rastrear a tarefa nos estados do ciclo de vida da tarefa. É possível ver os registros de data e hora nos detalhes da tarefa no Console de gerenciamento da AWS, e com a descrição da tarefa na AWS CLI e nos SDKs. Por exemplo, é possível usar os carimbos de data/hora para avaliar quanto tempo a tarefa gastou baixando as imagens do contêiner e decidir se você deve otimizar o tamanho da imagem do contêiner ou usar índices Seekable OCI. Para obter mais informações sobre práticas de imagens de contêiner, consulte [Práticas recomendadas para imagens de contêiner do Amazon ECS](container-considerations.md).

### Registro em log de aplicações
<a name="fargate-app-logging"></a>

As definições de tarefa do Amazon ECS para AWS Fargate oferecem suporte aos drivers de log `awslogs`, `splunk` e `awsfirelens` para a configuração do log.

O driver de log `awslogs` configura as tarefas do Fargate para enviar informações de log ao Amazon CloudWatch Logs. A tabela a seguir mostra um trecho de uma definição de tarefa em que o driver de log `awslogs` está configurado:

```
"logConfiguration": { 
   "logDriver": "awslogs",
   "options": { 
      "awslogs-group" : "/ecs/fargate-task-definition",
      "awslogs-region": "us-east-1",
      "awslogs-stream-prefix": "ecs"
   }
}
```

Para obter mais informações sobre como usar o driver de log `awslogs` em uma definição de tarefa para enviar os logs de contêiner para o CloudWatch Logs, consulte [Envio de logs do Amazon ECS para o CloudWatch](using_awslogs.md).

Para obter mais informações sobre o driver de log `awsfirelens` em uma definição de tarefa, consulte [Envio de logs do Amazon ECS para um serviço da AWS ou para uma AWS Partner](using_firelens.md).

Para obter mais informações sobre como usar o driver de log `splunk` em uma definição de tarefa, consulte [Driver de log do `splunk`](example_task_definitions.md#example_task_definition-splunk).

## Armazenamento de tarefas
<a name="fargate-tasks-storage"></a>

Para tarefas do Amazon ECS hospedadas no Fargate, os seguintes tipos de armazenamento são compatíveis:
+ Os volumes do Amazon EBS fornecem armazenamento em blocos econômico, durável e de alto desempenho para workloads em contêineres com uso intenso de dados. Para obter mais informações, consulte [Uso de volumes do Amazon EBS com o Amazon ECS](ebs-volumes.md).
+ Os volumes do Amazon EFS para armazenamento persistente. Para obter mais informações, consulte [Uso de volumes do Amazon EFS com o Amazon ECS](efs-volumes.md).
+ Montagens bind para armazenamento temporário. Para obter mais informações, consulte [Uso de montagens vinculadas com o Amazon ECS](bind-mounts.md).

## Carregamento lento de imagens de contêiner usando Seekable OCI (SOCI)
<a name="fargate-tasks-soci-images"></a>

As tarefas do Amazon ECS no Fargate que usam a versão da plataforma Linux `1.4.0` podem usar o Seekable OCI (SOCI) para ajudar a iniciar tarefas mais rapidamente. Com o SOCI, os contêineres gastam apenas alguns segundos na extração da imagem antes de serem iniciados, fornecendo tempo para a configuração do ambiente e a instanciação da aplicação enquanto a imagem é baixada em segundo plano. Isso é chamado de *carregamento lento*. Quando o Fargate inicia uma tarefa do Amazon ECS, o Fargate detecta automaticamente se existe um índice SOCI para uma imagem na tarefa e inicia o contêiner sem esperar que a imagem inteira seja baixada.

Para contêineres executados sem índices SOCI, as imagens do contêiner são baixadas completamente antes de o contêiner ser iniciado. Esse comportamento é o mesmo em todas as outras versões da plataforma do Fargate e na AMI otimizada para Amazon ECS em instâncias do Amazon EC2.

O Seekable OCI (SOCI) é uma tecnologia de código aberto desenvolvida pela AWS que pode iniciar contêineres mais rapidamente carregando lentamente a imagem do contêiner. O SOCI funciona criando um índice (Índice SOCI) dos arquivos em uma imagem de contêiner existente. Esse índice ajuda a iniciar contêineres mais rapidamente, fornecendo a capacidade de extrair um arquivo individual de uma imagem de contêiner antes de baixar a imagem inteira. O índice SOCI deve ser armazenado como um artefato no mesmo repositório da imagem no registro do contêiner. Você só deve usar índices SOCI de fontes confiáveis, pois o índice é a fonte autorizada do conteúdo da imagem. Para obter mais informações, consulte [Introdução ao Seekable OCI para o carregamento lento de imagens de contêiner](https://aws.amazon.com/about-aws/whats-new/2022/09/introducing-seekable-oci-lazy-loading-container-images/).

Os clientes que quiserem usar o SOCI só poderão usar o SOCI Index Manifest v2. Os clientes existentes que já tiverem usado o SOCI no Fargate poderão continuar usando o SOCI Index Manifest v1, no entanto, recomendamos fortemente que esses clientes migrem para o SOCI Index Manifest v2. O SOCI Index Manifest v2 cria uma relação explícita entre imagens de contêiner e seus índices SOCI para garantir implantações consistentes.
<a name="fargate-soci-considerations"></a>
**Considerações**  
Se você quiser que o Fargate use um índice SOCI para carregar imagens de contêiner lentamente em uma tarefa, considere o seguinte:
+ Somente tarefas executadas na versão da plataforma Linux `1.4.0` podem usar índices SOCI. Não há suporte para tarefas executadas em contêineres do Windows no Fargate.
+ Não há suporte para tarefas executadas nas arquitetura de CPU X86\$164 ou ARM64.
+ As imagens de contêiner na definição da tarefa devem ser armazenadas em um registro de imagens compatível. A seguir, são listados os registros compatíveis:
  + Registros privados do Amazon ECR.
+ Só há suporte para as imagens de contêiner que usem compactação gzip ou não sejam compactadas. Não há suporte para imagens de contêiner que usem compactação zstd.
+ Para o SOCI Index Manifest v2, a geração de um manifesto do índice SOCI modifica o manifesto da imagem do contêiner conforme adicionamos uma anotação ao índice SOCI. Isso resulta em um novo resumo da imagem do contêiner. O conteúdo das camadas do sistema de arquivos das imagens do contêiner não muda.
+ Para o SOCI Index Manifest v2, quando a imagem do contêiner já tiver sido armazenada no repositório de imagens do contêiner, depois que um índice SOCI tiver sido gerado, você precisará reenviar a imagem do contêiner. O reenvio de uma imagem de contêiner não aumentará os custos de armazenamento ao duplicar as camadas do sistema de arquivos, apenas carregará um novo arquivo de manifesto.
+ Recomendamos que você experimente o carregamento lento com imagens de contêiner maiores que 250 MiB compactadas em tamanho. É menos provável que você veja uma redução no tempo de carregamento de imagens menores.
+ Como o carregamento lento pode alterar o tempo de início das tarefas, talvez seja necessário alterar vários tempos limite, como o período de carência da verificação de integridade do Elastic Load Balancing.
+ Se você quiser evitar que uma imagem de contêiner seja carregada lentamente, a imagem do contêiner precisará ser reenviada sem um índice SOCI anexado.
<a name="create-soci"></a>
**Criação de um índice Seekable OCI**  
Para que uma imagem de contêiner seja carregada lentamente, ela precisa de um índice SOCI (um arquivo de metadados) criado e armazenado no repositório de imagens do contêiner com a imagem do contêiner. Para criar e fazer push de um índice SOCI, é possível usar a [ferramenta de CLI soci-snapshotter](https://github.com/awslabs/soci-snapshotter) de código aberto no GitHub. Você também pode implantar o AWS SOCI Index Builder do CloudFormation. Essa é uma solução sem servidor que cria e faz push de um índice SOCI automaticamente quando uma imagem de contêiner é enviada por push para o Amazon ECR. Para obter mais informações sobre a solução e as etapas de instalação, consulte [CloudFormation AWS SOCI Index Builder](https://awslabs.github.io/cfn-ecr-aws-soci-index-builder/) no GitHub. O AWS SOCI Index Builder do CloudFormation é uma maneira de automatizar a introdução ao SOCI, enquanto a ferramenta SOCI de código aberto tem mais flexibilidade na geração de índices e a capacidade de integrar a geração de índices nos pipelines de integração contínua e entrega contínua (CI/CD).

**nota**  
Para que o índice SOCI seja criado para uma imagem, a imagem deve existir no armazenamento de imagens do containerd no computador com o `soci-snapshotter` em execução. Se a imagem estiver no armazenamento de imagens do Docker, ela não poderá ser encontrada.
<a name="verify-soci"></a>
**Verificação se uma tarefa usou carregamento lento**  
Para verificar se uma tarefa foi carregada lentamente usando o SOCI, verifique o endpoint de metadados da tarefa de dentro da tarefa. Quando você consulta o endpoint de metadados de tarefa versão 4, há um campo `Snapshotter` no caminho padrão do contêiner do qual você está consultando. Além disso, há campos `Snapshotter` para cada contêiner no caminho `/task`. O valor padrão para esse campo é `overlayfs`, e esse campo será definido como `soci` se o SOCI for usado. Para verificar se uma imagem de contêiner tem um SOCI Index Manifest v2 anexado, você pode recuperar o índice de imagem do Amazon ECR usando o AWS CLI.

```
IMAGE_REPOSITORY=r
IMAGE_TAG=latest

aws ecr batch-get-image \
    --repository-name=$IMAGE_REPOSITORY \
    --image-ids imageTag=$IMAGE_TAG \
    --query 'images[0].imageManifest' --output text | jq -r '.manifests[] | select(.artifactType=="application/vnd.amazon.soci.index.v2+json")'
```

Para verificar se uma imagem de contêiner tem um SOCI Index Manifest v1 anexado, você pode usar a API OCI Referrers.

```
ACCOUNT_ID=111222333444
AWS_REGION=us-east-1
IMAGE_REPOSITORY=nginx-demo
IMAGE_TAG=latest
IMAGE_DIGEST=$(aws ecr describe-images --repository-name $IMAGE_REPOSITORY --image-ids imageTag=$IMAGE_TAG --query 'imageDetails[0].imageDigest' --output text)
ECR_PASSWORD=$(aws ecr get-login-password)

curl \
    --silent \
    --user AWS:$ECR_PASSWORD \
    https://$ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/v2/$IMAGE_REPOSITORY/referrers/$IMAGE_DIGEST?artifactType=application%2Fvnd.amazon.soci.index.v1%2Bjson | jq -r '.'
```

# Diferenças de definição de tarefa do Amazon ECS para instâncias do EC2 executando o Windows
<a name="windows_task_definitions"></a>

As tarefas executadas em instâncias do EC2 do Windows não oferecem suporte a todos os parâmetros de definição de tarefa disponíveis do Amazon ECS. Alguns parâmetros são totalmente incompatíveis e outros se comportam de maneira diferente.

Os seguintes parâmetros de definição de tarefa não são compatíveis com definições de tarefa do Amazon EC2 do Windows:
+ `containerDefinitions`
  + `disableNetworking`
  + `dnsServers`
  + `dnsSearchDomains`
  + `extraHosts`
  + `links`
  + `linuxParameters`
  + `privileged`
  + `readonlyRootFilesystem`
  + `user`
  + `ulimits`
+ `volumes`
  + `dockerVolumeConfiguration`
+ `cpu`

  É recomendável especificar a CPU em nível de contêiner para contêineres do Windows.
+ `memory`

  É recomendável especificar a memória em nível de contêiner para contêineres do Windows.
+ `proxyConfiguration`
+ `ipcMode`
+ `pidMode`
+ `taskRoleArn`

  Os perfis do IAM para tarefas em recursos de instâncias do Windows para EC2 exigem uma configuração adicional, mas boa parte dela é semelhante à configuração de perfis do IAM para tarefas em instâncias de contêiner do Linux. Para obter mais informações, consulte [Configuração adicional de instância do Windows no Amazon EC2](task-iam-roles.md#windows_task_IAM_roles).