No SAP-C02, estrategias de implantacao e continuidade de negocios abrangem dois dominios: D2 (Projetar novas solucoes) e D3 (Melhoria continua de solucoes existentes). O exame nao testa apenas se voce conhece os nomes dos servicos. Ele testa sua capacidade de julgar qual abordagem de implantacao escolher em uma situacao especifica. Este post aborda o gerenciamento de mudancas com CloudFormation, pipelines CI/CD, implantacoes Blue/Green e padroes de recuperacao de desastres usando cenarios reais do exame.
Gerenciamento de mudancas com CloudFormation — Change Sets e Stack Policy
O momento mais perigoso ao gerenciar infraestrutura de producao com CloudFormation e a atualizacao de um stack. Mudancas que exigem deletar e recriar um recurso — chamadas mudancas de Substituicao — podem causar perda de dados. Exemplos incluem modificar o esquema de chaves do DynamoDB, renomear um bucket S3, ou mudar uma instancia RDS para Multi-AZ em certas configuracoes.
Change Sets resolvem esse problema. Antes de tocar o stack, voce cria um plano de mudancas que mostra exatamente quais recursos serao Adicionados, Modificados, Removidos ou Substituidos. Itens marcados como Replacement: True serao deletados e recriados, portanto revisar e aprovar esses itens antes de prosseguir e essencial.
Stack Policy e um documento JSON que bloqueia automaticamente operacoes de Replace ou Delete em recursos especificos. Se Change Sets sao a "previa", Stack Policy e a "barreira de seguranca". Em ambientes regulados como PCI DSS ou SOX, o historico de Change Sets tambem serve como trilha de auditoria de aprovacao de mudancas.
Drift Detection e frequentemente confundida com essas ferramentas. Drift Detection encontra mudancas feitas fora do CloudFormation — diretamente pelo console ou CLI — depois que uma implantacao ja ocorreu. Seu proposito e diferente de prevenir substituicoes antes de uma implantacao. Conheca a distincao para o exame.
| Funcionalidade | Proposito | Momento | |----------------|-----------|---------| | Change Sets | Previa de mudancas (identificar Substituicoes) | Antes da implantacao | | Stack Policy | Bloquear automaticamente substituicoes/delecoes em recursos especificos | Durante a implantacao | | Drift Detection | Detectar mudancas manuais feitas fora do CloudFormation | Apos a implantacao |
Pipelines CI/CD — CodePipeline, CodeBuild, ManualApproval
No modelo CI/CD nativo da AWS, CodePipeline orquestra o pipeline completo, CodeBuild lida com builds e testes, e CodeDeploy executa a implantacao real.
O pipeline de implantacao segura integrado ao CloudFormation segue este fluxo: Deteccao de fonte (CodeCommit ou GitHub) → Criar Change Set → Estagio de ManualApproval onde um engenheiro revisa o Change Set → Aprovar → ExecuteChangeSet. Esse padrao implementa Segregacao de Funcoes para gerenciamento de mudancas em ambientes PCI DSS.
A integracao com Jenkins e testada com frequencia. Organizacoes que migram para AWS nem sempre querem substituir o Jenkins completamente. O CodePipeline permite designar Jenkins como provedor no estagio de build, mantendo o investimento existente em Jenkins enquanto adiciona a orquestracao do pipeline AWS. CodeBuild e a escolha quando voce quer substituir Jenkins. A combinacao CodePipeline mais Jenkins e a escolha quando voce quer manter Jenkins.
Para CI/CD de containers, o escaneamento de imagens ECR importa. O Escaneamento Basico usa um banco de dados CVE. O Escaneamento Aprimorado usa Amazon Inspector para analise mais profunda de vulnerabilidades. As opcoes de implantacao do ECS sao Rolling Update (substituicao sequencial de instancias) e Blue/Green (baseado em CodeDeploy, zero downtime). Quando o requisito e zero downtime, escolha Blue/Green.
Implantacao progressiva do Lambda — Alias, Canary, Linear
Para atualizar uma funcao Lambda com seguranca, voce primeiro precisa publicar uma Versao e criar um Alias, em vez de invocar $LATEST diretamente. A integracao com CodeDeploy fornece tres estrategias de implantacao.
Canary envia uma pequena porcentagem do trafego (por exemplo, 10%) para a nova versao primeiro. Apos a validacao, muda os 90% restantes de uma vez. Linear aumenta o trafego para a nova versao em uma porcentagem fixa a cada N minutos. AllAtOnce muda tudo imediatamente e e usado para mudancas de baixo risco onde nenhum rollback e esperado.
Conectar alarmes do CloudWatch ao CodeDeploy habilita rollback automatico para a versao anterior se a taxa de erros aumentar. Com SAM, voce declara essa configuracao usando a propriedade DeploymentPreference.
| Estrategia | Comportamento | Rollback automatico | |------------|---------------|---------------------| | Canary | X% primeiro, depois 100% apos validacao | Alarme CloudWatch | | Linear | X% a mais a cada N minutos | Alarme CloudWatch | | AllAtOnce | 100% imediatamente | Apenas manual |
!Tipos de implantação progressiva do Lambda
Implantacao Blue/Green — Zero downtime e rollback instantaneo
O principio central da implantacao Blue/Green e manter dois ambientes em paralelo e alternar o trafego entre eles para trocar versoes. Rollback significa redirecionar o trafego de volta para Blue, o que e concluido em menos de cinco minutos. Implantacoes Rolling ou in-place exigem reimplantacao para rollback, o que demora tanto quanto a implantacao original.
Cada plataforma implementa Blue/Green de forma diferente. Para EC2 com Auto Scaling, voce executa um Blue ASG e um Green ASG em paralelo, depois alterna o grupo de destino do ALB. Para ECS, o CodeDeploy executa tarefas Blue (versao antiga) e Green (versao nova) em paralelo usando listeners duplos do ALB — trafego de teste na porta 8080 e trafego de producao na porta 443. Para Elastic Beanstalk, voce faz uma troca instantanea de CNAME entre os dois ambientes.
O roteamento ponderado do Route 53 oferece controle mais fino sobre a mudanca de trafego durante transicoes Blue/Green. Voce pode comecar com Blue 90% e Green 10%, depois mudar gradualmente a proporcao — uma abordagem Blue/Green no estilo canary.
Cenarios DR — RTO, RPO e compensacoes de custo
Os criterios de julgamento mais importantes em questoes de continuidade de negocios sao RTO (Objetivo de Tempo de Recuperacao) e RPO (Objetivo de Ponto de Recuperacao). Custo e velocidade de recuperacao sao inversamente proporcionais. O exame SAP-C02 pede para encontrar a solucao de menor custo que atenda aos requisitos declarados.
Aurora Global Database alcanca RPO abaixo de um segundo atraves de replicacao em nivel de armazenamento, e RTO abaixo de um minuto atraves da promocao da regiao secundaria. E adequado para sistemas financeiros e de saude com requisitos rigorosos.
RDS Cross-Region Read Replica usa replicacao assincrona, entao o RPO e medido em segundos a minutos. Custa menos que Aurora Global Database mas tem um RPO mais flexivel. A promocao leva de cinco a dez minutos no momento do failover.
DynamoDB Global Tables fornece uma estrutura Active-Active multi-regiao onde leituras e escritas sao aceitas de qualquer regiao. Isso contrasta com Aurora Global Database, que e Active-Passive: apenas a regiao primaria aceita escritas. Quando o cenario exige NoSQL com capacidade de escrita multi-regiao, escolha DynamoDB Global Tables.
Pontos-chave do exame
"Replacement True em Change Sets significa" -- o recurso sera deletado e recriado (risco de perda de dados)
"Ferramentas para prevenir substituicoes antes da implantacao" -- Change Sets mais Stack Policy
"Detectar mudancas manuais feitas fora do CloudFormation apos implantacao" -- Drift Detection
"Enviar primeiro pequena porcentagem de trafego para nova Lambda, depois mudar o restante" -- implantacao Canary (CodeDeploy mais Alias)
"Aumentar trafego Lambda X% a cada N minutos" -- implantacao Linear
"Por que rollback Blue/Green conclui em 5 minutos" -- apenas redirecionamento de trafego necessario, sem reimplantacao
"NoSQL multi-regiao Active-Active com escritas" -- DynamoDB Global Tables
"RPO abaixo de 1 segundo e RTO abaixo de 1 minuto para BD relacional" -- Aurora Global Database
"Replicacao assincrona, promocao em 5-10 minutos, menor custo" -- RDS Cross-Region Read Replica
"Gerenciar patches de servidores on-premises pelo console AWS" -- Systems Manager Patch Manager mais Hybrid Activation