AWS CCP — Guia de Estudo

Estrutura do Exame CLF-C02

• 65 questões (50 pontuadas + 15 não pontuadas)
• 90 minutos | Aprovação: 700/1000
• Formato: múltipla escolha + múltipla resposta

1. Conceitos de Nuvem

Benefícios da Nuvem (os 6 da AWS)

A AWS descreve formalmente seis benefícios da computação em nuvem. Eles aparecem frequentemente em questões que perguntam “qual benefício da nuvem se aplica a este cenário?”. Memorize o nome e o que ele significa na prática.

Cenário de prova — benefícios: Se a questão diz “empresa quer lançar em três países sem escritórios locais” → resposta envolve global em minutos. Se diz “empresa quer evitar comprar servidores antecipadamente” → Trade CapEx por OpEx. Se diz “empresa não sabe quanto de capacidade vai precisar no Black Friday” → parar de adivinhar capacidade.

Modelos de Serviço

A diferença entre IaaS, PaaS e SaaS é sobre o quanto você gerencia. Pense assim: em IaaS você aluga o terreno e constrói tudo; em PaaS você aluga um apartamento já com encanamento e elétrica; em SaaS você usa um hotel — tudo pronto, só entrar.

Cenário de prova — modelos: Se a questão diz “desenvolvedor quer fazer deploy da aplicação sem se preocupar com SO ou patches” → PaaS (Elastic Beanstalk). Se diz “empresa precisa de controle total sobre o sistema operacional” → IaaS (EC2).

Modelos de Implantação

Infraestrutura Global AWS

A infraestrutura global da AWS é composta de camadas com propósitos distintos — e essa distinção cai bastante na prova.

Uma Região é uma área geográfica com dois ou mais data centers isolados entre si. Exemplos: us-east-1 (Norte da Virgínia), sa-east-1 (São Paulo). Você escolhe a região ao criar recursos. Critérios de escolha: latência, compliance de dados, disponibilidade de serviços, custo.

Uma Availability Zone (AZ) é um ou mais data centers físicos dentro de uma região, conectados por rede de baixíssima latência, mas fisicamente separados (energia, rede, localização). Quando você distribui sua aplicação em múltiplas AZs, uma falha em um data center não derruba o sistema inteiro. É o bloco fundamental de alta disponibilidade na AWS.

Uma Edge Location é um ponto de presença distribuído globalmente (100+ no mundo), usado pelo CloudFront para cachear conteúdo perto dos usuários finais e pelo Route 53 para responder queries DNS rapidamente. Edge Locations não rodam EC2 nem RDS — elas servem conteúdo em cache.

Uma Local Zone é uma extensão de região para cidades específicas que precisam de latência ultra-baixa. Exemplo: uma aplicação de trading em São Paulo pode usar uma Local Zone próxima à bolsa.

Dica de prova: Edge Locations ≠ AZs. Edge = CloudFront/Route 53. AZ = onde rodam EC2/RDS. Região = conjunto de AZs numa área geográfica.

2. Segurança & Compliance

Modelo de Responsabilidade Compartilhada

Este é o conceito mais importante do CCP e aparece em pelo menos 5-8 questões direta ou indiretamente. O princípio central é simples: AWS cuida da segurança da nuvem; você cuida da segurança dentro da nuvem.

A AWS garante que o hardware físico não seja comprometido, que os data centers sejam seguros, que a rede global funcione corretamente, que o hypervisor de virtualização não tenha brechas. Tudo isso é responsabilidade dela, e você não tem visibilidade nem controle sobre isso — confia na AWS.

Você, como cliente, é responsável pelo que coloca dentro dessa infraestrutura: seus dados, suas configurações de acesso (IAM), seu código, as regras de firewall que você cria (Security Groups), a criptografia que você habilita ou não, o sistema operacional que você atualiza (ou não) em instâncias EC2.

O que muda entre os modelos de serviço:

EC2 (IaaS): A AWS entrega uma máquina virtual funcionando. Tudo acima do hypervisor é seu: você instala o SO, você faz os patches, você configura o firewall, você gerencia as chaves SSH. Se o SO não for atualizado e houver uma vulnerabilidade, isso é culpa sua, não da AWS.

RDS (PaaS): A AWS entrega um banco de dados gerenciado. Ela instala o banco, faz patches do motor de banco, gerencia o SO subjacente, faz backups automáticos. Você configura as regras de acesso (Security Groups), gerencia usuários do banco e cuida dos dados que armazena. Você não tem acesso SSH ao servidor — nem precisa.

Lambda (Serverless): Você entrega apenas o código. A AWS gerencia absolutamente tudo mais: o runtime, o SO, os patches, a escalabilidade. Sua responsabilidade se resume ao código em si e às permissões IAM que você configura para a função.

Exemplos exatos que caem na prova:

