Modelos de Implantação em Nuvem e Operação na AWS

Toda carga de trabalho precisa responder duas perguntas antes de ir ao ar: onde ela roda? e como vamos operá-la de novo amanhã? O exame chama isso de Domínio 3, Tarefa 3.1, "Definir métodos de implantação e operação na AWS Cloud", e é a tarefa mais orientada a decisão do CLF-C02: a AWS testa explicitamente se você consegue escolher entre o Console, o acesso programático e a infraestrutura como código, se um trabalho é único ou repetível, e qual modelo de implantação corresponde a uma descrição. A armadilha é que a Tarefa 3.1 parece uma tarefa de programação e não é, "Implementação" está listada como tarefa de trabalho fora do escopo, então nunca lhe perguntam como escrever o script, apenas qual porta atravessar.

Nesta lição você vai:

• nomear os quatro modelos de implantação com as palavras da própria AWS e separar híbrido de multi-nuvem;
• mapear IaaS, PaaS e SaaS para exemplos da AWS e ler a transferência de responsabilidade que cada um aciona;
• escolher entre Console, CLI, SDKs, APIs e IaC, e aplicar a regra único versus repetível;
• distinguir CloudFormation de CDK (e saber por que Terraform é pano de fundo, não syllabus);
• escolher a porta de conectividade certa: internet, Direct Connect, Site-to-Site VPN ou um endpoint de VPC / PrivateLink;
• situar Amplify, AppSync e IoT Core onde o guia de exame realmente os testa;
• diferenciar Elastic Beanstalk, Lightsail e CloudFormation pelo trabalho que cada um faz;
• estudar quatro estudos de caso publicados pela AWS sobre Lightsail, operações repetíveis, velocidade de ambiente e migração;
• conferir o que mudou em 2026 nas listas de escopo, nas ferramentas do console e onde você pode provisionar;
• praticar com 12 questões em formato de exame mais cinco verificações interativas.

---

1. O que a Tarefa 3.1 realmente pede

1.1 A tarefa, dividida em conhecimento e habilidades

1.2 A linha de escopo: uma decisão, não uma construção

O guia CLF-C02 lista "Implementação" entre as tarefas de trabalho fora do escopo. Essa única palavra remodela toda questão 3.1: uma opção que diz "escrever um script Python que cria 40 subnets" ou "elaborar um template do CloudFormation com Lambda inline" está descrevendo implementação, e implementação não é o que este exame mede. A opção correta é sempre a seleção: Console versus CLI versus SDK versus IaC, único versus repetível, público versus híbrido.

• 📚 Você sabia? A AWS publica uma regra de paridade que mata uma família inteira de distratores: toda função de administração, gerenciamento e acesso do IaaS disponível na AWS Management Console também está disponível na AWS API e na AWS CLI "no lançamento ou dentro de 180 dias do lançamento." Então a opção que começa com "o Console é a única forma de…" quase sempre está errada, o Console é simplesmente "o método mais comum", não o exclusivo.

1.3 As três listas de serviços que você deve manter separadas

⚠️ O CloudShell é o distrator perfeito. O AWS CloudShell é "um shell baseado em navegador, pré-autenticado, que você pode iniciar diretamente a partir do AWS Management Console", com AWS CLI, EB CLI, ECS CLI e SAM pré-instalados (imagem Amazon Linux 2023). Ele soa ideal para "formas de acessar a AWS", e está explicitamente fora do escopo do CLF-C02. Se uma questão oferece CloudShell ao lado de Console, CLI, SDK e IaC, o CloudShell está ali para ser eliminado, não selecionado. O mesmo destino aguarda as opções de Wavelength, IoT Greengrass e Snow Family.

Atualizações de 2026 (em outubro de 2026)

---

2. Modelos de implantação: público, privado, híbrido e multi-nuvem

2.1 As quatro definições da AWS, com as palavras da própria AWS

