📦

ECS vs EKS: Orquestração de Containers

⏱ 13 min de leitura·+70 XP

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

📘 Domain 3 — High-Performing Architectures· 24%

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

🗺️ Hierarquia ECS


   Cluster (agrupamento lógico)
    │
    ├── Task Definition (receita: imagem, CPU, RAM, portas)
    │
    ├── Task (instância rodando da task definition)
    │
    └── Service (mantém N tasks, integra com LB, faz rolling deploy)

   Capacity Providers: Fargate | EC2 | Fargate Spot | EC2 Spot

• 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

🗺️ Arquitetura EKS


   Control Plane (gerenciado AWS)
   ┌────────────────────────────────┐
   │ API Server  etcd  Scheduler    │  ← AWS mantém e patchea
   │ Controller  Cloud Controller   │     multi-AZ, HA automático
   └────────────┬───────────────────┘
                │
   ┌────────────┴────────────────┐
   │ Worker Nodes (você gerencia) │
   │ ┌──────────┐  ┌───────────┐  │
   │ │ Managed  │  │ Self-mgd  │  │
   │ │ Node Grp │  │ Node Grp  │  │
   │ └──────────┘  └───────────┘  │
   │ ┌──────────────────────────┐ │
   │ │ Fargate Profile          │ │
   │ └──────────────────────────┘ │
   └──────────────────────────────┘

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 ip (pods recebem tráfego direto) ou instance (via NodePort)

ECR — Elastic Container Registry

• Registry privado para Docker/OCI images
• Integrado com IAM (authN via aws ecr get-login-password)
• 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

✓ ECS + Fargate + ALB

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 (Managed Node Groups ou Fargate Profile)

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

✓ ECS Fargate Spot (ou EKS Fargate Spot)

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

✓ AWS App Runner

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

✓ EKS + Managed Node Groups com g5 instances

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:

• Task Role vs Execution Role — confusão clássica.
• Fargate NÃO suporta GPU, daemon tasks, privileged containers, alguns network modes.
• EKS control plane custa $0,10/h mesmo sem workloads.
• Para secrets em containers: use SSM Parameter Store ou Secrets Manager referenciado na task definition (não hardcode).
• ECS Anywhere e EKS Anywhere rodam on-prem com controle AWS.
• App Mesh (service mesh) foi descontinuado em 2024 — ECS Service Connect ou Istio/Linkerd no EKS são as alternativas.

Perguntas típicas (Q&A)

❓ Como passar env vars secretas para um container?

Na task definition, use secrets section referenciando ARN de SSM Parameter Store ou Secrets Manager. ECS Agent resolve em runtime e injeta como env var. Precisa execution role ter permissão de leitura.

❓ Como deploy zero-downtime em ECS?

ECS Service com deployment configuration: minimumHealthyPercent e maximumPercent. Rolling update substitui tasks gradualmente. Ou use CodeDeploy Blue/Green para troca atômica via listener.

❓ ECS em EC2 launch type — como a instância sabe que faz parte do cluster?

ECS Agent (container) roda na EC2. AMI ECS-optimized já inclui agent. Config em /etc/ecs/ecs.config: ECS_CLUSTER=meu-cluster. Instância precisa IAM role com permissões ECS.

❓ EKS — como dar permissão IAM a um pod específico?

IRSA (IAM Roles for Service Accounts): associa IAM Role a Kubernetes ServiceAccount via OIDC. Pod assume a role via tokens projetados. Melhor que dar role na instância (que daria a todos os pods).

✅

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.

🧩

Quiz rápido

3 perguntas · Acerte tudo e ganhe o badge 🎯 Gabarito