Postagens

Mostrando postagens com o rótulo AWS

Obtendo o Instance ID via Metadados do EC2: Por que IMDSv2 é Mais Seguro que V1

Você está escrevendo um script de inicialização ou uma rotina de automação que precisa saber em qual instância EC2 está rodando — e a pergunta natural é: como obter o Instance ID de dentro da própria máquina, sem depender de variáveis de ambiente ou arquivos de configuração externos? A resposta está no Instance Metadata Service (IMDS), mas a forma como você o acessa faz toda a diferença do ponto de vista de segurança. TL;DR — Resumo Rápido Aspecto IMDSv1 IMDSv2 Autenticação Nenhuma — requisição direta Token de sessão obrigatório Vulnerabilidade SSRF Exposta Mitigada pelo token Método HTTP GET simples PUT para obter token, depois GET Recomendação AWS Legado — evitar Padrão recomendado Configuração necessária Nenhuma Nenhuma (habilitado por padrão em novas instâncias) Como o Instance Metadata Service Funciona O IMDS é um endpoint HTTP local disponível em http://169.254.169.254 — um endereço lin...

Visibility Timeout no SQS: Por Que Suas Mensagens São Processadas Duas Vezes

Você está vendo a mesma mensagem sendo processada por dois consumidores diferentes, gerando duplicatas no banco de dados ou efeitos colaterais repetidos em produção. O problema quase sempre está no Visibility Timeout do SQS configurado abaixo do tempo real de processamento — e o SQS, por design, assume que a mensagem foi perdida e a reentrega. TL;DR — Visibility Timeout no SQS Ponto Detalhe O que é Janela de tempo em que uma mensagem fica invisível para outros consumidores após ser recebida Padrão 30 segundos Faixa configurável 0 segundos a 12 horas Causa de duplicata Processamento demora mais que o timeout — SQS reentrega a mensagem Solução imediata Aumentar o timeout ou chamar ChangeMessageVisibility durante o processamento Garantia do SQS At-least-once delivery — duplicatas são esperadas, idempotência é obrigatória Como o Visibility Timeout Funciona no SQS Quando um consumidor chama ...

DynamoDB Modos de Capacidade: Provisionado vs. On-Demand — Como Escolher Sem Errar

Você acabou de modelar sua tabela DynamoDB e chegou na tela de configuração de capacidade. O tráfego da aplicação ainda é incerto — pode ser 10 requisições por segundo, pode ser 10.000. Escolher o modo errado aqui significa ou pagar por capacidade ociosa ou ver a aplicação throttlada em produção. Este post detalha como os modos de capacidade do DynamoDB funcionam internamente, quando cada um faz sentido, e como migrar entre eles sem surpresas. TL;DR — Modos de Capacidade DynamoDB Critério On-Demand Provisionado Tráfego previsível ❌ Custo mais alto ✅ Mais econômico Tráfego imprevisível ou novo ✅ Sem risco de throttling ❌ Risco de under-provisioning Picos esporádicos e intensos ✅ Absorve automaticamente ⚠️ Depende de Auto Scaling Custo por unidade Mais caro por RCU/WCU individual Mais barato com uso consistente Configuração operacional Zero Requer monitoramento e ajuste Troca de modo Uma vez a ca...

Route 53 Alias vs CNAME: Qual Usar para Apontar seu Domínio para um ALB?

Você acabou de provisionar um Application Load Balancer e precisa apontar example.com para ele. A primeira tentativa natural é criar um registro CNAME — e aí você descobre que o console do Route 53 simplesmente não deixa. Não é bug, não é permissão faltando: é uma limitação fundamental do protocolo DNS que existe desde 1987, e o registro Alias do Route 53 foi criado especificamente para contorná-la. TL;DR — Alias vs CNAME no Route 53 Característica CNAME Alias (Route 53) Funciona no zone apex ( example.com ) ❌ Não ✅ Sim Aponta para ALB, CloudFront, S3 ✅ Sim (subdomínios) ✅ Sim (qualquer nível) Cobrança por consulta DNS Sim Gratuito para destinos AWS suportados Retorna endereço IP diretamente Não — retorna outro nome Sim — resolve para A/AAAA Health check integrado ...

Configurando um Alarme de Cobrança no Free Tier da AWS com CloudWatch

Você acabou de criar sua conta AWS, ativou alguns serviços para testar e, algumas semanas depois, recebe uma fatura inesperada. Isso acontece com mais frequência do que deveria — configurar um alarme de cobrança para o AWS Free Tier é a primeira coisa que qualquer engenheiro deveria fazer antes de qualquer outra coisa na conta. TL;DR — Resumo Rápido Etapa O que fazer Serviço envolvido 1 Habilitar métricas de cobrança na conta Billing Console 2 Criar tópico SNS e confirmar e-mail Amazon SNS 3 Criar alarme no CloudWatch com threshold de $5 Amazon CloudWatch 4 Verificar o alarme via CLI AWS CLI Como o Alarme de Cobrança do CloudWatch Funciona Antes de executar qualquer comando, vale entender o fluxo. A métrica EstimatedCharges do namespace AWS/Billing só é publicada na região us-east-1 — independentemente de onde seus recursos estão rodando. Isso não é configurável. Se você criar o alarme em outra...

EBS gp2 vs gp3: Qual escolher para escalar IOPS sem aumentar o disco?

Você está provisionando um volume EBS e vê duas opções de SSD de uso geral: gp2 e gp3. A diferença não é apenas de geração — o modelo de performance e custo entre eles é fundamentalmente diferente, e escolher errado significa pagar mais por menos controle. Em workloads de banco de dados ou aplicações com picos de I/O previsíveis, essa decisão impacta diretamente o comportamento da instância em produção. TL;DR: gp2 vs gp3 — Comparação Direta Característica gp2 gp3 IOPS base 3 IOPS/GB (mín. 100, máx. 16.000) 3.000 IOPS fixos incluídos IOPS independente do tamanho Não — acoplado ao tamanho do volume Sim — configurável até 16.000 IOPS Throughput máximo 250 MiB/s 1.000 MiB/s Throughput base incluído Acoplado ao modelo de burst 125 MiB/s incluídos Custo por GB Maio...