Amazon DOP-C02: Contêineres e Operações Serverless — Guia de estudos

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Faz parte do AWS DevOps Engineer Professional DOP-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

Contêineres e serverless mudam a forma como você opera, escala e lança aplicações na AWS. Esta seção conecta as primitivas operacionais entre Amazon ECS, AWS Fargate, Amazon EKS, Amazon ECR, AWS Lambda e Amazon API Gateway para que você possa projetar implantações seguras, aplicar governança de imagens, ajustar a concorrência e fazer escolhas consistentes entre capacidade baseada em EC2 e Fargate. Ela foca nos modelos de agendamento de tarefas e pods, verificações de saúde e controles de implantação, desvio de tráfego, distribuição de imagens entre contas e recursos de performance como cache de API e concorrência provisionada do Lambda.

Amazon ECS e AWS Fargate

As definições de tarefa (task definitions) do ECS declaram um ou mais contêineres e toda a configuração de tempo de execução necessária para o agendador. Elementos-chave incluem reservas e limites de CPU/memória, portMappings, variáveis de ambiente e segredos (do AWS Secrets Manager ou Systems Manager Parameter Store), parâmetros Linux e ulimits, logConfiguration (awslogs, firelens, etc.), tamanho do ephemeralStorage (para o Fargate, de 20 a 200 GB) e volumes (incluindo EFS). Use a role de execução da tarefa (task execution role) para pulls de imagem e drivers de log; use a role da tarefa (task role) para o acesso da aplicação à API da AWS. O healthCheck do contêiner define comando, intervalo, timeout, tentativas e startPeriod. Combinado com dependsOn (condition=HEALTHY), as verificações de saúde forçam a ordem de inicialização para sidecars.

Os serviços do ECS mantêm a contagem de tarefas desejada e, opcionalmente, registram as tarefas em um ALB/NLB. A deploymentConfiguration do serviço controla as atualizações contínuas (rolling updates) com minimumHealthyPercent e maximumPercent. O circuit breaker de implantação (enabled/rollback) pode reverter automaticamente implantações com falha quando as tarefas não passam nas verificações de saúde. O autoscaling de serviço se integra com o Application Auto Scaling para rastreamento de meta (target tracking) baseado em CPU/memória ou no RequestCountPerTarget do ALB. A descoberta de serviço (AWS Cloud Map) e o ECS Service Connect simplificam o tráfego de serviço a serviço.

Tipos de cluster e capacidade:

O tipo de inicialização (launch type) EC2 executa tarefas em instâncias EC2 autogerenciadas. Use grupos de Auto Scaling, restrições/estratégias de posicionamento (placement constraints/strategies) e qualquer networkMode (bridge/host/awsvpc). Tarefas do tipo Daemon e AMIs especializadas (ex: Bottlerocket) são suportadas.
O tipo de inicialização (launch type) Fargate é a computação serverless para contêineres. Ele usa apenas o modo de rede awsvpc, dando a cada tarefa sua própria ENI e security group. Não há tarefas do tipo Daemon; você depende de sidecars ou integrações nativas do serviço (ex: FireLens). As versões da plataforma (Platform versions) controlam o acesso a recursos (verifique as notas de lançamento para suporte a EFS, ephemeral storage e exec). O Fargate Spot reduz o custo para tarefas que podem ser interrompidas. Escolha CPU/memória em pares suportados (ex: de 0.25 vCPU/0.5–2 GB até 16 vCPU/120 GB). Ao executar em sub-redes privadas, adicione endpoints de interface da VPC para o ECR (api e dkr), CloudWatch Logs e um endpoint de gateway do S3 para baixar imagens e enviar logs sem um NAT.

Fargate e EFS: defina um volume EFS na definição da tarefa e monte-o com TLS; prefira usar pontos de acesso (access points) do EFS para aplicar o princípio de menor privilégio e forçar a identidade. Isso suporta necessidades com estado (stateful), como configurações compartilhadas, pesos de modelos de machine learning ou arquivos intermediários, sem a necessidade de incorporá-los nas imagens.

Verificações de saúde de contêiner, atualizações contínuas e blue/green:

As verificações de saúde ocorrem em múltiplas camadas: contêiner (baseada em CMD), tarefa do ECS (status agregados dos contêineres) e saúde do destino do load balancer (HTTP/TCP). Alinhe os intervalos e os limites (thresholds) para que o ECS possa substituir graciosamente tarefas não saudáveis antes que o ALB cancele o registro dos destinos (targets).
Atualizações contínuas (rolling updates) são o padrão do ECS. Ajuste minHealthy/maxPercent para controlar o aumento súbito de tarefas (surge) e a segurança da capacidade.
A estratégia blue/green usa o CodeDeploy com o ECS (deploymentController tipo CODE_DEPLOY). O CodeDeploy gerencia dois grupos de destino (target groups) por trás do ALB, desvia o tráfego de teste para o conjunto verde (green) (AfterAllowTestTraffic), executa verificações automatizadas (por exemplo, via Lambda) e, em seguida, desvia o tráfego de produção. Associe alarmes do CloudWatch para acionar o rollback em caso de picos de erros 5XX, latência ou métricas personalizadas. Este padrão isola falhas e proporciona reversões rápidas com tempo de inatividade próximo de zero.

Governança de imagens com o ECR:

Escaneamento: habilite o escaneamento no push (scan-on-push) e adote o escaneamento aprimorado do Amazon Inspector para cobertura contínua de CVEs e SBOMs. Bloqueie implantações com base na severidade da vulnerabilidade usando verificações no pipeline.
Políticas de ciclo de vida (Lifecycle policies) expiram tags de imagem antigas por contagem/idade e prefixo de tag. Combine isso com a imutabilidade de tags para bloquear sobrescritas acidentais.
Criptografia: use a criptografia gerenciada pelo ECR ou uma chave KMS gerenciada pelo cliente com a política de chave (key policy) apropriada.
Entre contas: anexe políticas de recurso ao repositório para conceder permissões de pull/push de outras contas ou roles de CI. Use regras de replicação do ECR para copiar imagens entre Regiões/contas para garantir localidade e reduzir o raio de impacto (blast-radius). O PrivateLink (endpoints da VPC) permite fazer pull de imagens sem acesso à internet.

Modelos de Computação do Amazon EKS

O EKS separa o plano de controle gerenciado das suas escolhas para o plano de dados:

Grupos de nós gerenciados (MNGs) provisionam e gerenciam o ciclo de vida dos nós de trabalho (worker nodes) EC2. Eles se integram com launch templates para a escolha da AMI (Amazon Linux 2, Bottlerocket), tipos de instância e parâmetros de bootstrap. Os MNGs lidam com atualizações contínuas (rolling updates) com capacidade extra (surge capacity) e cordon/drain automatizados para disrupção mínima. Use taints/tolerations de nós para direcionar workloads específicos. Combine com o Cluster Autoscaler (ou Karpenter) para dimensionar corretamente a capacidade dos nós com base em pods pendentes.

Nós autogerenciados dão controle total sobre o bootstrap e o sistema operacional, mas adicionam sobrecarga operacional; eles são tipicamente reservados para kernels especiais ou hardware de nicho.

EKS on Fargate executa pods sem gerenciar nós. Perfis do Fargate mapeiam namespaces/labels para o Fargate. Cada pod recebe sua própria ENI (awsvpc), simplificando o isolamento de rede. As limitações incluem a ausência de DaemonSets, de rede/volumes do host e restrições em workloads privilegiados. Agentes de observabilidade (ex: Fluent Bit) devem ser executados como sidecars ou usar a coleta de logs gerenciada. Este modelo é ideal para workloads com picos de uso, de baixo consumo de recursos (small-footprint) ou multilocatário (multi-tenant) que se beneficiam do isolamento por pod e do modelo econômico de pagamento por pod.

Add-ons operacionais:

VPC CNI, CoreDNS e kube-proxy são add-ons gerenciados; fixe as versões compatíveis com a versão do cluster e atualize de forma deliberada.
IAM Roles for Service Accounts (IRSA) impõe o acesso AWS de menor privilégio por pod e substitui o compartilhamento de credenciais da role do nó.
O balanceamento de carga via AWS Load Balancer Controller suporta ALB/NLB para Services e Ingress; garanta as regras de IAM e de security group adequadas, especialmente ao misturar MNG e Fargate.
Armazenamento persistente via drivers CSI (EBS para bloco por pod, EFS para POSIX compartilhado). Para o Fargate, o EFS é a opção típica para estado compartilhado.

Operações e Concorrência do AWS Lambda

Empacotamento e configuração:

