Amazon SAA-C03: Contêineres e Orquestração — Guia de estudos

By Laurynas Brazys · 18 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Faz parte do AWS SAA-C03 — Guia de estudos completo. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Escolhendo Entre ECS e EKS, e Entre EC2 e Fargate

A primeira decisão de arquitetura para qualquer workload de contêineres na AWS é escolher o orquestrador e o modo de computação. O Amazon ECS é um orquestrador proprietário da AWS com integração profunda com IAM, ALB/NLB, CloudWatch, Service Discovery e redes VPC. Ele não tem taxa de control plane e é o caminho mais rápido para a produção para equipes que não precisam de ferramentas específicas do Kubernetes. As tasks (tarefas) são unidades de um ou mais contêineres que compartilham um ciclo de vida; os services (serviços) são conjuntos de tarefas gerenciadas de longa duração, controlados por um scheduler. O Amazon EKS executa uma versão do Kubernetes compatível com o upstream por uma taxa fixa de US$ 0,10/hora por cluster, e é a escolha correta quando os workloads precisam permanecer portáteis, usar a API do Kubernetes ou aproveitar o ecossistema da CNCF (Helm, CRDs, Operators). O control plane — API server, etcd, controller manager, scheduler — é atualizado (patched), tem backup e sua alta disponibilidade é garantida pela AWS em três AZs.

Ambos os orquestradores aceitam dois modos de computação. O AWS Fargate executa cada task ou pod em microVMs Firecracker isoladas; não há AMIs para atualizar, nem capacity providers de Auto Scaling Group para ajustar, nem decisões de bin-packing, nem hosts acessíveis por SSH. Você paga por vCPU-segundo e GB-segundo da tarefa. O launch type EC2 / managed node groups significa que você é o proprietário das instâncias, com a flexibilidade e a carga operacional que isso implica.

O Fargate é a escolha padrão correta sempre que um cenário enfatiza “serverless”, “mínima sobrecarga operacional” ou “nenhuma infraestrutura para gerenciar”, desde que o workload se encaixe em suas restrições: máximo de 16 vCPUs / 120 GB de memória por tarefa, sem GPU, sem contêineres privilegiados, sem DaemonSets, sem HostPort/HostNetwork, sem personalização em nível de host do Windows. Escolha managed node groups ou o launch type EC2 quando precisar de GPUs, DaemonSets que exigem acesso ao host, AMIs personalizadas, contêineres Windows Server com GMSA, eficiência de bin-packing de sub-segundos ou otimização de custos agressiva baseada em Spot.

A armadilha clássica é escolher nós EC2 porque eles “parecem” mais baratos. Para workloads com picos de uso (spiky) ou de baixa utilização, o Fargate costuma ser mais barato quando se considera a capacidade ociosa mais o tempo de engenharia para aplicar patches em AMIs, drenar nós e configurar o cluster autoscaler — tudo isso o Fargate elimina.

Task Definitions, Placement e Capacity Providers

Uma task definition canônica do ECS Fargate captura os elementos essenciais — dimensionamento de CPU/memória, uma execution role para baixar imagens e gravar logs, o modo de rede awsvpc e a conexão com o CloudWatch Logs:

family: checkout-service
requiresCompatibilities: [FARGATE]
networkMode: awsvpc
cpu: "1024"
memory: "2048"
executionRoleArn: arn:aws:iam::111122223333:role/ecsTaskExecutionRole
containerDefinitions:
  - name: checkout
    image: 111122223333.dkr.ecr.us-east-1.amazonaws.com/checkout:1.4.2
    portMappings: [{ containerPort: 8080 }]
    logConfiguration:
      logDriver: awslogs
      options:
        awslogs-group: /ecs/checkout
        awslogs-region: us-east-1

No ECS com EC2, as estratégias de posicionamento de tarefas (task placement strategies) decidem como as tarefas são distribuídas entre as instâncias. Elas são compostas em ordem:

Restrições de posicionamento (placement constraints), como distinctInstance ou memberOf, usando a linguagem de consulta do cluster, restringem ainda mais os candidatos.

