翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # 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 が有効になっていない場合は、アカウントの自動登録を有効にするか、EnabledBaseline で ResetEnabledBaseline API と ResetEnabledControl APIs を使用してアカウント EnabledControls を登録できます。 EnabledBaselines AWSControlTowerBaseline の詳細については、「」を参照してください[OU レベルで適用されるベースラインタイプ](types-of-baselines.md#ou-baseline-types)。 **注記** プロビジョニング、更新、登録など、最大 5 つのアカウント関連のオペレーションを同時に実行できます。 ## アカウントのプロビジョニングに必要なアクセス許可 適切なユーザーグループの許可があれば、組織内のすべてのアカウントに対して標準化されたベースラインとネットワーク設定を指定できます。 Account Factory を使用して AWS Control Tower コンソールからアカウントを作成する場合は、AWS Control Tower コンソールを使用するアクセス許可と共に、`AWSServiceCatalogEndUserFullAccess` ポリシーが有効になっている IAM ユーザーとしてアカウントにサインインする必要があります。**ルート**ユーザーとしてサインインすることはできません。 **注記** アカウントをプロビジョニングする場合、アカウントのリクエスタには必ず `CreateAccount` および `DescribeCreateAccountStatus` アクセス許可が必要です。このアクセス許可セットは **Admin** ロールの一部であり、リクエスタが **Admin** ロールを引き受けると自動的に付与されます。アカウントをプロビジョニングするアクセス許可を委任する場合、これらのアクセス許可をアカウントリクエスタに直接追加する必要がある場合があります。 AWS Control Tower で必要な許可の全般的な情報については、「[AWS Control Tower でアイデンティティベースのポリシー (IAM ポリシー) を使用する](access-control-managing-permissions.md)」を参照してください。AWS Control Tower のロールとアカウントについては、「[Roles and accounts](https://docs.aws.amazon.com//controltower/latest/userguide/roles.html)」を参照してください。 # AWS Control Tower 内のアカウントのプロビジョニング AWS Control Tower には、メンバーアカウントを作成および更新するための方法が複数用意されています。一部の方法は主にコンソールベースで、一部の方法は主に自動化されています。 **概要**: AWS Control Tower のメンバーアカウントを作成する標準的な方法の 1 つは、Account Factory を使用することです。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 コンソールからプロビジョニングする手段を提供し、アカウントのカスタマイズとデプロイを自動化します。1 回限りのセットアップのためのいくつかのステップを実行すると、コンソールベースの自動プロビジョニングを使用できるようになり、スクリプトの作成やパイプラインの設定は不要となります。詳細については、「[Account Factory Customization (AFC) を使用したアカウントのカスタマイズ](af-customization-page.md)」を参照してください。 **自動登録** ランディングゾーン**設定****の自動アカウント登録**機能にオプトインすると、継承ドリフトを作成せずに、AWS Control Tower AWS アカウント *の外部*で作成し、AWS Control Tower に登録されている OU に移動することもできます。詳細については、「[自動登録でアカウントを移動して登録する](account-auto-enrollment.md)」を参照してください。 **コンソールベースの方法:** + 基本アカウントまたはカスタマイズされたアカウントについては AWS Service Catalog、 の一部である Account Factory コンソールを使用します。詳細と手順については、「[Account Factory でのアカウントのプロビジョニングと管理](account-factory.md)」を参照してください。 + 自動登録を通じて、コンソールから OU にアカウントを移動します。「[自動登録でアカウントを移動して登録する](account-auto-enrollment.md)」を参照してください。 + AWS Control Tower 内の **[Enroll account]** (アカウントの登録) 機能を使用します (ランディングゾーンがドリフト状態でない場合)。「[AWS Control Tower コンソールから既存のアカウントを登録する](quick-account-provisioning.md)」を参照してください。 + AWS Control Tower コンソールでは、Account Factory を使用して、同時に最大 5 つのアカウントを作成、更新、または登録できます。 **自動化された方法:** + **Lambda コード: **AWS Control Tower ランディングゾーンの管理アカウントから、Lambda コードと適切な IAM ロールを使用します。「[Automated Account Provisioning with IAM Roles](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)」を参照してください。 + 自動登録を通じ、API を使用して OU に既存のアカウントを移動します。「[自動登録でアカウントを移動して登録する](account-auto-enrollment.md)」を参照してください。 + **AWS Control Tower コンソールの Account Factory Customization:** セットアップのステップの実行後は、カスタマイズされたアカウントの今後のプロビジョニングで、設定を追加したり、パイプラインを維持したりする必要はありません。アカウントは、*ブループリント*と呼ばれる AWS Service Catalog 製品によってプロビジョニングされます。ブループリントでは、 CloudFormation テンプレートまたは Terraform テンプレートを使用できます。 **注記** CloudFormation ブループリントは、リソースを複数のリージョンにデプロイできます。Terraform ブループリントでは、1 つのリージョンにのみリソースをデプロイできます。デフォルトでは、それはホームリージョンです。 # AWS Control Tower コンソールでのアカウントのプロビジョニング 次の手順では、AWS Control Tower コンソールを使用して、アカウントを IAM Identity Center のユーザーとして作成およびプロビジョニングする方法について説明します。この手順は、*マニュアルアカウントプロビジョニング*とも呼ばれます。必要に応じて、プログラム、CLI、Service Catalog APIs、または AWS Control Tower Account Factory for Terraform (AFT)AWSを使用して AWS Control Tower アカウントをプロビジョニングしたり、既存のアカウントを登録済みの OU に自動的に登録したりできます。以前にカスタムブループリントを設定したことがある場合は、カスタマイズされたアカウントをコンソールでプロビジョニングできる場合があります。カスタマイズの詳細については、「[Account Factory Customization (AFC) を使用したアカウントのカスタマイズ](af-customization-page.md)」を参照してください。 **ユーザーとして AWS Control Tower コンソールでアカウントを個別にプロビジョニングするには** 1. にサインインAWSし、AWS Control Tower コンソールに移動します。 1. 左のナビゲーションから、**[組織]** を選択して **[組織]** ページを表示します。 1. 右上の **[リソースを作成]** を選択します。 1. ドロップダウンメニューで、**[アカウントを作成]** を選択します。 1. そのページで情報を入力し、次の点に注意してください。 + **[アカウント E メール]** は、AWS アカウントにまだ関連付けられていない E メールアドレスでなければなりません。 + 表示名は、このアカウントに表示する名前です。 1. IAM Identity Center の E メールアドレスとユーザー名を使用して、**[アクセス設定]** を定義するフィールドに入力します。 1. ドロップダウンリストから登録済み OU を選択して、アカウントをプロビジョニングする OU を指定します。 1. 必要に応じて、定義済みのブループリントを使用して、カスタマイズされたリソースでアカウントをプロビジョニングします。このタスクは後で実行できます。 1. アカウントの選択を確認し、右下の **[アカウントを作成]** を選択します。 1. これで、アカウントのプロビジョニングが開始されます。この処理には数分かかることがあります。ページをリフレッシュして、表示されたステータス情報を更新できます。 **注記** 一度にプロビジョニングできるアカウントは最大 5 個です。 # アカウントの表示 **[Organization]** (組織) ページには、AWS Control Tower での OU や登録のステータスに関係なく、組織内のすべての OU とアカウントが一覧表示されます。各アカウントが登録の前提条件を満たしていれば、AWS Control Tower でメンバーアカウントを個別または OU グループ別に表示および登録できます。 **特定のアカウントを表示するには** + **[Organization]** (組織) ページに移動します。 + 右上のドロップダウンメニューから **[アカウントのみ]** を選択できます。 + 次に、テーブルからアカウントの名前を選択します。 + テーブルから親 OU の名前を選択して、その OU の **[詳細]** ページで、その OU 内のすべてのアカウントのリストを表示することもできます。 **[組織]** ページと **[アカウントの詳細]** ページで、アカウントの **[状態]** を表示できます。これは、次のいずれかです。 + **[Not enrolled]** (未登録) - アカウントは親 OU のメンバーですが、AWS Control Tower によって完全には管理されていません。親 OU が登録されている場合、アカウントはその登録済みの親 OU に設定された予防コントロールによって管理されますが、OU の検出コントロールはこのアカウントに適用されません。親 OU が未登録の場合は、どのコントロールもこのアカウントに適用されません。 + **Enrolling** (登録中) - アカウントは、AWS Control Tower の管理対象になっています。親 OU のコントロール設定に適合するようにアカウントが調整されます。このプロセスには、アカウントリソースごとに数分かかる場合があります。 + **[Enrolled]** (登録済み) - アカウントは、その親 OU 用に設定されたコントロールによって管理されています。AWS Control Tower によって完全に管理されています。 + **Enrollment failed** (登録に失敗しました) - アカウントを AWS Control Tower に登録できませんでした。詳細については、「[登録の失敗の一般的な原因](quick-account-provisioning.md#common-causes-for-enrollment-failure)」を参照してください。 + **Update available** (更新が利用可能) – アカウントには利用可能な更新があります。この状態のアカウントは**登録済み**ですが、環境に加えられた最近の変更を反映するには、アカウントを更新する必要があります。単一のアカウントを更新するには、アカウントの詳細ページに移動し、**[Update account]** (アカウントの更新) を選択します。 1 つの OU の下にこの状態のアカウントが複数ある場合は、OU を**再登録**することを選択し、これらのアカウントをまとめて更新できます。 # 既存のアカウントの登録について AWS Control Tower ガバナンスは、AWS Control Tower によって既に管理されている組織単位 (OU) *に登録* AWS アカウント するときに、既存の個人に拡張できます。対象アカウント*は、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 アイデンティティセンター または を通じてアカウントを識別します AWS Organizations。 + 指定した OU にアカウントを配置します。現在の OU に適用されているすべての SCP を適用して、セキュリティ体制の整合性を保ってください。 + 選択した OU 全体に適用される SCP を使用して、必須のコントロールをアカウントに適用します。 + アカウント内のすべてのリソースを記録するように有効に 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 にアカウントを登録する前にアカウントの既存の追跡を削除しない限り、料金が重複して発生する可能性があります。 AWS Organizations コンソールや APIs などを使用してアカウントを登録済みの OU に移動する場合は、アカウントの残りのアカウントレベルの証跡を削除できます。CloudTrail 証跡の既存のデプロイがある場合は、CloudTrail の料金が重複して発生します。 ランディングゾーンを更新して組織レベルの証跡をオプトアウトすることを選択した場合、またはランディングゾーンがバージョン 3.0 より古い場合、組織レベルの CloudTrail 証跡はアカウントには適用されません。 ## VPC を使用して既存のアカウントを登録する AWS Control Tower は、Account Factory で新しいアカウントをプロビジョニングするときに、既存のアカウントを登録するときとは異なる方法で VPC を処理します。 + 新しいアカウントを作成すると、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 、設定レコーダーや配信チャネルなど、既存のアカウント AWS Config リソースのステータスを判断するために使用できる CLI コマンドの例です。 **表示コマンド:** + `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 アカウントを AWS Control Tower に登録する方法について説明します。* 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 管理アカウントと同じ組織にのみ、AWS Control Tower に既に登録されている OU で登録できます。** 登録に関するその他の前提条件を確認するには、「[AWS Control Tower の開始方法](https://docs.aws.amazon.com//controltower/latest/userguide/getting-started-with-control-tower.html)」を参照してください。 **注記** AWS Control Tower にアカウントを登録すると、そのアカウントは AWS Control Tower 組織の AWS CloudTrail 追跡によって管理されます。CloudTrail 追跡の既存のデプロイがある場合、AWS Control Tower にアカウントを登録する前にアカウントの既存の追跡を削除しない限り、料金が重複して発生する可能性があります。 **`AWSControTowerExecution` ロールでの信頼されるアクセスについて** 既存の AWS アカウント を AWS Control Tower に登録する前に、AWS Control Tower がアカウントを管理または*管理する*アクセス許可を付与する必要があります。具体的に CloudFormation は、AWS Control Tower には、 が選択した組織のアカウントにスタックを自動的にデプロイできるように、 AWS Organizations ユーザーに代わって AWS CloudFormation と の間に信頼されたアクセスを確立するためのアクセス許可が必要です。この信頼されたアクセスでは、`AWSControlTowerExecution` ロールは、各アカウントを管理するために必要なアクティビティを実行します。そのため、登録する前にこのロールを各アカウントに追加する必要があります。 信頼されたアクセスが有効になっている場合、 は 1 回のオペレーション AWS リージョン で複数のアカウントおよび のスタックを作成、更新、または削除 CloudFormation できます。AWS Control Tower はこの信頼機能を使用して既存のアカウントにロールとアクセス許可を適用します。その後、それらを登録済み組織単位に移動して、管理下に置くことができます。 信頼されたアクセスと の詳細については AWS CloudFormation StackSets、「」および[AWS CloudFormationStackSetsAWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudformation.html)「」を参照してください。 # 自動登録でアカウントを移動して登録する アカウントの自動登録機能は、バージョン 3.1 以降のランディングゾーンで利用可能です。 オプションでこの機能を有効にする場合は、 AWS Organizations APIs とコンソールを使用して、[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 に移動できます。アカウントは、AWS Control Tower の送信先の組織単位 (OU) からベースラインリソースとコントロール設定を自動的に受け取ります。このオプション機能を使用すると、2 つの OU が同じベースライン設定を持ち、同じコントロールが有効になっている場合、継承ドリフトを作成せずに、AWS Control Tower 内の OU 間でアカウントを移動することもできます。 **自動登録を有効にするには:** AWS Control Tower コンソールのランディングゾーンの **[設定]** ページでアカウントの自動登録を選択するか、`RemediationType` パラメータの値を**継承ドリフト**に設定して AWS Control Tower `CreateLandingZone` または `UpdateLandingZone` API を呼び出します。 **自動登録を適用するには:** **設定**ページでこのオプションを選択したら、 AWS Organizations コンソール、 API、 AWS Organizations `MoveAccount`または AWS Control Tower コンソールを使用してアカウントを移動できます。 **自動登録を使用してアカウントの登録を解除するには:** 登録されている OU の外部にアカウントを移動すると、AWS Control Tower はデプロイされたすべてのベースラインとコントロールを自動的に削除します。 **注記** AWS Control Tower のソースと送信元 OU の設定が異なる場合、アカウントで [移動されたメンバーアカウント](governance-drift.md#drift-account-moved) ドリフトが表示されることがあります。 ## 前提条件: 自動登録用に設定する + AWS Control Tower ランディングゾーンバージョン 3.1 以降を実行している必要があります。 + コンソールのランディングゾーンの **[設定]** ページ、または `RemediationTypes` パラメータの値を `Inheritance Drift` に設定して AWS Control Tower ランディングゾーン API を使用して、AWS Control Tower 自動登録機能にオプトインします。オプトインすると、AWS Control Tower はユーザーに代わって の`move account`イベントに対応し AWS Organizations、移動したアカウントの継承ドリフトを直ちに修正します。 ## 必要なアクセス許可 `CreateAccount` API と `MoveAccount` API を使用するには AWS Organizations 、特定のロールとアクセス許可が必要です。AWS Control Tower AWS Organizations で を使用する方法の詳細については、[「AWS Control Tower と AWS Organizations](https://docs.aws.amazon.com//organizations/latest/userguide/services-that-can-integrate-CTower.html)」を参照してください。 ## API の使用状況に関する例 これらの API に関する詳細と例については、「*AWS Organizations API リファレンス*」の「[https://docs.aws.amazon.com//organizations/latest/APIReference/API_CreateAccount.html](https://docs.aws.amazon.com//organizations/latest/APIReference/API_CreateAccount.html)」と「[https://docs.aws.amazon.com//organizations/latest/APIReference/API_MoveAccount.html](https://docs.aws.amazon.com//organizations/latest/APIReference/API_MoveAccount.html)」を参照してください。 ## 考慮事項 + **登録タイムライン:** AWS Control Tower に登録されている OU に移動したアカウントは、*結果整合性*モデルで登録されます。このプロセスは通常、移動するアカウントの数に応じて数分、最大数時間かかります。 + **登録解除プロセス:** AWS Control Tower の外部の OU に移動することで、同じプロセスを使用して AWS Control Tower からアカウントの登録を解除できます。このプロセスでは、AWS Control Tower によってデプロイされたロールとリソース、および AWS Control Tower で有効になっているコントロールがすべて削除されます。 # AWS Control Tower コンソールから既存のアカウントを登録する 個人を AWS Control Tower に登録 AWS アカウント するには、2 つの一般的な方法があります。 1. **設定**ページで*自動登録*機能を選択したら、AWS Control Tower の AWS アカウント 外部で を作成し、登録済みの OU に直接移動できます。詳細については、「[自動的にアカウントを移動し、登録する](https://docs.aws.amazon.com//controltower/latest/userguide/account-auto-enroll.html)」を参照してください。このオプションは、ランディングゾーンバージョン 3.1 以降でのみ有効です。 1. AWS Control Tower コンソールから既存のアカウントを手動で登録できます。 **以下のセクションでは、2 つ目のオプションについて説明します。**これは、AWS Control Tower 環境の以前の設定を必要としません。は、必要な[前提条件](https://docs.aws.amazon.com//controltower/latest/userguide/enrollment-prerequisites.html)を満たす AWS アカウント 必要があります。 **コンソールで対象となるアカウントを表示します。** 1. AWS Control Tower の **[Organization]** (組織) ページに移動します。 1. 登録するアカウントの名前を見つけます。見つけるには、アカウント名は、右上にあるドロップダウンメニューから **[Accounts only]** (アカウントのみ) を選択し、フィルターされたテーブルで探してください。 次に、[アカウントを手動で登録する手順](#enrollment-steps) セクションで示されているように、個々のアカウントを登録する手順に従います。 ## コンソールからの登録に関する考慮事項 + AWS Control Tower コンソールで使用できる**アカウント登録**機能は、AWS Control Tower によって管理 AWS アカウント されるように既存の を登録することを目的としています。詳細については、「[既存の 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 コンソールからアカウントを登録する場合は、AWS Control Tower コンソールを使用する**管理者**権限と共に、`AWSServiceCatalogEndUserFullAccess` ポリシーが有効になっているユーザーでアカウントにサインインする必要があり、ルートユーザーとしてサインインすることはできません。 + 登録するアカウントは、他のアカウントを更新する場合と同様に、 および AWS Control Tower Account Factory を使用して更新できます。更新手順については、「[AWS Control Tower でアカウントを更新して移動する](updating-account-factory-accounts.md)」セクションを参照してください。 **注記** 既存の E メールアドレスを登録するときは AWS アカウント、必ず既存の E メールアドレスを確認してください。それ以外の場合は、新しいアカウントが作成されます。 ## アカウントを手動で登録する手順 既存の AWS アカウント アカウントで **AdministratorAccess** アクセス許可 (ポリシー) を設定したら、次のステップに従ってアカウントを登録します。 **コンソールから AWS Control Tower に個別のアカウントを登録するには** + AWS Control Tower の **[Organization]** (組織) ページに移動します。 + **[Organization]** (組織) ページで、登録できるアカウントでは、セクション上部の **[Actions]** ドロップダウンメニューから **[Enroll]** を選択できます。これらのアカウントには、**[Account details]** (アカウントの詳細) ページでも **[Enroll account]** (アカウントの登録) ボタンが表示されます。 + **[Enroll account]** (アカウントの登録) を選択した場合、**[Enroll account]** (アカウントの登録) ページが表示され、`AWSControlTowerExecution` ロールをアカウントに追加するよう促されます。手順については、「[必要な IAM ロールを既存の に手動で追加 AWS アカウント して登録する](enroll-manually.md)」を参照してください。 + 次に、ドロップダウンの一覧から登録された OU を選択します。アカウントが既に登録済みの OU にある場合、このリストには OU が表示されます。 + [**[Enroll account（アカウントの登録）**] を選択します。 + `AWSControlTowerExecution` ロールを追加するためのモーダルリマインダーが表示されるので、アクションを確認します。 + **[Enroll]** (登録する) を選択します。 + AWS Control Tower は登録プロセスを開始し、**[Account details]** (アカウントの詳細) ページに戻ります。 ## 登録の失敗の一般的な原因 + 既存のアカウントを登録するには、登録するアカウントに `AWSControlTowerExecution` ロールが存在する必要があります。 + IAM プリンシパルに、アカウントをプロビジョニングするアクセス許可がない可能性があります。 + AWS Security Token Service (AWS STS) は、ホームリージョンの AWS アカウント 、または AWS Control Tower でサポートされている任意のリージョンで無効になっています。 + AWS Service Catalogの Account Factory ポートフォリオに追加する必要があるアカウントにサインインしている場合があります。アカウントを AWS Control Tower で作成または登録できるように、Account Factory にアクセスする前に、アカウントを追加する必要があります。適切なユーザーまたはロールが 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)」を参照してください。 + アカウントが別の AWS Control Tower OU を含む管理アカウントを持つ別の OU に属している場合、別の OU に参加する前に、現在の OU のアカウントを終了する必要があります。元の OU で既存のリソースを削除する必要があります。それ以外の場合、登録は失敗します。 + 目的の OU の SCP で、そのアカウントに必要なすべてのリソースの作成が許可されていない場合、アカウントのプロビジョニングと登録は失敗します。例えば、目的の OU 内の SCP は、特定のタグのないリソースの作成をブロックする場合があります。この場合、AWS Control Tower はリソースのタグ付けをサポートしていないため、アカウントのプロビジョニングまたは登録は失敗します。サポートについては、アカウント担当者または サポートにお問い合わせください。 新しいアカウントを作成するとき、または既存のアカウントを登録するときに、AWS Control Tower でロールをどのように使用するかの詳細については、「[Roles and accounts](https://docs.aws.amazon.com//controltower/latest/userguide/roles.html)」を参照してください。 **ヒント** 既存の が登録の前提条件 AWS アカウント を満たしていることを確認することができない場合は、**登録 OU** を設定し、その OU にアカウントを登録できます。登録が成功したら、アカウントを目的の OU に移動できます。登録に失敗しても、他のアカウントや OU は障害の影響を受けません。 既存のアカウントとその設定が AWS Control Tower に対応しているかどうか疑問がある場合は、次のセクションで推奨されるベストプラクティスに従うことができます。 **推奨: アカウントの登録に 2 段階のアプローチを設定する** + まず、コン 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 アカウントを招待する](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_manage_accounts_invites.html)」を参照してください。 *AWS Organizations * 1. 招待を受け入れます アカウントは組織のルートに表示されます。このステップでは、アカウントを AWS Control Tower と同じ組織に移動し、SCP および一括請求を確立します。 **ヒント** アカウントが古い組織から削除される前に、新しい組織への招待を送信できます。招待は、アカウントが既存の組織から正式に削除されるのを待機します。 **残りの前提条件を満たすステップ:** 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 Account Factory でアカウントプロビジョニング済み製品を削除します。(このステップでは、プロビジョニングされた製品が AWS Control Tower から削除されるだけです。アカウントは削除されません。) 1. 必要に応じて、組織に属していないアカウントに必要な請求の詳細を使用してアカウントを設定します。次に、組織からアカウントを削除します (これを行うと、アカウントは AWS Organizations クォータの合計に対してカウントされません）。 1. リソースが残っている場合はアカウントをクリーンアップし、「[アカウントを登録解除する](unmanage-account.md)」のアカウント閉鎖のステップに従って、アカウントを閉鎖します。 1. コントロールが定義された **[Suspended]** (停止状態) の OU がある場合、ステップ 1 を実行する代わりに、その OU にアカウントを移動できます。 # 必要な 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) に記載されているステップに従います。ランディングゾーンの準備ができたら、次のステップを実行して、手動で既存のアカウントを AWS Control Tower による管理下に入れます。 **この章で前述した [登録の前提条件](enrollment-prerequisites.md) を必ず確認してください。** AWS Control Tower にアカウントを登録する前に、そのアカウントを管理するアクセス許可を AWS Control Tower に付与する必要があります。これを行うには、次のステップに示すように、アカウントへのフルアクセス権を持つロールを追加します。これらのステップは、登録するアカウントごとに実行する必要があります。 **アカウントごとに次の手順を実行します。** **ステップ 1: 登録するアカウントが現在含まれている組織の管理アカウントに、管理者アクセス権を使ってサインインします。** 例えば、このアカウントを から作成 AWS Organizations し、クロスアカウント IAM ロールを使用してサインインする場合、次の手順を実行できます。 1. 組織の管理アカウントにサインインします。 1. **AWS Organizations** に移動します。 1. **[Accounts]** (アカウント) で、登録するアカウントを選択し、アカウント ID をコピーします。 1. 上部のナビゲーションバーのアカウントドロップダウンメニューを開き、**[Switch Role]** (ロールの切り替え) を選択します。 1. **[Switch Role]** (ロールの切り替え) フォームで、次のフィールドに入力します。 + **[Account]** (アカウント) に、コピーしたアカウント ID を入力します。 + **[Role]** (ロール) に、このアカウントへのクロスアカウントアクセスを有効にする IAM ロールの名前を入力します。このロールの名前は、アカウントの作成時に定義されています。アカウントの作成時にロール名を指定していない場合は、デフォルトのロール名、`OrganizationAccountAccessRole` を入力します。 1. [**Switch Role**] (ロールの切り替え) を選択します。 1. これで、子アカウント AWS マネジメントコンソール として にサインインします。 1. 完了したら、次の手順を実行するために子アカウントにとどまります。 1. 管理アカウント ID は次のステップで入力する必要があるため、メモしておきます。 **ステップ 2: AWS Control Tower にアカウントを管理する許可を付与します。** 1. **[IAM]** に移動します。 1. **[Roles]** (ロール) に移動します。 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:Tags]** (次へ: タグ) を選択します。 1. **[Add tags]** (タグを追加する) というタイトルのオプションの画面が表示されることがあります。**[Next:Review]** (次へ: レビュー) を選択して、この画面をスキップします。 1. **[Review]** (確認) 画面の **[Role name]** (ロール名) フィールドに、`AWSControlTowerExecution` と入力します。 1. **[Description]** (説明) ボックスに、登録のためのフルアカウントアクセスを許可などの短い説明を入力します。** 1. [**ロールの作成**] を選択してください。 **ステップ 3: 登録された OU に移動してアカウントを登録し、登録を確認します。** ロールを作成して必要なアクセス許可を設定したら、次のステップに従ってアカウントを登録し、登録を確認します。 1. **管理者として再度サインインし、AWS Control Tower に移動します。** 1. **アカウントを登録します。** + AWS Control Tower の **[Organization]** (組織) ページでアカウントを選択し、右上にある **[Actions]** (アクション) ドロップダウンメニューから **[Enroll]** (登録) を選択します。 + [アカウントを手動で登録する手順](quick-account-provisioning.md#enrollment-steps) ページで示されているように、個々のアカウントを登録する手順に従います。 1. **登録を確認します。** + AWS Control Tower から、左側のナビゲーションの **[Organization]** (組織) を選択します。 + 最近登録したアカウントを探します。初期状態では、**[Enrolling]** (登録中) のステータスが表示されます。 + 状態が **[Enrolled]** (登録済み) に変わったら、移動は成功です。 このプロセスを続行するには、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 リソースがあるアカウントを登録する このトピックでは、既存の 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 リソースを使用してアカウントを登録することは、ランディングゾーンで設定された管理アカウントまたはサービス統合アカウント (複数可) ではサポートされていません。 + アカウントは、 を有効にする 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 によって管理されるリージョンの少なくとも 1 つに、少なくとも 1 つの既存の AWS Config リソースがあります。 + アカウントでガバナンスドリフトが発生していないこと。 **注記** 既存の Config リソースを持つアカウントを、許可リストに追加せずに登録しようとすると、登録は失敗します。後で、同じアカウントを許可リストに追加しようとしても、AWS Control Tower はアカウントが正しくプロビジョニングされていることを検証できません。許可リストをリクエストして登録する前に、AWS Control Tower からアカウントをプロビジョニング解除する必要があります。アカウントを別の AWS Control Tower OU に移動しただけでは、ガバナンスドリフトが発生し、アカウントを許可リストに追加できなくなります。 既存の AWS Config リソースにアカウントを登録する自動アプローチを説明するブログについては、[「AWS Control Tower への既存の AWS Config リソースを持つアカウントの登録を自動化](https://aws.amazon.com//blogs/mt/automate-enrollment-of-accounts-with-existing-aws-config-resources-into-aws-control-tower/)する」を参照してください。 **このプロセスには主に次の 5 つのステップがあります。** 1. AWS Control Tower 許可リストにアカウント (複数可) を追加します。 1. アカウントで新しい IAM ロールを作成します。 1. 既存の AWS Config リソースを変更します。 1. リソースが存在しない AWS リージョンに AWS Config リソースを作成します。 1. AWS Control Tower にアカウントを登録します。 **先に進む前に、このプロセスに関する次の期待事項を考慮してください。** + AWS Control Tower はこのアカウントに AWS Config リソースを作成しません。 + 登録後、AWS Control Tower コントロールは、新しい IAM ロールを含む、作成した AWS Config リソースを自動的に保護します。 + 登録後に AWS Config リソースに変更があった場合は、アカウントを再登録する前に、AWS Control Tower の設定に合わせてリソースを更新する必要があります。 ## ステップ 1: サポートに連絡して、許可リストにアカウント (複数可) を追加する **チケットの件名には次の文章を使用してください。** *既存の 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. スタックを作成します。 **注記** 作成する SCP は `aws-controltower-ConfigRecorderRole*` ロールを除外する必要があります。 AWS Config ルールが評価を実行する機能を制限するアクセス許可を変更しないでください。 Config の呼び出しから `aws-controltower-ConfigRecorderRole*` をブロックする SCP がある場合に `AccessDeniedException` を受信しないよう、次のガイドラインに従ってください。 ## ステップ 3: 既存のリソースがある AWS リージョンを特定する アカウント内の管理対象リージョン (AWS Control Tower 管理対象) ごとに、前述の既存の AWS Config リソースサンプルタイプが少なくとも 1 つあるリージョンを特定してメモします。 ## ステップ 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 レコーダーは 1 つだけです。それが存在する場合は、次のように設定を変更します。ホームリージョンでは項目 `GLOBAL_RESOURCE_RECORDING` を **true** に置き換えます。 AWS Config レコーダーが存在する他のリージョンの項目を **false** に置き換えます。 + **Name:** 変更なし + **RoleARN:**` IAM_ROLE_ARN` + **RecordingGroup:** + **AllSupported:** true + **IncludeGlobalResourceTypes:** `GLOBAL_RESOURCE_RECORDING` + **ResourceTypes:** 空欄 この変更は、次のコマンドを使用して AWS CLI から行うことができます。文字列を既存の AWS Config レコーダー名`RECORDER_NAME`に置き換えます。 ``` 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 配信チャネルは 1 つだけです。2 つ以上存在する場合は、次のように設定を変更します。 + **Name:** 変更なし + **ConfigSnapshotDeliveryProperties:** TwentyFour\$1Hours + **S3BucketName:***CONFIG\$1BUCKET* + **S3KeyPrefix: ***ORGANIZATION\$1ID* + **SnsTopicARN:** 次の形式の、監査アカウントからの SNS トピック ARN。 `arn:aws:sns:CURRENT_REGION:AUDIT_ACCOUNT:aws-controltower-AllConfigNotifications` この変更は、次のコマンドを使用して AWS CLI から行うことができます。文字列を既存の AWS Config レコーダー名`DELIVERY_CHANNEL_NAME`に置き換えます。 ``` 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 が管理するリージョンで、リソースが存在しない場所にリソースを作成する 次の例`GLOBAL_RESOURCE_RECORDING`に示すように、ホームリージョンで **IncludeGlobalResourcesTypes** パラメータの値が になるように CloudFormation テンプレートを改訂します。また、このセクションで指定している、テンプレートの必須フィールドを更新します。 ホームリージョンでは項目 `GLOBAL_RESOURCE_RECORDING` を **true** に置き換えます。 AWS Config レコーダーが存在しない他のリージョンの場合は、項目を **false** に置き換えます。 1. 管理アカウントの CloudFormation コンソールに移動します。 1. **CustomerCreatedConfigResourcesForControlTower** という名前の新しい StackSet を作成します。 1. 次のテンプレートをコピーして更新します。 **注記** テンプレートの `CustomerCreatedAggregationAuthorization`リソースは、ランディングゾーンバージョン 4.0 以降では必要ありません。 ``` 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: OU を AWS Control Tower に登録する AWS Control Tower のダッシュボードで OU を登録します。 **注記** **アカウントの登録**ワークフローは、このタスクでは成功しません。**[Register OU]** (OU の登録) または **[Re-register OU]** (OU の再登録) を選択する必要があります。 # Account Factory でのアカウントのプロビジョニングと管理 **注記** 単一アカウントのプロビジョニング、更新、カスタマイズは、AWSControlTowerBaseline を有効にした組織単位 (OU) をターゲットにする必要があります。OU で AWSControlTowerBaseline が有効になっていない場合は、アカウントの自動登録を有効にするか、EnabledBaseline で ResetEnabledBaseline API と ResetEnabledControl APIs を使用し、その OU で EnabledControls を使用してアカウントを登録できます。 EnabledBaselines AWSControlTowerBaseline の詳細については、「」を参照してください[OU レベルで適用されるベースラインタイプ](types-of-baselines.md#ou-baseline-types)。 この章では、Account Factory を使用して AWS Control Tower ランディングゾーンに新しいメンバーアカウントをプロビジョニングするための概要と手順について説明します。 ## アカウントの設定とプロビジョニングのためのアクセス許可 AWS Control Tower Account Factory を使用すると、 のクラウド管理者とユーザーがランディングゾーンにアカウント AWS IAM アイデンティティセンター をプロビジョニングできます。デフォルトでは、IAM Identity Center ユーザーは `AWSAccountFactory` グループまたは管理グループに属している必要があります。 **注記** 組織全体で許可を持つアカウントを使用する場合と同様に、管理アカウントから作業するときは注意が必要です。 AWS Control Tower 管理アカウントには `AWSControlTowerExecution` ロールとの信頼関係があります。これにより、一部の自動アカウント設定も含めて、管理アカウントからのアカウント設定が可能になります。`AWSControlTowerExecution` ロールの詳細については、「[Roles and accounts](https://docs.aws.amazon.com//controltower/latest/userguide/roles-how.html)」を参照してください。 **注記** 既存の AWS アカウント を AWS Control Tower に登録するには、そのアカウントで`AWSControlTowerExecution`ロールが有効になっている必要があります。既存のアカウントを登録する方法の詳細については、「[既存のアカウントの登録について](enroll-account.md)」を参照してください。 権限の詳細については、「[アカウントのプロビジョニングに必要なアクセス許可](provision-and-manage-accounts.md#permissions)」を参照してください。 ## Account Factory アカウントの管理に関する考慮事項 Account Factory を使用して作成およびプロビジョニングしたアカウントは、更新、登録解除、および閉鎖できます。転用したいアカウントのユーザーパラメータを更新することで、アカウントを再利用できます。アカウントの組織単位 (OU) を変更することもできます。 **注記** Account Factory が供給するアカウントに関連付けられているプロビジョニング済み製品を更新するときに、新しいユーザーの E メールアドレスを指定すると AWS IAM アイデンティティセンター、AWS Control Tower は IAM Identity Center に新しいユーザーを作成します。以前に作成したアカウントは削除されません。IAM Identity Center から以前の IAM Identity Center ユーザーの E メールアドレスを削除する方法については、「[Disabling a User](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 の **[Organization]** (組織) ページに移動します。 1. OU のリストで、更新するアカウントの名前を選択します。更新可能なアカウントには、**[Update available]** (更新可能) のステータスが表示されます。 1. 次に、選択したアカウントのページの **[Account details]** (アカウントの詳細) が表示されます。 1. 右上の **[Update account]** (アカウントの更新) を選択します。 ある組織単位 (OU) から別の OU にアカウントを移動する場合、新しい OU によって適用されるコントロールが以前の OU のコントロールとは異なる場合があることに注意してください。新しい OU のコントロールがアカウントのポリシー要件を満たしている必要があります。 AWS Control Tower アカウントは、アカウントの自動登録をオプトインしたかどうかによって変更されます。自動登録の詳細については、「[オプションでアカウントの自動登録を設定する](configure-auto-enroll.md)」を参照してください。 **自動登録を使用して、アカウントが OU 間を移動するときの動作を制御する** アカウントを新しい OU に移動するとき、AWS Control Tower は OU で有効なベースラインとコントロールをアカウントに適用します。前の OU のコントロールとベースラインは削除されます。登録されている OU の外部にアカウントを移動すると、AWS Control Tower はデプロイされたすべてのベースラインとコントロールを削除します。 **自動登録を使用しないで、アカウントが OU 間を移動するときの動作を制御する** アカウントを OU 間で移動するとき、宛先 OU のコントロールがアカウントに適用されます。ただし、以前の OU のアカウントに適用されていたコントロールは削除されません。コントロールの正確な動作は、以前の OU と宛先 OU でアクティブなコントロールの実装に固有です。 + * AWS Config ルールで実装されたコントロールの場合:* 前の OU のコントロール
 は削除されません。このようなコントロールは手動で削除する必要があります。 + *SCP を使用して実装されたコントロールの場合:* 以前の OU の SCP ベースのコントロールは削除されます。宛先 OU の SCP ベースのコントロールがこのアカウントで有効になります。 + CloudFormation フックを使用して実装されたコントロールの場合: この動作は、新しい OU のコントロールのステータスによって異なります**。 + 宛先 OU でフックベースのコントロールが有効になっていない場合: 古いコントロールは、手動で削除しない限り、移動したアカウントに対して有効なままとなります**。 + 宛先 OU でフックのコントロールが有効になっている場合: 古いコントロールは削除され、宛先 OU のコントロールがアカウントに適用されます**。 # 登録済みアカウントの E メールアドレスの変更 AWS Control Tower で登録されたメンバーアカウントの E メールアドレスを変更するには、このセクションの手順に従います。 **注記** 以下の手順では、**管理アカウント**、**ログアーカイブアカウント**、または**監査アカウント**の E メールアドレスを変更することはできません。詳細については、[AWS 「アカウントに関連付けられた E メールアドレスを変更するにはどうすればよいですか?](https://aws.amazon.com//premiumsupport/knowledge-center/change-email-address/)」または「 サポート」にお問い合わせください AWS 。 **AWS Control Tower によって作成されたアカウントの E メールアドレスを変更するには** 1. アカウントのルートユーザーパスワードを回復します。[「紛失または忘れた AWS パスワードを復元するにはどうすればよいですか？」の記事の手順に従います。](https://aws.amazon.com//premiumsupport/knowledge-center/recover-aws-password/) 1. ルートユーザーパスワードでアカウントにサインインします。 1. E メールアドレスを他のメールアドレスと同じように変更し AWS アカウント、変更が反映されるまで待ちます AWS Organizations。E メールアドレスの変更による更新が完了するまで、遅延が発生する可能性があります。 1. アカウントに以前にあった E メールアドレスを使用して、Service Catalog でプロビジョニング済み製品を更新します。プロビジョニング済み製品を更新するプロセスには、新しい E メールアドレスのプロビジョニング済み製品への関連付けが含まれます。これにより、E メールアドレスの変更が AWS Control Tower で有効になります。今後プロビジョニングされる製品の更新には、新しい E メールアドレスを使用します。 AWS Organizationsで作成したメンバーアカウントのパスワードまたは E メールアドレスを変更するには、「*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 または他のメンバーアカウントの E メールアドレスを更新できます。詳細については、「*AWS Organizations User Guide*」の「[Updating the root user email address for a member account with 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. アカウントの root パスワードを回復します。この記事で説明されている手順に従います。[紛失または忘れた AWS パスワードを復元するにはどうすればよいですか?](https://aws.amazon.com//premiumsupport/knowledge-center/recover-aws-password/) 1. root パスワードでアカウントにサインインします。 1. AWS Billing コンソールで、**アカウント設定**ページに移動します。 1. その他の AWS アカウントの場合と同様に、**[Account settings]** (アカウント設定) で名前を変更します。 1. AWS Control Tower が自動的に更新され、名前の変更が反映されます。この更新は、 AWS Service Catalogのプロビジョニング済み製品には反映されません。 # Amazon Virtual Private Cloud の設定を使用して Account Factory を構成する Account Factory により、組織内のアカウントに対して、事前承認済みのベースラインと設定オプションを作成できます。 AWS Service Catalogを通じて新しいアカウントを設定し、プロビジョニングできます。 Account Factory ページに、組織単位 (OU) のリストとその**許可リスト**のステータスが表示されます。デフォルトでは、すべての OU が許可リストに表示されます。つまり、アカウントは OU の下でプロビジョニングできます。アカウントプロビジョニングのために特定の OUsを無効にすることができます AWS Service Catalog。 エンドユーザーが新しいアカウントをプロビジョニングするときに使用できる Amazon VPC 設定オプションを表示できます。 **Account Factory で Amazon VPC 設定を構成するには** 1. 中央のクラウド管理者として、管理アカウントの管理者権限で AWS Control Tower コンソールにサインインします。 1. ダッシュボードの左側から **[Account Factory]** を選択し、Account Factory ネットワーク設定ページに移動します。そこに、デフォルトのネットワーク設定が表示されます。編集するには、**[Edit]** (編集) を選択し、編集可能なバージョンの Account Factory ネットワーク設定を表示します。 1. 必要に応じて、デフォルト設定の各フィールドを変更できます。エンドユーザーが作成できるすべての新しい Account Factory アカウントに指定する VPC 設定オプションを選択し、該当する設定をフィールドに入力します。 + **[disabled]** (無効) または **[enabled]** (有効) を選択して、Amazon VPC にパブリックサブネットを作成します。デフォルトでは、インターネットにアクセス可能なサブネットは許可されません。 **注記** 新しいアカウントをプロビジョニングするときにパブリックサブネットが**有効**になるように Account Factory の VPC 設定を定義すると、Account Factory によって Amazon VPC が設定されて、[NAT ゲートウェイ](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-nat-gateway.html)が作成されます。料金は Amazon VPC による使用量に対して請求されます。詳細については、「[Amazon 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 を作成する 1 つのリージョンまたはすべてのリージョンを選択します。デフォルトでは、すべての使用可能なリージョンが選択されます。 + リストから、各 VPC にサブネットを設定するアベイラビリティーゾーンの数を選択します。デフォルト値および推奨値は 3 です。 + **[Save]** (保存) を選択します。 これらの設定オプションを設定して、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 の SCP の対象ではなくなります。アカウントは を通じて閉鎖できます 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 アイデンティティセンターユーザーは引き続きこのアカウントに対する管理者権限を保持します。このユーザーに管理者権限を持たせないようにするには、Account Factory でアカウントを更新し、このアカウントの IAM Identity Center ユーザー E メールアドレスを変更して、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//accounts/latest/reference/manage-acct-closing.html ](https://docs.aws.amazon.com//accounts/latest/reference/manage-acct-closing.html )」の「[Closing an account](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/close-account.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 コンソールでアカウントを閉じると、メンバーアカウントは AWS アカウント 90 日間分離されます。アカウントのステータスは、AWS Control Tower と AWS Organizationsで **[Suspended]** (停止) となります。この 90 日間にアカウントを操作しようとすると、AWS Control Tower からエラーメッセージが表示されます。 **注記** OU がアカウントを停止した場合、ターゲットのリージョンコントロールの EnabledControl オペレーションは失敗します。 90 日が経過する前に、メンバーアカウントを復元できます AWS アカウント。90 日が過ぎると、アカウントのレコードは削除されます。 ベストプラクティスとして、メンバーアカウントを解約する前に、そのアカウントを登録解除することをお勧めします。メンバーアカウントを最初に管理解除せずに解約すると、AWS Control Tower でアカウントのステータスは **[Suspended]** (停止) とともに **[Enrolled]** (登録済み) と表示されます。その結果、この 90 日の期間中にアカウントの OU を**再登録**しようとすると、AWS Control Tower からエラーメッセージが表示されます。停止中のアカウントは、基本的に、事前チェックに失敗した再登録アクションをブロックします。OU からアカウントを削除すると、OU **を再登録**できますが、アカウントの支払い方法がないとエラーが発生する AWS 可能性があります。この制約を回避するには、別の OU を作成し、この OU にアカウントを移動してから再登録を試みます。この OU の名前は、**Suspended** OU とすることをお勧めします。 **注記** アカウントを解約する前に登録を解除しない場合は、その 90 日が経過 AWS Service Catalog した後に でアカウントのプロビジョニング済み製品を削除する必要があります。 詳細については、 [CloseAccount API](https://docs.aws.amazon.com//organizations/latest/APIReference/API_CloseAccount.html) に関する AWS Organizations ドキュメントを参照してください。 # Account Factory のリソースに関する考慮事項 アカウントが Account Factory でプロビジョニングされると、アカウント内に次の AWS リソースが作成されます。 | AWS サービス | リソースタイプ | リソース名 | | --- | --- | --- | | 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 | # Account Factory Customization (AFC) を使用したアカウントのカスタマイズ **注記** 単一アカウントのプロビジョニング、更新、カスタマイズは、AWSControlTowerBaseline を有効にした組織単位 (OU) をターゲットにする必要があります。OU で AWSControlTowerBaseline が有効になっていない場合は、アカウントの自動登録を有効にするか、EnabledBaseline で ResetEnabledBaseline API と ResetEnabledControl APIs を使用してアカウント EnabledControls を登録できます。 EnabledBaselines AWSControlTowerBaseline の詳細については、「」を参照してください[OU レベルで適用されるベースラインタイプ](types-of-baselines.md#ou-baseline-types)。 AWS Control Tower では、AWS Control Tower コンソールからリソースをプロビジョニング AWS アカウント するときに、新規および既存の をカスタマイズできます。AWS Control Tower では、Account Factory Customization を設定すると、今後のプロビジョニングに備えてこのプロセスが自動化されるため、パイプラインを維持する必要がなくなります。カスタマイズされたアカウントは、リソースがプロビジョニングされるとすぐに使用できます。 **ブループリントを使用して新しいアカウントをプロビジョニングする** カスタマイズされたアカウントは、AWS Control Tower Account Factory、 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 リソースを監視します**。オプションで、これらのコントロールをランディングゾーンでアクティブ化できます。プロアクティブコントロールを適用すると、アカウントにデプロイするリソースが組織のポリシーと手順に準拠しているかどうかがチェックされます。プロアクティブコントロールの詳細については、「[Proactive controls](https://docs.aws.amazon.com//controltower/latest/userguide/proactive-controls.html)」を参照してください。 AFC との連携の詳細については、「[Automate account customization using Account Factory Customization in AWS Control Tower](https://aws.amazon.com//blogs/mt/automate-account-customization-using-account-factory-customization-in-aws-control-tower/)」(AWS Control Tower の Account Factory Customization を使ったアカウントのカスタマイズの自動化) を参照してください。 **前提条件** カスタマイズされたアカウントの作成を AWS Control Tower の Account Factory を使用して開始する前に、AWS Control Tower のランディングゾーン環境をデプロイし、新しく作成したアカウントを配置する組織単位 (OU) を AWS Control Tower に登録しておく必要があります。 **カスタマイズの準備** + *ハブアカウントを指定する:* ハブアカウントとして機能する新しいアカウントを作成するか、既存の を使用できます AWS アカウント。AWS Control Tower 管理アカウントをブループリントハブアカウントとしては使用しないことを強くお勧めします。 + *必要なロールを追加する:* AWS Control Tower AWS アカウント に登録してカスタマイズする場合は、AWS Control Tower に登録する他のアカウントと同様に、まずロールを`AWSControlTowerExecution`それらのアカウントに追加する必要があります。 + *パートナーのブループリントの設定 (オプション):* マーケットプレイスサブスクリプション要件を持つパートナーのブループリントを使用する予定の場合は、これらのブループリントを AWS Control Tower 管理アカウントから設定した後に Account Factory Customization ブループリントとしてデプロイする必要があります。 **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. 必要なロールを作成します。**Service Catalog 製品 (ブループリントとも呼ばれます) が保存される (ハブ) アカウントにアクセスする許可を AWS Control Tower に付与する IAM ロールを作成します。 + **ステップ 2. AWS Service Catalog 製品を作成します。**カスタムアカウントのベースライン化に必要な AWS Service Catalog 製品 (「ブループリント製品」とも呼ばれます) を作成します。 + **ステップ 3. カスタムブループリントを確認します。**作成した AWS Service Catalog 製品 (ブループリント) を検査します。 + **Step 4. ブループリントを呼び出して、カスタマイズされたアカウントを作成します。**アカウントの作成時、ブループリント製品の情報とロール情報を AWS Control Tower コンソールの Account Factory の適切なフィールドに入力します。 # ステップ 1. 必要なロールを作成する アカウントのカスタマイズを開始する前に、AWS Control Tower とハブアカウント間の信頼関係を含んでいるロールを設定する必要があります。このロールが継承されると、ハブアカウントのリソースを管理するためのアクセス権を AWS Control Tower に付与できます。ロールの名前は **AWSControlTowerBlueprintAccess** にする必要があります。 AWS Control Tower はこのロールを引き受けて、ユーザーに代わってポートフォリオリソースを作成し AWS Service Catalog、ブループリントを 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** ロールは、次の 2 つのプリンシパルに信頼を付与するように設定する必要があります。 + AWS Control Tower 管理アカウントで AWS Control Tower を実行するプリンシパル (ユーザー)。 + AWS Control Tower 管理アカウントの `AWSControlTowerAdmin` という名前のロール。 次に信頼ポリシーの例を示します。これは、ロールに含める必要があるポリシーと似ています。このポリシーは、最小特権アクセスの付与のベストプラクティスを示しています。独自のポリシーを作成する場合は、*YourManagementAccountId* を AWS Control Tower 管理アカウントの実際のアカウント 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* 製品とプロビジョニング済み製品のサポートが *External* という新しい製品タイプ AWS Service Catalog に変更されました。この変更が AFC に与える影響の詳細 (既存のアカウントのブループリントを External 製品タイプに更新する方法など) については、「[External 製品タイプへの移行](af-customization-page.md#service-catalog-external-product-type)」を参照してください。 **ブループリントを作成する手順の概要** + アカウントのブループリントとなる CloudFormation テンプレートまたは Terraform tar.gz 設定ファイルを作成またはダウンロードします。いくつかのテンプレートの例については、このセクションの後半に示します。 + Account Factory ブループリント AWS アカウント を保存する にサインインします (ハブアカウントと呼ばれることもあります）。 + AWS Service Catalog コンソールに移動します。次に、**[Product list]** (製品リスト) を選択し、**[Upload new product]** (新しい製品をアップロード) を選択します。 + **[Product details]** (製品詳細) ペインに、名前や説明など、ブループリント製品の詳細を入力します。 + **[Use a template file]** (テンプレートファイルの使用)、**[Choose file]** (ファイルの選択) の順に選択します。ブループリントとして使用するために作成またはダウンロードしたテンプレートや設定ファイルを選択または貼り付けます。 + コンソールページの下部にある **[Create product]** (製品を作成する) を選択します。 テンプレートは、 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 コンソールの**[Create account]** (アカウントの作成) ワークフローに従うと、オプションのセクションが表示され、アカウントのカスタマイズに使用できるブループリントに関する情報を入力できます。 **前提条件** カスタマイズするハブアカウントを設定し、ブループリント (Service Catalog 製品) を少なくとも 1 つ追加してから、その情報を 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 ID が含まれる場合があります。 1. ハブアカウントまたはブループリントの準備がまだ整っていない場合は、**アカウントの更新**プロセスに従って後からアカウントをカスタマイズできます。 詳細については、[ブループリントからカスタマイズされたアカウントを作成する](create-afc-customized-account.md)を参照してください。 # ブループリントからカスタマイズされたアカウントを作成する カスタムブループリントを作成すると、AWS Control Tower の Account Factory でカスタムアカウントの作成を開始できます。 **新しい AWS アカウントを作成するときにカスタムブループリントをデプロイするには、次の手順に従います。** 1. の AWS Control Tower に移動します AWS マネジメントコンソール。 1. **[Account Factory]** と **[Create account]** (アカウントの作成) を選択します。 1. アカウント名や E メールアドレスなどのアカウントの詳細を入力します。 1. E メールアドレスとユーザー名で IAM Identity Center の詳細を設定します。 1. アカウントが追加される登録済みの OU を選択します。 1. **[Account Factory Customization]** セクションを展開します。 1. Service Catalog 製品が含まれているブループリントハブアカウントのアカウント ID を入力し、**[Validate]** (検証) を選択します。ブループリントハブアカウントの詳細については、「[Account Factory Customization (AFC) を使用したアカウントのカスタマイズ](af-customization-page.md)」を参照してください。 1. Service Catalog 製品リスト (すべてのカスタムブループリント、パートナーブループリント) から、すべてのブループリントが含まれているドロップダウンメニューを選択します。ブループリントと対応するバージョンを選択してデプロイします。 1. ブループリントにパラメータが含まれている場合は、これらのフィールドが表示されて入力できます。事前にデフォルト値が入力されています。 1. 最後に、ブループリントをデプロイする場所を **[Home Region]** (ホームリージョン) または **[All governed Regions]** (すべての管理対象リージョン) から選択します。Route 53 や IAM などのグローバルリソースは、単一のリージョンのみにデプロイする必要がある場合があります。Amazon EC2 インスタンスや Amazon S3 バケットなどのリージョン別リソースは、すべての管理対象リージョンにデプロイできます。 1. すべてのフィールドに入力したら、**[Create account]** (アカウントの作成) を選択します。 **注記** Terraform で作成されたブループリントは 1 つのリージョンにのみデプロイでき、複数のリージョンにはデプロイできません。 アカウントプロビジョニングの進捗状況は、**[Organization]** (組織) ページで確認できます。アカウントのプロビジョニングが完了すると、ブループリントで指定されたリソースはすでにそのアカウント内にデプロイされています。アカウントとブループリントの詳細を表示するには、**[Account details]** (アカウント詳細) ページに移動します。 # 登録時に AFC を使用してアカウントをカスタマイズする 以下は、AWS Control Tower コンソールで、アカウントを登録およびカスタマイズする方法を示しています。 1. AWS Control Tower コンソールに移動し、左側のナビゲーションから **[Organization]** (組織) を選択します。 1. 使用可能なアカウントのリストが表示されます。カスタムブループリントを使用して登録するアカウントを特定します。そのアカウントの **[State]** (状態) 列に、**[Not enrolled]** (未登録) ステータスのアカウントが反映されています。 1. アカウントの左側にあるラジオボタンを選択し、画面右上の **[Actions]** (アクション) ドロップダウンメニューを選択します。ここで、**[Enroll]** (登録) オプションを選択します。 1. **[Access configuration]** (アクセス設定) セクションにアカウントの IAM Identity Center 情報を入力します。 1. アカウントがメンバーとなる登録済みの OU を選択します。 1. **アカウント作成**手順の 7～12 と同じ手順を使用して、**[Account Factory Customization]** (Account Factory のカスタマイズ) セクションを完了します。詳細については、[「 で Account Factory アカウントをプロビジョニング AWS Service Catalog](https://docs.aws.amazon.com/controltower/latest/userguide/provision-as-end-user.html)する」を参照してください。 アカウントの進捗状況は、**[Organization]** (組織) ページで確認できます。アカウントの登録が完了すると、ブループリントで指定されたリソースはすでにそのアカウント内にデプロイされています。 # ブループリントを AWS Control Tower アカウントに追加する 既存の AWS Control Tower メンバーアカウントにブループリントを追加するには、AWS Control Tower コンソールの **[Update account]** (アカウントの更新) ワークフローに従い、アカウントに追加する新しいブループリントを選択します。詳細については、「[AWS Control Tower または AWS Service Catalogで Account Factory アカウントを更新して移動する](https://docs.aws.amazon.com/controltower/latest/userguide/updating-account-factory-accounts.html#update-account-in-console)」を参照してください。 **注記** アカウントに新しいブループリントを追加すると、既存のブループリントは上書きされます。 **注記** AWS Control Tower アカウントごとに 1 つのブループリントをデプロイできます。 # ブループリントを更新する 以下の手順では、カスタムブループリントの更新方法とデプロイ方法について説明します。 **カスタムブループリントを更新するには** 1. CloudFormation テンプレートまたは Terraform tar.gz ファイル (ブループリント) を新しい設定で更新します。 1. 更新したブループリントを新しいバージョンとして AWS Service Catalogに保存します。 **更新したブループリントをデプロイするには** 1. AWS Control Tower コンソールの **[Organization]** (組織) ページに移動します。 1. **[Organization]** (組織) ページをブループリント名とバージョンでフィルタリングします。 1. **アカウントの更新**プロセスに従い、アカウントに最新バージョンのブループリントをデプロイします。 **ブループリントの更新に失敗した場合** AWS Control Tower では、プロビジョニングされた製品が `AVAILABLE` 状態になると、ブループリントを更新できます。プロビジョニングされた製品が `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 Account Factory Customization (AFC) は、 AWS パートナーによって構築および管理される事前定義されたカスタマイズブループリントへのアクセスを提供します。このようなパートナーブループリントは、特定のユースケースに合わせてアカウントをカスタマイズするのに役立ちます。各パートナーのブループリントは、特定のパートナーからの製品提供と連携するように事前に設定してカスタマイズされたアカウントの作成に役立ちます。 AWS Control Tower のパートナーのブループリントの完全なリストを表示するには、コンソールで Service Catalog の「**入門ライブラリ**」に移動します。ソースタイプ **[AWS Control Tower Blueprints]** (AWS Control Tower ブループリント) を検索します。 ## Account Factory Customizations (AFC) に関する考慮事項 + AFC は、単一の AWS Service Catalog ブループリント製品を使用したカスタマイズのみをサポートしています。 + AWS Service Catalog ブループリント製品は、ハブアカウントと AWS Control Tower ランディングゾーンのホームリージョンと同じリージョンに作成する必要があります。 + `AWSControlTowerBlueprintAccess` IAM ロールは、適切な名前、権限、信頼ポリシーを使用して作成する必要があります。 + AWS Control Tower は、ホームリージョンのみにデプロイするか、またはAWS Control Tower によって管理されているすべてのリージョンにデプロイするかという 2 つのブループリントのデプロイオプションをサポートしています。リージョンの選択はできません。 + メンバーアカウントのブループリントを更新すると、ブループリントハブアカウント ID と AWS Service Catalog ブループリント製品を変更することはできません。 + AWS Control Tower では、1 回のブループリント更新操作で既存のブループリントの削除と新しいブループリントの追加を同時に行うことはできません。ブループリントを削除してから、別の操作で新しいブループリントを追加できます。 + AWS Control Tower は、作成または登録するアカウントがカスタマイズされているか、またはカスタマイズされていないかに基づいて動作を変更します。カスタマイズされたアカウントをブループリントを使用して作成または登録しない場合、AWS Control Tower は AWS Control Tower 管理アカウントで (Service Catalog を通じて)、Account Factory によってプロビジョニングされた製品を作成します。ブループリントを使用してアカウントを作成または登録する際にカスタマイズを指定する場合は、AWS Control Tower は AWS Control Tower 管理アカウントで、Account Factory でプロビジョニングされた製品を作成しません。 ## ブループリントエラーが発生した場合 **ブループリントの適用中のエラー** 新しいアカウント、または AWS Control Tower に登録している既存のアカウントのいずれの場合も、ブループリントをアカウントに適用する過程でエラーが発生した場合の復旧手順は同じです。アカウントは存在したままですが、カスタマイズされず、AWS Control Tower に登録されていません。続行するには、次の手順に従って、AWS Control Tower にアカウントを登録し、登録時にブループリントを追加します。 **`AWSControlTowerBlueprintAccess` ロール作成中のエラーと回避策** AWS Control Tower アカウントから `AWSControlTowerBlueprintAccess` ロールを作成する場合、`AWSControlTowerExecution` ロールを使用してプリンシパルとしてサインインする必要があります。他のユーザーとしてサインインすると、次のアーティファクトに示すように、`CreateRole` オペレーションは SCP によって妨げられます。 ``` { "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 ブループリント用のポリシードキュメントのカスタマイズ Account Factory でブループリントを有効にすると、AWS Control Tower はユーザーに代わって StackSet を作成する CloudFormation ように に指示します。 は、StackSet にスタックを作成 CloudFormation するためにマネージドアカウントへのアクセス CloudFormation を必要とします。 CloudFormation にはすでに `AWSControlTowerExecution`ロールを通じてマネージドアカウントの管理者権限がありますが、このロールは によって引き受けることはできません CloudFormation。 ブループリントの有効化の一環として、AWS Control Tower によってメンバーアカウントにロールが作成されます。このロールは CloudFormation によって継承され、StackSet の管理タスクが完了する場合があります。Account Factory を使用してカスタマイズ済みブループリントを有効にする最も簡単な方法は、*allow-all* ポリシーを使用することです。このようなポリシーはすべてのブループリントテンプレートと互換性があるためです。 ただし、ベストプラクティスでは、ターゲットアカウントの CloudFormation のアクセス許可を制限する必要があります。カスタマイズされたポリシーを提供できます。このポリシーは、AWS Control Tower が 用に作成するロールに適用 CloudFormation します。例えば、ブループリントによって *something-important* という名前の 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" } ] } ``` ------ `AllowCloudFormationActionsOnStacks` ステートメントはすべての AFC カスタムポリシーに必要です。このロール CloudFormation を使用してスタックインスタンスを作成するため、スタックで CloudFormation アクションを実行するためのアクセス許可が必要です。`AllowSsmParameterActions` セクションは、有効になっているテンプレートに固有です。 **権限に関する問題の解決** 制限付きポリシーを使用してブループリントを有効にするとき、ブループリントを有効にする権限が不足していることがあります。このような問題を解決するには、ポリシードキュメントを改訂し、修正されたポリシーを使用するようにメンバーアカウントのブループリント設定を更新します。ポリシーがブループリントを有効にするのに十分であることを確認するには、 CloudFormation アクセス許可が付与され、そのロールを使用してスタックを直接作成できることを確認します。 ## Terraform ベースの Service Catalog 製品の作成に必要な追加のアクセス許可 AFC の Terraform 設定ファイルを使用して AWS Service Catalog 外部製品を作成する場合、 AWS Service Catalog では、テンプレートで定義されたリソースの作成に必要なアクセス許可に加えて、特定のアクセス許可を AFC カスタム IAM ポリシーに追加する必要があります。デフォルトのフル **Admin** ポリシーを選択した場合は、これらの追加のアクセス許可を追加する必要はありません。 ------ #### [ 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* 製品とプロビジョニング済み製品のサポートを *External *という新しい製品タイプに変更しました。この移行の詳細については、「*AWS Service Catalog 管理者ガイド*」の「[既存の Terraform オープンソース製品およびプロビジョニングされた製品から External 製品タイプへの更新](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/update_terraform_open_source_to_external.html)」を参照してください。 この変更は、AWS Control Tower アカウントファクトリーのカスタマイズを使用して作成または登録した既存のアカウントに影響します。これらのアカウントを *External* 製品タイプに移行するには、 AWS Service Catalog と AWS Control Tower の両方で変更を行う必要があります。 **新しい External 製品タイプに移行するには** 1. 既存の Terraform リファレンスエンジンを にアップグレード AWS Service Catalog して、*External* 製品タイプと *Terraform Open Source* 製品タイプの両方のサポートを含めます。Terraform Reference Engine の更新方法については、[AWS Service Catalog GitHub リポジトリ](https://github.com/aws-samples/service-catalog-engine-for-terraform-os)を参照してください。 1. で AWS Service Catalog、新しい *External* 製品タイプを使用して、既存の *Terraform Open Source* 製品 (ブループリント) を複製します。既存の Terraform Open Source ブループリントを**削除しないでください**。 1. AWS Control Tower で、Terraform オープンソースブループリントを使用している各アカウントを更新し、新しい External ブループリントを使用するようにします。**** 1. ブループリントを更新するには、まず Terraform オープンソースブループリントを完全に削除する必要があります。**詳細については、「[アカウントからブループリントを削除する](https://docs.aws.amazon.com/controltower/latest/userguide/remove-a-blueprint.html)」を参照してください。 1. 新しい External ブループリントを同じアカウントに追加します。**詳細については、「[ブループリントを AWS Control Tower アカウントに追加する](https://docs.aws.amazon.com/controltower/latest/userguide/add-blueprint-to-account.html)」を参照してください。 1. *Terraform Open Source* ブループリントを使用するすべてのアカウントが*外部*ブループリントに更新されたら、*Terraform Open Source* を製品タイプとして使用する製品に戻って AWS Service Catalog 終了します。 1. 今後、AWS Control Tower アカウントファクトリーのカスタマイズを使用して作成または登録するすべてのアカウントは、*CloudFormation* または *External* 製品タイプを使用するブループリントを参照する必要があります。 *External* 製品タイプを使用して作成したブループリントの場合、AWS Control Tower は Terraform テンプレートと Terraform リファレンスエンジンを使用するアカウントのカスタマイズのみをサポートします。詳細については、「[カスタマイズのための設定](https://docs.aws.amazon.com/controltower/latest/userguide/afc-setup-steps.html)」を参照してください。 **注記** AWS Control Tower は、新しいアカウントの作成時に *Terraform オープンソース*を製品タイプとしてサポートしていません。これらの変更の詳細については、 *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) は、AWS Control Tower でのアカウントプロビジョニングとアカウント更新のプロセスを自動化する GitOps モデルを採用します。 AFT では、AFT ワークフローを呼び出す入力を含むアカウントリクエスト Terraform ファイルを作成します。AFT のワークフローは、AFT のアカウントプロビジョニングフレームワークとアカウントカスタマイズステップを実行します。 AFT は、AWS Control Tower のワークフローパフォーマンスに影響しません。Account Factory または AFT によってアカウントをプロビジョニングした場合、同じバックエンドワークフローが発生します。 ## 前提条件 **注記** AFT アカウントプロビジョニングは、AWS Control Tower で AWSControlTowerBaseline が有効になっている組織単位 (OU) をターゲットにする必要があります。AWSControlTowerBaseline の詳細については、「」を参照してください[OU レベルで適用されるベースラインタイプ](types-of-baselines.md#ou-baseline-types)。 AFT を開始するとき、次を作成します。 + AWS Control Tower で OU、次に AFT 環境の AFT 管理アカウントを作成します。アカウント ID をメモしておき、後で Terraform モジュールで AFT をデプロイするときに `main.tf` ファイルに入力できるようにします。このアカウント ID は、AWS Control Tower **[コントロールの詳細]** ページで確認できます。詳細については、「[Terraform のドキュメント](https://developer.hashicorp.com/terraform/tutorials/aws/aws-control-tower-aft)」を参照してください。 + 完全にデプロイされた AFT 環境内の 1 つ以上の `git` リポジトリ。詳細については、「[Post-deployment steps for AFT](https://docs.aws.amazon.com/controltower/latest/userguide/aft-post-deployment.html)」を参照してください。 + 完全にデプロイされた AFT 環境。詳細については、「[AWS Control Tower Account Factory for Terraform (AFT) の概要](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html)」および「[AWS Control Tower Account Factory for Terraform (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)には、AWS Control Tower Account Factory for Terraform (AFT) を設定する方法の概要が含まれています。 # AWS Control Tower Account Factory for Terraform (AFT) の概要 Account Factory for Terraform (AFT) は、AWS Control Tower でアカウントのプロビジョニングとカスタマイズに役立つ Terraform パイプラインを設定します。AFT は、お客様のアカウントの AWS Control Tower を管理できるようにしながら、Terraform ベースのアカウントプロビジョニングの利点を提供するように設計されています。 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 Insights クエリを使用してタイムスタンプを範囲指定して検索し、リクエストトークンを取得できます。その結果、トークンに関連付けられたペイロードを確認し、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 は[コンポーネントサービス](aft-components.md)、他の AWS サービスの機能を として組み合わせ、Terraform Infrastructure as Code (IaC) をデプロイするパイプラインを使用してフレームワークを構築します。AFT により、次のことが可能になります。 + GitOps モデルでアカウントプロビジョニングと更新リクエストを送信する + アカウントのメタデータと監査履歴を保存する + アカウントレベルのタグを適用する + すべてのアカウント、一連のアカウント、または個々のアカウントにカスタマイズを追加する + 機能オプションの有効化 AFT は、AFT 管理アカウントと呼ばれる別のアカウントを作成して、AFT 機能をデプロイします。**AFT を設定する前に、既存の AWS Control Tower ランディングゾーンが必要です。AFT 管理アカウントは、AWS Control Tower 管理アカウントと同じではありません。 **AFT が提供する柔軟性** + **プラットフォームに対する柔軟性:** AFT は、Community Edition、Cloud、Enterprise の初期デプロイおよび継続的な運用のための Terraform ディストリビューションをサポートしています。 + **バージョン管理システムの柔軟性:** 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 は、先入れ先出しの順序でリクエストを処理します。詳細については、「[複数のアカウントリクエストを送信する](https://docs.aws.amazon.com/controltower/latest/userguide/aft-multiple-account-requests.html)」を参照してください。 1. 各アカウントがプロビジョニングされます。このステージは AWS Control Tower 管理アカウントで実行されます。 1. グローバルカスタマイズは、発行された各アカウントごとに作成されたパイプラインで実行されます。 1. 最初のアカウントプロビジョニングリクエストでカスタマイズが指定されている場合、カスタマイズは対象アカウントでのみ実行されます。アカウントが既にプロビジョニングされている場合は、そのアカウントのパイプラインでさらにカスタマイズを手動で開始する必要があります。 **AWS Control Tower Account Factory for Terraform – アカウントのプロビジョニングワークフロー** ![\[図: AFT のワークフロー図\]](http://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/images/high-level-aft-diagram.png) # Cost AFT に伴う追加料金はありません。AFT によってデプロイされたリソース、AFT によって有効化された AWS サービス、および AFT 環境にデプロイされたリソースに対してのみ料金が発生します。 デフォルトの AFT 設定には、データ保護とセキュリティを強化するための AWS PrivateLink エンドポイントの割り当て、および AWS CodeBuild のサポートに必要な NAT ゲートウェイが含まれます。このインフラストラクチャの料金の詳細については、[AWS PrivateLink の料金](https://aws.amazon.com//privatelink/pricing/)と [NAT ゲートウェイの Amazon VPC の料金](https://aws.amazon.com//vpc/pricing/)を参照してください。これらのコストの管理の詳細については、 AWS アカウント担当者にお問い合わせください。AFT のこれらのデフォルト設定は変更できます。 # AWS Control Tower Account Factory for Terraform (AFT) のデプロイ このセクションは、既存の環境で 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 リポジトリ全体がモジュールと見なされます。 AFT リポジトリのクローンを作成する代わりに、GitHub の 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 Control Tower で AWS リージョン を使用する方法](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 ユーザーガイド*」の[「What is AWS CodeCommit?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)」を参照してください。 AFT を初めてデプロイする場合に、既存の CodeCommit リポジトリがないときは、GitHub や BitBucket などの外部 VCS プロバイダーを選択する必要があります。詳細については、「[Alternatives for version control of source code in 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)」を参照してください。 ## AWS Control Tower Account Factory for Terraform を設定して起動する 以下の手順は、Terraform のワークフローに精通していることを前提としています。AFT のデプロイの詳細については、 AWS Workshop Studio ウェブサイトの[「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 ユーザーガイド*」の「[IAM ID (ユーザー、ユーザーグループ、ロール)](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 管理アカウントをプロビジョニングするには、**[組織]** ページで **[アカウントを作成]** を選択するか、他の方法を選択します。詳細については、[AWS Service Catalog 「Account Factory でアカウントをプロビジョニング](https://docs.aws.amazon.com/controltower/latest/userguide/provision-as-end-user.html)する」を参照してください。 **注記** AFT 用に別の OU を作成した場合は、AFT 管理アカウントを作成するときに必ずこの OU を選択してください。 AFT 管理アカウントを完全にプロビジョニングするには、最大 30 分かかる場合があります。 **ステップ 4: Terraform 環境がデプロイに使用可能であることを検証する** このステップは、Terraform の使用経験があり、Terraform を実行するための手順を適切に行っていることを前提としています。詳細については、HashiCorp Developer ウェブサイトの「[Command: init](https://developer.hashicorp.com/terraform/cli/commands/init)」を参照してください。 **注記** AFT は Terraform バージョン `1.6.0` 以降をサポートしています。 **ステップ 5: オプション 設定** + **オプションで仮想プライベートクラウド (VPC) 設定を設定する** AFT モジュールには、AWS Control Tower が中央 AFT 管理アカウントの VPC 内にアカウントリソースをプロビジョニングするかどうかを指定する `aft_enable_vpc` パラメータが含まれています。デフォルトでは、パラメータは `true` に設定されています。このパラメータを `false` に設定すると、AWS Control Tower は VPC やプライベートネットワークリソース (NAT ゲートウェイや VPC エンドポイントなど) を*使用せずに* AFT をデプロイします。`aft_enable_vpc` を無効にすると、*一部の使用パターンで* AFT の運用コストを削減できる場合があります。VPC 設定を追加すると、`false` に設定されている `aft_enable_vpc` パラメータが上書きされます。 **注記** `aft_enable_vpc` パラメータを再度有効にする (値を `false` から `true` に切り替える) には、`terraform apply` コマンドを 2 回連続して実行する必要があります。 新しい VPC をプロビジョニングする代わりに、アカウント内の既存の VPC を使用するように AFT を設定できます。独自の VPC を使用するには、次の VPC 設定パラメータを指定します。 + `aft_customer_vpc_id` - 既存の VPC の ID + `aft_customer_private_subnets` - VPC 内のプライベートサブネット ID のリスト 設定例: ``` 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 オプションを使用することはお勧めしません。基盤となる既存の VPC 内のリソースに応じて、Lambda 関数または CodePipeline との依存関係がある場合があります。 + **オプションで 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、*alias/aft* を使用して CloudWatch ログと SNS トピックを暗号化します。この CMK は、AFT が AFT 管理アカウントにデプロイされたときに作成され、ロググループと 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-notifications* および *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 のワークロード ID トークン (または動的プロバイダー認証情報) を使用して、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 管理アカウントを通じて、AWS Control Tower Account Factory リクエストをオーケストレーションするために必要なすべてのインフラストラクチャを確立する Terraform モジュールをプロビジョニングします。 GitHub の [AFT リポジトリ](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main)で AFT モジュールを表示できます。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)」を参照してください。 **注記** AFT が Terraform モジュールを使用してデプロイを完了するまで最大 30 分かかる場合があります。 **ステップ 7: Terraform 状態ファイルを管理する** AFT をデプロイすると、Terraform 状態ファイルが生成されます。このアーティファクトは、Terraform が作成したリソースの状態を記述します。AFT バージョンを更新する予定がある場合は、必ず Terraform 状態ファイルを保存するか、Amazon S3 と DynamoDB を使用して Terraform バックエンドをセットアップします。AFT モジュールはバックエンドの Terraform 状態を管理しません。 **注記** Terraform 状態ファイルを保護するのはユーザーの責任です。一部の入力変数には、プライベートの `ssh` キーまたは Terraform トークンなどの機密値が含まれる場合があります。デプロイ方法によって、これらの値は Terraform 状態ファイルにプレーンテキストとして表示されることがあります。詳細については、HashiCorp ウェブサイトの「[Sensitive data in State](https://www.terraform.io/docs/language/state/sensitive-data.html)」を参照してください。 # デプロイ後のステップ AFT インフラストラクチャのデプロイが完了したら、次の追加ステップに従って設定プロセスを完了し、アカウントをプロビジョニングする準備を整えます。 **ステップ 1: 目的の VCS プロバイダーとの CodeConnection を完了する** サードパーティーの VCS プロバイダーを選択した場合、AFT によって CodeConnection が確立されるので、その CodeConnection を確認します。希望する VCS を使用して AFT を設定する方法については、「[AFT での代替のソースコードバージョン管理](aft-alternative-vcs.md)」を参照してください。 AWS CodeStar 接続を確立する最初のステップは、AFT によって行われます。接続を確認する必要があります。 **ステップ 2: 各リポジトリを設定する** AFT では、次の [4 つのリポジトリ](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 で作成され、管理されるすべてのアカウントに適用されるカスタマイズを管理します。[使用可能な例](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 で作成され、管理されるすべてのアカウントに適用されるカスタマイズを管理します。[使用可能な例](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 で作成され、管理される特定のアカウントにのみ適用されるカスタマイズを管理します。[使用可能な例](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` を実行してアカウントリクエストの処理を開始します。このコマンドは、 で `ct-aft-account-request`オペレーションを呼び出します。これは AWS CodePipeline、アカウントのプロビジョニングが完了した後に AFT 管理アカウントで作成されます。詳細については、「[AFT アカウントプロビジョニングパイプライン](https://docs.aws.amazon.com/controltower/latest/userguide/aft-provisioning-framework.html)」を参照してください。 ## アカウントリクエスト Terraform ファイルのパラメータ アカウントリクエストの Terraform ファイルには、次のパラメータを含める必要があります。[アカウントリクエストの Terraform ファイルの例は](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-request) GitHub で確認できます。 + `module name` の値は、 AWS アカウント リクエストごとに一意である必要があります。 + `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 はアカウントリクエストを 1 つずつ処理しますが、AFT パイプラインには複数のアカウントリクエストを送信できます。AFT パイプラインに複数のアカウントリクエストを送信すると、AFT はアカウントリクエストを先入れ先出しの順序でキューに入れ、処理します。 **注記** AFT がプロビジョニングするアカウントごとに 1 つのアカウントリクエスト Terraform ファイルを作成することも、1 つの Terraform ファイルに複数のリクエストをカスケードすることもできます。 # 既存のアカウントの更新 **自動登録の互換性** 組織で自動登録を使用して自動アカウント登録を行う場合、AFT にはこれらのアカウントのインポートに関する制限があることに注意してください。自動登録を通じて登録されたアカウントには、AFT のインポートワークフローに必要な Service Catalog でプロビジョニングされた製品がありません。 **回避策:** OU の登録機能を使用して、自動的に登録されたアカウントのプロビジョニング済み製品を作成します。これにより、AFT のカスタマイズに必要なライフサイクルイベントが可能になります。 以前に送信されたアカウントリクエストを更新するして `git push` を実行することで、AFT がプロビジョニングしたアカウントを更新できます。このコマンドは、アカウントプロビジョニングワークフローを起動し、アカウント更新リクエストを処理できます。`ManagedOrganizationalUnit` の入力を更新できます。これは `control_tower_parameters` に必要な値の一部です。 `ManagedOrganizationalUnit` は、すべての `control_tower_parameters` の中で唯一の更新可能なパラメータです。ただし、`custom_fields` など、アカウントリクエストの Terraform ファイルに含まれるその他のパラメータは更新できます。詳細については、「[AFT による新しいアカウントのプロビジョニング](https://docs.aws.amazon.com/controltower/latest/userguide/aft-provision-account.html)」を参照してください。 例えば、AFT アカウントの名前または E メールアドレスを更新するには、アカウントリクエストファイルで `custom_fields` として詳細を定義できます。このように、グローバルカスタマイズ中に `aws_account_alternate_contact` リソースに渡すことができる SSM パラメータを作成します。 ``` 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 の外部で作成された AWS Control Tower アカウントを更新するには、**aft-account-request** リポジトリにアカウントを指定します。 **注記** すべてのアカウントの詳細が正しく、AWS Control Tower 組織およびそれぞれの AWS Service Catalog プロビジョニング済み製品と一致していることを確認します。 **AFT AWS アカウント で既存の を更新するための前提条件** + は AWS Control Tower に登録 AWS アカウント する必要があります。 + は AWS Control Tower 組織の一部 AWS アカウント である必要があります。 # Terraform と AFT バージョン Account Factory for Terraform (AFT) は、Terraform バージョン `1.6.0` 以降をサポートしています。次の例に示すように、AFT デプロイプロセスの入力パラメータとして Terraform のバージョンを指定する必要があります。 ``` terraform_version = "1.6.0" ``` ## Terraform ディストリビューション AFT は、次の 3 つの Terraform ディストリビューションをサポートしています。 + Terraform Community Edition + Terraform Cloud + Terraform Enterprise これらのディストリビューションについては、以降のセクションで説明します。AFT ブートストラッププロセス中に、選択した Terraform ディストリビューションを入力パラメータとして指定します。AFT デプロイと入力パラメータの詳細については、「[AWS Control Tower Account Factory for Terraform (AFT) のデプロイ](aft-getting-started.md)」を参照してください。 Terraform Cloud または Terraform Enterprise ディストリビューションを選択した場合、`terraform_token ` に指定する [API トークン](https://www.terraform.io/cloud-docs/users-teams-organizations/api-tokens)は、ユーザーまたはチーム API トークンである必要があります。組織トークンは、すべての必須 API でサポートされているわけではありません。セキュリティ上の理由から、次の例に示すように [terraform 変数](https://www.terraform.io/cloud-docs/workspaces/variables/managing-variables)を割り当てることによって、このトークンの値をバージョン管理システム (VCS、Version Control System) にチェックインしないようにする必要があります。 ``` # Sensitive variable managed in Terraform Cloud: terraform_token = var.terraform_cloud_token ``` ### Terraform Community Edition ディストリビューションとして Terraform Community Edition を選択すると、AFT は AFT 管理アカウントで Terraform バックエンドを管理します。AFT は、AFT デプロイメントおよび AFT パイプラインフェーズ中に実行する、指定された Terraform バージョンの `terraform-cli` をダウンロードします。結果の Terraform 状態設定は、次の形式の名前で Simple Storage Service (Amazon S3) バケットに格納されます。 ``` aft-backend-[account_id]-primary-region ``` AFT は、災害対策のために、次の形式の名前で、別の AWS リージョンに Terraform 状態設定をレプリケートする Simple Storage Service (Amazon S3) バケットも作成します。 ``` aft-backend-[account_id]-secondary-region ``` これらの Terraform 状態の Simple Storage Service (Amazon S3) バケットの削除機能に対しては、多要素認証 (MFA、Multi-Factor Authentication) を有効にすることをお勧めします。Terraform Community Edition の詳細については、[Terraform のドキュメント](https://www.terraform.io/docs/cli/index.html)を参照してください。 ディストリビューションとして Terraform OSS を選択するには、次の入力パラメータを指定します。 ``` terraform_distribution = "oss" ``` ### Terraform Cloud ディストリビューションとして 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 パラメータストアに Secure String として保存します。会社のセキュリティポリシーとコンプライアンスガイドラインに従って、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 は、その値を機密としてマークし、AFT 管理アカウントの SSM パラメータストアに secure string として保存します。会社のセキュリティポリシーとコンプライアンスガイドラインに従って、Terraform トークンの値を定期的にローテーションすることをお勧めします。 + `terraform_org_name` — このパラメータには、Terraform Enterprise 組織の名前が含まれます。 + `terraform_api_endpoint` — このパラメータには、Terraform Enterprise 環境の URL が含まれます。このパラメータの値は、次の形式であることが必要です。 ``` https://{fqdn}/api/v2/ ``` Terraform Enterprise の設定方法の詳細については、[Terraform のドキュメント](https://www.terraform.io/docs/enterprise/index.html)を参照してください。 # AFT バージョンを確認する デプロイした AFT のバージョンを確認するには、AWS SSM パラメータストアキーをクエリできます。 ``` /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 の更新を開始します。 デプロイした AFT のバージョンを更新するには、`main` リポジトリブランチからバージョンをプルできます。 ``` 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 管理アカウントに組織の証跡を作成します。 + Simple Storage Service (Amazon S3) および Lambda データイベントのログ記録をオンにします。 + AWS KMS 暗号化を使用して、すべての CloudTrail データイベントを暗号化し、AWS Control Tower Log Archive アカウントの `aws-aft-logs-*` S3 バケットにエクスポートします。 + **[Log file validation]** (ログファイルの検証) 設定をオンにします。 このオプションを有効にするには、AFT デプロイ入力設定で次の機能フラグを **[True]** に設定します。 ``` aft_feature_cloudtrail_data_events ``` **前提条件** この機能オプションを有効にする前に、 の信頼されたアクセス AWS CloudTrail が組織で有効になっていることを確認してください。 **CloudTrail の信頼されたアクセスのステータスを確認するには、次の手順に従います。** 1. AWS Organizations コンソールに移動します。 1. **[Services] (サービス) > [CloudTrail]** を選択します。 1. 次に、必要に応じて、右上の **[Enable trusted access]** (信頼されたアクセスを有効にする) を選択します。 AWS CloudTrail コンソールを使用するように指示する警告メッセージが表示される場合がありますが、この場合は警告を無視してください。AFT は、信頼されたアクセスを許可した後、この機能オプションの有効化の一環として証跡を作成します。信頼されたアクセスが有効になっていない場合は、AFT がデータイベントの証跡を作成しようとしたときにエラーメッセージが表示されます。 **注記** この設定は組織レベルで機能します。この設定を有効にすると、AFT によって管理されているかどうかにかかわらず AWS Organizations、 のすべてのアカウントに影響します。有効化時の AWS Control Tower ログアーカイブアカウントのすべてのバケットは、Simple Storage Service (Amazon S3) データイベントから除外されます。CloudTrail の詳細については、「[AWS CloudTrail ユーザーガイド](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)」を参照してください。 ## AWS エンタープライズサポートプラン このオプションを有効にすると、AFT パイプラインは AFT によってプロビジョニングされたアカウントの AWS エンタープライズサポートプランを有効にします。 AWS アカウントには、デフォルトで AWS 基本サポートプランが有効になっています。AFT は、AFT がプロビジョニングするアカウントのエンタープライズサポートレベルへの自動登録を提供します。プロビジョニングプロセスにより、 アカウントのサポートチケットが開き、 AWS エンタープライズサポートプランへの追加がリクエストされます。 エンタープライズサポートオプションを有効にするには、AFT デプロイ入力設定で次の機能フラグを **[True]** に設定します。 ``` aft_feature_enterprise_support=false ``` [AWS サポートプランの詳細については、「サポートプランの比較](https://aws.amazon.com/premiumsupport/plans/)」を参照してください。 AWS **注記** この機能を使用するには、支払いアカウントを Enterprise Support プランに登録する必要があります。 ## 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 を作成するための標準プラクティスがある場合があります。そのため、特に AFT 管理アカウントでは、 AWS デフォルトの VPC を削除し、有効にしないようにする必要があります。 このオプションを有効にするには、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 の詳細については、「[Default VPC and default subnets](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html)」(デフォルト VPC とデフォルトサブネット) を参照してください。 # AWS Control Tower Account Factory for Terraform のリソースに関する考慮事項 AWS Control Tower Account Factory for Terraform を使用してランディングゾーンを設定すると、 AWS アカウント内にいくつかのタイプの AWS リソースが作成されます。 **リソースの検索** + タグを使用して、AFT リソースの最新リストを検索できます。検索のキーと値のペアは次のとおりです。 ``` Key: managed_by | Value: AFT ``` + タグをサポートしないコンポーネントサービスの場合は、リソース名で `aft` を検索してリソースを特定できます。 **注記** AFT は、管理アカウントに AWS Backup リソースを作成しません。 **最初に作成されたリソースのテーブル (アカウント別)** **AWS Control Tower Account Factory for Terraform 管理アカウント** | **AWS service** | **リソースタイプ** | **リソース名** | | --- | --- | --- | | 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 | | Simple Storage Service (Amazon S3) | バケット | aft-\$1 | | Lambda | 関数 | aft-\$1 | | Lambda | レイヤー | aft-common-\$1 | | DynamoDB | テーブル | aft-request aft-request-audit aft-request-metadata aft-controltower-events | | Step Functions | ステートマシン | 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 service** | **リソースタイプ** | **リソース名** | | --- | --- | --- | | AWS Identity and Access Management | ロール | AWSAFTExecution | | AWS サポートセンター (オプション) | サポートプラン | Enterprise | **AWS Control Tower 管理アカウント** | **AWS service** | **リソースタイプ** | **リソース名** | | --- | --- | --- | | 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 service** | **リソースタイプ** | **リソース名** | | --- | --- | --- | | AWS Identity and Access Management | ロール | AWSAFTExecution AWSAFTService | | Key Management Service (KMS) | カスタマーマネージドキー | aft | | Simple Storage Service (Amazon S3) | バケット | aws-aft-logs-\$1 aws-aft-s3-access-logs-\$1 | | AWS サポートセンター (オプション) | サポートプラン | Enterprise | **AWS Control Tower 監査アカウント** | **AWS service** | **リソースタイプ** | **リソース名** | | --- | --- | --- | | AWS Identity and Access Management | ロール | AWSAFTExecution AWSAFTService | | AWS サポートセンター (オプション) | サポートプラン | Enterprise | # 必要なロール 一般に、ロールとポリシーは AWSの Identity and Access Management (IAM) の一部です。詳細については、「[AWS IAM ユーザーガイド](https://docs.aws.amazon.com//IAM/latest/UserGuide/introduction.html)」を参照してください。** AFT は、AFT パイプラインのオペレーションをサポートするために、AFT 管理アカウントと AWS Control Tower 管理アカウントに複数の IAM のロールとポリシーを作成します。これらのロールは、最小特権アクセスモデルに基づいて作成されます。このモデルは、各ロールおよびポリシーで最小限必要なアクションとリソースのセットに対する許可を制限します。これらのロールとポリシーには、識別` managed_by:AFT`のために AWS タグ`key:value`ペアが割り当てられます。 これらの IAM ロールの他に、AFT は 3 つの重要な役割を作成します。 + `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 Account Factory を使用して、アカウントをプロビジョニングします。 + **[Amazon DynamoDB](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/Introduction.html)** - AFT は AFT 管理アカウントに Amazon DynamoDB テーブルを作成します。このテーブルには、アカウントリクエスト、アカウント更新の監査履歴、アカウントメタデータ、および AWS Control Tower ライフサイクルイベントが保存されます。AFT は、AFT アカウントプロビジョニングワークフローの開始など、ダウンストリームプロセスを開始するための DynamoDB Lambda トリガーも作成します。 + **[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 Queue Service](https://docs.aws.amazon.com//AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)** - AFT は、AFT 管理アカウントに Amazon Simple Queue Service (Amazon SQS) FIFO キューを作成します。キューを使用すると、複数のアカウントリクエストを並行して送信できますが、順次処理する場合には AWS Control Tower Account Factory に一度に 1 つのリクエストを送信します。 + **[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 Parameter Store](https://docs.aws.amazon.com//systems-manager/latest/userguide/systems-manager-parameter-store.html)** - AFT は、AFT 管理アカウントに AWS Systems Manager Parameter Store をセットアップして、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 は、AFT 管理アカウントと AWS Control Tower ログアーカイブアカウントで AWS Key Management Service (KMS) を使用します。AFT は、Terraform の状態、DynamoDB テーブルに保存されるデータ、および SNS トピックを暗号化するためのキーを作成します。これらのログとアーティファクトは、AWS のリソースとサービスが AFT によってデプロイされたときに生成されます。AFT で作成された KMS キーは、デフォルトで 1 年ごとのローテーションが有効になっています。 + **[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com//IAM/latest/UserGuide/introduction.html)** – AFT は、推奨される最小特権モデルに従います。これにより、AFT パイプラインワークフロー中に必要なアクションを実行するために、AFT 管理アカウント、AWS Control Tower アカウント、および AFT プロビジョニング済みアカウントにAWS Identity and Access Management (IAM) ロールとポリシーが必要に応じて作成されます。 + **[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 イベントバスを作成して、AWS Control Tower ライフサイクルイベントを AFT 管理アカウントの DynamoDB テーブルにキャプチャして長期間保存します。AFT は、AFT 管理アカウントと AWS Control Tower 管理アカウントに Amazon CloudWatch イベントルールを作成して、AFT パイプラインワークフローの実行中に必要な複数のステップをトリガーします。 + **[AWS CloudTrail (オプション)](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/cloudtrail-user-guide.html)** – この機能を有効にすると、AFT は Amazon S3 バケットとAWS Lambda 関数のデータイベントを記録するためのAWS CloudTrail組織の証跡を AWS Control Tower 管理アカウントに作成します。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 は、このロールが Account Factory ポートフォリオへのアクセスを許可するために、アカウントのカスタマイズステージを実行するこのロールを引き受けます。 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 関数 + Docker コンテナを使用した、AWS ECS または AWS Fargate タスク + AWS またはオンプレミスでホストされるカスタムワーカーを使用した AWS Step Functions アクティビティ + Amazon SNS または SQS 統合 AWS Step Functions ステートマシンが定義されていない場合、ステージはノーオペレーションで渡されます。AFT アカウントプロビジョニングのカスタマイズのステートマシンを作成するには、[AFT アカウントプロビジョニングのカスタマイズのステートマシンを作成する](#aft-create-customizations)の手順に従います。カスタマイズを追加する前に、前提条件を満たしていることを確認してください。 これらのタイプの統合は AWS Control Tower の一部ではないため、AFT アカウントカスタマイズのグローバルな事前 API ステージの間は追加できません。代わりに、AFT パイプラインを使用して、プロビジョニングプロセスの一部としてこれらのカスタマイズを設定できます。これらは、プロビジョニングワークフローで実行されます。次のセクションで説明するように、AFT アカウントプロビジョニングステージを開始する前に、事前にステートマシンを作成して、これらのカスタマイズを実装する必要があります。 **ステートマシンを作成するための前提条件** + AFT が完全にデプロイされていること。AFT デプロイの詳細については、「[AWS Control Tower Account Factory for Terraform (AFT) のデプロイ](aft-getting-started.md)」を参照してください。 + AFT アカウントプロビジョニングのカスタマイズのために、環境に `git` リポジトリを設定します。詳細については、「[デプロイ後のステップ](aft-post-deployment.md)」を参照してください。 ## AFT アカウントプロビジョニングのカスタマイズのステートマシンを作成する **ステップ 1: ステートマシンの定義を変更する** 例の `customizations.asl.json` ステートマシンの定義を変更します。この例は、[デプロイ後のステップ](https://docs.aws.amazon.com//controltower/latest/userguide/aft-post-deployment.html)において、AFT アカウントプロビジョニングのカスタマイズを保存するために設定した `git` リポジトリで使用できます。ステートマシンの定義の詳細については、「[AWS Step Functions デベロッパーガイド](https://docs.aws.amazon.com//step-functions/latest/dg/welcome.html)」を参照してください。 **ステップ 2: 対応する Terraform 構成を含める** カスタム統合のためのステートマシンの定義を使用して、`.tf` 拡張子を持つ Terraform ファイルを同じ `git` リポジトリに含めます。例えば、ステートマシンのタスク定義で Lambda 関数を呼び出す場合は、`lambda.tf` ファイルを同じディレクトリに保存します。カスタム設定に必要な IAM ロールと許可を含めてください。 適切な入力を指定すると、AFT パイプラインは自動的にステートマシンを呼び出し、AFT アカウントプロビジョニングフレームワークステージの一部としてカスタマイズをデプロイします。 ## AFT アカウントプロビジョニングのフレームワークとカスタマイズを再開するには AFT は、AFT パイプラインを介して発行されたすべてのアカウントについて、アカウントプロビジョニングのフレームワークとカスタマイズの手順を実行します。アカウントプロビジョニングのカスタマイズを再開するには、次の 2 つの方法のいずれかを使用できます。 1. アカウントリクエストリポジトリの既存のアカウントに変更を加えます。 1. AFT で新しいアカウントをプロビジョニングします。 # アカウントのカスタマイズ AFT は、プロビジョニングされたアカウントに標準の設定またはカスタマイズされた設定をデプロイできます。AFT 管理アカウントでは、AFT はアカウントごとに 1 つのパイプラインを提供します。このパイプラインを使用すると、すべてのアカウント、一組のアカウント、または個々のアカウントにカスタマイズを実装できます。Python スクリプト、bash スクリプト、および Terraform 設定を実行したり、アカウントカスタマイズステージの一部として AWS CLI を操作したりできます。 ## 概要 選択した `git` リポジトリでカスタマイズを指定した後、グローバルカスタマイズを保存する場所またはアカウントカスタマイズを保存する場所のいずれかで、アカウントカスタマイズステージが AFT パイプラインによって自動的に完了します。アカウントを遡及的にカスタマイズするには、「[カスタマイズの再呼び出し](#aft-re-invoke-customizations)」を参照してください。 **グローバルカスタマイズ (オプション)** AFT によってプロビジョニングされているすべてのアカウントに特定のカスタマイズを適用することもできます。例えば、特定の IAM ロールを作成する必要がある場合やすべてのアカウントにカスタムコントロールをデプロイする必要がある場合、AFT パイプラインのグローバルカスタマイズステージでその操作を自動的に行うことができます。 **アカウントカスタマイズ (オプション)** AFT でプロビジョニングされた他のアカウントとは異なる個別のアカウント、または一組のアカウントをカスタマイズするには、AFT パイプラインのアカウントカスタマイズ部分を使用して、アカウント固有の設定を実装します。例えば、特定のアカウントでのみ、インターネットゲートウェイへのアクセスが必要になる場合があります。 ## カスタマイズの前提条件 アカウントのカスタマイズを開始する前に、次の前提条件が満たされていることを確認してください。 + AFT が完全にデプロイされていること。デプロイ方法については、「[AWS Control Tower Account Factory for Terraform を設定して起動する](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 でプロビジョニングされたアカウントに変更が加えられます。イベントソースベースの再呼び出しを使用すると、個々のアカウント、すべてのアカウント、OU に応じたアカウント、またはタグに従って選択されたアカウントにカスタマイズを適用できます。 AFT でプロビジョニングされたアカウントのカスタマイズを再呼び出しするには、次の 3 つのステップに従います。 **ステップ 1: グローバルカスタマイズまたはアカウントカスタマイズの `git` リポジトリに変更をプッシュする** 必要に応じてグローバルカスタマイズおよびアカウントカスタマイズを更新し、変更を `git` リポジトリに再度プッシュします。この時点では何も起こりません。次の 2 つのステップで説明するように、イベントソースによってカスタマイズパイプラインを呼び出す必要があります。 **ステップ 2: カスタマイズを再呼び出しするための AWS Step Functions の実行を開始する** AFT では、AFT 管理アカウントに `aft-invoke-customizations` という AWS Step Functions が用意されています。この関数の目的は、AFT でプロビジョニングされたアカウントのカスタマイズパイプラインを再呼び出しすることです。 次に、`aft-invoke-customizations` AWS Step Functions に入力を渡すために作成できるイベントスキーマ (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 以降の場合は、ネストされた OU を構文 `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 Functions の出力をモニタリングし、AWS CodePipeline の実行を監視する** + Step Functions で生成される出力には、Step Functions 入力イベントソースと一致するアカウント ID が含まれています。 + **[Developer Tools]** (開発者用ツール) の下にある AWS CodePipeline に移動して、アカウント ID に対応するカスタマイズパイプラインを表示します。 ## AFT アカウントカスタマイズリクエストの追跡によるトラブルシューティング AWS Lambda に基づいてアカウントカスタマイズワークフローが出力するログには、ターゲットアカウント ID とカスタマイズリクエスト ID が含まれます。AFT では、カスタマイズリクエストに関連する CloudWatch Logs をターゲットアカウントまたはカスタマイズリクエスト ID でフィルタリングするために使用できる CloudWatch Logs Insights クエリを提供することで、Amazon CloudWatch Logs によるカスタマイズリクエストの追跡とトラブルシューティングを行うことができます。詳細については、「*Amazon CloudWatch Logs ユーザーガイド*」の「[Amazon CloudWatch Logs を使用したログデータの分析](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)」を参照してください。 **AFT で CloudWatch Logs Insights を使用するには** 1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。 1. ナビゲーションペインで、**[ログ]**、**[ログのインサイト]** の順に選択します。 1. **[クエリ]** を選択します。 1. **[サンプルクエリ]** で **[Account Factory for 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 別のカスタマイズログ** **注記** 必ず *"YOUR-CUSTOMIZATION-REQUEST-ID"* をカスタマイズリクエスト ID に置き換えてください。カスタマイズリクエスト ID は、AFT アカウントプロビジョニングフレームワーク AWS Step Functions ステートマシンの出力にあります。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 はソースコードバージョン管理システム (VCS) AWS CodeCommit に を使用し、ビジネス要件または既存のアーキテクチャを満たす他の [CodeConnections](https://docs.aws.amazon.com//dtconsole/latest/userguide/supported-versions-connections.html) を許可します。 AFT を初めてデプロイする場合に、既存の CodeCommit リポジトリがないときは、AFT デプロイの前提条件の一部として外部 VCS プロバイダーを指定する必要があります。 **AFT では、次のソースコード管理の代替方法がサポートされています。** + GitHub + GitHub Enterprise Server + Bitbucket + GitLab + GitLab セルフマネージド **注記** VCS AWS CodeCommit として を指定した場合、追加のステップは必要ありません。AFT は、環境内に必要な `git` リポジトリ (デフォルト名を使用) を作成します。ただし、組織の標準に準拠するように、必要に応じて CodeCommit のデフォルトのリポジトリ名をオーバーライドすることができます。 ## AFT で代替のソースコードバージョン管理システム (カスタム VCS) を設定する AFT デプロイ用の代替のソースコードバージョン管理システムを設定するには、次のステップに従います。 **ステップ 1: サポートされているサードパーティーのバージョン管理システム (VCS、Version Control System) で `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 設定パラメータを指定する** AFT デプロイの一部として VCS プロバイダーを設定するには、次の入力パラメータが必要です。 + **vcs\$1provider**: を使用していない場合は AWS CodeCommit、ユースケースに基づいて VCS `"bitbucket"` `"github"`プロバイダーを `"gitlab"`、、`"githubenterprise"`、または として指定します。 + **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` ですが、この値はオーバーライドできます。 デフォルトでは、AFT のソースは各 `git` リポジトリの `main` ブランチです。ブランチ名の値は、追加の入力パラメータでオーバーライドできます。入力パラメータの詳細については、[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 接続を完了する必要があります。CodeCommit 接続を完了する詳細な手順については、「[AWS CodeCommit のドキュメント](https://docs.aws.amazon.com//dtconsole/latest/userguide/connections-update.html)」を参照してください。 # AFT をAWS CodeCommit から別の VCS プロバイダーに移動する このセクションでは、AWS Control Tower Account Factory for Terraform (AFT) をバージョン管理システム (VCS) としてAWS CodeCommit から別の VCS プロバイダーに移動する方法の概要を説明します。 **ステップ 1.** 選択した VCS に新しいリポジトリを設定します。 **ステップ 2.** これらのリポジトリを新しいリモートとして `git` に追加します。 **ステップ 3.** 新しい VCS プロバイダーに `git push` を実行します。 **注記** 作成するリポジトリ構造は in AWS CodeCommit と同じである必要があります。構造を変更すると、AFT の目的のコードの実行に影響が出ます。 aft-account-request aft-account-customizations aft-global-customizations aft-account-provisioning-customizations **Step 4.** 次の例に示すように、AWS Control Tower 管理アカウントで、VCS プロバイダーを指すように Terraform モジュール (ブートストラップ) を更新します。 **例:** [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 プロバイダーの pendingCodeConnections](https://docs.aws.amazon.com/dtconsole/latest/userguide/connections-update.html)AWS CodeConnections を見つけて完了します`https://us-east-1.console.aws.amazon.com/codesuite/settings/connections`。AWS 1. リファレンス: 「[Post-deployment steps](https://docs.aws.amazon.com//controltower/latest/userguide/aft-post-deployment.html)」 **注記** アカウントパイプラインは、`aft-invoke-customizations` *ステップ関数*が呼び出されるまで以前のソースを保持します。この呼び出しは、アップグレードの一部として、または次のカスタマイズ呼び出しの一部として実行できます。 詳細については、このブログ[AWS CodeCommit リポジトリを別の Git プロバイダーに移行する](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider)方法」を参照してください。 # データ保護 AFT でのデータ保護には、[AWS責任共有モデル](https://aws.amazon.com//compliance/shared-responsibility-model/)が適用されます。データ保護のため、セキュリティについては、次のベストプラクティスをお勧めします。 + AWS Control Tower で提供されるデータ保護ガイドラインに従ってください。詳細については、「[AWS Control Tower のデータ保護](controltower-console-encryption.md)」を参照してください。 + AFT デプロイ時に生成された Terraform 状態設定を保持します。詳細については、「[AWS Control Tower Account Factory for Terraform (AFT) のデプロイ](aft-getting-started.md)」を参照してください。 + 組織のセキュリティポリシーの指示に従って、機密性の高い認証情報を定期的にローテーションします。シークレットの例としては、Terraform トークン、`git` トークンなどがあります。 **保管時の暗号化** AFT は、保管時にAWS Key Management Service キーで暗号化される Amazon S3 バケット、Amazon SNS トピック、Amazon SQS キュー、Amazon DynamoDB データベースを作成します。AFT で作成された KMS キーは、デフォルトで 1 年ごとのローテーションが有効になっています。Terraform の Terraform Cloud または Terraform Enterprise ディストリビューションを選択した場合、AFT には、機密性の高い Terraform トークン値を保存するAWS Systems Manager SecureString パラメータが含まれます。 AFT は、 で説明[コンポーネントサービス](aft-components.md)されているAWSサービスを使用します。デフォルトでは、保管時に暗号化されます。詳細については、AFT の各コンポーネントAWSサービスのAWSドキュメントを参照し、各サービスのデータ保護プラクティスについて説明します。 **転送時の暗号化** AFT は、デフォルトで転送中の暗号化を使用する で説明[コンポーネントサービス](aft-components.md)されているAWSサービスに依存します。詳細については、AFT の各コンポーネントAWSサービスのAWSドキュメントを参照し、各サービスのデータ保護プラクティスについて説明します。 Terraform Cloud または Terraform Enterprise ディストリビューションの場合、AFT は Terraform 組織にアクセスするための HTTPS エンドポイント API を呼び出します。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 アカウント、以下を参照してください。 「*Control Tower ユーザーガイド*」の「[Unmanage a member account](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` および `aft-backend-012345678901-secondary-region` Amazon S3 バケットに 3 つのフォルダがアカウントごとに表示されます。これらのフォルダは、*カスタマイズパイプラインの状態*、*アカウントのカスタマイズ状態*、および*グローバルカスタマイズ状態*に関連しています **例: テラフォームクラウドまたはテラフォームエンタープライズ** Terraform Cloud または Terraform Enterprise を選択した場合、`aft-backend-012345678901-primary-region` および `aft-backend-012345678901-secondary-region` Amazon S3 バケットには、アカウントごとにフォルダがあります。これらのフォルダは、*カスタマイズパイプラインの状態*に関連しています。 # 運用メトリクス デフォルトでは、Account Factory for Terraform (AFT) は匿名の運用メトリクスを AWS に送信します。このデータは、ソリューションの品質と機能を向上させる目的で、お客様が AFT をどのように使用しているかを理解するために使用されます。AFT のデプロイ中にパラメーターを変更することで、データ収集をオプトアウトできます。データ収集が有効になっていると、次のデータが AWS に送信されます。 + **ソリューション:** AFT 固有の識別子 + **バージョン:** AFT のバージョン + **UUID (Universally Unique Identifier):** 個々の ATF のデプロイに対してランダムに生成された一意の識別子 + **タイムスタンプ:** データ収集タイムスタンプ + **データ:** お客様が行った AFT の設定とアクション 収集したデータの所有権は AWS が有します。データ収集には、[AWS プライバシーポリシー](https://aws.amazon.com/privacy/)が適用されます。 **注記** 1.6.0 より前のバージョンの AFT では、使用量メトリクスは AWS にレポートされません。 レポートメトリクスをオプトアウトするには: + 次の例に示すように、Terraform 入力設定ファイルで `aft_metrics_reporting` の入力値を `false` に設定し、AFT を再デプロイします。明示的に設定しない場合、この値は、デフォルトで `true` に設定されます。 例をコピーする場合は、`x` の部分の文字列を実際の ID とリージョン値で置き換えてください。 ``` 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 サポート](https://aws.amazon.com/premiumsupport/)にお問い合わせください。Account Factory は AWS CodeBuild、、 AWS Organizations、 を含むリソースクォータ AWS のサービス で を使用します 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 が最新バージョンであることを確認します。詳細については、「[Updating the Account Factory version](https://docs.aws.amazon.com/controltower/latest/userguide/update-aft-version.html)」(Account Factory バージョンの更新)を参照してください。 + **Account Factory ソースコードにローカルな変更が加えられている** Account Factory は、オープンソースプロジェクトです。AWS Control Tower は Account Factory コアコードをサポートしています。Account Factory コアコードにローカルな変更を加える場合、AWS Control Tower は Account Factory デプロイをベストエフォートベースでのみサポートします。 + **Account Factory ロールのアクセス許可が不十分** Account Factory では、IAM ロールとポリシーを作成して、発行されたアカウントのデプロイとカスタマイズを管理します。このようなロールまたはポリシーを変更すると、Account Factory パイプラインで特定のアクションを実行できなくなる可能性があります。詳細については、「[Required roles](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 で自動的に行われます。ドリフトの解決の詳細については、「[Detect and resolve drift in AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/drift.html#resolving-drift)」(AWS Control Tower でドリフトを検出して解決する) を参照してください。 組織単位 (OU) が手動で変更されると、ドリフトが検出されなくなります。これは、イベント駆動型の Account Factory が持つ性質によるものです。アカウントリクエストが送信されるとき、Terraform によって管理されるリソースは Amazon DynamoDB アイテムであり、直接のアカウントではありません。アイテムが変更されると、リクエストはキューに入れられ、AWS Control Tower によって (アカウントの詳細を管理するサービス) を通じて処理されます。OU を手動で変更すると、アカウントリクエストが変更されないため、ドリフトは検出されません。 ## アカウントのプロビジョニング/登録に関連する問題 + **アカウントリクエスト (メールアドレス/名前) がすでに存在する** この問題は通常、プロビジョニング中または `ConditionalCheckFailedException` 発生時に、Service Catalog 製品の障害を引き起こします。 この問題の詳細情報は、次のいずれかを実行することで確認できます。 + 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 「組織のクォータ](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_reference_limits.html)」を参照してください。 ## カスタマイズの呼び出しに関する問題 + **ターゲットアカウントが Account Factory にオンボードされていない** カスタマイズリクエストに含まれるすべてのアカウントが Account Factory にオンボードされていることを確認します。詳細については、「[Update an existing account](https://docs.aws.amazon.com/controltower/latest/userguide/aft-update-account.html)」(既存のアカウントの更新)を参照してください。 + **カスタマイズリクエストのターゲットとなるアカウントが DynamoDB テーブル `aft-request-metadata` には存在するが、アカウントリクエストリポジトリに存在しない** 次のいずれかを実行して、問題のあるアカウントを除外するようにカスタマイズ呼び出しリクエストを書式設定します。 + DynamoDB テーブル `aft-request-metadata` で、アカウントリクエストリポジトリに存在しないアカウントを参照するエントリを削除する。 + 「all」をターゲットとして使用しない。 + アカウントが属する 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 クエリを使用して、ターゲットアカウントとカスタマイズリクエスト ID を含むログをフィルタリングすることで、カスタマイズリクエストの追跡とトラブルシューティングを行うこともできます。詳細については、「[AFT アカウントカスタマイズリクエストの追跡によるトラブルシューティング](https://docs.aws.amazon.com/controltower/latest/userguide/aft-account-customization-options.html)」を参照してください。