Amazon CLF-C02: Serviços de Computação Principais — Guia de estudos

By Laurynas Brazys · 29 July 2026 · #amazon #clf-c02 #certification #exam-prep #study-guide

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

Conceitos essenciais do EC2, modelos de compra e padrões de disponibilidade

O Amazon EC2 é a oferta fundamental de computação IaaS: você escolhe tipos de instância para CPU, memória, armazenamento e rede, executa sistemas operacionais que você controla e, opcionalmente, anexa volumes do Elastic Block Store (EBS) para armazenamento em bloco persistente. Projetar para disponibilidade exige a distribuição de workloads por múltiplas Zonas de Disponibilidade (AZs) e, quando apropriado, por múltiplas Regiões. Para bancos de dados relacionais gerenciados, use o Amazon RDS Multi‑AZ para ter um standby síncrono e failover automatizado; para escalabilidade extrema de leitura ou recuperação de desastres entre regiões, considere o Amazon Aurora Global Database. As escolhas de compra de instâncias geram trade-offs de custo e resiliência: On-Demand oferece flexibilidade sem compromisso; Reserved Instances ou Compute Savings Plans oferecem as maiores economias previsíveis para uso contínuo e estável; Spot Instances entregam o menor preço para workloads tolerantes a falhas e interrompíveis. Armadilhas comuns incluem depender de uma única AZ, incorporar credenciais de longa duração nas instâncias e superprovisionar “só por precaução”. Use grupos de Auto Scaling com health checks, lifecycle hooks e políticas de instâncias mistas (On-Demand + Spot) para equilibrar custo e disponibilidade. Decida entre Reserved/Savings Plans versus Spot avaliando o uptime necessário, a tolerância a interrupções e a precisão do forecasting; escolha Multi‑AZ ou multi‑Região com base nos requisitos de RTO/RPO e nas restrições de latência entre regiões.

Computação gerenciada de contêineres, em lote e serverless: critérios de decisão

A AWS oferece múltiplas plataformas de computação gerenciada para atender a diferentes objetivos de arquitetura. O AWS Lambda possibilita funções serverless orientadas a eventos com escalabilidade automática e faturamento por milissegundo, ideal para tarefas stateless e de curta duração. O Amazon ECS fornece uma opção gerenciada de orquestração de contêineres que se integra com o Fargate para execução de contêineres serverless ou com o EC2 para maior controle. O Amazon EKS executa o Kubernetes como um control plane gerenciado para equipes que padronizam o uso do Kubernetes, com worker nodes como EC2 ou Fargate. O AWS Batch agenda e escala jobs de computação em lote na capacidade do EC2 ou Spot, otimizando o throughput para jobs de alto desempenho ou alto volume. O Elastic Beanstalk é uma plataforma de aplicação para implantar aplicações web sem gerenciar a infraestrutura subjacente; ele abstrai a configuração de EC2, autoscaling, ELB e RDS para implantações lift-and-shift mais rápidas. Os principais critérios de decisão incluem a habilidade operacional da equipe (experiência em Kubernetes favorece o EKS), a velocidade de implantação (Beanstalk), a previsibilidade de custos (o Fargate simplifica, mas pode custar mais) e as características do workload (Lambda para tarefas curtas e orientadas a eventos; ECS/EKS para serviços de longa duração). Evite a armadilha de selecionar a opção mais rica em recursos quando um serviço gerenciado mais simples (Lambda ou Fargate) reduziria a carga operacional e aumentaria a agilidade.

Estratégias de autoscaling, elasticidade e otimização de custos

Elasticidade é a capacidade de escalar recursos para mais ou para menos para corresponder à demanda; autoscaling é o mecanismo para alcançá-la. Use grupos de Auto Scaling (ASGs) para EC2 para adicionar ou remover instâncias com base em políticas de target tracking, step ou preditivas. Para contêineres, use o auto-scaling do ECS ou EKS para tarefas e clusters, e use os controles de concorrência integrados do Lambda para funções. Arquitete para statelessness e externalize o estado para serviços gerenciados como Amazon RDS, DynamoDB, ElastiCache ou S3, para que as instâncias possam ser efêmeras. Faça o right‑sizing das instâncias com revisões periódicas de dimensionamento, use monitoramento (métricas e alarmes do CloudWatch) e considere Savings Plans ou Reserved Instances para o uso de linha de base estável, enquanto aloca workloads variáveis em Spot. Modelos de preço a serem ponderados:

On-Demand: sem compromisso, pague por hora/segundo.
Reserved Instances / Savings Plans: compromisso de 1 ou 3 anos para descontos substanciais.
Spot Instances: maiores descontos para workloads interrompíveis.
Dedicated Hosts/Instances: isolamento físico para conformidade, custo mais alto. Erros comuns incluem subestimar os tempos de aquecimento (warm‑up) para o autoscaling, não usar lifecycle hooks para um desligamento gradual (graceful shutdown) e usar excessivamente Spot para workloads stateful e críticos. Use implantações blue/green ou canary para releases seguros e políticas de ciclo de vida (lifecycle policies) para automatizar o controle de custos de recursos não utilizados.

Ferramentas de segurança, conformidade e operações para computação

Segurança e operações são fundamentais para a computação na AWS. No modelo de responsabilidade compartilhada, a AWS protege a infraestrutura global e os serviços gerenciados, enquanto os clientes são responsáveis pelo sistema operacional convidado (guest OS), configuração da aplicação, dados e permissões do IAM ao usar IaaS. Evite incorporar chaves de acesso de longa duração; em vez disso, anexe IAM roles a instâncias EC2 ou use IAM Roles for Service Accounts (IRSA) para EKS, e utilize o AWS Secrets Manager ou o Systems Manager Parameter Store (SecureString) para rotacionar e gerenciar segredos de forma centralizada. Para auditoria e investigação, habilite o AWS CloudTrail para capturar a atividade de API em toda a conta e use o AWS Config para registrar as configurações dos recursos. Use o Amazon Macie para descobrir e classificar dados sensíveis no S3, e o IAM Access Analyzer ou o S3 Access Analyzer para encontrar compartilhamento de recursos entre contas ou públicos. Para evidências de conformidade, use o AWS Artifact para obter relatórios de auditoria. A visibilidade operacional é aprimorada com os VPC Flow Logs para o tráfego de rede, o AWS Personal Health Dashboard para eventos específicos da conta e o Service Health Dashboard para o status global dos serviços. Erros comuns de profissionais incluem deixar a conta raiz (root) com chaves ativas, não habilitar o MFA no usuário raiz e não centralizar a identidade com o IAM Identity Center (anteriormente AWS SSO) para single sign-on baseado em SAML para aplicações externas.

Problema Prático: Cenário de Caso de Uso

Cenário: A Acme Analytics executa uma aplicação de processamento de dados em EC2 em uma única AZ dentro de uma conta de produção da AWS. Eles têm jobs em lote (batch) que processam grandes volumes durante a noite e desejam custos mais baixos, recuperação mais rápida de falhas de AZ e gerenciamento seguro de segredos.

Desafio: Reduzir o custo de computação, garantindo a taxa de transferência (throughput) noturna dos lotes e melhorando a disponibilidade entre AZs, sem rearquitetar toda a aplicação imediatamente.

Abordagem Recomendada:

Migrar os workers de lote para um ambiente de computação do AWS Batch usando uma política de instâncias mistas (Spot + On-Demand) para reduzir o custo, mantendo a capacidade de base.
Configurar o AWS Batch para usar múltiplas AZs e habilitar Retry/RetryStrategy com filas de jobs distribuídas entre as AZs para resiliência.
Substituir credenciais incorporadas por IAM roles para os jobs do EC2/Batch e armazenar segredos rotacionados no AWS Secrets Manager; integrar com o IAM para recuperação automática.
Implementar alarmes do CloudWatch e políticas de Auto Scaling em uma frota mínima de EC2 para quaisquer componentes stateful restantes e habilitar o RDS Multi-AZ entre AZs (Cross-AZ) se um banco de dados estiver em uso.

Justificativa: Usar o processamento em lote gerenciado + Spot reduz o custo e a sobrecarga operacional, enquanto a distribuição multi-AZ e o IAM/Secrets Manager melhoram a disponibilidade e a segurança — alinhando-se com as melhores práticas de elasticidade, menor privilégio e rotação automatizada de segredos.

← Infraestrutura Global da AWS · Todos os domínios · Serviços de Armazenamento Principais →

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