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

# プラットフォーム基盤
<a name="platform-foundation"></a>

このセクションでは、オンプレミスインフラストラクチャの準備状況の評価、 AWS ランディングゾーンの準備または既存のランディングゾーン設計の確認、必要な移行ツールの特定に焦点を当てます。プラットフォームの構築時に考慮すべきインフラストラクチャ、運用、セキュリティに関する一般的な質問を確認します。回答と決定を移行原則として文書化します。その結果、大規模な移行に必要な規模と速度を実現するための強固なプラットフォームが得られます。

このセクションでは、次のトピックについて説明します。
+ [大規模な移行におけるランディングゾーンに関する考慮事項](landing-zone.md)
+ [大規模な移行に関するオンプレミスの考慮事項](on-premises.md)
+ [移行原則を文書化する](document.md)

# 大規模な移行におけるランディングゾーンに関する考慮事項
<a name="landing-zone"></a>

*ランディングゾーン*は、スケーラブルで安全な、適切に設計された AWS 環境です。アカウント数の定義やサブネットとセキュリティグループの設計など、ランディングゾーンの標準を確立することで、強固な基盤を構築できます。この基盤により、クラウド導入ジャーニーを加速しながら、ビジネスの俊敏性とガバナンスの両方を大規模に実現、プロビジョニング、運用できます。ランディングゾーンとその構築戦略の詳細については、[「安全でスケーラブルなマルチアカウント AWS 環境のセットアップ](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/)」を参照してください。

ランディングゾーン戦略における標準的なビジネス、運用、セキュリティ、コンプライアンスに関する考慮事項に加えて、大規模な移行を容易にする方法を検討する必要があります。一部のワークロードがオンプレミスに残っている場合、移行中および移行後に既存のオンプレミスワークロードをサポートするようにランディングゾーンを設計する必要があります。このガイドでは、移行の速度と全体的な移行タイムラインに影響するランディングゾーンに関する追加の考慮事項について説明します。

通常、ランディングゾーンは の新しいワークロードをサポートするように設計およびデプロイされます AWS クラウド。これは、組織が多数の既存のアプリケーションを移行 AWS する前に を採用しているためです。このアプローチの利点は、組織が大規模な移行 AWS の前に で貴重な知識とスキルを得るが、さまざまな利害関係者間の競合につながる可能性があることです。一部の利害関係者は、クラウドネイティブ機能を活用したいため、移行中にアプリケーションをモダナイズしたい場合があります。ただし、大規模な移行の一般的な目標は、ワークロードを変更せずにできるだけ多くのアプリケーションを移行することで、移行速度を最大化し、移行を容易にすることです。次に、移行が完了したら、これらのアプリケーションをモダナイズします。

大規模な移行プログラムプロジェクトに影響を与えるランディングゾーンの主な要因は次のとおりです。
+ ネットワーク帯域幅の可用性と管理
+ ワークロードの分離とリソース管理のためのアカウント戦略
+ 移行されたワークロードのセキュリティおよび管理コントロール

このセクションでは、 AWS ランディングゾーンを構築する際に考慮すべきインフラストラクチャ、運用、セキュリティに関する質問について説明します。また、大規模な移行プロジェクトをサポートするためにランディングゾーンを設計およびデプロイする方法に関する推奨事項も含まれています。このセクションの質問に回答すると、これらの決定は移行原則になり、[「大規模な移行原則として決定を文書化する」の指示に従って文書化します](document.md)。

## インフラストラクチャの考慮事項
<a name="infrastructure"></a>


