Quando uma empresa vai iniciar sua jornada na AWS sem o apoio de uma consultoria ou com uma equipe madura, normalmente tudo começa em uma única conta. Os primeiros serviços são criados rapidamente, os times possuem acesso administrativo e a preocupação principal é colocar os serviços em produção.

Não foi diferente por aqui.

Quando identificamos a oportunidade de iniciar nossa jornada em ambiente cloud, mesmo com algum apoio, não identificamos a necessidade de termos um ambiente multi-account.

Porém, à medida que o ambiente vai crescendo, começamos a perceber novos desafios:

  • Como separar ambientes de produção e homologação?
  • Como controlar custos por área de negócio?
  • Como impedir que usuários criem recursos fora dos padrões corporativos?
  • Como garantir governança sem limitar a produtividade dos times?

Foi com a necessidade de resolver essas questões que me aprofundei nos estudos em AWS Organizations e ele se mostrou uma peça fundamental. Neste artigo veremos como estruturar múltiplas contas AWS desde o início, exemplos reais de Service Control Policies (SCPs) e as principais práticas de governança utilizadas em ambientes corporativos.

O que é AWS Organizations?

O AWS Organizations é um serviço que permite gerenciar diversas contas AWS de forma centralizada. Em vez de administrar cada conta individualmente, é possível agrupá-las em uma única organização e aplicar políticas de governança em larga escala.

Na prática, isso permite:

  • Centralização do faturamento
  • Delegação de acesso entre equipes
  • Controle de segurança
  • Aplicação de políticas corporativas
  • Isolamento de ambientes

A principal vantagem é que cada conta continua sendo uma fronteira de segurança independente, reduzindo o impacto de erros operacionais e problemas de configuração.

O erro mais comum: separar tudo apenas por VPC

Muitas empresas iniciam sua arquitetura criando apenas VPCs separadas para diferentes ambientes:

  • Produção
  • Homologação
  • Desenvolvimento

Embora funcione inicialmente, essa estratégia apresenta limitações pois todos os recursos continuam compartilhando:

  • Limites de serviço
  • Faturamento
  • IAM
  • Configurações globais

Além disso, um erro administrativo pode afetar todos os ambientes simultaneamente. Por isso, a recomendação da AWS é utilizar múltiplas contas como unidade primária de isolamento.

Estruturando uma organização AWS do zero

Uma estrutura simples e eficiente para pequenas e médias empresas pode seguir o modelo abaixo:

Root
│
├── Security OU
│   ├── Log Archive
│   └── Security Tooling
│
├── Network OU
│   └── Networking Hub
│
├── Shared Services OU
│   ├── Sandbox
│   └── Shared Services
│
├── Wokloads OU
│   ├── DEV
│   ├── HML
│   └── PRD
│
└── Management Account

Diagrama AWS Organizations

  • Security OU

Contém contas responsáveis por:

  • AWS Security Hub

  • AWS GuardDuty

  • AWS Config

  • AWS IAM Identity Center

  • Centralização de logs

  • Network OU

Responsável por serviços compartilhados:

  • Transit Gateway

  • Direct Connect

  • DNS corporativo

  • Ferramentas de backup

  • Ferramentas de monitoramento

  • Workloads OU

Hospeda os workloads (PRD, DEV e etc).

  • Shared Services OU

Contém ambientes de Sandbox e serviços compartilhados. Normalmente possui políticas mais flexíveis para permitir experimentação.

  • Management Account

Cada aplicação crítica pode possuir sua própria conta, facilitando:

  • Governança
  • Custos
  • Segurança
  • Auditoria

Controle de custos utilizando múltiplas contas

Um dos maiores benefícios do AWS Organizations é a visibilidade financeira. Sem múltiplas contas, identificar quem está consumindo recursos torna-se complexo, mas com uma estrutura organizada, é possível responder rapidamente perguntas como:

  • Quanto o ambiente de produção consumiu este mês?
  • Qual aplicação está gerando maior custo?
  • Qual equipe aumentou o consumo de armazenamento?

Além disso, o Consolidated Billing permite consolidar toda a cobrança da organização em uma única fatura. Isso simplifica bastante o gerenciamento financeiro.

Entendendo o papel das SCPs