O enquadramento híbrido da AWS vale memorizar: "Nuvem híbrida com a AWS oferece uma experiência AWS consistente onde você precisa: da nuvem para on-premises e para a borda", e AWS Outposts é "uma família de serviços totalmente gerenciados que entrega infraestrutura e serviços da AWS para praticamente qualquer local on-premises ou de borda, para uma experiência híbrida verdadeiramente consistente."

2.2 Duas taxonomias, e a linha híbrido/multi-nuvem

O guia de exame diz "nuvem, híbrido, on-premises". As páginas "o que é" da AWS dizem público, privado, híbrido, multi-nuvem. Elas se sobrepõem em vez de conflitar:

A distinção que o exame realmente protege é esta:

• Híbrido = sua infraestrutura + uma nuvem pública. A AWS diz que o gerenciamento híbrido "pode ser feito usando serviços de um único provedor de nuvem."
• Multi-nuvem = serviços de dois ou mais provedores de nuvem de terceiros. No momento em que um enunciado diz "AWS e outro provedor", você está em multi-nuvem, não em híbrido.

2.3 O kit híbrido da AWS que está no escopo

• 📚 Você sabia? O Outposts é entregue como um rack autossuficiente de 42U que precisa de 10 to 30 kVA, e como servidores 1U/2U (tamanhos e valores de potência em outubro de 2026: verifique o estado atual antes do uso). O que torna isso um fato de modelo de implantação e não um fato de hardware é que um Outpost é gerenciado "como parte de uma Região da AWS", então a história híbrida permanece um único modelo operacional: mesmas APIs, mesmo console, mesma ferramenta, CEP diferente.

---

3. Modelos de serviço: IaaS, PaaS, SaaS, e a transferência de responsabilidade

3.1 Os três modelos de serviço

3.2 Exemplo E1: contando a transferência de responsabilidade

A documentação do RDS publica as mesmas nove linhas operacionais para três ambientes. Conte quem possui cada linha:

Seguem três leituras, e todas as três são examináveis:

1. On-premises a contagem é 9 de 9: você possui tudo, incluindo a energia do prédio.
2. O EC2 move três linhas para a AWS (manutenção de servidor, ciclo de vida de hardware, energia/refrigeração) mas deixa seis na sua coluna: é isso que "o IaaS exige que o cliente realize todas as tarefas necessárias de configuração e gerenciamento de segurança" significa na prática.
3. O RDS inverte a maioria para a AWS (seis de nove): ainda assim "Otimização da aplicação" permanece Cliente em todas as colunas. "A AWS gerencia o banco de dados" nunca significa "a AWS ajusta suas consultas."

3.3 O invariante: segurança DA versus NA Nuvem

O modelo de responsabilidade compartilhada é a moldura por baixo de tudo isso: a AWS é responsável pela segurança "DA" Nuvem, o cliente é responsável pela segurança "NA" Nuvem. Para serviços abstraídos como Amazon S3 e Amazon DynamoDB, "a AWS opera a camada de infraestrutura, o sistema operacional e as plataformas … Os clientes são responsáveis por gerenciar seus dados … e por usar as ferramentas do IAM." Para o AWS Lambda, a AWS gerencia "a infraestrutura subjacente e os serviços de base, o sistema operacional e a plataforma de aplicativos", enquanto você é dono "da segurança do seu código e do AWS IAM para o serviço Lambda e dentro da sua função."

3.4 A nuance de patch que o exame testa sorrateiramente

Nem todos os serviços gerenciados lhe dão o mesmo grau de controle:

⚠️ "A AWS gerencia isso" não é "a AWS assume tudo". Duas armadilhas vivem aqui. Primeiro, o RDS não é delegação total, otimização de aplicativo, suas consultas, seu schema e seus dados permanecem seus em toda coluna da matriz. Segundo, SaaS não é um produto da AWS: a AWS afirma que não oferece serviços de SaaS, ela oferece as ferramentas para construir SaaS de terceiros. Uma opção afirmando "WorkMail / QuickSight é a oferta de SaaS da AWS" não é suportada por nenhuma página da AWS nesta pesquisa, trate-a como errada.

