examhub .cc 用最有效率的方法，考取最有價值的認證
Vol. I
本篇導覽 約 31 分鐘

多帳戶策略與身份聯合

6,100 字 · 約 31 分鐘閱讀

AWS 的多帳號策略，就是刻意將不同工作負載拆分到多個 AWS 帳號，再透過 AWS Organizations 將這些帳號整合起來，搭配稱為**服務控制政策（SCP）**的護欄、由 AWS Control Tower 自動化部署的 landing zone、透過 AWS IAM Identity Center 集中管理員工登入，以及使用 IAM 角色搭配 AWS STS 的跨帳號存取機制。多帳號聯合身分（Multi-Account Federation）是 SAA-C03 的核心主題，貫穿了企業如何隔離爆炸半徑、大規模套用合規護欄、讓員工一次登入便能存取數十個 AWS 帳號，同時在各處落實最小權限原則。

在 SAA-C03 考試中，多帳號聯合身分屬於任務說明 1.1（「設計安全的 AWS 資源存取」）的核心範疇。你需要區分 IAM 政策與服務控制政策（SCP）的差異、在 IAM Identity Center 與傳統 IAM 使用者之間做出選擇、判斷何時應使用 SAML 2.0 或 OIDC 與企業身分提供者聯合，並為不同情境配對正確的跨帳號 IAM 角色模式。本篇筆記以直白的方式說明每個多帳號聯合身分概念、點出所有常見考試陷阱，並鎖定考試當天需要記住的數字。

什麼是 AWS 多帳號策略？

多帳號策略是 AWS 推薦的做法：將工作負載分散在多個隔離的 AWS 帳號中，而非把所有環境、團隊與合規邊界硬塞進同一個帳號。每個 AWS 帳號本身就是一道硬性的安全與計費邊界——帳號 A 裡的 IAM 政策、資源或 API 呼叫，預設無法存取帳號 B 的任何東西。多帳號聯合身分正是 AWS 為了讓這種隔離切實可行所提供的工具組合：AWS Organizations 將帳號整理成樹狀階層、SCP 對整個階層套用預防性護欄、AWS Control Tower 自動化 landing zone 的建置、IAM Identity Center 提供跨帳號單一登入，而跨帳號 IAM 角色與 AWS RAM 則讓帳號在需要協作時能安全地共用存取權和資源。

SAA-C03 要求你在心態上做一個轉換：從「一個 AWS 帳號加上許多 IAM 使用者」轉變為「多個 AWS 帳號，搭配聯合身分、SCP 護欄，以及短期角色憑證」。只要題目出現「擁有多個業務單位的企業」、「正式環境與非正式環境隔離」、「中央資安團隊」或「員工登入」等描述，幾乎都指向多帳號聯合身分模型。

  • AWS Organizations：將多個 AWS 帳號統整在一個管理帳號（management account）之下、套用政策並整合計費的 AWS 服務。
  • Organizational Unit（OU）：AWS Organizations 內的帳號容器；OU 最多可在根（root）之下巢狀嵌套 5 層。
  • Service Control Policy（SCP）：附加到根、OU 或特定 AWS 帳號的 JSON 政策，用來設定該範圍內所有主體（principal）最大可用的權限。SCP 本身永遠不會直接授予權限。
  • AWS Control Tower：建立在 AWS Organizations 之上的高階 AWS 服務，以固定的最佳實踐方式部署多帳號 landing zone，並內建護欄與帳號工廠（Account Factory）自動化。
  • IAM Identity Center：AWS 的員工 SSO 服務（前身為 AWS SSO），可將使用者聯合到組織內所有 AWS 帳號。
  • 跨帳號 IAM 角色：帳號 B 中的一個 IAM 角色，其信任政策（trust policy）允許帳號 A 的主體呼叫 sts:AssumeRole 以取得短期憑證。
  • AWS Resource Access Manager（RAM）：在不複製資源的前提下，將特定 AWS 資源（子網路、Transit Gateway 連接、License Manager 設定）跨帳號共用的 AWS 服務。
  • 參考資料：https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html

為什麼多帳號聯合身分對 SAA-C03 如此重要

任務 1.1 是 SAA-C03 藍圖中權重最高的資安任務，而多帳號聯合身分又是 AWS 標準答案與直覺答案分歧最大的領域。只熟悉單一帳號 IAM 的考生，看到題目往往會選「在每個帳號建立 IAM 使用者」，但正確答案卻是「透過 IAM Identity Center 進行聯合身分存取」。多帳號聯合身分還與成本優化（任務 4.2，透過跨帳號共用 Savings Plans）、網路（任務 3.4，透過共用 Transit Gateway）和韌性（任務 2.2，透過獨立的正式環境帳號）相互交叉。把多帳號聯合身分搞懂，不只能拿下資安題分，還能帶動多個領域的成績提升。

用台灣人熟悉的方式理解多帳號聯合身分

多帳號聯合身分很抽象。用三個具體類比來加深記憶。

類比一：科學園區的多棟辦公大樓

想像一家公司在科學園區租了好幾棟大樓。每棟大樓就是一個 AWS 帳號：財務部在 A 棟、工程部在 B 棟、行銷部在 C 棟、正式環境在 D 棟、開發沙箱在 E 棟。因為財務和正式環境各自待在獨立的大樓裡，沙箱裡發生的火災不會燒到帳本。這就是多帳號策略帶來的爆炸半徑隔離。

園區管委會就是 AWS Organizations。管委會掌握每棟大樓的名冊、統一收取管理費（整合計費），並可發布全區規定，也就是服務控制政策（SCP）——例如「任何大樓均不得違規排放廢水」。SCP 是管委會貼在公告欄的規定，每棟大樓都必須遵守，大樓裡的任何個別租戶都無法推翻它。