| 検討したことはありますか？ | 説明 | アクション | 
| --- | --- | --- | 
|  1 日あたりおよび 1 週間あたりに移行するデータの量  |  必要な移行速度によって、ネットワーク接続のタイプとネットワークスループット要件が決まります。また、ウェーブプランニングの選択条件にも影響します。  |  ポートフォリオ評価が完了したら、クラウド内の移行されたすべてのリソースに必要なストレージの合計量を決定します。この値を使用して、現在のネットワーク帯域幅を使用してデータを移行するために必要な時間を計算します。移行の時間枠に合わせて帯域幅を増やす必要がある場合や、 AWS Snow Family ソリューションなどの代替手段を使用する必要がある場合があります。[基盤プレイブックテンプレート](samples/foundation-playbook-templates.zip)では、*データレプリケーション計算ツール* (Microsoft Excel 形式) を使用して、各移行ウェーブに必要な帯域幅を計算できます。  | 
|  各ウェーブのソースサーバーの平均書き込み速度はどのくらいですか？  |  レプリケートされたデータの転送に必要な帯域幅は、参加しているソースサーバーの書き込み速度に基づいています。サーバーレプリケーションに必要な帯域幅の量は、ソースサーバーの平均書き込み速度に、最大ウェーブのサーバー数を掛けたものです。  |  ポートフォリオの評価中に、各サーバーによって ごとに実行されるデータ書き込みの平均数を決定する必要があります。[基盤プレイブックテンプレート](samples/foundation-playbook-templates.zip)では、*データレプリケーション計算ツール* (Microsoft Excel 形式) を使用して、移行トラフィックに必要な帯域幅を把握できます。移行トラフィックに必要な帯域幅は、通常のビジネスアクティビティに使用される帯域幅に追加されます。移行が完了したら、移行アクティビティをサポートするために追加の帯域幅は必要ありません。  | 
|  追加のネットワークアクティビティや既存のインフラストラクチャは、レプリケーション速度を制限または低下させる可能性がありますか？  |  ネットワーク帯域幅が他のビジネス機能もサポートしている場合、これらのアクティビティにより、移行中のサーバーのレプリケーションに使用できる帯域幅の量を減らすことができます。  |  プロジェクトのライフサイクルの早い段階で、 はすべてのビジネス活動をサポートするために必要なネットワーク帯域幅を慎重に評価して計算します。通常のビジネスアクティビティ、サーバーレプリケーション、およびオンプレミスのファイル共有を のデータと同期するなどの新しい移行関連のアクティビティに必要な帯域幅を考慮します AWS。 プロバイダーは、ネットワーク容量を増やすためにリードタイムが長くなり、既存のオンプレミスインフラストラクチャのアップグレードが必要になる場合があります。ネットワークインフラストラクチャのアップグレードの結果として、追加のアップグレードが必要かどうかを検討してください。プロジェクトの早い段階で帯域幅要件を評価することで、必要な変更を加える時間を確保できます。  | 
|  現在の AWS サブネット戦略は、オンプレミスワークロードを移行するための IP アドレス指定要件を満たしていますか？  |  サーバーの数とワークロードの分離要件によって、ランディングゾーンのサブネット戦略が決まります。 大規模な移行では、想定よりも大きなサブネットが必要になる場合があります。大規模な移行では、オンプレミスインフラストラクチャのセットアップと同様のサブネットにワークロードをグループ化します。移行を簡素化するには、最初は大きくフラットなサブネット設計が推奨され、その後モダナイゼーション中に必要に応じてサブネットを再設計します。  |  ポートフォリオ評価にインフラストラクチャインベントリに関する十分な情報がある場合は、オンプレミスのネットワーク構造を評価し、できるだけ早くランディングゾーン設計に組み込みます。  | 
|  並列でレプリケートおよび移行する予定のサーバーはいくつありますか？  |  最大移行ウェーブのサイズは、サブネットの要件と[AWS サービスクォータ](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)に影響します。  |  大まかな移行計画を確認し、それを使用してサブネットを設計します。例えば、200 台のサーバーを 1 つのサブネットに移行する予定がある場合、そのサブネットのクラスレスドメイン間ルーティング (CIDR) 範囲には、サーバーのターゲット数をサポートするのに十分な IP アドレスが必要です。また、必要に応じて各ターゲットアカウントの AWS サービスクォータを引き上げます。  | 
|  移行リソースのセキュリティグループ戦略を特定しましたか？  |  セキュリティグループは、 AWS リソースのインバウンドトラフィックとアウトバウンドトラフィックを管理するために使用されます。移行が遅れないように、セキュリティグループを早期に設計することが重要です。  |  アプリケーションの優先順位付けのためのランブックで、移行戦略を確認し、移行戦略に基づいてセキュリティグループを設計します。例えば、移行戦略でほとんどのワークロードをリホストする場合は、ネットワークをリファクタリングしてアプリケーション固有のセキュリティグループを適用する代わりに、移行カットオーバーをサポートする一時的な汎用セキュリティグループを検討してください。  | 
|  ロードバランサーは使用されていますか？  |  通常、ロードバランサーのある環境のサーバーを移行する場合は、ロードバランサーの設定を評価してから、ロードバランサーを移行する必要があります。ロードバランサーの移行オプションには、Elastic Load Balancing (ELB) またはパートナーアプライアンスベースのソリューションの使用が含まれます。  |  ロードバランサーの評価は、カスタム設定を考慮して、検出フェーズの早い段階で開始する必要があります。ほとんどの環境では、ロードバランサーの設定はかなり標準ですが、ELB またはパートナーアプライアンスベースのソリューションに移行できるかどうかを決定する複雑なロジックがある場合があります。  | 
|  ソース IP アドレスを保持する必要があるサーバーはありますか？  |  サーバーをクラウドに移行する最も安全で簡単な方法は、移行したインスタンスに新しい IP アドレスを割り当てることです。場合によっては、ソースサーバーと同じ IP アドレスを保持する必要があります。例えば、レガシーアプリケーションには、変更方法がわからないハードコードされた IP アドレスがある場合があります。  |  ソース IP アドレスを保持すると、ウェーブ計画時に移動グループを形成する方法に影響します。最も一般的なアプローチは、サブネット全体を 1 つの移動グループ AWS で に移行することです。これにより、ネットワークレベルでルーティングと切り替えが簡単になるためです。 IP アドレスを保持するための主要なアクションは次のとおりです。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/large-migration-foundation-playbook/landing-zone.html)  | 
|  ソースと の間で許容されるレイテンシーはどのくらい AWSですか？  |  VPN リンクを使用してすばやくセットアップし、 を使用して確立された直接接続に移行できるため、VPN リンクを使用して移行を開始するのが一般的です AWS Direct Connect。VPN リンクのレイテンシーは通常、より大きく、より可変的であり、データスループット、さらに重要なのはアプリケーションの応答時間に影響します。  |  高レイテンシーまたは可変レイテンシー接続タイプを使用している場合は、各アプリケーションの要件を確認し、それに応じて移行ウェーブを計画します。代替の接続タイプが利用可能な場合、低レイテンシーの接続を必要とするアプリケーションを後続のウェーブに配置することを計画します。  | 