• Quem corrige falha física em servidor EC2? → AWS (hardware é responsabilidade dela)
• Quem configura as regras do Security Group? → Cliente
• Quem gerencia o SO de uma instância RDS? → AWS (serviço gerenciado)
• Quem gerencia o SO de uma EC2? → Cliente (IaaS — você tem controle total)
• Quem criptografa os dados em repouso no S3? → Cliente (você habilita ou não a criptografia)
• Quem garante que o data center tem segurança física? → AWS

IAM — Identidade e Acesso

IAM é o sistema de controle de acesso da AWS. Entender a diferença entre as quatro entidades é fundamental — cada uma existe por um motivo específico.

User representa uma identidade com credenciais permanentes — uma pessoa ou uma aplicação que precisa de acesso à AWS. Exemplo real: você cria um User para o desenvolvedor João, que recebe um login no Console e chaves de API. O problema de criar Users para tudo é que as credenciais existem indefinidamente e precisam ser rotacionadas manualmente. Para serviços que precisam chamar a API da AWS, User não é a melhor opção — é aí que Role entra.

Group é simplesmente um contêiner de Users. Você não autentica como um Group — você cria o Group “Developers”, atribui a política de permissões ao Group, e adiciona Users ao Group. Assim, todos os desenvolvedores herdam as mesmas permissões. Quando João sair da empresa, você o remove do Group e ele perde acesso automaticamente. Best practice: nunca atribua políticas diretamente a Users; use Groups.

Role é o conceito mais poderoso e frequentemente mal compreendido. Uma Role não tem credenciais permanentes — ela gera credenciais temporárias quando é assumida. Quem pode assumir uma Role? Serviços AWS (EC2 chamando o S3, Lambda acessando DynamoDB), usuários de outras contas AWS, ou identidades federadas (login via Google, Active Directory). Exemplo prático: sua aplicação no EC2 precisa ler arquivos do S3. Em vez de colocar chaves de API hardcodadas no código (péssima prática), você cria uma Role com permissão de leitura no S3 e atribui essa Role à instância EC2. A instância recebe credenciais temporárias automaticamente, sem você gerenciar nada.

Policy é o documento JSON que define as permissões. Uma Policy diz: “para qual serviço, qual ação, em qual recurso, Allow ou Deny”. Ela não existe sozinha — precisa ser anexada a um User, Group ou Role para ter efeito.

Boas práticas IAM:

• Root account → apenas para setup inicial; habilitar MFA imediatamente
• Nunca use root para tarefas do dia a dia — crie um User administrador e use esse
• Criar Users individuais (nunca compartilhar credenciais)
• Princípio do menor privilégio: conceda apenas o que é necessário para a tarefa
• Usar Roles para serviços (EC2, Lambda) ao invés de access keys hardcodadas no código
• Rotacionar access keys regularmente
• Habilitar MFA para Users com acesso privilegiado

Cenário de prova — IAM: Se a questão diz “aplicação rodando no EC2 precisa acessar o DynamoDB” → IAM Role (não User, não chave hardcodada). Se diz “como garantir que todos os desenvolvedores tenham as mesmas permissões sem configurar individualmente” → IAM Group. Se diz “usuário externo precisa acessar temporariamente a conta AWS” → Role com trust policy.

Serviços de Segurança: o quarteto que mais cai

Quatro serviços causam confusão sistemática na prova porque todos parecem fazer “segurança”, mas cada um faz uma coisa diferente. Entender a diferença é questão certa.

GuardDuty detecta comportamentos maliciosos analisando logs que já existem na sua conta (CloudTrail, VPC Flow Logs, DNS). Ele não instala nada nas instâncias — é totalmente passivo. A analogia é um sistema de câmeras de segurança: fica observando tudo silenciosamente e dispara um alerta quando vê algo suspeito. Exemplos do que ele detecta: comunicação com endereços IP maliciosos conhecidos, tentativas de reconnaissance, chamadas de API incomuns de locais geográficos inesperados, instâncias EC2 comunicando com servidores de command-and-control. GuardDuty não bloqueia nada — ele detecta e alerta. Tem trial de 30 dias gratuito.

Inspector é o oposto em termos de postura: ele é ativo. O Inspector faz scan nas suas instâncias EC2 e nos containers (ECR) buscando vulnerabilidades conhecidas — CVEs (Common Vulnerabilities and Exposures), exposição involuntária de portas, desvios de benchmark de segurança. Ele instala um agente na instância (ou analisa imagens de container) e gera um relatório de vulnerabilidades priorizadas por severidade. Use Inspector quando quiser saber “tem algum software desatualizado com vulnerabilidade conhecida nessa instância?”. Tem trial de 90 dias.

Macie foca exclusivamente no S3. Ele usa machine learning para varrer seus buckets S3 e identificar dados sensíveis — PII (CPF, nome, endereço, email), números de cartão de crédito, credenciais, passwords. O problema que ele resolve: “será que algum desenvolvedor acidentalmente subiu um dump de banco com dados de clientes em um bucket de acesso público?”. Macie também detecta buckets com configurações arriscadas (acesso público habilitado, criptografia desabilitada).