Pacotes de implantação podem ser arquivos ZIP (com o runtime da linguagem) ou imagens de contêiner de até 10 GB. ZIP é mais leve para código pequeno; imagens unificam o ferramental com builds baseados em contêiner.
Layers (camadas) encapsulam bibliotecas compartilhadas entre funções; mantenha-as mínimas e versionadas. Uma função pode incluir até cinco layers.
Versões são snapshots imutáveis; aliases são ponteiros estáveis para versões e podem ter pesos para o desvio de tráfego (traffic shifting).
O armazenamento efêmero tem um padrão de 512 MB e pode ser aumentado para 10.240 MB para builds, arquivos temporários ou caches de inferência de ML. Escolha x86_64 ou arm64 para trade-offs de custo/performance. Use variáveis de ambiente para configuração e integre com o Secrets Manager ou o Parameter Store.

Desvio de tráfego e segurança:

Use o CodeDeploy para implantações canary/lineares com reversão (rollback) automatizada baseada em alarmes do CloudWatch (ex: erros 5XX, latência ou métricas personalizadas da aplicação). Alternativamente, defina os pesos do alias diretamente para um roteamento A/B simples.
Use logging estruturado para o CloudWatch Logs e crie filtros de métrica para derivar métricas dimensionadas por operação/versão/código sem alterar a instrumentação de métricas. Habilite o X-Ray para rastreamento de latência de ponta a ponta.

Controles de concorrência:

A concorrência não reservada utiliza o pool regional da conta. Picos de tráfego podem deixar outras funções sem recursos (starvation).
A concorrência reservada limita a concorrência máxima de uma função e garante capacidade para ela, reservando uma parte do pool regional; isso fornece isolamento contra “vizinhos ruidosos” (noisy neighbors).
A concorrência provisionada mantém os ambientes de execução inicializados para uma versão/alias, praticamente eliminando cold starts e estabilizando a latência. Escale a concorrência provisionada com o Application Auto Scaling por horário do dia ou por métricas.
O throttling (limitação) ocorre quando uma função atinge seu limite de concorrência; chamadas síncronas recebem erros 429, enquanto invocações assíncronas são repetidas com backoff exponencial e podem ser enviadas para uma fila de mensagens mortas (dead-letter) após as tentativas configuradas. Para fontes baseadas em polling como o SQS, o Lambda aumenta a concorrência com a profundidade da fila; garanta que a concorrência reservada/provisionada e a capacidade downstream correspondam ao máximo de mensagens em trânsito para evitar o crescimento do backlog.

Design de API Gateway e Acesso Cross-Account ao ECR

API Gateway REST APIs versus HTTP APIs:

As REST APIs fornecem o conjunto de recursos mais completo: mapeamento de requisição/resposta (VTL), planos de uso e chaves de API, autorizadores, WAF e cache em nível de stage. Escolha as REST APIs quando precisar de transformações avançadas, chaves de API com cotas ou integrações maduras com o ecossistema.
As HTTP APIs têm menor latência e custo, com roteamento mais simples para backends Lambda e HTTP (incluindo integrações com ALB/NLB/privadas). Elas suportam autorizadores JWT e IAM, mas não possuem muitos recursos das REST APIs, incluindo cache em nível de stage e transformações VTL. Escolha as HTTP APIs para proxy direto com sobrecarga (overhead) mínima.

Stages e throttling:

Stages vinculam uma implantação específica a um caminho de URL. Configure variáveis de stage, logs e throttling no nível do stage. Aplique planos de uso (REST) para impor limites de throttling e cotas por chave de API. As configurações de throttling incluem taxa (rate) e pico (burst); elas se somam aos limites no nível da conta, então garanta que o tráfego agregado não exceda as cotas regionais. Habilite logs de acesso com JSON estruturado e integre o WAF para inspecionar e bloquear requisições maliciosas.

Cache (somente REST APIs):

O cache em nível de stage reduz a carga no backend e a latência; defina TTLs por método, habilite a criptografia e considere parâmetros/cabeçalhos de chave de cache para garantir a corretude. Invalide os caches após implantações que alteram a forma ou o comportamento da resposta.

Conectividade privada:

Escolha o tipo de endpoint: otimizado para a borda (edge-optimized) (REST, global via CloudFront), regional ou privado (endpoints de VPC). Integrações privadas com VPC Link se conectam a backends NLB/ALB em VPCs sem exposição pública.

Acesso cross-account ao ECR:

Use políticas de recursos do repositório para conceder permissões de pull/push a principals em outras contas (funções de CI/CD ou de tempo de execução). Se estiver usando uma chave KMS gerenciada pelo cliente, estenda a política da chave de acordo. Para distribuição em múltiplas contas, defina regras de replicação do ECR para contas/Regiões de destino e valide a integridade da imagem com imutabilidade de tags e fixação de digest (digest pinning) nas implantações.