AWS Control Tower 是統包工程公司，交給你一棟已完成水電、消防、警報和標準格局的全新大樓——你不必為每個新帳號從頭打地基。IAM Identity Center 是園區的聯合接待大廳——在大門刷一次員工證，服務人員便帶你前往你有權進入的任何大樓，完全不需要重新換證。跨帳號 IAM 角色是特定大樓的訪客識別證：工程部同仁需要短暫前往財務部處理一件事，向前台借一張訪客證（呼叫 sts:AssumeRole），事情辦完歸還，不留下任何持久存取紀錄。AWS RAM 是共用健身房和停車場——各棟大樓共享基礎設施，不必各自興建。

類比二：連鎖飯店的會員計畫

連鎖飯店完美呈現了員工聯合身分的概念。每間個別飯店是一個 AWS 帳號；集團總部是 AWS Organizations；會員計畫是 IAM Identity Center——你只需加入一次，取得單一會員帳號，之後在集團旗下任何一家飯店都能用同樣的身分辦理入住，不必在每家飯店另開新帳號。入住時，前台給你一張房卡（由 IAM Identity Center 以權限集的形式具現化的 IAM 角色），過了退房時間自動失效。

透過外部 SAML 2.0 或 OIDC 身分提供者聯合（Microsoft Entra ID、Okta、Ping、Google Workspace）就像拿著駕照入住飯店——飯店集團信任公路監理所對身分的認證，確認駕照有效後給你一張房卡。你的房卡（短期 AWS STS 憑證）有時效；你的駕照（企業身分）仍持續由監理所保管。這正是聯合身分之所以能避免長期 AWS 憑證的原因：長期的身分保存在企業 IdP，AWS 只會看到一個以臨時斷言換來的臨時憑證。

類比三：直轄市教育局與轄下各學校

想像一個直轄市的教育局系統。教育局是 AWS Organizations；每所學校是一個 AWS 帳號。教育局可以訂定全市規定（禁菸、強制消防演習）——這就是附加在根或 OU 上的 SCP。各校可以在局規之上針對自己的學生加嚴規定（這是成員帳號內的 IAM 政策），但任何一所學校都不能放寬教育局的規定。如果教育局說「校內 Wi-Fi 禁止連社群媒體」，個別老師的 IAM 政策無論怎麼寫，都不能重新開放這個權限。

AWS Control Tower 是教育局的標準建校範本：預設的教室配置、視聽設備、消防安全、成績系統。在帳號工廠按下「新增學校」，就能得到一個符合規範的 landing zone，而非一塊空地。IAM Identity Center 是全市統一的教職員識別證——一張卡開啟你被分派任教的學校大門，每天下班自動失效，遺失了也不會造成災難性影響。跨帳號角色是代課教師的臨時通行證——A 校老師到 B 校代課一個下午（呼叫 sts:AssumeRole），領一張臨時通行證，代完課離開，不留下任何持久存取記錄。

當 SAA-C03 出現「多個 AWS 帳號」加上「集中登入」，就聯想連鎖飯店會員計畫——答案幾乎一定是 IAM Identity Center 聯合到企業身分提供者。當題目出現 SCP 和一個看似允許某操作的 IAM 政策、使用者卻仍被拒絕，就聯想教育局規定覆蓋學校規定。參考資料：https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html

AWS Organizations——OU、管理帳號與成員帳號

AWS Organizations 是多帳號聯合身分的骨幹，負責將多個 AWS 帳號整理成單一樹狀結構、整合計費，並套用 SCP。

Organizations 的樹狀結構

一個 AWS 組織只有一個根（root）。根之下可建立組織單位（OU）；OU 內再放置 AWS 帳號。OU 最多可在根之下巢狀嵌套 5 層。SAA-C03 常見的典型結構如下：

  • Root
    • Security OU（日誌封存帳號、稽核 / 資安工具帳號）
    • Infrastructure OU（共用網路帳號、共用服務帳號）
    • Workloads OU
      • Production OU（正式環境應用帳號）
      • Non-production OU（開發、測試、預備環境帳號）
    • Sandbox OU（個別開發人員沙箱帳號）

管理帳號 vs 成員帳號

管理帳號（在較舊的文件中有時仍稱為「付款帳號」或「主帳號」）是建立組織的那個帳號。它負責支付整合後的帳單，也是唯一能管理 AWS Organizations 的帳號——包括建立 OU、附加 SCP、邀請或建立成員帳號。成員帳號則是組織內其他所有帳號。重要的是：SCP 不適用於管理帳號的根使用者，這也是 AWS 建議在管理帳號中完全不執行任何工作負載的原因之一，讓它保持為純粹的管理用帳號。

整合計費

組織內的每個帳號都會彙總到同一張月帳單。量折扣（Savings Plans、Reserved Instances、分層資料傳輸定價）適用於整個組織，是一項強大的成本優化槓桿。在 SAA-C03 中，如果題目提到「跨業務單位共用 Savings Plans」，就是在暗示 AWS Organizations 的整合計費。

AWS 的最佳實踐（AWS Well-Architected Framework 與 AWS Organizations 使用者指南均有強調）是：讓管理帳號保持空白，僅用於組織層級的管理。SCP 無法限制管理帳號的根使用者，因此若在管理帳號中執行工作負載，一旦發生資安事件，可能繞過所有護欄，影響整個組織。參考資料：https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices.html

服務控制政策（SCP）——護欄 vs IAM 權限

SCP 是 SAA-C03 中 AWS Organizations 功能裡測試最頻繁的項目。把心智模型建立正確，幾個考試陷阱就會迎刃而解。

SCP 的運作方式

SCP 是與 IAM 政策格式相同的 JSON 政策，但它附加的對象是 AWS Organizations 的實體——根、OU，或特定的 AWS 帳號。SCP 定義了該範圍內任何 IAM 主體（IAM 使用者、IAM 角色，甚至成員帳號的根使用者）最多能行使的權限。SCP 本身永遠不會直接授予權限——它只負責設定上限。一個 API 呼叫要成功，必須同時通過所有適用的 SCP（從根到帳號）的允許，以及成員帳號內的 IAM 政策允許。

