

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# AWS Control Tower とは
<a name="what-is-control-tower"></a>

AWS Control Tower は、規範的なベストプラクティスに従って、AWSマルチアカウント環境をセットアップして管理するための簡単な方法を提供します。AWS Control Tower は、AWS Organizations、AWS Service Catalog、 など、他のいくつかの [AWSサービスの](https://docs.aws.amazon.com//controltower/latest/userguide/integrated-services.html)機能を*オーケストレーション*してAWS IAM アイデンティティセンター、1 時間以内にランディングゾーンを構築します。リソースは、ユーザーに代わって設定および管理されます。

AWS Control Tower オーケストレーションは の機能を拡張しますAWS Organizations。組織やアカウントに、ベストプラクティスからの逸脱である**ドリフトをさせないために、AWS Control Tower はコントロール **(ガードレールと呼ばれることもあります) を適用します。例えば、コントロールを使用して、セキュリティログと必要なクロスアカウントアクセス許可が作成され、変更されないようにすることができます。

少数のアカウントをホストしている場合は、アカウントデプロイとアカウントガバナンスを容易にするオーケストレーションレイヤーを持つことは有益です。AWS Control Tower は、アカウントとインフラストラクチャをプロビジョニングする主な方法として採用できます。AWS Control Tower を使用すると、より簡単に企業基準を遵守し、規制要件を満たし、ベストプラクティスに従うことができます。

AWS Control Tower を使用すると、分散チームのエンドユーザーは、Account Factory で設定可能なAWSアカウントテンプレートを使用して、新しいアカウントをすばやくプロビジョニングできます。一方、中央のクラウド管理者は、すべてのアカウントが、確立された、会社全体のコンプライアンスポリシーと連携していることをモニタリングできます。

つまり、AWS Control Tower は、何千もの企業と連携することで確立されたベストプラクティスに基づいて、安全で準拠したマルチアカウントAWS環境を設定および管理する最も簡単な方法を提供します。AWS Control Tower の使用とAWS、マルチアカウント戦略で説明されているベストプラクティスの詳細については、「」を参照してください[AWS マルチアカウント戦略: ベストプラクティスガイダンス](aws-multi-account-landing-zone.md#multi-account-guidance)。

## 機能
<a name="features"></a>

AWS Control Tower には次の機能があります。
+ **ランディングゾーン** — ランディングゾーンは、セキュリティとコンプライアンスのベストプラクティスに基づく、優れたアーキテクチャ設計の[複数アカウントの環境](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/appendix-e-establish-multi-account.html#example-workloads-flat-structure)です。これは、すべての組織単位 (OU)、アカウント、ユーザー、およびコンプライアンス規制の対象とするその他のリソースを保持するエンタープライズ全体のコンテナです。ランディングゾーンは、いずれの規模の企業のニーズに合わせてもスケーリングできます。
+ **コントロール** – コントロール (*ガードレール*と呼ばれることもあります) は、AWS環境全体に継続的なガバナンスを提供する高レベルのルールです。これは、わかりやすい形式で表されます。予防コントロール、検出コントロール、プロアクティブコントロールの 3 種類があります******。必須、強く推奨、選択的の 3 つのガイダンスカテゴリが適用されます。******コントロールの詳細については、「[コントロールの仕組み](how-controls-work.md)」を参照してください。
+ **Account Factory** — Account Factory は、事前に承認されたアカウント設定で新規アカウントのプロビジョニングを標準化するのに役立つ、設定可能なアカウントテンプレートです。AWS Control Tower には、組織内でアカウントプロビジョニングワークフローの自動化を支援する、組み込みの Account Factory が用意されています。詳細については、「[Account Factory でのアカウントのプロビジョニングと管理](account-factory.md)」を参照してください。
+ **ダッシュボード** — このダッシュボードでは、中央のクラウド管理者のチームがランディングゾーンを継続的に監視できます。このダッシュボードを使用して、企業全体でプロビジョニングされているアカウント、ポリシーの適用に対して有効にされているコントロール、ポリシーの非準拠の継続的検出に対応するコントロール、およびアカウントと OU によって編成され非準拠リソースを確認できます。

## AWS Control Tower が他のAWSサービスとやり取りする方法
<a name="related-services"></a>

AWS Control Tower はAWS Service CatalogAWS IAM アイデンティティセンター、 や などの信頼できるAWSサービス上に構築されていますAWS Organizations。詳細については、「[統合サービス](integrated-services.md)」を参照してください。

既存のワークロードの移行に役立つソリューションに、AWS Control Tower を他のAWSサービスに組み込むことができますAWS。詳細については、「[How to take advantage of AWS Control Tower and CloudEndure to migrate workloads to AWS](https://aws.amazon.com//blogs/mt/how-to-take-advantage-of-aws-control-tower-and-cloudendure-to-migrate-workloads-to-aws/)」(AWS Control Tower と CloudEndure を活用してワークロードを AWS に移行する方法) を参照してください。

**構成、ガバナンス、拡張性**
+ *自動アカウント設定:* AWS Control Tower は、AWS Service Catalogのプロビジョニングされた製品の上に抽象化として構築された Account Factory (または「自動販売機」) を使用して、アカウントのデプロイと登録を自動化します。Account Factory はAWSアカウントを作成および登録でき、それらのアカウントにコントロールとポリシーを適用するプロセスを自動化します。アカウントの作成とプロビジョニングの詳細については、「[プロビジョニングの方法](https://docs.aws.amazon.com//controltower/latest/userguide/methods-of-provisioning.html)」を参照してください。
+ *一元化されたガバナンス:* の機能を採用することでAWS Organizations、AWS Control Tower はマルチアカウント環境全体で一貫したコンプライアンスとガバナンスを確保するフレームワークをセットアップします。このAWS Organizationsサービスは、アカウントの中央ガバナンスと管理、AWS Organizations APIs からのアカウント作成、サービスコントロールポリシー (SCPs)、リソースコントロールポリシー (RCPs) など、マルチアカウント環境を管理するための重要な機能を提供します。

  
+ *拡張性:* AWS Control Tower コンソールだけでなく、 で直接作業することでAWS Organizations、独自の AWS Control Tower 環境を構築または拡張できます。既存の組織を登録し、既存のアカウントを AWS Control Tower に登録すると、変更が AWS Control Tower に反映されていることがわかります。AWS Control Tower ランディングゾーンを更新して、変更を反映させることができます。ワークロードにさらに高度な機能が必要な場合は、AWS Control Tower とともに他のAWSパートナーソリューションを活用できます。

  

## AWS Control Tower を初めてお使いになる方に
<a name="first-time-user"></a>

このサービスを初めて使用する方には、以下を読むことをお勧めします。

1. ランディングゾーンを計画および整理する方法の詳細については、「[AWS Control Tower ランディングゾーンの計画](planning-your-deployment.md)」および「[AWS AWS Control Tower ランディングゾーンのマルチアカウント戦略](aws-multi-account-landing-zone.md)」を参照してください。

1. 最初のランディングゾーンを作成する準備ができている場合は、「[AWS Control Tower の使用開始方法](getting-started-with-control-tower.md)」を参照してください。

1. ドリフトの検出と防止の詳細については、「[AWS Control Tower でドリフトを検出および解決する](drift.md)」を参照してください。

1. セキュリティの詳細については、「[AWS Control Tower のセキュリティ](security.md)」を参照してください。

1. ランディングゾーンおよびメンバーアカウントの更新方法については、「[AWS Control Tower での設定更新管理](configuration-updates.md)」を参照してください。

# AWS Control Tower の仕組み
<a name="how-control-tower-works"></a>

このセクションでは、AWS Control Tower がどのように動作するかを大まかに説明します。ランディングゾーンは、すべての AWS リソース用に適切に設計されたマルチアカウント環境です。この環境を使用して、すべての AWS アカウントにコンプライアンス規制を適用できます。

## AWS Control Tower のランディングゾーンの構造
<a name="landing-zone-structure"></a>

AWS Control Tower のランディングゾーンの構造は次のとおりです。
+ **ルート** - ランディングゾーン内の他のすべての OU を含む親。
+ **セキュリティ OU** - この OU には、ログアーカイブアカウントと監査アカウントが含まれています。これらのアカウントは、共有アカウント**とも呼ばれます。ランディングゾーンを起動するときに、これらの共有アカウントのカスタマイズされた名前を選択できます。また、セキュリティとログ記録のために既存の AWS アカウントを AWS Control Tower に持ち込むオプションもあります。ただし、これらの名前を後で変更することはできません。また、初回起動後にセキュリティとログ記録のために既存のアカウントを追加することはできません。
+ **サンドボックス OU** - サンドボックス OU は、ランディングゾーンを有効にしている場合にランディングゾーンを起動すると作成されます。このメンバー OU と他のメンバー OU には、ユーザーが AWS ワークロードを実行するために使用する登録済みアカウントが含まれています。
+ **IAM Identity Center ディレクトリ** - デフォルトでは、このディレクトリには、IAM Identity Center ユーザーが格納されます。これは、各 IAM Identity Center ユーザーの許可の範囲を定義します。オプションで、ID とアクセスコントロールを自己管理することを選択できます。詳細については、[「IAM Identity Center と AWS AWS Control Tower の使用](https://docs.aws.amazon.com/controltower/latest/userguide/sso.html)」を参照してください。
+ **IAM Identity Center ユーザー** – ランディングゾーンで AWS ワークロードを実行するためにユーザーが引き受けることができる ID です。

## ランディングゾーンをセットアップした場合に起きること
<a name="how-it-works-setup"></a>

ランディングゾーンをセットアップすると、ユーザーに代わって AWS Control Tower が管理アカウントで次のアクションを実行します。
+  AWS Organizations 組織のルート構造に含まれるセキュリティとサンドボックス (オプション) の 2 つの組織単位 (OUs) を作成します。
+ セキュリティ OU 内に共有アカウントを 2 つ作成または追加する (ログアーカイブアカウントと監査アカウント)。
+ デフォルトの AWS Control Tower 設定を選択した場合や、ID プロバイダーを自己管理できる場合は、事前設定されたグループとシングルサインオンアクセスを使用して、IAM Identity Center にクラウドネイティブディレクトリを作成します。
+ 必須の予防コントロールをすべて適用してポリシーを実施する。
+ 必須の検出コントロールをすべて適用して設定違反を検出する。
+ *予防コントロールは管理アカウントには適用されません。*
+ 管理コントロールを除き、ガードレールを組織全体に適用する。

**AWS Control Tower ランディングゾーンおよびアカウント内のリソースの安全な管理**
+ ランディングゾーンを作成すると、多数の AWS リソースが作成されます。AWS Control Tower を使用するには、このガイドで説明されたサポートされている方法以外で、これらの AWS Control Tower マネージドリソースを変更または削除することはできません。これらのリソースを変更または削除すると、ランディングゾーンの状態が不明になります。詳細については、「[AWS Control Tower リソースの作成と変更に関するガイダンス](getting-started-guidance.md)」を参照してください。
+ オプションのコントロール (*強く推奨または選択的*ガイダンスを持つコントロール) を有効にすると、AWS Control Tower はアカウントで管理する AWS リソースを作成します。AWS Control Tower によって作成されたリソースを変更または削除しないでください。これにより、コントロールの状態が不明になる可能性があります。

# 共有アカウントとは
<a name="what-shared"></a>

AWS Control Tower では、ランディングゾーンの共有アカウント (管理アカウント、ログアーカイブアカウント、および監査アカウント) がセットアップ時にプロビジョニングされます。

## 管理アカウントとは
<a name="what-is-mgmt"></a>

これは、ランディングゾーン専用に作成したアカウントです。このアカウントは、ランディングゾーンでのすべての請求に使用されます。また、このアカウントは、OU とコントロールの管理だけでなく、アカウントの Account Factory プロビジョニングに使用することもできます。

**注記**  
AWS Control Tower 管理アカウントから運用ワークロードを実行することはお勧めしません。ワークロードを実行する別の AWS Control Tower アカウントを作成します。

詳細については、「[管理アカウント](special-accounts.md#mgmt-account)」を参照してください。

## ログアーカイブアカウントとは
<a name="what-is-log-archive"></a>

このアカウントは、ランディングゾーン内のすべてのアカウントからの API アクティビティとリソース設定に関するログのリポジトリとして使用されます。

詳細については、「[ログアーカイブアカウント](special-accounts.md#log-archive-account)」を参照してください。

## 監査アカウントとは
<a name="what-is-audit"></a>

監査アカウントは、セキュリティチームとコンプライアンスチームに対してランディングゾーンのすべてのアカウントへの読み書きアクセスを許可するように設計された制限付きのアカウントです。監査アカウントからは、Lambda 関数にのみ付与されるロールを使用して、アカウントをレビューするためにプログラムによってアクセスできます。監査アカウントでは、他のアカウントに手動でログインすることはできません。Lambda 関数とロールの詳細については、「[別の  AWS アカウント からロールを引き受けるように Lambda 関数を設定する](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-function-assume-iam-role)」を参照してください。

詳細については、「[監査アカウント](special-accounts.md#audit-account)」を参照してください。

# コントロールの仕組み
<a name="how-controls-work"></a>

コントロールは、 AWS 環境全体に継続的なガバナンスを提供する高レベルのルールです。各コントロールは 1 つのルールを適用します。これは、わかりやすい言語で示されます。有効になっている選択的コントロールまたは強く推奨されるコントロールを AWS Control Tower コンソールまたは AWS Control Tower API からいつでも変更できます。必須コントロールは常に適用され、変更することはできません。

予防コントロールにより、アクションの発生が防止されます。例えば、**[Disallow Changes to Bucket Policy for Amazon S3 Buckets]** (Amazon S3 バケットのバケットポリシーへの変更を不許可にする) という選択的コントロール (以前の名称は **[Disallow Policy Changes to Log Archive]** (ログアーカイブへのポリシーへの変更を不許可にする)) により、ログアーカイブ共有アカウント内で IAM ポリシーを変更できなくなります。禁止されたアクションを実行しようとすると、拒否され、CloudTrail に記録されます。リソースもログインします AWS Config。

検出コントロールにより、特定のイベントが発生したときにそのイベントが検出され、アクションが CloudTrail に記録されます。例えば、**[Detect Whether Encryption is Enabled for Amazon EBS Volumes Attached to Amazon EC2 Instances]** (Amazon EC2 インスタンスにアタッチされた Amazon EBS ボリュームに対して暗号化が有効になっているかどうかを検出する) という強く推奨されるコントロールにより、暗号化されていない Amazon EBS ボリュームがランディングゾーンの EC2 インスタンスにアタッチされているかどうかが検出されます。

プロアクティブコントロールは、リソースがアカウントにプロビジョニングされる前に、リソースが会社のポリシーと目標に準拠しているかどうかを確認します。リソースがポリシーと目標に準拠していない場合、リソースはプロビジョニングされません。プロアクティブコントロールは、 CloudFormation テンプレートを使用してアカウントにデプロイされるリソースをモニタリングします。

*に精通しているユーザーの場合 AWS: *AWS Control Tower では、予防コントロールはサービスコントロールポリシー (SCPs) とリソースコントロールポリシー (RCPs。検出コントロールは AWS Config ルールで実装されます。プロアクティブコントロールは CloudFormation フックで実装されます。

## 関連トピック
<a name="how-controls-related"></a>
+ [AWS Control Tower でドリフトを検出および解決する](drift.md)

## AWS Control Tower と StackSets が動作する仕組み
<a name="stacksets-how"></a>



AWS Control Tower は、デフォルトで CloudFormation StackSets を使用してアカウントのリソースを設定します。各スタックセットには、アカウントとアカウント AWS リージョン ごとの に対応する StackInstances があります。AWS Control Tower は、アカウントとリージョンごとに 1 つのスタックセットインスタンスをデプロイします。

AWS Control Tower は、 CloudFormation パラメータに基づいて、特定のアカウントおよび AWS リージョン 選択的に更新を適用します。更新が一部のスタックインスタンスに適用されると、他のスタックインスタンスが **OUTDATED** ステータスのままになることがあります。これは想定内の正常な動作です。

スタックインスタンスが **OUTDATED** 状態になった場合は通常、そのスタックインスタンスに対応するスタックがスタックセットの最新のテンプレートと合致していないことになります。スタックは古いテンプレートに残っているため、最新のリソースやパラメータが含まれていない可能性があります。スタックはまだ完全に使用可能です。

 更新時に指定された CloudFormation パラメータに基づいて、想定される動作を簡単にまとめます。

スタックセットの更新にテンプレートへの変更が含まれている場合 (つまり、 `TemplateBody`または `TemplateURL`プロパティが指定されている場合）、または `Parameters`プロパティが指定されている場合、 は、指定されたアカウントのスタックインスタンスを更新する前に、ステータスが **Outdated **のすべてのスタックインスタンスを CloudFormation マークします AWS リージョン。スタックセットの更新にテンプレートまたはパラメータの変更が含まれていない場合、 は指定されたアカウントとリージョンのスタックインスタンス CloudFormation を更新し、他のすべてのスタックインスタンスは既存のスタックインスタンスのステータスのままにします。スタックセットに関連付けられたすべてのスタックインスタンスを更新するには、`Accounts` プロパティまたは `Regions` プロパティを指定しないでください。

詳細については、「 CloudFormation ユーザーガイド」の[「スタックセットの更新](https://docs.aws.amazon.com//AWSCloudFormation/latest/UserGuide/stacksets-update.html)」を参照してください。