APRENDER. PRATICAR. EVOLUIR.Identificar a operação antes da política
Uma mudança de infraestrutura com dados exige saber se vai alterar o mesmo recurso, substituí-lo ou removê-lo da gestão. O identificador lógico no template pode continuar igual enquanto a instância física muda. No caso fictício, uma base de reporting é substituída durante uma release. DeletionPolicy: Retain, por si só, não define o tratamento da instância antiga nesse caminho; UpdateReplacePolicy é a política relevante. Revê também referências, migração de dados e continuidade do serviço. Um recurso criado com sucesso não demonstra que contém o estado necessário. A revisão da mudança deve descrever a sequência, a evidência de preservação e os critérios para aceitar ou recuperar cada etapa.
Dar destino aos recursos preservados
Reter evita uma eliminação naquele caminho, mas não transforma a cópia antiga numa base automaticamente gerida ou gratuita. O recurso antigo retido após substituição sai do âmbito da stack; mantém necessidades de acesso, proteção, custo e eliminação futura. Snapshot só é uma opção de UpdateReplacePolicy quando o tipo a suporta; a referência avisa que, sem suporte, recai em Delete. RetainExceptOnCreate distingue rollback da operação que criou o recurso de eliminações posteriores. Define a opção pela necessidade, não pelo nome tranquilizador. No handover, inclui identificadores físicos, responsáveis, prazo de revisão e a evidência necessária para deixar de conservar recursos ou snapshots.
Combinar proteções com âmbitos distintos
Termination protection protege tentativas de apagar a stack; não é uma proibição universal de updates destrutivos. Uma atualização da principal pode remover uma nested stack. A stack policy controla ações de update CloudFormation sobre recursos, sem substituir o controlo IAM de chamadas diretas ao serviço. Se há Allow e Deny sobrepostos, a negação explícita prevalece. A orientação atual alerta ainda que uma exclusão por NotResource com Allow não protege de forma fiável, devido à avaliação de ID lógico e tipo; usa proteção explícita e testa-a. O objetivo da revisão é conseguir dizer qual operação fica impedida, em que caminho, e quem pode alterar a proteção.
Recuperar controlo sem esconder divergência
UPDATE_ROLLBACK_FAILED não é um estado onde repetir indiscriminadamente um update normal resolva o problema. Lê os eventos, identifica a causa e prepara ContinueUpdateRollback quando as condições permitirem. Ignorar recursos elegíveis com ResourcesToSkip pode desbloquear a recuperação, mas deixa obrigação de reconciliar o que ficou diferente do template. Usa o mínimo necessário e regista a exceção. A disponibilidade da aplicação não prova que a próxima atualização da stack será segura. Depois de importar recursos existentes, verifica drift no âmbito suportado e reconcilia intenção e realidade. Em ambos os casos, separa estado administrativo recuperado de configuração efetivamente compreendida e validada.
Tratar dependências e protocolos
Exports usados por Fn::ImportValue criam dependências que restringem alteração do valor ou eliminação da stack exportadora. Planeia a migração dos consumidores antes de retirar essa origem. Uma referência dinâmica a Secrets Manager também tem ciclo de vida: alterar apenas o segredo não faz CloudFormation voltar a obtê-lo automaticamente; valida a estratégia de rotação e o serviço consumidor. Nos custom resources, o PhysicalResourceId devolvido em Update distingue atualização de substituição. Gerar um ID aleatório pode provocar Delete sobre o objeto anterior. O handler precisa ainda de responder ao ResponseURL; terminar a função sem erro não comunica, por si, sucesso ao orquestrador. Reconcilia efeitos antes de repetir pedidos cujo resultado ficou incerto.
Exercício de handover e decommission
O modelo local revê um recurso antigo retido sem executar eliminações. Devolve razões concretas quando faltam proprietário, reconciliação, aprovação, ausência de consumidores ou libertação das obrigações de retenção. Quatro casos verificam bloqueios isolados, bloqueios simultâneos e elegibilidade para uma mudança planeada. O modelo confia nos valores fornecidos: True não é prova de autorização real nem de verificação de todas as dependências. No exercício de equipa, associa cada valor à evidência, ao responsável e à data da verificação. O PM reúne APS, aplicação e FinOps para aceitar a coexistência necessária e corrigir a previsão. O resumo final deve permitir que outro turno saiba o que pode alterar, o que deve preservar e qual evidência falta.
def retirement_review(resource):
checks = {
"missing-owner": bool(resource.get("owner")),
"reconciliation-pending": resource.get("reconciled") is True,
"approval-pending": resource.get("approved") is True,
"active-consumers": resource.get("consumers") == 0,
"retention-pending": resource.get("retention_released") is True,
}
reasons = [name for name, passed in checks.items() if not passed]
return {"eligible_for_planned_change": not reasons, "blocking_reasons": reasons}
ready = dict(owner="APS", reconciled=True, approved=True,
consumers=0, retention_released=True)
cases = [
({**ready, "reconciled": False}, ["reconciliation-pending"]),
({**ready, "owner": "", "consumers": 2}, ["missing-owner", "active-consumers"]),
({**ready, "approved": False, "retention_released": False},
["approval-pending", "retention-pending"]),
(ready, []),
]
for resource, expected in cases:
result = retirement_review(resource)
assert result["blocking_reasons"] == expected
assert result["eligible_for_planned_change"] == (not expected)
# Original local review model. No deletion, AWS calls, live inventory or policy discovery.
# It trusts supplied evidence: a True value is not proof of real authorization or retention clearance.
Caso fictício: a stack recupera após skip, mas um recurso diverge do template; a passagem para RUN mantém essa exceção com owner e correção prevista.
Armadilhas comuns
Tratar Retain como backup ou custo zero; usar termination protection para qualquer update; esquecer recursos ignorados; confundir sucesso da função com resposta do protocolo.
Tópicos relacionados: Concorrência, gates e recuperação de pipelines
Uma mudança só fica operacionalmente fechada quando estado, evidência, responsabilidade e destino dos recursos antigos estão reconciliados.
Referência: CloudFormation DeletionPolicy · DOP-C02