Postagens

Mostrando postagens de junho, 2026

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 ...

Variáveis de Ambiente no Lambda: Configuração, Acesso e Criptografia com KMS

Você tem um endpoint de banco de dados que precisa chegar até a função Lambda — hardcodar isso no código é o caminho mais rápido para um vazamento de credencial em um repositório público. Variáveis de ambiente no Lambda resolvem esse problema, e quando combinadas com KMS, você adiciona uma camada de criptografia que vai além do padrão gerenciado pela AWS. TL;DR — Variáveis de Ambiente no Lambda Ponto Detalhe Onde configurar Console, CLI ( --environment ), IaC (CloudFormation/SAM/Terraform) Criptografia padrão AWS gerencia com chave própria (aws/lambda) — transparente, sem custo adicional de KMS Criptografia customizada Você fornece uma CMK do KMS; Lambda criptografa em repouso e você descriptografa em runtime Acesso no código process.env.NOME (Node.js), os.environ['NOME'] (Python) Limite de tamanho 4 KB total para todas as variáveis — verifique a documentação oficial para limites atuais ...