AWS國際企業帳號 AWS命令行工具配置與CLI多賬戶權限切換技巧

第一章：把命令行當成一張可控的地圖

很多人剛開始用 AWS CLI 時，會把憑證一股腦放進同一套設定裡：一份密鑰、固定的 access key、再配幾個常用參數。這樣短期很省事，但一旦你同時要管理開發、測試、預發、正式，或同時需要不同公司的不同賬戶，問題就會慢慢浮現：你不確定目前的賬戶是哪個；你不知道命令到底用了哪組憑證；有時切換得太快，最後才發現「以為」做在 A 賬戶，實際上打到了 B 賬戶。

真正舒服的 CLI 多賬戶體驗，不是把命令寫得更花，而是把流程設計得更清楚：用 profile 把賬戶與角色說清楚；用 assume-role 讓權限變成可控、可追蹤的臨時憑證；用 MFA/會話時間限制把風險壓低；用一套固定的切換命令讓你不必靠記憶。

本文會用比較務實的做法，從「配置」到「切換」，再到「日常排錯與安全」，一路串起來。你不需要同時學完所有 AWS 概念，但需要一套能直接落地的 CLI 多賬戶工作流。

AWS國際企業帳號 第二章：AWS CLI 的基本組件與設定檔位置

AWS CLI 的核心概念其實很簡單：它會在你呼叫命令時，嘗試從特定來源讀取憑證與設定，然後用該憑證去簽名 API 請求。你要做的是「讓每個賬戶/角色都有自己的配置入口」，並且讓切換變成明確的選擇。

2.1 常見的設定檔與憑證檔

大多數情況下，你會在主目錄下看到兩個檔案：

• ~/.aws/config：儲存非密鑰類設定，例如 region、profile、role 設定等。

• ~/.aws/credentials：儲存基本憑證（access key / secret key），或被你自行管理的密鑰對。

但如果你使用了更多自訂方式（例如使用環境變數、使用 SSO、或在不同平台有不同目錄），要注意優先順序：CLI 讀憑證並不是只看一個檔案。

2.2 AWS CLI 的憑證優先順序（你需要知道的重點）

你不必背下所有細節，但要記得原則：CLI 會依序檢查多種來源，當你同時設了環境變數與 profile，結果可能跟你想的不一致。

因此在做多賬戶切換時，盡量避免「到處都設」：不要長期在終端機環境裡塞 access key，除非你確定自己在控制它。

第三章：建立第一個多賬戶 Profile（从“能用”到“清楚”）

多賬戶的基礎動作是：為每個賬戶（或每個角色）建立獨立的 profile，並在呼叫 CLI 命令時顯式指定。只要你做到了這一步，很多混亂自然會消失。

3.1 建立 profile 的兩種常見方式

AWS國際企業帳號 profile 常見有兩類：

• 靜態憑證型（Access Key / Secret）：適用於你手上確實有該賬戶的長期密鑰。不過這通常不推薦用於正式安全策略，因為長期密鑰的風險更高。

• 角色切換型（AssumeRole）：更常見的企業做法。你用一組「可取得臨時權限」的身份，去假冒（assume）某角色，獲得臨時憑證。

在多賬戶環境裡，assume-role 往往是更好的選擇：權限更可控、會話時間更短、可結合 MFA。

3.2 config 檔中定義 profile（示例骨架）

假設你有兩個賬戶：dev-account 與 prod-account。你希望透過不同角色切換：

• dev：假設角色 arn:aws:iam::111111111111:role/DeveloperRole

• prod：假設角色 arn:aws:iam::222222222222:role/OperatorRole

你可以在 ~/.aws/config 加入：

[profile dev]
region=ap-northeast-1
role_arn=arn:aws:iam::111111111111:role/DeveloperRole
source_profile=base

[profile prod]
region=ap-northeast-1
role_arn=arn:aws:iam::222222222222:role/OperatorRole
source_profile=base

其中 source_profile 指向你用來假設角色的「底座身份」（base）。它可能是你的登入用長期憑證，或是你用 SSO 得到的某種可用來源。