Detective é o investigador. Quando o GuardDuty encontrou algo suspeito e você precisa entender o que aconteceu, quem fez, quando, de onde — você usa o Detective. Ele agrega e correlaciona dados de múltiplas fontes (CloudTrail, VPC Flow Logs, GuardDuty findings) e apresenta visualizações em grafo para ajudar a reconstruir a linha do tempo de um incidente. A analogia: GuardDuty é o alarme que disparou; Detective é o investigador que chega depois para analisar as evidências.

Cenário de prova — quarteto de segurança: Se a questão menciona “detectar atividade suspeita ou anomalia na conta” → GuardDuty. Se menciona “verificar vulnerabilidades em instâncias EC2” → Inspector. Se menciona “dados pessoais no S3, conformidade com LGPD/GDPR” → Macie. Se menciona “investigar causa raiz de incidente de segurança” → Detective.

Outros Serviços de Segurança

Shield Standard vs Advanced: Todo mundo tem Standard automaticamente, sem custo. Advanced é para organizações com aplicações críticas que precisam de resposta rápida da equipe de segurança AWS, relatórios detalhados de ataques e, importante, proteção contra cobranças excessivas de EC2/ELB causadas por DDoS.

KMS vs CloudHSM: KMS é o serviço padrão — AWS gerencia o hardware dos HSMs mas você controla as políticas de uso das chaves. CloudHSM é quando você precisa de HSM dedicado onde somente você tem as chaves (multi-tenant vs single-tenant). CloudHSM é significativamente mais caro e para casos de conformidade específicos (ex: FIPS 140-2 Level 3).

Secrets Manager vs Parameter Store: Secrets Manager cobra por segredo e tem rotação automática integrada com RDS/outros serviços. Parameter Store (do Systems Manager) tem um tier gratuito para parâmetros simples mas sem rotação automática. Para a prova CCP: “rotação automática de senhas de banco” → Secrets Manager.

CloudTrail vs CloudWatch vs Config

Esta é a outra tríade que mais causa confusão, depois do quarteto de segurança.

CloudTrail responde à pergunta: “quem fez o quê na conta AWS?”. Ele registra cada chamada de API — seja pelo Console, CLI, SDK ou outro serviço. Exemplo: alguém deletou um bucket S3 às 3h da manhã. CloudTrail tem o registro de qual usuário fez isso, de qual IP, em qual momento. É o log de auditoria da conta. Por padrão, os logs ficam disponíveis por 90 dias no CloudTrail Event History. Para retenção longa, você configura um Trail que envia os logs para um bucket S3.

CloudWatch responde à pergunta: “o que está acontecendo com meus recursos agora?”. É a plataforma de observabilidade da AWS: coleta métricas (CPU de EC2, latência de RDS, erros de Lambda), armazena logs de aplicação, dispara alarmes quando métricas passam de um threshold. Exemplo: “me avise quando o uso de CPU de qualquer instância EC2 passar de 80% por 5 minutos” → CloudWatch Alarm. “Quero ver os logs da minha aplicação Node.js” → CloudWatch Logs.

Config responde à pergunta: “minha infraestrutura está configurada da forma correta?”. Ele rastreia mudanças de configuração de recursos ao longo do tempo e verifica conformidade com regras. Exemplo: “todo bucket S3 deve ter Block Public Access habilitado” — Config verifica todos os buckets e marca os que estão em non-compliance. Se você quer saber “como estava a configuração desse Security Group há 30 dias” → Config tem o histórico.

Cenário de prova — tríade: Se a questão diz “detectar mudanças não autorizadas em recursos AWS” → CloudTrail (quem mudou) ou Config (o que mudou). Se diz “monitorar performance de instâncias EC2” → CloudWatch. Se diz “verificar compliance de configuração” → Config.

Compliance & Programas

A AWS mantém certificações de conformidade que você herda ao usar os serviços. Use AWS Artifact para baixar os relatórios e assinar acordos como o BAA (Business Associate Agreement) exigido para HIPAA.

• HIPAA — regulação de privacidade de dados de saúde nos EUA
• PCI DSS — padrão de segurança para processamento de cartões de crédito
• SOC 1/2/3 — relatórios de controles internos de segurança, disponibilidade e confidencialidade
• ISO 27001 — gestão de segurança da informação
• GDPR — regulação europeia de proteção de dados pessoais

3. Tecnologia & Serviços Cloud

EC2 — Elastic Compute Cloud

EC2 é a base do IaaS da AWS: máquinas virtuais que você aluga por hora ou segundo. Você escolhe o tipo (quantidade de CPU, RAM), o sistema operacional, o armazenamento e a rede.

Tipos de instância (famílias):

Modelos de Compra EC2: quando usar cada um

Entender quando cada modelo faz sentido é mais importante que memorizar o percentual de desconto.

On-Demand é o modelo padrão: você paga pelo que usa, sem compromisso. É o mais caro por hora, mas sem lock-in. Use para workloads imprevisíveis, ambientes de desenvolvimento, testes, ou qualquer coisa que você não sabe quanto tempo vai rodar. É o ponto de partida antes de otimizar.

