AWS 適用於 AWS Control Tower landing zone 的多帳戶策略 - AWS Control Tower
符合 AWS 多帳戶指引建立架構良好環境的指引具有完整多帳戶 OU 結構的 AWS Control Tower 範例關於根

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

AWS 適用於 AWS Control Tower landing zone 的多帳戶策略

AWS Control Tower 客戶經常會尋求有關如何設定 AWS 環境和帳戶的指導，以獲得最佳結果。AWS 建立了一組統一的建議 (稱為多帳戶策略)，以協助您充分利用 AWS 資源，包括 AWS Control Tower landing zone。

基本上，AWS Control Tower 可作為與其他 AWS 服務搭配使用的協調流程層，協助您實作 AWS 帳戶和. AWS AWS Organizations設定 landing zone 後，AWS Control Tower 會繼續協助您跨多個帳戶和工作負載維護公司政策和安全實務。

大多數著陸區隨著時間的推移發展 隨著 AWS Control Tower landing zone 中的組織單位 (OU) 和帳戶數量增加，您可以使用有效地組織工作負載的方式擴展 AWS Control Tower Town 部署。本章提供規範指導，說明如何規劃和設定 AWS Control Tower landing zone，以配合 AWS 多帳戶策略，並隨著時間的推移進行擴充。

如需有關組織單位最佳作法的一般討論，請參閱使用的組織單位最佳做法 AWS Organizations。

AWS 多帳戶策略：最佳做法指南

AWS 架構良好的環境的最佳實務建議您將資源和工作負載分成多個 AWS 帳戶。您可以將 AWS 帳戶視為隔離的資源容器：它們提供工作負載分類，以及在出錯時減少爆炸半徑。

AWS 帳戶的定義

AWS 帳號充當資源容器和資源隔離邊界。

注意

AWS 帳戶與透過聯合或 AWS Identity and Access Management (IAM) 設定的使用者帳戶不同。

更多關於 AWS 帳戶

AWS 帳戶提供隔離資源並遏止 AWS 工作負載安全威脅的功能。帳戶還提供了一種計費機制，以及用於工作負載環境的控管。

AWS 帳戶是為工作負載提供資源容器的主要實作機制。如果您的環境架構良好，則可以有效管理多個 AWS 帳戶，因此可以管理多個工作負載和環境。

AWS Control Tower 設定了架構良好的環境。它依賴 AWS 帳戶以及可協助管理可跨多個帳戶延伸的環境變更。 AWS Organizations

一個結構良好的環境的定義

AWS 將架構良好的環境定義為以 landing zone 開始的環境。

AWS Control Tower 提供自動設定的 landing zone。它會強制執行控制，以確保您環境中的多個帳戶符合企業準則。

landing zone 的定義

landing zone 域是一種雲端環境，提供建議的起點，包括預設帳戶、帳戶結構、網路和安全性配置等。從 landing zone，您可以部署利用您的解決方案和應用程式的工作負載。

建立架構良好環境的指引

結構良好的環境的三個關鍵元件，在以下各節中說明：

  • 多個 AWS 帳戶

  • 多個組織單位 (OU)

  • 精心規劃的結構

使用多個 AWS 帳戶

一個帳戶不足以設置一個架構良好的環境。通過使用多個帳戶，您可以最好地支持您的安全目標和業務流程。以下是使用多帳戶方法的一些好處：

  • 安全性控制 — 應用程式具有不同的安全性設定檔，因此需要不同的控制原則和機制。例如，與稽核員交談並指向託管支付卡產業 (PCI) 工作負載的單一帳戶要容易得多。

  • 隔離 — 帳戶是安全保護的一個單位。帳戶中可能包含潛在風險和安全威脅，而不會影響其他人。因此，安全性需求可能會要求您將帳戶彼此隔離。例如，您的團隊可能具有不同的安全性設定檔。

  • 許多團隊 — 團隊有不同的職責和資源需求。通過設置多個帳戶，團隊不能互相干擾，因為他們可能在使用同一帳戶時。

  • 資料隔離 — 將資料存放區隔離至帳戶，有助於限制可存取資料並可以管理資料存放區的人數。這種隔離有助於防止未經授權暴露高度私密的數據。例如，資料隔離有助於支援符合一般資料保護規範 (GDPR) 的規定。

  • 業務流程 — 業務單位或產品通常具有完全不同的目的和流程。可以建立個人帳戶以滿足特定業務需求。

  • 帳單 — 帳戶是在帳單層級分隔項目的唯一方法，包括轉移費用等項目。多帳戶策略有助於跨業務單位、功能團隊或個別使用者建立個別的可計費項目。

  • AWS 配額分配 — 以每個帳戶為基礎設定配額。將工作負載分隔到不同的帳戶中，可為每個帳戶 (例如專案) 提供明確定義的個別配額。