SCP 的繼承模式是由上往下取交集：一個帳號的實際最大權限，等於根 SCP、所有中間 OU 的 SCP 與直接附加到帳號的 SCP 三者的交集。在樹狀結構較高層附加一個限制性 SCP，會立即對下方所有帳號生效。

SCP vs IAM 政策——最經典的考試陷阱

陷阱通常長這樣：「一個附加到使用者的 IAM 政策允許 s3:DeleteBucket，但使用者嘗試刪除儲存桶時卻收到明確拒絕錯誤。為什麼？」正確答案是：OU 或帳號層級的 SCP 拒絕了 s3:DeleteBucket，使 IAM 政策的授予被 SCP 靜默地截斷。

反過來同樣成立，而且常被忽略：一個允許 s3:DeleteBucket 的 SCP，本身並不授予任何權限。若成員帳號內沒有對應的 IAM 政策，使用者仍然無法刪除儲存桶。

「附加 SCP 給開發團隊完整管理權限」這類選項是錯的。SCP 只定義外部邊界，實際授予權限仍需依賴成員帳號內的 IAM 政策。另外請記住：SCP 不適用於組織管理帳號的根使用者；套用到帳號的 SCP 也不會限制與 AWS Organizations 本身連結的 AWS 服務。參考資料：https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html

你會在考試中看到的 SCP 範例

SAA-C03 情境中常出現的 SCP 模式：

  • 區域限制：拒絕所有 aws:RequestedRegion 不在允許清單內的動作——用來強制工作負載只能在核准的區域運行。
  • 服務拒絕清單：拒絕所有 iam:*CreateUser 和 iam:*AccessKey* API，強制整個組織改用 IAM Identity Center 而非 IAM 使用者。
  • 資料邊界 SCP：拒絕移除 s3:PutBucketPublicAccessBlock，或拒絕任何未加密的 S3 PutObject。
  • 合規導向 SCP：拒絕 cloudtrail:StopLogging，讓任何成員帳號都無法停用 CloudTrail。

SCP 類型：允許清單 vs 拒絕清單

新組織預設在根附加一個 SCP：FullAWSAccess（全部允許的允許清單）。從這個起點出發，你可以選擇疊加拒絕清單 SCP（大多數組織的首選，因為拒絕是明確的），或將根 SCP 換成只列出允許服務的允許清單（設定門檻較高，但預設姿態更緊）。當 SAA-C03 題目說「封鎖所有帳號中的特定動作」，答案通常是拒絕清單 SCP。

AWS Control Tower——Landing Zone 自動化與護欄

AWS Control Tower 是建立在 AWS Organizations 之上的高階 AWS 服務，負責自動化建置一個符合規範的多帳號 landing zone。

Control Tower 建立了什麼

啟用 Control Tower 時，它會建立：

  • AWS Organizations 組織（若尚未存在）。
  • Security OU，含日誌封存帳號（集中的 CloudTrail + Config S3 日誌）與稽核 / 資安工具帳號（集中的資安儀表板、跨帳號唯讀存取）。
  • Sandbox OU（供開發人員使用的沙箱帳號）。
  • 預先設定好的 AWS IAM Identity Center（員工登入）。
  • 帳號工廠（Account Factory）——一個自助服務入口（以 AWS Service Catalog 為後端），可快速產出已套用標準護欄的新 AWS 帳號。
  • 一組護欄（guardrails）：以 SCP 實作的預防性護欄，以及以 AWS Config 規則實作的偵測性護欄。護欄分為三級：強制（Mandatory）（始終啟用，例如「禁止 S3 儲存桶開放公開寫入」）、強烈建議（Strongly Recommended） 與 選用（Elective）。

Control Tower vs 原始 AWS Organizations

原始 AWS Organizations 提供基本元素——OU、SCP、帳號、整合計費——landing zone 的設計完全由你決定。Control Tower 則是對這些基本元素的固定最佳實踐化、自動化部署，另附預建護欄與帳號工廠。對 SAA-C03 而言，若情境同時出現「landing zone」、「自動化多帳號設定」、「帳號工廠」或「護欄」，答案就是 AWS Control Tower，而非「自己用 Organizations 和 SCP 設計」。

把 AWS Control Tower 想成「內建最佳實踐的 AWS Organizations」。它不取代 AWS Organizations，而是驅動它運作。Control Tower 的護欄底層是 SCP 和 Config 規則，OU 就是 AWS Organizations 的 OU，帳號工廠是 Service Catalog 加上 Organizations 帳號建立。參考資料：https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html

IAM Identity Center（SSO）——跨帳號員工聯合身分

AWS IAM Identity Center 是多帳號 AWS 環境中的員工單一登入服務。AWS 明確建議以它取代在每個帳號中建立 IAM 使用者，SAA-C03 也一致地將它視為員工存取情境的標準答案。

IAM Identity Center 提供什麼

  • 使用者入口網站：每位員工登入一次，即可看到所有被授權的 AWS 帳號與 SaaS 應用程式圖磚。
  • 透過 SAML 2.0 或 OIDC 與外部身分提供者聯合——常見整合包括 Microsoft Entra ID、Okta、Ping、Google Workspace，以及透過 AWS Directory Service 串接的地端 Active Directory。若組織尚無現有 IdP，IAM Identity Center 也可作為獨立目錄使用。
  • 權限集（Permission sets）——可重複使用的範本（受管政策、內嵌政策、權限邊界），IAM Identity Center 會在需要時於目標 AWS 帳號中具現化為 IAM 角色。
  • 帳號指派（Account assignment）——將使用者或群組對應到特定 AWS 帳號的特定權限集。使用者第一次使用該指派時，IAM Identity Center 會自動在目標帳號建立底層的 IAM 角色。
  • AWS CLI v2 的短期憑證：透過 aws sso login，工程師無需在筆電上儲存長期存取金鑰。
  • 屬性型存取控制（ABAC）：透過 SAML 屬性或 SCIM 佈建的使用者屬性傳遞為 session tags。