## オペレーションに関する考慮事項
<a name="operations"></a>


| 検討したことはありますか？ | 説明 | アクション | 
| --- | --- | --- | 
|  ランディングゾーンの AWS アカウント戦略を特定しましたか？  |  AWS 優れた設計環境の ベストプラクティスでは、リソースとワークロードを複数の AWS アカウントに分割することをお勧めします。 AWS アカウントは分離されたリソースコンテナと考えることができます。アカウントはワークロードを分類し、災害発生時の影響範囲を縮小できます。  |  アプリケーションの優先順位付けのためのランブックで、選択した移行戦略を確認し、それらを使用してアカウント戦略を決定します。例えば、できるだけ早く移行し、リホストが最も一般的な移行戦略である場合、管理しやすいアカウントが少なくなります。ただし、移行戦略でアプリケーションをモダナイズする必要があり、コンプライアンス上の理由からビジネスユニットを分離する必要がある場合は、アカウント戦略にビジネスユニットごとに 1 つ以上のアカウントを含める必要があります。  | 
|  移行中にモニタリングツールを切り替える必要がありますか？ その場合、これは移行プロセスの一部ですか、それとも移行の前後に発生しますか？  |  モニタリングツールはクラウド運用に不可欠です。互換性またはライセンス上の理由から、既存のツールがクラウドで機能しない場合があります。設計の一環として、 のワークロードに使用するモニタリングツールを決定する必要があります AWS クラウド。  |  移行を開始する前に、モニタリングツールを選択します。移行チームに、移行パターンでモニタリングを設定する手順が組み込まれていることを確認します。必要に応じて、モニタリングツールを置き換えるか再利用する自動化スクリプトを作成することをお勧めします。  | 
|  アプリケーション所有者を特定済みで、クラウドで正常に機能するようにアプリケーションに加える必要がある変更を認識していますか？  |  大規模な移行は、単なるインフラストラクチャプロジェクトではなく、変革です。移行をサポートするために、アプリケーション所有者を早期に含めます。例えば、アプリケーション所有者はウェーブプランを検証し、テストプランを作成し、カットオーバーに参加します。  |  プロジェクト管理オフィスと Cloud Enablement Engine チームと協力して、アプリケーションチームのリーダーと連携し、すべてのアプリケーションチーム間のコミュニケーションが明確であることを確認します。コミュニケーションとプロジェクトの透明性の詳細については、[AWS 「大規模な移行のためのプロジェクトガバナンスプレイブック](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-governance-playbook/)」を参照してください。  | 
|  バックアップおよびリカバリソリューションを選択済みで、移行されたワークロードでも機能しますか？  |  バックアップおよび復旧ツールはクラウド運用に不可欠です。互換性またはライセンス上の理由から、既存のツールがクラウドで機能しない場合があります。設計の一環として、 のワークロードに使用するバックアップおよびリカバリツールを決定する必要があります AWS クラウド。  |  移行を開始する前に、バックアップおよびリカバリツールを選択します。移行チームが、移行パターンにバックアップとリカバリを設定する手順を必ず組み込んでください。必要に応じて、バックアップおよびリカバリツールを置き換えるか再利用する自動化スクリプトを作成することをお勧めします。  | 
|  すべての共有サービスを特定し、ランディングゾーンにデプロイしましたか？  |  *共有サービスは*、E メール、Active Directory、共有データベース環境など、複数のアプリケーションをサポートするサービスです。通常、移行前にクラウドに共有サービスをデプロイして、移行したアプリケーションが期待どおりに動作するようにする必要があります。  |  ランディングゾーンの設計を完了する前に、インフラストラクチャチームおよびアプリケーションチームのリーダーと詳細に検討してください。移行を開始する前に、クラウドにデプロイする必要がある共有サービスのリストを確認して確認します。最も一般的な共有サービスは、Active Directory、ネットワークデバイス、ドメインネームシステム (DNS)、インフラストラクチャソフトウェアです。  | 
|  ターゲット AWS リージョンとアカウントの AWS サービスクォータを確認しましたか？  |  すべての AWS サービスにはサービスクォータがあります。これらのクォータの一部は増やすことができます。カットオーバーの前にクォータを確認することが重要です。十分なリソースがない場合、カットオーバーが失敗する可能性があります。  |  移行計画を確認します。サービスクォータの引き上げを必要とするターゲットアカウントについては、引き上げをリクエストします。詳細と手順については、[AWS 「 Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)」を参照してください。  | 
|   AWS サポートプランをアップグレードする必要がありますか？  |  AWS エンタープライズサポートプランは、24 時間 365 日の電話サポートを提供し、他のプランよりも応答時間を短縮します。通常、カットオーバーウィンドウは非常に短いため、カットオーバーの問題を解決するために経験豊富なエンジニアにアクセスできることは、大規模な移行を成功させるために不可欠です。  |   AWS アカウントチームに連絡して、さまざまなサポートオプションについて話し合い、大規模な移行プロジェクトに適したサポートプランを選択してください。  | 
|  大規模な移行計画について AWS テクニカルアカウントマネージャー (TAM) に通知しましたか？  |   AWS Enterprise On-Ramp サポートチームは、プロアクティブプログラム、予防プログラム、 AWS 対象分野のエキスパートへのアクセスを調整するテクニカルアカウントマネージャー (TAMs) のプールを割り当てます。TAMsは、必要に応じてサポートリソースの可用性をスケジュールできます。  |  今後の大規模な移行プロジェクトを AWS テクニカルアカウントマネージャーに通知し、移行計画を共有します。TAMs は、必要に応じて AWS サポートリソースが利用可能であることを確認します。例えば、TAMs はカットオーバー中にサポートエンジニアをスケジュールでき、エンジニアは技術的な問題を軽減し、カットオーバーを合理化できます。  | 

