De Conta Única a Plataforma AWS Governada

Uma instituição do setor financeiro concentrava todo o seu ambiente AWS em uma única conta.

Aplicações de áreas diferentes, ambientes de produção e de teste, cargas críticas e experimentos — tudo dividia o mesmo espaço, os mesmos limites de serviço e a mesma rede. O que começou como simplicidade havia se tornado o principal fator de risco da operação.

O projeto reestruturou esse ambiente segundo os padrões do AWS Well-Architected Framework, quebrando a conta única em uma estrutura multi-conta governada, com segregação de rede, provisionamento por código e visão de custo granular.

Uma conta única concentra riscos que só aparecem quando já é tarde:

• Um erro de configuração em um ambiente de teste alcançava recursos de produção.
• Não havia isolamento de rede entre aplicações de áreas de negócio distintas.
• Limites de serviço da AWS eram compartilhados, de modo que o consumo de uma aplicação podia bloquear outra.
• Permissões cresciam por acúmulo, sem fronteira que as contivesse.
• A fatura chegava agregada, sem forma de atribuir custo a projeto, setor, BU ou time.
• Recursos provisionados manualmente ao longo dos anos não tinham dono nem registro.

Esse último ponto era o mais caro. Havia capacidade contratada que ninguém reivindicava, e sem inventário não era possível nem desligar com segurança, nem justificar a manutenção.

A reestruturação seguiu quatro frentes, ancoradas nos pilares do Well-Architected Framework:

• Estrutura de contas: desenhar a separação por ambiente, criticidade e área de negócio, com fronteiras de permissão entre elas.
• Segregação de rede: isolar as cargas de forma que a comunicação entre elas passasse a ser explícita e autorizada.
• Infraestrutura como código: tornar o provisionamento reproduzível e auditável, condição para operar muitas contas sem multiplicar esforço.
• Visibilidade de custo: classificar os recursos de modo que a fatura pudesse ser lida pela ótica do negócio.

A conta única deu lugar a uma organização multi-conta, com separação por ambiente e por área de negócio. Cada conta passou a ter seus próprios limites de serviço, suas próprias permissões e sua própria fronteira de falha.

A rede foi segregada na mesma lógica: cargas de áreas distintas deixaram de se alcançar por padrão, e a comunicação necessária passou a ser declarada explicitamente em vez de existir por omissão.

Sobre essa estrutura, o Terraform tornou-se a única via de provisionamento. Uma conta nova deixou de ser um trabalho manual e passou a ser a aplicação de um padrão já descrito em código — o que é o que torna a estrutura multi-conta sustentável em vez de custosa.

Os recursos passaram a ser classificados por projeto, setor, BU e time, o que transformou a fatura agregada em uma visão financeira legível pelo negócio e abriu caminho para a prática de FinOps.

O trabalho começou pelo inventário: mapear o que existia dentro da conta única, a que aplicação pertencia e quem respondia por aquilo.

Esse levantamento revelou a massa de recursos sem dono declarado, que passou a ser tratada em uma frente própria de revisão e realocação.

A estrutura de contas foi desenhada em seguida e povoada de forma incremental, começando pelas cargas de menor criticidade, para que o padrão fosse validado antes de alcançar produção.

O Terraform entrou desde o início, não ao final: cada conta criada já nasceu descrita em código, evitando que a nova estrutura repetisse o problema de provisionamento manual que motivou o projeto.

A classificação de custo foi aplicada junto da migração, de modo que cada recurso chegasse à nova estrutura já atribuído a projeto, setor, BU e time.

• AWS Well-Architected Framework
• Estrutura multi-conta AWS
• Terraform
• Segregação de rede por carga e área
• Cost Allocation Tags
• Classificação por projeto, setor, BU e time

A mudança de fundo foi substituir confiança implícita por fronteira explícita.

Antes, o isolamento entre cargas dependia de ninguém cometer um erro. Depois, passou a ser uma propriedade da estrutura: um ambiente não alcança outro porque a conta e a rede não permitem, e não porque houve cuidado.

A infraestrutura como código mudou quem podia agir. Provisionar deixou de ser um trabalho artesanal e passou a ser uma mudança revisável, o que tornou a estrutura multi-conta operável por um time do tamanho que já existia.

E a visibilidade de custo mudou a conversa entre Tecnologia e Financeiro. Com a fatura legível por projeto, setor, BU e time, cada área passou a enxergar o próprio consumo — base sobre a qual a prática de FinOps foi construída em seguida.

30%Economia em recursos não mapeados

• Conta única substituída por estrutura multi-conta segundo os padrões do AWS Well-Architected Framework, com fronteiras de ambiente, criticidade e área de negócio.

• Segregação de rede estabelecida, tornando explícita e autorizada a comunicação que antes existia por omissão.

• Provisionamento 100% por código em Terraform, condição para operar muitas contas sem multiplicar o esforço.

• 30% de economia na revisão e realocação de recursos que não tinham dono nem registro.

• Custo visível por projeto, setor, BU e time, substituindo a fatura agregada por uma leitura financeira do negócio.

• Base estabelecida para FinOps, com a classificação de custo já aplicada no momento da migração.