在企業上雲和多帳號治理的實踐過程中，身分與權限始終是最核心、也是最容易出問題的環節。無論是日常運維、自動化腳本，還是跨帳號存取和企業級SSO 集成，“目前呼叫AWS 介面的到底是誰”，往往是排查問題的第一個關鍵點。
在AWS 提供的眾多安全能力中，aws sts get-caller-identity 是一個極其基礎、卻又不可或缺的命令。它沒有複雜配置、不涉及資源變更，卻在實際專案中承擔著「身分校驗錨點」的角色。
什麼是AWS STS GetCallerIdentity？
get-caller-identity 是AWS Security Token Service（STS）提供的一個接口，用於返回當前呼叫者的身份訊息。透過此接口，使用者可以明確知道目前的請求是由哪一個IAM 使用者、角色（Role），或Root 帳戶發起。
在AWS CLI 中，只需執行一條指令即可取得結果：
aws sts get-caller-identity
典型返回內容如下：
{ "UserId": "AIDAEXAMPLE123456789", "Account": "123456789012", "Arn": "arn:aws:iam::123456789012:user/dev-user" }
這三個欄位共同構成了目前存取身分的「身分證明」。
- Account：目前AWS 帳號ID
- Arn：呼叫者的完整身分路徑
- UserId：AWS 內部使用的唯一識別符
透過ARN 快速識別目前身分類型
在實際使用中，真正有價值的是ARN。只看ARN，資深工程師就能判斷目前的授權連結是否正確。
1.IAM 用戶身份
arn:aws:iam::123456789012:user/dev-user
通常意味著使用的是長期AK/SK 憑證，適合開發調試，但不建議用於生產環境。
2.AssumeRole 身份
arn:aws:sts::123456789012:assumed-role/admin-role/session-name
這是企業環境中最常見的形態，廣泛用於：
- AWS SSO
- 跨帳號訪問
- ECS / EC2 / Lambda 的執行角色
3.Root 使用者身份
arn:aws:iam::123456789012:root
在生產環境中應極力避免，通常意味著安全風險或操作不規範。
為什麼它是權限排錯的“起點”
在實際客戶專案中，我們發現大量權限問題並非策略書寫錯誤，而是身份連結出現偏差。例如：
- 配置了多個CLI profile，卻使用了錯誤的帳號
- SSO 登入成功，但AssumeRole 未生效
- ECS Task Role 未正確綁定
- 自動化腳本在錯誤的執行角色下運行
在這些場景中，get-caller-identity 往往可以第一時間回答兩個關鍵問題：
- 目前操作確實發生在哪個AWS 帳號？
- 目前API 呼叫是由哪個IAM 身分發起？
這使得後續的策略分析和問題定位有了明確前提。
在企業級場景中的典型應用
1.多帳號與跨帳號治理
在Landing Zone、多帳號架構中，確認角色是否正確Assume 是合規與安全審計的基礎操作。
2.自動化與CI/CD
在管線發布、Terraform 執行前，校驗執行身分可顯著降低誤操作風險。
3.容器與無伺服器環境
在ECS、EKS、Lambda 中排查權限問題時，此指令常用來驗證執行角色是否與預期一致。
權限與成本影響
get-caller-identity 不需要額外授權，也不會修改或建立任何AWS 資源。介面呼叫免費，不會對帳單產生影響，適合在各類環境中頻繁使用。
作為AWS 代理商的實踐建議
作為AWS 官方合作夥伴，我們建議客戶將 get-caller-identity 納入以下標準流程：
- 權限問題排查的第一步
- 自動化腳本執行前的身分校驗
- 企業安全與Well-Architected Review 中的基礎檢查項
透過對身分連結的清晰認知，可以有效減少權限誤判、越權風險及維運複雜度。
結語
在AWS 的安全體系中，複雜往往不是問題的根源，看不清楚身分才是。aws sts get-caller-identity 正是連結「身分認知」與「權限配置」的關鍵一步。
身為AWS 代理商，在雲端持續幫助企業建構清晰、可控、可審計的雲端身分體系，確保每一次API 呼叫都來源明確、權限合理，真正讓雲端治理變得簡單可靠。
