AWS Admin

O que Todo Dev Deve Saber sobre AWS Organizations: Multi-account Strategy e Control Tower Já leu

AWS Organizations: Fundamentos e Arquitetura Multi-conta AWS Organizations é um serviço que permite gerenciar múltiplas contas AWS de forma centralizada. Diferente de trabalhar com contas isoladas, uma estratégia multi-conta oferece segregação de ambientes, melhor controle de custos, conformidade regulatória e isolamento de segurança. Cada conta funciona como um silos independente, mas você as governa através de uma conta raiz (Management Account). A estrutura básica envolve a criação de uma organização, depois adicionar contas membro e organizá-las em Unidades Organizacionais (OUs). Você pode aplicar políticas em nível de organização que se propagam automaticamente para todas as contas filhas. Isso evita retrabalho e garante conformidade consistente. Estrutura Organizacional A hierarquia começa com a Raiz (Root), que contém tudo. Abaixo dela, você cria OUs (Organizational Units) para agrupar contas por função: desenvolvimento, produção, segurança, financeiro, etc. Cada OU pode ter políticas específicas aplicadas, criando uma governança em camadas. Criando uma Organização com AWS CLI Control Tower: Governança Automatizada AWS Control Tower é uma

AWS Organizations: Fundamentos e Arquitetura Multi-conta

AWS Organizations é um serviço que permite gerenciar múltiplas contas AWS de forma centralizada. Diferente de trabalhar com contas isoladas, uma estratégia multi-conta oferece segregação de ambientes, melhor controle de custos, conformidade regulatória e isolamento de segurança. Cada conta funciona como um silos independente, mas você as governa através de uma conta raiz (Management Account).

A estrutura básica envolve a criação de uma organização, depois adicionar contas membro e organizá-las em Unidades Organizacionais (OUs). Você pode aplicar políticas em nível de organização que se propagam automaticamente para todas as contas filhas. Isso evita retrabalho e garante conformidade consistente.

Estrutura Organizacional

A hierarquia começa com a Raiz (Root), que contém tudo. Abaixo dela, você cria OUs (Organizational Units) para agrupar contas por função: desenvolvimento, produção, segurança, financeiro, etc. Cada OU pode ter políticas específicas aplicadas, criando uma governança em camadas.

# Exemplo de estrutura de árvore
Root
├── OU: Produção
│   ├── Conta: Production-App-1
│   └── Conta: Production-App-2
├── OU: Desenvolvimento
│   ├── Conta: Dev-App-1
│   └── Conta: Dev-App-2
└── OU: Segurança
    └── Conta: Security-Audit

Criando uma Organização com AWS CLI

# Criar organização
aws organizations create-organization \
  --feature-set ALL

# Criar OU sob a raiz
aws organizations create-organizational-unit \
  --parent-id r-xxxx \
  --name "Producao"

# Criar conta
aws organizations create-account \
  --account-name "Production-App-1" \
  --email "prod-app-1@empresa.com"

# Mover conta para OU
aws organizations move-account \
  --account-id 123456789012 \
  --source-parent-id r-xxxx \
  --destination-parent-id ou-xxxx

Control Tower: Governança Automatizada

AWS Control Tower é uma solução construída sobre Organizations que automatiza a criação de contas seguras e conformes. Enquanto Organizations oferece a infraestrutura, Control Tower adiciona guardrails (políticas automáticas), blueprints de conta pré-configurada e um painel centralizado de governança.

Control Tower cria automaticamente duas OUs: Security (para auditoria) e Sandbox (para experimentação). Você também recebe uma conta de Logging centralizada e uma de Audit. Tudo isso é configurado automaticamente com detecção de desvios em tempo real.

Guardrails: Proteção Automática

Guardrails são políticas de prevenção ou detecção. Um guardrail preventivo (como SCP) impede ações não conformes. Um guardrail detectivo (como Config Rules) identifica recursos não conformes e alerta você. Cada guardrail tem um nível: Foundational (essencial), Strongly Recommended (recomendado) ou Elective (opcional).

# Exemplo: Script Python para verificar guardrails ativos
import boto3

ct = boto3.client('controltower')

# Listar guardrails habilitados
response = ct.list_enabled_controls()

for control in response['enabledControls']:
    print(f"Controle: {control['controlIdentifier']}")
    print(f"Status: {control['statusSummary']['status']}")

# Habilitar um guardrail específico
ct.enable_control(
    targetIdentifier='ou-prod-xxxx',
    controlIdentifier='arn:aws:controltower:us-east-1::control/...'
)

Exemplo Prático: Landing Zone

Quando você configura Control Tower pela primeira vez, ele cria uma Landing Zone — um ambiente base seguro com buckets S3 para logs, CloudTrail centralizado, Config Rules, e permissões de auditoria pré-configuradas.

# Verificar Landing Zone status via CLI
aws controltower get-landing-zone-status

# Resultado (exemplo)
# {
#   "landingZoneStatus": "ACTIVE",
#   "latestAvailableVersion": "3.3",
#   "version": "3.3"
# }

Estratégia Multi-conta na Prática

Uma boa estratégia multi-conta reduz risco, isola custos e facilita compliance. A segregação típica separa Produção (isolada, acesso restrito), Desenvolvimento (mais permissivo), Segurança (auditoria centralizada) e Infraestrutura Compartilhada (recursos comuns como VPN, DNS).

O acesso entre contas funciona via Cross-Account Roles. Uma aplicação em produção pode assumir uma role em outra conta para acessar um serviço específico. Isso é mais seguro que compartilhar credenciais de longa vida.

Cross-Account Access com IAM Roles

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "unique-external-id-123"
        }
      }
    }
  ]
}

A role acima, criada na conta 222222222222 (produção), permite que a conta 111111111111 (desenvolvimento) assuma seus privilégios. Você depois anexa uma política à role para definir o que ela pode fazer.

# Script para assumir role cross-account
import boto3

sts = boto3.client('sts')

response = sts.assume_role(
    RoleArn='arn:aws:iam::222222222222:role/CrossAccountRole',
    RoleSessionName='dev-session',
    ExternalId='unique-external-id-123'
)

# Agora use as credenciais temporárias
credentials = response['Credentials']
s3_client = boto3.client(
    's3',
    aws_access_key_id=credentials['AccessKeyId'],
    aws_secret_access_key=credentials['SecretAccessKey'],
    aws_session_token=credentials['SessionToken']
)

# Listar objetos no bucket de produção
s3_client.list_objects_v2(Bucket='prod-data-bucket')

Billing Consolidado

Organizations oferece Consolidated Billing, agregando custos de todas as contas sob uma fatura única. Você obtém volume discounts em todos os serviços, reduzindo custos operacionais.

# Listar contas e seus custos (via AWS Cost Explorer)
aws ce get-cost-and-usage \
  --time-period Start=2024-01-01,End=2024-01-31 \
  --granularity MONTHLY \
  --metrics BlendedCost \
  --group-by Type=DIMENSION,Key=LINKED_ACCOUNT

Conclusão

Multi-account strategy com AWS Organizations resolve três problemas críticos: governança centralizada (uma só verdade), isolamento de segurança (falha em uma conta não afeta outra) e otimização de custos (controle granular por departamento). Control Tower acelera isso oferecendo guardrails automáticos e um framework pronto.

O aprendizado principal: não trabalhe com contas isoladas em produção. Invista tempo inicial em organizar contas por ambiente e função, configure Control Tower para automatizar conformidade, e use cross-account roles para acesso seguro. Isso não é overhead — é fundação.

Referências


Artigos relacionados