---

4. Formas de acessar a AWS: Console, CLI, SDKs, APIs e IaC

4.1 As cinco portas (mais a que está fora do escopo)

• 📚 Você sabia? O Amazon S3 foi lançado em 14 de março de 2006 a $0,15 por GB-mês, com tamanho máximo de objeto de 5 GB e cerca de 1 PB de capacidade em aproximadamente 400 nós de armazenamento; a AWS agora diz que o preço está "levemente acima de 2 centavos por gigabyte", uma redução de cerca de 85%, e que "o código que você escreveu para o S3 em 2006 ainda funciona hoje, inalterado" (AWS News Blog, 2026-03-13; preços em outubro de 2026, verifique o estado atual antes do uso). O ponto examinável é o de operação: APIs estáveis são o que faz a automação repetível sobreviver, a chamada de CLI ou a solicitação de SDK que você colocou em script anos ainda funciona, e é exatamente por isso que a AWS pareia "processos repetíveis" com acesso programático.

4.2 Operações únicas versus processos repetíveis

Esta é a frase mais testável da Tarefa 3.1. A habilidade é "avaliar os requisitos para determinar se devem ser usadas operações únicas ou processos repetíveis", e a orientação de IaC da AWS fornece o raciocínio na outra metade:

Os próprios argumentos da AWS para a metade repetível, citados:

• a IaC torna "novos ambientes repetíveis, confiáveis e consistentes";
• "escreva seu código IaC uma vez e implante o mesmo código em centenas de ambientes em uma fração do tempo";
• "A deriva de configuração ocorre quando a configuração que provisionou seu ambiente não corresponde mais ao ambiente real": a criação manual é "sujeita a erros", e um template é um arquivo de texto, então você "simplesmente rastreie as diferenças nos seus templates para rastrear mudanças na sua infraestrutura."

A regra operacional: quando um ambiente derivou, reaplique o template. Editar manualmente o recurso vivo recria exatamente a deriva que você está tentando remover.

4.3 Exemplo E2: a aritmética das operações manuais

Suponha que 100 ambientes precisem cada um da mesma mudança, e que um humano leve 10 minutos por ambiente clicando pelo Console:

$$T_{\text{manual}} = 100 \times 10 \text{ min} = 1{,}000 \text{ min} \approx 16.7 \text{ horas}$$

16,7 horas de esforço humano não dirigido, com 100 chances de clicar na coisa errada, repetidas todo mês. A promessa de IaC da AWS é o contrafactual: "escreva seu código IaC uma vez e implante o mesmo código em centenas de ambientes em uma fração do tempo." O exame não pede que você prove isso: ele pede que você reconheça a forma: muitos ambientes + uma mudança padrão ⇒ IaC.

4.4 Exemplo E3: um template, quatro ambientes, aritmética da deriva

O padrão repetível canônico da documentação do CloudFormation da AWS é a mesma stack de 12 recursos implantada em desenvolvimento, staging, produção e uma segunda Região da AWS:

As conclusões examináveis: um template é reutilizado, versionado e comparado por diff; os recursos de uma stack são criados e configurados para você; e excluir a stack exclui os recursos que ela criou: razão pela qual a IaC é a resposta mais limpa para "limpar este ambiente".

4.5 O trio de IaC: CloudFormation, CDK e o terceiro nome na sala

A orientação prescritiva da AWS compara cinco ferramentas de IaC, CloudFormation, SAM, CDK, Terraform e Pulumi, e entrega a regra de seleção que você precisa: "Se você gerencia sua infraestrutura inteiramente na AWS, então o AWS CloudFormation e o AWS Cloud Development Kit (AWS CDK) são boas opções", enquanto "O Terraform pode ser uma boa escolha porque é agnóstico de plataforma."