Os Capacity providers desacoplam os serviços dos Auto Scaling Groups brutos. FARGATE e FARGATE_SPOT são providers gerenciados; providers personalizados encapsulam um ASG e habilitam o managed scaling para que o ECS ajuste a contagem desejada (desired count) do ASG com base no número de tarefas provisionadas. Uma estratégia de capacity provider divide as tarefas por peso e base — por exemplo, garantindo duas tarefas Fargate on-demand e dividindo o restante na proporção de 1:4 com o Fargate Spot para workloads tolerantes a interrupções:

capacityProviderStrategy:
  - capacityProvider: FARGATE
    base: 2
    weight: 1
  - capacityProvider: FARGATE_SPOT
    weight: 4

Autoscaling: Pods, Tarefas e Nós

O Fargate remove o gerenciamento de nós, mas ele não escala automaticamente o número de tarefas ou pods. Essa distinção é o equívoco mais comum sobre o Fargate: o conceito de serverless se aplica à camada de host, nunca à contagem desejada do seu serviço. Você ainda é responsável pelo autoscaling no nível do serviço.

Para o ECS, use o Application Auto Scaling. O Target tracking é o padrão idiomático porque cria automaticamente os alarmes de scale-out e scale-in do CloudWatch e respeita os cooldowns. Métricas sensatas são ECSServiceAverageCPUUtilization, ECSServiceAverageMemoryUtilization e ALBRequestCountPerTarget:

aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --resource-id service/prod-cluster/checkout \
  --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 2 --max-capacity 30

aws application-autoscaling put-scaling-policy \
  --policy-name cpu-target-50 \
  --service-namespace ecs \
  --resource-id service/prod-cluster/checkout \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration \
    '{"TargetValue":50.0,"PredefinedMetricSpecification":{"PredefinedMetricType":"ECSServiceAverageCPUUtilization"}}'

O Step scaling e o scheduled scaling continuam disponíveis para curvas de resposta não lineares ou janelas de tráfego conhecidas.

Para o EKS em nós EC2, a dimensão dos pods é tratada pelo Horizontal Pod Autoscaler (HPA), que ajusta a contagem de réplicas com base em CPU, memória ou métricas personalizadas. O HPA sozinho não consegue adicionar nós — ele aumentará o número de réplicas além da capacidade do cluster, momento em que novos pods entram no estado Pending com eventos de FailedScheduling. É por isso que o HPA no EC2 deve sempre ser combinado com o Kubernetes Cluster Autoscaler ou o Karpenter. Esquecer essa combinação é um erro de design frequente: o HPA relata “escalado para 20 réplicas” enquanto metade delas está presa em pending. Uma configuração mínima do Cluster Autoscaler descobre os node groups por meio de tags do ASG:

- --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/prod-eks
- --balance-similar-node-groups
- --skip-nodes-with-system-pods=false

Em perfis Fargate, esse problema desaparece — cada pod se torna sua própria microVM, de modo que a dimensão de escalonamento de nós é totalmente eliminada. É exatamente por isso que o Fargate é a escolha correta para workloads com picos de uso (bursty) e contagens de pods imprevisíveis.

Perfis do Fargate e Seus Limites de Recursos

Um perfil do Fargate no EKS é um seletor — namespace mais labels de pod opcionais — que instrui o EKS a agendar pods correspondentes no Fargate em vez de em um nó:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata: { name: microservices, region: us-east-1 }
fargateProfiles:
  - name: fp-app
    selectors:
      - namespace: app
        labels: { compute: fargate }

A ressalva crítica é que o EKS no Fargate não suporta toda a gama de funcionalidades do Kubernetes:

• DaemonSets não são executados. Sem um nó para executar o daemon, agentes de log (log shippers) como DaemonSets do fluentd devem ser substituídos por sidecars ou pelo roteador de logs integrado Fluent Bit.
• Contêineres privilegiados, HostPort e HostNetwork não estão disponíveis.
• O armazenamento persistente é limitado ao EFS através do driver CSI. O EBS não é suportado porque os volumes EBS exigem anexação a uma instância EC2 específica.
• Cargas de trabalho de GPU não são suportadas.
• Serviços NodePort e services meshes que dependem de contêineres de inicialização privilegiados não funcionam.

