翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # 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)」を参照してください。