3.3 credentials 檔中放 base（或使用 SSO/其他來源）

若你的 base 是一組靜態密鑰，可以在 ~/.aws/credentials 放：

[base]
aws_access_key_id=AKIA...
aws_secret_access_key=...

如果你的公司用的是 SSO，那 base 可能不需要放在 credentials，而是由 aws sso login 或特定來源提供。具體做法取決於你組織的身份策略。

3.4 用 profile 呼叫命令

當 profile 就位後，你就能明確地呼叫：

aws sts get-caller-identity --profile dev
aws sts get-caller-identity --profile prod

看這兩次輸出裡的 Account 是否分別對應你期望的賬戶。你應該把這一步變成習慣：每次切換到新的 profile，都先用 sts get-caller-identity 確認。

第四章：assume-role 與臨時憑證的切換技巧

assume-role 的魅力在於：你不需要為每個角色準備一套長期密鑰。CLI 會代表你請求 AWS 產生臨時憑證，通常有效期短，而且可以配合 MFA、限制會話時長。

4.1 在切換時避免“以為切了其實沒切”

最常見的錯誤是：你以為自己在某個 profile，但實際命令沒有指定 --profile，或你的環境變數覆蓋了配置。

因此我建議：

• 在日常工作中，幾乎所有 AWS CLI 命令都帶上 --profile（至少在初期）。

• 在必要時使用明確的 shell alias，例如 alias awsd='aws --profile dev' 之類（不要用太多花樣，否則更難排查）。

• 不要在終端機長期 export AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY，除非你非常確定自己在控制切換。

4.2 使用 MFA：把“第二道門”變成可預期流程

如果你的角色切換要求 MFA，通常在 role 設定或你所在的 AWS 身份流程中會觸發。CLI 在假設角色時會需要 mfa_serial 或透過特定參數。

一個常見做法是在 ~/.aws/config 補上：

[profile prod]
region=ap-northeast-1
role_arn=arn:aws:iam::222222222222:role/OperatorRole
source_profile=base
mfa_serial=arn:aws:iam::222222222222:mfa/your-virtual-mfa

接著你執行：

aws sts get-caller-identity --profile prod

CLI 可能會提示你輸入 MFA code。這時你會更確定「臨時憑證」是以正確身份、在正確賬戶下拿到的。

若你遇到需要 MFA 但命令沒有提示，或一直報錯，通常原因是 profile 中的 MFA 參數不對，或你的 base 身份沒有被授權去 assume-role 並使用 MFA 方案。

4.3 會話時長與權限範圍：讓臨時憑證“夠用但不多”

臨時憑證不是永遠有效。合理的做法是配合你團隊的安全策略設定會話時長。例如你可能希望每次 assume-role 有 1 小時或更短的有效期，讓誤操作的影響面縮小。

在 ~/.aws/config 的 profile 中可以加入例如：

[profile prod]
role_arn=arn:aws:iam::222222222222:role/OperatorRole
source_profile=base
role_session_name=cli-prod-session

role_session_name 的價值在於可追蹤：AWS 日誌與 CloudTrail 常能看到會話名稱，排錯或追責會清晰許多。

第五章：把多賬戶切換做成“可視化流程”

光靠 profile 解決了「用對憑證」的問題，還不夠，因為你還得解決「心裡有數」：我現在到底在 dev 還是 prod？我接下來的命令會動到什麼資源？如果出錯，錯在何處？

5.1 用“確認步”建立節奏

我建議你在任何會產生變更的操作前，固定跑一遍確認命令：

aws sts get-caller-identity --profile prod
aws configure list --profile prod

第二個命令可讓你看到 CLI 目前將用哪些設定來源。它的價值在於：當你覺得「怎麼可能錯」的時候，這個確認能快速揭穿問題。

5.2 用 region 避免“跨區誤操作”

多賬戶之外，跨 region 也是常見坑。你的資源可能在 us-east-1，但你默認在 ap-northeast-1；你可能在錯的區查不到資源，然後用其他命令去嘗試，最後反而在錯區建立了新資源。