Assumir paridade de recursos leva a falhas na migração de StatefulSets que precisam de EBS, controladores de ingress que usam hostPort ou cargas de trabalho de inferência de GPU.

Ingress: ALB vs. NLB via o AWS Load Balancer Controller

O AWS Load Balancer Controller é um controlador do Kubernetes que traduz objetos Ingress e Service em ALBs e NLBs reais. Para microsserviços HTTP/HTTPS com roteamento baseado em caminho ou host, crie um único Ingress da classe alb. Um único ALB atendendo a muitos serviços (via alb.ingress.kubernetes.io/group.name) é drasticamente mais barato do que um ALB por serviço e é o padrão canônico de custo-benefício:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/group.name: shop
spec:
  rules:
  - http:
      paths:
      - path: /customers
        pathType: Prefix
        backend: { service: { name: customers, port: { number: 80 }}}
      - path: /orders
        pathType: Prefix
        backend: { service: { name: orders, port: { number: 80 }}}

Use um NLB (Service do tipo LoadBalancer com service.beta.kubernetes.io/aws-load-balancer-type: external e tipo de destino nlb-ip) para TCP, UDP, pass-through de TLS, requisitos de IP estático ou throughput extremo na Camada 4. Colocar um proxy de banco de dados gRPC-sobre-HTTP/2 ou TCP simples atrás de um ALB só é adequado para gRPC (o ALB suporta HTTP/2 e gRPC); o ALB não pode terminar TCP arbitrário ou qualquer UDP. Tentar servir tráfego de jogos UDP através de um ALB é uma incompatibilidade de protocolo que deve ser identificada na fase de projeto.

IAM no Nível do Pod com IRSA

IAM Roles for Service Accounts (IRSA) é o mecanismo correto para conceder permissões da API da AWS a pods individuais. Anexar o instance profile do nó para dar aos pods acesso ao S3 está errado, porque todo pod no nó herda essas permissões, quebrando o princípio do menor privilégio. O IRSA funciona federando o provedor OIDC do cluster com o IAM: crie o provedor OIDC uma vez, depois crie uma role do IAM cuja política de confiança (trust policy) confie nesse provedor para um sujeito namespace:serviceaccount específico.

eksctl utils associate-iam-oidc-provider --cluster prod --approve

eksctl create iamserviceaccount \
  --cluster prod --namespace payments --name orders-sa \
  --attach-policy-arn arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess \
  --approve

A service account é anotada com eks.amazonaws.com/role-arn: arn:aws:iam::...:role/orders-role, e os pods que a montam recebem credenciais STS de curta duração por meio de um token projetado. Pular a associação do provedor OIDC ou omitir a anotação resulta silenciosamente no fallback para a role do nó — uma regressão de segurança sutil que é fácil de passar despercebida em uma revisão.

O plugin VPC CNI complementa isso atribuindo a cada pod um endereço ENI/IP roteável na sub-rede da VPC. Os pods podem então comunicar-se diretamente com RDS, ElastiCache ou endpoints da VPC usando security groups, e o CloudTrail vê o IP real do pod para fins de auditoria.

Armazenamento Persistente e Efêmero

A escolha do armazenamento depende do modo de acesso, da durabilidade e do tipo de inicialização.

EBS (via driver EBS CSI no EKS, ou EBS anexado à tarefa no ECS) fornece volumes de bloco ReadWriteOnce para cargas de trabalho stateful de pod único, como um banco de dados Postgres primário. EFS fornece armazenamento NFS ReadWriteMany que é regional, multi-AZ e montável por muitos pods simultaneamente — a escolha correta sempre que o requisito mencionar “altamente disponível, tolerante a falhas, compartilhado entre múltiplos contêineres” ou artefatos de ML compartilhados. FSx for Lustre lida com HPC de alto throughput; FSx for NetApp ONTAP e FSx for Windows File Server lidam com NFS/SMB empresarial.