Reserved Instances (1 ou 3 anos) fazem sentido quando você tem certeza que vai precisar de uma certa capacidade por pelo menos um ano. Um banco de dados de produção que roda 24/7, um servidor de aplicação sempre ativo — esses são candidatos perfeitos para Reserved. Você se compromete com o tipo de instância e paga menos (até 72%). Existe a opção de pagar tudo upfront (maior desconto), parcialmente upfront, ou nada upfront. Atenção: Reserved Instance é um compromisso de faturamento, não uma instância reservada para você — você paga se usar ou não.

Savings Plans funcionam de forma similar às Reserved, mas com mais flexibilidade: você se compromete com um gasto em dólares por hora (ex: $10/hora), e a AWS aplica o desconto em qualquer instância EC2, independente do tipo, tamanho ou região. É a opção certa quando você precisa de desconto mas quer flexibilidade para mudar tipo de instância ou região.

Spot Instances são a opção mais barata (até 90% de desconto), mas com uma condição: a AWS pode interromper sua instância com 2 minutos de aviso quando precisar de capacidade de volta. Por isso, Spot é ideal apenas para workloads tolerantes a interrupção: processamento em batch (análise de dados, transcoding de vídeo), treinamento de modelos de ML, simulações científicas, renderização. Nunca use Spot para banco de dados de produção ou qualquer aplicação que não suporte ser interrompida no meio.

Dedicated Host aloca um servidor físico inteiro para você. O motivo geralmente é compliance de licenciamento: softwares como Oracle, Windows Server, SQL Server têm licenças atadas ao número de sockets físicos ou cores físicos. Para usar essas licenças existentes (BYOL — Bring Your Own License) corretamente, você precisa saber exatamente qual hardware está usando.

Dedicated Instance garante isolamento físico — sua instância roda em hardware que não é compartilhado com outras contas AWS. A diferença do Dedicated Host: você não tem visibilidade nem controle de qual servidor físico específico é seu. Use quando o requisito é “isolamento de hardware por questão de compliance” sem necessidade de controle de licença por socket.

Cenário de prova — modelos de compra: “Workload imprevisível, precisa escalar e diminuir” → On-Demand. “Servidor de produção rodando 24/7 há 2 anos” → Reserved. “Processamento de batch que pode ser interrompido” → Spot. “Precisam controlar licença Oracle por socket” → Dedicated Host. “Querem desconto com flexibilidade de mudar tipo de instância” → Savings Plans.

S3 — Simple Storage Service

O S3 é o serviço de armazenamento de objetos da AWS. “Objeto” significa que você armazena arquivos com metadados — não é um sistema de arquivos (sem hierarquia real de diretórios) e não é block storage. A durabilidade é impressionante: 11 noves (99.999999999%) — para um milhão de arquivos, você esperaria perder um objeto a cada 100.000 anos. A disponibilidade varia por classe.

A escolha de classe é um trade-off entre custo de armazenamento e custo + latência de recuperação. A regra geral: quanto mais barato o armazenamento, mais caro e demorado é recuperar.

S3 Standard é para dados que você acessa com frequência. Latência de milissegundos, alta disponibilidade (99.99%), sem custo de recuperação. Use para assets de sites, arquivos de aplicação ativos, dados que users baixam frequentemente. É o tier padrão e o mais caro por GB.

S3 Intelligent-Tiering é para quando você não sabe o padrão de acesso. O S3 monitora automaticamente o acesso de cada objeto e move entre camadas automaticamente — se o objeto não for acessado por 30 dias, vai para IA; se for acessado novamente, volta para Standard. Há uma pequena taxa mensal de monitoramento por objeto. Ideal para data lakes onde alguns dados são acessados frequentemente e outros raramente.

S3 Standard-IA (Infrequent Access) é para dados que você raramente acessa mas que precisam estar disponíveis rapidamente quando necessário. Exemplos: backups mensais, logs de um ano atrás, arquivos de projetos concluídos. Custo de armazenamento menor que Standard, mas há cobrança por recuperação. Há também um tamanho mínimo de objeto (128KB) e duração mínima (30 dias).

S3 One Zone-IA é igual ao Standard-IA, mas os dados ficam em apenas uma AZ em vez de três. Isso reduz o custo em ~20%, mas sacrifica resiliência — se aquela AZ falhar, os dados ficam inacessíveis (não são perdidos permanentemente, mas ficam indisponíveis). Use apenas para dados que podem ser recriados ou que têm cópia em outro lugar.

S3 Glacier Instant Retrieval é para arquivos que você acessa raramente (uma vez por trimestre, por exemplo) mas que precisam de resposta rápida quando acessados (milissegundos). Custo de armazenamento muito menor, mas custo de recuperação mais alto.

S3 Glacier Flexible Retrieval é para arquivos de longa duração onde você aceita aguardar para recuperar. Recuperação em minutos (Expedited), horas (Standard) ou 5-12 horas (Bulk, mais barato). Use para backups de compliance que você raramente ou nunca vai precisar acessar.

