Amazon CLF-C02: Conceitos de Nuvem — 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 da nuvem e a proposta de valor da AWS

A computação em nuvem transforma problemas de planejamento de capacidade e de uso intensivo de capital em um modelo operacional onde computação, armazenamento e rede são consumidos sob demanda. A AWS oferece elasticidade (escalonamento automático para acompanhar a carga), alcance global (Regions e Availability Zones para localidade e isolamento de falhas) e uma gama de serviços gerenciados que eliminam o trabalho pesado indiferenciado. Conceitos de arquitetura como projetar para falhas, baixo acoplamento e infraestrutura imutável ajudam as equipes a explorar os benefícios da nuvem: tempo de lançamento no mercado mais rápido, economia de pagamento pelo uso e escala global. Primitivas de rede como VPCs, subnets e um Internet Gateway controlam a entrada e saída (ingress e egress) de tráfego para as cargas de trabalho, enquanto o Direct Connect oferece um link dedicado de alta vazão para datacenters on-premises quando é necessária largura de banda previsível ou menor latência. Para migrações físicas muito grandes ou conectividade intermitente, os dispositivos Snowball Edge permitem a transferência offline segura e até mesmo computação de borda (edge compute). Armadilhas comuns para profissionais incluem presumir que o “lift-and-shift” reduzirá custos automaticamente, subestimar as taxas de saída de rede (egress) e não projetar para resiliência multi-AZ. Os critérios de decisão devem ponderar os requisitos de disponibilidade do negócio, a gravidade dos dados (data gravity), as restrições de latência e os custos operacionais de longo prazo antes de escolher estratégias de rehost, replatform ou refactor.

Serviços, padrões de migração e decisões de arquitetura

A escolha do serviço AWS correto depende se você precisa de operações gerenciadas, controle sobre as responsabilidades no nível do sistema operacional ou capacidades de borda/offline. Os padrões de migração incluem rehost (lift-and-shift), replatform (fazer pequenas otimizações) e refactor (rearquitetar para cloud-native). As escolhas de armazenamento refletem os padrões de acesso: S3 para armazenamento de objetos e data lakes, EBS para armazenamento em bloco anexado a instâncias EC2, EFS para sistemas de arquivos compartilhados POSIX e as variantes do FSx para necessidades de arquivos gerenciados do Windows ou de alto desempenho. Bancos de dados podem ser executados como serviços gerenciados, como o Amazon RDS e o Amazon DynamoDB, que desoneram tarefas administrativas, ou autogerenciados em EC2, onde o cliente retém as responsabilidades de sistema operacional, aplicação de patches, backups e escalonamento. Para contêineres, as opções gerenciadas reduzem a carga operacional, oferecendo diferentes trade-offs:

Amazon ECS (EC2 launch): orquestração gerenciada, mas você gerencia os hosts EC2.
Amazon ECS / Fargate: contêineres serverless sem gerenciamento de hosts.
Amazon EKS: control plane do Kubernetes gerenciado; você pode gerenciar os nós ou usar o Fargate. Para uma implantação rápida de aplicações sem configurar manualmente cada recurso, o AWS Elastic Beanstalk ou os templates do CloudFormation aceleram a entrega, ao mesmo tempo que impõem arquiteturas padronizadas. Armadilhas para profissionais incluem subestimar o esforço operacional de bancos de dados ou hosts de contêineres autogerenciados e esquecer de anexar perfis de instância IAM (instance profiles) às instâncias EC2 para acesso seguro aos serviços.

Economia da nuvem: modelos de precificação e práticas de otimização de custos