所以：

• 在每個 profile 裡都寫清楚 region。

• 不要把 region 依賴於記憶或偶然配置。

5.3 對敏感操作加一道“預演”

對於可能刪除、覆寫、擴縮容、或改動安全策略的操作，建議先查詢再執行，或先用 dry-run 機制（若該服務支援）。即便你已經切換正確賬戶，資源層級仍可能選錯。

例如部署前先列出目標叢集或目標版本；刪除前先確認資源 ID 與標籤。這看似多一步，但它能在事故前替你止血。

第六章：常見錯誤與排查路徑（真正在坑裡學會）

多賬戶 CLI 工作流最可怕的地方不是你一開始就完全錯掉，而是你在某個命令上“差不多”。差一點的錯，往往最難察覺。

6.1 AccessDenied：先看“你以為的權限”是否真的在

遇到 AccessDenied，你的排查順序建議是：

1. 確認 profile：aws sts get-caller-identity --profile XXX

2. AWS國際企業帳號

   確認 region：是否與資源所在 region 一致

3. 確認角色是否真的被 assume：CloudTrail 或 STS 輸出中的 Arn 應該符合預期角色

4. 檢查策略：該權限可能缺在角色本身，或缺在條件（Condition）上

很多時候你會發現：你以為你在 prod 角色，但其實 profile 沒切成功；或你 assume 到的是另一個角色，導致權限不同。

6.2 ExpiredToken：臨時憑證快用完了

臨時憑證到期後，CLI 會報 ExpiredToken。這通常不是配置壞了，而是你的會話太久。

解決方式通常是重新假設角色（你重新執行帶 profile 的命令，CLI 會自動 refresh）；如果你的流程依賴某種外部 login（例如 SSO），則要確保已重新登入。

6.3 認不出 profile 或找不到配置

如果你輸入 --profile dev 但 CLI 顯示找不到 profile，優先檢查：

• ~/.aws/config 或 ~/.aws/credentials 是否真的存在對應段落

• 你目前的使用者主目錄是否跟你以為的一致

• 是否在容器或遠端機器上跑，但你看的檔案其實是本機

6.4 configure 來源混亂：環境變數在作怪

當你覺得 profile 明明寫了，但 CLI 行為卻跟預期不同，常見原因是：

• AWS國際企業帳號 shell 裡設了 AWS_PROFILE

• 或設了 AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY

• 或你用的是不同的 AWS_CONFIG_FILE / AWS_SHARED_CREDENTIALS_FILE

這時最有效的是用 aws configure list 直接看 CLI 採用的來源。你會很快理解問題在哪。

第七章：多賬戶日常工作流模板（你可以照抄）

下面給一套你可以直接套用的節奏。目標是：每一次切換都可驗證，每一次執行都可追蹤。

7.1 初始化一次：profile 與 base

先設定 base（用來 assume-role 的來源），再設定每個目標 profile 的 role_arn。

~/.aws/credentials
[base]
aws_access_key_id=...
aws_secret_access_key=...

~/.aws/config
[profile dev]
region=ap-northeast-1
role_arn=arn:aws:iam::111111111111:role/DeveloperRole
source_profile=base

[profile prod]
region=ap-northeast-1
role_arn=arn:aws:iam::222222222222:role/OperatorRole
source_profile=base

7.2 每天使用：兩步確認 + 一次操作

aws sts get-caller-identity --profile prod
aws configure list --profile prod

# 之後再做真正操作，例如查服務
aws s3 ls --profile prod

當你要做變更操作時，再多一道查詢步（例如先列資源，再刪除或更新）。

AWS國際企業帳號 7.3 需要在 dev / prod 之間切換

# 切到 dev
aws sts get-caller-identity --profile dev

# 切到 prod
aws sts get-caller-identity --profile prod

如果你常切換，也可以使用 alias，但建議保守：只做「縮短輸入」，不要把行為藏起來。至少要讓你一眼看出目前 profile 是什麼。