S3 Glacier Deep Archive é o armazenamento mais barato da AWS. Recuperação em 12 horas (Standard) ou 48 horas (Bulk). Para dados que você precisa guardar por anos mas que você quase certamente nunca vai precisar acessar — compliance de 7 anos, registros históricos, arquivos de mídia de décadas passadas.

Conceitos importantes:

• Durabilidade: 11 noves (99.999999999%) — todos os tiers
• Disponibilidade Standard: 99.99%
• Objetos: até 5 TB por objeto
• Buckets são globais (nomes únicos mundialmente), mas dados ficam na região escolhida
• S3 não é sistema de arquivos — é object storage

Cenário de prova — classes S3: “Backups diários raramente acessados mas precisam de disponibilidade imediata quando necessários” → Standard-IA. “Arquivos de compliance de 7 anos que provavelmente nunca serão acessados” → Glacier Deep Archive. “Não sabe o padrão de acesso” → Intelligent-Tiering. “Imagens acessadas por usuários do site” → Standard.

Banco de Dados

A AWS oferece bancos de dados específicos para diferentes casos de uso. A escolha deve ser guiada pelo tipo de dado e padrão de acesso.

RDS: Multi-AZ vs Read Replica

Esta é uma distinção que cai bastante. Multi-AZ existe para disponibilidade, não para performance. A AWS mantém uma réplica síncrona do seu banco em outra AZ — cada escrita no primário só é confirmada depois que a réplica também escreveu. Se o primário cair, o failover é automático (aproximadamente 1-2 minutos) e o DNS do endpoint aponta para a réplica sem você mudar nada na aplicação. A réplica em Multi-AZ não aceita queries de leitura — ela existe apenas para failover.

Para escalar leituras, existe a Read Replica: uma cópia assíncrona do banco que aceita consultas SELECT. Sua aplicação precisa ser configurada para enviar leituras para o endpoint da Read Replica. Pode ter Read Replicas em outras regiões (Global Read Replicas), o que também ajuda com latência para usuários geográficos.

Cenário de prova — RDS: “Quer que o banco continue funcionando se houver falha em uma AZ” → Multi-AZ. “Quer escalar consultas de leitura sem sobrecarregar o primário” → Read Replica.

Redes

A rede na AWS começa com a VPC.

VPC (Virtual Private Cloud) é sua rede privada virtual dentro da AWS. Você define o range de IP (CIDR block), cria subnets (públicas e privadas), configura tabelas de roteamento e gateways. Uma subnet pública tem acesso à internet via Internet Gateway; uma subnet privada não tem acesso direto à internet (você usa NAT Gateway se precisar que recursos privados façam requisições de saída).

Security Group vs NACL é uma distinção que cai na prova com regularidade. Security Group é um firewall stateful aplicado no nível da instância (EC2, RDS, etc.) — stateful significa que se você permite tráfego de entrada em uma porta, a resposta de saída é automaticamente permitida. Security Group só tem regras de Allow (sem Deny explícito). NACL (Network Access Control List) é um firewall stateless aplicado no nível da subnet — stateless significa que você precisa definir regras de entrada E saída separadamente. NACL tem regras de Allow e Deny, processadas em ordem numérica.

Route 53 é o DNS gerenciado da AWS. Além de resolver nomes de domínio, oferece roteamento inteligente: latency-based (direciona para a região mais próxima do usuário), failover (muda para um endpoint backup se o primário falhar), geolocation, weighted (divide tráfego entre endpoints com pesos).

CloudFront é a CDN global da AWS. Cacheia conteúdo (arquivos estáticos, vídeos, APIs) nas Edge Locations próximas aos usuários, reduzindo latência e carga nos servidores de origem. Funciona com S3, EC2, ALB ou qualquer servidor HTTP como origem.

Direct Connect é uma conexão física dedicada entre seu data center on-premises e a AWS, através de um parceiro de conectividade. Oferece largura de banda consistente e baixa latência, sem passar pela internet pública. Use quando você tem grandes volumes de dados a transferir regularmente ou aplicações sensíveis à latência variável da internet.

VPN cria um túnel criptografado entre sua rede on-premises e a VPC, passando pela internet pública. É mais rápido de configurar e mais barato que Direct Connect, mas a performance depende da qualidade da conexão com a internet.

Computação Adicional

Lambda vs EC2: Lambda é ideal para funções curtas (máximo 15 minutos), event-driven, que escalam automaticamente para zero quando não há requisições (você não paga nada quando não usa). EC2 é ideal quando você precisa de controle do ambiente, processos de longa duração, ou quando o custo de Lambda seria maior que EC2 com alto volume de requisições contínuas.

ECS vs EKS vs Fargate: ECS é o orquestrador de containers nativo da AWS — simples de configurar. EKS é Kubernetes — use quando você já tem expertise em K8s ou precisa de portabilidade. Fargate é o motor de execução serverless que funciona com ambos — elimina o gerenciamento de servidores.

Armazenamento Adicional

Monitoramento & Gerenciamento: CloudTrail, CloudWatch e Config revisitados

(Ver seção 2 para a explicação aprofundada das diferenças entre os três.)