IAM Identity Center 的聯合身分流程

SAA-C03 情境中的使用者體驗如下：

  1. 員工開啟 IAM Identity Center 入口網站 URL。
  2. IAM Identity Center 將使用者重新導向至企業 IdP（SAML 2.0 或 OIDC）。
  3. 員工在 IdP 完成驗證（含 MFA）。
  4. IdP 回傳 SAML 斷言（或 OIDC token）給 IAM Identity Center。
  5. IAM Identity Center 顯示使用者可進入的所有 AWS 帳號入口。
  6. 使用者點選某帳號圖磚與權限集；IAM Identity Center 呼叫 AWS STS 以承擔（assume）該成員帳號中對應的 IAM 角色，並將短期 session 交給使用者，可於 AWS 管理主控台或 AWS CLI 中使用。

任何涉及「員工登入多個 AWS 帳號」的 SAA-C03 情境，推薦服務都是 IAM Identity Center。「在每個 AWS 帳號建立 IAM 使用者」或「在管理帳號建立一個 IAM 使用者並共用憑證」都是陷阱選項。參考資料：https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html

SAML 2.0 與 OIDC 聯合——將企業 IdP 連接到 AWS

IAM Identity Center 與許多直接整合的底層，都是標準的聯合身分機制：SAML 2.0 和 OIDC。SAA-C03 要求你能辨別兩者。

SAML 2.0 聯合身分

SAML 2.0 是企業聯合身分的標準協定。Microsoft Entra ID、Active Directory Federation Services（AD FS）、Okta、Ping 和地端的 Shibboleth 都支援 SAML。

直接 SAML-to-IAM 聯合（不透過 IAM Identity Center）的設定流程：

  1. 在 AWS IAM 建立 SAML 2.0 身分提供者物件，上傳 IdP 的中繼資料 XML。
  2. 建立一個或多個 IAM 角色，其信任政策信任該 SAML 提供者，並可選擇性地依 SAML 屬性（saml:aud、使用者屬性）進行篩選。
  3. 設定 IdP 在 SAML 斷言中包含 AWS 角色屬性——一個識別 IAM 角色 ARN 與 SAML 提供者 ARN 的字串。
  4. 登入時，IdP 將 SAML 斷言回傳至 AWS 登入端點。
  5. AWS STS 透過 sts:AssumeRoleWithSAML 交換斷言，並回傳與所選 IAM 角色綁定的短期憑證。

OIDC（Web 身分）聯合身分

OIDC（OpenID Connect）是現代、基於 OAuth 2.0 的聯合標準。Google、Apple、Facebook、Amazon、GitHub Actions 和 Kubernetes 服務帳號都支援 OIDC。

直接 OIDC-to-IAM 聯合的運作方式與 SAML 類似，但使用 sts:AssumeRoleWithWebIdentity 和 IAM 中的 OIDC 提供者物件。SAA-C03 最常考的兩個 OIDC 模式：

  • Amazon EKS IRSA（IAM Roles for Service Accounts）——Kubernetes Pod 的服務帳號透過叢集的 OIDC issuer 聯合到 IAM 角色。
  • GitHub Actions / CI 系統——工作流程以短期的 GitHub OIDC token 換取 IAM 角色憑證，無需在 CI 密鑰中存放長期 IAM 存取金鑰。

何時直接聯合，何時透過 IAM Identity Center

若只有單一 AWS 帳號，或是服務對服務的窄範圍模式（EKS IRSA、GitHub Actions），直接聯合到 IAM 即可。若有多個 AWS 帳號且使用者是人工員工，請透過 IAM Identity Center 聯合——它封裝了 SAML/OIDC 的底層機制，統一管理跨帳號的權限集，並提供入口網站體驗。

  • sts:AssumeRole——IAM 主體或 AWS 服務進行同帳號或跨帳號的角色承擔。Session 最長 12 小時，預設 1 小時。
  • sts:AssumeRoleWithSAML——以企業 IdP 的 SAML 2.0 斷言換取短期憑證。Session 最長 12 小時。
  • sts:AssumeRoleWithWebIdentity——以 OIDC token（Cognito、Google、Apple、Facebook、EKS IRSA、GitHub Actions）換取短期憑證。Session 最長 12 小時。
  • sts:GetSessionToken——為 IAM 使用者發行通過 MFA 認證的 session（特殊用途，考試少見）。
  • sts:GetFederationToken——以 IAM 使用者權限為基礎的自訂代理聯合身分（SAA-C03 少見）。
  • 參考資料：https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html

Cognito User Pools vs Identity Pools——驗證與聯合的邊界

Amazon Cognito 是員工聯合身分與客戶應用程式聯合身分的分岔點。SAA-C03 非常喜歡考這個區別。

Cognito User Pools——身分驗證

Cognito 使用者集區（user pool）是為應用程式終端使用者服務的受管使用者目錄，處理註冊、登入、密碼重設、MFA、帳號復原，以及選用的社群媒體 / SAML 登入。使用者集區的輸出是 JWT token（ID token、access token），供應用程式用來驗證 API Gateway 或 AppSync 的呼叫。使用者集區關注的是身分驗證——「這個使用者是誰？」。

Cognito Identity Pools——聯合到 AWS 憑證

Cognito 身分集區（identity pool）接收來自任何支援身分來源的 token——Cognito 使用者集區、SAML IdP、OIDC IdP、Google / Apple / Facebook / Amazon——並將其換取綁定到 IAM 角色的短期 AWS 憑證。身分集區關注的是聯合到 AWS——「這位已驗證的使用者應承擔哪個 IAM 角色，才能直接呼叫 AWS API？」