## セキュリティに関する考慮事項
<a name="security"></a>


| 検討したことはありますか？ | 説明 | アクション | 
| --- | --- | --- | 
|  アクセス管理用の AWS Identity and Access Management (IAM) ロールとポリシーを特定しましたか？  |  大規模な移行プロジェクトのすべてのメンバーの ID とアクセスを管理します。移行されたリソースに IAM ロールをアタッチし、アクセスポリシーを定義することで、クラウド内の移行されたリソースにアクセスできるユーザーを制御します。  |  移行チームと協力して、役割と責任を特定します。どのロールがどの AWS アカウントにアクセスできるかを判断し、各ロールが持つアクセスレベルを特定します。セキュリティチームと協力して、各ターゲット AWS リソースの IAM ロールが正しいことを確認します。  | 
|  ワークロードにコンプライアンス要件はありますか？  |  ワークロードには、医療保険の相互運用性と説明責任に関する法律 (HIPAA) や決済カード業界のデータセキュリティ標準 (PCI DSS) など、さまざまなコンプライアンス要件がある場合があります。これらの要件は、移行前に特定し、満たす方法を計画する必要があります。  |  コンプライアンスチームとポートフォリオチームと協力して、各アプリケーションのコンプライアンス要件を特定し、それに応じてターゲット AWS アカウントを設計します。例えば、一部のワークロードを AWS GovCloud (US) 特定の AWS リージョンに移行する必要がある場合があります。アプリケーションの優先順位付けとウェーブプランニングプロセスの後半でこの情報を使用できるように、各アプリケーションのコンプライアンス要件を文書化することをお勧めします。  | 
|  セキュリティチームは、移行中に使用する予定のツールやサービスを確認して承認する必要がありますか？  |  への大規模な移行プロジェクトでは、 AWS Database Migration Service （AWS DMS） AWS Application Migration Service、ポートフォリオ検出ツール (Flexera One など) など AWS DataSync、多くの サービス AWS クラウド を使用します。一部の組織では、すべての新しいツールとサービスを使用する前に承認する必要があります。  |  移行チームと協力して、移行に使用する予定のすべてのツール、サービス、アプリケーションを特定します。セキュリティチームと協力して会社のポリシーを確認し、移行を開始する前にこれらのツールを承認します。  | 