A AWS oferece múltiplos modelos de precificação para corresponder à previsibilidade da carga de trabalho e à tolerância a interrupções. On-Demand é flexível e sem compromisso, Reserved Instances e Savings Plans oferecem grandes descontos para uso de estado estável (steady-state), Spot Instances têm descontos profundos, mas podem ser interrompidas, e Dedicated Hosts atendem a necessidades regulatórias ou de licenciamento. A visibilidade e o controle de custos dependem de tagging, Cost Explorer, AWS Budgets e AWS Cost Anomaly Detection; ferramentas de dimensionamento correto (rightsizing), como o AWS Compute Optimizer e as recomendações de recursos do Cost Explorer, ajudam a identificar instâncias EC2 superprovisionadas. O Trusted Advisor expõe otimizações de custo e desempenho e destaca recursos órfãos, enquanto o AWS Budgets pode disparar alertas do SNS quando os gastos excedem os limites. Armadilhas comuns incluem comprar Reserved Instances ou Savings Plans sem analisar a utilização histórica, aplicar Spot Instances a cargas de trabalho críticas e não interrompíveis, e não implementar um tagging consistente, o que prejudica os esforços de estorno (chargeback) e otimização. Os critérios de decisão devem combinar padrões de carga de trabalho, tolerância a interrupções e previsão (forecasting): use On-Demand para cargas imprevisíveis, Savings Plans ou RIs para linhas de base sustentadas e Spot para computação flexível e tolerante a falhas.

Segurança, responsabilidade compartilhada e melhores práticas operacionais

A segurança na AWS é um modelo compartilhado: a AWS protege a infraestrutura da nuvem (hardware, rede, regiões, Zonas de Disponibilidade e serviços fundamentais), enquanto os clientes são responsáveis pela segurança na nuvem — isso inclui dados, controle de acesso, criptografia em nível de aplicação, aplicação de patches no SO e em software para IaaS e federação de identidade. Use IAM roles anexadas a perfis de instância (instance profiles) do EC2 para conceder acesso temporário com o mínimo de privilégios a serviços como o S3; evite incorporar credenciais de longa duração nas instâncias. Os recursos de proteção de dados incluem o versionamento (versioning) do S3 e o Object Lock para retenção, criptografia no lado do servidor (server-side encryption - SSE) e criptografia no lado do cliente (client-side encryption) para registros sensíveis. O monitoramento e a auditabilidade contam com o CloudTrail para registro de logs de API, o AWS Config para conformidade de configuração, o Amazon Inspector para avaliações de vulnerabilidade de cargas de trabalho no EC2, o GuardDuty para detecção de ameaças e o Amazon Macie para descoberta de dados sensíveis no S3. O Well-Architected Framework orienta considerações operacionais, de segurança, confiabilidade, performance e custo; erros comuns dos profissionais incluem o uso excessivo da conta root, negligenciar backups automatizados e não implementar arquiteturas multi-AZ ou planos de Recuperação de Desastres (Disaster Recovery). As decisões operacionais devem priorizar a automação, o princípio do menor privilégio e o registro centralizado de logs para reduzir o erro humano e acelerar a resposta a incidentes.

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

Cenário: A Acme Analytics executa um pipeline de processamento de dados sazonal em uma única Região da AWS. Seu ambiente inclui instâncias EC2 para computação, um arquivo on-premises e um data lake no S3. Eles precisam ingerir 50 TB do ambiente on-premises a cada temporada, garantir alta disponibilidade durante as execuções e controlar os custos entre as temporadas.

Desafio: Transferência de dados em massa de 50 TB com largura de banda limitada e a necessidade de uma ingestão durável e auditável; a computação deve ser altamente disponível durante uma janela de processamento de dois meses e ter um custo-benefício eficiente quando ociosa.

Abordagem Recomendada:

Solicitar um Amazon Snowball Edge para importar com segurança os 50 TB para o Amazon S3, usando a computação de borda (edge compute) se o pré-processamento for necessário.
Armazenar os dados ingeridos em um bucket S3 com o versionamento (versioning) ativado e aplicar o S3 Object Lock para a retenção dos registros de origem.
Executar o processamento em grupos de Auto Scaling de instâncias EC2 distribuídas em múltiplas Zonas de Disponibilidade (Availability Zones) ou usar o AWS Batch/ECS Fargate para escalonamento gerenciado durante a janela de dois meses.
Implementar o Cost Explorer, o AWS Budgets com alertas e aplicar Savings Plans ou Reserved Instances apenas para os recursos persistentes de base; encerrar ou reduzir a escala da computação após a temporada.

Justificativa: O Snowball Edge minimiza o tempo de transferência e os custos de rede para grandes importações únicas, enquanto o S3 oferece armazenamento durável e auditável. O uso de Auto Scaling ou computação gerenciada durante os meses de pico oferece disponibilidade e só incorre em custos durante o processamento, enquanto as ferramentas de gerenciamento de custos evitam gastos inesperados.

Todos os domínios · Infraestrutura Global da AWS →

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