SAA-C03 的典型模式：一個行動應用程式允許使用者以 Google 登入，然後直接上傳照片到 Amazon S3、並直接將中繼資料寫入 Amazon DynamoDB。應用程式透過 Cognito 使用者集區（或直接以 Google 作為 OIDC IdP）完成登入，再將 token 送至 Cognito 身分集區換取短期 AWS 憑證，而這組憑證對應的 IAM 角色只允許 s3:PutObject（限使用者自己的路徑前綴）和 dynamodb:PutItem（限使用者自己的項目）。

SAA-C03 常見陷阱是選項將「使用者集區」與「身分集區」互換。請記住：使用者集區 = 身分驗證，身分集區 = 聯合到 AWS 憑證。若情境談的是應用程式終端使用者的註冊、登入、MFA 或密碼重設，指的是使用者集區。若談的是讓已驗證的使用者從行動用戶端直接呼叫 AWS API（S3、DynamoDB），還需要身分集區。參考資料：https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html

跨帳號角色切換——Switch-Role 模式

跨帳號角色切換是早於 IAM Identity Center 的經典模式，SAA-C03 仍有考題。情境是：帳號 A 的使用者（或 AWS 服務）需要存取帳號 B 的資源。

跨帳號角色承擔的運作方式

  1. 在帳號 B 建立一個 IAM 角色，賦予任務所需的權限（例如，S3 儲存桶的唯讀存取）。
  2. 為該角色附加一個信任政策，其 Principal 指定帳號 A（整個帳號，或帳號 A 內的特定 IAM 使用者或角色）。信任政策是 IAM 角色本身的資源型政策。
  3. 在帳號 A 中，給呼叫端 IAM 主體（IAM 使用者、IAM 角色，或 IAM Identity Center 權限集）一個 IAM 政策，允許對帳號 B 的角色 ARN 執行 sts:AssumeRole。
  4. 帳號 A 的主體呼叫 sts:AssumeRole，取得短期憑證——存取金鑰 ID、私密存取金鑰、session token——有效期最長 12 小時。
  5. 使用這組憑證，該主體可在帳號 B 中呼叫 AWS API，如同自己是帳號 B 的主體一般。

第三方存取的 ExternalId

當第三方（例如 SaaS 資安廠商）需要承擔你 AWS 帳號內的角色時，AWS 建議在信任政策中要求 ExternalId——一個呼叫端在呼叫 sts:AssumeRole 時必須提供的共享密鑰。這可以緩解**混淆代理人（confused deputy）**問題：防止同一 SaaS 的其他客戶騙該 SaaS 代入錯誤客戶的角色。

AWS 管理主控台的 Switch Role 功能

主控台內建 Switch Role 介面。IAM Identity Center 使用者或 IAM 使用者可透過提供目標帳號 ID 和角色名稱，切換到另一個 AWS 帳號的角色。主控台會儲存最近五個使用過的角色，方便快速切換。在 CLI 端，工程師通常會將跨帳號角色寫入 ~/.aws/config 的設定檔，並使用 aws --profile prod 呼叫。

IAM Identity Center vs 手動跨帳號角色

對於員工跨多帳號的存取，IAM Identity Center 是現代化的替代方案——它在底層以權限集的形式管理跨帳號角色。對於服務對服務或合作夥伴對你的存取，手動跨帳號角色模式仍是正確答案。

跨帳號 IAM 角色承擔需要兩側都到位：目標帳號 B 的信任政策必須將帳號 A 列為受信任的主體，且帳號 A 的 IAM 政策必須允許對目標角色 ARN 執行 sts:AssumeRole。任何一側缺失，AssumeRole 呼叫都會失敗。參考資料：https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html

AWS Resource Access Manager（RAM）——跨帳號資源共用

有些資源不需要以角色為基礎的跨帳號存取，而是需要被共用，讓多個 AWS 帳號直接使用同一個資源。AWS Resource Access Manager（AWS RAM）就是為此而生的服務。

RAM 可共用的資源

AWS RAM 可以將一份不斷增長的 AWS 資源清單共用給其他 AWS 帳號，或 AWS Organizations 內的整個 OU：

  • VPC 子網路——中央網路帳號擁有一個 VPC，各工作負載帳號可在共用的子網路中啟動 EC2 執行個體、Lambda ENI 或 RDS。
  • AWS Transit Gateway——將多個帳號的多個 VPC 連接到同一個共用的 Transit Gateway。
  • AWS License Manager 設定。
  • Route 53 Resolver 規則 與 Outposts。
  • Amazon Aurora 叢集（跨帳號讀取）。
  • 還有更多——清單持續增加中。

RAM vs 跨帳號 IAM 角色 vs VPC Peering

這個區別很容易被忽略。三種模式，三種不同工具：

  • 跨帳號 IAM 角色——帳號 A 的主體在帳號 B 中呼叫 AWS API；資源仍留在帳號 B。
  • AWS RAM——帳號 A 擁有的資源共用到帳號 B，讓帳號 B 可以原生使用，無需每次都承擔角色。
  • VPC Peering / Transit Gateway——兩個 VPC 之間建立網路連線。Peering 適用兩個 VPC；Transit Gateway 是多個帳號、多個 VPC 的中樞，常透過 RAM 共用。

SAA-C03 的經典情境是：「中央網路團隊想擁有 VPC，並讓其他業務單位帳號在同一 VPC 的子網路中啟動工作負載。應使用什麼？」答案是 AWS RAM 共用子網路，而非跨帳號角色，也非 VPC Peering。

若題目問的是在 AWS 帳號之間共用一項 AWS 基礎設施（子網路、Transit Gateway、License Manager 設定），答案是 AWS RAM。若問的是讓帳號 A 的主體在帳號 B 執行 API 操作，答案是跨帳號 IAM 角色。參考資料：https://docs.aws.amazon.com/ram/latest/userguide/what-is.html

