← Back to list

Multi-account na AWS com CDK: Organizando a casa

O Desafio da Escala: Reflexões de 30 anos em TI

Luciano Jesus Lima · 2026-03-24 01:38 · 0 claps · 2.9 min read
#aws #aws-cdk #devops #serverless #telemedicina
Open on Medium ↗
Wiki topics: ☁️ · DevOps & Cloud

Multi-account na AWS com CDK: Organizando a casa

Crescer às vezes é doloroso… para TI.

Crescer às vezes é doloroso… para TI.

O Desafio da Escala: Reflexões de 30 anos em TI

Trabalhar com tecnologia desde 1996 me deu uma perspectiva privilegiada, mas também algumas cicatrizes. A principal lição? A infraestrutura não pode ser um gargalo para o negócio. Na Doutor ao Vivo, sabíamos que para escalar com a segurança que a telemedicina exige, precisávamos de uma fundação que fosse além de “subir instâncias na nuvem”.

Estávamos no cenário clássico de muitas startups: intervenções manuais, ambientes que divergiam entre si e aquele receio de que um hotfix de madrugada pudesse quebrar a produção. Era hora de destravar esses receios.

A Gênese: Onde Estávamos

Nosso ponto de partida era uma arquitetura centralizada com 7 anos de estrada. Funcional? Sim. Mas o modelo de conta única ou deploys manuais cobra seu preço em agilidade e segurança a longo prazo. O desafio era: como isolar Desenvolvimento (Dev), Sandbox (Homologação) e Produção (Prd), garantindo que o código testado fosse rigorosamente o mesmo que chega ao paciente na ponta final?

A Transformação: Engenharia Multi-Account com CDK Pipelines

Decidimos implementar uma arquitetura Multi-Account utilizando AWS CDK e CDK Pipelines. Criamos uma conta central de Operações (Ops) que orquestra o deploy para as demais via Cross-Account Roles.

Aqui não tem “mágica”, tem engenharia. Veja como estruturamos a orquestração:

// Exemplo da nossa Beta Pipeline (Release/Hotfix)
const pipeline = new pipelines.CodePipeline(this, 'BetaPipeline', {
  synth: new pipelines.ShellStep('Synth', {
    // Monitoramos branches de release/* e hotfix/*
    input: pipelines.CodePipelineSource.bitbucket('workspace/repo', 'release/v1'),
    commands: ['npm ci', 'npm run build', 'npx cdk synth']
  }),
});

// Deploy para Sandbox em conta isolada (sa-east-1)
pipeline.addStage(new SharedInfraStage(this, 'Sandbox', {
  env: { account: 'ACCOUNT_ID_HOM', region: 'sa-east-1' }
}));

// Deploy para Produção após aprovação manual
const prodStage = pipeline.addStage(new SharedInfraStage(this, 'Production', {
  env: { account: 'ACCOUNT_ID_PRD', region: 'sa-east-1' }
}), {
  pre: [ new pipelines.ManualApprovalStep('AprovarParaProducao') ]
});

A Infra é só o começo e a desculpa para começar.

A Infra é só o começo e a desculpa para começar.

O “Robô de Merge” e o fim do Housekeeping manual

Uma das dores que resolvi atacar foi a dessincronização de branches. Sabe quando o hotfix vai para a master, mas alguém esquece de atualizar a develop? Resolvemos isso com um script de Post-Deploy.

Assim que a aprovação manual acontece e o deploy em PRD termina, o CodeBuild assume o papel de “zelador” do repositório:

# Sincronização automática pós-deploy
git checkout master
git merge --no-ff $SOURCE_BRANCH -m "chore: promoção aprovada: $APPROVAL_COMMENT"
git push origin master

# Nivelando as bases: Stage e Develop
for branch in stage develop; do
  git checkout $branch
  git merge master
  git push origin $branch
done

# Limpeza: Deletando branches temporárias mergeadas
git branch -r --merged master | egrep -v '(^\*|master|develop|stage|v[0-9])' \
  | sed 's/origin\///' | xargs -I {br} git push origin --delete {br}

Além da limpeza técnica, esse processo gera uma trilha de auditoria imbatível: cada merge na master está vinculado a um comentário de aprovação humana no pipeline.

O Futuro: Agnosticidade e Microserviços

A base está pavimentada. Agora, o foco é a Hiper-Modularização. Estamos migrando nossos serviços para um modelo agnóstico.

Hoje, rodamos com o Serverless framework. Buscamos com o CDK uma liberdade com os serviços onde um deploy com CDK e AWS Lambda Web Adapter permite o NestJS em usa forma mais pura, sem criar dependencia direta com handler de Lambda. Se amanhã precisarmos rodar o mesmo serviço em Kubernetes ou no CloudRun, basta um Dockerfile com multi build e umdocker push. A infraestrutura serve ao software, e não o contrário.

Conclusão

Infraestrutura como Código (IaC) é, acima de tudo, sobre confiança. Hoje, posso dormir tranquilo sabendo que o pipeline é o guardião da nossa qualidade. Tenho muito orgulho desse primeiro passo; a telemedicina exige esse rigor, e nós estamos cada vez mais prontos.

A borboleta vai sair do casulo.

A borboleta vai sair do casulo.


메타데이터
post_id
ef42d42d7b1c
slug
multi-account-na-aws-com-cdk-organizando-a-casa-ef42d42d7b1c
url
https://medium.com/@solutionarchitectrocks/multi-account-na-aws-com-cdk-organizando-a-casa-ef42d42d7b1c
canonical_url
https://medium.com/@solutionarchitectrocks/multi-account-na-aws-com-cdk-organizando-a-casa-ef42d42d7b1c
author_url
https://medium.com/@solutionarchitectrocks
status
ok
fetched_at
2026-06-09 15:37:30