“`html
Erros comuns em AWS que você deve evitar
Se você já se pegou “corrigindo” custos, apagando incidentes tarde demais ou lidando com permissões
que nunca fecham, este guia é pra você. A ideia aqui é apontar os erros mais frequentes e como evitar
antes de virar dor de cabeça.
1 Permissões demais (ou de menos) sem governança
Um dos erros mais comuns em AWS é tratar IAM como “configurações temporárias”.
O resultado costuma ser acesso amplo para “resolver rápido” (risco) ou bloqueio total para “evitar risco”
(atraso operacional).
- Use policy genérica demais: credenciais com
"Action": "*"ou recursos sem escopo. - Falta de separação por função: o mesmo papel faz tudo (deploy, leitura, admin, suporte).
- Sem trilha de auditoria: deixar de habilitar trilhas (ex.: CloudTrail) e monitoramento.
- Dependência em “chave de longa duração”: acesso estático em vez de identidade efêmera.
o acesso com testes de permissões (o ideal é que deploy e runtime tenham políticas diferentes).
2 Custos imprevisíveis por falta de controle e tags
Outro erro clássico: rodar recursos “por tempo indeterminado” e só descobrir custo quando o mês fecha.
Mesmo em cenários pequenos, isso vira padrão e escala com o tempo.
- Sem tags obrigatórias: fica difícil ratear custo por time, app ou ambiente.
- Instâncias e serviços sem política de descarte: volumes EBS parados, NAT gateways caros, snapshots acumulados.
- Ignorar uso e limites: permissões/quotas permitem operar sem perceber gargalos (ou custos crescentes).
- Sem budgets e alertas: você só vê o custo quando já passou.
app, env, owner, cost-center),configure budgets e revise mensalmente os recursos “órfãos” (principalmente redes e storage).
3 Observabilidade fraca: você não monitora o que realmente importa
Muita gente monitora “CPU e erro 500” e acha que está coberta.
Na prática, incidentes relevantes falham em métricas óbvias: latência, saturação de fila, falha de dependência,
e degradação gradual.
- Sem logs estruturados: quando dá problema, você depende de tentativa e erro para entender o fluxo.
- Alertas sem contexto: alertas que “disparam” mas não orientam ação.
- Foco em métricas internas e não em SLO: você mede o servidor, mas não o usuário.
- Não correlacionar eventos: eventos assíncronos e filas quebram sem que você perceba.
configure alertas por limiar e por taxa (ex.: erro por minuto), e padronize um “dash” por serviço.
Observação: ajuste conforme seu serviço
# Exemplo de padrão: alertar por taxa (não apenas contagem)
# Use métricas do seu app/serviço e crie alarmes com base em percentuais.
# Cenário: API Gateway / ALB / aplicação gerando métrica de 5xx
# Regra sugerida:
# - Taxa > 2% por 5 minutos
# - Sustentado (para reduzir falsos positivos)
#
# Em vez de: "5xx > 10"
# Prefira: "5xx_rate > 2%"
4 Arquitetura sem resiliência e deploy sem segurança
É comum ver workloads sem failover pensado, com filas sem política de retentativa,
ou dependências críticas sem timeout/circuit breaker.
Some isso a um processo de deploy sem validação e você terá incidentes recorrentes.
- Single point of failure: um único componente crítico sem redundância.
- Time-out e retry mal configurados: retry agressivo amplifica a falha (e o custo).
- Deploy direto em produção: sem canário, sem rollback e sem verificação de saúde.
- Sem estratégia para dados: migração e restauração improvisadas em incidente.
estabeleça timeouts consistentes e padronize comportamento de retry com backoff.
Aplicável a chamadas HTTP / dependências
# Padrão de retry seguro (conceitual):
# - Backoff exponencial com jitter
# - Limite de tentativas
# - Não retry em erros que não são recuperáveis
def should_retry(status_code):
# Exemplo: retry para erros transitórios
return status_code in (408, 429, 500, 502, 503, 504)
def backoff_ms(attempt):
# backoff exponencial limitado + jitter
base = 200
cap = 5000
exp = min(cap, base * (2 ** (attempt - 1)))
jitter = random.randint(0, 250)
return exp + jitter
max_attempts = 4
for attempt in range(1, max_attempts + 1):
try:
resp = call_dependency()
if resp.ok:
break
if not should_retry(resp.status_code):
raise Exception(f"Não-retryável: {resp.status_code}")
except TransientError:
if attempt == max_attempts:
raise
sleep(backoff_ms(attempt))
Quer aprofundar ainda mais?
No yurideveloper.com eu organizo posts técnicos que evitam justamente esses “erros que viram hábito”.
Vale a pena ler também os conteúdos sobre IAM na prática, redução de custo e observabilidade com métricas e logs.
“`
Sou Apaixonado pela programação e estou trilhando o caminho de ter cada diz mais conhecimento e trazer toda minha experiência vinda do Design para a programação resultando em layouts incríveis e idéias inovadoras! Conecte-se Comigo!