何時使用聯合身分，何時使用 IAM 使用者

SAA-C03 經常要求你為情境選擇正確的身分建構。以下是決策框架：

  • 員工、約聘人員，跨一個或多個 AWS 帳號 → IAM Identity Center，聯合到企業 IdP。正式環境中切勿為每位員工建立 IAM 使用者。
  • 你的 SaaS 產品的應用程式終端使用者 → Amazon Cognito 使用者集區（若需要直接呼叫 AWS API，還要加上身分集區）。
  • AWS 服務承擔身分（EC2 存取 S3、Lambda 存取 DynamoDB、ECS 任務存取 SQS）→ 附加到服務的 IAM 角色（執行個體設定檔、執行角色、任務角色）。切勿在 EC2 執行個體上存放長期存取金鑰。
  • 你自己的 AWS 帳號之間的跨帳號存取 → 透過 sts:AssumeRole 承擔的跨帳號 IAM 角色。若屬於員工使用情境，請考慮使用 IAM Identity Center 權限集。
  • 第三方 / SaaS 合作夥伴存取你的 AWS 帳號 → 跨帳號 IAM 角色，信任政策中帶有 ExternalId。
  • CI/CD 管線（GitHub Actions、GitLab CI） → 透過 sts:AssumeRoleWithWebIdentity 聯合到 IAM 角色的 OIDC 聯合身分。CI 密鑰中不存放長期存取金鑰。
  • 無法承擔角色的地端伺服器 → 優先使用 IAM Roles Anywhere（以 X.509 憑證為基礎發行短期憑證）；IAM 使用者存取金鑰是最後手段。

在現代 AWS 環境中，建立長期 IAM 使用者應是罕見的例外。大多數 SAA-C03「正確」答案在有替代方案時都會避免使用 IAM 使用者。

多帳號 vs 單一帳號——設計取捨

SAA-C03 有時會要求你論證或質疑多帳號設計。請熟悉以下取捨：

多帳號的優勢

  • 硬性安全邊界——某帳號遭入侵，預設無法存取其他帳號的資源。
  • 爆炸半徑隔離——帳號 A 的 Lambda 失控、S3 遞迴循環或帳單爆增，不影響帳號 B。
  • 服務配額隔離——每個 AWS 帳號有各自的服務配額；多帳號可突破單帳號的限制上限。
  • 按帳號歸因成本——每個業務單位看到自己的 AWS 帳單，標籤（tagging）更簡單，費用回沖（chargeback）輕而易舉。
  • 合規分區——PCI 工作負載放在 PCI 範疇帳號、HIPAA 放在 HIPAA 範疇帳號、開發放在沙箱帳號。
  • SCP 驅動的合規——預防性護欄在整個組織範圍內強制執行。

多帳號的成本與複雜度

  • 更多初始設定——需要 AWS Organizations、Control Tower、IAM Identity Center、網路策略（Transit Gateway + RAM）和日誌策略。
  • 跨帳號網路——不同帳號的工作負載往往需要互相通訊，這意味著需要 VPC Peering、Transit Gateway 或 PrivateLink。
  • 跨帳號資料共用——S3 儲存桶政策、KMS 金鑰政策和資源型政策都需要為跨帳號存取另行設定。
  • 較高的最低營運成本——規模極小時，單帳號架構更簡單。當有多個團隊、多個環境或多個合規邊界時，多帳號才真正值回票價。

對 SAA-C03 而言，一旦情境出現「業務單位」、「正式環境隔離」、「合規」或「中央資安團隊」，正確答案幾乎總是多帳號。

多帳號聯合身分的關鍵數字

考試通常會有一到兩題直接考這些數字，請務必記住。

  • AWS Organizations：一個管理帳號、多個成員帳號。OU 最多可在根之下巢狀嵌套 5 層。
  • SCP 可附加到根、OU 或個別 AWS 帳號。評估方式為由上往下取交集——帳號的實際有效權限是從根到帳號每層 SCP 的交集，再與成員帳號內的 IAM 政策取交集。
  • SCP 不適用於管理帳號的根使用者。
  • SCP 不授予權限——只設上限。
  • 新組織的預設值：根附加一個 SCP：FullAWSAccess（全部允許）。你可在此之上疊加拒絕清單 SCP，或改用允許清單 SCP 取代。
  • sts:AssumeRole 的 IAM 角色 session 時長：預設 1 小時，最長 12 小時（可依角色設定）。
  • sts:AssumeRoleWithSAML 的 SAML 斷言 session：最長 12 小時。
  • sts:AssumeRoleWithWebIdentity 的 OIDC / Web 身分 session：最長 12 小時。
  • AWS IAM 是全域服務；AWS Organizations、IAM Identity Center 和 STS 也是全域服務（STS 有區域端點可降低延遲）。
  • IAM Identity Center 本身免費；你只需為使用者存取的 AWS 服務付費，而非 IAM Identity Center 本身。
  • AWS Control Tower 護欄分三種：強制（Mandatory）（始終啟用）、強烈建議（Strongly Recommended）、選用（Elective）。
  • AWS RAM 本身免費；你只需為底層共用資源付費（例如 Transit Gateway 連接費用）。
  • 參考資料：https://docs.aws.amazon.com/organizations/latest/userguide/orgs_reference_limits.html

常見考試陷阱——多帳號聯合身分

陷阱一：SCP vs IAM 政策

「IAM 政策允許 s3:*，為什麼使用者還是無法刪除儲存桶？」因為 AWS Organizations 中更上層的 SCP 拒絕了 s3:DeleteBucket。請記住，SCP 只設上限、不授予；允許某動作的 SCP 本身也不授予任何權限。

陷阱二：IAM Identity Center vs 每帳號建立 IAM 使用者