Trusted Advisor merece destaque: ele analisa sua conta e sugere melhorias em cinco categorias — Cost Optimization (ex: “você tem instâncias EC2 subutilizadas”), Performance, Security (ex: “você tem Security Groups muito permissivos”), Fault Tolerance e Service Limits. O plano Basic/Developer só dá acesso a 7 checks de segurança básicos; os planos Business e Enterprise têm acesso completo a todos os checks.

Mensageria & Integração

SQS vs SNS: SQS é para desacoplamento ponto-a-ponto — um produtor, uma fila, múltiplos consumidores competindo. SNS é para fan-out — uma mensagem precisa ser entregue para N destinos diferentes simultaneamente. Padrão comum: SNS → múltiplas filas SQS (fan-out + processamento assíncrono).

Analytics

AI & Machine Learning (Domínio 3.7 — adicionado no CLF-C02)

O CLF-C02 adicionou serviços de IA como domínio. O nível de profundidade esperado no CCP é: saber o que cada serviço faz e para qual tipo de problema se aplica.

Dica de memorização dos serviços de AI: Pense no fluxo de processamento: Transcribe (áudio → texto) → Comprehend (texto → insights) → Translate (texto → outro idioma) → Polly (texto → fala de volta). Rekognition é só para imagens/vídeo. Textract é para documentos físicos digitalizados. SageMaker é para quando você quer construir seus próprios modelos. Lex é para chatbots. Kendra é para pesquisa.

Nota importante: Amazon Bedrock não está no escopo oficial do CLF-C02. Para IA generativa em profundidade, existe a certificação separada AWS Certified AI Practitioner (AIF-C01).

Migração & Transferência

Quando usar Snowball: Quando o volume de dados a transferir levaria semanas ou meses pela internet, ou quando a conexão é muito cara. A AWS entrega o dispositivo físico, você carrega os dados, devolve, e a AWS importa para o S3.

Developer Tools

4. Billing, Pricing & Suporte

Modelos de Preço

A AWS opera com três princípios de precificação:

Ferramentas de Custo

Pricing Calculator vs Cost Explorer: Pricing Calculator é para estimar custos de arquiteturas antes de criar. Cost Explorer é para analisar gastos depois que os recursos já existem.

Well-Architected Framework — os 6 Pilares

O Well-Architected Framework é um conjunto de melhores práticas para construir sistemas na AWS. Os 6 pilares aparecem frequentemente na prova — você precisa saber o nome de cada um e o que ele protege.

Excelência Operacional trata de como você opera e melhora seus sistemas. Inclui automação de operações, monitoramento, resposta a eventos, e aprendizado contínuo com falhas. Pergunta central: “você consegue operar e evoluir o sistema com confiança?”. Exemplo de prática: usar Infrastructure as Code (CloudFormation), fazer deploys pequenos e frequentes, criar runbooks para operações rotineiras.

Segurança cobre proteção de dados, sistemas e assets contra ameaças. Inclui gerenciamento de identidade (IAM), proteção de dados em trânsito e em repouso, resposta a incidentes de segurança. Pergunta central: “os dados e sistemas estão protegidos?”. Exemplo de prática: princípio do menor privilégio, criptografia habilitada, MFA em todas as contas.

Confiabilidade trata da capacidade do sistema de funcionar corretamente e se recuperar de falhas. Inclui recuperação de falhas, escalabilidade horizontal, teste de recuperação de desastres. Pergunta central: “o sistema continua funcionando quando algo falha?”. Exemplo de prática: distribuir em múltiplas AZs, usar Auto Scaling, testar backups periodicamente.

Eficiência de Performance trata de usar recursos computacionais eficientemente para atender requisitos. Inclui escolher os tipos de recursos certos, monitorar performance e adaptar à medida que as necessidades mudam. Pergunta central: “estou usando os recursos mais adequados para a tarefa?”. Exemplo de prática: usar instâncias com GPU apenas para workloads GPU-bound, usar cache (ElastiCache) para reduzir carga no banco.

Otimização de Custos trata de evitar gastos desnecessários. Inclui eliminar recursos ociosos, usar modelos de compra adequados (Reserved, Spot), monitorar gastos. Pergunta central: “estou pagando o preço justo pelo valor que recebo?”. Exemplo de prática: usar Reserved Instances para workloads estáveis, Spot para batch, desligar ambientes de dev à noite.

Sustentabilidade (adicionado em 2021) trata de minimizar o impacto ambiental das cargas de trabalho. Inclui maximizar utilização de recursos, usar regiões com energia renovável, eliminar provisionamento excessivo. Pergunta central: “estou minimizando o footprint ambiental da arquitetura?”.

Planos de Suporte: como escolher

Os planos de suporte não se diferenciam apenas pelo preço — o critério correto de escolha é a criticidade do sistema e o tipo de acesso que você precisa.

Basic é gratuito para todos os clientes AWS. Dá acesso à documentação, fóruns da comunidade, AWS Health Dashboard e um subconjunto de 7 checks do Trusted Advisor (os mais básicos de segurança). Não há acesso a suporte técnico da AWS — nenhum engenheiro atende você. Adequado para contas de estudo, exploração e projetos pessoais sem produção.

