CI/CD enterprise multi-account com CDK Pipelines
- ⬜🔗 Híbrido: Direct Connect, Site-to-Site VPN, Storage Gateway(AWS Solutions Architect Professional (SAP-C03))
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Arquitetura cross-account padrão
Accounts envolvidas:
tools-account: CodePipeline + CodeBuild + ECR + artifacts
dev-account: stacks de dev (auto-deploy)
staging-account: stacks de staging (auto-deploy)
prod-account: stacks de prod (manual approval)
Bootstrap CDK:
Em cada conta-alvo, 'cdk bootstrap aws://ACCOUNT/REGION
--trust TOOLS_ACCOUNT --cloudformation-execution-policies ...'
cria IAM role que tools-account pode assumir pra deploy.
Pipeline (CDK):
1. Source: CodeCommit/GitHub via CodeStar Connection
2. Build: CodeBuild cdk synth → artifact cloud assembly
3. SelfMutate: pipeline atualiza a si mesmo
4. DevStage: deploy em dev-account (auto)
5. IntegrationTests: CodeBuild smoke tests
6. StagingStage: deploy em staging-account (auto)
7. ManualApproval: SNS notifica team, espera aprovação
8. ProdStage: deploy em prod-account
9. PostProdValidation: CodeBuild valida + alarmes- → publica artefato
- → cifra
- → AssumeRole
- → implanta
- → pausa
- → aprovado → AssumeRole
- → implanta
- → change set
- Gestão e governança
- Compute
- Armazenamento
- Segurança e identidade
- Fora da AWS
Três decisões que a questão testa: pipeline em conta separada, artefato cifrado com CMK que as contas destino podem usar, e deploy por AssumeRole em role de escopo mínimo.
- O pipeline vive fora das contas de carga. Numa conta de ferramentas dedicada. Assim produção não hospeda o que pode alterar produção, e o raio de ação de um comprometimento do CI fica limitado.
- Artefato compartilhado exige CMK compartilhada. O bucket de artefato é cifrado com KMS, e a key policy precisa permitir as contas destino — senão o deploy falha com "access denied" ao decifrar. É o erro nº 1 de pipeline cross-account.
- Cada conta destino expõe uma role. Com trust policy apontando exclusivamente para a conta de ferramentas, e permissão mínima para criar a stack daquela aplicação. Nunca credencial de longa duração.
- Aprovação manual entre ambientes. Dev implanta automático; produção espera aprovação. É o portão que separa entrega contínua de deploy contínuo — e a maioria das empresas reguladas precisa dele.
- Change set antes de aplicar em produção. O pipeline cria o change set, alguém revisa o que vai ser substituído, e só então executa. É onde se descobre que a mudança recriaria o banco — antes, não depois.
Onde isso entra no exame
Domain 3 parte de algo que já roda. Aqui: como levar pipeline para várias contas (papel cross-account no CodePipeline, artefato em bucket compartilhado com KMS), e como reduzir risco de release — canary com rollback automático disparado por alarme do CloudWatch, não por decisão manual.
CDK Pipelines mínimo
import { Stack, StackProps, Stage, StageProps } from 'aws-cdk-lib';
import { CodePipeline, CodePipelineSource, ShellStep, ManualApprovalStep } from 'aws-cdk-lib/pipelines';
class AppStage extends Stage {
constructor(scope: Construct, id: string, props: StageProps) {
super(scope, id, props);
new AppStack(this, 'AppStack', props);
}
}
export class PipelineStack extends Stack {
constructor(scope: Construct, id: string, props: StackProps) {
super(scope, id, props);
const pipeline = new CodePipeline(this, 'Pipeline', {
pipelineName: 'app-pipeline',
synth: new ShellStep('Synth', {
input: CodePipelineSource.connection('org/repo', 'main', {
connectionArn: 'arn:aws:codestar-connections:...',
}),
commands: ['npm ci', 'npm test', 'npx cdk synth'],
}),
crossAccountKeys: true,
});
pipeline.addStage(new AppStage(this, 'Dev', {
env: { account: '111111111111', region: 'us-east-1' },
}));
pipeline.addStage(new AppStage(this, 'Staging', {
env: { account: '222222222222', region: 'us-east-1' },
}));
pipeline.addStage(new AppStage(this, 'Prod', {
env: { account: '333333333333', region: 'us-east-1' },
}), {
pre: [new ManualApprovalStep('PromoteToProd')],
});
}
}Um pipeline cross-account falha ao implantar em produção com erro de acesso negado ao decifrar o artefato. Qual é a causa mais provável?
Artifact signing e rollback
Assinar artifacts com AWS Signer garante supply chain integrity — container images e Lambda packages assinados, verificados no deploy, rejeitados se tampered. Rollback estratégico: CodeDeploy automatic rollback em CloudWatch alarm, blue/green ECS com deployment circuit breaker, Lambda alias shifting reversível em minutos, RDS point-in-time recovery como safety net em migrations.
Checklist CI/CD enterprise: CDK Pipelines com self-mutation, multi-account via trust bootstrap, integration tests como stage, manual approval pra prod, artifact signing, blue/green em ECS/Lambda, rollback automático por alarm, audit trail em CloudTrail. Esse stack é alvo em 20-30% das questões de Continuous Improvement no SAP.
Perguntas frequentes
❓ Como implantar em várias contas com segurança?
❓ Onde colocar a aprovação manual?
❓ Como reverter uma implantação enterprise?
Fixando
Por que o pipeline deve viver numa conta de ferramentas separada das contas de carga?
Qual controle é obrigatório antes de aplicar uma mudança de infraestrutura em produção?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…