ECS vs EKS: Orquestração de Containers
- ⬜⚖️ EC2 Profissional: Auto Scaling e Load Balancers(AWS Solutions Architect Associate)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Containers dominaram deploys modernos. A AWS oferece 3 serviços principais: ECS (orquestrador proprietário), EKS (Kubernetes gerenciado) e ECR (registry). Cada um pode rodar sobre EC2 ou Fargate. O SAA-C03 exige saber quando cada combinação faz sentido.
Onde isso entra no exame
Container questions foram muito expandidas no SAA-C03 vs SAA-C02. Esperar: ECS vs EKS trade-offs, launch type decisions, service discovery, task vs service, IAM roles (task role vs execution role).
A família de serviços de container
| Serviço | Função |
|---|---|
| Amazon ECR | Container Registry (armazena images, tipo Docker Hub privado) |
| Amazon ECS | Orquestrador proprietário AWS |
| Amazon EKS | Kubernetes gerenciado (upstream K8s) |
| AWS Fargate | Serverless compute para containers (usado por ECS e EKS) |
| AWS App Runner | PaaS "deploy de container" para apps simples web |
| AWS Copilot | CLI que abstrai ECS/Fargate setup |
| AWS Proton | Templates de infra para dev platforms (internal PaaS) |
- → pull da imagem
- → pull da imagem
- → agenda task
- → agenda task
- → agenda pod
- → agenda pod
- → roteia
- → credencial temporária
- Compute
- Rede e entrega
- Segurança e identidade
- Gestão e governança
Duas escolhas ortogonais: orquestrador e plano de dados. As quatro combinações são válidas, e a questão sempre dá uma pista de cada eixo — "não usamos Kubernetes" e "não queremos gerenciar servidor" apontam para ECS sobre Fargate.
- Separe as duas perguntas. A escolha de container tem dois eixos independentes: QUAL orquestrador (ECS ou EKS) e ONDE ele roda (Fargate ou EC2). A prova mistura os dois numa só alternativa para ver se você separa.
- ECS vs EKS é decisão de ecossistema. ECS é mais simples, integra direto com IAM e ALB, e o plano de controle é grátis. EKS é Kubernetes de verdade: vale quando o time já tem Helm, operators e manifestos, ou quando portabilidade entre nuvens é requisito. "Menor esforço operacional e não usamos Kubernetes" → ECS.
- Fargate vs EC2 é decisão de responsabilidade. Fargate: sem host para patchear, cobrança por vCPU e memória da task, escala por task. EC2: você controla tipo de instância, pode usar Spot e GPU, e assume o patch. "Não queremos gerenciar servidor" → Fargate.
- Permissão é por task, não por host. Task Role dá credencial temporária para aquela task específica. Instance Profile na EC2 daria a permissão para TODO container no host — violação de menor privilégio que aparece como alternativa errada.
- ECR fecha o ciclo. Registry privado na sua conta, com scan de imagem e política de lifecycle. Autenticação por IAM, então nada de credencial de registry em pipeline.
Amazon ECS — conceitos
- • Cluster — agrupamento lógico de capacity (EC2 ou Fargate)
- • Task Definition — JSON: containerDefinitions[], cpu, memory, networkMode, taskRole, executionRole
- • Task — 1 ou mais containers rodando juntos (mesmo network namespace). Análogo a Pod do K8s.
- • Service — gerencia tasks desejadas, replacement em falha, integração com ALB/NLB.
- • Capacity Provider — estratégia de capacity (mix Fargate + Fargate Spot + EC2).
ECS Launch Types
| Aspecto | EC2 launch type | Fargate launch type |
|---|---|---|
| Host management | Você gerencia EC2 | AWS gerencia (serverless) |
| Pricing | Por EC2 (horas de instância) | Por vCPU-segundo + GB-segundo |
| Scaling | ASG de EC2 + ECS service scaling | Service scaling (0→N tasks diretamente) |
| Patching/OS | Você mantém | AWS mantém |
| GPU support | Sim (via EC2 GPU) | Não |
| Windows containers | Sim | Sim (desde 2021) |
| Daemon tasks (1 per host) | Sim | Não |
| Uso | Cargas grandes/constantes, controle granular | Variável, pequena/média, sem overhead |
Network Modes do ECS
| Mode | Uso |
|---|---|
| awsvpc (default Fargate) | Cada task tem ENI própria com IP privado da VPC — ideal, mais isolamento |
| bridge (EC2 only) | Docker bridge network — port mapping tradicional |
| host (EC2 only) | Task usa network stack do host — latência mínima, mas colisão de portas |
| none | Sem networking externo |
IAM Roles em ECS
| Role | Função |
|---|---|
| Task Role | Permissões do CÓDIGO da task (acessar S3, DynamoDB, etc.) |
| Task Execution Role | Permissões do ECS Agent para pull de ECR, enviar logs a CloudWatch, fetch de secrets |
| EC2 Instance Role (EC2 launch only) | Permissões da EC2 onde o ECS agent roda |
Confusão comum: pergunta “qual role dar para task poder ler bucket S3?” — resposta é Task Role (não Execution Role). Execution Role é para infraestrutura do ECS (pull image, push logs).
Service Discovery no ECS
- • AWS Cloud Map — registry de serviços com DNS privado (service.local)
- • ECS Service Connect — service mesh leve nativo para ECS, com observability automática
- • ALB — atrás de ALB, target group tipo IP para Fargate
Amazon EKS — Kubernetes gerenciado
3 tipos de worker nodes:
| Tipo | Descrição |
|---|---|
| Managed Node Groups | AWS provisiona/updata EC2 no seu EKS cluster |
| Self-managed Nodes | Você cria ASG, registra no cluster, controla tudo |
| Fargate Profile | Pods rodam em Fargate (serverless), selecionados por namespace/labels |
EKS Auto Mode (2024): AWS lançou modo em que a AWS gerencia nodes + Karpenter + componentes de rede, deixando EKS quase tão zero-ops quanto ECS + Fargate. Tendência do exame: esperar questões nesse modelo.
Um time sem experiência em Kubernetes precisa rodar containers com o menor esforço operacional possível. Qual combinação?
ECS vs EKS — a decisão
| Critério | ECS | EKS |
|---|---|---|
| Complexidade | Baixa — tudo AWS-native | Alta — Kubernetes tem learning curve |
| Portabilidade | Locked-in AWS | Portátil (K8s upstream) |
| Ecossistema | AWS-only | Helm charts, operators, tooling vasto |
| Preço control plane | Grátis | $0,10/h por cluster (~$73/mês) |
| Hybrid/Multi-cloud | Não | EKS Anywhere (on-prem), integração com outros K8s |
| Quando escolher | Greenfield AWS, time pequeno | Time K8s experiente, workloads portáveis, multi-cloud |
Ingress em EKS
- • AWS Load Balancer Controller — cria ALB/NLB a partir de Ingress / Service objects
- • Service type: LoadBalancer → provisiona NLB (L4)
- • Ingress → ALB (L7, path/host routing)
- • Target mode (pods recebem tráfego direto) ou (via NodePort)
ECR — Elastic Container Registry
- • Registry privado para Docker/OCI images
- • Integrado com IAM (authN via )
- • Scanning básico gratuito (CVE) + scanning avançado via Inspector
- • Lifecycle policies (ex: deletar images não-usadas há 30 dias)
- • Replicação cross-region e cross-account
- • ECR Public — registry público (aparecem em gallery.ecr.aws)
App Runner — alternativa simples
Para apps web HTTP simples, App Runner pega uma imagem de ECR (ou source do GitHub) e deploya com scaling automático, TLS gerenciado, custom domain. Zero orquestração visível. Ideal para MVP, side projects, APIs que não justificam ECS/EKS.
Cenários de decisão
📋 Startup com time pequeno, quer deploy de microservices em Docker sem overhead
Zero gestão de cluster, Fargate cobra por uso, ALB faz roteamento. Setup simples com CodeDeploy/Copilot. EKS adicionaria complexidade desnecessária.
📋 Empresa usa Kubernetes on-prem há 3 anos, quer migrar para AWS mantendo Helm charts
EKS é Kubernetes upstream — zero mudança em manifests, Helm, operators. Migração acontece com kubectl apply. ECS exigiria re-arquitetar.
📋 Batch job que roda 4x/dia por 30min, processa filas SQS
Fargate Spot dá até 70% off. Batch é tolerante a interrupção. ECS Service configurado com capacity provider mix resolve.
📋 App simples em Python/Go que precisa estar online 24/7 com HTTPS
App Runner cuida de tudo: cert TLS, scaling, custom domain, deploy automático do GitHub. Não precisa pensar em cluster. Custo proporcional ao uso.
📋 Cluster EKS com pods que precisam de GPUs para ML inference
Fargate não suporta GPU. Managed Node Group com instance family g5 (NVIDIA A10G). Pod spec seleciona GPU via node selector + device plugin.
Pegadinhas ECS/EKS no SAA:
Perguntas típicas (Q&A)
❓ Como passar env vars secretas para um container?
❓ Como deploy zero-downtime em ECS?
❓ ECS em EC2 launch type — como a instância sabe que faz parte do cluster?
❓ EKS — como dar permissão IAM a um pod específico?
Perguntas frequentes
❓ ECS ou EKS: como escolher?
❓ Fargate ou instância como base do contêiner?
❓ Como um contêiner encontra o outro?
Fixando
Qual role dá ao SEU container permissão para ler um bucket S3?
Numa Task Definition com network mode awsvpc no Fargate, como o ALB roteia para a task?
Take-aways: ECS = orquestrador AWS-native simples (Cluster/Service/Task Definition/Task). EKS = Kubernetes upstream gerenciado. Ambos rodam em EC2 ou Fargate (serverless). Fargate = sem gestão de host, pay-per-use; EC2 = controle + possível menor custo em scale. Task Role (código) ≠ Execution Role (agent). Service Discovery via Cloud Map ou Service Connect. ECR = registry privado. App Runner = PaaS para apps simples sem orquestração.
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…