SW BBANG P

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

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

Você abre o console da AWS, confere o target group e todas as instâncias estão Healthy . Mesmo assim, o ALB continua retornando 502 Bad Gateway para os clientes. Esse é um dos cenários mais frustrantes em operações com Application Load Balancer — o health check passa, mas a aplicação real falha silenciosamente na camada de protocolo HTTP. TL;DR — Diagnóstico Rápido do 502 no ALB Causa Raiz Sinal Observável Camada Resposta HTTP malformada da aplicação 502 imediato, sem latência Aplicação Conexão fechada antes da resposta completa 502 intermitente sob carga Keep-alive / TCP Timeout de idle no ALB menor que no backend 502 em requisições longas Configuração ALB Header HTTP inválido ou tamanho excedido 502 em rotas específicas Protocolo HTTP Target desregistrado durante requisição ativa 502 durante deploy/scale-in Ciclo de vida Como o ALB Processa Respostas — Antes de Depurar O ALB opera na camada ...