Cenário de Problema Prático

O Spotify está modernizando uma pilha de microsserviços de playlists para reduzir a variação de latência durante picos de lançamentos e para aprimorar o controle de sua cadeia de suprimentos de imagens em múltiplas contas AWS.

Padronizar a construção e a governança de imagens

Implemente repositórios ECR com verificação no push (scan-on-push) e a verificação aprimorada do Amazon Inspector. Adicione imutabilidade de tags e políticas de ciclo de vida para reter as N versões mais recentes por branch e remover as que não são mais usadas (prune drift). Configure a replicação entre Regiões/contas da conta de build para as contas de produção e homologação. Por quê: O Inspector garante cobertura contínua de CVEs, a imutabilidade impede o sequestro de tags (tag hijacking) e a replicação localiza as operações de pull para reduzir a latência de implantação e o raio de impacto (blast radius).

Servir APIs stateless no ECS com Fargate

Defina definições de tarefa (task definitions) do ECS com awslogs e FireLens para logs e métricas estruturados. Habilite o healthCheck do contêiner e alinhe as verificações de saúde (health checks) do grupo de destino (target group) do ALB. Monte um volume EFS para configuração compartilhada somente leitura por meio de um ponto de acesso (access point). Execute serviços no Fargate com uma estratégia de provedor de capacidade (capacity provider) que mescla Fargate e Fargate Spot para eficiência de custos. Por quê: O Fargate elimina o gerenciamento de nós e isola as tarefas por ENI; o EFS evita embutir configurações nas imagens e suporta rollbacks atômicos de configuração.

Implantações seguras com blue/green e testes automatizados

Altere os serviços ECS para usar um controlador de implantação do CodeDeploy. Configure dois grupos de destino (target groups) no ALB. Use um desvio de tráfego canary com AfterAllowTestTraffic para invocar um executor de testes Lambda que exercita endpoints críticos em 5 minutos. Associe alarmes do CloudWatch para erros 5XX e latência p90 para acionar o rollback. Por quê: A implantação blue/green do CodeDeploy isola o risco, o gancho de teste (test hook) valida o ambiente ‘green’ antes da transição completa (cutover) e os alarmes proporcionam um rollback automatizado e objetivo.

Operações sensíveis à latência no Lambda com cold starts estabilizados

Para uma API auxiliar de tokenização, empacote a função como um ZIP com dependências enxutas. Crie uma versão/alias e habilite a concorrência provisionada (provisioned concurrency) dimensionada para o pico. Gerencie a concorrência provisionada via Application Auto Scaling com uma programação diária que acompanha as janelas de lançamento. Use uma implantação canary do CodeDeploy (10%/15 minutos) para o desvio de tráfego baseado em alias, vinculado a alarmes do CloudWatch. Por quê: A concorrência provisionada elimina os cold starts durante picos de tráfego; as implantações canary em alias permitem exposição gradual com rollback rápido.

Expor APIs externas via API Gateway e proteger backends privados

Coloque o API Gateway na frente do Lambda e do ALB do ECS. Use HTTP APIs para o proxy do Lambda para minimizar custo/latência. Use a REST API para o caminho do ALB do ECS que precisa de mapeamento de requisição/resposta e cache de stage para endpoints de leitura intensiva. Aplique Web ACLs do WAF e throttling de stage; habilite logs de acesso estruturados. Por quê: Corresponder os tipos de API às necessidades otimiza custos e capacidades; o cache reduz a carga; o WAF e o throttling adicionam proteção durante picos de eventos.

Pulls cross-account em tempo de execução sem internet

Nas VPCs de tempo de execução, adicione endpoints de interface para o ECR (api, dkr) e CloudWatch Logs, e um endpoint de gateway para o S3. Anexe políticas de recursos do repositório ECR para permitir que as ’task execution roles’ da conta de produção façam o pull. Use uma chave KMS gerenciada pelo cliente com uma política de chave cross-account para criptografia de imagem em repouso (at rest). Por quê: Os pulls de imagem privados evitam custos de NAT e riscos de egresso; políticas explícitas de recursos/chaves impõem o acesso cross-account com o menor privilégio (least-privilege).

Este design reduz o esforço operacional (sem nós para gerenciar), fornece latência determinística por meio da concorrência provisionada e de rollouts alinhados com a saúde do ALB, e impõe a proveniência da imagem de ponta a ponta com a verificação, replicação e imutabilidade do ECR.

← Segurança · Todos os domínios · Alta Disponibilidade →

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