AWS EC2 新增 ImdsV1Enabled 指標：企業 IMDSv2 遷移盤點與 5 步驟強制檢查清單
在 AWS 上跑 EC2 的企業，多半聽過「要把 IMDSv1 關掉、改用 IMDSv2」，但實際做起來常卡在第一步：到底還有哪些機器允許 IMDSv1？ 帳號一多、區域一多，靠人工或自寫腳本逐台檢查，很容易漏掉。
AWS 在 2026-11-05 推出 Amazon EC2 的 ImdsV1Enabled CloudWatch 指標：EC2 會依每台執行個體的設定，回報它是否仍允許 IMDSv1，企業可以直接用 CloudWatch 儀表板與警示，跨帳號、跨區域追蹤 IMDSv2 遷移進度。這個指標在所有 AWS 區域提供，不另外收費。 這讓長期「知道該做、但不知道做到哪」的 IMDSv2 遷移，終於有一個可以持續追蹤的數字。以下整理官方說明與企業落地的檢查重點。
為什麼 IMDSv1 值得企業處理
執行個體中繼資料服務（Instance Metadata Service，IMDS）讓 EC2 上的程式取得自身資訊，以及 IAM 角色的暫時憑證。IMDSv1 是單純的請求與回應；IMDSv2 則要求先取得 token，使用 token 的工作階段才能讀取資料。
以下為 WeWinCloud 的分析，非官方說法：IMDS 裡有 IAM 角色憑證，一旦網站程式有 SSRF（伺服器端請求偽造）之類的漏洞，攻擊者可能借道讀取中繼資料。改用 IMDSv2 是 AWS 長期建議的強化做法，也是許多資安檢查與稽核項目會問的設定。真正的難點不在「改一個參數」，而在於確認舊軟體不會因此壞掉。
新聞重點：三個 IMDS 指標各看什麼
以下為 AWS 官方公告與 EC2 使用者指南整理的事實（查核日期：2026-11-08）。
ImdsV1Enabled：看「設定」，不看「呼叫」
意義： 數值 1 代表執行個體允許 IMDSv1（httpTokens 為 optional）；數值 0 代表已停用 IMDSv1（httpTokens 為 required）。
依設定發布： 即使這台機器目前沒有任何 IMDSv1 呼叫，只要設定仍允許，就會被找出來。
加總就是數量： 官方說明，這個指標的 Sum 就是某帳號、某區域仍允許 IMDSv1 的執行個體數量，可用來衡量遷移進度。
範圍與費用： 屬於 AWS/EC2 命名空間的執行個體指標，所有 AWS 區域提供，不另外收費。
三個指標比較
指標 | 什麼時候有資料 | 用途 |
|---|---|---|
ImdsV1Enabled | 依執行個體設定持續發布 | 找出仍允許 IMDSv1 的機器、追蹤遷移進度 |
MetadataNoToken | 有 IMDSv1 呼叫時（允許 IMDSv1 的機器） | 確認還有沒有程式在用 IMDSv1，目標是降到 0 |
MetadataNoTokenRejected | IMDSv1 呼叫被拒時（已停用 IMDSv1 的機器） | 關閉 IMDSv1 後，找出因此失敗的軟體 |
官方也說明，同一台執行個體上，MetadataNoToken 與 MetadataNoTokenRejected 不會同時出現：允許 IMDSv1 時只會有前者，停用後只會有後者。
官方建議的 IMDSv2 遷移 5 步驟
AWS 的〈Transition to using IMDSv2〉文件列出以下路徑：
找出允許 IMDSv1 的執行個體並稽核用量： 用 ImdsV1Enabled 看數量；在 EC2 主控台以篩選條件「IMDSv2 = optional」找出是哪幾台；用 MetadataNoToken 看實際呼叫次數；用開源工具 IMDS Packet Analyzer 找出是哪個程式在呼叫 IMDSv1。
更新軟體： 把 AWS CLI、AWS SDK 與其他會使用角色憑證的軟體更新到支援 IMDSv2 的版本。Amazon Linux 2 與 Amazon Linux 2023 的套件皆支援 IMDSv2，Amazon Linux 2023 預設停用 IMDSv1。
在執行個體上要求 IMDSv2： 確認 MetadataNoToken 為 0 後，以主控台「修改執行個體中繼資料選項」或 ModifyInstanceMetadataOptions API 改為 Required。官方說明這項設定可在執行中的機器上修改，立即生效、不需重新開機。之後用 MetadataNoTokenRejected 監看有沒有程式因此失敗。
把 IMDSv2 設為預設： 在 EC2 帳號屬性的「IMDS defaults」設定，或用 AWS Organizations 的 Declarative Policies 設定組織層級預設，讓新機器自動要求 IMDSv2。AMI 也可把 ImdsSupport 設為 v2.0。
強制要求 IMDSv2： 依區域啟用帳號層級的 IMDSv2 強制設定，或用 IAM／SCP 條件鍵（ec2:MetadataHttpTokens 等）限制 RunInstances 與 ModifyInstanceMetadataOptions。
強制設定前要知道的事
既有機器不會被自動改： 帳號層級強制只影響新啟動的機器；已允許 IMDSv1 的既有執行個體不受影響，已停用的則無法再開回 IMDSv1。
可能讓部署失敗： 啟用強制後，若啟動設定、帳號預設與 AMI 都沒有把 httpTokens 設為 required，執行個體會啟動失敗。
Auto Scaling 要改範本： 自動擴展群組需要在啟動範本（launch template）設定 MetadataOptions；既有機器要另外修改或替換。
憑證也能加一道限制： 官方提到可在 IAM 政策或 SCP 使用 ec2:RoleDelivery 條件鍵（值 2.0），讓透過 IMDSv1 取得的角色憑證無法呼叫 API。
避免被改回去： 官方建議用 IAM 政策限制 ModifyInstanceMetadataDefaults API 的存取，防止強制設定被關閉。
對台灣企業的影響與建議
以下為 WeWinCloud 的分析與建議，非官方說法。
遷移進度終於能「量化」： 過去要寫腳本逐帳號、逐區域呼叫 API 統計；現在可以直接建 CloudWatch 儀表板，把「仍允許 IMDSv1 的台數」當成資安 KPI，每月追蹤。
最大風險是舊系統： 多年前建立的 AMI、舊版 SDK、第三方監控代理程式或自製腳本，最可能還在用 IMDSv1。不要跳過步驟 1 直接全面改 Required，先用 MetadataNoToken 與 IMDS Packet Analyzer 找出依賴。
先從新機器下手最省力： 先把帳號預設與啟動範本改成 IMDSv2，讓「新增的機器」不再增加待改清單，再分批處理既有機器。
多帳號環境要統一治理： 用 AWS Organizations 的多個帳號時，建議以 Declarative Policies 或 SCP 一次套用，並保留例外清單與到期日。
建議的落地檢查清單
建立 ImdsV1Enabled 儀表板，依帳號與區域列出仍允許 IMDSv1 的數量。
對數量不為 0 的帳號設定 CloudWatch 警示，避免新機器又以 IMDSv1 啟動。
依系統重要性排序，先在測試環境改為 Required，觀察 MetadataNoTokenRejected。
更新啟動範本、AMI（ImdsSupport = v2.0）與 IaC 範本（例如 Terraform、CloudFormation）中的中繼資料設定。
全部完成後，再啟用帳號層級強制，並用 IAM 限制修改預設值的權限。
常見問題 FAQ
ImdsV1Enabled 指標要額外付費嗎？
依 AWS 官方公告，ImdsV1Enabled 在所有 AWS 區域提供，不另外收費。若另外建立 CloudWatch 儀表板或警示，相關費用依 CloudWatch 定價計算，建議以官方定價頁為準。
把執行個體改成只接受 IMDSv2，需要重新開機嗎？
不需要。官方文件說明，可在執行中的執行個體上修改中繼資料選項，變更立即生效。但仍建議先確認沒有程式依賴 IMDSv1，避免服務中斷。
ImdsV1Enabled 和 MetadataNoToken 有什麼不同？
ImdsV1Enabled 看的是「設定是否允許 IMDSv1」，即使沒有呼叫也會回報；MetadataNoToken 看的是「實際有多少次 IMDSv1 呼叫」，只在有呼叫時才有資料。前者用來盤點範圍，後者用來確認能不能安全關閉。
啟用帳號層級 IMDSv2 強制，既有機器會受影響嗎？
不會改變既有機器的設定，但已停用 IMDSv1 的機器將無法再開回 IMDSv1；新啟動的機器若未設定要求 IMDSv2，會啟動失敗。啟用前要先確認啟動範本與 AMI 都已更新。
WeWinCloud 可以協助什麼
WeWinCloud 協助企業把 IMDSv2 遷移這類雲端資安設定，落實到日常維運：
資安顧問與弱點評估： 盤點 EC2、IAM 角色與對外服務的風險，排定修補優先順序
架構規劃與上雲： 調整啟動範本、AMI 與多帳號治理架構，讓新資源預設就安全
AWS 雲端服務： 架構規劃與技術支援，協助分批切換並監看指標
延伸閱讀
參考資料
留言