• 📚 Você sabia? Os templates do CloudFormation são arquivos de texto simples, razão pela qual a AWS diz que você pode "simplesmente rastrear as diferenças nos seus templates para rastrear mudanças na sua infraestrutura." Essa propriedade é a mesma que torna a deriva de configuração detectável: compare o template com a stack viva, encontre as edições manuais, reaplique. Infraestrutura que você não consegue comparar por diff é infraestrutura que você não consegue auditar.

---

5. Conectividade: as quatro portas para dentro e para fora de uma VPC

5.1 A visão geral (apenas serviços no escopo)

5.2 Exemplo E4: dois túneis, quatro números

O AWS Site-to-Site VPN inclui dois túneis por conexão, e cada túnel tem um teto de largura de banda:

Duas observações que o exame recompensa. Primeiro, os dois túneis existem para alta disponibilidade, não primariamente para velocidade, a AWS diz que "Cada conexão VPN inclui dois túneis VPN que você pode usar simultaneamente para alta disponibilidade." Segundo, a largura de banda é um teto por túnel, então um enunciado que diz "uma conexão Site-to-Site VPN entrega 1,25 Gbps no total" está errado por um fator de dois. Todos os valores em outubro de 2026, verifique o estado atual antes do uso.

5.3 Exemplo E5: quanto um SLA de resiliência custa em minutos

O Direct Connect publica dois designs de resiliência. Converta as porcentagens em orçamentos de downtime ao longo de um ano de 365 dias ($8{,}760$ horas):

$$8{,}760 \times (1 - 0.999) = 8.76 \text{ horas por ano}$$ $$8{,}760 \times (1 - 0.9999) = 0.876 \text{ horas} \approx 52.6 \text{ minutos por ano}$$

O exame não pede esta aritmética: ele pede que você case o requisito com o design: "thruput privada estável com a disponibilidade publicada mais apertada" ⇒ Direct Connect com Máxima Resiliência; "precisamos de um link privado esta tarde" ⇒ Site-to-Site VPN. Valores de SLA em outubro de 2026.

5.4 Exemplo E6: escolhendo a porta do Direct Connect

Uma filial precisa de 400 Mbps; o data center central precisa de 100 Gbps:

Regra prática da página de opções de conexão: conexões hospedadas escalam de 50 Mbps a 25 Gbps (entregues por meio de parceiros do AWS Direct Connect), enquanto conexões dedicadas são de 1, 10, 100 ou 400 Gbps. Um enunciado citando 50 Mbps é um sinal de porta hospedada; um enunciado citando 100 Gbps é um sinal de porta dedicada. Valores em outubro de 2026: verifique o estado atual antes do uso.

5.5 PrivateLink e endpoints de gateway, com precisão

• 📚 Você sabia? Os endpoints de VPC vêm em duas famílias e o exame testa a exceção: endpoints de gateway (Amazon S3, Amazon DynamoDB) não usam o AWS PrivateLink, enquanto endpoints de interface são o tipo com tecnologia PrivateLink. Então a afirmação "todos os endpoints de VPC são com tecnologia PrivateLink" é falsa: um contra-exemplo, direto da documentação de VPC da AWS, é suficiente para derrubá-la.

---

6. Frontend, móveis e IoT: o que a tarefa 3.8 acrescenta

A Tarefa 3.1 é sobre provisionar e operar; o guia de exame testa frontend/móveis e IoT sob a Tarefa 3.8: "Identificar serviços de outras categorias de serviços da AWS no escopo." Ambas as habilidades são de nomeação: "Identificar os serviços que podem criar e implantar serviços de frontend e móveis" e "Identificar os serviços que gerenciam dispositivos IoT."

6.1 AWS Amplify: a resposta de frontend e móveis