使用多個組織單位

AWS Control Tower 和其他帳戶協調架構可以跨帳戶界限進行變更。因此，最 AWS 佳做法可解決跨帳戶的變更，這可能會破壞環境或破壞其安全性。在某些情況下，變更可能會影響整體環境，而不是政策。因此，我們建議您至少設定兩個強制性帳戶，即生產和預備帳戶。

此外，出於治理和控制目的， AWS 帳戶通常被分為組織單位（OU）。OU 是專為處理跨多個帳戶執行原則而設計的。

我們的建議是，您至少要使用不同的控制項和原則，建立與生產環境不同的生產前 (或預備) 環境。您可以將生產環境和預備環境建立為個別的 OU，並以個別帳戶計費。此外，您可能會想要設定用於程式碼測試的沙箱 OU。

在您的 landing zone 使用規劃良好的 OU 結構

AWS Control Tower 會自動為您設定部分 OU。隨著您的工作負載和需求隨著時間的推移而擴展，您可以擴展原始的 landing zone 配置以滿足您的需求。

注意

範例中提供的名稱遵循建議的 AWS 命名慣例來設定多帳戶 AWS 環境。您可以在設定 landing zone 域後重新命名 OU，方法是選取 OU 詳細資料頁面上的 [編輯]。

建議

AWS Control Tower 為您設定第一個必要的 OU (安全 OU) 之後，我們建議您在 landing zone 建立一些額外的 OU。

建議您允許 AWS Control Tower 至少建立一個額外的 OU，稱為沙箱 OU。此 OU 適用於您的軟體開發環境。如果您選取了登陸區域，AWS Control Tower 可以在建立 landing zone 期間為您設定沙箱 OU。

您可以自行設定兩個建議的其他 OU：包含共用服務和網路帳戶的基礎結構 OU，以及用來包含生產工作負載的 OU (稱為工作負載 OU)。您可以透過組織單位頁面上的 AWS Control 塔主控台，在您的 landing zone 域新增其他 OU。

除了自動設定的 OU 之外，還建議使用

  • 基礎結構 OU — 包含您的共用服務和網路帳戶。

    注意

    AWS Control Tower 不會為您設定基礎設施 OU。

  • 沙箱 OU — 軟體開發 OU。例如，它可能有固定的支出限制，或者可能沒有連接到生產網絡。

    注意

    AWS Control Tower 建議您設定沙箱 OU，但這是選擇性的。它可以在配置 landing zone 域時自動進行設置。

  • 工作負載 OU — 包含執行工作負載的帳戶。

    注意

    AWS Control Tower 不會為您設定工作負載 OU。

如需詳細資訊，請參閱使用 AWS Control Tower 的生產入門組織。

具有完整多帳戶 OU 結構的 AWS Control Tower 範例

AWS Control Tower 支援巢狀 OU 階層，這表示您可以建立符合組織需求的階層式 OU 結構。您可以建立 AWS Control Tower 環境，以符合 AWS 多帳戶策略指導。

您也可以建置一個更簡單、平整的 OU 結構，該結構的效能良好，並符合 AWS 多帳戶指引。僅僅因為您可以建置階層式 OU 結構，並不代表您必須這麼做。

連結頁面上的圖表顯示已建立更多基礎 OU 和更多其他 OU。這些 OU 可滿足較大部署的額外需求。

在「基礎 OU」欄中，已將兩個 OU 新增至基本結構：

  • Security_Prod OU — 提供安全性原則的唯讀區域，以及中斷安全性稽核區域。

  • 基礎結構 OU — 您可能希望將先前建議的基礎結構 OU 分為兩個 OU：基礎結構 _Test (適用於生產前基礎結構) 和基礎結構 _Prod (適用於生產基礎結構)。

在「其他 OU」區域中，基本結構已新增多個 OU。以下是隨著環境成長而建立的下一個建議 OU：

  • 工作負載 OU — 先前建議但選用的工作負載 OU 已分為兩個 OU：Workloads_Test (適用於生產前工作負載) 和 Workloads_Prod (適用於生產工作負載)。

  • PolicyStaging OU — 可讓系統管理員先測試他們對控制項和原則的變更，然後再完全套用它們。

  • 已暫停的 OU — 為可能已暫時停用的帳戶提供位置。

關於根

根目錄不是 OU。它是管理帳戶以及組織中所有 OU 和帳戶的容器。從概念上講，根包含所有 OU。無法將其刪除。您無法在 AWS Control Tower 內的根層級管理註冊帳戶。而是管理 OU 中的已註冊帳戶。如需有用的圖表，請參閱 AWS Organizations 文件。