# 大規模な移行に関するオンプレミスの考慮事項
<a name="on-premises"></a>

ビジネスオペレーションをサポートするオンプレミスインフラストラクチャも、大規模な移行に備える必要があります。現在のインフラストラクチャを準備することで、ビジネスオペレーションやアプリケーションユーザーへの大規模な移行の影響を軽減できます。

このセクションでは、大規模な移行に備えてオンプレミスインフラストラクチャを準備する際に考慮すべきインフラストラクチャ、運用、セキュリティに関する質問について説明します。このセクションの質問に回答すると、これらの決定は*移行原則*になり、[「大規模な移行原則として決定を文書化する」の指示に従って文書化します](document.md)。

## インフラストラクチャの考慮事項
<a name="on-premises-infra"></a>


| 検討したことはありますか？ | 説明 | アクション | 
| --- | --- | --- | 
|  ターゲット AWS アカウントとの間のトラフィックをサポートするようにオンプレミス DNS とルーターを設計しましたか？  |  多数のサーバーとターゲット AWS アカウントがあるため、移行戦略とスケーリングをサポートするようにさまざまなネットワークコンポーネントが正しく設定されていることを確認することが重要です。  |  ルーティングテーブルの設計を確認し、 AWS アカウントとオンプレミスデータセンターの間に正しいルートがあることを確認します。また、DNS サーバーがオンプレミスサーバーと AWS リソースの両方からの DNS クエリをサポートできることを確認します。  | 
|  移行チームはオンプレミスと AWS 環境の両方にどのようにアクセスしますか？  |  移行チームは、ソースサーバーとターゲットサーバーにアクセスして、ソースサーバーにレプリケーションエージェントをインストールしたり、ターゲットサーバーに古いソフトウェアをアンインストールしたりするなどの移行アクティビティを実行する必要があります。  |  既存の認証と認可のメカニズムを確認し、アクセス権を付与する戦略を構築します。Active Directory グループ、IAM ロール、Security Assertion Markup Language 2.0 (SAML 2.0) フェデレーションを使用して、 AWS アカウントへのシングルサインオンを許可できます。Active Directory で認証の問題が発生した場合に備えて、ローカル管理者ユーザーを作成することをお勧めします。  | 
|  現在のネットワーク設定に、移行中のデータスループットを低下させる既知の輻輳ポイントはありますか？  |  大規模な移行では、オンプレミスのデータセンターからクラウドにデータをレプリケートするために大量の帯域幅が必要です。既存の輻輳のポイントや制限を理解することは、移行をより適切に計画するのに役立ちます。  |  ネットワークチームとネットワーク設定を確認して、ソースマシンからターゲット AWS アカウントへのネットワークパスをよりよく理解してください。移行ワークロードと本稼働ワークロード間で共有される接続など、潜在的な輻輳ポイントを特定します。  | 