A palavra "atômica" é a dica: como um novo deploy substitui o antigo como uma unidade, um release falhado não deixa um site meio atualizado, razão pela qual a AWS diz que janelas de manutenção desaparecem. Amplify é, portanto, também uma história de operação, releases repetíveis acionados por Git em vez de uploads manuais.

6.2 AppSync: uma ressalva de nomenclatura

Amazon AppSync aparece em nenhuma das listas, no escopo ou fora do escopo, no guia de exame atual do CLF-C02. Trate-o como vocabulário de pano de fundo apenas: não é material examinável, então não o memorize como "a resposta de GraphQL deste exame" e não espere que ele seja creditado. O serviço de frontend/móveis creditado no guia é AWS Amplify.

6.3 AWS IoT Core: a resposta de IoT

⚠️ Duas armadilhas de IoT. Primeiro, IoT Device Defender e IoT Greengrass estão fora do escopo, uma questão descrevendo execução de Lambda no dispositivo ou monitoramento de comportamento de segurança está atraindo você para serviços que não estão na lista; a resposta no escopo é AWS IoT Core. Segundo, IoT Device Management e IoT Analytics aparecem em nenhuma das listas, então não são nem respostas nem exclusões documentadas, se você os vir, trate a questão como um teste de saber o que está listado.

---

7. Elastic Beanstalk, Lightsail e CloudFormation: três papéis distintos

7.1 AWS Elastic Beanstalk: implantação estilo PaaS do seu código

A armadilha tripartite em uma linha: $0 de cobrança de serviço ≠ $0 na fatura, porque as instâncias EC2, o balanceador de carga e o armazenamento que ele cria são faturados na sua conta; Beanstalk não é serverless, porque ele provisiona EC2 ou EKS; e Beanstalk não é IaC, porque você está lhe entregando código, não um template de infraestrutura reutilizável.

7.2 Amazon Lightsail, o ponto de entrada de preço previsível

7.3 Exemplo E7, o bundle do Lightsail, precificado de duas formas

Aritmética do bundle:

Hora versus teto mensal. O Lightsail cobra por hora mas limita a cobrança ao preço mensal. Um mês cheio tem $750$ horas:

$$0.0067 \times 750 = 5.025 \text{ USD} \longrightarrow \text{limitado a } 5.00 \text{ USD}$$

Um mês parcial de $200$ horas: $0.0067 \times 200 \approx$ $1,34$. Então o preço mensal é um teto, não um piso: você paga pelo que roda até o limite. Todos os valores em outubro de 2026; tamanhos, faixas e preços mudam, então verifique o estado atual antes do uso.

7.4 Exemplo E8: Elastic Beanstalk custa $0 para executar como serviço

O Elastic Beanstalk cobra $0 por si mesmo. A fatura vem do que ele cria. Para ilustração (valores didáticos, não preços de lista da AWS: verifique o estado atual antes do uso):

A frase examinável: o Elastic Beanstalk remove o trabalho operacional, não o custo dos recursos.

7.5 A decisão dos três em um

• 📚 Você sabia? A versão de aplicação do Elastic Beanstalk é armazenada como "um objeto do Amazon Simple Storage Service (Amazon S3) que contém o código implantável", então "onde o Beanstalk guarda meu código?" tem resposta de uma palavra: S3. Isso também explica o versionamento estilo blue/green: você promove um objeto S3 diferente como versão atual, e a configuração do ambiente continua descritível como dados em vez de cliques.

---

Casos Reais

A AWS publica como essas escolhas aparecem em produção. Todo valor abaixo é afirmação do cliente ou da AWS, não auditado, com a fonte nomeada para que você possa conferir, o ponto examinável é o padrão (qual modelo de implantação, qual método de acesso, qual hábito de operação), não o número de marketing.

Caso A, Gourmeat: Lightsail como pequeno ponto de entrada previsível