Developer custa a partir de $29/mês. Adiciona acesso por email a engenheiros de suporte em horário comercial (não 24/7). O SLA de resposta é de 12-24 horas para problemas gerais. É adequado para ambientes de desenvolvimento ou testes onde um atraso de algumas horas é aceitável.

Business custa a partir de $100/mês (escala com o uso). É um salto significativo: suporte 24/7 por telefone, chat e email, acesso completo ao Trusted Advisor, API de suporte, e SLA de 1 hora para sistema de produção fora do ar. Para qualquer empresa com sistemas de produção na AWS, Business é o mínimo recomendado.

Enterprise On-Ramp custa a partir de $5.500/mês. Adiciona acesso a um pool de Technical Account Managers (TAMs), SLA de 30 minutos para sistema crítico fora do ar, e revisões proativas de arquitetura. Para organizações de médio porte com dependência significativa da AWS.

Enterprise custa a partir de $15.000/mês. Tem um TAM dedicado (que conhece sua arquitetura, participa de reuniões de planejamento, antecipa problemas), SLA de 15 minutos para sistema crítico, e acesso à equipe de gerenciamento de conta executiva da AWS. Para empresas que dependem criticamente da AWS e onde downtime de 15 minutos significa milhões em perda.

Cenário de prova — planos de suporte: “Aplicação de missão crítica em produção que não pode ter downtime” → Enterprise. “Empresa quer suporte 24/7 por telefone ao menor custo” → Business. “Equipe de desenvolvimento testando a AWS” → Developer. “Conta de estudo pessoal” → Basic.

Organizations & Consolidated Billing

AWS Organizations permite gerenciar múltiplas contas AWS centralmente sob uma organização. É o modelo ideal para empresas com múltiplas contas separadas (por ambiente, por equipe, por produto). Você tem uma conta Master (Management Account) que consolida a governança.

Consolidated Billing é um dos benefícios do Organizations: todas as contas da organização têm suas faturas consolidadas em uma única fatura. O benefício financeiro é real — o uso somado de todas as contas conta para os descontos por volume do S3, data transfer e outros serviços.

Service Control Policies (SCP) são políticas aplicadas a OUs (Organizational Units) ou contas inteiras dentro da organização, que definem quais ações são permitidas. SCPs limitam o que até o administrador da conta pode fazer — são uma camada acima do IAM. Exemplo: SCP proibindo que qualquer conta desligue o CloudTrail.

Free Tier

5. Outros Conceitos Frequentes no CCP

Escalabilidade vs Elasticidade vs Alta Disponibilidade

Esses termos parecem sinônimos mas têm significados distintos no contexto da AWS.

Scalability (Escalabilidade) é a capacidade do sistema de crescer para atender demanda maior. Um sistema é escalável se você pode adicionar capacidade. Há dois tipos: vertical (scale up — trocar t3.micro por m5.large, adicionando mais CPU/RAM à mesma máquina) e horizontal (scale out — adicionar mais instâncias ao pool).

Elasticity (Elasticidade) vai além: não só você pode escalar, como o sistema escala automaticamente para cima e para baixo conforme a demanda. Auto Scaling Group é elasticidade. Lambda é inerentemente elástico — escala para zero quando não há requisições, para milhares quando há pico.

High Availability (Alta Disponibilidade) significa que o sistema continua funcionando mesmo quando componentes individuais falham. Uma aplicação em duas AZs com um load balancer na frente é altamente disponível — se uma AZ cair, o tráfego vai automaticamente para a outra.

Fault Tolerance é um grau mais alto que HA: o sistema opera sem degradação perceptível mesmo com falhas. Implica redundância total de todos os componentes críticos.

Disaster Recovery é o conjunto de procedimentos para restaurar operações após um desastre (incêndio no data center, ataque cibernético, erro humano catastrófico). Duas métricas chave: RTO (Recovery Time Objective — quanto tempo para restaurar o sistema) e RPO (Recovery Point Objective — quanto de dados pode ser perdido, ou seja, há quanto tempo foi o último backup).

AWS Cloud Adoption Framework (AWS CAF)

O CAF é um guia da AWS para ajudar organizações a planejar e executar a jornada de adoção da nuvem. Ele divide as atividades necessárias em 6 perspectivas, cada uma cobrindo uma área diferente da organização.

O que diferencia as perspectivas é quem é responsável:

Business foca em garantir que a adoção da nuvem entregue valor de negócio real. As atividades incluem definir casos de uso com ROI claro, criar modelos de negócio para serviços cloud, alinhar investimento em TI com estratégia corporativa. Stakeholders: C-suite, gestores de negócio, CFO.

People trata da dimensão humana da transformação. Mudança de cultura, identificação de gaps de habilidades, treinamento de equipes, criação de novos papéis (Cloud Architect, DevOps Engineer). A adoção da nuvem falha frequentemente não por falta de tecnologia, mas por falta de cultura e habilidades. Stakeholders: RH, líderes de equipe, L&D.

