前兩天談的是面對需求時，如何確認條件並選擇服務，不過，隨著系統和專案增加，架構問題不只是哪個服務比較適合，還會開始遇到另一件事：如果公司有不只一個 AWS 帳號，這些帳號要怎麼一起管理？

很多環境並不是一開始就規劃成多帳號，第一套系統上線時，可能只有一個 AWS 帳號；後來因為新增專案、正式環境需要獨立管理，或不同客戶要求使用各自的帳號，才逐漸出現第二、第三個帳號。

如果每個帳號都各自管理，帳號聯絡資訊、付款方式、IAM 權限、CloudTrail、AWS Config 與安全服務設定很容易不一致，管理者也需要分別登入不同帳號，才能確認資源、帳單與安全狀態。

AWS Organizations 就是用來處理這類跨帳號管理問題的服務。

先把帳號放進同一個 Organization

建立 AWS Organizations 後，原本的帳號會成為 Management account，再透過 Organizations 建立新帳號，或邀請既有帳號加入，成為 member accounts。

Management account 可以集中管理帳號生命週期、組織政策、AWS 服務整合與帳單，各 member account 仍保有自己的資源、IAM 與服務設定，不會因為加入 Organization 就變成同一個帳號。

帳號加入後會先位於 Organization 的 Root，當帳號數量增加，就可以建立 Organizational Unit（OU），把需要相同治理方式的帳號放在一起。

例如，正式環境可能需要限制可用 Region，測試環境則允許使用更多服務；安全或共用基礎設施帳號，也可能需要和一般工作負載分開管理，這時可以依治理需求建立不同 OU，而不是對每個帳號分別設定相同政策。

OU 不只是整理帳號的資料夾

Organizations 的政策可以套用在 Root、OU 或個別帳號上，套用在上層的政策會由底下的 OU 與帳號繼承。

其中，**Service Control Policy（SCP）**可以限制 member accounts 最多能取得哪些權限。例如，在正式環境所在的 OU 禁止使用未核准的 Region，或禁止成員帳號自行離開 Organization。

不過，SCP 本身不會授予權限。即使 SCP 沒有禁止建立 EC2，使用者仍然需要 IAM Policy 的 Allow 才能操作；反過來說，只要 SCP 明確 Deny，帳號內的 IAM administrator 也無法自行放寬限制。

另外，SCP 不會套用到 Management account，因此一般系統不適合直接部署在這個帳號裡，Management account 應盡量只處理組織層級的管理工作，並限制可以登入的人員。

除了政策，還能集中哪些事情？

Organizations 會把所有 member accounts 的費用整合成一份帳單，同時保留各帳號的成本明細，管理者不需要分別處理多份 AWS 帳單，也能看出各專案或環境產生多少費用。

部分 AWS 服務也能與 Organizations 整合。例如，可以建立 CloudTrail（a trail for an organization），統一記錄所有 member accounts 的操作；GuardDuty、Security Hub 與 AWS Config 等服務，則能將組織管理權限委派給指定的 member account。

這種 delegated administrator 機制可以把安全服務交給專用帳號管理，不需要所有管理工作都集中在權限最高的 Management account。

如果目前確定只有一個 AWS 帳號，也沒有獨立帳單、跨帳號安全管理或環境隔離需求，不一定需要為了使用 Organizations 而強行拆分帳號，Organizations 真正開始發揮作用的時機，是帳號數量逐漸增加，或公司需要對多個帳號套用一致的政策、日誌與安全設定。

不過，Organizations 提供的主要是組織階層與治理機制，它不會自動替我們建立安全帳號、集中日誌帳號，也不會自動完成所有帳號的基礎設定。

下一篇會接著看 AWS Control Tower 如何建立 Landing Zone，並在 Organizations 之上準備多帳號環境需要的基礎結構與 Controls。