As tarefas do Fargate recebem 20 GB de armazenamento efêmero por padrão, configurável até 200 GB via ephemeralStorage.sizeInGiB na plataforma 1.4.0+. Assumir que o Fargate sempre tem “muito espaço temporário” é uma armadilha: um contêiner de fornecedor que grava 50 GB de arquivos intermediários pode caber no armazenamento efêmero expandido, mas se o requisito for de 50 GB de armazenamento compartilhado ou durável entre reinicializações de tarefas ou entre tarefas, o armazenamento efêmero está errado, porque ele é destruído quando a tarefa para e nunca é compartilhado. O Fargate não suporta EBS. Se uma carga de trabalho no Fargate precisa de armazenamento persistente ou compartilhado, o EFS é essencialmente a única opção suportada.

Para o ECS, monte o EFS diretamente na definição da tarefa; os access points impõem UID/GID POSIX e um diretório raiz por tarefa, proporcionando multi-tenancy seguro em um único sistema de arquivos, e a autorização do IAM delimita o escopo para elasticfilesystem:ClientMount:

"volumes": [{
  "name": "scratch",
  "efsVolumeConfiguration": {
    "fileSystemId": "fs-0abc123",
    "transitEncryption": "ENABLED",
    "authorizationConfig": {
      "accessPointId": "fsap-0def456",
      "iam": "ENABLED"
    }
  }
}],
"containerDefinitions": [{
  "name": "app",
  "mountPoints": [{
    "sourceVolume": "scratch",
    "containerPath": "/data"
  }]
}]

Para o EKS, conecte o EFS por meio de uma StorageClass:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata: { name: efs-sc }
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-0123456789abcdef0
  directoryPerms: "700"

Uma armadilha recorrente: selecionar o Fargate para uma carga de trabalho stateful e esquecer de instalar o driver CSI do EFS e a StorageClass — os pods iniciam, mas os PersistentVolumeClaims permanecem em Pending para sempre. Por outro lado, escolher nós EC2 apenas para anexar EBS quando o requisito é de armazenamento compartilhado com múltiplos gravadores (multi-writer) também está errado; um volume EBS io2 anexado a um nó não pode ser compartilhado entre AZs.

Análise de Imagens e Ciclo de Vida do ECR

O Amazon ECR oferece dois modos de verificação. A verificação básica usa o banco de dados de código aberto Clair e é executada no push (ou sob demanda) sem custo. A verificação aprimorada integra o Amazon Inspector, monitora continuamente CVEs tanto do SO quanto de pacotes de linguagem, e reporta os resultados no Security Hub. Para “verificar CVEs, verificar novas imagens na criação, com o mínimo de alterações nas cargas de trabalho”, a ação correta é habilitar a verificação no push (scan on push) no nível do repositório — nenhuma alteração no pipeline é necessária porque o evento de push aciona a verificação:

aws ecr put-image-scanning-configuration \
  --repository-name payments-api \
  --image-scanning-configuration scanOnPush=true

O CI/CD então chama describe-image-scan-findings e falha os builds se houver contagens CRITICAL ou HIGH. Pular a verificação significa que CVEs não corrigidos do Log4j, OpenSSL ou glibc serão executados em produção; o custo de mitigação de não verificar é muito maior do que o custo quase zero de habilitá-la.

As políticas de ciclo de vida (lifecycle policies) limitam o custo de armazenamento e impõem a higiene das tags:

{
  "rules": [{
    "rulePriority": 1,
    "selection": {
      "tagStatus": "untagged",
      "countType": "sinceImagePushed",
      "countUnit": "days",
      "countNumber": 14
    },
    "action": { "type": "expire" }
  }]
}

Migrando Cargas de Trabalho Kubernetes + MongoDB

Ao fazer o lift-and-shift de uma stack Kubernetes + MongoDB auto-hospedada para a AWS sob as restrições de “não alterar o código da aplicação” e “mínima sobrecarga operacional”, duas decisões se alinham. Primeiro, a camada de computação é movida para o EKS, pois a compatibilidade com a API do Kubernetes significa que manifestos e Helm charts são portados sem alterações; use perfis do Fargate para os serviços stateless para eliminar o gerenciamento de nós.

Segundo, o próprio MongoDB não deve ser realocado em instâncias EC2 autogerenciadas ou StatefulSets — isso reintroduz backups, sharding, failover e aplicação de patches como fardos operacionais. Use o Amazon DocumentDB (com compatibilidade com MongoDB), que utiliza o protocolo de comunicação (wire protocol) do MongoDB 3.6/4.0/5.0, para que os drivers e strings de conexão existentes funcionem com o mínimo de alterações.

