Habilitando o IMDSv2 EC2 AWS
O tema de hoje como podemos estar Habilitando IMDSv2 EC2 AWS.
O IMDSv2 usa solicitações orientadas a sessão. Com solicitações orientadas a sessão, você cria um token de sessão que define a duração da sessão, que pode ser, no mínimo, um segundo e, no máximo, seis horas. Durante o período especificado, é possível usar o mesmo token de sessão para solicitações subsequentes.
Fonte: Site AWS
Para essa ativação temos que acessar a instancia desejada e avaliar se está como “Required”. Em nosso exemplo temos ela como “”Optional”. 
Para ativar temos que selecionar a opção “Instance settings”, em seguida “modify instance metadata options”.
Como podemos ver está como optional.
Para ativar o recurso temos que selecionar a opção de “Required” e “Save”.
Após isso teremos a opção como “required”.
Por que o IMDSv2 importa (e não é só burocracia)
O IMDSv1 aceita requisições HTTP simples, sem token, pro endpoint de metadados (169.254.169.254). Isso vira um problema sério quando a instância roda uma aplicação vulnerável a SSRF (Server-Side Request Forgery): um atacante consegue fazer a própria aplicação “perguntar” pro serviço de metadados e devolver credenciais temporárias da IAM Role da instância — sem nunca ter acesso direto ao servidor. Foi exatamente esse vetor que causou o vazamento de dados da Capital One em 2019, um dos incidentes mais citados de segurança em nuvem.
O IMDSv2 fecha essa brecha exigindo um token de sessão obtido via requisição PUT — algo que a maioria dos payloads de SSRF simples não consegue replicar, já que exige um verbo HTTP diferente e um cabeçalho customizado.
Habilitando via AWS CLI (útil pra várias instâncias de uma vez)
Pra não precisar entrar instância por instância no console, dá pra forçar o IMDSv2 direto pela CLI:
aws ec2 modify-instance-metadata-options --instance-id i-1234567890abcdef0 --http-tokens required --http-endpoint enabled
Se você ainda não tem a AWS CLI configurada na sua máquina, veja como instalar o AWS CLI no Windows.
Atenção ao hop limit em containers
Se a instância roda containers (Docker, ECS, EKS) que também precisam acessar o serviço de metadados, o parâmetro padrão --http-put-response-hop-limit 1 pode bloquear o acesso de dentro do container, já que ele conta como um “hop” extra de rede. Nesses casos, aumentar pra 2 resolve sem precisar voltar pro IMDSv1.
Confirmando que a instância está usando IMDSv2
Depois de aplicar a mudança, você pode confirmar de dentro da própria instância com curl -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" -X PUT http://169.254.169.254/latest/api/token — se vier um token, o IMDSv2 está habilitado e funcionando corretamente na instância EC2.
🚀 Vamos nos conectar?
Não perca nenhuma oportunidade! Cadastre-se nas minhas redes e no canal do YouTube para receber conteúdos de TI, Cloud, Azure, Kubernetes e DevOps em primeira mão.
Dica: No Facebook, todos os artigos do blog são publicados automaticamente. Vale a pena curtir!
💬 Dúvidas ou Problemas?
Com o intuito de ajudar a comunidade, caso você tenha dúvidas ou encontre problemas na execução dos comandos deste artigo, deixe um comentário abaixo. Responderei o mais breve possível!
Muito obrigado pela visita e até o próximo post!
Jefferson Castilho Especialista em Cloud & DevOps.
Este guia técnico é exclusivo do Blog do Castilho. Explore mais conteúdos sobre Cloud e DevOps.