若情境說「員工需要登入多個 AWS 帳號」，答案是 IAM Identity Center，而非「在每個帳號建立 IAM 使用者並共用」。每帳號建立 IAM 使用者是 SAA-C03 的典型錯誤選項。

陷阱三：Cognito 使用者集區 vs 身分集區

使用者集區 = 終端使用者身分驗證。身分集區 = 聯合到短期 AWS 憑證。陷阱在於情境說「行動應用程式使用者直接上傳到 S3」——這時兩者都需要，或使用者集區 + 身分集區串接（或身分集區直接聯合 Google / Apple / Facebook）。

陷阱四：SAML vs OIDC

SAML 2.0 = 企業員工 IdP（Entra ID、ADFS、Okta、Ping）。OIDC = 現代應用程式 / CI / Kubernetes 聯合（Google、Apple、Amazon Cognito 使用者集區、GitHub Actions、EKS IRSA）。若情境說「企業員工 SSO」，答案是 SAML（通常透過 IAM Identity Center）。若說「行動社群媒體登入」或「GitHub Actions CI」，答案是 OIDC。

陷阱五：管理帳號中執行工作負載

若情境顯示工作負載在組織的管理帳號中執行，這是不良實踐的設定——管理帳號應保持輕量。SAA-C03 的答案通常是「將工作負載遷移到專屬的成員帳號」，以及／或「對工作負載的 OU 套用 SCP」。

陷阱六：跨帳號角色需要雙向設定

跨帳號 IAM 角色承擔失敗，通常是因為目標帳號的信任政策沒有將呼叫端列為受信任主體，或者呼叫端的 IAM 政策沒有允許對目標角色 ARN 執行 sts:AssumeRole。任一側缺失都會導致失敗。

陷阱七：RAM vs 跨帳號角色 vs VPC Peering

將 AWS 資源（子網路、Transit Gateway）共用到另一個帳號是 AWS RAM，而非跨帳號角色，也非 VPC Peering。能否辨識 RAM 的適用情境，是 SAA-C03 常見的鑑別點。

陷阱八：AWS Control Tower vs 原始 AWS Organizations

若情境說「自動化 landing zone」、「帳號工廠」或「預建護欄」，答案是 AWS Control Tower。若只提到「將帳號整理成 OU 並套用 SCP」，原始 AWS Organizations 就已足夠。

多帳號聯合身分 vs 單帳號 IAM——範疇邊界

多帳號聯合身分與單帳號 IAM 身分管理（相關主題：iam-identity-access-control）有所重疊，但各有明確的範疇。單帳號 IAM（iam-identity-access-control 主題）關注的是單一 AWS 帳號內的 IAM 使用者、IAM 角色、IAM 政策與政策評估——底層的基本元素。多帳號聯合身分（本主題）關注的是如何將多個帳號串接起來——AWS Organizations、SCP、Control Tower、IAM Identity Center、跨帳號角色、RAM。任務 1.1 要求你理解兩者，SAA-C03 題目往往需要結合運用（例如「使用 IAM Identity Center 加上 SCP，限制開發人員只能存取非正式環境帳號」）。

練習題情境——多帳號聯合身分場景

  • 「一家公司有 20 個 AWS 帳號，希望員工只需登入一次就能以最小權限存取所有帳號。應使用哪種服務？」→ AWS IAM Identity Center，聯合到企業 SAML 2.0 身分提供者。
  • 「中央資安團隊希望防止組織內任何 AWS 帳號停用 AWS CloudTrail。應使用什麼？」→ 服務控制政策（SCP），附加在根或適當的 OU，拒絕 cloudtrail:StopLogging 與 cloudtrail:DeleteTrail。
  • 「一家公司希望自動建立新的 AWS 帳號，並套用標準護欄與集中日誌帳號。應使用哪種服務？」→ AWS Control Tower，搭配其帳號工廠與強制護欄。
  • 「中央網路帳號擁有一個 VPC，希望讓多個業務單位帳號在同一 VPC 子網路中啟動 EC2。應使用什麼？」→ AWS Resource Access Manager（AWS RAM），將 VPC 子網路共用給目標 AWS 帳號。
  • 「第三方 SaaS 廠商需要對客戶 AWS 帳號的唯讀存取。最安全的模式是什麼？」→ 在客戶帳號建立跨帳號 IAM 角色，以廠商的 AWS 帳號作為受信任主體，並在信任政策中加入 ExternalId 條件。
  • 「GitHub Actions 需要部署到 AWS 但不能使用長期存取金鑰。應如何設定？」→ 在 IAM 建立指向 GitHub issuer 的 OIDC 身分提供者，再建立一個 IAM 角色，透過 sts:AssumeRoleWithWebIdentity 承擔。
  • 「一個行動應用程式讓使用者以 Google 登入，並需要直接上傳照片到 Amazon S3。應使用哪些服務？」→ Amazon Cognito 身分集區，聯合到 Google（或聯合到已整合 Google 的 Cognito 使用者集區），將 token 換取限縮在使用者自己 S3 路徑前綴的短期 IAM 角色憑證。

FAQ——多帳號與聯合身分存取熱門問題

Q1：AWS Organizations 和 AWS Control Tower 有什麼差別？

AWS Organizations 提供的是基本元素：根、OU、成員帳號、整合計費和 SCP，landing zone 的設計完全由你決定。AWS Control Tower 是在 AWS Organizations 之上建立的固定最佳實踐、自動化部署層，包含完整的多帳號 landing zone——資安與稽核帳號、集中的 CloudTrail 和 Config 日誌、IAM Identity Center，以及以 SCP 和 AWS Config 規則實作的預建護欄（強制、強烈建議、選用三種等級）。若想自行設計結構，使用 AWS Organizations；若想在一個下午就得到符合規範的 landing zone，使用 AWS Control Tower。在 SAA-C03 中，「自動化 landing zone」和「帳號工廠」幾乎一定指向 AWS Control Tower。

