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이란

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

2) Availability Zone

curl -H "X-aws-ec2-metadata-token: $TOKEN" \
 http://169.254.169.254/latest/meta-data/placement/availability-zone

3) 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. 결론 — 운영자라면 반드시 알아야 하는 핵심 포인트

1. 169.254.169.254는 EC2 내부에서만 접근 가능한 내부 시스템 주소이다.

2. IMDS는 인스턴스 ID, IAM Role 크리덴셜, 네트워크 등 핵심 정보를 제공한다.

3. IMDSv1은 SSRF에 매우 취약하며, 실제 대형 사고들을 유발했다.

4. IMDSv2는 토큰 기반 인증으로 보안을 극적으로 강화했다.

5. Auto Scaling·CloudWatch·배포 자동화·로그 백업 등 실무에서 반드시 사용된다.

6. EC2 운영 능력의 핵심 중 하나가 IMDS를 이해하고 적절히 사용하는 것이다.

AWS EC2 인스턴스 메타데이터

Table of Contents