Uma dúvida comum é acreditar que uma SCP concede permissões. Na verdade, ela faz exatamente o contrário. Uma Service Control Policy define o limite máximo do que pode ser executado dentro de uma conta, mesmo que um usuário tenha permissões administrativas, uma SCP pode impedir determinadas ações. Pense na SCP como uma camada de proteção corporativa.

Exemplo 1: Bloquear exclusão do CloudTrail

Uma prática comum é impedir que usuários desativem mecanismos de auditoria.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail",
        "cloudtrail:StopLogging"
      ],
      "Resource": "*"
    }
  ]
}

Esse controle reduz significativamente o risco de perda de rastreabilidade durante incidentes.

Exemplo 2: Restringir regiões autorizadas

Muitas organizações operam apenas em algumas regiões específicas. Uma SCP pode bloquear implantações fora dessas localidades.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideApprovedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "route53:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "sa-east-1",
            "us-east-1"
          ]
        }
      }
    }
  ]
}

Essa política ajuda a evitar recursos criados acidentalmente em regiões não aprovadas.

Exemplo 3: Impedir exclusão de backups

Uma das SCPs mais valiosas em ambientes corporativos.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "backup:DeleteBackupVault",
        "backup:DeleteRecoveryPoint"
      ],
      "Resource": "*"
    }
  ]
}

Esse tipo de proteção é extremamente útil em cenários de ransomware e recuperação de desastres.

Exemplo 4: Bloquear contas Sandbox de criar recursos caros

Muitas empresas criam contas Sandbox para experimentação. Sem controles, usuários podem provisionar instâncias muito grandes ou serviços de alto custo. Uma SCP pode limitar a criação de determinados recursos e reduzir desperdícios financeiros.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyExpensiveEC2Instances",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringNotEquals": {
          "ec2:InstanceType": [
            "t3.micro",
            "t3.small",
            "t3.medium",
            "t2.micro",
            "t2.small"
          ]
        }
      }
    },
    {
      "Sid": "DenyExpensiveRDSInstances",
      "Resource": "arn:aws:rds:*:*:db:*",
      "Effect": "Deny",
      "Action": "rds:CreateDBInstance",
      "Condition": {
        "StringNotEquals": {
          "rds:DatabaseClass": [
            "db.t3.micro",
            "db.t3.small",
            "db.t3.medium"
          ]
        }
      }
    },
    {
      "Sid": "DenyExpensiveServices",
      "Effect": "Deny",
      "Action": [
        "redshift:CreateCluster",
        "elasticmapreduce:RunJobFlow",
        "sagemaker:CreateTrainingJob",
        "sagemaker:CreateEndpoint"
      ],
      "Resource": "*"
    }
  ]
}

Governança além das SCPs

Embora as SCPs sejam importantes, elas representam apenas uma parte da estratégia de governança.

Uma arquitetura madura normalmente inclui:

Serviço Função
AWS Config Monitora conformidade de recursos
AWS Security Hub Centraliza alertas de segurança
AWS GuardDuty Detecta atividades suspeitas
IAM Identity Center Gerencia identidade
AWS Backup Centraliza backups

Boas práticas para ambientes corporativos

Após trabalhar com ambientes multi-account, algumas recomendações se destacam:

  • Não utilize a conta Management para hospedar workloads.
  • Mantenha uma conta exclusiva para logs e auditoria.
  • Utilize OUs para refletir políticas de negócio e não apenas departamentos.
  • Aplique SCPs inicialmente em modo controlado para evitar impactos inesperados.
  • Centralize identidade através do IAM Identity Center.
  • Implemente uma estratégia de tagging obrigatória desde o início.
  • Automatize a criação de contas utilizando o AWS Control Tower sempre que possível.
  • Revise regularmente contas não utilizadas e ambientes Sandbox.

Conclusão

O AWS Organizations é muito mais do que uma ferramenta de agrupamento de contas. Ele representa a base para uma estratégia escalável de segurança, governança e gestão financeira dentro da AWS.

Empresas que estruturam corretamente sua organização desde o início evitam problemas comuns relacionados a acesso, auditoria, custos e conformidade.

A combinação de múltiplas contas, Organizational Units bem definidas e SCPs cuidadosamente planejadas cria uma fundação sólida para o crescimento da plataforma em longo prazo.

Quanto mais cedo essa estrutura for implementada, menor será o esforço para manter o ambiente organizado e seguro à medida que novas aplicações e equipes forem surgindo.