## オペレーションに関する考慮事項
<a name="on-premises-ops"></a>


| 検討したことはありますか？ | 説明 | アクション | 
| --- | --- | --- | 
|  移行に影響を与える可能性のある、*変更のフリーズ*とも呼ばれるブロック日がスケジュールされていますか？  |  移行中に変更がフリーズすると、重要なリソースが不足し、進行中の移行プロジェクトが中断される可能性があります。  |  オペレーションチームとともに変更管理プロセスを確認し、カットオーバー期間を計画する際は、ブロックされた日数を考慮してください。  | 
|  移行の変更日を予約しましたか？  |  変更管理プロセスは複雑になる場合があり、一部の組織では特定のメンテナンスウィンドウでのみ変更を許可しています。  |  変更管理プロセスに従って、少なくとも 5 つのウェーブを事前にスケジュールします。これにより、遅延を防ぐことができます。  | 
|  移行の対象となるすべてのサーバーが最近再起動されましたか？  |  システムの変更やパッチのアンインストールにより、移行中に問題が発生し、長いカットオーバーウィンドウやサーバーのロールバックが必要になる場合があります。ベストプラクティスは、移行前にサーバーがターゲット側で最近再起動されたことを確認することです。  |  サーバーの最終再起動日を確認します。過去 90 日以内にサーバーを再起動していない場合は、サーバーを移行する前に再起動をスケジュールします。  | 
|  ディザスタリカバリとビジネス継続性計画は、現在どのように機能しますか? また、これはランディングゾーンの設計に取り入れられていますか？  |  ディザスタリカバリとビジネス継続性計画は、アプリケーションの目標復旧時間 (RTO) と目標復旧時点 (RPO) を満たすための重要な要素です。移行期間中は、これらのプランがオンプレミスと AWS ワークロードの両方で機能することを確認する必要があります。  |  既存のディザスタリカバリおよび事業継続計画を確認し、その計画がターゲット AWS アカウントに対して機能することを確認します。そうでない場合は、ワークロードを に移行する前に新しい計画を設計します AWS クラウド。  | 

## セキュリティに関する考慮事項
<a name="on-premises-security"></a>


