EC2에 IMDSv1 설정 지표 추가: 호출이 없어도 허용 상태를 확인합니다
🤖 AI Summary
EC2의 IMDSv1 허용 설정과 실제 호출은 다른 관측 대상입니다. AWS가 11월 5일 발표한 ImdsV1Enabled는 호출이 없어도 설정 상태를 확인하도록 돕습니다. MetadataNoToken은 실제 접근, MetadataNoTokenRejected는 차단 후 거부된 시도를 보는 지표입니다. IMDSv2 전환은 지표 조회로 끝나지 않으며 소프트웨어 호환성, 설정 변경, 변경 후 동작을 나눠 확인해야 합니다.
블로그 목차
최근 IMDSv1 호출을 찾지 못했습니다. 그렇다면 해당 EC2 인스턴스는 이미 IMDSv2만 받도록 설정된 걸까요? 호출 기록만으로는 이 질문에 답하기 어렵습니다. 사용하지 않은 것과 사용할 수 없게 설정한 것은 다르기 때문이죠.
이번 발표는 그 차이를 확인할 수단을 더합니다. 이 글은 실제 AWS 계정을 조사한 결과가 아니라 공식 발표와 사용자 가이드를 바탕으로 지표의 의미와 확인 순서를 설명합니다.
11월 5일 EC2 발표에서 어떤 지표가 추가됐나요?
IMDSv1 호출이 없어도 허용 설정을 확인할 수 있는 ImdsV1Enabled 지표를 발표했습니다.
AWS의 2026년 11월 5일 공식 발표에 따르면 새 CloudWatch 지표는 EC2 인스턴스가 IMDSv1을 계속 허용하는지 보여줍니다. 대시보드와 알람으로 전환 대상을 추적하는 데 활용할 수 있죠. 지표가 추가됐다는 사실과 인스턴스 설정이 바뀌었다는 사실은 구분해야 합니다.
먼저 IMDS의 역할을 짚어 보세요. AWS의 IMDS 사용 안내는 인스턴스 메타데이터에 접근하는 두 방식을 설명합니다. IMDSv2는 세션 토큰을 사용하는 방식이며, IMDSv1과 요청 방식이 다릅니다. 새 지표는 이 접근 방식 중 무엇을 허용하는지 읽는 데 쓰입니다.
ImdsV1Enabled의 0과 1은 무엇을 뜻하나요?
1은 httpTokens의 optional, 0은 required 설정을 뜻하므로 호출 횟수와 구분합니다.
EC2 인스턴스 지표 설명은 두 값을 다음과 같이 연결합니다. 이름에 Enabled가 들어가더라도 IMDSv2의 성공 여부를 나타내는 지표로 읽으면 안 됩니다.
지표 값 | httpTokens 설정 | 읽을 수 있는 의미 |
|---|---|---|
1 | optional | IMDSv1을 허용하는 설정 |
0 | required | 토큰을 요구하는 설정으로 IMDSv1 비활성화 |
optional은 IMDSv1만 사용한다는 뜻이 아닙니다. 메타데이터 옵션 안내는 토큰 선택 상태에서 IMDSv1과 IMDSv2를 허용하고, 토큰 필수 상태에서는 IMDSv2만 허용한다고 설명하죠. 또한 IMDS 자체의 활성화 여부는 별도 옵션입니다. 토큰 설정 하나만으로 메타데이터에 정상 접근할 수 있다고 판단하지 않습니다.
MetadataNoToken과 새 지표는 무엇이 다른가요?
MetadataNoToken은 실제 접근을, 새 지표는 허용 설정을 나타내므로 관측 목적이 다릅니다.
인스턴스 지표 문서에서 MetadataNoToken은 토큰 없이 IMDS에 성공적으로 접근한 횟수입니다. 반면 ImdsV1Enabled는 설정을 기준으로 발행되므로 IMDSv1 호출이 없는 때에도 허용 상태를 파악하도록 돕습니다.
지표 | 관측 대상 | 해석할 때의 구분 |
|---|---|---|
ImdsV1Enabled | IMDSv1 허용 설정 | 설정 상태이며 호출 횟수가 아님 |
MetadataNoToken | 토큰 없는 성공 접근 | IMDSv1 실제 사용을 조사 |
MetadataNoTokenRejected | IMDSv1 차단 후 거부된 호출 시도 | 변경 후 남은 호출 의존성을 조사 |
예를 들어 토큰 없는 호출을 관찰하지 못했더라도 설정이 optional로 남아 있다면, 사용 흔적과 허용 설정의 결론은 다릅니다. 아래 그림은 이 구분을 설명하는 개념도이며 실측 대시보드가 아닙니다.
호출이 없으면 IMDSv2 전환이 끝났다고 봐도 되나요?
호출이 관찰되지 않았다는 사실만으로 전환 완료를 단정하지 말고 관측 범위와 현재 설정을 함께 대조합니다.
AWS의 IMDSv2 전환 가이드는 IMDSv1을 허용하는 인스턴스를 찾고 실제 호출을 조사하는 일을 구분합니다. 사용 소프트웨어를 업데이트한 뒤 IMDSv2를 요구하도록 변경하고, 이후 거부된 호출과 문제를 확인하는 흐름이죠.
검토 기록에는 계정·리전·인스턴스와 관측 기간을 함께 적는 방식을 제안합니다. 데이터가 비어 있는 결과를 측정값 0으로 바꾸거나, 특정 기간의 관찰을 모든 실행 경로에 대한 시험 결과로 확대하지 마세요. 부팅 시점이나 평소 실행되지 않은 작업은 확인 범위를 따로 표시하는 편이 좋습니다.
설정을 확인한 시점도 남겨 두세요. 예전 호출 기록과 현재 설정을 같은 시점의 증거처럼 취급하면 변경 전후를 잘못 해석할 수 있어요. 이 구분은 기록을 정리하는 제안이며 별도의 AWS 기능을 뜻하지 않습니다.
실제 전환 전 어떤 의존성을 확인해야 하나요?
소프트웨어의 IMDSv2 호환성을 확인하고 변경 후 거부 기록과 업무 동작을 함께 점검합니다.
전환 가이드는 SDK·CLI와 인스턴스에서 역할 자격 증명을 사용하는 소프트웨어의 호환성 확인을 안내합니다. IMDS Packet Analyzer는 부팅과 실행 중 IMDSv1 호출을 식별하는 도구로 소개하죠. 확인한 호출 주체를 기준으로 업데이트 대상을 좁힙니다.
변경 뒤에는 MetadataNoTokenRejected와 실제 소프트웨어 문제를 함께 봅니다. 거부된 호출이 보이면 어느 프로그램의 요청인지 조사해야 하죠. 설정 변경이 재부팅 없이 적용된다는 설명을 업무 영향이 없다는 보장으로 바꾸지는 않습니다.
이 글은 여러 인스턴스를 한꺼번에 바꾸는 명령 대신 관측의 의미를 설명합니다. 필요한 시험 범위와 변경 대상을 정한 뒤 공식 전환 절차를 검토하세요. 토큰 설정의 값만 확인하고 애플리케이션 정상 동작까지 확인했다고 기록하지 않는 것이 핵심입니다.
자격 증명의 보관과 회전 원칙은 시크릿 관리 입문: 하드코딩된 Access Key가 사고가 되기 전에에서 다룹니다. 이번 글은 시크릿 관리 전반을 반복하지 않고 EC2 메타데이터의 허용 설정과 호출 관측을 읽는 데 집중합니다.
이것만 기억하세요
설정과 실제 동작은 각각의 증거로 확인해야 합니다. 호출을 찾지 못한 결과를 차단 확인으로 바꾸지 말고, 어느 대상과 기간을 살폈는지 남겨 두세요. 전환 뒤에도 거부 기록과 업무 동작을 함께 검토합니다.
자주 묻는 질문 (FAQ)
Q. ImdsV1Enabled가 1이면 IMDSv1 요청이 발생했다는 뜻인가요?
아닙니다. IMDSv1을 허용하는 설정이라는 뜻입니다. 실제 토큰 없는 접근 기록은 MetadataNoToken과 구분해 확인합니다.
Q. ImdsV1Enabled가 0이면 애플리케이션도 정상인가요?
0은 httpTokens가 required라는 설정을 나타냅니다. 애플리케이션의 IMDSv2 접근 성공이나 업무 정상 여부까지 입증하지는 않습니다.
Q. MetadataNoToken 데이터가 없으면 0으로 봐도 되나요?
데이터가 없다는 사실을 0이라는 측정값으로 바꾸지 않습니다. 대상과 관측 기간, 현재 메타데이터 설정을 먼저 대조하고 판단 근거를 구분합니다.
Q. 새 지표를 조회하면 IMDSv1도 자동으로 차단되나요?
아닙니다. 지표 조회와 설정 변경은 별개입니다. IMDSv2만 요구하도록 변경할 때는 사용 소프트웨어의 호환성과 영향을 먼저 확인해야 합니다.
Q. IMDSv1 차단 뒤 거부된 호출은 무엇으로 확인하나요?
MetadataNoTokenRejected로 IMDSv1 호출 시도와 거부 기록을 확인합니다. 기록이 보이면 해당 호출 소프트웨어와 실제 업무 영향을 함께 조사합니다.
