trilha

AWS SAA-C03/10 - Observabilidade e Governança2 min

Infraestrutura como Código

Perguntas-guia

Responda com suas palavras antes de ler o resto da nota.

  • Que problema isso resolve?
  • Quando usar / quando NÃO usar?
  • Qual o principal trade-off (custo, latência, operação)?
  • Que sinal no enunciado aponta pra isso?
  • Com o que isso é confundido na prova?

Conceito

Ferramenta O que é
CloudFormation IaC declarativa nativa (YAML/JSON). Base de quase tudo
CDK Define infra em linguagem de programação (TS, Python, Java) → gera CloudFormation
SAM Extensão do CloudFormation para serverless (sintaxe enxuta pra Lambda/API GW)
Elastic Beanstalk PaaS: você sobe o código, ele cria e gerencia a infra
Service Catalog Catálogo de produtos aprovados que os times podem provisionar
Systems Manager (SSM) Operação da frota: patch, comando remoto, inventário, Session Manager
OpsWorks Chef/Puppet gerenciado (legado)
Proton Templates de infra para times de plataforma

CloudFormation — conceitos que caem

Conceito O que é
Stack Conjunto de recursos gerenciado como unidade
Change Set Preview do que vai mudar antes de aplicar
Drift detection Detecta alteração manual fora do template
StackSets Aplica a mesma stack em várias contas e regiões
Nested stacks Reutiliza componentes
Parameters / Mappings / Conditions Reuso do template entre ambientes
Outputs / Exports Compartilha valores entre stacks
DeletionPolicy: Retain Preserva o recurso (ex: banco) ao apagar a stack

Systems Manager — o que a prova cobra

  • Session Manager: shell na instância sem porta 22 aberta, sem bastion e sem chave SSH, com log no CloudTrail/S3. É resposta recorrente para "acessar EC2 privada com segurança".
  • Patch Manager: patch automatizado da frota
  • Run Command: comando em massa sem SSH
  • Parameter Store: config e segredo
  • Session Manager e SSM Agent funcionam também on-premises (hybrid activations)

Trade-offs

CloudFormation é declarativo, gratuito e verboso; o CDK troca verbosidade por lógica de programação, ao custo de uma camada de abstração a mais para depurar. Beanstalk entrega uma aplicação no ar em minutos e esconde a infra — ótimo pra começar, limitante quando o requisito é controle fino (aí a resposta vira ECS/EKS ou EC2 direto).

StackSets e Service Catalog resolvem o mesmo problema por ângulos diferentes: StackSets empurra infra padronizada; Service Catalog oferece produtos aprovados que o time provisiona sozinho.

Sinais de prova

  • "Provisionar infra de forma repetível e versionada" → CloudFormation
  • "Mesma stack em várias contas e regiões" → StackSets
  • "Ver o impacto antes de aplicar" → Change Set
  • "Não apagar o banco ao deletar a stack" → DeletionPolicy: Retain
  • "Detectar mudança manual na infra" → drift detection
  • "Subir uma app web rapidamente sem gerenciar infra" → Elastic Beanstalk
  • "Acessar EC2 privada sem abrir a porta 22" → SSM Session Manager
  • "Aplicar patch em centenas de instâncias" → SSM Patch Manager
  • "Times provisionando só recursos aprovados" → Service Catalog

Relacionado


Parte de 10 - MOC Observabilidade e Governança · Documentação AWS

Buscar

Busca por título, seção e texto das notas