A ressalva de compatibilidade é importante. O DocumentDB emula a superfície da API do MongoDB, mas não é o MongoDB. Certos operadores de agregação, tipos de índice específicos, semântica de change streams e recursos introduzidos em versões mais recentes do MongoDB podem falhar. O passo correto de pré-migração é executar a ferramenta de compatibilidade do DocumentDB (compat.py) contra a aplicação para confirmar que todas as operações são suportadas. Escolher o DynamoDB em vez disso forçaria uma reescrita do modelo de dados; escolher o RDS quebraria completamente o modelo de documento. Ambas as opções violam a restrição de “não alterar o código”.

Opções Híbridas: ECS Anywhere e EKS Anywhere

O ECS Anywhere registra servidores on-premises (ou VMs de outras nuvens) como instâncias externas em um cluster ECS. O plano de controle permanece na AWS; o SSM Agent e o ECS Agent na instância externa se conectam à AWS (outbound). Um único pipeline de implantação, uma única definição de tarefa e um único conjunto de IAM roles cobrem tanto as cargas de trabalho na nuvem quanto as on-premises.

O EKS Anywhere instala uma distribuição Kubernetes compatível em seu hardware (normalmente vSphere ou bare metal), opcionalmente com visibilidade no console da AWS através do EKS Connector. Escolha o ECS Anywhere para um ambiente híbrido leve e baseado em definições de tarefa; escolha o EKS Anywhere quando restrições regulatórias ou de latência exigirem o Kubernetes localmente com as mesmas ferramentas do EKS na nuvem. Ambos mantêm a consistência da orquestração — o valor fundamental é que as equipes evitam manter dois sistemas de CI/CD ou dois modelos mentais.

Visibilidade Multi-Cluster com o EKS Connector

As organizações frequentemente operam uma mistura de clusters EKS, clusters Kubernetes autogerenciados em EC2 e clusters on-premises. O Amazon EKS Connector registra qualquer cluster Kubernetes compatível no console do EKS, fornecendo um painel único para visualizar nós, cargas de trabalho e metadados do cluster. É essencialmente um agente leve mais um canal SSM — a resposta de baixa sobrecarga para ter uma “visão central de todos os clusters”. Construir uma visibilidade equivalente com Rancher, Anthos auto-hospedados ou uma federação personalizada de Prometheus/Grafana é viável, mas operacionalmente muito mais caro e não se integra com o IAM ou com o acesso baseado no console.

O EKS Connector é estritamente uma camada de visibilidade; ele não gerencia nem atualiza o cluster remoto, o que é exatamente o que “visão central com o mínimo de sobrecarga” implica.

Juntando os Padrões

Para uma carga de trabalho de e-commerce com um front-end com balanceamento de carga, uma camada intermediária conteinerizada e um banco de dados relacional, onde o critério é “o mínimo de intervenção manual possível”, a stack canônica é ALB → ECS no Fargate → Aurora Serverless v2. Cada camada elimina o gerenciamento em nível de instância: o ALB é totalmente gerenciado, o Fargate remove os hosts e o Aurora Serverless v2 escala em ACUs sem a necessidade de dimensionar instâncias.

Para uma plataforma de microsserviços onde a equipe “não pode gerenciar infraestrutura adicional”, a combinação correta é ECS ou EKS com Fargate, mais um serviço de dados totalmente gerenciado. Selecionar o tipo de inicialização EC2 ou grupos de nós autogerenciados contradiz a restrição, embora a carga de trabalho tecnicamente funcionasse.

Para o lift-and-shift de Kubernetes + MongoDB, a resposta converge para EKS + DocumentDB: a API do Kubernetes preserva os métodos de implantação, o DocumentDB preserva a compatibilidade de drivers e os perfis do Fargate preservam a operação mínima — desde que o uso de recursos do Kubernetes e a superfície de comandos do MongoDB pela carga de trabalho estejam dentro dos limites suportados descritos acima.

← Computação · Todos os domínios · Arquiteturas Serverless e Orientadas a Eventos →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Amazon →