Q2：SCP 和 IAM 政策有什麼差別？

SCP 是附加在根、OU 或帳號上的 AWS Organizations 政策，定義了該範圍內任何主體最多能行使的權限。附加在成員帳號內 IAM 使用者、群組或角色上的 IAM 政策，負責授予權限。API 呼叫要成功，必須同時通過——從根到帳號每層的 SCP，以及成員帳號內的 IAM 政策。SCP 只設上限、不授予；IAM 政策才授予（或明確拒絕）。常見的考試陷阱是「附加 SCP 給開發團隊管理員存取權」——這是錯的，SCP 無法授予權限。

Q3：什麼時候應該使用 IAM Identity Center，而非直接 SAML 聯合到 IAM？

對於多帳號員工存取，請一律優先選擇 IAM Identity Center。它封裝了 SAML / OIDC 聯合的底層機制，並新增了權限集、帳號入口網站、跨帳號 IAM 角色的自動佈建，以及 AWS CLI v2 整合。直接 SAML-to-IAM 聯合（在 IAM 中建立 SAML 提供者物件並手動設定 IAM 角色）對於窄範圍單帳號用途或舊有設定仍然有效。在 SAA-C03 中，若情境說「多個 AWS 帳號」加上「員工登入」，IAM Identity Center 就是答案。

Q4：讓 CI/CD 管線（GitHub Actions）部署到 AWS，正確做法是什麼？

在 AWS IAM 設定一個 OIDC 身分提供者，指向 GitHub 的 issuer（https://token.actions.githubusercontent.com）。建立一個 IAM 角色，其信任政策信任該 OIDC 提供者，並以 sub 宣告篩選到特定的 GitHub 儲存庫和分支。在 GitHub Actions 工作流程中，使用 aws-actions/configure-aws-credentials 呼叫 sts:AssumeRoleWithWebIdentity，以短期的 GitHub OIDC token 換取短期 AWS 憑證。如此一來，GitHub 密鑰中永遠不需要存放長期存取金鑰。同樣的模式也適用於 GitLab CI、CircleCI 和其他支援 OIDC 的 CI 系統。

Q5：跨帳號 IAM 角色是什麼？sts:AssumeRole 如何運作？

跨帳號 IAM 角色是 AWS 帳號 B 中的一個 IAM 角色，其信任政策將帳號 A 的某個實體（整個帳號，或特定使用者或角色）列為受信任的主體。帳號 A 的呼叫端必須擁有一個 IAM 政策，允許對該角色的 ARN 執行 sts:AssumeRole。呼叫端執行 sts:AssumeRole 後，AWS STS 回傳短期憑證（存取金鑰 ID、私密存取金鑰、session token），有效期最長 12 小時。呼叫端接著使用這組憑證在帳號 B 中呼叫 AWS API。這是跨帳號存取的標準模式，適用於非人工員工的呼叫端（員工的跨帳號存取請改用 IAM Identity Center 權限集）。

Q6：AWS RAM 能做到跨帳號 IAM 角色做不到的事？

AWS Resource Access Manager 負責將特定 AWS 資源（VPC 子網路、Transit Gateway 連接、License Manager 設定、Route 53 Resolver 規則、Aurora 叢集等）跨帳號共用。共用的資源在實體上仍由一個 AWS 帳號擁有，但其他帳號可以原生使用——在共用子網路啟動 EC2、連接 VPC 到共用的 Transit Gateway——無需為每次 API 呼叫承擔跨帳號角色。跨帳號 IAM 角色的核心是讓主體在另一帳號執行 API 操作；AWS RAM 的核心是讓另一帳號像使用本地資源一樣消費共用資源。

Q7：我應該在 AWS Organizations 的管理帳號中執行任何工作負載嗎？

不應該。AWS 最佳實踐是讓管理帳號保持不含工作負載的乾淨狀態。管理帳號是唯一能管理 AWS Organizations（建立 OU、附加 SCP、邀請成員）的帳號，且其根使用者不受 SCP 的有意義限制。若在此執行工作負載，一旦帳號遭到入侵，可能危及整個組織的護欄設定。管理帳號僅用於 AWS Organizations 管理與整合計費，工作負載請部署到適當 OU 下的專屬成員帳號（Workloads/Production、Workloads/Non-production、Sandbox 等）。

Q8：如何跨所有帳號限制 AWS 工作負載只能在特定區域運行？

在 AWS Organizations 的根（或 OU）附加一個 SCP，拒絕所有 aws:RequestedRegion 不在允許清單內的動作。例如，拒絕所有動作，除非區域是 us-east-1 或 eu-west-1。由於 SCP 設定了 IAM 政策授予的上限，無論成員帳號的 IAM 政策多寬鬆，都無法在不允許的區域啟動或操作工作負載。請在 SCP 條件中豁免全域服務（IAM、CloudFront、AWS Organizations 本身），因為它們沒有區域情境。這是 SAA-C03「如何在整個組織強制執行資料主權，只使用核准區域」的常見標準答案。

Q9：Amazon Cognito 使用者集區和身分集區有什麼差別？

Cognito 使用者集區是應用程式的受管使用者目錄，負責註冊、登入、密碼重設、MFA，以及選用的社群媒體和 SAML 聯合。使用者集區的輸出是 JWT token，供應用程式用於驗證。Cognito 身分集區接受任何支援的 token（來自使用者集區、SAML IdP、Google、Apple、Facebook、Amazon），並將其換取綁定到 IAM 角色的短期 AWS 憑證，讓已驗證的使用者能直接呼叫 AWS API（如 S3 和 DynamoDB）。使用者集區 = 身分驗證；身分集區 = 聯合到 AWS 憑證。許多行動應用程式情境需要兩者兼備：使用者集區負責登入，身分集區負責取得 AWS 憑證。

延伸閱讀

官方資料來源