翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ランディングゾーンを構築する
AWS Transform は、移行プロジェクトの一環としてラン AWS ディングゾーンを設計およびデプロイするガイドを提供します。ランディングゾーンは、ワークロードが到着する前に、組織の境界、ガバナンスコントロール、アカウント構造を備えたワークロードの基盤として機能するマルチアカウント AWS 環境です。 AWS Transform は、移行インベントリとビジネス要件を分析して、組織単位 (OU) とアカウント構造を推奨し、推奨されるサービスコントロールポリシー (SCPs) を適用し、Infrastructure as Code (IaC) を生成および/またはデプロイします。
ランディングゾーンエージェントは、次の 2 つのフェーズを順を追って説明します。
+ **基盤のセットアップ** – コアランディングゾーン構造、 AWS Control Tower、基盤 OUs、コアアカウントを確立します。
+ **ワークロードアカウント設計** – 移行の波、ビジネスユニット、環境分離要件に基づいてワークロード OUs とアカウントを設計および作成します。
AWS Transform は、グリーンフィールド環境 (既存のランディングゾーンなし) とブラウンフィールド環境 (既存の OUs とアカウントがデプロイ済み) の両方をサポートしています。ブラウンフィールドシナリオでは、 AWS Transform は既存の組織構造を検出し、 AWS ベストプラクティスとのギャップを埋めるために必要な変更のみを推奨します。
## コネクタのセットアップ
ランディングゾーンエージェントには、組織管理アカウントにリソースをプロビジョニングするためのターゲット AWS アカウント コネクタが必要です。コネクタには、次のアクセス許可があります。
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) のセットアップ
+ [組織単位とアカウント](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html)を作成する
+ [サービスコントロールポリシー (SCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)を設定する
コネクタリクエストを承認すると、 AWS 変換アクセス許可が付与されます。
+ ターゲットとリージョンでランディングゾーンインフラストラクチャをプロビジョニング AWS アカウント および管理します。これには、以下の項目のアクセス許可が含まれ、`ATWorkspace:{workspace-id}`該当する場合、 `CreatedBy:AWSTransform`および でタグ付けされたリソースに制限されます。
+ で始まるバケットの S3 バケットオペレーション (作成、読み取り、書き込み、削除) `transform-vmware-landing-zone-`
+ CloudFormation ランディングゾーンスタックのスタックデプロイと変更セット管理
+ AWS Control Tower オペレーション (ランディングゾーンの管理、ベースラインとコントロールの有効化)
+ [AWS 組織の](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)管理 (組織単位の作成と管理、アカウントの作成、アカウントの移動)
+ AWS Control Tower によるサービスコントロールポリシー (SCP) 管理
+ [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html) プロビジョニングアーティファクト管理
コネクタを作成するときは、ターゲットを指定します AWS リージョン。このリージョンは、ホーム Control Tower リージョンと同じである必要があります。Control Tower リージョンの詳細については、[AWS 「Control Tower AWS リージョン の操作](https://docs.aws.amazon.com/controltower/latest/userguide/region-how.html)方法」を参照してください。
ランディングゾーンのセットアップの開始時に、 AWS Transform はコネクタ設定を取得し、確認のために AWS Organization 管理アカウント ID とターゲットリージョンを表示します。詳細については、「[AWS 変換コネクタ](transform-user-connectors.md)」を参照してください。
**重要**
**IAM アイデンティティセンターリージョンの依存関係** – AWS 変換には AWS IAM アイデンティティセンター (IAM アイデンティティセンター) が必要です。つまり、コネクタリージョンは AWS Control Tower ホームリージョン*と* IAM アイデンティティセンターリージョンの両方と一致する必要があります。IAM Identity Center が組織で既に設定されている場合、 AWS コネクタが別のリージョンをターゲットとしている場合、Control Tower の初期化は失敗します。詳細については、「 Control Tower ユーザーガイド」の[「IAM Identity Center のお客様向けの考慮事項](https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-prereqs.html) AWS 」を参照してください。
## 基盤のセットアップ
基盤設定フェーズでは、[AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) を使用してコアランディングゾーンインフラストラクチャを確立します。 AWS Control Tower がランディングゾーンを設定すると、管理アカウントに一連のマネージドリソースが自動的にプロビジョニングされ、 AWS 組織全体のガバナンス基盤を形成します。
+ **ルート** – ランディングゾーン内のすべての OUs を含む最上位の親。
+ **セキュリティ OU** – Control Tower によって自動的に作成されます。**ログアーカイブ**アカウント (組織全体のすべての AWS API アクティビティとリソースの変更に対する一元管理されたイミュータブルなログ記録) と**監査アカウント** (セキュリティとコンプライアンスのレビューのためのすべてのアカウントへの読み取り専用アクセス) の 2 つの共有アカウントが含まれます。これらのアカウントの名前を変更したり、初期設定後に置き換えたりすることはできません。
+ **必須コントロール (ガードレール)** – Control Tower は、予防コントロールと検出コントロールを組織全体に自動的に適用して、ベースラインガバナンスポリシーを適用します。これらを無効にすることはできません。
+ **IAM Identity Center ディレクトリ** – Control Tower は、ランディングゾーンユーザーの事前設定されたグループとシングルサインオンアクセスを持つクラウドネイティブディレクトリを作成します。詳細については、[AWS 「IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」を参照してください。
Control Tower は [CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) を使用して、組織内のすべてのアカウントとリージョンにこれらのリソースを一貫してデプロイおよび管理します。ランディングゾーンが不明な状態になる可能性があるため、サポートされている方法以外で Control Tower マネージドリソースを変更または削除しないでください。
### アカウントの E メール規則
AWS では、アカウントごとに一意の E メールアドレスが必要です。これらの E メールは、アカウントに関する重要な通知を受け取ります。 AWS Transform は、 と アドレス指定を使用して、単一のメールボックスから一意のアカウント E メールを生成します。
形式: `prefix+account-name@domain`
プレフィックス ( など`aws-admin`) とドメイン ( など`acme.com`) を指定すると、 AWS 変換によってすべてのアカウント E メールが自動的に取得されます。例えば、次のようになります。
+ 監査アカウント: `aws-admin+audit@acme.com`
+ ログアーカイブアカウント: `aws-admin+log-archive@acme.com`
+ サンドボックスアカウント: `aws-admin+sandbox@acme.com`
ブラウンフィールドシナリオでは、 AWS Transform は既存のアカウント E メールを検査して、既に使用されているプラスアドレス規則を推測し、同じパターンを続行することを提案します。
### 推奨される基盤構造
AWS ベストプラクティスに基づいて、 AWS Transform は次の基盤 OU 構造を推奨します。作成前にカスタマイズできます。
| OU | 目的 | アカウント |
| --- | --- | --- |
| セキュリティ | 一元化された監査ログ記録とモニタリング。これらのサービスを専用アカウントで分離することは、監査証跡をワークロードチームと分離するのに役立ちます。 | 監査、ログアーカイブ |
| インフラストラクチャ | 共有ネットワーキング (Transit Gateway、VPN)、DNS、および共通サービス。重複を減らし、ネットワークチームが 1 か所で接続を管理することができるように、これらを一元化することをお勧めします。 | なし (空で作成) |
| サンドボックス | 支出制限とアクセス制限に関するデベロッパー実験。本番環境のリソースを危険にさらすことなく、デベロッパーに実験するスペースを与えることをお勧めします。 | サンドボックス |
| ワークロード | Production、Non-Production、およびオプションで規制されたサブ OUs。ワークロードアカウントは、移行要件に基づいて次のフェーズで設計されています。 | なし (空で作成) |
**注記**
[監査アカウントとログアーカイブアカウント](https://docs.aws.amazon.com/controltower/latest/userguide/accounts.html)を含むセキュリティ OU は、Control Tower 基盤設定の一部として作成されます。インフラストラクチャ、サンドボックス、ワークロード OUs は、構造を確認した後に個別に作成されます。
ブラウンフィールドシナリオでは、 AWS Transform は既存の基盤をこの推奨構造と比較し、ギャップのみをレポートします。例：「基盤にはセキュリティとインフラストラクチャの OUs」
### サービスコントロールポリシー (SCP)
SCPs は[、組織内のすべてのアカウントに最大アクセス許可を設定する組織レベルのアクセス許可ガードレール](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)です。 AWS アクセスを許可しません。代わりに、アカウント管理者であっても、アカウント内の誰も超えることができない境界を定義します。
Control Tower のデプロイの一環として、ベースラインガードレールが自動的に適用されます。 AWS Transform は、組織の体制を強化するために設計された追加の SCPs も推奨します。これらは、実行可能な最小ランディングゾーンの AWS ベストプラクティスに基づいています。
SCPs は、インフラストラクチャ、サンドボックス、ワークロード OUs に適用できます。Security OU は Control Tower によって管理され、このツールを通じて SCPsによってターゲットにすることはできません。
**重要**
Security OU は、Control Tower によって管理される基盤 OU です。ランディングゾーンエージェントを介してアカウント、SCPs、またはリソースを追加することはできません。
ブラウンフィールドシナリオでは、 AWS Transform はどの SCPs がすでに適用されているかをチェックし、ギャップを埋める SCP のみを推奨します。
### Foundation のデプロイ
基盤設計が完了したら、デプロイ方法を選択します。
+ **Deploy for me** – AWS Transform は基盤 OUs、アカウント、SCPs を Organization にデプロイします AWS 。
+ **自分でデプロイする** – AWS 変換は、任意の形式でダウンロードするための Infrastructure as Code (IaC) アーティファクトを生成します (「」を参照)[IaC 形式](#transform-vmware-lz-iac-formats)。
+ **ワークロードアカウントを最初に設計**する – デプロイをスキップし、ワークロードアカウント設計フェーズに進みます。すべては後でまとめてデプロイできます。
#### Control Tower の初期化
AWS Transform は、組織内で AWS Control Tower がまだ初期化されていないことを検出した場合、 AWS 変換コンソールページへのリンクをユーザーに提供します。リンクで オペレーションを生成すると、Control Tower をブートストラップする CloudFormation スタックが作成されます。このプロセスでは、ターゲットリージョンの CloudFormation コンソールにこのスタックが作成されます。スタックの作成が完了すると、 AWS Transform はデプロイを続行します。
## ワークロードアカウント設計
ワークロードアカウント設計フェーズでは、 AWS Transform は、移行インベントリ、ビジネス要件、環境分離設定に基づいて、アプリケーションワークロードの OU とアカウント構造を設計します。
### 移行計画コンテキスト
AWS Transform は、ウェーブプラン、server-to-applicationマッピング、共有コンテキストなど、移行計画フェーズからデータを取得します。移行計画データが利用可能な場合、 AWS Transform は概要を表示し、確認または調整するよう求めます。移行計画データが利用できない場合、 AWS Transform は検出に直接質問をします。
### 発見
AWS Transform は、ワークロードの要件を理解するために質問します。質問はスキップできます。トピックは以下のとおりです。
+ を使用するビジネスユニットまたはチームの数 AWS
+ 業界および該当するフレームワーク (HIPAA、PCI-DSS、SOC2、FedRAMP)
+ ワークロードが機密データ (PII、PHI、財務) を処理するかどうか
+ 環境分離設定 (開発dev/test/staging/個別のアカウントまたは共有として生成)
+ ワークロードの分離要件
+ ビジネスアプリケーションとその目的
+ アプリケーションへのサーバーグループ化
+ コスト追跡と配分のニーズ (ビジネスユニット、プロジェクト、環境別)
+ 今後 12～24 か月に予想される増加
+ アカウント戦略の設定 (アカウント、グループ化、または環境ベースごとに 1 つのアプリ)
### 提案されたワークロード構造
回答と移行計画データに基づいて、 AWS Transform はワークロード OU の下に OU とアカウント構造を提案します。この提案には、各設計決定の背後にある推論が含まれています。
AWS 変換は、次の設計原則に従います。
+ 移行ウェーブ内のすべてのサーバーは同じアカウントに送られます。ウェーブをアカウント間で分割することはできません。これは、ウェーブ実行中のリホスト制限です。
+ 分離された環境をリクエストすると、 AWS Transform はワークロード/本番稼働用およびワークロード/非本番稼働用サブ OUsを作成します。
+ 該当するフレームワークが特定された場合、 AWS Transform はワークロード/規制対象およびワークロード/標準サブ OUsを作成します。
+ 複数のビジネスユニットが異なるガバナンスを必要とする場合、 AWS Transform はワークロードの下にbusiness-unit-specific OUs を作成します。
+ 重要または機密データアプリケーションは、アカウントごとに 1 つのアプリケーションを取得します。この場合、ウェーブプランを反復するように求められることがあります。
+ 依存関係を共有する緊密に結合されたアプリケーションは、1 つのアカウントにグループ化されます。
提案された各アカウントには、名前、目的、ターゲット OU、ビジネスユニットが含まれます。 AWS Transform は、使用されている命名規則を示します (例: `--`)。
AWS Transform が変更を適用する前に、提案された構造を確認して変更できます。適用後、反復して、満足するまで追加の変更を加えることができます。
### ワークロード SCP 設定
ワークロード構造が作成されると、 AWS Transform は使用可能な SCPs を提示し、ワークロード OUs。適用SCPs と OUs. AWS Transform が SCPsし、更新された組織ツリーを SCP 概要テーブルとともに表示します。
### ワークロードのデプロイ
ワークロード設計が完了したら、デプロイ方法を選択します。
+ **Deploy for me** – AWS Transform はワークロード OUs、アカウント、SCPs を Organization にデプロイします AWS 。
+ **自分でデプロイする** – AWS 変換は IaC アーティファクトを生成して任意の形式でダウンロードします (「」を参照[IaC 形式](#transform-vmware-lz-iac-formats))。
## IaC 形式
自己デプロイを選択すると、 AWS Transform は次の形式で Infrastructure as Code アーティファクトを生成します。
+ **[AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html)** – プログラムによるインフラストラクチャデプロイ用の TypeScript プロジェクト。
+ **HashiCorp Terraform** – ランディングゾーンリソースを管理するための HashiCorp 設定言語 (HCL) テンプレートを生成します。
+ **Landing Zone Accelerator (LZA)** – LZA ユニバーサル設定バージョン 1.1.0 に基づく設定 YAML ファイル。これらのエンタープライズ対応テンプレートは、 の Landing Zone Accelerator と連携して、マルチアカウント AWS 環境を確立 AWS します。生成されたファイルには、 AWS ベストプラクティスに沿ったガバナンス、組織構造、ネットワークのための事前設定が含まれています。詳細については、[「LZA ユニバーサル設定](https://docs.aws.amazon.com/solutions/latest/landing-zone-accelerator-on-aws/universal-configuration.html)」を参照してください。
**注記**
Landing Zone Accelerator (LZA) パイプラインを介してデプロイする場合、 AWS 変換アカウントと LZA のインストールは同じ AWS Organization に存在する必要があります。 AWS Transform と LZA で使用される Organizations IDs が一致しない場合、デプロイは失敗します。Organizations を使用して LZA インストールを設定する方法については、[AWS 「Organizations ベースのインストール](https://docs.aws.amazon.com/solutions/latest/landing-zone-accelerator-on-aws/aws-organizations-based-installation.html)」を参照してください。
形式を選択すると、 AWS Transform はアーティファクトを生成し、ダウンロードできるようにします。
ダウンロードしたファイルが破損または改ざんされていないことを確認するには、チェックサムを生成してダウンロードし、以下を使用してローカルに生成されたハッシュと比較します。
```
openssl dgst -sha256 -binary | base64
```
## デプロイの承認プロセス
ランディングゾーンのデプロイリクエストには、実行前に明示的な承認が必要です。デプロイリクエストを送信すると、 AWS Transform Approvals タブを介して承認済承認者に自動的にルーティングされます。
承認者は CloudFormation テンプレートとランディングゾーンの設定を確認します。 AWS Transform の管理者ロールを持つユーザーのみがデプロイリクエストを承認できます。各送信は新しいレビューサイクルをトリガーし、デプロイは確認を受け取った後にのみ続行されます。
承認者がリクエストを拒否した場合は、直接連絡して必要な変更について話し合います。システムは、監査目的でのすべての承認決定を追跡し、デプロイ履歴を維持します。
## ランディングゾーンリソースにタグを付ける
AWS 変換は、追跡のために、生成されたすべてのリソースに定義と実行 IDs `"CreatedBy": "AWSTransform"`とともに自動的にタグ付けします。
### 自動タグ
すべてのランディングゾーンリソースには、次のタグが付けられます。
+ `CreatedBy` – AWSTransform
+ `ATWorkspace` – ワークスペース識別子
**注記**
移行が AWS Migration Acceleration Program (MAP 2.0) の一部である場合は、必要な MAP タグとして Key: `map-migrated` Value: `migMPE_ID` (MPE\_ID は移行ポートフォリオ評価識別子) を含めることができます。MAP タグは、コネクタのセットアップフェーズ中にリクエストされます。 AWS Transform は、ランディングゾーンのデプロイ中にこれらのタグを適用します。
## 変更の取り消し
削除できるのは、デプロイされていない要素のみです。OU またはアカウントがデプロイされると、ランディングゾーンエージェントを介して削除することはできません。
要素を削除する場合、順序は重要です。親の前に子を削除する必要があります。
1. まず (E メールで) アカウントを削除します。
1. OUs から SCPs を削除します。
1. 子 OUs の削除 — アカウントまたはネストされた OU がまだある場合OUs を削除することはできません。
## 関連リソース
+ [ターゲットの AWS アカウントとリージョンを接続する](transform-vmware-connect-target-account.md)
+ [ネットワークを に移行する AWS](transform-vmware-migrate-network.md)
+ [AWS Control Tower ユーザーガイド](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS Organizations ユーザーガイド](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)
+ [AWS IAM Identity Center ユーザーガイド](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)
+ [CloudFormation ユーザーガイド](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [でのランディングゾーンアクセラレーター AWS](https://aws.amazon.com/solutions/implementations/landing-zone-accelerator-on-aws/)
+ [AWS Well-Architected フレームワーク](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)
+ [AWS 規範ガイダンス: ランディングゾーンの構築](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-landing-zone/welcome.html)