Dentro de um servidor (ex: instância EC2), múltiplos containers Docker rodam de forma isolada, cada um com seu próprio runtime e dependências — sem interferência entre si.
Cada container encapsula a aplicação e suas dependências
Containers Java, Node.js e MySQL rodam lado a lado no mesmo OS
O Docker Daemon no host gerencia todos os containers
Recursos de CPU e memória são compartilhados com o host
Múltiplos containers em uma instância EC2
O que é Docker?
Plataforma de desenvolvimento de software para fazer deploy de aplicações
Apps são empacotadas em containers que rodam em qualquer OS
Apps rodam da mesma forma independente de onde são executadas:
Qualquer máquina, sem problemas de compatibilidade
Comportamento previsível, menos trabalho operacional
Funciona com qualquer linguagem, OS ou tecnologia
Casos de uso: microsserviços, lift-and-shift de apps on-premises para a AWS Cloud
Onde ficam as imagens Docker?
Imagens Docker ficam armazenadas em Docker Repositories.
Docker Hub
Repositório público
Imagens base para muitas tecnologias e sistemas operacionais (Ubuntu, MySQL…)
Amazon ECR
Repositório privado e público (Amazon ECR Public Gallery)
Docker vs. Máquinas Virtuais
Docker é "de certa forma" uma virtualização, mas não exatamente
Recursos são compartilhados com o host → muitos containers em um servidor
Aspecto
VM
Docker
Isolamento
Total (Guest OS)
Processo no Host OS
Overhead
Alto (GB/VM)
Baixo (MB/container)
Boot time
Minutos
Segundos
Camada extra
Hypervisor + Guest OS
Docker Daemon
VM vs Container — arquitetura comparada
Como funciona o Docker
Dockerfile → define a imagem (FROM, COPY, RUN, CMD…)
Build → gera a Docker Image
Push → envia para Docker Hub ou Amazon ECR
Pull → baixa a imagem do repositório
Run → executa como container
Dockerfile → Image → Container
Gerenciamento de Containers na AWS
Amazon ECS — plataforma de containers própria da Amazon
Amazon EKS — Kubernetes gerenciado pela AWS (open source)
AWS Fargate — plataforma serverless, funciona com ECS e EKS
Amazon ECR — armazena as imagens de containers
Amazon ECS — EC2 Launch Type
ECS = Elastic Container Service
Deploy de containers = lançar ECS Tasks em ECS Clusters
Você precisa provisionar e manter as instâncias EC2
Cada EC2 deve rodar o ECS Agent para se registrar no cluster
A AWS cuida de iniciar e parar os containers
ECS Cluster com EC2 Instances e ECS Agent
Amazon ECS — Fargate Launch Type
Sem provisionamento de infraestrutura — totalmente Serverless
Você apenas cria as task definitions
A AWS executa ECS Tasks com base na CPU/RAM necessária
Para escalar: aumente o número de tasks — sem EC2
Dica de prova
EC2 Launch Type = você gerencia EC2 + ECS Agent. Fargate = serverless, só crie task definitions.
Fargate — sem EC2, só tasks
Amazon ECS — IAM Roles
EC2 Instance Profile (somente EC2 Launch Type)
Usado pelo ECS Agent para chamadas de API ao ECS
Envia logs ao CloudWatch Logs
Faz pull de imagens do ECR
Referencia dados no Secrets Manager / SSM Parameter Store
ECS Task Role
Cada task tem um role específico
Roles diferentes para cada ECS Service
Definido na task definition
EC2 Instance Profile vs ECS Task Role
Amazon ECS — Load Balancer Integrations
Application Load Balancer — recomendado para maioria dos casos
Network Load Balancer — alto throughput / alta performance ou AWS PrivateLink
Classic Load Balancer — suportado mas não recomendado (sem Fargate)
ALB distribuindo para ECS Tasks
Amazon ECS — Data Volumes (EFS)
Monte sistemas de arquivos EFS nas ECS Tasks
Funciona para EC2 e Fargate launch types
Tasks em qualquer AZ compartilham os mesmos dados
Fargate + EFS = Serverless
Caso de uso: armazenamento compartilhado multi-AZ persistente
Importante
Amazon S3 não pode ser montado como sistema de arquivos em containers ECS.
EC2 e Fargate montando EFS compartilhado
ECS Service Auto Scaling
Aumenta/diminui automaticamente o número de ECS Tasks
Usa AWS Application Auto Scaling com métricas:
ECS Service Average CPU Utilization
ECS Service Average Memory Utilization
ALB Request Count Per Target
Target Tracking — valor alvo de uma métrica CloudWatch
Step Scaling — baseado em CloudWatch Alarm
Scheduled Scaling — baseado em data/horário
Atenção
ECS Service Auto Scaling (task level) ≠ EC2 Auto Scaling (instance level).
Fargate Auto Scaling é muito mais simples (Serverless).
EC2 Launch Type — Auto Scaling Instances
Auto Scaling Group Scaling — escala o ASG com base em CPU, adiciona EC2 ao longo do tempo
ECS Cluster Capacity Provider:
Provisiona e escala a infraestrutura automaticamente para as ECS Tasks
Capacity Provider associado a um Auto Scaling Group
Adiciona instâncias EC2 quando falta capacidade (CPU, RAM…)
Exemplo: ECS Scaling por CPU
CloudWatch Metric → Alarm → Auto Scaling Group → Scale ECS Capacity Providers
EventBridge captura o evento e aciona um SNS Topic
SNS envia e-mail para o administrador
ECS Task Definition — Estrutura
A Task Definition é o "blueprint" de como seu container vai rodar. É um arquivo JSON versionado (família + revisão) que define tudo que uma task precisa.
Comparativo direto ECS vs EKS — os pontos mais cobrados na SAA-C03
Dica de prova
Trigger words para EKS: "já usa Kubernetes", "multi-cloud", "portabilidade", "on-premises Kubernetes". Trigger words para ECS: "simples", "only-AWS", "menor custo de operação", "novo projeto de containers".
Qual servico usar? — Arvore de decisao
Questao classica da prova: dado um cenario, qual servico de container escolher?
Frequentemente omitido nos estudos, mas cobrado na prova como mecanismo de controle de custo e organização de imagens.
Regras que expiram imagens automaticamente com base em idade ou contagem
Exemplo: manter apenas as últimas 10 imagens por repositório
Exemplo: deletar imagens com tag "dev-" após 7 dias
Evita crescimento ilimitado do armazenamento no S3 (ECR usa S3 como backend)
Dica de prova
Cenário: "custos do ECR crescendo sem controle — imagens antigas acumulando" → solução: ECR Lifecycle Policy.
ECS Service Connect e Service Discovery
Como os serviços ECS se comunicam entre si dentro de um cluster?
ECS Service Discovery (Cloud Map)
Registra automaticamente tasks ECS no AWS Cloud Map
Cada task recebe um DNS name (ex: api.my-namespace.local)
Outros serviços resolvem via DNS — sem hardcode de IPs
Funciona com EC2 e Fargate
ECS Service Connect (mais recente)
Simplifica a comunicação service-to-service com proxy sidecar gerenciado
Fornece métricas de latência e erros entre serviços automaticamente
Mais fácil que configurar Service Discovery + App Mesh manualmente
Ideal para arquiteturas de microsserviços no ECS
Dica de prova
Se a questão perguntar sobre comunicação interna entre serviços ECS: Service Connect (solução mais simples e moderna) ou Service Discovery via Cloud Map (mais configurável).
Amazon ECR
ECR = Elastic Container Registry
Armazena e gerencia imagens Docker na AWS
Repositório Privado e Público (ECR Public Gallery)
Integrado ao ECS, com backing no Amazon S3
Acesso controlado pelo IAM
Suporta scan de vulnerabilidades, versionamento, image tags e lifecycle
ECR Repository → pull via IAM Role → ECS
Amazon EKS — Overview
EKS = Amazon Elastic Kubernetes Service
Lança clusters Kubernetes gerenciados na AWS
Kubernetes é open-source para deployment automático, scaling e gestão de containers
Alternativa ao ECS com API diferente; suporta EC2 ou Fargate
Caso de uso: empresa já usa Kubernetes on-premises e quer migrar para AWS
Cloud-agnostic — funciona em Azure, GCP e qualquer cloud
Para múltiplas regiões: um cluster EKS por região
Logs e métricas via CloudWatch Container Insights
Amazon EKS — Diagrama de Arquitetura
EKS Cluster — VPC com 3 AZs, subnets públicas/privadas, EKS Nodes e Pods
Amazon EKS — Node Types
Managed Node Groups — EKS cria e gerencia os nodes (EC2); suporta On-Demand e Spot
Self-Managed Nodes — você cria e registra os nodes no cluster; suporta On-Demand e Spot
AWS Fargate — sem manutenção, sem nodes para gerenciar
Amazon EKS — Data Volumes
Especifique o manifesto StorageClass no cluster EKS
Driver compatível com Container Storage Interface (CSI)