Governance garante que a organização possa gerenciar a nuvem de forma consistente, segura e eficiente. Inclui processos de TI, gestão de portfólio de projetos, compliance, gestão de riscos, KPIs de TI. Stakeholders: CIO, gestores de programa, risk officers.

Platform cobre a arquitetura técnica da nuvem. Provisionamento de infraestrutura, pipelines de CI/CD, padrões de arquitetura de referência, princípios de design de sistemas cloud-native. Stakeholders: arquitetos de soluções, líderes técnicos.

Security garante que a adoção seja feita de forma segura. IAM, proteção de dados, resposta a incidentes, controles de conformidade, gestão de vulnerabilidades. Stakeholders: CISO, equipe de segurança.

Operations garante que os serviços cloud sejam operados de forma eficiente. Monitoramento, gestão de incidentes, continuidade de negócio, disaster recovery, ITSM. Stakeholders: gerentes de operações, time de SRE.

Estratégias de Migração — Os 7 R’s

Quando uma empresa migra para a nuvem, cada aplicação precisa de uma estratégia. Os 7 R’s descrevem as opções:

Cenário de prova — 7 R’s: “Mover servidor de aplicação para EC2 sem alterar código” → Rehost. “Mover banco de dados Oracle para Amazon RDS” → Replatform. “Redesenhar aplicação como microserviços serverless” → Refactor. “Trocar sistema de email interno por Office 365” → Repurchase.

Responsabilidade por Serviço (tabela crítica para prova)

Uma das aplicações mais diretas do modelo de responsabilidade compartilhada é entender quem gerencia o SO de cada tipo de serviço:

Serviços para Alta Disponibilidade

• ELB (Elastic Load Balancer) — distribui tráfego entre instâncias em múltiplas AZs; detecta instâncias não saudáveis e para de enviar tráfego para elas
• Auto Scaling Group — ajusta automaticamente o número de instâncias EC2 com base em métricas (CPU, por exemplo) ou agendamento
• Multi-AZ (RDS) — réplica síncrona do banco em outra AZ com failover automático
• Route 53 — roteamento failover entre regiões; DNS com health checks

6. Simulados Gratuitos

A melhor estratégia de estudo para o CCP é fazer muitos simulados após uma primeira leitura do conteúdo. Use os recursos abaixo em ordem de prioridade.

Como usar: Comece pelo AWS Skill Builder para entender o padrão exato de linguagem da prova real — a forma como a AWS formula questões é específica e você precisa se acostumar. Depois use Tutorials Dojo para volume com qualidade. Kanani Nirav é bom para reforço e volume sem criar conta. ExamTopics tem questões antigas e algumas respostas controversas — sempre leia os comentários da comunidade antes de aceitar a resposta marcada.

7. Checklist Rápido para a Prova

• AWS CAF — 6 perspectivas e qual é o foco de cada uma
• 7 R’s de migração — especialmente Rehost vs Replatform vs Refactor
• Saber os 6 benefícios da nuvem AWS de cor
• Diferenciar IaaS / PaaS / SaaS com exemplos AWS
• Modelo de responsabilidade compartilhada: quem cuida do quê para EC2 vs RDS vs Lambda
• IAM: User vs Group vs Role vs Policy — quando usar cada um com exemplos reais
• Classes S3: quando usar cada uma (custo vs latência de recuperação)
• Tipos EC2: On-Demand vs Reserved vs Spot vs Dedicated Host vs Savings Plans
• Diferença Security Group (stateful, só Allow) vs NACL (stateless, Allow+Deny)
• CloudTrail (quem fez o quê via API) vs CloudWatch (métricas/logs de performance) vs Config (compliance de configuração)
• GuardDuty (detecta ameaças passivamente) vs Inspector (scan ativo de vulnerabilidades) vs Macie (PII no S3) vs Detective (investiga causa raiz)
• Multi-AZ vs Read Replica no RDS — disponibilidade vs escala de leitura
• Audit Manager vs Config: Config = conformidade contínua; Audit Manager = coleta evidências para auditorias
• IAM Identity Center = SSO para múltiplas contas AWS e apps externas
• Planos de suporte: Basic → Developer → Business → Enterprise On-Ramp → Enterprise
• Ferramentas de billing: Pricing Calculator (estimar) vs Cost Explorer (analisar histórico) vs Budgets (alertas)
• Well-Architected Framework — 6 pilares e o que cada um protege
• Infraestrutura global: Região vs AZ vs Edge Location — diferenças e uso de cada
• SQS (fila, desacoplamento) vs SNS (pub/sub, fan-out)
• Lambda vs EC2: quando serverless faz sentido vs quando IaaS faz sentido
• Fargate = serverless containers (elimina gerenciamento de servidores para ECS/EKS)
• Direct Connect (físico, dedicado, consistente) vs VPN (internet, criptografado, rápido de configurar)
• Snowball = migração física de dados em volume; quando a internet seria lenta/cara demais