ECS vs EKS: Orquestração de Containers
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) |
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.
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?
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.
Discussão
Carregando…