Boas práticas na AWS

Boas práticas na AWS: proteja credenciais, controle custos, organize contas e ative observabilidade desde o dia zero. Checklist prático para ação imediata.

Avatar de Danrley Pereira
Danrley Pereira
Boas práticas na AWS

Toda conta AWS começa limpa e, uns seis meses depois, vira um depósito de recurso esquecido, permissão ampla demais e fatura que ninguém entende. As boas práticas abaixo não são teoria de prova de certificação — são o que dói quando você ignora.

Imagem de abertura que traduz "conta AWS organizada vs. bagunçada" de forma limpa e editorial.
Imagem de abertura que traduz "conta AWS organizada vs. bagunçada" de forma limpa e editorial.

IAM: menos privilégio, mais roles

Chave de acesso vazada em repositório é, de longe, um dos incidentes mais comuns na AWS. E quase sempre a chave era de um usuário com AdministratorAccess. Então:

  • Zere credenciais estáticas de longa duração. EC2, ECS e Lambda assumem roles — não precisam de access key hardcoded.
  • Pessoas entram via SSO (IAM Identity Center), com credencial temporária. Nada de usuário IAM humano com senha eterna.
  • Least privilege de verdade é chato e vale a pena: comece pela permissão mínima e amplie quando a aplicação reclamar, não o contrário. O Access Analyzer ajuda a enxergar o que está exposto.

Se você ainda tem a chave raiz com uso ativo, pare de ler e vá desativar agora. Root é pra emergência, com MFA físico.

Uma conta só é dívida técnica: Organizations e multi-conta

Colocar dev, staging e produção na mesma conta é confortável no começo e caro depois — basta um terraform apply no diretório errado pra derrubar produção. Multi-conta resolve isso pela raiz:

  • Uma conta por ambiente (ou por time/produto), tudo sob o AWS Organizations.
  • SCPs (Service Control Policies) travam o que nem admin pode fazer — como abrir região que você não usa ou desligar o CloudTrail.
  • Billing consolidado: uma fatura, mas custo isolado por conta. Fica óbvio quem está gastando.

É mais setup no dia um, mas é a diferença entre um raio de explosão pequeno e um incidente que vaza pra todo mundo.

Custo não é surpresa de fim de mês

A fatura da AWS não deveria te assustar — se assusta, é porque ninguém está olhando. Três frentes resolvem a maioria dos casos:

  • Budgets com alerta por e-mail/Slack em thresholds (80%, 100%, previsão). Custo é métrica, trate como uma.
  • Right-sizing: aquele m5.2xlarge a 8% de CPU há três meses é dinheiro no lixo. Compute Optimizer aponta os óbvios.
  • Savings Plans / Reserved pra workload estável. On-demand em base previsível é o preço de balcão — dá pra cortar 30–60% commitando o que você já sabe que vai usar.

Bônus: apague o que não usa. Volume EBS órfão, snapshot de 2023, NAT Gateway de um ambiente morto — tudo isso pinga na fatura em silêncio.

Serviço gerenciado quase sempre ganha do EC2

Rodar seu próprio Postgres num EC2 significa que você agora é DBA, responsável por patch, backup, failover e a madrugada em que o disco encher. A AWS faz isso melhor e mais barato do que o custo do seu tempo:

  • Banco? RDS/Aurora em vez de Postgres na unha.
  • Fila, mensageria, cron? SQS, EventBridge, Lambda em vez de daemon num EC2 que você esquece de atualizar.
  • Container? ECS Fargate ou EKS antes de administrar node você mesmo.

EC2 não morreu — ele é a saída quando o gerenciado não cabe (licença específica, kernel custom, controle fino). O erro é usá-lo como padrão por hábito.

Tag ou não existe

Recurso sem tag é órfão: você não sabe de quem é, de qual projeto, nem se pode apagar. Sem tag, todo relatório de custo vira chute.

  • Padronize um punhado de chaves obrigatórias: env, owner, project, cost-center.
  • Force via Tag Policies e SCP — recurso sem tag não sobe.
  • Ative Cost Allocation Tags pra fatiar a fatura por time/projeto no Cost Explorer.

Tag é chato de implantar e impagável no dia em que alguém pergunta "por que a conta subiu 40%?".

Observabilidade: CloudWatch e CloudTrail ligados desde o dia zero

Depurar sem log é adivinhação. E na AWS os dois pilares vêm de fábrica — só ligar direito:

  • CloudTrail em todas as contas (via Organization trail), gravando em um bucket central e imutável. É seu "quem fez o quê e quando" — auditoria e pós-incidente vivem disso.
  • CloudWatch pra métrica, log e alarme. Alarme que dispara antes do usuário reclamar, não depois.
  • Centralize log e trace numa conta de observabilidade separada, sem acesso de escrita das contas de aplicação. Log que o atacante pode apagar não é evidência.

Se você só tem esses dois ligados e mais nada, já está à frente da maioria.

Boas práticas na AWS não são burocracia de compliance — são o que separa a conta que você controla da conta que controla você (e o seu cartão de crédito). Escolha uma seção acima e arrume ainda esta semana. A próxima fatura agradece.

Gostou do artigo?

Compartilhe com seus amigos e ajude a espalhar conhecimento!