AWS EC2 인스턴스 메타데이터 서비스
AWS에서 서버를 운영하다 보면, 스크립트 또는 로그에서 169.254.169.254 라는 낯선 IP를 마주하게 됩니다.
이 주소는 외부에서도, 같은 서브넷에 있는 다른 인스턴스에서도 접근할 수 없지만 EC2 내부에서는 언제든지 접근 가능한 특수 시스템 엔드포인트입니다.
많은 자동화 도구, 배포 스크립트, Observability 에이전트, 서버 초기화 스크립트가 이 엔드포인트를 사용합니다.
그러나 대부분은 “그냥 쓰던 것” 정도로만 알고 있을 뿐, 왜 필요한지 / 내부적으로 어떻게 동작하는지 / 보안 이슈는 무엇인지 모르는 경우가 많습니다.
1. 169.254.169.254는 어디에 존재하는가?
이 IP는 Link-local IPv4 주소(169.254.0.0/16) 에 속합니다.
특징:
- 로컬 네트워크 인터페이스에서만 접근 가능
- 라우팅되지 않음
- 인터넷이나 동일 VPC 내 다른 인스턴스에서도 접근 불가
- 오직 해당 EC2 내부에서만 접근 가능
AWS는 이 주소를 EC2 하이퍼바이저(가상화 계층)에 바인딩하여, 인스턴스가 스스로 환경 정보를 조회할 수 있도록 만들어 놓았습니다.
요약하면:
169.254.169.254 = EC2 인스턴스 전용 내부 OS 정보 조회 시스템
2. EC2 메타데이터 서비스란?
EC2 내부에서 인스턴스 정보를 조회할 수 있는 서비스입니다.
접근 경로:
http://169.254.169.254/latest/meta-data/제공되는 정보 종류
| 카테고리 | 내용 |
|---|---|
| 인스턴스 정보 | instance-id, AMI ID, 인스턴스 타입, 호스트네임 |
| 네트워크 정보 | private-ip, public-ip, MAC주소, subnet-id, vpc-id |
| IAM 정보 | Role 이름, AccessKey / SecretKey / SessionToken(임시) |
| 스토리지 | 블록 디바이스 매핑 (/dev/xvda 등) |
| 시스템 | 보안 그룹, 인스턴스 프로파일 |
| 기타 | user-data(첫 부팅 스크립트) |
즉, 운영 자동화에서 필요한 대부분의 “환경 정보”를 EC2 자체가 직접 조회할 수 있습니다.
3. IMDSv1의 문제점: 심각한 SSRF 취약성
IMDSv1은 단순합니다.
curl http://169.254.169.254/latest/meta-data/이렇게 GET 요청 하나만으로 모든 메타데이터를 가져올 수 있었습니다.
문제가 된 이유 — SSRF 공격
웹 애플리케이션이 SSRF(Server Side Request Forgery) 취약점을 갖고 있다면, 공격자는 앱을 통해 다음 요청을 보내게 할 수 있습니다.
http://169.254.169.254/latest/meta-data/iam/security-credentials/<RoleName>이 URL은 EC2에 설정된 IAM Role Credentials(AccessKey / SecretKey / SessionToken)을 그대로 반환합니다.
그러면 공격자는:
- S3 버킷 삭제
- RDS DB 삭제
- EC2 종료
- IAM 사용자 생성
- Lambda 실행
등 사실상 AWS 전체 권한을 탈취할 수 있습니다.
2019년 Capital One 해킹 사고도 바로 이 취약점으로 인해 발생했습니다.
4. AWS가 IMDSv2를 만든 이유: 완전한 보안 강화
IMDSv2는 "세션 토큰 기반 인증"을 도입하여 SSRF 공격을 원천 차단합니다.
4.1 IMDSv2 동작 방식
1) 먼저 토큰 발급
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
-H "X-aws-ec2-metadata-token-ttl-seconds: 21600")- IMDSv2 토큰 TTL: 21600초(6시간)
- 정상 요청의 User-Agent와 Security Header를 요구
2) 이후 모든 메타데이터 요청에 토큰 포함
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
http://169.254.169.254/latest/meta-data/instance-id토큰이 없으면 401/403으로 즉시 거절됩니다.
4.2 IMDSv2의 효능
- SSRF로 metadata에 접근하는 것 자체가 불가능
- 웹서버를 거쳐 “대리 요청”을 시키는 것도 불가능
- 강력한 요청 제한(hop limit)으로 외부 네트워크 경유 접근 차단
기업 보안 기준에서는:
- IMDSv1 비활성화
- IMDSv2 필수
- hop-limit=1 강제
이 세 가지를 거의 기본 정책으로 사용합니다.
5. 운영 스크립트에서 IMDSv2가 쓰이는 이유
많은 운영 자동화 스크립트는 인스턴스 정보를 동적으로 가져와야 합니다.
예: EC2 로그 자동 백업 스크립트
INSTANCE_ID=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
http://169.254.169.254/latest/meta-data/instance-id)이 값을 이용해 다음처럼 S3 경로를 구성합니다.
s3://my-service-logs/<INSTANCE_ID>/<날짜>/...Auto Scaling 환경에서는 서버가 계속 새로 생성되고 삭제되므로, 고정된 서버 이름을 쓸 수 없습니다.
따라서 인스턴스 ID 등은 반드시 런타임에 조회해야 합니다.
또한 다음 AWS 기능들도 내부적으로 모두 IMDS를 사용합니다.
- CloudWatch Agent
- CodeDeploy Agent
- SSM Agent
- Jenkins Agent (EC2 기반)
- 배포/옵저버빌리티 자동화 스크립트
IMDS가 꺼져 있으면 많은 운영 도구가 제대로 작동하지 않습니다.
6. IMDSv2 보안 옵션
EC2 생성 시 다음을 설정할 수 있습니다.
✔ IMDS 활성화 여부
- enabled / disabled
✔ IMDSv1 허용 여부
- optional (둘 다 허용)
- required (IMDSv2만 허용)
✔ Hop limit
Hop limit = 메타데이터 요청이 몇 hop까지 허용되는지 설정
- 기본값: 1 (EC2 내부에서만 접근 가능)
- 2 이상 → 매우 위험, 내부 네트워크에서 metadata가 노출될 수 있음
대부분의 보안 규정은 다음을 요구합니다.
- "IMDSv2 required"
- "IMDS hop limit = 1"
7. 실무에서 자주 쓰는 메타데이터 명령어 모음
1) 인스턴스 ID
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
http://169.254.169.254/latest/meta-data/instance-id2) Availability Zone
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
http://169.254.169.254/latest/meta-data/placement/availability-zone3) IAM Role 이름
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
http://169.254.169.254/latest/meta-data/iam/security-credentials/4) 실제 AWS Credentials 조회
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
http://169.254.169.254/latest/meta-data/iam/security-credentials/<RoleName>(매우 민감 — 절대 로그로 남기면 안 됨)
8. 결론 — 운영자라면 반드시 알아야 하는 핵심 포인트
- 169.254.169.254는 EC2 내부에서만 접근 가능한 내부 시스템 주소이다.
- IMDS는 인스턴스 ID, IAM Role 크리덴셜, 네트워크 등 핵심 정보를 제공한다.
- IMDSv1은 SSRF에 매우 취약하며, 실제 대형 사고들을 유발했다.
- IMDSv2는 토큰 기반 인증으로 보안을 극적으로 강화했다.
- Auto Scaling·CloudWatch·배포 자동화·로그 백업 등 실무에서 반드시 사용된다.
- EC2 운영 능력의 핵심 중 하나가 IMDS를 이해하고 적절히 사용하는 것이다.
