Detalhes do Amazon ECS
1. Estrutura de Clusters e Capacidade
1.1 Capacity Providers
- Capacidade gerenciada: Capacity providers permitem que você gerencie de forma dinâmica a capacidade de um cluster ECS. É possível especificar estratégias de escalabilidade que ajustem automaticamente a quantidade de instâncias EC2, equilibrando custo e disponibilidade.
- Auto Scaling Avançado: Combine Auto Scaling groups com capacity providers para reagir a picos de demanda. Você pode definir métricas que disparam a adição (ou remoção) de instâncias. Assim, o cluster automaticamente mantém a capacidade ideal para que as tarefas ECS sejam executadas sem interrupções.
1.2 EC2 x Fargate: Critérios Avançados de Escolha
- EC2:
- Maior controle do SO e da camada de rede, possibilitando otimizações específicas, como ajustes de kernel, uso de instâncias otimizadas para GPU e acesso direto ao servidor para ferramentas de segurança de terceiros.
- Maior responsabilidade de patch e manutenção das AMIs.
- Fargate:
- Simplifica a gestão de infraestrutura ao não expor o SO subjacente.
- Remove a necessidade de gerenciar escalabilidade de cluster, pois cada tarefa (task) ganha recursos isolados.
- Excelente para workloads com tamanho variável e que se beneficiam de um custo baseado em uso por segundo.
---
2. Task Definitions: Recursos Avançados
2.1 Montagem de Volumes e Storage
- Amazon EFS:
- Permite configurar volumes compartilhados entre containers ou serviços diferentes, mantendo dados persistentes.
- Útil para aplicações que precisam de acesso simultâneo ao mesmo volume (por exemplo, sistemas de cache ou upload de arquivos).
- Atenção às permissões de arquivo e à encriptação em repouso (EFS oferece criptografia nativa).
- Ephemeral Storage:
- Possível configurar espaço de armazenamento efêmero adicional em Fargate (até 200 GiB) ou usar discos locais em instâncias EC2.
- Ideal para caches temporários, manipulação de arquivos de curto prazo, mas lembre-se de que os dados não são persistidos após interrupção da tarefa.
2.2 Configurações de Rede
- Bridge x Host x AWSVPC
- Bridge Mode: Cria uma rede Docker separada, mapeando portas para o host. Útil quando você tem múltiplos containers executando na mesma instância com portas semelhantes.
- Host Mode: O container compartilha a mesma stack de rede da instância. Traz menor sobrecarga, mas requer cuidado para evitar conflitos de porta.
- AWSVPC Mode: Cada tarefa recebe um endereço IP próprio na VPC. Maior isolamento e rastreabilidade de tráfego, recomendado para microserviços que requerem segurança granular (melhor prática atual).
2.3 Secrets e Configurações
- Secrets Manager e Parameter Store
- Você pode injetar segredos em variáveis de ambiente ou em arquivos no container, consumindo-os diretamente do AWS Secrets Manager ou AWS Systems Manager Parameter Store.
- Use a sintaxe "{\"SecretsManagerSecret\":\" no arquivo de definição para simplificar a configuração.
---
3. Segurança Avançada
3.1 IAM Roles for Tasks
- Menor Privilégio: Sempre crie uma IAM role específica para cada tipo de tarefa, definindo apenas as ações necessárias.
- Isolamento entre Containers: Ao invés de um role único para todo o cluster, atribua diferentes roles a cada serviço (ou task) para evitar acessos indevidos a recursos não relacionados.
3.2 Controle de Rede e Zero Trust
- Network ACLs e Security Groups:
- Para tarefas que usem awsvpc, cada tarefa pode ter seu próprio security group. Isso permite um controle altamente refinado de tráfego ingress e egress.
- Considere agrupar serviços back-end em subnets privadas, usando um NAT Gateway para acesso à internet, deixando apenas front-ends voltados ao público em subnets públicas.
- AWS Verified Access (ZTA):
- Se sua arquitetura for desenhada com zero trust em mente, pode ser vantajoso integrar o ECS a soluções de VPN-less access e checagens de contexto para cada solicitação, dependendo do modelo de governança.
3.3 Patching e Imagens Seguras
- Ciclo de Vida de Imagens
- Automatize a verificação de vulnerabilidades de imagens via Amazon ECR image scanning ou ferramentas de terceiros (Twistlock, Aqua Security, etc.).
- Crie um pipeline de CI/CD que interrompe o build se detecções de alto risco forem encontradas.
- Atualização de AMIs (EC2)
- Se estiver usando instâncias EC2, crie um processo regular de patching e atualização das AMIs (por exemplo, via EC2 Image Builder) para manter o SO atualizado e reduzir falhas de segurança.
3.4 IDS/IPS e Integração com GuardDuty
- Amazon GuardDuty
- Monitora tráfego de rede e chamadas de API dentro da sua conta AWS, identificando atividades potencialmente maliciosas.
- Importante habilitar a integração com o ECR e a VPC para detecção de comportamentos suspeitos relacionados a containers (por exemplo, mineração de criptomoeda ou varreduras de porta).
- AWS Security Hub
- Centraliza achados de segurança, incluindo integrações com GuardDuty, AWS Config e soluções de terceiros.
- Possibilita criar automated response via Amazon EventBridge para remediação rápida de incidentes.
---
4. Observabilidade e Monitoração
4.1 Logs e Métricas
- CloudWatch Logs
- Cada container pode enviar logs de aplicação diretamente para o CloudWatch.
- Configure log drivers (por exemplo, awslogs, fluentd, splunk) para encaminhar dados de log para o destino desejado.
- Container Insights
- Disponibiliza métricas detalhadas de CPU, memória, uso de disco, rede, além de insights sobre a performance de cada tarefa ou serviço ECS.
- Ajuda a identificar gargalos e comportamentos anormais.
4.2 Distribuição de Tracing e Telemetria
- AWS X-Ray
- Monitora transações distribuídas entre diferentes serviços microserviços.
- Agrega métricas, latência e logs associados a requisições de ponta a ponta, facilitando a detecção de problemas de desempenho e mapeamento de dependências.
4.3 Estrutura de Deployment
- Circuit Breakers e Deployments Rolling
- O ECS suporta circuit breaker para interromper de forma automática implantações que falharem ou demorarem muito tempo para estabilizar.
- Tenha métricas definidas (por exemplo, erros HTTP 5xx) que disparem a reversão automática antes que problemas se propaguem em ambiente de produção.
---
5. Estratégias de Alta Disponibilidade e Disaster Recovery
5.1 Multi-AZ
- Serviços ECS podem ser configurados para executar tarefas em múltiplas zonas de disponibilidade (AZs), aumentando a resiliência a falhas de infraestrutura.
5.2 Cross-Region Replication
- ECR Cross-Region
- Caso precise de maior resiliência de imagens, habilite a replicação para que as imagens fiquem disponíveis em diferentes regiões.
- Útil para arquiteturas de DR (Disaster Recovery), em que é necessário trazer aplicações rapidamente em outra região.
5.3 Backup e Versões de Imagens
- Versionamento de Imagens
- Sempre versionar suas imagens Docker (tags sem ambiguidade) para reverter rapidamente em casos de incidentes.
- Snapshots de Configurações
- Utilize o AWS CloudFormation ou Terraform para gerenciar a infraestrutura como código. Assim, sua configuração de ECS (serviços, tasks, IAM, redes etc.) pode ser reproduzida em outro ambiente em caso de desastre.
---
6. Casos Específicos e Boas Práticas
6.1 ECS Exec: Depuração Segura de Containers
- ECS Exec
- Permite que você acesse o shell dentro de um container em execução, de forma análoga ao kubectl exec no Kubernetes.
- Requer configuração do AWS Systems Manager (SSM), que gerencia esse acesso de forma segura e auditável (todos os comandos são registrados em CloudTrail, se habilitado).
6.2 Integração com Outras Soluções
- AWS WAF
- Se você estiver publicando serviços via ALB (Application Load Balancer), é possível integrar com AWS WAF para proteção de camadas 7, bloqueando SQL injection, XSS e outras ameaças de aplicação.
- Shield e Firewall Manager
- Para workloads críticas que exigem proteção contra DDoS, ative o AWS Shield Advanced e gerencie regras de bloqueio proativas via AWS Firewall Manager.
6.3 Políticas de Governança
- AWS Organizations & Service Control Policies (SCPs)
- Restringe globalmente algumas ações ou serviços em contas específicas para reduzir risco de mau uso.
- Exemplo: bloquear a criação de recursos ECS fora de determinada região, ou proibir acesso de root a mudanças no cluster.
---