| 検討したことはありますか？ | 説明 | アクション | 
| --- | --- | --- | 
|  大規模な移行をサポートするためにファイアウォールルールを作成しましたか？  |  組織内のプロセスによっては、ファイアウォール設定の変更リクエストが完了するまでに時間がかかる場合があります。  |  セキュリティチームと既存のファイアウォール変更プロセスを確認し、それに応じて大規模な移行ファイアウォール変更の戦略を設計します。大規模な移行プロジェクトのカスタムプロセスを設計する必要があるかもしれませんし、プロジェクトの早い段階で変更を送信する必要があるかもしれません。データセンターの拡張として AWS Virtual Private Cloud (VPC) を使用することを検討し、複雑すぎるファイアウォールルールを構築しないことが推奨されます。これにより、大規模な移行が大幅に遅れる可能性があります。  | 
|  環境で Active Directory AWS をセットアップしましたか？  |  Active Directory は認証と認可に使用されます。ターゲットアカウントのワークロードが認証と認可のためにドメインコントローラーに接続できることを確認する必要があります。ターゲット VPC に新しいドメインコントローラーを追加するか、 AWS ワークロードがオンプレミスのドメインコントローラーに接続することを許可できます。  |  セキュリティチームとインフラストラクチャチームで Active Directory の設計を確認します。ターゲット AWS アカウントが正しいドメインコントローラーに接続されていることを確認します。のワークロードが最寄りのドメインコントローラー AWS に接続できるように、ターゲット AWS サブネット CIDR ブロックが正しい Active Directory サイトにあることを確認します。  | 
|  サードパーティーの接続とアプリケーションの相互依存関係を特定しましたか？  |  サードパーティーの接続とアプリケーションの相互依存関係では、ファイアウォールルール、ネットワークアクセスコントロールリスト、セキュリティグループを変更する必要があります。  |  アプリケーション所有者とのディープダイブセッション中に、各アプリケーションの外部依存関係を確認します。サードパーティーの依存関係要件に基づいて、ファイアウォールルールとネットワークアクセスコントロールリストを変更し、それに応じてセキュリティグループを変更するリクエストを送信します。  | 
|  オンプレミス環境には、CyberArk など、システムで実行されているアクセスとプロセスを制御する追加のセキュリティツールがありますか？  |  移行ツールをランディングゾーンで AWS 機能させるには、これらのセキュリティツールの評価と更新が必要になる場合があります。  |  ソース環境でアクセスポリシーを確認します。アクセスポリシーでセキュリティツールを使用している場合は、ツールが で機能していることを確認し AWS クラウド、移行チームがソース環境とターゲット環境の両方にアクセスできることを確認します。変更が必要な場合は、移行ランブックにこれらのステップを追加します。  | 

# 移行原則を文書化する
<a name="document"></a>

ランディングゾーンとオンプレミスに関する考慮事項を確認したら、回答と決定事項を文書化する必要があります。これらは、残りのプロジェクトをガイドする移行原則になります。

以下の操作を実行します。

1. [基盤プレイブックテンプレート](samples/foundation-playbook-templates.zip)で、*移行原則テンプレート* (Microsoft Word 形式) を開きます。

1. このガイドの[「大規模な移行に関するランディングゾーンの考慮事項](landing-zone.md)」と[「大規模な移行に関するオンプレミスの考慮事項](on-premises.md)」のインフラストラクチャ、運用、セキュリティに関する考慮事項を確認し、推奨されるチームと質問について話し合います。

1. インフラストラクチャ、運用、セキュリティに関する決定事項を移行原則ドキュメントに文書化します。これらの決定を記録する方法の例については、次の表を参照してください。

1. ユースケースに応じて、新しいカテゴリ、項目、原則を追加します。例えば、ポートフォリオ評価やプロジェクト管理の決定に関する移行原則を記録できます。

以下は、このガイドの質問の一部に決定を記録する方法の例です。

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/large-migration-foundation-playbook/document.html)