APRENDER. PRATICAR. EVOLUIR.Desenhar o âmbito antes do rollout
Uma equipa fictícia gere conectividade e logging em contas de desenvolvimento e produção. O pedido diz todas as contas, mas o desenho só contém o nome de uma OU. Antes de executar, transforma essa frase num inventário de contas, Regiões, recursos esperados e exceções aprovadas. StackSets reúne stacks baseadas num template comum, com parâmetros que podem variar. Identifica a Região onde o StackSet é administrado e as Regiões alvo; não são a mesma decisão. O modelo service-managed integra Organizations e cria roles necessárias, enquanto self-managed exige relações de confiança próprias. A escolha afeta onboarding, autoridade e cobertura. Uma operação aceite na conta central não prova implantação nos destinos.
Preparar a entrada e saída de contas
No modelo service-managed, a conta de gestão não recebe stacks por esse mecanismo. O plano de cobertura deve tratar esse requisito separadamente. Com automatic deployments, a entrada de uma conta pode criar recursos usando defaults do StackSet, sem herdar overrides das contas antigas. Os filtros usados numa operação inicial também não garantem exclusão de contas futuras na implantação automática. No caso desta aula, uma política interna exige retenção de 90 dias, mas o default mantém 30. O onboarding precisa de corrigir essa diferença antes da entrada. Na saída da OU, reter stacks preserva recursos fora do StackSet; atribui responsável, custo, manutenção e futura desativação em vez de declarar que desapareceram.
Separar padrão, exceção e drift
Guarda o motivo e prazo das exceções de parâmetros. Atualizar um default não elimina automaticamente um override já aplicado. Drift responde a outra pergunta: os recursos diferem do estado esperado na stack? Alterar uma stack individual pelo próprio CloudFormation pode mudar o seu template sem produzir drift dos recursos, embora a stack deixe de representar o padrão central pretendido. Por isso, compara também templates e parâmetros efetivos quando essa consistência faz parte do requisito. Um DETECT_DRIFT bem-sucedido pode encontrar discrepâncias; o sucesso da observação não é reparação. A reconciliação deve decidir se corrige o recurso ou atualiza a intenção aprovada, preservando evidência e dependências.
Planear exposição por conta e Região
Concorrência e tolerância descrevem comportamento de execução, não a quantidade de impacto que o negócio aceita sem análise. O modo strict reduz concorrência em função das falhas; soft mantém a janela pretendida e pode terminar com mais falhas devido ao trabalho já lançado. O exercício de cálculo usa a regra de planeamento documentada, não um comando pronto para submeter à API. Decide também se as Regiões devem avançar sequencialmente ou em paralelo. RegionOrder não cria um gate humano: se a segunda Região exige aprovação após observar a primeira, divide a mudança em operações controladas. As preferências de uma operação manual não se aplicam automaticamente ao onboarding AutoDeployment.
Conter e recuperar o estado parcial
Aceitar um pedido de stop não significa que todas as contas pararam ou regressaram à configuração anterior. StopStackSetOperation cancela implantações não iniciadas e espera pelas que já decorrem. Conserva o ID da operação e acompanha cada resultado até poder separar concluído, falhado e não iniciado. Com ManagedExecution, pedidos podem ficar em fila, incluindo pedidos aparentemente não conflitantes quando já há trabalho ativo. Não os dupliques por falta de resultado imediato. O sponsor precisa de um relato factual: que destinos receberam a alteração, quais ainda mudam, quais faltam e quem decide a recuperação. Enviar a alteração inversa indiscriminadamente pode sobrepor operações em estados diferentes.
Exercício: fechar a cobertura por destino
O modelo local cruza um conjunto esperado de pares conta/Região com resultados sintéticos e a revisão pretendida. Identifica destinos ausentes, falhas, revisões erradas e resultados que não deveriam estar no âmbito. Não chama AWS, não interpreta todos os estados CloudFormation e não resolve autorização. Executa os exemplos, acrescenta uma conta nova e remove uma Região do relatório. Explica como uma operação agregada SUCCEEDED pode deixar o objetivo de cobertura por cumprir quando há tolerância a falhas. No fecho da mudança, apresenta a matriz, as exceções e a ação seguinte por linha. Guarda a evidência de forma que outra pessoa consiga reconstruir a decisão sem ter acompanhado a execução.
# Original local inventory review, not a CloudFormation state machine.
def review_rollout(expected, observed, revision):
gaps = []
for target in sorted(expected):
row = observed.get(target)
if row is None:
gaps.append((target, "missing result"))
elif row["status"] != "SUCCEEDED":
gaps.append((target, "not completed successfully"))
elif row["revision"] != revision:
gaps.append((target, "wrong revision"))
return {"gaps": gaps, "unexpected": sorted(set(observed) - expected)}
expected = {("account-a", "eu-west-1"), ("account-b", "eu-west-1")}
good = {k: {"status": "SUCCEEDED", "revision": "network-7"} for k in expected}
assert review_rollout(expected, good, "network-7") == {"gaps": [], "unexpected": []}
assert len(review_rollout(expected, {}, "network-7")["gaps"]) == 2
bad = {**good, ("account-b", "eu-west-1"): {"status": "RUNNING", "revision": "network-7"}}
assert review_rollout(expected, bad, "network-7")["gaps"][0][1] == "not completed successfully"
assert len(review_rollout(expected, good, "network-8")["gaps"]) == 2
extra = {**good, ("account-c", "eu-west-1"): {"status": "SUCCEEDED", "revision": "network-7"}}
assert review_rollout(expected, extra, "network-7")["unexpected"] == [("account-c", "eu-west-1")]
Uma conta nova recebe 30 dias de retenção quando a política exige 90; sucesso técnico de onboarding não demonstra conformidade do valor.
Armadilhas comuns
Herdar overrides imaginários; esquecer a conta de gestão; tratar drift como comparação universal; assumir rollback no stop; usar SUCCEEDED como prova de cobertura.
Tópicos relacionados: Configuração, patching e janelas operacionais
O âmbito efetivo e o resultado por destino têm de corresponder à intenção aprovada, incluindo contas novas e exceções persistentes.
Referência: StackSets concepts · DOP-C02