Lição de exame: esta é a resposta Lightsail em forma humana, o valor alegado é operacional (horas de relatório manual removidas, uma fatura mensal previsível), não um benchmark bruto de computação. A questão de exame construída a partir deste padrão pergunta "equipe pequena, poucas instâncias, quer um preço mensal previsível", e Lightsail é a opção para alcançar, com Elastic Beanstalk como quase-resposta (também de baixa operação, mas precificado por recurso subjacente em vez de empacotado).

Caso B, athenahealth: operações repetíveis em 120 contas

Lição de exame: esta é a linha de "processos repetíveis" da Tarefa 3.1 com números anexados. Regras como código no CloudFormation é o mecanismo, AWS RAM é o método de distribuição, e Direct Connect é a porta de conectividade. Oito pessoas não poderiam configurar à mão centenas de VPCs em 120 contas em poucos dias: a aritmética só fecha quando a mudança é escrita uma vez e aplicada muitas vezes, que é exatamente o argumento de IaC da Seção 4.

Caso C, Capital One: ambientes de desenvolvimento de meses para minutos

Lição de exame: "de 3 meses para minutos" é a regra de uma vez versus repetível com um relógio anexado. Um prazo de três meses é o que um ambiente montado à mão, uma única vez custa quando cada pedido é sob medida; "minutos" é o que o mesmo ambiente custa quando a construção é um processo repetível que você reexecuta sob demanda. A leitura do modelo de implantação é igualmente limpa: um parque com zero de restinho on-premises é a ilustração de nuvem pública em escala empresarial: híbrido exigiria os data centers continuando ali, e multi-nuvem exigiria um segundo provedor público. E a aritmética por baixo é a da Seção 4: 90 dias de prazo removidos por ambiente se acumulam em uma organização de engenharia de 11.000 pessoas.

• 📚 Você sabia? O estudo de caso da Capital One afirma que o banco "saiu de oito data centers on-premises" e "construiu 80% das quase 2.000 aplicações que agora roda na nuvem do zero" (estudo de caso da AWS, acesso em outubro de 2026). O indicador do modelo de implantação é a expressão "all in": nada fica rodando on-premises, então o modelo de implantação é nuvem pública, não híbrido: um setor regulado escolhendo nuvem pública não transforma a resposta em "privada" ou "híbrida" no dia do exame.

Caso D, Bangkok Flight Services: uma migração repetível com operações multi-AZ

Lição de exame: dois padrões se encontram aqui. A migração em si é um processo repetível, um único método de rehost, aplicado em todo o parque, terminado em sete meses sem rollback, o oposto de uma série de eventos heroicos de uma única vez. As operações depois dela também são repetíveis: CloudWatch e CloudTrail fornecem a observação, e a Zona de Disponibilidade é a unidade de isolamento de falhas dentro da qual o design de recuperação opera (uma AZ protege contra falha de nível de data center dentro de uma Região; uma segunda Região é o que protege contra falha de nível de Região). Ressalva de escopo vale memorizar: o AWS Application Migration Service aparece neste estudo de caso, mas um estudo de caso nunca torna um serviço examinável, apenas a lista no escopo do guia de exame atual faz isso. Confira a lista, não a história.

O que os dois casos iniciais compartilham

O que os casos C e D acrescentam

⚠️ Como ler os números de estudos de caso no dia do exame: toda porcentagem aqui é alegação do cliente, não auditada, e "até" é um teto, nunca uma média. Atribua a fonte e a data: "estudo de caso da athenahealth, acesso em outubro de 2026", não "a AWS prova". Um caso nunca licencia uma resposta fora do escopo: pede-se para selecionar o padrão (Lightsail para um bundle pequeno e previsível; IaC para muitas contas), nunca reproduzir o número de marketing. Os valores do Gourmeat vêm de um estudo de caso de outubro de 2020 e são relatados como a AWS os publicou.

---

Perguntas de Prática (Practice Questions)