第八章：安全建議與治理思維（讓系統不靠人記憶）

多賬戶 CLI 的便利性很高，但安全不能只靠人的自律。你要把限制寫到系統裡，而不是寫在自己的腦海。

8.1 優先使用角色與臨時憑證

長期密鑰適用範圍要收斂。你可以把 base 控制得更嚴格，例如只允許 assume-role，並且要求 session 時間短、加入 MFA、或限制可假設的角色集合。

AWS國際企業帳號 8.2 限制作用範圍：最小權限與資源條件

在 IAM 角色策略中，盡量使用最小權限（actions 最少、resources 範圍合理），並針對資源加條件。這樣即便你誤操作，損害也不會擴大到不可收拾。

8.3 在命令層面做“可追蹤”

利用 role_session_name，讓 CloudTrail 記錄包含可辨識的會話名稱。再配合你的工作站或工單系統，你就能更快回溯某個動作屬於誰、在什麼時間。

8.4 對憑證檔做權限管理

不要讓憑證檔在多人共享環境中可讀。設定正確的檔案權限，並避免把 ~/.aws/credentials 提交到版本控制。

AWS國際企業帳號 第九章：進階技巧——讓切換更像“按鈕”，而不是“猜測”

當你熟悉了基本 profile 後，還可以做得更貼合你的工作習慣。

9.1 使用腳本封裝切換與確認

如果你每天都要切換並確認，可以寫一個簡單腳本：

• 輸入目標 profile 名稱

• AWS國際企業帳號

  先跑 sts get-caller-identity

• AWS國際企業帳號

  再執行你要的命令

這樣你不用每次手動敲確認命令，卻仍保留“確認步”。

9.2 避免“全域覆蓋”錯誤：慎用 AWS_PROFILE

有些人會在 shell 裡設置 AWS_PROFILE，期待它自動切換。這在單一目標環境很好用，但在多賬戶高頻切換時容易出錯：你開了新終端、設置沒跟上、或你以為你切的是另一個終端。

更穩妥的做法是在命令中顯式指定 --profile，讓行為跟輸入一致。

9.3 同一臺機器上管理多套 AWS 配置

AWS國際企業帳號 如果你同時服務多團隊（例如有不同工作目錄與不同設定來源），可以考慮使用不同的 AWS_CONFIG_FILE / AWS_SHARED_CREDENTIALS_FILE 指向不同檔案。這能避免互相污染。

當然，代價是你要記住你現在指向哪一套檔案。這也是為什麼本文更推薦使用清晰 profile 並在命令中顯式指定。

第十章：把知識收斂成一套“你能持續使用”的規範

學完 CLI 多賬戶切換後，真正重要的是形成規範。規範的目標不是約束你，而是減少事故。

10.1 一句話規則

在任何可能造成影響的命令前，都要確定三件事：賬戶正確、region 正確、profile 明確。

10.2 建議你在團隊內推廣的最小標準

• 每個環境（dev/test/prod）一個 profile，禁止共用同一套設定來打所有賬戶。

• 角色切換優先於長期密鑰；需要權限時才 assume，且憑證有效期短。

• 每次切換新 profile，先用 sts get-caller-identity 確認。

• 對刪除或變更類操作，先查再做，並記錄 session_name。

結語：讓切換變成確定性，讓錯誤變成可控性

AWS CLI 多賬戶配置的難點，並不在於你能不能設定成功，而在於你能不能在日常工作裡保持清楚。當 profile 被設計得合理，當 assume-role 帶來臨時憑證並配合 MFA，你的切換就不再是賭運氣；當你用固定的確認步驟，你的錯誤也就不會突然發生在你最不想看到的時刻。

把流程做成可驗證、可追蹤、可回溯，你就會發現 CLI 不只是工具，而是你在雲端操作的一套可靠控制台。下一次你需要從 dev 切到 prod，或從某個供應商賬戶切到另一個內部賬戶，你不必靠記憶，你只要照著規範走。