本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 在 AWS Control Tower 中佈建和管理帳戶 本章包含： + 在 AWS Control Tower 中佈建和管理新成員帳戶的概觀和程序。 + 將現有 AWS 帳戶註冊到 AWS Control Tower 的概觀和程序。 如需 AWS Control Tower 中帳戶的一般資訊，請參閱 [關於 AWS Control Tower AWS 帳戶 中的](accounts.md)。如需在 AWS Control Tower 中註冊多個帳戶的資訊，請參閱 [向 AWS Control Tower 註冊現有的組織單位](importing-existing.md)。 **注意** 單一帳戶佈建、更新和自訂必須以啟用 AWSControlTowerBaseline 的組織單位 (OU) 為目標。如果 OU 未啟用 AWSControlTowerBaseline，您可以啟用帳戶自動註冊，或在 EnabledBaselines 上使用 ResetEnabledBaseline 和 ResetEnabledControl APIs並在該 OU 上使用 EnabledControls 來註冊帳戶。如需 AWSControlTowerBaseline 的詳細資訊，請參閱：[在 OU 層級套用的基準類型](types-of-baselines.md#ou-baseline-types)。 **注意** 您可以同時執行最多五 (5) 個與帳戶相關的操作，包括佈建、更新和註冊。 ## 佈建帳戶所需的許可 使用適當的使用者群組許可，佈建器可以為其組織中的任何帳戶指定標準化基準和網路組態。 當您使用 Account Factory 從 AWS Control Tower 主控台建立帳戶時，您必須使用已啟用`AWSServiceCatalogEndUserFullAccess`政策的 IAM 使用者登入帳戶，以及使用 AWS Control Tower 主控台的許可，而且您無法以**根**使用者身分登入。 **注意** 佈建帳戶時，帳戶請求者一律必須擁有 `CreateAccount`和 `DescribeCreateAccountStatus`許可。此許可集是 **Admin** 角色的一部分，當申請者擔任 **Admin** 角色時會自動提供。如果您委派佈建帳戶的許可，您可能需要直接為帳戶請求者新增這些許可。 如需 AWS Control Tower 中所需許可的一般資訊，請參閱 [針對 AWS Control Tower 使用身分型政策 (IAM 政策）](access-control-managing-permissions.md)。如需 AWS Control Tower 中角色和帳戶的相關資訊，請參閱[角色和帳戶](https://docs.aws.amazon.com//controltower/latest/userguide/roles.html)。 # 在 AWS Control Tower 內佈建帳戶 AWS Control Tower 提供多種方法來建立和更新成員帳戶。有些方法主要以主控台為基礎，有些方法主要是自動化的。 **概觀** 在 AWS Control Tower 中建立成員帳戶的一種標準方法是透過 Account Factory，這是一種屬於 Service Catalog 的主控台型產品。此外，在 AWS Control Tower 主控台中，如果您的登陸區域未處於偏離狀態，您可以使用**建立帳戶**作為佈建新帳戶的方法，以及**註冊帳戶**以將現有 AWS 帳戶註冊到 AWS Control Tower。 透過 Account Factory，您可以根據 AWS Control Tower 預設設定來佈建基本帳戶。您也可以佈建符合特殊使用案例需求的*自訂*帳戶。 [Account Factory Customization (AFC)](https://docs.aws.amazon.com//controltower/latest/userguide/af-customization-page.html) 是一種從 AWS Control Tower 主控台佈建自訂帳戶的方式，可自動化帳戶的自訂和部署。它允許在一些一次性設定步驟之後以主控台為基礎的自動佈建，這樣就不需要編寫指令碼或設定管道。如需詳細資訊，請參閱[使用帳戶工廠自訂 (AFC) 自訂帳戶](af-customization-page.md)。 **自動註冊** 如果您選擇加入登陸區域**設定的****自動帳戶註冊**功能，您也可以在 AWS Control Tower AWS 帳戶 *外部*建立 AWS Control Tower，並將它們移至向 AWS Control Tower 註冊的 OU，而無需建立繼承偏離。如需詳細資訊，請參閱[使用自動註冊來移動和註冊帳戶](account-auto-enrollment.md)。 **主控台型方法：** + 透過屬於基本或自訂帳戶一部分的 Account Factory AWS Service Catalog主控台。檢閱 [使用 Account Factory 佈建和管理帳戶](account-factory.md) 以取得詳細資訊和指示。 + 透過自動註冊，將帳戶從主控台移至 OU。請參閱 [使用自動註冊來移動和註冊帳戶](account-auto-enrollment.md) + 如果您的登陸區域未處於偏離狀態，請透過 AWS Control Tower 中的**註冊帳戶**功能。請參閱 [從 AWS Control Tower 主控台註冊現有帳戶](quick-account-provisioning.md)。 + 在 AWS Control Tower 主控台中，您可以使用 Account Factory 同時建立、更新或註冊最多五個帳戶。 **自動化方法：** + **Lambda 程式碼：**從您的 AWS Control Tower 登陸區域的管理帳戶，使用 Lambda 程式碼和適當的 IAM 角色。請參閱[使用 IAM 角色的自動化帳戶佈建](https://docs.aws.amazon.com//controltower/latest/userguide/roles-how.html#stacksets-and-roles)。 + **Terraform：**來自 AWS Control Tower Account Factory for Terraform (AFT)，這倚賴 Account Factory 和 GitOps 模型來允許帳戶佈建和更新自動化。請參閱 [使用 AWS Control Tower Account Factory for Terraform (AFT) 佈建帳戶](taf-account-provisioning.md)。 + 透過自動註冊，使用 APIs 將現有帳戶移至 OU。請參閱 [使用自動註冊來移動和註冊帳戶](account-auto-enrollment.md) + **AWS Control Tower 主控台中的 Account Factory 自訂：**設定步驟之後，自訂帳戶的未來佈建不需要額外的組態或管道維護。帳戶是透過稱為*藍圖* AWS Service Catalog 的產品來佈建。藍圖可以使用 CloudFormation 範本或 Terraform 範本。 **注意** CloudFormation 藍圖可以將資源部署到多個區域。Terraform 藍圖只能將資源部署到單一區域。根據預設，這是主要區域。 # 在 AWS Control Tower 主控台中佈建帳戶 下列程序說明如何透過 AWS Control Tower 主控台，在 IAM Identity Center 中以使用者身分建立和佈建帳戶。此程序也稱為*手動帳戶佈建*。或者，您可以使用 AWS CLI、Service Catalog APIs 或 AWS Control Tower Account Factory for Terraform (AFT) 以程式設計方式佈建 AWS Control Tower 帳戶，或自動將現有帳戶註冊到已註冊的 OU。如果您先前已設定自訂藍圖，則可以在 主控台中佈建自訂帳戶。如需自訂的詳細資訊，請參閱 [使用帳戶工廠自訂 (AFC) 自訂帳戶](af-customization-page.md)。 **以使用者身分在 AWS Control Tower 主控台中個別佈建帳戶** 1. 登入 AWS 並導覽至 AWS Control Tower 主控台。 1. 從左側導覽中，選擇**組織**以檢視**組織**頁面。 1. 從右上角，選擇**建立資源**。 1. 在下拉式選單中，選擇**建立帳戶**。 1. 填寫頁面上的資訊，並謹記下列事項： + **帳戶電子郵件**必須是尚未與 建立關聯的電子郵件地址 AWS 帳戶。 + 顯示名稱是您想要為此帳戶查看的名稱。 1. 使用 IAM Identity Center 電子郵件地址和使用者名稱，填寫欄位以定義您的**存取組態**。 1. 從下拉式清單中選取已註冊的 OU，以指出您要佈建帳戶的 OU。 1. 選擇性地使用預先定義的藍圖，以自訂資源佈建您的帳戶。您可以稍後執行此任務。 1. 檢閱您的帳戶選擇，然後選擇右下角的**建立帳戶**。 1. 正在佈建您的帳戶。這可能需要幾分鐘的時間。您可以重新整理頁面來更新顯示的狀態資訊。 **注意** 一次最多可佈建五個帳戶。 # 檢視您的帳戶 **組織**頁面列出組織中的所有 OUs 和帳戶，無論 AWS Control Tower 中的 OU 或註冊狀態為何。如果每個帳戶都符合註冊的先決條件，您可以個別或依 OU 群組檢視和註冊成員帳戶到 AWS Control Tower。 **檢視特定帳戶** + 導覽至**組織**頁面。 + 您只能從右上角的下拉式選單中選擇**帳戶**。 + 然後，從資料表中選取您帳戶的名稱。 + 或者，您可以從資料表中選取父 OU 的名稱，並在該 OU **的詳細資訊**頁面上檢視該 OU 內所有帳戶的清單。 在**組織**頁面和**帳戶詳細資訊**頁面上，您可以查看帳戶**的狀態**，這是下列其中一項： + **未註冊** – 帳戶是父 OU 的成員，但不是由 AWS Control Tower 完全管理。如果父 OU 已註冊，帳戶會受到為其註冊父 OU 設定的預防性控制所管理，但 OU 的偵測性控制不適用於此帳戶。如果父 OU 未註冊，則不會套用任何控制項到此帳戶。 + **註冊 –** 帳戶正由 AWS Control Tower 進行控管。我們將帳戶與父 OU 的控制組態保持一致。此程序每個帳戶資源可能需要幾分鐘的時間。 + **已註冊** – 帳戶由為其父 OU 設定的控制項管理。它由 AWS Control Tower 完全管理。 + **註冊失敗** – 帳戶無法在 AWS Control Tower 中註冊。如需詳細資訊，請參閱[註冊失敗的常見原因](quick-account-provisioning.md#common-causes-for-enrollment-failure)。 + **可用的更新** – 帳戶有可用的更新。處於此狀態的帳戶仍會**註冊**，但帳戶必須更新以反映最近對您環境所做的變更。若要更新單一帳戶，請導覽至帳戶詳細資訊頁面，然後選取**更新帳戶**。 如果您在單一 OU 下有多個具有此狀態的帳戶，您可以選擇**重新註冊** OU 並一起更新這些帳戶。 # 關於註冊現有帳戶 當您將 AWS Control Tower *註冊*到已受 AWS Control Tower 管理的組織單位 (OU) AWS 帳戶 時，您可以將 AWS Control Tower 管控擴展到現有的個人。合格帳戶存在於與 AWS Control Tower *OUs 屬於相同 AWS Organizations 組織的未註冊* OU 中。 有數種方法可將帳戶註冊到 AWS Control Tower。**此頁面上的資訊適用於所有註冊方法。** **注意** 除非在初始登陸區域設定期間，否則您無法註冊現有 AWS 帳戶做為稽核或日誌封存帳戶。 ## 帳戶註冊期間會發生什麼情況 在註冊過程中，AWS Control Tower 會執行下列動作： + 確立帳戶的基準，其中包括部署這些堆疊集： + `AWSControlTowerBP-BASELINE-CLOUDTRAIL` + `AWSControlTowerBP-BASELINE-CLOUDWATCH` + `AWSControlTowerBP-BASELINE-CONFIG` + `AWSControlTowerBP-BASELINE-ROLES` + `AWSControlTowerBP-BASELINE-SERVICE-ROLES` + `AWSControlTowerBP-BASELINE-SERVICE-LINKED-ROLES` + `AWSControlTowerBP-VPC-ACCOUNT-FACTORY-V1` 檢閱這些堆疊集的範本，並確定它們與您現有的政策沒有衝突是個不錯的主意。 + 透過 AWS IAM Identity Center 或 識別帳戶 AWS Organizations。 + 將帳戶放入您指定的 OU 中。請務必套用目前 OU 中套用的所有 SCP，使您的安全狀態能夠保持一致。 + 透過套用至整個所選 OU SCPs，將強制性控制項套用至帳戶。 + 啟用 AWS Config 並設定它來記錄帳戶中的所有資源。 + 新增將 AWS Control Tower 偵測控制項套用至帳戶的 AWS Config 規則。 **帳戶和組織層級 CloudTrail 追蹤** 對於登陸區域 3.1 版及更高版本，如果您已在登陸區域設定中選擇選用 AWS CloudTrail 整合： OU 中的所有成員帳戶都受 OU 的 AWS CloudTrail 線索管理，無論是否已註冊。 當您在 AWS Control Tower 中註冊帳戶時，您的帳戶會受到新組織的 AWS CloudTrail 追蹤管理。如果您有現有的 CloudTrail 追蹤部署，除非您在 AWS Control Tower 中註冊帳戶之前刪除該帳戶的現有追蹤，否則可能會看到重複費用。 如果您將帳戶移至已註冊的 OU，例如透過 AWS Organizations 主控台或 APIs，您可能想要移除帳戶的任何剩餘帳戶層級追蹤。如果您有現有的 CloudTrail 追蹤部署，則會產生重複的 CloudTrail 費用。 如果您更新登陸區域並選擇不接收組織層級追蹤，或您的登陸區域比 3.0 版舊，則組織層級 CloudTrail 追蹤不適用於您的帳戶。 ## 使用 VPCs 註冊現有帳戶 當您在 Account Factory 中佈建新帳戶時，AWS Control Tower 處理 VPCs 的方式與註冊現有帳戶時不同。 + 當您建立新帳戶時，AWS Control Tower 會自動移除 AWS 預設 VPC，並為該帳戶建立新的 VPC。 + 當您註冊現有帳戶時，AWS Control Tower 不會為該帳戶建立新的 VPC。 + 當您註冊現有帳戶時，AWS Control Tower 不會移除與該帳戶相關聯的任何現有 VPC 或 AWS 預設 VPC。 **提示** 您可以設定 Account Factory 來變更新帳戶的預設行為，因此預設不會在 AWS Control Tower 下為組織中的帳戶設定 VPC。如需詳細資訊，請參閱[在 AWS Control Tower 中建立沒有 VPC 的帳戶](configure-without-vpc.md#create-without-vpc)。 ## 使用 AWS Config 資源註冊帳戶 要註冊的帳戶不得有現有 AWS Config 資源。請參閱[註冊具有現有 AWS Config 資源的帳戶](https://docs.aws.amazon.com//controltower/latest/userguide/existing-config-resources.html)。 以下是一些範例 AWS Config CLI 命令，您可以用來判斷現有帳戶 AWS Config 資源的狀態，例如組態記錄器和交付管道。 **檢視命令：** + `aws configservice describe-delivery-channels` + `aws configservice describe-delivery-channel-status` + `aws configservice describe-configuration-recorders` 正常回應類似 `"name": "default"` **刪除命令：** + `aws configservice stop-configuration-recorder --configuration-recorder-name NAME-FROM-DESCRIBE-OUTPUT` + `aws configservice delete-delivery-channel --delivery-channel-name NAME-FROM-DESCRIBE-OUTPUT` + `aws configservice delete-configuration-recorder --configuration-recorder-name NAME-FROM-DESCRIBE-OUTPUT` # 註冊的先決條件 *本節說明如何在登陸區域**設定**頁面上未選取選用的自動註冊功能，或是您使用 3.1 之前的登陸區域版本操作時，在 AWS Control Tower 中註冊現有 AWS 帳戶。* 在您可以註冊 AWS Control Tower AWS 帳戶 中現有的 之前，需要這些先決條件： **注意** 如果您已在登陸區域**設定**頁面中啟用 AWS Control Tower 自動註冊功能，或者您正在註冊帳戶作為**註冊 OU** 程序的一部分，則不需要新增`AWSControlTowerExecution`角色的先決條件。不過，在所有情況下，要註冊的帳戶可能沒有現有的 AWS Config 資源。請參閱[註冊具有現有 AWS Config 資源的帳戶](https://docs.aws.amazon.com//controltower/latest/userguide/existing-config-resources.html) 1. 若要註冊現有的 AWS 帳戶，`AWSControlTowerExecution`角色必須存在於您要註冊的帳戶中。您可以檢閱[註冊帳戶](https://docs.aws.amazon.com//controltower/latest/userguide/quick-account-provisioning.html)以取得詳細資訊和指示。 1. 除了 `AWSControlTowerExecution`角色之外， AWS 帳戶 您要註冊的現有 必須具有下列許可和信任關係。否則，註冊將會失敗。 角色許可： `AdministratorAccess` (AWS 受管政策） **角色信任關係：** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": "sts:AssumeRole" } ] } ``` ------ 1. 我們建議帳戶不應有 AWS Config 組態記錄器或交付管道。您可以透過 AWS CLI 刪除或修改這些項目，然後才能註冊 帳戶。否則，請檢閱[註冊具有現有 AWS Config 資源的帳戶](https://docs.aws.amazon.com//controltower/latest/userguide/existing-config-resources.html)，以取得如何修改現有資源的指示。 1. 您要註冊的帳戶必須存在於與 AWS Control Tower 管理帳戶相同的 AWS Organizations 組織中。已存在的帳戶只能在已**向 AWS Control Tower 註冊的 OU 中，註冊到與 AWS Control Tower 管理帳戶相同的組織。 若要檢查其他註冊先決條件，請參閱 [AWS Control Tower 入門](https://docs.aws.amazon.com//controltower/latest/userguide/getting-started-with-control-tower.html)。 **注意** 當您向 AWS Control Tower 註冊帳戶時，您的帳戶會受 AWS CloudTrail AWS Control Tower 組織的追蹤所管理。如果您有現有的 CloudTrail 追蹤部署，除非您在 AWS Control Tower 中註冊帳戶之前刪除該帳戶的現有追蹤，否則可能會看到重複費用。 **關於使用 `AWSControTowerExecution`角色的受信任存取** 在將現有的 註冊 AWS 帳戶 到 AWS Control Tower 之前，您必須授予 AWS Control Tower 管理或*控管*帳戶的許可。具體而言，AWS Control Tower 需要許可，才能 AWS Organizations 代表您在 AWS CloudFormation 和 之間建立受信任的存取，以便 CloudFormation 可以自動將堆疊部署到所選組織中的帳戶。透過此受信任的存取，`AWSControlTowerExecution`角色會執行管理每個帳戶所需的活動。因此，您必須先將此角色新增至每個帳戶，才能註冊。 啟用受信任存取時， CloudFormation 可以透過 AWS 區域 單一操作跨多個帳戶建立、更新或刪除堆疊。AWS Control Tower 依賴此信任功能，因此在將角色和許可移至已註冊的組織單位之前，可以先將角色和許可套用至現有帳戶，進而使其受到控管。 若要進一步了解受信任存取和 AWS CloudFormation StackSets，請參閱 [AWS CloudFormationStackSets和 AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudformation.html) 。 # 使用自動註冊來移動和註冊帳戶 帳戶自動註冊功能適用於 3.1 版及更高版本的登陸區域。 如果您選擇性地啟用此功能，您可以使用 AWS Organizations APIs和主控台將帳戶移至 AWS Control Tower，而無需建立[https://docs.aws.amazon.com//controltower/latest/userguide/governance-drift.html](https://docs.aws.amazon.com//controltower/latest/userguide/governance-drift.html)。帳戶會自動從 AWS Control Tower 中的目的地組織單位 (OU) 接收基準資源和控制組態。如果兩個 OUs 具有相同的基準組態並啟用相同的控制項，則此選用功能也可讓您在 AWS Control Tower 內的 OUs 之間移動帳戶，而無需建立繼承偏離。 **若要啟用自動註冊：**您可以在 AWS Control Tower 主控台的登陸區域**設定**頁面上選取帳戶自動註冊，或呼叫 AWS Control Tower `CreateLandingZone`或 `UpdateLandingZone` APIs，並將 `RemediationType` 參數的值設定為**繼承偏離**。 **若要套用自動註冊：**在**設定**頁面中選取此選項後，您可以透過 AWS Organizations 主控台、 API AWS Organizations `MoveAccount`或 AWS Control Tower 主控台來移動帳戶。 **若要使用自動註冊取消註冊帳戶：**如果您將帳戶移出已註冊的 OU，AWS Control Tower 會自動移除所有部署的基準資源和控制項。 **注意** 如果 AWS Control Tower 中的來源和目的地 OUs [已移動的成員帳戶](governance-drift.md#drift-account-moved) 具有不同的組態，帳戶可能會顯示偏離。 ## 先決條件：設定 進行自動註冊 + 您必須執行 AWS Control Tower 登陸區域 3.1 版或更新版本。 + 透過主控台中的登陸區域**設定**頁面或透過 AWS Control Tower 登陸區域 APIs，將 `RemediationTypes` 參數的值設定為 ，選擇加入 AWS Control Tower 自動註冊功能`Inheritance Drift`。當您選擇加入時，AWS Control Tower 會針對 `move account`的事件做出反應 AWS Organizations，並代表您立即修復已移動帳戶的繼承偏離。 ## 所需的許可 您需要特定角色和許可才能使用 `CreateAccount` API AWS Organizations 和 `MoveAccount` API。如需 AWS Organizations 搭配 AWS Control Tower 使用 的詳細資訊，請參閱 [AWS Control Tower 和 AWS Organizations](https://docs.aws.amazon.com//organizations/latest/userguide/services-that-can-integrate-CTower.html) 。 ## API 用量範例 如需這些 APIs的詳細資訊和範例，請參閱*AWS Organizations 《 API 參考*[https://docs.aws.amazon.com//organizations/latest/APIReference/API_MoveAccount.html](https://docs.aws.amazon.com//organizations/latest/APIReference/API_MoveAccount.html)》中的 [https://docs.aws.amazon.com//organizations/latest/APIReference/API_CreateAccount.html](https://docs.aws.amazon.com//organizations/latest/APIReference/API_CreateAccount.html)和 。 ## 考量事項 + **註冊時間表：**移至向 AWS Control Tower 註冊的 OU 的帳戶會使用*最終一致性*模型註冊。此程序通常需要幾分鐘的時間，最多幾個小時，取決於要移動的帳戶數目。 + **取消註冊程序：**您可以使用相同的程序，將帳戶移至 AWS Control Tower 外部的 OU，從 AWS Control Tower 取消註冊帳戶。此程序會移除 AWS Control Tower 部署的任何角色和資源，以及 AWS Control Tower 中啟用的任何控制項。 # 從 AWS Control Tower 主控台註冊現有帳戶 有兩種常見方式可將個人註冊 AWS 帳戶 到 AWS Control Tower。 1. 在**設定**頁面中選取*自動註冊*功能後，您可以在 AWS Control Tower AWS 帳戶 外部建立 ，並將其直接移入已註冊的 OU。如需詳細資訊，請參閱[自動移動和註冊帳戶](https://docs.aws.amazon.com//controltower/latest/userguide/account-auto-enroll.html)。此選項適用於登陸區域 3.1 版和更新版本。 1. 您可以從 AWS Control Tower 主控台手動註冊現有帳戶。 **下列各節說明第二個選項，**不需要 AWS Control Tower 環境的先前組態。 AWS 帳戶 必須符合必要的[先決條件](https://docs.aws.amazon.com//controltower/latest/userguide/enrollment-prerequisites.html)。 **在 主控台中檢視您的合格帳戶：** 1. 導覽至 AWS Control Tower 中的**組織**頁面。 1. 尋找您要註冊的帳戶名稱。若要尋找，請從右上角的下拉式選單中選擇**帳戶**，然後在篩選的表格中找到帳戶名稱。 接著，請遵循註冊個別帳戶的步驟，如 [手動註冊帳戶的步驟](#enrollment-steps)一節所示。 ## 從主控台註冊的考量事項 + AWS Control Tower 主控台中提供的**註冊帳戶**功能旨在註冊現有的 ， AWS 帳戶 以便它們由 AWS Control Tower 管理。如需詳細資訊，請參閱[註冊現有的 AWS 帳戶](https://docs.aws.amazon.com/controltower/latest/userguide/enroll-account.html)。 + 當您的登陸區域未處於[偏離](https://docs.aws.amazon.com//controltower/latest/userguide/drift.html)狀態時，可以使用主控台型**註冊帳戶**功能。如果登陸區域處於偏離狀態，您可能無法成功使用 **Enroll account (註冊帳戶)** 佈建。您需要透過 Account Factory 或其他方法佈建新帳戶，直到您的登陸區域偏離解決為止。 + 當您從 AWS Control Tower 主控台註冊帳戶時，您必須使用已啟用`AWSServiceCatalogEndUserFullAccess`政策的使用者登入帳戶，以及使用 AWS Control Tower 主控台的**管理員**存取許可，而且您無法以根使用者身分登入。 + 您註冊的帳戶可能會透過 AWS Control Tower 帳戶工廠更新，就像您更新任何其他帳戶一樣。稱為[使用 AWS Control Tower 更新和移動帳戶](updating-account-factory-accounts.md)的小節會提供更新程序。 **注意** 當您註冊現有的 時 AWS 帳戶，請務必驗證現有的電子郵件地址。否則，可能會建立新帳戶。 ## 手動註冊帳戶的步驟 在現有 AWS 帳戶 帳戶中具備 **AdministratorAccess** 存取許可 （政策） 之後，請依照下列步驟註冊帳戶： **從主控台在 AWS Control Tower 中註冊個別帳戶** + 導覽至 AWS Control Tower **Organization** 頁面。 + 在**組織**頁面上，有資格註冊的帳戶可讓您從區段頂端**的動作**下拉式功能表中選取**註冊**。當您在帳戶詳細資訊頁面上檢視帳戶時，這些帳戶也會顯示**註冊**帳戶按鈕。 **** + 選擇**註冊帳戶**時，您會看到**註冊帳戶**頁面，提示您將`AWSControlTowerExecution`角色新增至帳戶。如需一些說明，請參閱 [手動將必要的 IAM 角色新增至現有 AWS 帳戶 並註冊](enroll-manually.md)。 + 接著，從下拉式清單中選取已註冊的 OU。如果帳戶已在已註冊的 OU 中，此清單會顯示 OU。 + 選擇 **Enroll acount (註冊帳戶)**。 + 您會看到新增`AWSControlTowerExecution`角色並確認動作的模態提醒。 + 選擇**註冊**。 + AWS Control Tower 會開始註冊程序，系統會將您導向至**帳戶詳細資訊**頁面。 ## 註冊失敗的常見原因 + 若要註冊現有帳戶，`AWSControlTowerExecution`角色必須存在於您要註冊的帳戶中。 + 您的 IAM 委託人可能缺乏佈建帳戶的必要許可。 + AWS Security Token Service (AWS STS) 在您的 AWS 帳戶 主區域或 AWS Control Tower 支援的任何區域中已停用。 + 您可能會登入需要新增至帳戶工廠產品組合的帳戶 AWS Service Catalog。您必須先新增帳戶，才能存取 Account Factory，才能在 AWS Control Tower 中建立或註冊帳戶。如果適當的使用者或角色未新增至 Account Factory 產品組合，當您嘗試新增帳戶時，會收到錯誤。如需如何授予 AWS Service Catalog 產品組合存取權的指示，請參閱[授予使用者存取權](https://docs.aws.amazon.com//servicecatalog/latest/adminguide/catalogs_portfolios_users.html)。 + 您可以 root 身分登入。 + 您嘗試註冊的帳戶可能會有剩餘的 AWS Config 設定。特別是，帳戶可能具有組態記錄器或交付管道。您必須先透過 刪除或修改這些項目， AWS CLI 才能註冊 帳戶。如需詳細資訊，請參閱[註冊具有現有 AWS Config 資源的帳戶](existing-config-resources.md)及[透過 與 互動 AWS Control Tower AWS CloudShell](cshell-examples.md)。 + 如果帳戶屬於另一個具有管理帳戶的 OU，包括另一個 AWS Control Tower OU，您必須先終止其目前 OU 中的帳戶，才能加入另一個 OU。必須移除原始 OU 中的現有資源。否則，註冊將會失敗。 + 如果您的目的地 OU 的 SCPs 不允許您建立該帳戶所需的所有資源，則帳戶佈建和註冊會失敗。例如，目的地 OU 中的 SCP 可能會在沒有特定標籤的情況下封鎖資源建立。在此情況下，帳戶佈建或註冊會失敗，因為 AWS Control Tower 不支援資源標記。如需協助，請聯絡您的客戶代表，或 支援。 如需在建立新帳戶或註冊現有帳戶時，AWS Control Tower 如何使用角色的詳細資訊，請參閱[角色和帳戶](https://docs.aws.amazon.com//controltower/latest/userguide/roles.html)。 **提示** 如果您無法確認現有的 AWS 帳戶 符合註冊先決條件，您可以設定**註冊 OU** 並將帳戶註冊到該 OU。註冊成功後，您可以將帳戶移至所需的 OU。如果註冊發生失敗，則不會有其他帳戶或 OUs 受到失敗的影響。 如果您不確定現有帳戶及其組態是否與 AWS Control Tower 相容，您可以遵循下一節建議的最佳實務。 **建議：您可以為帳戶註冊設定雙步驟方法** + 首先，使用 AWS Config *一致性套件*來評估您的帳戶可能如何受到某些 AWS Control Tower 控制項的影響。若要判斷註冊 AWS Control Tower 如何影響您的帳戶，請參閱[使用一致性套件擴展 AWS Control Tower AWS Config 控管](https://aws.amazon.com//blogs/mt/extend-aws-control-tower-governance-using-aws-config-conformance-packs/)。 + 接下來，您可能希望註冊該帳戶。如果合規結果令人滿意，遷移路徑會更容易，因為您可以在預期的情況下註冊帳戶。 + 完成評估後，如果您決定設定 AWS Control Tower 登陸區域，您可能需要移除為評估建立的 AWS Config 交付管道和組態記錄器。然後，您就可以成功設定 AWS Control Tower。 **注意** 一致性套件也適用於帳戶位於 AWS Control Tower 註冊OUs 中的情況，但工作負載會在沒有 AWS Control Tower 支援的 AWS 區域中執行。您可以使用一致性套件來管理 AWS Control Tower 未部署區域中現有的帳戶中的資源。 # 如果帳戶不符合先決條件 請記住，作為先決條件，符合 AWS Control Tower 控管資格的帳戶必須屬於相同的整體組織。若要滿足帳戶註冊的此先決條件，您可以遵循這些準備步驟，將帳戶移至與 AWS Control Tower 相同的組織。 **將帳戶帶入與 AWS Control Tower 相同的組織的準備步驟** 1. 從現有組織捨棄帳戶。如果您使用此方法，則必須提供單獨的付款方式。 1. 邀請帳戶加入 AWS Control Tower 組織。如需詳細資訊，請參閱*AWS Organizations 《 使用者指南*》中的[邀請 AWS 帳戶加入您的組織](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_manage_accounts_invites.html)。 1. 接受邀請。帳戶會顯示在組織的根目錄中。此步驟會將帳戶移至與 AWS Control Tower 相同的組織。 會建立 SCPs和合併帳單。 **提示** 您可以在帳戶退出舊組織之前傳送新組織的邀請。當帳戶正式退出其現有組織時，邀請將等待。 **滿足其餘先決條件的步驟：** 1. 建立必要的`AWSControlTowerExecution`角色。 1. 清除預設 VPC。（此部分為選用。 AWS Control Tower 不會變更您現有的預設 VPC。) 1. 透過 或 刪除或修改任何現有的 AWS Config 組態記錄器或交付管道 AWS CLI AWS CloudShell。如需詳細資訊，請參閱 [使用 AWS Config 資源註冊帳戶](enroll-account.md#example-config-cli-commands) 和 [註冊具有現有 AWS Config 資源的帳戶](existing-config-resources.md) 完成這些準備步驟後，您可以將帳戶註冊到 AWS Control Tower。如需詳細資訊，請參閱[手動註冊帳戶的步驟](quick-account-provisioning.md#enrollment-steps)。此步驟會將帳戶納入完整的 AWS Control Tower 控管。 **取消佈建帳戶的選用步驟，以便註冊並保留其堆疊** 1. 若要保留套用的 CloudFormation 堆疊，請從堆疊集中刪除堆疊執行個體，然後選擇**保留執行個體的堆疊**。 1. 終止帳戶工廠中的 AWS Service Catalog 帳戶佈建產品。（此步驟只會從 AWS Control Tower 移除佈建的產品。 它不會刪除帳戶。) 1. 視需要為不屬於組織的任何帳戶設定具有必要帳單詳細資訊的帳戶。然後從組織中移除帳戶。（您這樣做，因此帳戶不會計入 AWS Organizations 配額中的總計。) 1. 如果資源仍然存在，請清除帳戶，然後遵循中的帳戶關閉步驟將其關閉[取消註冊 帳戶](unmanage-account.md)。 1. 如果您有已定義控制項的**暫停** OU，您可以在該處移動帳戶，而不是執行步驟 1。 # 手動將必要的 IAM 角色新增至現有 AWS 帳戶 並註冊 如果您已設定 AWS Control Tower 登陸區域，您可以開始將組織的帳戶註冊到向 AWS Control Tower 註冊的 OU。如果您尚未設定登陸區域，請遵循《 入門》中的 *AWS Control Tower 使用者指南*，步驟 2 中所述的步驟。 [https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-with-control-tower.html#step-two](https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-with-control-tower.html#step-two)登陸區域準備就緒後，請完成下列步驟，以手動方式將現有帳戶納入 AWS Control Tower 的控管。 **請務必檢閱本章先前[註冊的先決條件](enrollment-prerequisites.md)記下的 。** 向 AWS Control Tower 註冊帳戶之前，您必須授予 AWS Control Tower 管理該帳戶的許可。若要這樣做，您將新增具有帳戶完整存取權的角色，如以下步驟所示。您必須為您註冊的每個帳戶執行這些步驟。 **對於每個帳戶：** **步驟 1：使用管理員存取權登入目前包含您要註冊之帳戶的組織的管理帳戶。** 例如，如果您從 建立此帳戶， AWS Organizations 並使用跨帳戶 IAM 角色登入，則可以遵循下列步驟： 1. 登入組織的管理帳戶。 1. 前往 **AWS Organizations**。 1. 在**帳戶**下，選取您要註冊的帳戶，並複製其帳戶 ID。 1. 開啟頂端導覽列上的帳戶下拉式選單，然後選擇**切換角色**。 1. 在**切換角色**表單上，填寫下列欄位： + 在**帳戶**下，輸入您複製的帳戶 ID。 + 在**角色**下，輸入允許跨帳戶存取此帳戶的 IAM 角色名稱。此角色的名稱是在建立帳戶時定義的。如果您在建立帳戶時未指定角色名稱，請輸入預設角色名稱 `OrganizationAccountAccessRole`。 1. 選擇 **Switch Role** (切換角色)。 1. 您現在應該以子帳戶 AWS 管理主控台 身分登入 。 1. 完成後，請保留在子帳戶中以進行程序的下一個部分。 1. 請記下管理帳戶 ID，因為您需要在下一個步驟中輸入它。 **步驟 2：授予 AWS Control Tower 管理帳戶的許可。** 1. 前往 **IAM**。 1. 前往 **角色**。 1. 選擇建**立角色**。 1. 當系統要求選取角色適用的服務時，請選擇**自訂信任政策**。 1. 複製此處顯示的程式碼範例，並貼到政策文件中。將字串取代*`Management Account ID`*為您管理帳戶的實際管理帳戶 ID。以下是要貼上的政策： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": "sts:AssumeRole", "Condition": {} } ] } ``` ------ 1. 當系統要求連接政策時，請選擇 **AdministratorAccess**。 1. 選擇 **Next: Add Tags (下一步：新增標籤)**。 1. 您可能會看到名為**新增標籤**的選用畫面。選擇**下一步：檢閱**，立即略過此畫面 1. 在**檢閱**畫面上**的角色名稱**欄位中，輸入 `AWSControlTowerExecution`。 1. 在描述方塊中輸入簡短**描述**，例如*允許註冊的完整帳戶存取權。* 1. 選擇建**立角色**。 **步驟 3：將帳戶移至已註冊的 OU 來註冊帳戶，並驗證註冊。** 建立角色以設定必要的許可之後，請依照下列步驟註冊帳戶並驗證註冊。 1. **以管理員身分再次登入，然後前往 AWS Control Tower。** 1. **註冊 帳戶。** + 在 AWS Control Tower 的組織****頁面中，選取您的帳戶，然後從右上角**的動作**下拉式選單中選擇**註冊**。 + 請遵循註冊個別帳戶的步驟，如 [手動註冊帳戶的步驟](quick-account-provisioning.md#enrollment-steps) 頁面所示。 1. **驗證註冊。** + 從 AWS Control Tower，選擇左側導覽中的**組織**。 + 尋找您最近註冊的帳戶。其初始狀態會顯示**註冊**狀態。 + 當狀態變更為**已註冊**時，移動成功。 若要繼續此程序，請登入組織中您要在 AWS Control Tower 註冊的每個帳戶。為每個帳戶重複先決條件步驟和註冊步驟。 **新增`AWSControlTowerExecution`角色的範例** 下列 YAML 範本可協助您在帳戶中建立所需的角色，以便以程式設計方式註冊。 ``` AWSTemplateFormatVersion: 2010-09-09 Description: Configure the AWSControlTowerExecution role to enable use of your account as a target account in AWS CloudFormation StackSets. Parameters: AdministratorAccountId: Type: String Description: AWS Account Id of the administrator account (the account in which StackSets will be created). MaxLength: 12 MinLength: 12 Resources: ExecutionRole: Type: AWS::IAM::Role Properties: RoleName: AWSControlTowerExecution AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: AWS: - !Ref AdministratorAccountId Action: - sts:AssumeRole Path: / ManagedPolicyArns: - !Sub arn:${AWS::Partition}:iam::aws:policy/AdministratorAccess ``` # 註冊具有現有 AWS Config 資源的帳戶 本主題提供step-by-step方法，說明如何註冊具有現有 AWS Config 資源的帳戶。如需如何檢查現有資源的範例，請參閱 [使用 AWS Config 資源註冊帳戶](enroll-account.md#example-config-cli-commands)。 **AWS Config 資源的範例** 以下是您的帳戶可能已有的一些 AWS Config 資源類型。您可能需要修改這些資源，才能將您的帳戶註冊到 AWS Control Tower。 + AWS Config 記錄器 + AWS Config 交付管道 + AWS Config 彙總授權 **限制** + 登陸區域中設定的管理帳戶或服務整合帳戶不支援使用現有的 AWS Config 資源註冊帳戶 (AWS Config)。 + 只能使用啟用 的 OU 註冊或重新註冊工作流程來註冊帳戶`AWSControlTowerBaseline`。無法透過啟用或停用 來註冊帳戶`ConfigBaseline`。 + 不支援具有現有 AWS Config 資源的帳戶[使用自動註冊來移動和註冊帳戶](account-auto-enrollment.md)。 + 如果修改資源並在帳戶上建立偏離，AWS Control Tower 不會更新資源。 + AWS Config 不受 AWS Control Tower 管理的區域中的資源不會變更。 **前提** + 您已部署 AWS Control Tower 登陸區域。 + 您的帳戶尚未向 AWS Control Tower 註冊。 + 您的帳戶在至少一個由 AWS Control Tower 管理的區域中至少有一個預先存在 AWS Config 的資源。 + 您的帳戶未處於控管偏離狀態。 **注意** 如果您嘗試註冊具有現有 Config 資源的帳戶，但未將帳戶新增至允許清單，則註冊將會失敗。之後，如果您隨後嘗試將相同帳戶新增至允許清單，AWS Control Tower 就無法驗證帳戶是否已正確佈建。您必須從 AWS Control Tower 取消佈建帳戶，才能請求允許清單，然後註冊。如果您只將帳戶移至不同的 AWS Control Tower OU，則會導致控管偏離，這也會防止帳戶新增至允許清單。 如需描述使用現有 AWS Config 資源註冊帳戶的自動化方法的部落格，請參閱[將具有現有 AWS Config 資源的帳戶註冊自動化到 AWS Control Tower](https://aws.amazon.com//blogs/mt/automate-enrollment-of-accounts-with-existing-aws-config-resources-into-aws-control-tower/)。 **此程序有 5 個主要步驟。** 1. 將帳戶新增至 AWS Control Tower 允許清單 (AWS Control Tower)。 1. 在帳戶中建立新的 IAM 角色。 1. 修改預先存在 AWS Config 的資源。 1. 在資源不存在的 AWS 區域中建立 AWS Config 資源。 1. 向 AWS Control Tower 註冊帳戶。 **在繼續之前，請考慮下列有關此程序的期望。** + AWS Control Tower 不會在此帳戶中建立任何 AWS Config 資源。 + 註冊後，AWS Control Tower 控制會自動保護您建立 AWS Config 的資源，包括新的 IAM 角色。 + 如果在註冊後對 AWS Config 資源進行任何變更，則必須更新這些資源以符合 AWS Control Tower 設定，才能重新註冊帳戶。 ## 步驟 1：聯絡支援，將 account（帳戶） 新增至允許清單 **在票證主旨行中包含此片語：** *將具有現有 AWS Config 資源的帳戶註冊至 AWS Control Tower* **在票證內文中包含下列詳細資訊：** + 管理帳戶號碼 + 具有現有 AWS Config 資源的成員帳戶的帳號。您可以為要註冊的所有帳戶建立支援案例。 + 您為 AWS Control Tower 設定選取的主區域 **注意** 將您的帳戶新增至允許清單所需的時間為 2 個工作天。 ## 步驟 2：在成員帳戶中建立新的 IAM 角色 1. 開啟成員帳戶的 CloudFormation 主控台。 1. 使用下列範本建立新的堆疊 ``` AWSTemplateFormatVersion: 2010-09-09 Description: Configure AWS Config Resources: CustomerCreatedConfigRecorderRole: Type: AWS::IAM::Role Properties: RoleName: aws-controltower-ConfigRecorderRole-customer-created AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - config.amazonaws.com Action: - sts:AssumeRole Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWS_ConfigRole - arn:aws:iam::aws:policy/ReadOnlyAccess ``` 1. 將堆疊的名稱提供為 **CustomerCreatedConfigRecorderRoleForControlTower** 1. 建立堆疊。 **注意** 您建立的任何 SCPs都應排除 `aws-controltower-ConfigRecorderRole*`角色。請勿修改限制 AWS Config 規則執行評估能力的許可。 請遵循這些準則，以便在您擁有`aws-controltower-ConfigRecorderRole*`封鎖呼叫 Config SCPs `AccessDeniedException`時，不會收到 。 ## 步驟 3：使用預先存在的資源識別 AWS 區域 對於帳戶中的每個受管區域 (AWS Control Tower 受管），識別並記下至少具有先前顯示之其中一個現有 AWS Config 資源範例類型的區域。 ## 步驟 4：識別沒有任何 AWS Config 資源 AWS 的區域 對於帳戶中的每個受管區域 (AWS Control Tower 受管），識別並記下先前顯示的範例類型沒有 AWS Config 資源的區域。 ## 步驟 5：修改每個區域中的現有資源 AWS 在此步驟中，需要有關 AWS Control Tower 設定的下列資訊。 + `AUDIT_ACCOUNT` - AWS Config 服務整合帳戶 （先前稱為稽核帳戶） ID + `CONFIG_BUCKET` - AWS Config 交付組態快照和組態歷史記錄檔案的 AWS S3 儲存貯體。找到並確認 AWS S3 儲存貯體存在，然後再繼續進行後續步驟。 + 對於登陸區域 3.3 版或更低版本，AWS S3 儲存貯體名為 `aws-controltower-logs-LOGGING_ACCOUNT-HOME_REGION`，位於記錄帳戶中。 + 對於登陸區域 4.0 版或更新版本，AWS S3 儲存貯體名為 `aws-controltower-config-logs-AUDIT_ACCOUNT--`，位於 AWS Config 服務整合帳戶 （先前稱為稽核帳戶）。 + `IAM_ROLE_ARN` - 在步驟 2 中建立的 IAM 角色 ARN + `ORGANIZATION_ID` - 管理帳戶的組織 ID + `MEMBER_ACCOUNT_NUMBER` - 正在修改的成員帳戶 + `HOME_REGION` - AWS Control Tower 設定的主區域。 按照以下第 5a 至 5c 節中的指示修改每個現有資源。 ## 步驟 5a. AWS Config recorder 資源 每個 AWS 區域只能存在一個 AWS Config 記錄器。如果存在，請修改設定，如下所示。在主區域中將項目取代`GLOBAL_RESOURCE_RECORDING`為 **true**。對於存在 AWS Config 記錄器的其他區域，以 **false** 取代項目。 + **名稱：**請勿變更 + **RoleARN：**` IAM_ROLE_ARN` + **RecordingGroup：** + **AllSupported：** true + **IncludeGlobalResourceTypes：** `GLOBAL_RESOURCE_RECORDING` + **ResourceTypes：**空 您可以使用下列命令，透過 AWS CLI 進行此修改。將字串取代`RECORDER_NAME`為現有的 AWS Config 記錄器名稱。 ``` aws configservice put-configuration-recorder --configuration-recorder name=RECORDER_NAME,roleARN=arn:aws:iam::MEMBER_ACCOUNT_NUMBER:role/aws-controltower-ConfigRecorderRole-customer-created --recording-group allSupported=true,includeGlobalResourceTypes=GLOBAL_RESOURCE_RECORDING --region CURRENT_REGION ``` ## 步驟 5b。修改 AWS Config 交付管道資源 每個區域只能有一個 AWS Config 交付管道。如果存在另一個設定，請修改設定，如下所示。 + **名稱：**請勿變更 + **ConfigSnapshotDeliveryProperties：**TwentyFour\$1Hours + **S3BucketName：***CONFIG\$1BUCKET* + **S3KeyPrefix：***ORGANIZATION\$1ID* + **SnsTopicARN：**來自稽核帳戶的 SNS 主題 ARN，格式如下： `arn:aws:sns:CURRENT_REGION:AUDIT_ACCOUNT:aws-controltower-AllConfigNotifications` 您可以使用下列命令，透過 AWS CLI 進行此修改。將字串取代`DELIVERY_CHANNEL_NAME`為現有的 AWS Config 記錄器名稱。 ``` aws configservice put-delivery-channel --delivery-channel name=DELIVERY_CHANNEL_NAME,s3BucketName=CONFIG_BUCKET,s3KeyPrefix="ORGANIZATION_ID",configSnapshotDeliveryProperties={deliveryFrequency=TwentyFour_Hours},snsTopicARN=arn:aws:sns:CURRENT_REGION:AUDIT_ACCOUNT:aws-controltower-AllConfigNotifications --region CURRENT_REGION ``` ## 步驟 5c：修改 AWS Config 彙總授權資源 **注意** 登陸區域 4.0 版或更新版本不需要此步驟。 每個區域可以存在多個彙總授權。AWS Control Tower 需要彙總授權，將稽核帳戶指定為授權帳戶，並將 AWS Control Tower 的主區域指定為授權區域。如果不存在，請使用下列設定建立新的設定： + **AuthorizedAccountId：**稽核帳戶 ID + **AuthorizedAwsRegion：**AWS Control Tower 設定的主區域 您可以使用下列命令，透過 AWS CLI 進行此修改： `aws configservice put-aggregation-authorization --authorized-account-id AUDIT_ACCOUNT_ID --authorized-aws-region HOME_REGION --region CURRENT_REGION` ## 步驟 6：在 AWS Control Tower 管理的區域中建立不存在的資源 修訂 CloudFormation 範本，以便在您的主區域中，**IncludeGlobalResourcesTypes** 參數具有值 `GLOBAL_RESOURCE_RECORDING`，如以下範例所示。另請更新範本中的必要欄位，如本節所指定。 將主區域中的項目取代`GLOBAL_RESOURCE_RECORDING`為 **true**。對於 AWS Config 記錄器不存在的其他區域，以 **false** 取代項目。 1. 導覽至管理帳戶的 CloudFormation 主控台。 1. 使用名稱 **CustomerCreatedConfigResourcesForControlTower** 建立新的 StackSet。 1. 複製並更新下列範本： **注意** 登陸區域 4.0 版或更新版本不需要範本中的`CustomerCreatedAggregationAuthorization`資源。 ``` AWSTemplateFormatVersion: 2010-09-09 Description: Configure AWS Config Resources: CustomerCreatedConfigRecorder: Type: AWS::Config::ConfigurationRecorder Properties: Name: aws-controltower-BaselineConfigRecorder-customer-created RoleARN: !Sub arn:aws:iam::${AWS::AccountId}:role/aws-controltower-ConfigRecorderRole-customer-created RecordingGroup: AllSupported: true IncludeGlobalResourceTypes: GLOBAL_RESOURCE_RECORDING ResourceTypes: [] CustomerCreatedConfigDeliveryChannel: Type: AWS::Config::DeliveryChannel Properties: Name: aws-controltower-BaselineConfigDeliveryChannel-customer-created ConfigSnapshotDeliveryProperties: DeliveryFrequency: TwentyFour_Hours S3BucketName: CONFIG_BUCKET S3KeyPrefix: ORGANIZATION_ID SnsTopicARN: !Sub arn:aws:sns:${AWS::Region}:AUDIT_ACCOUNT:aws-controltower-AllConfigNotifications CustomerCreatedAggregationAuthorization: Type: "AWS::Config::AggregationAuthorization" Properties: AuthorizedAccountId: AUDIT_ACCOUNT AuthorizedAwsRegion: HOME_REGION ``` **使用必要欄位更新範本：** 1. 在 **S3BucketName** 欄位中，取代 *CONFIG\$1BUCKET* 1. 在 **S3KeyPrefix** 欄位中，取代 *ORGANIZATION\$1ID* 1. 在 **SnsTopicARN** 欄位中，取代 *AUDIT\$1ACCOUNT* 1. 在 **AuthorizedAccountId** 欄位中，取代 *AUDIT\$1ACCOUNT* 1. 在 **AuthorizedAwsRegion** 欄位中，取代 *HOME\$1REGION* 1. 在 CloudFormation 主控台上部署期間，新增成員帳戶號碼。 1. 新增步驟 4 中識別 AWS 的區域。 1. 部署堆疊集。 ## 步驟 7：向 AWS Control Tower 註冊 OU 在 AWS Control Tower 儀表板中，註冊 OU。 **注意** 此任務的**註冊帳戶**工作流程將不會成功。您必須選擇**註冊 OU** 或**重新註冊 OU**。 # 使用 Account Factory 佈建和管理帳戶 **注意** 單一帳戶佈建、更新和自訂必須以啟用 AWSControlTowerBaseline 的組織單位 (OU) 為目標。如果 OU 未啟用 AWSControlTowerBaseline，您可以啟用帳戶自動註冊，或在 EnabledBaselines 上使用 ResetEnabledBaseline 和 ResetEnabledControl APIs並在該 OU 上使用 EnabledControls 來註冊帳戶。如需 AWSControlTowerBaseline 的詳細資訊，請參閱：[在 OU 層級套用的基準類型](types-of-baselines.md#ou-baseline-types)。 本章包含使用 Account Factory 在 AWS Control Tower 登陸區域中佈建新成員帳戶的概觀和程序。 ## 設定和佈建帳戶的許可 AWS Control Tower 帳戶工廠可讓 中的雲端管理員和使用者在您的登陸區域中 AWS IAM Identity Center 佈建帳戶。根據預設，佈建帳戶的 IAM Identity Center 使用者必須位於 `AWSAccountFactory`群組或 管理群組中。 **注意** 從管理帳戶工作時，請小心謹慎，就像使用整個組織中具有許可的任何帳戶一樣。 AWS Control Tower 管理帳戶與 `AWSControlTowerExecution`角色具有信任關係，允許從管理帳戶設定帳戶，包括一些自動帳戶設定。如需`AWSControlTowerExecution`角色的詳細資訊，請參閱[角色和帳戶](https://docs.aws.amazon.com//controltower/latest/userguide/roles-how.html)。 **注意** 若要在 AWS Control Tower AWS 帳戶 中註冊現有的 ，該帳戶必須啟用 `AWSControlTowerExecution`角色。如需如何註冊現有帳戶的詳細資訊，請參閱[關於註冊現有帳戶](enroll-account.md)。 如需許可的詳細資訊，請參閱「[佈建帳戶所需的許可](provision-and-manage-accounts.md#permissions)」。 ## 在 Account Factory 中管理帳戶的考量事項 您可以更新、取消註冊和關閉透過 Account Factory 建立和佈建的帳戶。您可以透過更新要重新利用之帳戶中的使用者參數來回收帳戶。您也可以變更帳戶的組織單位 (OU)。 **注意** 更新與 Account Factory 提供的帳戶相關聯的佈建產品時，如果您指定新的使用者電子郵件地址 AWS IAM Identity Center，AWS Control Tower 會在 IAM Identity Center 中建立新的使用者。先前建立的帳戶不會移除。如需有關從 IAM Identity Center 移除先前 IAM Identity Center 使用者電子郵件地址的資訊，請參閱[停用使用者](https://docs.aws.amazon.com//singlesignon/latest/userguide/disableuser.html)。 # 使用 AWS Control Tower 更新和移動帳戶 更新已註冊帳戶的最簡單方法是透過 AWS Control Tower 主控台。個別帳戶更新有助於解決偏離，例如 [已移動的成員帳戶](governance-drift.md#drift-account-moved)。帳戶更新也是完整登陸區域更新的一部分。 ## 在 主控台中更新帳戶 **在 AWS Control Tower 主控台中更新帳戶** 1. 登入 AWS Control Tower 時，導覽至**組織**頁面。 1. 在 OUs和帳戶清單中，選取您要更新的帳戶名稱。可供更新的帳戶會顯示**可用的更新**狀態。 1. 接下來，您將看到所選**帳戶的帳戶詳細資訊**頁面。 1. 在右上角，選擇**更新帳戶**。 如果您將帳戶從一個組織單位 (OU) 移至另一個組織單位，請記住，新 OU 套用的控制項可能與先前 OU 中的控制項不同。請確定新 OU 中的控制項符合您帳戶的政策需求。 AWS Control Tower 帳戶修改方式不同，取決於您是否已選擇加入帳戶自動註冊。如需自動註冊的詳細資訊，請參閱 [選擇性地設定帳戶的自動註冊](configure-auto-enroll.md)。 **在帳戶之間移動時的控制行為
 OUs啟用自動註冊** 當您將帳戶移至新的 OU 時，AWS Control Tower 會將 OU 啟用的基準和控制項套用至帳戶。會移除先前 OU 的控制項和基準。如果您將帳戶移出已註冊的 OU，AWS Control Tower 會移除所有部署的基準和控制項。 **在帳戶之間移動時的控制行為
 OUs，不含自動註冊** 當您在 OUs 之間移動帳戶時，目的地 OU 的控制項會套用至
 帳戶。不過，從先前 OU 套用到帳戶的控制項不是
 已移除。控制項的確切行為專屬於 的實作
 控制項在先前的 OU 和目的地 OU 上處於作用中狀態。 + *對於使用 AWS Config 規則實作的控制項：*先前 OU 的控制項
 不會移除。這些控制項必須手動移除。 + *對於使用 SCPs控制項：*先前 OU 的 SCP 型控制項為
 已移除。目的地 OU 的 SCP 型控制項會在此帳戶上生效。 + *對於使用 CloudFormation 勾點實作的控制項：*此行為
 取決於新 OU 中控制項的狀態。 + *如果目的地 OU 沒有作用中的勾點型控制項：*舊的
 控制項會保持移動帳戶的作用中狀態，除非您移除它們
 手動。 + *如果目的地 OU 已啟用勾點控制：*舊控制項為
 已移除，且目的地 OU 中的控制項會套用至
 帳戶。 # 變更已註冊帳戶的電子郵件地址 若要變更 AWS Control Tower 中已註冊成員帳戶的電子郵件地址，請遵循本節中的程序。 **注意** 下列程序不允許您變更**管理帳戶**、**日誌封存帳戶**或**稽核帳戶**的電子郵件地址。如需詳細資訊，請參閱[如何變更與 AWS 帳戶相關聯的電子郵件地址？](https://aws.amazon.com//premiumsupport/knowledge-center/change-email-address/)或聯絡 AWS Support。 **變更 AWS Control Tower 建立之帳戶的電子郵件地址** 1. 復原帳戶的根使用者密碼。您可以遵循文章中的步驟[，如何復原遺失或忘記 AWS 的密碼？](https://aws.amazon.com//premiumsupport/knowledge-center/recover-aws-password/) 1. 使用根使用者密碼登入帳戶。 1. 像對任何其他地址一樣變更電子郵件地址 AWS 帳戶，並等待變更反映 AWS Organizations。當電子郵件地址變更完成更新時，您可能會遇到延遲。 1. 使用先前屬於帳戶的電子郵件地址，更新 Service Catalog 中的佈建產品。更新佈建產品的程序包括將新電子郵件地址與佈建產品建立關聯。如此一來，電子郵件地址變更就會在 AWS Control Tower 中生效。使用新的電子郵件地址更新後續佈建的產品。 若要變更您使用 建立之成員帳戶的密碼或電子郵件地址 AWS Organizations，請參閱*AWS Organizations 《 使用者指南*》中的[以根使用者的身分存取成員帳戶](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_manage_accounts_access.html#orgs_manage_accounts_access-as-root)。 或者，您可以從 AWS Organizations 主控台更新 Account Factory 或其他成員帳戶的電子郵件地址，而無需以根使用者身分登入。如需詳細資訊，請參閱*AWS Organizations 《 使用者指南*》中的[使用 更新成員帳戶的根使用者電子郵件地址 AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_update_primary_email.html)。 # 變更已註冊帳戶的名稱 請依照本節中的程序，變更已註冊 AWS Control Tower 帳戶的名稱。 **注意** 若要變更 AWS *管理員*帳戶的名稱，您必須擁有管理員許可，並以帳戶的根使用者身分登入。 **使用 AWS Organizations 主控台或 APIs 變更 AWS Control Tower 建立的帳戶名稱** + 遵循 *AWS 帳戶管理參考指南*中[的指示](https://docs.aws.amazon.com//accounts/latest/reference/manage-acct-update-acct-name.html#update-account-name-orgs)。 **變更 AWS Control Tower 所建立帳戶名稱的替代方法** 1. 復原帳戶的根密碼。您可以遵循本文概述的步驟，[如何復原遺失或忘記 AWS 的密碼？](https://aws.amazon.com//premiumsupport/knowledge-center/recover-aws-password/) 1. 使用根密碼登入 帳戶。 1. 在 AWS Billing 主控台中，導覽至**帳戶設定**頁面。 1. 變更**帳戶設定**中的名稱，就像對任何其他設定一樣 AWS 帳戶。 1. AWS Control Tower 會自動自我更新以反映名稱變更。此更新不會反映在 中的佈建產品中 AWS Service Catalog。 # 使用 Amazon Virtual Private Cloud 設定帳戶工廠 Account Factory 可讓您為組織中的帳戶建立預先核准的基準和組態選項。您可以透過 AWS Service Catalog設定和佈建新的帳戶。 在帳戶工廠頁面上，您可以看到組織單位 (OUs及其**允許清單**狀態的清單。根據預設，所有 OU 都在允許清單中，這表示帳戶可以在這些 OU 下佈建。您可以停用透過 進行帳戶佈建的特定 OUs AWS Service Catalog。 您可以檢視最終使用者在佈建新帳戶時可用的 Amazon VPC 組態選項。 **在 Account Factory 中設定 Amazon VPC 設定** 1. 身為中央雲端管理員，請使用管理帳戶中的管理員許可登入 AWS Control Tower 主控台。 1. 從儀表板左側，選取 **Account Factory** 以導覽至 Account Factory 網路組態頁面。您可以在該處看到顯示的預設網路設定。若要編輯，請選取**編輯**並檢視您 Account Factory 網路組態設定的可編輯版本。 1. 您可以視需要修改預設設定的每個欄位。選擇您要為最終使用者可能建立的所有新 Account Factory 帳戶建立的 VPC 組態選項，然後在欄位中輸入您的設定。 + 選擇**停用**或**啟用**，以在 Amazon VPC 中建立公有子網路。根據預設，不允許可從網際網路存取的子網路。 **注意** 如果您設定帳戶工廠 VPC 配置，以便在佈建新帳戶時**啟用**公用子網路，則帳戶工廠會設定 Amazon VPC 以建立 [NAT 閘道](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-nat-gateway.html)。Amazon VPC 將向您收取您的使用費用。如需詳細資訊，請參閱[VPC; 定價](https://aws.amazon.com//vpc/pricing/)。 + 從清單中選擇 Amazon VPC 中的私有子網路數量上限。根據預設，選取 1。每個可用區域允許的私有子網路數量上限為 2。 + 輸入建立帳戶 VPC 的 IP 地址範圍。此值必須是無類別網域間路由 (CIDR) 區塊的格式 (例如，預設為 `172.31.0.0/16`)。此 CIDR 區塊提供 Account Factory 為您的帳戶建立之 VPC 的整體子網路 IP 地址範圍。在您的 VPC 中，子網路會從您指定的範圍自動指派 , 且大小相等。根據預設，VPC 中的子網路不會重疊。不過，在您所有已佈建帳戶的 VPC 中，子網路 IP 位址範圍可能會重疊。 + 選擇佈建帳戶時，建立 VPC 的一個區域或所有區域。預設為選取所有可用的區域。 + 從清單選擇可用區域數，以在每個 VPC 中設定子網路。預設及建議數字是三個。 + 選擇**儲存**。 您可以設定這些組態選項，以建立不包含 VPC 的新帳戶。請參閱[演練](https://docs.aws.amazon.com//controltower/latest/userguide/configure-without-vpc.html)。 # 取消註冊 帳戶 如果您在 Account Factory 中建立帳戶或註冊 AWS 帳戶，而且您不再希望帳戶由登陸區域中的 AWS Control Tower 管理，您可以從 AWS Control Tower 主控台*取消註冊*帳戶。 當您取消註冊 AWS Control Tower 帳戶時，會移除 AWS Control Tower 佈建的所有資源，包括任何控制項和藍圖。帳戶會從任何 AWS Control Tower OU 移至**根**區域。帳戶不再是已註冊 OU 的一部分，也不再受 AWS Control Tower SCPs的約束。您可以透過 關閉帳戶 AWS Organizations。 **從 AWS Control Tower 主控台取消註冊已註冊的帳戶** 1. 在 的網頁瀏覽器中開啟 AWS Control Tower 主控台 [https://console.aws.amazon.com/controltower](https://console.aws.amazon.com/controltower) 1. 在左側導覽窗格中，選擇**組織**。 1. 在**組織**頁面中，選取 OU 附近的 **\$1** 按鈕，展開包含帳戶的 OU。 1. 選取帳戶，然後選擇**取消管理**。 **注意** 等待帳戶的狀態顯示**未註冊**。 如果您不再需要該帳戶，請將其關閉。如需關閉 AWS 帳戶的詳細資訊，請參閱*AWS Billing 《 使用者指南*》中的[關閉帳戶](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/close-account.html) **自動註冊處於作用中狀態時取消註冊帳戶** 如果您的**設定**頁面中的自動註冊功能處於作用中狀態，您也可以將帳戶移至未在 AWS Control Tower 中註冊的 OU 來取消註冊帳戶。所有 AWS Control Tower 資源都會移除。請注意，您不會以這種方式意外取消註冊帳戶。不過，您可以透過將其傳回 OU 來重新註冊帳戶。 當您取消註冊自訂帳戶時，AWS Control Tower 會移除登陸區域已部署的資源，以及 AWS Control Tower 在帳戶中建立的任何其他資源。AWS Control Tower 也會移除 **AWSControlTowerExecution** 角色，即使已手動新增。移除此角色符合最低權限原則，因為服務執行角色不應保留在未受管帳戶中。 取消註冊帳戶後，您可以透過 關閉帳戶 AWS Organizations。 **注意** 未註冊的帳戶不會關閉或刪除。取消註冊帳戶後，您在 Account Factory 中建立帳戶時選取的 IAM Identity Center 使用者仍然具有帳戶的管理存取權。如果您不希望此使用者具有管理存取權，則必須更新帳戶工廠中的帳戶並變更帳戶的 IAM Identity Center 使用者電子郵件地址，以在 IAM Identity Center 中變更此設定。如需詳細資訊，請參閱[使用 AWS Control Tower 更新和移動帳戶](updating-account-factory-accounts.md)。 ## 影片演練 此影片 (3：25) 說明如何從 AWS Control Tower 移除帳戶、取得帳戶的根存取權，最後關閉 AWS 帳戶。您也可以使用 [AWS Organizations API](https://docs.aws.amazon.com//controltower/latest/userguide/delete-account.html) 關閉帳戶。若要獲得更佳的觀賞效果，請選取影片右下角的圖示，將影片放大至全螢幕。並提供字幕。 [![AWS Videos](http://img.youtube.com/vi/n3eALEKZaHc/0.jpg)](http://www.youtube.com/watch?v=n3eALEKZaHc) 您可以檢視說明 AWS Control Tower 中常見任務的 AWS [YouTube 影片](https://www.youtube.com/playlist?list=PLhr1KZpdzukdS9skEXbY0z67F-wrcpbjm)清單。 # 關閉在 Account Factory 中建立的帳戶 在 Account Factory 中建立的帳戶為 AWS 帳戶。如需關閉 的詳細資訊 AWS 帳戶，請參閱《[帳戶管理參考指南》中的關閉](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/close-account.html)[https://docs.aws.amazon.com//accounts/latest/reference/manage-acct-closing.html ](https://docs.aws.amazon.com//accounts/latest/reference/manage-acct-closing.html )。 **注意** 關閉 AWS 帳戶 與從 AWS Control Tower 取消註冊帳戶不同，這些是個別的動作。您必須先取消註冊帳戶，才能將其關閉。 ## 透過 關閉 AWS Control Tower 成員帳戶 AWS Organizations 您可以從組織的管理帳戶關閉 AWS Control Tower 成員帳戶，而無需使用根登入資料個別登入每個成員帳戶 AWS Organizations。不過，您無法以這種方式關閉管理帳戶。 當您呼叫 AWS Organizations [CloseAccount API](https://docs.aws.amazon.com//organizations/latest/APIReference/API_CloseAccount.html) 或在 AWS Organizations 主控台中關閉帳戶時，成員帳戶會隔離 90 天，如同任何 AWS 帳戶 一樣。帳戶會在 AWS Control Tower 和 中顯示**暫停**狀態 AWS Organizations。如果您在該 90 天內嘗試使用帳戶，AWS Control Tower 會提供錯誤訊息。 **注意** 如果 OU 已暫停帳戶，則目標上的區域控制項的 EnabledControl 操作將會失敗。 在 90 天過期之前，您可以還原成員帳戶，就像使用任何 一樣 AWS 帳戶。在 90 天之後，會移除帳戶的記錄。 根據最佳實務，建議您先取消註冊成員帳戶，再關閉該帳戶。如果您在未先取消管理的情況下關閉成員帳戶，AWS Control Tower 會將帳戶的狀態顯示為**已暫停**，但也顯示為**已註冊**。因此，如果您嘗試在該 90 天時間內**重新註冊**帳戶的 OU，AWS Control Tower 會產生錯誤訊息。暫停的帳戶基本上會封鎖重新註冊動作並發生預先檢查失敗。如果您從 OU 移除帳戶，您可以**重新註冊** OU，但 AWS 可能會產生帳戶缺少付款方式的錯誤。若要解決此限制，請先建立另一個 OU，然後將帳戶移至該 OU，然後再嘗試重新註冊。我們建議將此 OU 命名為**暫停的** OU。 **注意** 如果您在關閉帳戶之前未取消註冊帳戶，您必須在 AWS Service Catalog 這 90 天完成後刪除 中的帳戶佈建產品。 如需詳細資訊，請參閱 [CloseAccount API](https://docs.aws.amazon.com//organizations/latest/APIReference/API_CloseAccount.html) AWS Organizations 的文件。 # Account Factory 的資源考量事項 使用 Account Factory 佈建帳戶時，會在帳戶內建立下列 AWS 資源。 | AWS 服務 | Resource Type (資源類型) | 資源名稱 | | --- | --- | --- | | AWS CloudFormation | 堆疊 | StackSet-AWSControlTowerBP-BASELINE-CLOUDTRAIL-\$1 StackSet-AWSControlTowerBP-BASELINE-CLOUDWATCH-\$1 StackSet-AWSControlTowerBP-BASELINE-CONFIG-\$1 StackSet-AWSControlTowerBP-BASELINE-ROLES-\$1 StackSet-AWSControlTowerBP-BASELINE-SERVICE-ROLES-\$1 | | AWS CloudTrail | 追蹤 | aws-controltower-BaselineCloudTrail | | Amazon CloudWatch | CloudWatch 事件規則 | aws-controltower-ConfigComplianceChangeEventRule | | Amazon CloudWatch | CloudWatch Logs | aws-controltower/CloudTrailLogs /aws/lambda/aws-controltower-NotificationForwarder | | AWS Identity and Access Management | 角色 | aws-controltower-AdministratorExecutionRole aws-controltower-CloudWatchLogsRole aws-controltower-ConfigRecorderRole aws-controltower-ForwardSnsNotificationRole aws-controltower-ReadOnlyExecutionRole AWSControlTowerExecution | | AWS Identity and Access Management | 政策 | AWSControlTowerServiceRolePolicy | | Amazon Simple Notification Service | 主題 | aws-controltower-SecurityNotifications | | AWS Lambda | 應用程式 | StackSet-AWSControlTowerBP-BASELINE-CLOUDWATCH-\$1 | | AWS Lambda | 函數 | aws-controltower-NotificationForwarder | | Amazon EventBridge | 規則 | AWSControlTowerManagedRule | | Amazon EventBridge | 規則 | aws-controltower-ConfigComplianceChangeEventRule | # 使用帳戶工廠自訂 (AFC) 自訂帳戶 **注意** 單一帳戶佈建、更新和自訂必須以啟用 AWSControlTowerBaseline 的組織單位 (OU) 為目標。如果 OU 未啟用 AWSControlTowerBaseline，您可以啟用帳戶自動註冊，或在 EnabledBaselines 上使用 ResetEnabledBaseline 和 ResetEnabledControl APIs並在該 OU 上使用 EnabledControls 來註冊帳戶。如需 AWSControlTowerBaseline 的詳細資訊，請參閱：[在 OU 層級套用的基準類型](types-of-baselines.md#ou-baseline-types)。 當您從 AWS Control Tower 主控台佈建資源 AWS 帳戶 時，AWS Control Tower 可讓您自訂新的和現有的資源。設定 Account Factory 自訂後，AWS Control Tower 會自動執行此程序以供未來佈建，因此您不需要維護任何管道。自訂帳戶可在佈建資源後立即使用。 **使用藍圖佈建新帳戶** 您的自訂帳戶是在 AWS Control Tower 帳戶工廠、透過 CloudFormation 範本或使用 Terraform 佈建。您將定義做為自訂帳戶*藍圖*的範本。您的藍圖說明您在佈建帳戶時所需的特定資源和組態。也提供由 AWS 合作夥伴建置和管理的預先定義藍圖。如需合作夥伴管理藍圖的詳細資訊，請參閱 [AWS Service Catalog 入門程式庫](https://docs.aws.amazon.com//servicecatalog/latest/adminguide/getting-started-library.html)。 **將藍圖套用至現有帳戶** 您也可以遵循 AWS Control Tower 主控台中的**更新帳戶**步驟，將自訂藍圖套用至現有帳戶。如需詳細資訊，請參閱[在 主控台中更新帳戶](updating-account-factory-accounts.md#update-account-in-console)。 **定義：您的中樞帳戶** 您的帳戶藍圖會存放在 中 AWS 帳戶，基於我們的目的稱為*中樞帳戶*。藍圖會以 Service Catalog 產品的形式儲存。我們將此產品稱為藍圖，以區分它與任何其他 Service Catalog 產品。若要進一步了解如何建立 Service Catalog 產品，請參閱《 *AWS Service Catalog 管理員指南*》中的[建立產品](https://docs.aws.amazon.com//servicecatalog/latest/adminguide/productmgmt-cloudresource.html)。 **注意** AWS Control Tower 包含*主動控制*，可監控 AWS Control Tower 中的 CloudFormation 資源。或者，您可以在登陸區域中啟用這些控制項。當您套用主動控制時，他們會檢查以確保您要部署到帳戶的資源符合組織的政策和程序。如需主動控制的詳細資訊，請參閱[主動控制](https://docs.aws.amazon.com//controltower/latest/userguide/proactive-controls.html)。 如需使用 AFC 的詳細資訊，請參閱[使用 AWS Control Tower 中的帳戶工廠自訂自動化帳戶自訂](https://aws.amazon.com//blogs/mt/automate-account-customization-using-account-factory-customization-in-aws-control-tower/)。 **先決條件** 開始使用 AWS Control Tower 帳戶工廠建立自訂帳戶之前，您必須部署 AWS Control Tower 登陸區域環境，而且必須擁有向 AWS Control Tower 註冊的組織單位 (OU)，其中將放置新建立的帳戶。 **自訂的準備** + *指定中樞帳戶：*您可以建立新的帳戶做為中樞帳戶，也可以使用現有的 AWS 帳戶。我們強烈建議您不要使用 AWS Control Tower 管理帳戶做為藍圖中樞帳戶。 + *新增必要的角色：*如果您計劃 AWS 帳戶 註冊 AWS Control Tower 並自訂這些角色，您必須先將`AWSControlTowerExecution`角色新增至這些帳戶，就像註冊 AWS Control Tower 的任何其他帳戶一樣。 + *設定合作夥伴藍圖 （選用）：*如果您計劃使用具有市場訂閱需求的合作夥伴藍圖，您必須先從 AWS Control Tower 管理帳戶設定這些藍圖，才能將合作夥伴藍圖部署為帳戶原廠自訂藍圖。 **Topics** + [設定自訂](afc-setup-steps.md) + [從藍圖建立自訂帳戶](create-afc-customized-account.md) + [在您註冊帳戶時，使用 AFC 自訂帳戶](enroll-and-customize.md) + [將藍圖新增至 AWS Control Tower 帳戶](add-blueprint-to-account.md) + [更新藍圖](update-a-blueprint.md) + [從帳戶移除藍圖](remove-a-blueprint.md) + [合作夥伴藍圖](partner-blueprints.md) + [Account Factory Customizations (AFC) 的考量事項](#af-limitations) + [如果發生藍圖錯誤](#af-error) + [根據 CloudFormation 自訂 AFC 藍圖的政策文件](#custom-policy-document) + [建立 Terraform 型 Service Catalog 產品所需的其他許可](#custom-policy-document-tf) + [轉換為 AWS Service Catalog 外部產品類型](#service-catalog-external-product-type) # 設定自訂 下一節提供為自訂程序設定 Account Factory 的步驟。建議您在開始這些步驟之前，先設定中樞帳戶的[委派管理員](https://docs.aws.amazon.com//accounts/latest/reference/using-orgs-delegated-admin.html)。 **摘要** + **步驟 1. 建立必要的角色。**建立 IAM 角色，授予 AWS Control Tower 存取 （中樞） 帳戶的許可，其中存放 Service Catalog 產品，也稱為藍圖。 + **步驟 2. 建立 AWS Service Catalog 產品。**建立自訂帳戶基礎所需的 AWS Service Catalog 產品 （也稱為「藍圖產品」)。 + **步驟 3. 檢閱您的自訂藍圖。**檢查您建立 AWS Service Catalog 的產品 （藍圖）。 + **步驟 4. 呼叫您的藍圖以建立自訂帳戶。**在建立帳戶時，在 AWS Control Tower 主控台的 Account Factory 中的適當欄位中輸入藍圖產品資訊和角色資訊。 # 步驟 1. 建立必要的角色 開始自訂帳戶之前，您必須設定包含 AWS Control Tower 與中樞帳戶之間信任關係的角色。擔任 時，該角色會授予 AWS Control Tower 管理中樞帳戶中資源的存取權。角色必須命名為 **AWSControlTowerBlueprintAccess**。 AWS Control Tower 會擔任此角色來代表您在 中建立產品組合資源 AWS Service Catalog，然後將您的藍圖做為服務型錄產品新增至此產品組合，然後在帳戶佈建期間與成員帳戶共用此產品組合和藍圖。 您將建立`AWSControlTowerBlueprintAccess`角色，如以下各節所述。您可以在已註冊或未註冊帳戶中設定角色。 **導覽至 IAM 主控台以設定所需的角色。** **在已註冊的 AWS Control Tower 帳戶中設定 AWSControlTowerBlueprintAccess 角色** 1. 聯合或以 AWS Control Tower 管理帳戶中的委託人身分登入。 1. 從管理帳戶中的聯合委託人，擔任或切換角色到您選擇做為藍圖中樞帳戶的已註冊 AWS Control Tower 帳戶中`AWSControlTowerExecution`的角色。 1. 從已註冊 AWS Control Tower 帳戶中`AWSControlTowerExecution`的角色，建立具有適當許可和信任關係`AWSControlTowerBlueprintAccess`的角色。 **重要** 為了遵循 AWS 最佳實務指引，請務必在建立`AWSControlTowerExecution`角色後立即登出`AWSControlTowerBlueprintAccess`角色。 為避免意外變更資源，此`AWSControlTowerExecution`角色僅供 AWS Control Tower 使用。 如果您的藍圖中樞帳戶未在 AWS Control Tower 中註冊，則該`AWSControlTowerExecution`角色將不會存在於帳戶中，而且在您繼續設定角色之前，不需要擔任該`AWSControlTowerBlueprintAccess`角色。 **在未註冊的成員帳戶中設定 AWSControlTowerBlueprintAccess 角色** 1. 透過您偏好的方法，聯合或登入為您要指定為中樞帳戶之帳戶中的委託人。 1. 以帳戶中的委託人身分登入時，請建立具有適當許可和信任關係`AWSControlTowerBlueprintAccess`的角色。 必須設定 **AWSControlTowerBlueprintAccess** 角色，才能將信任授予兩個委託人： + 在 AWS Control Tower 管理帳戶中執行 AWS Control Tower 的委託人 （使用者）。 + AWS Control Tower 管理帳戶中名為 `AWSControlTowerAdmin` 的角色。 以下是信任政策範例，類似於您需要為角色包含的政策。此政策示範授予最低權限存取權的最佳實務。當您制定自己的政策時，請將該術語取代為 AWS Control Tower 管理帳戶*YourManagementAccountId*的實際帳戶 ID，並將該術語取代*YourControlTowerUserRole*為管理帳戶的 IAM 角色識別符。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::111122223333:role/service-role/AWSControlTowerAdmin", "arn:aws:iam::111122223333:role/YourControlTowerUserRole" ] }, "Action": "sts:AssumeRole" } ] } ``` ------ **必要的許可政策** AWS Control Tower 要求名為 的受管政策`AWSServiceCatalogAdminFullAccess`必須連接到`AWSControlTowerBlueprintAccess`角色。此政策提供許可，在允許 AWS Control Tower 管理您的產品組合和 AWS Service Catalog 產品資源 AWS Service Catalog 時尋找 。您可以在 IAM 主控台中建立角色時連接此政策。 **可能需要其他許可** 如果您在 Amazon S3 中存放藍圖，AWS Control Tower 也需要該`AWSControlTowerBlueprintAccess`角色的`AmazonS3ReadOnlyAccess`許可政策。 如果您不使用預設的**管理員**政策， AWS Service Catalog Terraform 產品類型會要求您將一些額外的許可新增至 AFC 自訂 IAM 政策。除了建立您在 terraform 範本中定義的資源所需的許可之外，還需要這些許可。 # 步驟 2. 建立 AWS Service Catalog 產品 若要建立 AWS Service Catalog 產品，請遵循 *AWS Service Catalog 管理員指南*中[建立產品](https://docs.aws.amazon.com//servicecatalog/latest/adminguide/productmgmt-cloudresource.html)的步驟。建立 AWS Service Catalog 產品時，您會將帳戶藍圖新增為範本。 **重要** 由於 HashiCorp 更新的 Terraform 授權，將對 *Terraform Open Source* 產品和佈建產品的支援 AWS Service Catalog 變更為新的產品類型，稱為 *External*。若要進一步了解此變更如何影響 AFC，包括如何將現有帳戶藍圖更新為外部產品類型，請檢閱[轉換為外部產品類型](af-customization-page.md#service-catalog-external-product-type)。 **建立藍圖的步驟摘要** + 建立或下載將成為您帳戶藍圖的 CloudFormation 範本或 Terraform tar.gz 組態檔案。本節稍後會提供一些範本範例。 + 登入您存放 Account Factory 藍圖的 AWS 帳戶 （有時稱為中樞帳戶）。 + 導覽至 AWS Service Catalog 主控台。選擇**產品清單**，然後選擇**上傳新產品**。 + 在**產品詳細資訊**窗格中，輸入藍圖產品的詳細資訊，例如名稱和描述。 + 選取**使用範本檔案**，然後選取**選擇檔案**。選取或貼上您開發或下載以用作藍圖的範本或組態檔案。 + 選擇主控台頁面底部的**建立產品**。 您可以從 AWS Service Catalog 參考架構儲存庫下載 CloudFormation 範本。[該儲存庫的一個範例有助於為您的 資源設定備份計劃](https://github.com/aws-samples/aws-service-catalog-reference-architectures/blob/master/backup/backup-tagoptions.yml)。 以下是一個範例範本，適用於名為 **Best Pets** 的虛構公司。它有助於設定與其寵物資料庫的連線。 ``` Resources: ConnectionStringGeneratorLambdaRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Principal: Service: - lambda.amazonaws.com Action: - "sts:AssumeRole" ConnectionStringGeneratorLambda: Type: AWS::Lambda::Function Properties: FunctionName: !Join ['-', ['ConnectionStringGenerator', !Select [4, !Split ['-', !Select [2, !Split ['/', !Ref AWS::StackId]]]]]] Description: Retrieves the connection string for this account to access the Pet Database Role: !GetAtt ConnectionStringGeneratorLambdaRole.Arn Runtime: nodejs22.x Handler: index.handler Timeout: 5 Code: ZipFile: > export const handler = async (event, context) => { const awsAccountId = context.invokedFunctionArn.split(“:”)[4] const connectionString= “fake connection for account ” + awsAccountId; const response = { statusCode: 200, body: connectionString }; return response; }; ConnectionString: Type: Custom::ConnectionStringGenerator Properties: ServiceToken: !GetAtt ConnectionStringGeneratorLambda.Arn PetDatabaseConnectionString: DependsOn: ConnectionString # For example purposes we're using SSM parameter store. # In your template, use secure alternatives to store # sensitive values such as connection strings. Type: AWS::SSM::Parameter Properties: Name: pet-database-connection-string Description: Connection information for the BestPets pet database Type: String Value: !GetAtt ConnectionString.Value ``` # 步驟 3。檢閱您的自訂藍圖 您可以在 AWS Service Catalog 主控台中檢視您的藍圖。如需詳細資訊，請參閱 *Service Catalog 管理員指南*中的[管理產品](https://docs.aws.amazon.com//servicecatalog/latest/adminguide/catalogs_products.html#productmgmt-menu)。 # 步驟 4. 呼叫您的藍圖以建立自訂帳戶 當您遵循 AWS Control Tower 主控台中的**建立帳戶**工作流程時，您會看到一個選用區段，您可以在其中輸入要用於自訂帳戶之藍圖的相關資訊。 **先決條件** 您必須設定自訂中樞帳戶並新增至少一個藍圖 (Service Catalog 產品），才能將該資訊輸入 AWS Control Tower 主控台並開始佈建自訂帳戶。 **在 AWS Control Tower 主控台中建立或更新自訂帳戶。** 1. 輸入包含您的藍圖之帳戶的帳戶 ID。 1. 從該帳戶選取現有的 Service Catalog 產品 （現有的藍圖）。 1. 如果您有多個版本，請選取藍圖的正確版本 (Service Catalog 產品）。 1. （選用） 您可以在程序的這個時間點新增或變更藍圖佈建政策。藍圖佈建政策是以 JSON 撰寫並連接到 IAM 角色，因此可以佈建藍圖範本中指定的資源。AWS Control Tower 會在成員帳戶中建立此角色，以便 Service Catalog 可以使用 CloudFormation 堆疊集部署資源。角色已命名 `AWSControlTower-BlueprintExecution-bp-xxxx`。根據預設，`AdministratorAccess`政策會在此處套用。 1. 根據此藍圖，選擇您要在其中部署帳戶的 AWS 區域 或 區域。 1. 如果您的藍圖包含參數，您可以將參數的值輸入 AWS Control Tower 工作流程中的其他欄位。其他值可能包括：GitHub 儲存庫名稱、GitHub 分支、Amazon ECS 叢集名稱，以及儲存庫擁有者的 GitHub 身分。 1. 如果您的中樞帳戶或藍圖尚未準備好，您可以稍後遵循**帳戶更新**程序來自訂帳戶。 如需詳細資訊，請參閱[從藍圖建立自訂帳戶](create-afc-customized-account.md)。 # 從藍圖建立自訂帳戶 建立自訂藍圖後，您可以在 AWS Control Tower 帳戶工廠中開始建立自訂帳戶。 **當您建立新 AWS 帳戶時，請依照下列步驟部署自訂藍圖：** 1. 前往 中的 AWS Control Tower AWS 管理主控台。 1. 選取**帳戶工廠**和**建立帳戶**。 1. 輸入帳戶詳細資訊，例如帳戶名稱和電子郵件地址。 1. 使用電子郵件地址和使用者名稱設定 IAM Identity Center 詳細資訊。 1. 選取將新增您帳戶的已註冊 OU。 1. 展開**帳戶原廠自訂**區段。 1. 輸入包含 Service Catalog 產品的藍圖中樞帳戶的帳戶 ID，然後選擇**驗證**。如需藍圖中樞帳戶的詳細資訊，請參閱 [使用帳戶工廠自訂 (AFC) 自訂帳戶](af-customization-page.md)。 1. 從 Service Catalog 產品清單中選取包含所有藍圖的下拉式選單 （所有自訂和合作夥伴藍圖）。選擇要部署的藍圖和對應的版本。 1. 如果您的藍圖包含參數，則會顯示這些欄位供您填入。預設值會預先填入。 1. 最後，選取您要部署藍圖的位置，無論是**主區域**或**所有受管區域**。Route 53 或 IAM 等全域資源可能只需要部署到單一區域。區域資源，例如 Amazon EC2 執行個體或 Amazon S3 儲存貯體，可以部署到所有受管區域 1. 完成所有欄位後，選取**建立帳戶**。 **注意** 使用 Terraform 建立的藍圖只能部署到一個區域，不能部署到多個區域。 您可以在**組織**頁面上檢視帳戶佈建的進度。當您的帳戶佈建完成時，藍圖指定的資源已在其中部署。若要檢視帳戶的詳細資訊和藍圖，請前往**帳戶詳細資訊**頁面。 # 在您註冊帳戶時，使用 AFC 自訂帳戶 在 AWS Control Tower 主控台中註冊和自訂帳戶。 1. 導覽至 AWS Control Tower 主控台，然後從左側導覽中選取**組織**。 1. 您將看到可用帳戶的清單。識別您想要使用自訂藍圖註冊的帳戶。該帳戶**的狀態**欄應反映為**未註冊**狀態的帳戶。 1. 選取帳戶左側的選項按鈕，然後選擇畫面右上角**的動作**下拉式功能表。在這裡，您將選取**註冊**選項。 1. 使用帳戶的 IAM Identity Center 資訊完成**存取組態**區段。 1. 選取您的帳戶將成為成員的已註冊 OU。 1. 使用與**建立****帳戶程序 7-12 相同的步驟，完成帳戶原廠自訂**區段。如需詳細資訊，請參閱[使用佈建帳戶工廠帳戶 AWS Service Catalog](https://docs.aws.amazon.com/controltower/latest/userguide/provision-as-end-user.html)。 您可以在**組織**頁面上檢視帳戶進度的狀態。當您的帳戶註冊完成時，藍圖指定的資源已在其中部署。 # 將藍圖新增至 AWS Control Tower 帳戶 若要將藍圖新增至現有的 AWS Control Tower 成員帳戶，請遵循 AWS Control Tower 主控台中的**更新帳戶**工作流程，然後選擇要新增至帳戶的新藍圖。如需詳細資訊，請參閱[使用 AWS Control Tower 或使用 更新和移動帳戶工廠帳戶 AWS Service Catalog](https://docs.aws.amazon.com/controltower/latest/userguide/updating-account-factory-accounts.html#update-account-in-console)。 **注意** 如果您將新的藍圖新增至帳戶，則會覆寫現有的藍圖。 **注意** 每個 AWS Control Tower 帳戶可以部署一個藍圖。 # 更新藍圖 下列程序說明如何更新自訂藍圖，以及如何部署這些藍圖。 **更新您的自訂藍圖** 1. 使用新組態更新您的 CloudFormation 範本或 Terraform tar.gz 檔案 （藍圖）。 1. 將更新的藍圖儲存為新的版本 AWS Service Catalog。 **部署更新的藍圖** 1. 導覽至 AWS Control Tower 主控台中的**組織**頁面。 1. 依藍圖名稱和版本篩選**組織**頁面。 1. 遵循**更新帳戶**程序，並在您的帳戶中部署最新的藍圖版本。 **如果藍圖更新失敗** 當佈建產品處於 `AVAILABLE` 狀態時，AWS Control Tower 允許藍圖更新。如果您的佈建產品處於 `TAINTED` 狀態，更新將會失敗。我們建議採取以下解決方法： 1. 在 AWS Service Catalog 主控台中，手動更新`TAINTED`佈建的產品，將狀態變更為 `AVAILABLE`。如需詳細資訊，請參閱[更新佈建的產品](https://docs.aws.amazon.com//servicecatalog/latest/userguide/enduser-update.html)。 1. 然後，遵循 AWS Control Tower 的更新帳戶程序來修正藍圖部署錯誤。 *我們建議您使用此手動步驟，因為：*當您移除藍圖時，可能會導致移除成員帳戶中的資源。移除資源可能會影響您現有的工作負載。因此，我們建議您使用此方法，而不是更新藍圖的替代方式，特別是如果您正在執行生產工作負載，即移除和取代原始藍圖。 # 從帳戶移除藍圖 若要從帳戶移除藍圖，請遵循**更新帳戶**工作流程移除藍圖，並將帳戶傳回 AWS Control Tower 預設組態。 當您在主控台中輸入**更新帳戶**工作流程時，您會看到所有帳戶詳細資訊都會填入，而且自訂詳細資訊也不會填入。如果您將這些 AFC 詳細資訊保留空白，AWS Control Tower 會從帳戶移除藍圖。您會在動作開始之前看到警告訊息。 **注意** 只有當您在**建立**帳戶或**更新帳戶程序期間選取藍圖時，AWS Control Tower 才會將藍圖新增至帳戶**。 # 合作夥伴藍圖 AWS Control Tower 帳戶工廠自訂 (AFC) 可讓您存取由 AWS 合作夥伴建置和管理的預先定義自訂藍圖。這些合作夥伴藍圖可協助您針對特定使用案例自訂帳戶。每個合作夥伴的藍圖都可協助您建置自訂帳戶，這些帳戶已預先設定為與該特定合作夥伴的產品方案搭配使用。 若要檢視 AWS Control Tower 合作夥伴藍圖的完整清單，請導覽至主控台中的 Service Catalog **入門程式庫**。搜尋來源類型 **AWS Control Tower 藍圖**。 ## Account Factory Customizations (AFC) 的考量事項 + AFC 僅支援使用單一 AWS Service Catalog 藍圖產品的自訂。 + AWS Service Catalog 藍圖產品必須在中樞帳戶中建立，並在與 AWS Control Tower 登陸區域主區域相同的區域中建立。 + IAM `AWSControlTowerBlueprintAccess` 角色必須以適當的名稱、許可和信任政策建立。 + AWS Control Tower 支援兩種藍圖部署選項：僅部署到主區域，或部署到由 AWS Control Tower 管理的所有區域。區域選擇不可用。 + 當您更新成員帳戶中的藍圖時，藍圖中樞帳戶 ID 和 AWS Service Catalog 藍圖產品無法變更。 + AWS Control Tower 不支援移除現有的藍圖，並在單一藍圖更新操作中新增新的藍圖。您可以移除藍圖，然後在個別操作中新增藍圖。 + AWS Control Tower 會根據您是建立還是註冊自訂帳戶或非自訂帳戶，來變更行為。如果您不是使用藍圖建立或註冊自訂帳戶，AWS Control Tower 會在 AWS Control Tower 管理帳戶中建立 Account Factory 佈建產品 （透過 Service Catalog)。如果您在使用藍圖建立或註冊帳戶時指定自訂，AWS Control Tower 不會在 AWS Control Tower 管理帳戶中建立 Account Factory 佈建的產品。 ## 如果發生藍圖錯誤 **套用藍圖時發生錯誤** 如果在將藍圖套用至帳戶的過程中發生錯誤，無論是新帳戶或您註冊 AWS Control Tower 的現有帳戶，復原程序都相同。帳戶將存在，但不會自訂，也不會註冊到 AWS Control Tower。若要繼續，請依照步驟將帳戶註冊到 AWS Control Tower，並在註冊時新增藍圖。 **建立`AWSControlTowerBlueprintAccess`角色時發生錯誤，以及解決方法** 當您從 AWS Control Tower 帳戶建立`AWSControlTowerBlueprintAccess`角色時，您必須使用該`AWSControlTowerExecution`角色以委託人身分登入。如果您以任何其他身分登入，SCP 會阻止`CreateRole`操作，如以下成品所示： ``` { "Condition": { "ArnNotLike": { "aws:PrincipalArn": [ "arn:aws:iam::*:role/AWSControlTowerExecution", "arn:aws:iam::*:role/stacksets-exec-*" ] } }, "Action": [ "iam:AttachRolePolicy", "iam:CreateRole", "iam:DeleteRole", "iam:DeleteRolePermissionsBoundary", "iam:DeleteRolePolicy", "iam:DetachRolePolicy", "iam:PutRolePermissionsBoundary", "iam:PutRolePolicy", "iam:UpdateAssumeRolePolicy", "iam:UpdateRole", "iam:UpdateRoleDescription" ], "Resource": [ "arn:aws:iam::*:role/aws-controltower-*", "arn:aws:iam::*:role/*AWSControlTower*", "arn:aws:iam::*:role/stacksets-exec-*" ], "Effect": "Deny", "Sid": "GRIAMROLEPOLICY" } ``` 可用的解決方法如下： + （最佳建議） 擔任`AWSControlTowerExecution`角色並建立`AWSControlTowerBlueprintAccess`角色。如果您選擇此解決方法，請務必在之後立即登出該`AWSControlTowerExecution`角色，以防止意外變更資源。 + 登入未在 AWS Control Tower 註冊的帳戶，因此不受此 SCP 約束。 + 暫時編輯此 SCP 以允許 操作。 + （強烈建議不要） 使用您的 AWS Control Tower 管理帳戶做為您的中樞帳戶，因此不受 SCP 約束。 ## 根據 CloudFormation 自訂 AFC 藍圖的政策文件 當您透過帳戶工廠啟用藍圖時，AWS Control Tower CloudFormation 會指示 代表您建立 StackSet。 CloudFormation 需要存取您的受管帳戶，才能在 StackSet 中建立 CloudFormation 堆疊。雖然 CloudFormation 已透過 `AWSControlTowerExecution`角色在受管帳戶中具有管理員權限，但此角色無法擔任 CloudFormation。 在啟用藍圖的過程中，AWS Control Tower 會在成員帳戶中建立角色， CloudFormation 可能擔任該角色來完成 StackSet 管理任務。透過帳戶工廠啟用自訂藍圖的最簡單方法是使用*全部允許*政策，因為這些政策與任何藍圖範本相容。 不過，最佳實務建議您必須限制 CloudFormation 目標帳戶中的 許可。您可以提供自訂政策，AWS Control Tower 會套用到其建立 CloudFormation 供 使用的角色。例如，如果您的藍圖建立稱為*重要事項*的 SSM 參數，您可以提供下列政策： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowCloudFormationActionsOnStacks", "Effect": "Allow", "Action": "cloudformation:*", "Resource": "arn:aws:cloudformation:*:*:stack/*" }, { "Sid": "AllowSsmParameterActions", "Effect": "Allow", "Action": [ "ssm:PutParameter", "ssm:DeleteParameter", "ssm:GetParameter", "ssm:GetParameters" ], "Resource": "arn:*:ssm:*:*:parameter/something-important" } ] } ``` ------ 所有 AFC 自訂政策都需要 `AllowCloudFormationActionsOnStacks`陳述式； CloudFormation 使用此角色來建立堆疊執行個體，因此需要在堆疊上執行 CloudFormation 動作的許可。`AllowSsmParameterActions` 區段專屬於要啟用的範本。 **解決許可問題** 當您啟用具有限制政策的藍圖時，您可能會發現沒有足夠的許可來啟用藍圖。若要解決這些問題，請修訂您的政策文件，並更新成員帳戶的藍圖偏好設定，以使用更正的政策。若要檢查政策是否足以啟用藍圖，請確定已授予 CloudFormation 許可，而且您可以直接使用該角色建立堆疊。 ## 建立 Terraform 型 Service Catalog 產品所需的其他許可 當您使用適用於 AFC 的 Terraform 組態檔案建立 AWS Service Catalog 外部產品時，除了建立範本中定義資源所需的許可之外， AWS Service Catalog 還需要將特定許可新增至您的 AFC 自訂 IAM 政策。如果您選擇預設的完整**管理員**政策，則不需要新增這些額外的許可。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "resource-groups:CreateGroup", "resource-groups:ListGroupResources", "resource-groups:DeleteGroup", "resource-groups:Tag" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "tag:GetResources", "tag:GetTagKeys", "tag:GetTagValues", "tag:TagResources", "tag:UntagResources" ], "Resource": "*", "Effect": "Allow" }, { "Action": "s3:GetObject", "Effect": "Allow", "Resource": "*", "Condition": { "StringEquals": { "s3:ExistingObjectTag/servicecatalog:provisioning": "true" } } } ] } ``` ------ 如需使用 中的外部產品類型建立 Terraform 產品的詳細資訊 AWS Service Catalog，請參閱 Service Catalog 管理員指南中的[步驟 5：建立啟動角色](https://docs.aws.amazon.com//servicecatalog/latest/adminguide/getstarted-launchrole-Terraform.html)。 ## 轉換為 AWS Service Catalog 外部產品類型 AWS Service Catalog 將 *Terraform Open Source* 產品和佈建產品的支援變更為新的產品類型，稱為*外部*。若要進一步了解此轉換，請參閱 *AWS Service Catalog 管理員指南*中的[將現有的 Terraform Open Source 產品和佈建產品更新為外部產品類型](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/update_terraform_open_source_to_external.html)。 此變更會影響您透過 AWS Control Tower 帳戶原廠自訂建立或註冊的現有帳戶。若要將這些帳戶轉換為*外部*產品類型，您需要在 AWS Service Catalog 和 AWS Control Tower 中進行變更。 **轉換為外部產品類型** 1. 升級您現有的 Terraform 參考引擎， AWS Service Catalog 以包含對*外部*和 *Terraform 開放原始碼*產品類型的支援。如需有關更新 Terraform 參考引擎的說明，請檢閱 [AWS Service Catalog GitHub 儲存庫](https://github.com/aws-samples/service-catalog-engine-for-terraform-os)。 1. 在 中 AWS Service Catalog，使用新的*外部*產品類型複製任何現有的 *Terraform Open Source* 產品 （藍圖） 和複本。**請勿終止現有的 Terraform 開放原始碼藍圖**。 1. 在 AWS Control Tower 中，使用 *Terraform 開放原始碼*藍圖更新每個帳戶，以使用新的*外部*藍圖。 1. 若要更新藍圖，您必須先完全移除 *Terraform 開放原始碼*藍圖。如需詳細資訊，請參閱[從帳戶移除藍圖](https://docs.aws.amazon.com/controltower/latest/userguide/remove-a-blueprint.html)。 1. 將新的*外部*藍圖新增至相同的帳戶。如需詳細資訊，請參閱[將藍圖新增至 AWS Control Tower 帳戶](https://docs.aws.amazon.com/controltower/latest/userguide/add-blueprint-to-account.html)。 1. 使用 *Terraform Open Source* 藍圖的所有帳戶更新為*外部*藍圖後，請返回 AWS Service Catalog 並終止使用 *Terraform Open Source* 作為產品類型的任何產品。 1. 接下來，使用 AWS Control Tower 帳戶原廠自訂建立或註冊的所有帳戶，都必須使用 *CloudFormation*或 *外部*產品類型參考藍圖。 對於使用*外部*產品類型建立的藍圖，AWS Control Tower 僅支援使用 Terraform 範本和 Terraform 參考引擎的帳戶自訂。若要進一步了解，請檢閱[設定以進行自訂](https://docs.aws.amazon.com/controltower/latest/userguide/afc-setup-steps.html)。 **注意** 建立新帳戶時，AWS Control Tower 不支援 *Terraform Open Source* 做為產品類型。若要進一步了解這些變更，請參閱《 *AWS Service Catalog 管理員指南*》中的[將現有的 Terraform 開放原始碼產品和佈建產品更新為*外部*產品類型](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/update_terraform_open_source_to_external.html)。 AWS Service Catalog 將視需要支援客戶完成此產品類型轉換。請聯絡您的 帳戶代表以請求協助。 # 使用 AWS Control Tower Account Factory for Terraform (AFT) 佈建帳戶 AWS Control Tower Account Factory for Terraform (AFT) 採用 GitOps 模型，可自動化 AWS Control Tower 中的帳戶佈建和更新程序。 使用 AFT，您可以建立帳戶請求 Terraform 檔案，其中包含叫用 AFT 工作流程的輸入。帳戶佈建和更新完成後，AFT 工作流程會繼續執行 AFT 帳戶佈建架構和帳戶自訂步驟。 AFT 不會影響 AWS Control Tower 中的工作流程效能。如果您透過 AFT 或 Account Factory 佈建帳戶，則會發生相同的後端工作流程。 ## 先決條件 **注意** AFT 帳戶佈建必須以 AWS Control Tower 中啟用 AWSControlTowerBaseline 的組織單位 (OU) 為目標。如需 AWSControlTowerBaseline 的詳細資訊，請參閱：[在 OU 層級套用的基準類型](types-of-baselines.md#ou-baseline-types)。 當您開始使用 AFT 時，您將建立下列項目： + 在 AWS Control Tower 中，為您的 AFT 環境建立 OU，然後建立 AFT 管理帳戶。請記下帳戶 ID，以便您稍後使用 Terraform 模組部署 AFT 時，可以在 `main.tf` 檔案中輸入帳戶 ID。您可以在 AWS Control Tower **Control 詳細資訊**頁面上檢視此帳戶 ID。如需詳細資訊，請參閱 [Terraform 文件](https://developer.hashicorp.com/terraform/tutorials/aws/aws-control-tower-aft)。 + 完整部署 AFT 環境的一或多個`git`儲存庫。如需詳細資訊，請參閱 [AFT 的部署後步驟](https://docs.aws.amazon.com/controltower/latest/userguide/aft-post-deployment.html)。 + 完全部署的 AFT 環境。如需詳細資訊，請參閱[適用於 Terraform 的 AWS Control Tower 帳戶工廠概觀 (AFT)](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) 和適用於 [Terraform 的部署 AWS Control Tower 帳戶工廠 (AFT)。](https://docs.aws.amazon.com/controltower/latest/userguide/aft-getting-started.html)另請參閱 [Terraform 文件](https://developer.hashicorp.com/terraform/tutorials/aws/aws-control-tower-aft)。 **提示** 您可以從 AWS Control Tower 主控台使用建立帳戶建立 AFT 管理**帳戶**。如需詳細資訊，請參閱[佈建方法](https://docs.aws.amazon.com//controltower/latest/userguide/methods-of-provisioning.html)。 此外，您可以選擇在 **aft-account-customizations** 儲存庫中建立帳戶範本資料夾，以協助定義其他帳戶。 對於透過自動註冊註冊的帳戶： + 透過 AFT 建立新帳戶會繼續正常運作。 + 現有的帳戶匯入需要額外的步驟： + 註冊 OU 以在匯入之前建立必要的佈建產品。 + 註冊 OU 將發出 `CreateManagedAccount`和 `UpdateManagedAccount`事件，啟用 AFT 自訂。 如需 AFT 具有部署限制 AWS 區域 之處的詳細資訊，請參閱 [AWS Control Tower 中的限制和配額](limits.md)和 [控制限制](control-limitations.md)。 [Terraform 文件](https://developer.hashicorp.com/terraform/tutorials/aws/aws-control-tower-aft)包含如何為 Terraform 設定 AWS Control Tower 帳戶工廠 (AFT) 的良好概觀。 # 適用於 Terraform (AFT) 的 AWS Control Tower 帳戶工廠概觀 Account Factory for Terraform (AFT) 會設定 Terraform 管道，協助您在 AWS Control Tower 中佈建和自訂帳戶。AFT 為您提供 Terraform 型帳戶佈建的優勢，同時允許您使用 AWS Control Tower 管理您的帳戶。 使用 AFT，您可以建立*帳戶請求 Terraform 檔案*，以取得觸發帳戶佈建之 AFT 工作流程的輸入。帳戶佈建階段完成後，AFT 會自動在帳戶自訂階段開始之前執行一系列步驟。如需詳細資訊，請參閱 [AFT 帳戶佈建管道](https://docs.aws.amazon.com/controltower/latest/userguide/aft-provisioning-framework.html)。 AFT 支援 Terraform Cloud、Terraform Enterprise 和 Terraform Community Edition。使用 AFT，您可以使用輸入檔案和簡單的`git push`命令來啟動帳戶建立，並自訂新的或現有的帳戶。帳戶建立包括所有 AWS Control Tower 控管優勢和帳戶自訂，可協助您符合組織的標準安全程序和合規準則。 AFT 支援帳戶自訂請求追蹤。每次您提交帳戶自訂請求時，AFT 都會產生唯一的追蹤字符，透過 AFT 自訂 AWS Step Functions 狀態機器傳遞，該機器會將字符記錄為執行的一部分。然後，您可以使用 Amazon CloudWatch Logs 洞見查詢來搜尋時間戳記範圍並擷取請求字符。因此，您可以看到字符隨附的承載，以便在整個 AFT 工作流程中追蹤您的帳戶自訂請求。如需 CloudWatch Logs 和 Step Functions 的相關資訊，請參閱下列內容： + 《Amazon CloudWatch Logs 使用者指南》**中的[什麼是 Amazon CloudWatch Logs？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) + 《AWS Step Functions 開發人員指南》**中的[什麼是 AWS Step Functions？](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) AFT 結合了其他 AWS 服務的功能，以[元件服務](aft-components.md)建置架構，以及部署 Terraform Infrastructure as Code (IaC) 的管道。AFT 可讓您： + 在 GitOps 模型中提交帳戶佈建和更新請求 + 存放帳戶中繼資料和稽核歷史記錄 + 套用帳戶層級標籤 + 將自訂新增至所有帳戶、一組帳戶或個別帳戶 + 啟用功能選項 AFT 會建立稱為 *AFT 管理帳戶*的獨立帳戶，以部署 AFT 功能。您必須先擁有現有的 AWS Control Tower 登陸區域，才能設定 AFT。AFT 管理帳戶與 AWS Control Tower 管理帳戶不同。 **AFT 提供彈性** + **平台彈性：**AFT 支援任何 Terraform Distribution 進行初始部署和持續操作：Community Edition、Cloud 和 Enterprise。 + **版本控制系統的彈性：**AFT 支援 AWS CodeCommit，以及透過 的替代版本控制來源 AWS CodeConnections。 **AFT 提供功能選項** 您可以根據最佳實務啟用數個功能選項： + 建立用於記錄資料事件的組織層級 CloudTrail + 刪除帳戶 AWS 的預設 VPC + 將佈建帳戶註冊至 AWS 企業支援計劃 **注意** AFT 管道不適用於部署您帳戶執行應用程式所需的資源，例如 Amazon EC2 執行個體。它僅用於自動佈建和自訂 AWS Control Tower 帳戶。 ## 影片演練 此影片 (7：33) 說明如何使用 AWS Control Tower Account Factory for Terraform 部署帳戶。若要獲得更佳的觀賞效果，請選取影片右下角的圖示，將影片放大至全螢幕。並提供字幕。 [![AWS Videos](http://img.youtube.com/vi/eDbNvHz02dk/0.jpg)](http://www.youtube.com/watch?v=eDbNvHz02dk) # AFT 架構 ## 操作順序 您可以在 AFT 管理帳戶中執行 AFT 操作。對於完整的帳戶佈建工作流程，圖表中從左到右的階段順序如下： 1. 帳戶請求會建立並提交至管道。您可以一次建立和提交多個帳戶請求。Account Factory first-in-first-out順序處理請求。如需詳細資訊，請參閱[提交多個帳戶請求](https://docs.aws.amazon.com/controltower/latest/userguide/aft-multiple-account-requests.html)。 1. 每個帳戶都會佈建。此階段會在 AWS Control Tower 管理帳戶中執行。 1. 全域自訂會在針對每個付費帳戶建立的管道中執行。 1. 如果在初始帳戶佈建請求中指定自訂，則自訂只會在目標帳戶上執行。如果您有已佈建的帳戶，則必須在帳戶的管道中手動啟動進一步的自訂。 **適用於 Terraform 的 AWS Control Tower 帳戶工廠 – 帳戶佈建工作流程 ** ![\[圖：AFT 工作流程圖表\]](http://docs.aws.amazon.com/zh_tw/controltower/latest/userguide/images/high-level-aft-diagram.png) # Cost AFT 沒有額外費用。您只需為 AFT 部署的資源、AFT 啟用 AWS 的服務，以及您在 AFT 環境中部署的資源付費。 預設 AFT 組態包含 AWS PrivateLink 端點的配置，以增強資料保護和安全性，以及支援 AWS CodeBuild 所需的 NAT 閘道。如需此基礎設施定價的詳細資訊，請參閱 NAT Gateway 的[AWS PrivateLink 定價](https://aws.amazon.com//privatelink/pricing/)和 Amazon VPC 定價。 [https://aws.amazon.com//vpc/pricing/](https://aws.amazon.com//vpc/pricing/)如需管理這些成本的詳細資訊，請聯絡您的 AWS 客戶代表。您可以變更 AFT 的這些預設設定。 # 部署適用於 Terraform (AFT) 的 AWS Control Tower 帳戶工廠 本節適用於想要在現有環境中設定 Account Factory for Terraform (AFT) 的 AWS Control Tower 環境管理員。它說明如何使用新的專用 AFT 管理帳戶設定 Account Factory for Terraform (AFT) 環境。 **注意** Terraform 模組會部署 AFT。此模組可在 GitHub 上的 [AFT 儲存庫](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main)中使用，而且整個 AFT 儲存庫都視為模組。 我們建議您參考 GitHub 上的 AFT 模組，而不是複製 AFT 儲存庫。如此一來，您就可以在模組可用時控制和使用更新。 如需 AWS Control Tower Account Factory for Terraform (AFT) 功能最新版本的詳細資訊，請參閱此 GitHub 儲存庫的[版本檔案](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/releases)。 **部署先決條件** 在設定和啟動 AFT 環境之前，您必須擁有下列資源： + AWS Control Tower 登陸區域的主區域。如需詳細資訊，請參閱[如何使用 AWS 區域 AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/region-how.html)。 + AWS Control Tower 登陸區域。如需詳細資訊，請參閱[規劃您的 AWS Control Tower 登陸區域](https://docs.aws.amazon.com/controltower/latest/userguide/planning-your-deployment.html)。 + AFT 管理帳戶，您可以在 AWS Control Tower 中佈建，或透過其他方式佈建並註冊 AWS Control Tower。 + Terraform 版本和分佈。如需詳細資訊，請參閱 [Terraform 和 AFT 版本](https://docs.aws.amazon.com/controltower/latest/userguide/version-supported.html)。 + 用於追蹤和管理程式碼和其他檔案變更的 VCS 提供者。根據預設，AFT 會使用 AWS CodeCommit。如需詳細資訊，請參閱*AWS CodeCommit 《 使用者指南*》中的[什麼是 AWS CodeCommit？](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)。 如果您是第一次部署 AFT，而且沒有現有的 CodeCommit 儲存庫，則必須選擇外部 VCS 供應商，例如 GitHub 或 BitBucket。如需詳細資訊，請參閱 [AFT 中原始程式碼版本控制的替代方案](https://docs.aws.amazon.com/controltower/latest/userguide/aft-alternative-vcs.html)。 + 執行期環境，您可以在其中執行安裝 AFT 的 Terraform 模組。 + AFT 功能選項。如需詳細資訊，請參閱[啟用功能選項](https://docs.aws.amazon.com/controltower/latest/userguide/aft-feature-options.html)。 ## 設定和啟動適用於 Terraform 的 AWS Control Tower 帳戶工廠 下列步驟假設您熟悉 Terraform 工作流程。您也可以遵循 AWS Workshop Studio 網站上的 AFT 實驗室[簡介，進一步了解部署 AFT](https://catalog.workshops.aws/control-tower/en-US/customization/aft)。 **步驟 1：啟動您的 AWS Control Tower 登陸區域** 完成 [AWS Control Tower 入門](https://catalog.workshops.aws/control-tower/en-US/customization/aft)中的步驟。您可以在此處建立 AWS Control Tower 管理帳戶，並設定 AWS Control Tower 登陸區域。 **注意** 請務必為具有 **AdministratorAccess** 登入資料的 AWS Control Tower 管理帳戶建立角色。如需詳細資訊，請參閱下列內容： *AWS Identity and Access Management 《 使用者指南*》中的 [IAM 身分 （使用者、使用者群組和角色）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) 《 *AWS 受管政策參考指南*》中的 [AdministratorAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html) **步驟 2：為 AFT 建立新的組織單位 （強烈建議）** 我們建議您在 AWS Control Tower 登陸區域 中建立個別的 OU。此 OU 是您佈建 AFT 管理帳戶的地方。從 AWS Control Tower 管理帳戶建立新的 OU 和 AFT 管理帳戶。如需詳細資訊，請參閱[建立新的 OU](https://docs.aws.amazon.com/controltower/latest/userguide/create-new-ou.html)。 **步驟 3：佈建 AFT 管理帳戶** AFT 要求您佈建專用於 AFT 管理操作 AWS 的帳戶。當您登入與您的 AWS Control Tower 登陸區域相關聯的 AWS Control Tower 管理帳戶時，請建立 AFT 管理帳戶。您可以在**組織**頁面上選取**建立帳戶，或透過其他方式，從 AWS Control Tower 主控台佈建 AFT 管理帳戶**。如需詳細資訊，請參閱[使用 Account Factory 佈建 AWS Service Catalog 帳戶](https://docs.aws.amazon.com/controltower/latest/userguide/provision-as-end-user.html)。 **注意** 如果您為 AFT 建立單獨的 OU，請務必在建立 AFT 管理帳戶時選取此 OU。 完整佈建 AFT 管理帳戶最多可能需要 30 分鐘。 **步驟 4：確認 Terraform 環境可供部署** 此步驟假設您有使用 Terraform 的經驗，並具有執行 Terraform 的程序。如需詳細資訊，請參閱 HashiCorp 開發人員網站上的 [Command： init](https://developer.hashicorp.com/terraform/cli/commands/init)。 **注意** AFT 支援 Terraform 版本 `1.6.0` 或更新版本。 **步驟 5：選用組態** + **選擇性地設定虛擬私有雲端 (VPC) 組態** AFT 模組包含 `aft_enable_vpc` 參數，指定 AWS Control Tower 是否在中央 AFT 管理帳戶中的 VPC 內佈建帳戶資源。根據預設， 參數會設定為 `true`。如果您將此參數設定為 `false`，AWS Control Tower *會在不使用* VPC 和私有聯網資源的情況下部署 AFT，例如 NAT Gateways 或 VPC 端點。停用`aft_enable_vpc`可能有助於降低*某些使用模式*的 AFT 操作成本。新增任何 VPC 組態會覆寫設定為 的`aft_enable_vpc`參數`false`。 **注意** 重新啟用 `aft_enable_vpc` 參數 （將值從 切換`false`為 `true`) 可能需要您連續執行`terraform apply`命令兩次。 您可以設定 AFT 以使用帳戶中現有的 VPC，而不是佈建新的 VPC。若要使用您自己的 VPC，請提供下列 VPC 組態參數： + `aft_customer_vpc_id` - 現有 VPC 的 ID + `aft_customer_private_subnets` - VPC 中的私有子網路 IDs清單 範例組態： ``` module "aft" { source = "github.com/aws-ia/terraform-aws-control_tower_account_factory" # VPC configuration aft_customer_vpc_id = "vpc-0123456789abcdef0" aft_customer_private_subnets = ["subnet-0123456789abcdef0", "subnet-0123456789abcdef1"] # Other AFT parameters... } ``` **重要** 如果您有現有的 AFT 部署，我們不建議您使用自訂 VPC 選項。您可能對 Lambda 函數或 CodePipeline 有相依性，這些相依性取決於基礎現有 VPC 中的資源。 + **選擇性地設定 Terraform 專案名稱** 您可以設定 `terraform_project_name` 參數來自訂 AFT 使用的 Terraform 專案名稱。根據預設，AFT 會將部署置於 Terraform Cloud 或 Terraform Enterprise 的「預設」專案中。 範例組態： ``` module "aft" { source = "github.com/aws-ia/terraform-aws-control_tower_account_factory" # Project name configuration terraform_project_name = "my-organization-aft" # Other AFT parameters... } ``` **注意** 此參數僅適用於 Terraform Enterprise 或 Terraform Cloud 部署。 + **選擇性地將自訂標籤套用至 AFT 資源** 您可以使用 `tags` 參數，將自訂標籤套用至所有 AFT 資源。這些標籤可協助進行資源組織、成本分配和存取控制。 範例組態： ``` module "aft" { source = "github.com/aws-ia/terraform-aws-control_tower_account_factory" # Custom tags configuration tags = { Environment = "Production" CostCenter = "IT-12345" Project = "AFT-Deployment" Owner = "platform-team@example.com" } # Other AFT parameters... } ``` 這些標籤會套用至 AFT 模組建立的所有資源。AFT 會自動將`managed_by = "AFT"`標籤新增至所有資源，這些資源無法被自訂標籤覆寫。 **注意** 您可以隨時新增自訂標籤，而不只是在初始部署期間。 + **選擇性地將 AWS KMS 客戶受管加密金鑰 (CMK) 套用至 CloudWatch 日誌群組和 SNS 主題** 若要啟用日誌群組和 SNS 主題的 KMS CMK 加密，請設定 `cloudwatch_log_group_enable_cmk_encryption`和 `sns_topic_enable_cmk_encryption`變數。 如果您選擇加入這些設定，AFT 會使用現有的 CMK、*別名/後*置來加密 CloudWatch 日誌和 SNS 主題。在 AFT 管理帳戶中部署 AFT 時，會建立此 CMK，並可套用至日誌群組和 SNS 主題。 + 如果變數`cloudwatch_log_group_enable_cmk_encryption`設為 **true**，則 AFT 的 CloudWatch 日誌群組會使用 CMK 加密。如果變數設定為 **false**，這是預設值，則會使用[伺服器端加密來加密日誌，並預設使用 CloudWatch 日誌](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html)。 + 如果變數`sns_topic_enable_cmk_encryption`設為 **true**，傳送至 AFT SNS 主題的通知 (*後置通知*和*aft-failure-notifications*) 會使用 CMK 加密。如果變數設定為 **false**，這是預設值，SNS 訊息會使用 AWS 受管金鑰加密：*alias/aws/sns*。如需詳細資訊，請參閱 [SSE 金鑰術語](https://docs.aws.amazon.com//sns/latest/dg/sns-server-side-encryption.html#sse-key-terms)。 + **選擇性地變更 CodeBuild 運算類型** 在部署期間，若要變更 AFT 用於 CodeBuild 的運算類型，請設定變數 `aft_codebuild_compute_type`。 如需已接受運算類型的資訊，請參閱[關於隨需環境類型](https://docs.aws.amazon.com//codebuild/latest/userguide/build-env-ref-compute-types.html#environment.types)。預設運算類型為 `BUILD_GENERAL1_MEDIUM`。 + **選擇性地為 Terraform 設定 OpenID Connect (OIDC)** 使用 Terraform Enterprise 或 HCP Terraform （先前稱為 Terraform Cloud) 的客戶可以使用建立在 OIDC 通訊協定上的 Terraform 工作負載身分字符 （或動態提供者憑證），以使用 AFT 安全地連接和驗證工作區。 您可以將 `terraform_oidc_integration` 參數設定為 ，以啟用 AFT 工作區的 OIDC 整合`true`。根據預設，此參數會設定為 `false`。啟用此參數時，如果預設值 (`aws.workload.identity` `terraform_oidc_aws_audience`和 分別為 ) 不符合您的環境`app.terraform.io`，則應檢閱和設定 和 `terraform_oidc_hostname` 參數。 範例組態： ``` module "aft" { source = "github.com/aws-ia/terraform-aws-control_tower_account_factory" # Terraform distribution must be "tfc" or "tfe" for OIDC terraform_distribution = "tfc" # Terraform OIDC Configuration terraform_oidc_integration = true terraform_oidc_aws_audience = "aws.workload.identity" # default terraform_oidc_hostname = "app.terraform.io" # default; set to your TFE hostname if applicable # Other AFT parameters... } ``` **注意** 此參數僅適用於 Terraform Enterprise 或 HCP Terraform 部署。 **注意** 如果您目前正在 AFT 管理帳戶中利用 Terraform 的 OIDC 提供者，您必須先刪除該提供者，才能選擇加入此整合。AFT 會在部署時為您重新建立該提供者。 **步驟 6：呼叫 Account Factory for Terraform 模組以部署 AFT** 使用您為具有 **AdministratorAccess** 憑證的 AWS Control Tower 管理帳戶建立的角色來呼叫 AFT 模組。AWS Control Tower 透過 AWS Control Tower 管理帳戶佈建 Terraform 模組，這會建立協調 AWS Control Tower 帳戶工廠請求所需的所有基礎設施。 您可以在 GitHub 的 AFT [儲存庫中檢視 AFT](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main) 模組。整個 GitHub 儲存庫會被視為 AFT 模組。如需執行 AFT 模組和部署 AFT 所需的輸入相關資訊，請參閱 [README 檔案](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/blob/main/README.md)。或者，您可以在 [Terraform 登錄](https://registry.terraform.io/modules/aws-ia/control_tower_account_factory/aws/latest)檔中檢視 AFT 模組。 如果您在環境中建立了用於管理 Terraform 的管道，您可以將 AFT 模組整合到現有的工作流程中。否則，請從使用所需登入資料進行身分驗證的任何環境執行 AFT 模組。 逾時會導致部署失敗。我們建議您使用 AWS Security Token Service (STS) 登入資料，以確保您的逾時足以進行完整部署。 AWS STS 登入資料的最短逾時為 60 分鐘。如需詳細資訊，請參閱*AWS Identity and Access Management 《 使用者指南*[》中的 IAM 中的臨時安全登入](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)資料。 **注意** 您可以等待最多 30 分鐘讓 AFT 透過 Terraform 模組完成部署。 **步驟 7：管理 Terraform 狀態檔案** 部署 AFT 時會產生 Terraform 狀態檔案。此成品說明 Terraform 建立的資源狀態。如果您打算更新 AFT 版本，請務必預先保存 Terraform 狀態檔案，或使用 Amazon S3 和 DynamoDB 設定 Terraform 後端。AFT 模組不會管理後端 Terraform 狀態。 **注意** 您有責任保護 Terraform 狀態檔案。某些輸入變數可能包含敏感值，例如私有`ssh`金鑰或 Terraform 字符。根據您的部署方法，這些值可以在 Terraform 狀態檔案中以純文字形式檢視。如需詳細資訊，請參閱 HashiCorp 網站上的[狀態敏感資料](https://www.terraform.io/docs/language/state/sensitive-data.html)。 # 部署後步驟 AFT 基礎設施部署完成後，請依照這些額外步驟完成設定程序，並準備好佈建帳戶。 **步驟 1：使用所需的 VCS 供應商完成 CodeConnections ** 如果您選擇第三方 VCS 提供者，AFT 會建立 CodeConnections，然後進行確認。請參閱 ，[AFT 中原始程式碼版本控制的替代方案](aft-alternative-vcs.md)了解如何使用您偏好的 VCS 設定 AFT。 建立 AWS CodeStar 連線的初始步驟是由 AFT 完成。您必須確認連線。 **步驟 2：填入每個儲存庫** AFT 要求您管理[四個儲存庫：](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos) 1. 帳戶請求 – 此儲存庫會處理提出或更新帳戶請求。[可用的範例](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-request) 。如需 AFT 帳戶請求的詳細資訊，請參閱 [使用 AFT 佈建新帳戶](aft-provision-account.md)。 1. AFT 帳戶佈建自訂 – 此儲存庫會在開始全域自訂階段之前，管理套用到由 AFT 建立和使用 AFT 管理的所有帳戶的自訂。[可用的範例](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-provisioning-customizations) 。若要建立 AFT 帳戶佈建自訂，請參閱 [建立您的 AFT 帳戶佈建自訂狀態機器](aft-provisioning-framework.md#aft-create-customizations)。 1. 全域自訂 – 此儲存庫會管理套用至由 AFT 建立和使用 AFT 管理的所有帳戶的自訂。[可用的範例](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-global-customizations) 。若要建立 AFT 全域自訂，請參閱 [套用全域自訂](aft-account-customization-options.md#aft-global-customizations)。 1. 帳戶自訂 – 此儲存庫會管理僅套用至由 AFT 建立和使用 AFT 管理的特定帳戶的自訂。[可用的範例](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-customizations) 。若要建立 AFT 帳戶自訂，請參閱 [套用帳戶自訂](aft-account-customization-options.md#aft-account-customizations)。 AFT 預期每個儲存庫都遵循特定的目錄結構。用於填入儲存庫的範本和描述如何填入範本的指示，可在 [AFT github 儲存庫](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos)的 Account Factory for Terraform 模組中使用。 # 使用 AFT 佈建新帳戶 *本節假設您已設定 AFT 和 AFT 管理帳戶，而且您正在佈建其他帳戶。* 若要使用 AFT 佈建新帳戶，請建立帳戶請求 Terraform 檔案。此檔案包含 **aft-account-request** 儲存庫中參數的輸入。建立帳戶請求 Terraform 檔案之後，請執行 開始處理您的帳戶請求`git push`。此命令會在 中叫用 操作 AWS CodePipeline，該`ct-aft-account-request`操作會在帳戶佈建完成後在 AFT 管理帳戶中建立。如需詳細資訊，請參閱 [AFT 帳戶佈建管道](https://docs.aws.amazon.com/controltower/latest/userguide/aft-provisioning-framework.html)。 ## 帳戶請求 Terraform 檔案參數 您必須在帳戶請求 Terraform 檔案中包含下列參數。您可以在 GitHub 上檢視[範例帳戶請求 Terraform 檔案](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-request)。 + 的值在每個 AWS 帳戶 請求中`module name`必須是唯一的。 + 的值`module source`是 AFT 提供之帳戶請求 Terraform 模組的路徑。 + 的值會`control_tower_parameters`擷取建立 AWS Control Tower 帳戶所需的輸入。此值包含下列輸入欄位： + `AccountEmail` + `AccountName` + `ManagedOrganizationalUnit` + `SSOUserEmail` + `SSOUserFirstName` + `SSOUserLastName` **注意** 您無法在帳戶佈建期間`control_tower_parameters`變更您為 提供的輸入。 在 **aft-account-request** 儲存庫`ManagedOrganizationalUnit`中指定 支援的格式包括 `OUName`和 `OUName (OU-ID)`。 + `account_tags` 會擷取使用者定義的金鑰和值，這些金鑰和值可根據業務準則 AWS 帳戶 進行標記。如需詳細資訊，請參閱*AWS Organizations 《 使用者指南*》中的[標記 AWS Organizations 資源](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_tagging.html)。 + 的值會`change_management_parameters`擷取其他資訊，例如建立帳戶請求的原因，以及啟動帳戶請求的人員。此值包含下列輸入欄位： + `change_reason` + `change_requested_by` + `custom_fields` 在 **/aft/account-request/custom-fields/** 下的付費帳戶中，使用部署為 SSM 參數的索引鍵和值擷取其他中繼資料。您可以在帳戶自訂期間參考此中繼資料，以部署適當的控制項。例如，受法規合規約束的帳戶可能會部署額外的 AWS Config 規則。您使用 收集的中繼資料`custom_fields`可以在帳戶佈建和更新期間叫用其他處理。如果從帳戶請求中移除自訂欄位，則自訂欄位會從佈建帳戶的 SSM 參數存放區中移除。 + （選用） 會`account_customizations_name`擷取 **aft-account-customizations** 儲存庫中的帳戶範本資料夾。如需詳細資訊，請參閱[帳戶自訂](https://docs.aws.amazon.com/controltower/latest/userguide/aft-account-customization-options.html)。 # 提交多個帳戶請求 AFT 一次處理一個帳戶請求，但您可以將多個帳戶請求提交至 AFT 管道。當您向 AFT 管道提交多個帳戶請求時，AFT 會排入佇列，並以先進先出順序處理帳戶請求。 **注意** 您可以為您希望 AFT 在單一帳戶請求 Terraform 檔案中佈建或串聯多個帳戶請求的每個帳戶建立帳戶請求 Terraform 檔案。 # 更新現有帳戶 **自動註冊相容性** 如果您的組織使用自動註冊進行自動帳戶註冊，請注意，AFT 對匯入這些帳戶有限制。透過自動註冊註冊的帳戶缺少 AFT 匯入工作流程所需的 Service Catalog 佈建產品。 **解決方法：**使用註冊 OU 功能為自動註冊的帳戶建立佈建產品。這可為 AFT 自訂啟用必要的生命週期事件。 您可以編輯先前提交的帳戶請求並執行 ，以更新 AFT 佈建的帳戶`git push`。此命令會叫用帳戶佈建工作流程，並可處理帳戶更新請求。您可以更新 的輸入`ManagedOrganizationalUnit`，這是 所需值的一部分`control_tower_parameters`。 `ManagedOrganizationalUnit` 是可在所有 中更新的唯一參數`control_tower_parameters`。不過，屬於帳戶請求 Terraform 檔案的其他參數可以更新，例如 `custom_fields`。如需詳細資訊，請參閱[使用 AFT 佈建新帳戶](https://docs.aws.amazon.com/controltower/latest/userguide/aft-provision-account.html)。 例如，若要更新 AFT 帳戶的名稱或電子郵件地址，您可以定義帳戶`custom_fields`請求檔案中的詳細資訊。透過這樣做，您可以建立 SSM 參數，您可以在全域自訂期間傳入`aws_account_alternate_contact`資源。 ``` resource "aws_account_alternate_contact" "operations" { alternate_contact_type = "OPERATIONS" name = "Example" title = "Example" email_address = "someone@example.com" phone_number = "+1234567890" } ``` 您可以為其他聯絡類型新增類似的欄位，例如操作和安全性。在全球自訂中，為每個自訂欄位新增資料查詢，以確保您查詢在帳戶請求中建立的所有欄位： ``` data "aws_ssm_parameter" "billing_name" { name = "/aft/account-request/custom-fields/billing_name" } data "aws_ssm_parameter" "billing_title" { name = "/aft/account-request/custom-fields/billing_title" } data "aws_ssm_parameter" "billing_email_address" { name = "/aft/account-request/custom-fields/billing_email_address" } data "aws_ssm_parameter" "billing_phone_number" { name = "/aft/account-request/custom-fields/billing_phone_number" } ``` 最後，在全球自訂檔案中，建立替代聯絡人資源。您需要為您在帳戶請求中建立的每個聯絡類型定義其中一個區塊： ``` resource "aws_account_alternate_contact" "billing" { alternate_contact_type = "BILLING" name = data.aws_ssm_parameter.billing_name.value title = data.aws_ssm_parameter.billing_title.value email_address = data.aws_ssm_parameter.billing_email_address.value phone_number = data.aws_ssm_parameter.billing_phone_number.value } ``` **注意** 您無法在帳戶佈建期間`control_tower_parameters`變更您為 提供的輸入。 在 **aft-account-request** 儲存庫`ManagedOrganizationalUnit`中指定 支援的格式包括 `OUName`和 `OUName (OU-ID)`。 ## 更新 AFT 未佈建的帳戶 您可以在 **aft-account-request** 儲存庫中指定帳戶，以更新在 AFT 外部建立的 AWS Control Tower 帳戶。 **注意** 確保所有帳戶詳細資訊皆正確且符合 AWS Control Tower 組織和個別 AWS Service Catalog 佈建的產品。 **AWS 帳戶 使用 AFT 更新現有 的先決條件** + AWS 帳戶 必須在 AWS Control Tower 中註冊。 + AWS 帳戶 必須是 AWS Control Tower 組織的一部分。 # Terraform 和 AFT 版本 Account Factory for Terraform (AFT) 支援 Terraform 版本 `1.6.0` 或更新版本。您必須提供 Terraform 版本做為 AFT 部署程序的輸入參數，如以下範例所示。 ``` terraform_version = "1.6.0" ``` ## Terraform 分佈 AFT 支援三種 Terraform 分佈： + Terraform Community Edition + Terraform 雲端 + Terraform Enterprise 這些分佈會在以下各節中說明。在 AFT 引導程序期間，提供您選擇的 Terraform 分佈做為輸入參數。如需 AFT 部署和輸入參數的詳細資訊，請參閱 [部署適用於 Terraform (AFT) 的 AWS Control Tower 帳戶工廠](aft-getting-started.md) 。 如果您選擇 Terraform Cloud 或 Terraform Enterprise 分佈，您為 指定的 [API 權](https://www.terraform.io/cloud-docs/users-teams-organizations/api-tokens)杖`terraform_token `必須是使用者或團隊 API 權杖。並非所有必要的 APIs都支援 Organization 權杖。基於安全考量，您必須藉由指派 [terraform 變數](https://www.terraform.io/cloud-docs/workspaces/variables/managing-variables)，避免將此權杖的值簽入版本控制系統 (VCS)，如以下範例所示。 ``` # Sensitive variable managed in Terraform Cloud: terraform_token = var.terraform_cloud_token ``` ### Terraform Community Edition 當您選取 Terraform Community Edition 做為分佈時，AFT 會在 AFT 管理帳戶中為您管理 Terraform 後端。AFT 會下載`terraform-cli`指定 Terraform 版本的 ，以在 AFT 部署和 AFT 管道階段執行。產生的 Terraform 狀態組態會存放在 Amazon S3 儲存貯體中，並以下列格式命名： ``` aft-backend-[account_id]-primary-region ``` AFT 也會建立 Amazon S3 儲存貯體，在另一個儲存貯體中複寫您的 Terraform 狀態組態 AWS 區域，用於災難復原，名稱為 ，格式如下： ``` aft-backend-[account_id]-secondary-region ``` 建議您為這些 Terraform 狀態 Amazon S3 儲存貯體上的刪除函數啟用多重驗證 (MFA)。若要進一步了解 Terraform Community Edition，請參閱 [Terraform 文件](https://www.terraform.io/docs/cli/index.html)。 若要選取 Terraform OSS 做為分佈，請提供下列輸入參數： ``` terraform_distribution = "oss" ``` ### Terraform 雲端 當您選取 Terraform Cloud 做為分佈時，AFT 會在 Terraform Cloud 組織中為下列元件建立工作區，這會啟動 API 驅動的工作流程。 + 帳戶請求 + AFT 佈建之帳戶的 AFT 自訂 + AFT 佈建之帳戶的帳戶自訂 + AFT 佈建之帳戶的全域自訂 Terraform Cloud 會管理產生的 Terraform 狀態組態。 當您選取 Terraform Cloud 做為分佈時，請提供下列輸入參數： + `terraform_distribution = "tfc"` + `terraform_token` – 此參數包含 Terraform Cloud 字符的值。AFT 會將 標記為敏感，並將值儲存為 AFT 管理帳戶中 SSM 參數存放區中的安全字串。我們建議您根據公司的安全政策和合規準則定期輪換 Terraform 字符的值。Terraform 權杖應該是使用者或團隊層級 API 權杖。不支援組織字符。 + `terraform_org_name` – 此參數包含 Terraform Cloud 組織的名稱。 **注意** 不支援單一 Terraform Cloud 組織中的多個 AFT 部署。 如需有關如何設定 Terraform Cloud 的資訊，請參閱 [Terraform 文件](https://www.terraform.io/docs/cloud/index.html)。 ### Terraform Enterprise 當您選取 Terraform Enterprise 做為分佈時，AFT 會在 Terraform Enterprise 組織中為下列元件建立工作區，並觸發產生 Terraform 執行的 API 驅動工作流程。 + 帳戶請求 + 由 AFT 佈建之帳戶的 AFT 帳戶佈建自訂 + AFT 佈建的帳戶的帳戶自訂 + AFT 佈建之帳戶的全域自訂 產生的 Terraform 狀態組態是由您的 Terraform Enterprise 設定管理。 若要選取 Terraform Enterprise 做為分佈，請提供下列輸入參數： + `terraform_distribution = "tfe"` + `terraform_token` – 此參數包含 Terraform Enterprise 字符的值。AFT 將其值標記為敏感，並將其儲存為 SSM 參數存放區 AFT 管理帳戶中的安全字串。我們建議您根據公司的安全政策和合規準則，定期輪換 Terraform 字符的值。 + `terraform_org_name` – 此參數包含 Terraform Enterprise 組織的名稱。 + `terraform_api_endpoint` – 此參數包含 Terraform Enterprise 環境的 URL。此參數的值格式必須為： ``` https://{fqdn}/api/v2/ ``` 請參閱 [Terraform 文件](https://www.terraform.io/docs/enterprise/index.html)以進一步了解如何設定 Terraform Enterprise。 # 檢查 AFT 版本 您可以透過查詢 AWS SSM 參數存放區金鑰來檢查已部署的 AFT 版本： ``` /aft/config/aft/version ``` 如果您使用登錄檔方法，則可以鎖定版本。 ``` module "control_tower_account_factory" { source = "aws-ia/control_tower_account_factory/aws" version = "1.3.2" # insert the 6 required variables here } ``` 您可以在 AFT [儲存庫中檢視 AFT ](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main)版本的詳細資訊。 # 更新 AFT 版本 登入 AWS Control Tower 管理帳戶以啟動此 AFT 更新。 您可以從`main`儲存庫分支中提取已部署的 AFT 版本，以更新該版本： ``` terraform get -update ``` 提取完成後，您可以重新執行 Terraform 計劃或執行套用，以使用最新的變更更新 AFT 基礎設施。 # 啟用功能選項 AFT 會根據最佳實務提供功能選項。您可以在 AFT 部署期間，透過功能旗標選擇加入這些功能。如需 AFT 輸入組態參數的詳細資訊[使用 AFT 佈建新帳戶](aft-provision-account.md)，請參閱。 預設不會啟用這些功能。您必須明確啟用環境中的每個項目。 **Topics** + [AWS CloudTrail 資料事件](#cloudtrail-data-event-option) + [AWS 企業支援計劃](#enterprise-support-option) + [刪除 AWS 預設 VPC](#delete-default-vpc-option) ## AWS CloudTrail 資料事件 啟用時， AWS CloudTrail 資料事件選項會設定這些功能。 + 在適用於 CloudTrail 的 AWS Control Tower 管理帳戶中建立 Organization Trail + 開啟 Amazon S3 和 Lambda 資料事件的記錄 + 使用加密將所有 CloudTrail 資料事件加密並匯出至 AWS Control Tower Log Archive 帳戶中的 `aws-aft-logs-*` S3 儲存貯體 AWS KMS + 開啟**日誌檔案驗證**設定 若要啟用此選項，請在 AFT 部署輸入組態中將下列功能旗標設為 **True**。 ``` aft_feature_cloudtrail_data_events ``` **必要條件** 啟用此功能選項之前，請確定您的組織中 AWS CloudTrail 已啟用 的受信任存取。 **若要檢查 CloudTrail 的受信任存取狀態：** 1. 導覽至 AWS Organizations 主控台。 1. 選擇**服務 > CloudTrail**。 1. 然後視需要選取右上角的**啟用受信任存取**。 您可能會收到警告訊息，建議您使用 AWS CloudTrail 主控台，但在這種情況下，請忽略警告。在您允許受信任存取之後，AFT 會建立線索做為啟用此功能選項的一部分。如果未啟用受信任存取，當 AFT 嘗試為資料事件建立追蹤時，您會收到錯誤訊息。 **注意** 此設定適用於組織層級。啟用此設定會影響 中的所有帳戶 AWS Organizations，無論它們是否由 AFT 管理。Amazon S3 資料事件會排除啟用時 AWS Control Tower Log Archive 帳戶中的所有儲存貯體。請參閱 [AWS CloudTrail 使用者指南](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)以進一步了解 CloudTrail。 ## AWS 企業支援計劃 啟用此選項時，AFT 管道會為 AFT 佈建的帳戶開啟 AWS 企業支援計劃。 AWS 帳戶預設會啟用 AWS 基本支援計劃。AFT 為 AFT 佈建的帳戶提供企業支援層級的自動註冊。佈建程序會開啟帳戶的支援票證，請求將其新增至 AWS 企業支援計劃。 若要啟用企業支援選項，請在 AFT 部署輸入組態中將下列功能旗標設為 **True**。 ``` aft_feature_enterprise_support=false ``` 請參閱[比較 AWS 支援計劃](https://aws.amazon.com/premiumsupport/plans/)以進一步了解 AWS 支援計劃。 **注意** 若要允許此功能運作，您必須將付款人帳戶註冊到企業支援計劃中。 ## 刪除 AWS 預設 VPC 當您啟用此選項時，即使尚未在這些 中部署 AWS Control Tower 資源 AWS 區域，AFT 仍會刪除 AFT 管理帳戶和 中的所有 AWS 預設 VPCs AWS 區域。 AFT 不會自動刪除 AFT 佈建的任何 AWS Control Tower 帳戶或您透過 AFT 註冊 AWS Control Tower 的現有 AWS 帳戶 AWS 的預設 VPCs。 根據預設 AWS 區域，會在每個 中設定 VPC 來建立新 AWS 帳戶。您的企業可能有建立 VPCs的標準實務，這需要您刪除 AWS 預設 VPC 並避免啟用它，尤其是 AFT 管理帳戶。 若要啟用此選項，請在 AFT 部署輸入組態中將下列功能旗標設為 **True**。 ``` aft_feature_delete_default_vpcs_enabled ``` 以下是 AFT 部署輸入組態的範例。 ``` module "aft" { source = "github.com/aws-ia/terraform-aws-control_tower_account_factory" ct_management_account_id = var.ct_management_account_id log_archive_account_id = var.log_archive_account_id audit_account_id = var.audit_account_id aft_management_account_id = var.aft_management_account_id ct_home_region = var.ct_home_region tf_backend_secondary_region = var.tf_backend_secondary_region vcs_provider = "github" account_request_repo_name = "${var.github_username}/learn-terraform-aft-account-request" account_provisioning_customizations_repo_name = "${var.github_username}/learn-terraform-aft-account-provisioning-customizations" global_customizations_repo_name = "${var.github_username}/learn-terraform-aft-global-customizations" account_customizations_repo_name = "${var.github_username}/learn-terraform-aft-account-customizations" # Optional Feature Flags aft_feature_delete_default_vpcs_enabled = true aft_feature_cloudtrail_data_events = false aft_feature_enterprise_support = false } ``` 請參閱[預設 VPC 和預設子網路](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html)，進一步了解預設 VPCs。 # 適用於 Terraform 的 AWS Control Tower 帳戶工廠的資源考量事項 當您使用 AWS Control Tower Account Factory for Terraform 設定登陸區域時，會在 AWS 您的帳戶內建立數種類型的 AWS 資源。 **搜尋資源** + 您可以使用標籤來搜尋最新的 AFT 資源清單。您搜尋的鍵/值對為： ``` Key: managed_by | Value: AFT ``` + 對於不支援標籤的元件服務，您可以在資源名稱`aft`中找到搜尋 的資源。 **注意** AFT 不會在管理帳戶中建立任何 AWS Backup 資源。 **帳戶最初建立的資源資料表** **適用於 Terraform 管理帳戶的 AWS Control Tower 帳戶工廠** | **AWS 服務** | **Resource Type (資源類型)** | **資源名稱** | | --- | --- | --- | | AWS Identity and Access Management | 角色 | AWSAFTAdmin AWSAFTExecution AWSAFTService ct-aft-\$1 aft-\$1 codebuild\$1trigger\$1role python-layer-builder-aft-common-\$1 | | AWS Identity and Access Management | 政策 | aft-\$1 | | CodeCommit： | 儲存庫 | aft-\$1 | | CodeBuild： | 組建專案 | aft-\$1 ct-aft-\$1 python-layer-builder-aft-common-\$1 | | 程式碼管道 | 管道 | **YourAccountId**-customizations-pipeline | | Amazon S3 | 儲存貯體 | aft-\$1 | | Lambda | 函數 | aft-\$1 | | Lambda | 層 | aft-common-\$1 | | DynamoDB | 表格 | aft-request aft-request-audit aft-request-metadata aft-controltower-events | | 步驟函數 | 狀態機器 | aft-account-provisioning-customizations aft-account-provisioning-framework aft-feature-options aft-invoke-customizations | | VPC | VPC | aft-management-vpc | | Amazon SNS | 主題 | aft-notifications aft-failure-notifications | | Amazon EventBridge | 事件匯流排 | aft-events-from-ct-management | | Amazon EventBridge | 事件規則 | aft-account-provisioning-customizations-trigger aft-account-request-codepipeline-trigger aft-lambda-account-request-processor aft-controltower-event-logger | | Key Management Service (KMS) | 客戶受管金鑰 | aft-backend-\$1-kms-key aft | | AWS Systems Manager | 參數存放區 | /aft/\$1 | | Amazon SQS | 佇列 | aft-account-request.fifo aft-account-request-dlg.fifo | | CloudWatch | 日誌群組 | /aws/\$1/ct-aft-\$1 /aws/\$1/aft-\$1 /aws/codebuild/python-layer-builder-aft-common-\$1 | | AWS 備份 | 保存庫 | aft-controltower-backup-vault | | AWS 備份 | 計劃 | aft-controltower-backup-plan | | AWS 支援中心 （選用） | 支援計劃 | Enterprise | **AWS 透過 AWS Control Tower Account Factory for Terraform 佈建的帳戶** | **AWS 服務** | **Resource Type (資源類型)** | **資源名稱** | | --- | --- | --- | | AWS Identity and Access Management | 角色 | AWSAFTExecution | | AWS 支援中心 （選用） | 支援計劃 | Enterprise | **AWS Control Tower 管理帳戶** | **AWS 服務** | **Resource Type (資源類型)** | **資源名稱** | | --- | --- | --- | | AWS Identity and Access Management | 角色 | AWSAFTExecution AWSAFTService aft-controltower-events-rule | | AWS Systems Manager | 參數存放區 | /aft/\$1 | | EventBridge | 事件規則 | aft-capture-ct-events | | CloudTrail （選用） | 線索 | aws-aft-CustomizationsCloudTrail | | AWS Support Center （選用） | 支援計劃 | Enterprise | **AWS Control Tower 日誌封存帳戶** | **AWS 服務** | **Resource Type (資源類型)** | **資源名稱** | | --- | --- | --- | | AWS Identity and Access Management | 角色 | AWSAFTExecution AWSAFTService | | Key Management Service (KMS) | 客戶受管金鑰 | aft | | Amazon S3 | 儲存貯體 | aws-aft-logs-\$1 aws-aft-s3-access-logs-\$1 | | AWS 支援中心 （選用） | 支援計劃 | Enterprise | **AWS Control Tower 稽核帳戶** | **AWS 服務** | **Resource Type (資源類型)** | **資源名稱** | | --- | --- | --- | | AWS Identity and Access Management | 角色 | AWSAFTExecution AWSAFTService | | AWS 支援中心 （選用） | 支援計劃 | Enterprise | # 必要角色 一般而言，角色和政策是 中身分和存取管理 (IAM) 的一部分 AWS。如需詳細資訊，請參閱 [https://docs.aws.amazon.com//IAM/latest/UserGuide/introduction.html](https://docs.aws.amazon.com//IAM/latest/UserGuide/introduction.html)。 AFT 會在 AFT 管理和 AWS Control Tower 管理帳戶中建立多個 IAM 角色和政策，以支援 AFT 管道的操作。這些角色是根據最低權限存取模型建立的，這會限制對每個角色和政策的最低必要動作和資源集的許可。這些角色和政策會獲指派 AWS 標籤`key:value`對，` managed_by:AFT`用於識別。 除了這些 IAM 角色之外，AFT 還會建立三個基本角色： + `AWSAFTAdmin` 角色 + `AWSAFTExecution` 角色 + `AWSAFTService` 角色 以下各節會說明這些角色。 **AWSAFTAdmin 角色，說明** 當您部署 AFT 時，`AWSAFTAdmin`角色會在 AFT 管理帳戶中建立。此角色允許 AFT 管道擔任 AWS Control Tower 和 AFT 佈建帳戶中`AWSAFTExecution`的角色，藉此執行與帳戶佈建和自訂相關的動作。 以下是連接到`AWSAFTAdmin`角色的內嵌政策 (JSON 成品）： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::*:role/AWSAFTExecution", "arn:aws:iam::*:role/AWSAFTService" ] } ] } ``` ------ 下列 JSON 成品顯示`AWSAFTAdmin`角色的信任關係。預留位置號碼`012345678901`會由 AFT 管理帳戶 ID 號碼取代。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::012345678901:root" }, "Action": "sts:AssumeRole" } ] } ``` ------ **AWSAFTExecution 角色，說明** 部署 AFT 時，`AWSAFTExecution`角色會在 AFT 管理和 AWS Control Tower 管理帳戶中建立。稍後，AFT 管道會在 AFT 帳戶佈建階段期間，在每個 AFT 佈建帳戶中建立`AWSAFTExecution`角色。 AFT 一開始會利用`AWSControlTowerExecution`角色，在指定的帳戶中建立`AWSAFTExecution`角色。此`AWSAFTExecution`角色可讓 AFT 管道針對 AFT 佈建帳戶和共用帳戶，執行在 AFT 架構佈建和佈建自訂階段期間執行的步驟。 **不同的角色可協助您限制範圍** 最佳實務是將自訂許可與 資源初始部署期間允許的許可分開。請記住，`AWSAFTService`角色適用於帳戶佈建，而`AWSAFTExecution`角色適用於帳戶自訂。此分隔會限制管道每個階段期間允許的許可範圍。如果您自訂 AWS Control Tower 共用帳戶，此區別尤其重要，因為共用帳戶可能包含敏感資訊，例如帳單詳細資訊或使用者資訊。 `AWSAFTExecution` 角色的許可： **AdministratorAccess** – AWS 受管政策 下列 JSON 成品顯示連接至`AWSAFTExecution`角色的 IAM 政策 （信任關係）。預留位置號碼`012345678901`會由 AFT 管理帳戶 ID 號碼取代。 的信任政策 `AWSAFTExecution` ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::012345678901:role/AWSAFTAdmin" }, "Action": "sts:AssumeRole" } ] } ``` ------ **AWSAFTService 角色，說明** 此`AWSAFTService`角色會在所有已註冊和受管帳戶中部署 AFT 資源，包括共用帳戶和管理帳戶。先前僅由 `AWSAFTExecution`角色部署的資源。 該`AWSAFTService`角色旨在供服務基礎設施在佈建階段期間部署資源，而該`AWSAFTExecution`角色僅用於部署自訂。透過以此方式擔任角色，您可以在每個階段維持更精細的存取控制。 `AWSAFTService` 角色的許可： **AdministratorAccess** – AWS 受管政策 下列 JSON 成品顯示連接至`AWSAFTService`角色的 IAM 政策 （信任關係）。預留位置號碼`012345678901`會由 AFT 管理帳戶 ID 號碼取代。 的信任政策 `AWSAFTService` ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::012345678901:role/AWSAFTAdmin" }, "Action": "sts:AssumeRole" } ] } ``` ------ # 元件服務 當您部署 AFT 時，元件會從每個 AWS 服務新增至您的 AWS 環境。 + **[AWS Control Tower](https://docs.aws.amazon.com//controltower/latest/userguide/what-is-control-tower.html)** – AFT 使用 AWS Control Tower 管理帳戶中的 AWS Control Tower 帳戶工廠來佈建帳戶。 + **[Amazon DynamoDB](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/Introduction.html)** – AFT 會在 AFT 管理帳戶中建立 Amazon DynamoDB 資料表，以存放帳戶請求、帳戶更新稽核歷史記錄、帳戶中繼資料和 AWS Control Tower 生命週期事件。AFT 也會建立 DynamoDB Lambda 觸發來啟動下游程序，例如啟動 AFT 帳戶佈建工作流程。 + **[Amazon Simple Storage Service](https://docs.aws.amazon.com//AmazonS3/latest/userguide/Welcome.html)** – AFT 會在 AFT 管理帳戶和 AWS Control Tower 日誌封存帳戶中建立 Amazon Simple Storage Service (S3) 儲存貯體，以存放 AFT 管道所需的 AWS 服務所產生的日誌。AFT 也會在主要和次要 中建立 Terraform 後端 S3 儲存貯體 AWS 區域，以存放 AFT 管道工作流程期間產生的 Terraform 狀態。 + **[Amazon Simple Notification Service](https://docs.aws.amazon.com//sns/latest/dg/welcome.html)** – AFT 會在 AFT 管理帳戶中建立 Amazon Simple Notification Service (SNS) 主題，該主題會在處理每個 AFT 帳戶請求後儲存成功和失敗通知。您可能會使用您選擇的通訊協定來接收這些訊息。 + **[Amazon Simple Queuing Service](https://docs.aws.amazon.com//AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)** – AFT 在 AFT 管理帳戶中建立 Amazon Simple Queuing Service (Amazon SQS) FIFO 佇列。佇列可讓您平行提交多個帳戶請求，但一次傳送一個請求給 AWS Control Tower 帳戶工廠，以進行循序處理。 + **[AWS CodeBuild](https://docs.aws.amazon.com//codebuild/latest/userguide/welcome.html)** – AFT 在 AFT 管理帳戶中建立 AWS CodeBuild 組建專案，以在各種組建階段初始化、編譯、測試和套用 AFT 原始程式碼的 Terraform 計劃。 + **[AWS CodePipeline](https://docs.aws.amazon.com//codepipeline/latest/userguide/welcome.html)** – AFT 在 AFT 管理帳戶中建立 AWS CodePipeline 管道，以與您所選、支援的 AFT 原始碼 AWS CodeStar 連線供應商整合，並在 AWS CodeBuild 中觸發建置任務。 + **[AWS Lambda](https://docs.aws.amazon.com//lambda/latest/dg/welcome.html)** – AFT 在 AFT 管理帳戶中建立 AWS Lambda 函數和層，以在帳戶請求、AFT 帳戶佈建和帳戶自訂程序期間執行步驟。 + **[AWS Systems Manager 參數存放](https://docs.aws.amazon.com//systems-manager/latest/userguide/systems-manager-parameter-store.html)**區 – AFT 會在 AFT 管理帳戶中設定 AWS Systems Manager 參數存放區，以存放 AFT 管道程序所需的組態參數。 + **[Amazon CloudWatch](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)** – AFT 在 AFT 管理帳戶中建立 Amazon CloudWatch 日誌群組，以存放由 AFT 管道使用之 AWS 服務產生的日誌。CloudWatch 日誌的保留期間設定為 `Never Expire`。 + **[Amazon VPC](https://docs.aws.amazon.com//vpc/latest/userguide/what-is-amazon-vpc.html)** – AFT 建立 Amazon Virtual Private Cloud (VPC)，將 AFT 管理帳戶中的服務和資源隔離到單獨的聯網環境中，以提高安全性。 + **[AWS KMS](https://docs.aws.amazon.com//kms/latest/developerguide/overview.html)** – AFT 在 AWS Key Management Service (KMS)。AFT 會建立金鑰來加密 Terraform 狀態、存放在 DynamoDB 資料表中的資料，以及 SNS 主題。這些日誌和成品會在 AFT 部署 AWS 資源和服務時產生。AFT 建立的 KMS 金鑰預設會啟用每年輪換。 + **[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com//IAM/latest/UserGuide/introduction.html)** – AFT 遵循建議的最低權限模型。它會視需要在 AFT 管理帳戶、AWS Control Tower 帳戶和 AFT 佈建帳戶中建立 AWS Identity and Access Management (IAM) 角色和政策，以在 AFT 管道工作流程期間執行所需的動作。 + **[AWS Step Functions](https://docs.aws.amazon.com//step-functions/latest/dg/welcome.html)** – AFT 在 AFT 管理帳戶中建立 AWS Step Functions 狀態機器。這些狀態機器會協調和自動化 AFT 帳戶佈建架構和自訂的程序和步驟。 + **[Amazon EventBridge](https://docs.aws.amazon.com//eventbridge/latest/userguide/eb-what-is.html)** – AFT 在 AFT 和 AWS Control Tower 管理帳戶中建立 Amazon EventBridge 事件匯流排，以在 AFT 管理帳戶的 DynamoDB 資料表中長期擷取和存放 AWS Control Tower 生命週期事件。AFT 在 AFT 管理和 AWS Control Tower 管理帳戶中建立 Amazon CloudWatch 事件規則，這會觸發執行 AFT 管道工作流程期間所需的多個步驟 + **[AWS CloudTrail （選用）](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/cloudtrail-user-guide.html)** – 啟用此功能時，AFT 會在 AWS Control Tower 管理帳戶中建立 AWS CloudTrail 組織追蹤，用於記錄 Amazon S3 儲存貯體和 AWS Lambda 函數的資料事件。AFT 會將這些日誌傳送至 AWS Control Tower 日誌封存帳戶中的中央 S3 儲存貯體。 + **[AWS 支援 （選用）](https://aws.amazon.com//premiumsupport/)** – 啟用此功能時，AFT 會為 AFT 佈建的帳戶開啟 AWS 企業支援計劃。根據預設， AWS 帳戶會在基本 AWS 支援計劃啟用的情況下建立。 # AFT 帳戶佈建管道 管道的帳戶佈建階段完成後，AFT 架構會繼續。它會自動執行一系列步驟，以確保新佈建的帳戶在[帳戶自訂](aft-account-customization-options.md)階段開始之前擁有詳細資訊。 **以下是 AFT 管道執行的後續步驟。** 1. 驗證帳戶請求輸入。 1. 擷取已佈建帳戶的相關資訊，例如帳戶 ID。 1. 將帳戶中繼資料存放在 AFT 管理帳戶中的 DynamoDB 資料表中。 1. 在新佈建的帳戶中建立 **AWSAFTExecution** IAM 角色。AFT 會擔任此角色來執行帳戶自訂階段，因為此角色會授予帳戶工廠產品組合的存取權。 1. 套用您在帳戶請求輸入參數中提供的帳戶標籤。 1. 套用您在 AFT 部署時選擇的 AFT 功能選項。 1. 套用您提供的 AFT 帳戶佈建自訂。下一節說明如何在`git`儲存庫中使用 AWS Step Functions 狀態機器設定這些自訂。此階段有時稱為*帳戶佈建架構*階段。這是核心佈建程序的一部分，但您先前已設定架構，在帳戶佈建工作流程中提供自訂整合，然後再將其他自訂新增至下一個階段的帳戶。 1. 對於每個佈建的帳戶，它會 AWS CodePipeline 在 AFT 管理帳戶中建立 ，該帳戶將執行以執行 （下一個、全域） [帳戶自訂](aft-account-customization-options.md)階段。 1. 叫用每個佈建 （和目標） 帳戶的帳戶自訂管道。 1. 傳送成功或失敗通知至 SNS 主題，您可以從中擷取訊息。 ## 使用狀態機器設定帳戶佈建架構自訂 如果您在佈建帳戶之前設定自訂、非 Terraform 整合，這些自訂會包含在 AFT 帳戶佈建工作流程中。例如，您可能需要特定自訂，以確保 AFT 建立的所有帳戶都符合組織的標準和政策，例如安全標準，而且這些標準可能會在其他自訂之前新增至帳戶。這些*帳戶佈建架構*自訂會在每個佈建帳戶上實作，之後才開始全球帳戶自訂階段。 **注意** 本節所述的 AFT 功能適用於了解 AWS Step Functions 功能的進階使用者。或者，我們建議您在帳戶自訂階段與全球協助程式合作。 AFT 帳戶佈建架構會呼叫您定義的 AWS Step Functions 狀態機器，以實作您的自訂。請參閱 [AWS Step Functions 文件](https://docs.aws.amazon.com//step-functions/latest/dg/welcome.html)，進一步了解可能的 狀態機器整合。 以下是一些常見的整合。 + 您選擇的語言 AWS Lambda 函數 + AWS ECS 或 AWS Fargate 任務，使用 Docker 容器 + 使用自訂工作者的 AWS Step Functions 活動，託管於 AWS 或內部部署 + Amazon SNS 或 SQS 整合 如果未定義 AWS Step Functions 狀態機器，則階段會通過無操作。若要建立 AFT 帳戶佈建自訂狀態機器，請遵循 中的指示[建立您的 AFT 帳戶佈建自訂狀態機器](#aft-create-customizations)。新增自訂之前，請確定您已備妥先決條件。 這些類型的整合不屬於 AWS Control Tower，而且無法在 AFT 帳戶自訂的全域預先 API 階段期間新增。反之，AFT 管道可讓您將這些自訂設定為佈建程序的一部分，並在佈建工作流程中執行。您必須在啟動 AFT 帳戶佈建階段之前，事先建立您的狀態機器來實作這些自訂，如以下各節所述。 **建立狀態機器的先決條件** + 完全部署的 AFT。如需 AFT 部署的詳細資訊[部署適用於 Terraform (AFT) 的 AWS Control Tower 帳戶工廠](aft-getting-started.md)，請參閱 。 + 在您的環境中設定儲存`git`庫以進行 AFT 帳戶佈建自訂。如需詳細資訊，請參閱[部署後步驟](aft-post-deployment.md)。 ## 建立您的 AFT 帳戶佈建自訂狀態機器 **步驟 1：修改狀態機器定義** 修改範例`customizations.asl.json`狀態機器定義。此範例在您為儲存 AFT 帳戶佈建自訂而設定的儲存`git`庫中可用，位於[部署後步驟](https://docs.aws.amazon.com//controltower/latest/userguide/aft-post-deployment.html)中。請參閱 [AWS Step Functions 開發人員指南](https://docs.aws.amazon.com//step-functions/latest/dg/welcome.html)，進一步了解狀態機器定義。 **步驟 2：包含對應的 Terraform 組態** 在具有自訂整合狀態機器定義的相同`git`儲存庫中包含`.tf`副檔名的 Terraform 檔案。例如，如果您選擇在狀態機器任務定義中呼叫 Lambda 函數，您會在相同的目錄中包含 `lambda.tf` 檔案。請務必包含自訂組態所需的 IAM 角色和許可。 當您提供適當的輸入時，AFT 管道會自動調用您的狀態機器，並將您的自訂部署為 AFT 帳戶佈建架構階段的一部分。 ## 重新啟動 AFT 帳戶佈建架構和自訂 AFT 會針對透過 AFT 管道提供的每個帳戶執行帳戶佈建架構和自訂步驟。若要重新啟動帳戶佈建自訂，您可以使用下列兩種方法之一： 1. 對帳戶請求儲存庫中的現有帳戶進行任何變更。 1. 使用 AFT 佈建新帳戶。 # 帳戶自訂 AFT 可以在佈建帳戶中部署標準或自訂組態。在 AFT 管理帳戶中，AFT 為每個帳戶提供一個管道。使用此管道，您可以在所有帳戶、一組帳戶或個別帳戶中實作自訂。您可以執行 Python 指令碼、Bash 指令碼和 Terraform 組態，也可以在帳戶自訂階段中與 AWS CLI 互動。 ## 概觀 在您選擇的`git`儲存庫中指定自訂之後，無論是存放全域自訂的儲存庫，或是存放帳戶自訂的儲存庫，帳戶自訂階段都會由 AFT 管道自動完成。若要追溯自訂帳戶，請參閱 [重新叫用自訂](#aft-re-invoke-customizations)。 **全域自訂 （選用）** 您可以選擇將特定自訂套用至 AFT 佈建的所有帳戶。例如，如果您需要建立特定 IAM 角色，或在每個帳戶中部署自訂控制項，則 AFT 管道中的全域自訂階段可讓您自動執行此操作。 **帳戶自訂 （選用）** 若要自訂個別帳戶或一組帳戶，與其他 AFT 佈建帳戶不同，您可以利用 AFT 管道的帳戶自訂部分來實作帳戶特定的組態。例如，只有特定帳戶可能需要存取網際網路閘道。 ## 自訂先決條件 開始自訂帳戶之前，請確定已備妥這些先決條件。 + 完全部署的 AFT。如需如何部署的資訊，請參閱 [設定和啟動適用於 Terraform 的 AWS Control Tower 帳戶工廠](aft-getting-started.md#aft-configure-and-launch)。 + 預先填入`git`的儲存庫，用於您環境中的全域自訂和帳戶自訂。如需詳細資訊[部署後步驟](aft-post-deployment.md)，請參閱 中的*步驟 3：填入每個儲存庫*。 ## 套用全域自訂 若要套用全域自訂，您必須將特定資料夾結構推送至您選擇的儲存庫。 + 如果您的自訂組態採用 Python 程式或指令碼的形式，請將這些組態放在儲存庫的 **api\$1helpers/python** 資料夾下。 + 如果您的自訂組態採用 Bash 指令碼形式，請將這些組態放在儲存庫的 **api\$1helpers** 資料夾下。 + 如果您的自訂組態採用 Terraform 格式，請將它們放在儲存庫中的 **terraform** 資料夾下。 + 如需建立自訂組態的詳細資訊，請參閱全域自訂 README 檔案。 **注意** 在 AFT 管道的 AFT 帳戶佈建架構階段之後，會自動套用全域自訂。 ## 套用帳戶自訂 **** 您可以將特定資料夾結構推送至您選擇的儲存庫，以套用帳戶自訂。帳戶自訂會在 AFT 管道和全域自訂階段之後自動套用。您也可以在帳戶自訂儲存庫中建立多個資料夾，其中包含不同的帳戶自訂。對於您需要的每個帳戶自訂，請使用下列步驟。 **套用帳戶自訂** 1. ** 步驟 1：為帳戶自訂建立資料夾 ** 在您選擇的儲存庫中，將 AFT 提供的`ACCOUNT_TEMPLATE`資料夾複製到新資料夾。新資料夾的名稱應與`account_customizations_name`您在帳戶請求中提供的 相符。 1. ** 將組態新增至您的特定帳戶自訂資料夾 ** 您可以根據組態的格式，將組態新增至您的帳戶自訂資料夾。 + 如果您的自訂組態採用 Python 程式或指令碼的形式，請將它們放在儲存庫中的 ***【account\$1customizations\$1name】*/api\$1helpers/python** 資料夾下。 + 如果您的自訂組態是 Bash 指令碼的形式，請將它們放在儲存庫中的 ***【account\$1customizations\$1name】*/api\$1helpers** 資料夾下。 + 如果您的自訂組態採用 Terraform 格式，請將它們放在儲存庫中的 ***【account\$1customizations\$1name】*/terraform** 資料夾下。 如需建立自訂組態的詳細資訊，請參閱帳戶自訂 README 檔案。 1. ** 請參閱帳戶請求檔案中的特定`account_customizations_name`參數 ** AFT 帳戶請求檔案包含輸入參數 `account_customizations_name`。輸入您帳戶自訂的名稱做為此參數的值。 **注意** 您可以為環境中的帳戶提交多個帳戶請求。當您想要套用不同或類似的帳戶自訂時，請在帳戶請求中使用`account_customizations_name`輸入參數來指定帳戶自訂。如需詳細資訊，請參閱[提交多個帳戶請求](https://docs.aws.amazon.com/controltower/latest/userguide/aft-multiple-account-requests.html)。 ## 重新叫用自訂 AFT 提供在 AFT 管道中重新叫用自訂項目的方法。當您新增新的自訂步驟，或變更現有的自訂時，此方法非常有用。當您重新叫用 時，AFT 會啟動自訂管道，以對 AFT 佈建帳戶進行變更。event-source-based重新叫用可讓您將自訂套用至個別帳戶、所有帳戶、根據其 OU 的帳戶，或根據標籤選取的帳戶。 請依照這三個步驟，為 AFT 佈建的帳戶重新叫用自訂。 **步驟 1：將變更推送至全域或帳戶自訂`git`儲存庫** 您可以視需要更新全域和帳戶自訂，並將變更推回`git`儲存庫。此時，不會發生任何情況。自訂管道必須由事件來源調用，如接下來兩個步驟所述。 **步驟 2：啟動 AWS Step Function 執行以重新叫用自訂** AFT 提供在 AFT 管理帳戶中呼叫`aft-invoke-customizations`的 AWS Step Function。該函數的目的是為 AFT 佈建的帳戶重新調用自訂管道。 以下是您可以建立以將輸入傳遞至 `aft-invoke-customizations` AWS Step Function 的事件結構描述 (JSON 格式） 範例。 ``` { "include": [ { "type": "all" }, { "type": "ous", "target_value": [ "ou1","ou2"] }, { "type": "tags", "target_value": [ {"key1": "value1"}, {"key2": "value2"}] }, { "type": "accounts", "target_value": [ "acc1_ID","acc2_ID"] } ], "exclude": [ { "type": "ous", "target_value": [ "ou1","ou2"] }, { "type": "tags", "target_value": [ {"key1": "value1"}, {"key2": "value2"}] }, { "type": "accounts", "target_value": [ "acc1_ID","acc2_ID"] } ] } ``` 範例事件結構描述顯示您可以選擇要包含在重新叫用程序中或從中排除的帳戶。您可以依組織單位 (OU)、帳戶標籤和帳戶 ID 進行篩選。如果您未套用任何篩選條件並包含陳述式 `"type":"all"`，則會重新叫用所有 AFT 佈建帳戶的自訂。 **注意** 如果您的 AWS Control Tower Account Factory for Terraform (AFT) 版本為 1.6.5 或更新版本，您可以使用語法 鎖定巢狀 OUs`OU Name (ou-id-1234`)。如需詳細資訊，請參閱 [GitHub](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/issues/280) 上的下列主題。 在您填寫事件參數之後，Step Functions 會執行並叫用對應的自訂。AFT 一次最多可以叫用 5 個自訂項目。Step Functions 會等待 和 迴圈，直到符合事件條件的所有帳戶都完成為止。 **步驟 3：監控 AWS Step Function 輸出並監看執行中的 AWS CodePipeline ** + 產生的 Step Function 輸出包含符合 Step Function 輸入事件來源的帳戶 IDs。 + 導覽至**開發人員工具**下的 AWS CodePipeline，並檢視帳戶 ID 對應的自訂管道。 ## 使用 AFT 帳戶自訂請求追蹤進行故障診斷 基於 AWS Lambda 的帳戶自訂工作流程會發出包含目標帳戶和自訂請求 IDs日誌。AFT 可讓您使用 Amazon CloudWatch Logs 追蹤和疑難排解自訂請求，方法是提供 CloudWatch Logs Insights 查詢，您可以使用這些查詢來依目標帳戶或自訂請求 ID 篩選與自訂請求相關的 CloudWatch Logs。如需詳細資訊，請參閱《[Amazon CloudWatch Logs 使用者指南》中的使用 Amazon CloudWatch Logs 分析日誌資料](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)。 *Amazon CloudWatch * **使用適用於 AFT 的 CloudWatch Logs Insights** 1. 透過 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 開啟 CloudWatch 主控台。 1. 從導覽窗格中，選擇**日誌**，然後選擇**日誌洞察**。 1. 選擇**查詢**。 1. 在**範例查詢**下，選擇**適用於 Terraform 的帳戶工廠**，然後選取下列其中一個查詢： + **依帳戶 ID 的自訂日誌** **注意** 請務必將 *"YOUR-ACCOUNT-ID"* 取代為您的目標帳戶 ID。 ``` fields @timestamp, log_message.account_id as target_account_id, log_message.customization_request_id as customization_request_id, log_message.detail as detail, @logStream | sort @timestamp desc | filter log_message.account_id == "YOUR-ACCOUNT-ID" and @message like /customization_request_id/ ``` + **依自訂請求 ID 的自訂日誌** **注意** 請務必使用自訂請求 ID 取代 *"YOUR-CUSTOMIZATION-REQUEST-ID"*。您可以在 AFT 帳戶佈建架構 AWS Step Functions 狀態機器的輸出中找到自訂請求 ID。如需 AFT 帳戶佈建架構的詳細資訊，請參閱 [AFT 帳戶佈建管道](https://docs.aws.amazon.com/controltower/latest/userguide/aft-provisioning-framework.html) ``` fields @timestamp, log_message.account_id as target_account_id, log_message.customization_request_id as customization_request_id, log_message.detail as detail, @logStream | sort @timestamp desc | filter log_message.customization_request_id == "YOUR-CUSTOMIZATION-REQUEST-ID" ``` 1. 選取查詢之後，請務必選取時間間隔，然後選擇**執行查詢**。 # AFT 中原始程式碼版本控制的替代方案 AFT AWS CodeCommit 用於原始程式碼版本控制系統 (VCS)，並允許其他 [CodeConnections](https://docs.aws.amazon.com//dtconsole/latest/userguide/supported-versions-connections.html) 符合您業務需求或現有架構。 如果您是第一次部署 AFT，而且沒有現有的 CodeCommit 儲存庫，則必須指定外部 VCS 供應商，做為 AFT 部署先決條件的一部分。 **AFT 支援下列原始程式碼控制替代方案：** + GitHub + GitHub Enterprise Server + BitBucket + GitLab + GitLab 自我管理 **注意** 如果您將 指定 AWS CodeCommit 為 VCS，則不需要其他步驟。AFT 會在您的環境中使用預設名稱建立必要的`git`儲存庫。不過，您可以視需要覆寫 CodeCommit 的預設儲存庫名稱，以符合您的組織標準。 ## 使用 AFT 設定替代原始程式碼版本控制系統 （自訂 VCS) 若要為您的 AFT 部署設定替代原始程式碼版本控制系統，請遵循下列步驟。 **步驟 1：在支援的第三方版本控制系統 (VCS) 中建立`git`儲存庫。** 如果您未使用 AWS CodeCommit，則必須在 AFT 支援的第三方 VCS 提供者環境中為下列項目建立`git`儲存庫。 + **AFT 帳戶請求。**[可用的範本程式碼](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-request) 。如需 AFT 帳戶請求的詳細資訊，請參閱 [使用 AFT 佈建新帳戶](aft-provision-account.md)。 + **AFT 帳戶佈建自訂。**[可用的範本程式碼](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-provisioning-customizations) 。如需 AFT 帳戶佈建自訂的詳細資訊，請參閱 [建立您的 AFT 帳戶佈建自訂狀態機器](aft-provisioning-framework.md#aft-create-customizations)。 + **AFT 全域自訂。**[可用的範本程式碼](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-global-customizations) 。如需 AFT 全域自訂的詳細資訊，請參閱 [帳戶自訂](aft-account-customization-options.md)。 + **AFT 帳戶自訂。**[可用的範本程式碼](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-customizations) 。如需 AFT 帳戶自訂的詳細資訊，請參閱 [帳戶自訂](aft-account-customization-options.md)。 **步驟 2：指定 AFT 部署所需的 VCS 組態參數** 需要下列輸入參數，才能將 VCS 提供者設定為 AFT 部署的一部分。 + **vcs\$1provider**：如果您未使用 AWS CodeCommit，`"gitlab"`請根據您的使用案例將 VCS 提供者指定為 `"bitbucket"`、`"githubenterprise"`、 `"github"`或 。 + **github\$1enterprise\$1url**：僅限 GitHub Enterprise 客戶，請指定 GitHub URL。 + **account\$1request\$1repo\$1name**：對於 AWS CodeCommit 使用者，此值設定為 `aft-account-request`。在 AFT 支援的第三方 VCS 提供者環境中，使用實際儲存庫名稱更新此輸入值。對於 BitBucket、Github、GitHub Enterprise、GitLab 和 GitLab 自我管理，儲存庫名稱的格式必須是 `[Org]/[Repo]`。 + **account\$1customizations\$1repo\$1name**：對於 AWS CodeCommit 使用者，此值設定為 `aft-account-customizations`。在 AFT 支援的第三方 VCS 提供者環境中，使用儲存庫名稱更新此輸入值。對於 BitBucket、Github、GitHub Enterprise、GitLab 和 GitLab 自我管理，儲存庫名稱的格式必須是 `[Org]/[Repo]`。 + **account\$1provisioning\$1customizations\$1repo\$1name**：對於 AWS CodeCommit 使用者，此值設定為 `aft-account-provisioning-customizations`。在 AFT 支援的第三方 VCS 提供者環境中，使用儲存庫名稱更新此輸入值。對於 BitBucket、Github、GitHub Enterprise、GitLab 和 GitLab 自我管理，儲存庫名稱的格式必須是 `[Org]/[Repo]`。 + **global\$1customizations\$1repo\$1name**：對於 AWS CodeCommit 使用者，此值設定為 `aft-global-customizations`。在 AFT 支援的第三方 VCS 提供者環境中，使用儲存庫名稱更新此輸入值。對於 BitBucket、Github、GitHub Enterprise、GitLab 和 GitLab 自我管理，儲存庫名稱的格式必須是 `[Org]/[Repo]`。 + **account\$1request\$1repo\$1branch**：分支`main`預設為 ，但值可以覆寫。 根據預設，來自每個`git`儲存庫`main`分支的 AFT 來源。您可以使用額外的輸入參數覆寫分支名稱值。如需輸入參數的詳細資訊，請參閱 [AFT Terraform 模組](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/blob/main/README.md#inputs)中的 README 檔案。 **對於現有 AWS CodeCommit 客戶** 如果您使用 AFT 的新名稱建立 CodeCommit 儲存庫，您可以透過更新這些輸入參數的值來更新儲存庫名稱。 **步驟 3：完成第三方 VCS 提供者的 AWS CodeCommit 連線** 當您的部署執行時，AFT 會建立所需的 AWS CodeCommit 儲存庫，或者為您選擇的第三方 VCS 提供者建立 AWS CodeCommit 連線。如果是後者，您必須手動登入 AFT 管理帳戶的主控台，以完成待定的 CodeCommit 連線。如需[AWS CodeCommit 完成 CodeCommit 連線的進一步說明，請參閱 文件](https://docs.aws.amazon.com//dtconsole/latest/userguide/connections-update.html)。 CodeCommit # 將 AFT 從 AWS CodeCommit 移至另一個 VCS 供應商 本節提供如何將 AWS Control Tower Account Factory for Terraform (AFT) 從 AWS CodeCommit 做為版本控制系統 (VCS) 移至另一個 VCS 供應商的概觀。 **步驟 1. ** 在您選擇的 VCS 中設定新的儲存庫。 **步驟 2.** 在 中將這些儲存庫新增為新的遠端`git`。 **步驟 3.** 執行`git push`至新的 VCS 提供者。 **注意** 您建立的儲存庫結構應與 in AWS CodeCommit 相同。變更結構會阻礙 AFT 執行所需程式碼的能力。 aft-account-request aft-account-customizations aft-global-customizations aft-account-provisioning-customizations **步驟 4.** 在您的 AWS Control Tower 管理帳戶中，更新 Terraform 模組 （引導） 以指向您的 VCS 供應商，如下列範例所示： **範例：**[GitLab 搭配 Terraform OSS](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/blob/main/examples/gitlab%2Btf_oss/main.tf) – 執行 `terraform plan`以預覽變更，然後執行 `terraform apply`。 **步驟 5.** 完成步驟以完成 CodeConnection （先前稱為 CodeStar) 的設定： 1. 登入您的 AFT 管理帳戶 1. 找到並完成新 VCS 供應商的 pending AWS CodeConnections，如[更新待定連線](https://docs.aws.amazon.com/dtconsole/latest/userguide/connections-update.html)或 AWS 主控台 【`https://us-east-1.console.aws.amazon.com/codesuite/settings/connections`】 所述。 1. 參考：[部署後步驟](https://docs.aws.amazon.com//controltower/latest/userguide/aft-post-deployment.html) **注意** 帳戶管道會保留先前的來源，直到叫用 `aft-invoke-customizations` *Step Functions* 為止。此調用可以作為升級的一部分或作為下一次自訂調用的一部分來完成。 如需詳細資訊，請參閱此部落格：[如何將 AWS CodeCommit 儲存庫遷移至另一個 Git 供應商](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider)。 # 資料保護 [AWS 共同責任模型](https://aws.amazon.com//compliance/shared-responsibility-model/)適用於 AFT 中的資料保護。基於資料保護目的，我們建議採用下列安全性最佳實務。 + 遵循 AWS Control Tower 提供的資料保護指導方針。如需詳細資訊，請參閱[AWS Control Tower 中的資料保護](controltower-console-encryption.md)。 + 保留在 AFT 部署時產生的 Terraform 狀態組態。如需詳細資訊，請參閱[部署適用於 Terraform (AFT) 的 AWS Control Tower 帳戶工廠](aft-getting-started.md)。 + 根據您組織的安全政策，定期輪換敏感憑證。秘密的範例包括 Terraform 字符、`git`字符等。 **靜態加密** AFT 會建立使用 AWS Key Management Service 金鑰靜態加密的 Amazon S3 儲存貯體、Amazon SNS 主題、Amazon SQS 佇列和 Amazon DynamoDB 資料庫。AFT 建立的 KMS 金鑰預設會啟用每年輪換。如果您選擇 Terraform 的 Terraform Cloud 或 Terraform Enterprise 分佈，AFT 會包含 AWS Systems Manager SecureString 參數來存放敏感的 Terraform 字符值。 AFT 使用中所述的服務，[元件服務](aft-components.md)該 AWS 服務預設為靜態加密。如需詳細資訊，請參閱每個 AFT 元件 AWS 服務 AWS 的文件，並了解每個服務後面的資料保護實務。 **傳輸中加密** 根據預設，AFT 倚賴 中所述[元件服務](aft-components.md)使用傳輸中加密 AWS 的服務。如需詳細資訊，請參閱每個 AFT 元件 AWS 服務 AWS 的文件，並了解每個服務後面的資料保護實務。 對於 Terraform Cloud 或 Terraform Enterprise 分佈，AFT 會呼叫 HTTPS 端點 API 來存取您的 Terraform 組織。如果您選擇 AWS CodeStar 連線支援的第三方 VCS 提供者，AFT 會呼叫 HTTPS 端點 API 來存取您的 VCS 提供者組織。 # 從 AFT 移除帳戶 本主題說明如何從 AFT 移除帳戶，因此 AFT 管道會停止部署和更新帳戶。 **重要** 從 AFT 管道移除帳戶是無法復原的，可能會導致狀態遺失。 當您想要關閉已淘汰應用程式的帳戶、隔離遭入侵的帳戶，或將帳戶從一個組織移至另一個組織時，您可以從 AFT 中移除帳戶。 **注意** 從 AFT 移除帳戶不同於刪除 AWS Control Tower 帳戶或 AWS 帳戶。當您從 AFT 移除帳戶時，AWS Control Tower 仍會管理該帳戶。若要刪除 AWS Control Tower 帳戶或 AWS 帳戶，請參閱下列內容： 《*AWS Control Tower 使用者指南*》中的[取消管理帳戶](https://docs.aws.amazon.com/controltower/latest/userguide/unmanage-account.html)。 *AWS Billing 《 使用者指南*》中的[關閉帳戶](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/close-account.html)。 **從 AFT 管道移除帳戶** 下列程序說明如何從 AFT 移除帳戶。 1. ** 從儲存帳戶請求的儲存`git`庫移除帳戶 ** 在您存放帳戶請求的儲存`git`庫中，刪除您要從 AFT 中移除之帳戶的 帳戶請求。 當您從帳戶請求儲存庫移除帳戶請求時，AFT 會刪除自訂管道和帳戶中繼資料。如需詳細資訊，請參閱 GitHub 上 AFT 的 [1.8.0 版本備註](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/releases/tag/1.8.0)。 1. ** 刪除 Terraform 工作區 （僅適用於 Terraform Cloud 和 Terraform Enterprise 客戶） ** 刪除您要從 AFT 中移除之帳戶的全域自訂和帳戶自訂工作區。 1. ** 從 Amazon S3 後端刪除 Terraform 狀態 ** 在 AFT 管理帳戶中，刪除您要從 AFT 中移除之帳戶的 Amazon S3 儲存貯體內的所有相關資料夾。 **提示** 在下列範例中，將 取代`012345678901`為 AFT 管理帳戶 ID 號碼。 **範例：Terraform OSS** 當您選擇 Terraform OSS 時，您會在 `aft-backend-012345678901-primary-region`和 Amazon S3 儲存貯體中找到每個帳戶的 `aft-backend-012345678901-secondary-region` 3 個資料夾。 Amazon S3 這些資料夾與*帳戶自訂狀態*、*自訂管道狀態*和*全域自訂狀態*相關 **範例：Terraform Cloud 或 Terraform Enterprise** 當您選擇 Terraform Cloud 或 Terraform Enterprise 時，您會在 `aft-backend-012345678901-primary-region`和 Amazon S3 `aft-backend-012345678901-secondary-region` 儲存貯體中找到每個帳戶的資料夾。這些資料夾與*自訂管道狀態*相關。 # 操作指標 根據預設，*Account Factory for Terraform (AFT)* 會傳送匿名操作指標至 AWS。我們使用此資料來了解客戶如何使用 AFT，以便改善解決方案的品質和功能。您可以在 AFT 部署期間變更參數，以選擇退出資料收集。啟用收集時，會將下列資料傳送至 AWS： + **解決方案：**AFT 特定的識別符 + **版本：**AFT 的版本 + **全域唯一識別符 (UUID)：**每個 AFT 部署隨機產生的唯一識別符 + **時間戳記：**資料收集時間戳記 + **資料：**客戶採取的 AFT 組態和動作 AWS 擁有收集的資料。資料收集受 [AWS 隱私權政策](https://aws.amazon.com/privacy/)的約束。 **注意** 1.6.0 之前的 AFT 版本不會向 報告用量指標。 AWS 若要選擇退出報告指標： + `aft_metrics_reporting` `false` 將 Terraform 輸入組態檔案中的輸入值設定為 ，如以下範例所示，然後重新部署 AFT。如果您未明確設定，則此值`true`預設為 。 如果您複製範例，請記得以 取代字串中給定項目的實際 ID 和區域值`x`。 ``` module "control_tower_account_factory" { source = "aws-ia/control_tower_account_factory/aws" # Required Vars ct_management_account_id = "xxxxxxxxxxx" log_archive_account_id = "xxxxxxxxxxx" audit_account_id = "xxxxxxxxxxx" aft_management_account_id = "xxxxxxxxxxx" ct_home_region = "xx-xxxx-x" tf_backend_secondary_region = "xx-xxxx-x" # Optional Vars aft_metrics_reporting = false # to opt out, set this value to false } ``` # Account Factory for Terraform (AFT) 疑難排解指南 本節可協助您針對使用 Account Factory for Terraform (AFT) 時可能遇到的常見問題進行疑難排解。 **Topics** + [一般問題](#w2aac44c33c45b7) + [與帳戶佈建/註冊相關的問題](#w2aac44c33c45b9) + [與自訂調用相關的問題](#w2aac44c33c45c11) + [與帳戶自訂工作流程相關的問題](#w2aac44c33c45c13) ## 一般問題 + **超過 AWS 資源配額** 如果您的日誌群組指出您超過 AWS 資源配額，請聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。Account Factory 使用 AWS 服務 與包含 AWS CodeBuild AWS Organizations和 的資源配額 AWS Systems Manager。如需詳細資訊，請參閱下列內容： + *CodeBuild 使用者指南*中的什麼[是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)。 + 《 *Organizations 使用者指南*》中的[什麼是 AWS Organizations？](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)。 + Systems *Manager 使用者指南*中的[什麼是 AWS Systems Manager？](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html)。 + **Account Factory 的過時版本 ** 如果您遇到問題，且認為問題是錯誤，請確定您擁有最新版的 Account Factory。如需詳細資訊，請參閱[更新 Account Factory 版本](https://docs.aws.amazon.com/controltower/latest/userguide/update-aft-version.html)。 + **已對 Account Factory 原始程式碼進行本機變更** Account Factory 是開放原始碼專案。AWS Control Tower 支援 Account Factory 核心程式碼。如果您對 Account Factory 核心程式碼進行本機變更，AWS Control Tower 只會盡力支援您的 Account Factory 部署。 + ** Account Factory 角色許可不足 ** Account Factory 會建立 IAM 角色和政策來管理付費帳戶部署和自訂。如果您變更這些角色或政策，Account Factory 管道可能無法執行特定動作。如需詳細資訊，請參閱[必要角色](https://docs.aws.amazon.com/controltower/latest/userguide/aft-required-roles.html)。 + **帳戶儲存庫未正確填入 ** 在佈建帳戶之前，請務必遵循[部署後步驟](https://docs.aws.amazon.com/controltower/latest/userguide/aft-post-deployment.html)。 + **手動變更 OU 後未偵測偏離** **注意** AWS Control Tower 會自動偵測漂移。如需解決偏離的資訊，請參閱[偵測和解決 AWS Control Tower 中的偏離](https://docs.aws.amazon.com/controltower/latest/userguide/drift.html#resolving-drift)。 手動變更組織單位 (OU) 時，不會偵測到偏離。這是因為 Account Factory 的事件驅動性質所致。提交帳戶請求時，Terraform 管理的資源是 Amazon DynamoDB 項目，而不是直接帳戶。變更項目後，請求會放入佇列中，AWS Control Tower 會在佇列中透過 Service Catalog （管理帳戶詳細資訊的服務） 處理它們。如果您手動變更 OU，則不會偵測到偏離，因為帳戶請求未變更。 ## 與帳戶佈建/註冊相關的問題 + **帳戶請求 （電子郵件地址/名稱） 已存在** 此問題通常會在佈建期間或作為 時導致 Service Catalog 產品故障`ConditionalCheckFailedException`。 您可以執行下列其中一項操作，找到有關問題的詳細資訊： + 檢閱您的 Terraform 或 CloudWatch Logs 日誌群組。 + 檢閱傳送到 Amazon SNS 主題 的失敗`aft-failure-notifications`。 + ** 格式不正確的帳戶請求 ** 請確定您的帳戶請求遵循預期的結構描述。如需範例，請參閱 GitHub 上的 [terraform-aws-control\$1tower\$1account\$1factory](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-request/examples)。 + ** 超過 AWS Organizations 資源配額** 請確定您的帳戶請求不超過 AWS Organizations 資源配額。如需詳細資訊，請參閱 [AWS Organizations 的配額](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_reference_limits.html)。 ## 與自訂調用相關的問題 + ** 未加入 Account Factory 的目標帳戶 ** 確定自訂請求中包含的所有帳戶都已加入 Account Factory。如需詳細資訊，請參閱[更新現有帳戶](https://docs.aws.amazon.com/controltower/latest/userguide/aft-update-account.html)。 + **自訂請求目標的帳戶存在於 DynamoDB 資料表 中`aft-request-metadata`，但不存在於帳戶請求儲存庫中 ** 執行下列其中一項操作來格式化您的自訂調用請求，以排除違規帳戶： + 在 DynamoDB 資料表 中`aft-request-metadata`，刪除參考不再位於您帳戶請求儲存庫中帳戶的項目。 + 不使用「全部」作為目標。 + 未鎖定帳戶所屬的 OU。 + 未直接鎖定帳戶。 + ** 對 Terraform Cloud 使用不正確的字符 ** 請確定您已設定正確的字符。Terraform Cloud 僅支援以團隊為基礎的權杖，不支援以組織為基礎的權杖。 + **無法在建立帳戶自訂管道之前建立帳戶；無法自訂帳戶** 變更帳戶請求儲存庫中的帳戶規格。當您進行變更，例如變更帳戶的標籤值時，即使管道不存在，Account Factory 仍會遵循嘗試建立管道的路徑。 ## 與帳戶自訂工作流程相關的問題 如果您遇到與帳戶自訂工作流程相關的問題，請確定您的 AFT 版本是 1.8.0 或更高版本，而且已從 DynamoDB 請求資料表刪除帳戶相關中繼資料的所有執行個體。 如需 AFT 1.8.0 版的相關資訊，請參閱 GitHub 上的 [1.8.0 版](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/releases/tag/1.8.0)。 如需有關如何檢查和更新 AFT 版本的資訊，請參閱下列內容： + [檢查 AFT 版本](https://docs.aws.amazon.com/controltower/latest/userguide/check-aft-version.html) + [更新 AFT 版本](https://docs.aws.amazon.com/controltower/latest/userguide/update-aft-version.html) 您也可以使用 Amazon CloudWatch Logs Insights 查詢來篩選包含目標帳戶和自訂請求 IDs日誌，以追蹤自訂請求並進行疑難排解。如需詳細資訊，請參閱[使用 AFT 帳戶自訂請求追蹤進行故障診斷](https://docs.aws.amazon.com/controltower/latest/userguide/aft-account-customization-options.html)。