大規模な移行におけるランディングゾーンの考慮事項

あるランディングゾーンよく設計されているAWSスケーラブルで安全な環境。アカウント数の定義、サブネットとセキュリティグループの設計など、ランディングゾーンの標準を確立することで、強固な基盤を構築できます。この基盤により、クラウドの導入を加速させながら、ビジネスの俊敏性とガバナンスの両方を実現する環境を大規模に実現、プロビジョニング、運用できるようになります。ランディングゾーンとその構築戦略の詳細については、以下を参照してください。安全でスケーラブルなマルチアカウントのセットアップAWS環境。

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

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

大規模な移行プログラムプロジェクトに影響を与える可能性のあるランディングゾーンの主な要因には、次のようなものがあります。

• ネットワーク帯域幅の可用性と管理

• ワークロードの分離とリソース管理のためのアカウント戦略

• 移行されたワークロードのセキュリティと管理制御

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

インフラストラクチャに関する考慮事項

考えたことはありますか？	説明	アクション
1 日あたり、1 週間あたりどのくらいの量のデータを移行しますか?	必要な移行速度によって、ネットワーク接続の種類とネットワークスループットの要件が決まります。また、ウェーブプランニングの選択基準にも影響を与える可能性があります。	ポートフォリオ評価が完了したら、クラウドに移行されたすべてのリソースに必要なストレージの合計量を決定します。この値を使用して、現在のネットワーク帯域幅を使用してデータを移行するのに必要な時間を計算します。移行期間に合わせて帯域幅を増やす必要がある場合もあれば、次のような代替手段を使用する必要がある場合もあります。AWS Snow Family解決策。にファンデーションプレイブックテンプレート、使用できますデータ複製計算ツール（Microsoft Excel 形式）をクリックして、各マイグレーションウェーブに必要な帯域幅を計算します。
各ウェーブのソースサーバーの平均書き込み速度はどのくらいですか?	複製されたデータを転送するのに必要な帯域幅は、参加しているソースサーバーの書き込み速度に基づいています。サーバーのレプリケーションに必要な帯域幅は、ソースサーバーの平均書き込み速度に、最大ウェーブのサーバー数を掛けたものです。	ポートフォリオ評価時には、各サーバで実行されるデータ書き込みの平均数を決定する必要があります。にファンデーションプレイブックテンプレート、使用できますデータ複製計算ツール移行トラフィックに必要な帯域幅を理解するには（Microsoft Excel 形式）。移行トラフィックに必要な帯域幅は、通常のビジネスアクティビティに使用される帯域幅に追加されます。移行が完了すると、移行作業をサポートするための追加の帯域幅は不要になります。
追加のネットワークアクティビティや既存のインフラストラクチャによってレプリケーション速度が制限されたり、低下したりする可能性はありますか?	ネットワーク帯域幅が他のビジネス機能もサポートしている場合、これらのアクティビティによって移行中に複製サーバーに使用できる帯域幅の量が減少する可能性があります。	プロジェクトライフサイクルの早い段階で、すべての事業活動をサポートするために必要なネットワーク帯域幅を慎重に評価して計算します。通常のビジネスアクティビティ、サーバーの複製、およびオンプレミスのファイル共有とオンプレミスのデータ同期などの新しい移行関連アクティビティに必要な帯域幅を考慮してください。AWS。 プロバイダーがネットワーク容量を増やすのにリードタイムが長い場合があり、既存のオンプレミスインフラストラクチャをアップグレードする必要がある場合があります。ネットワークインフラストラクチャをアップグレードした結果、追加のアップグレードが必要かどうかを検討してください。プロジェクトの早い段階で帯域幅要件を評価することで、必要な変更を加える時間を確保できます。
あなたは現在ですかAWSサブネット戦略は、オンプレミスのワークロードを移行するためのIPアドレス要件を満たしていますか？	サーバーの数とワークロード分離の要件によって、ランディングゾーンのサブネット戦略が決まります。 大規模な移行では、予想よりも大きなサブネットが必要になる場合があります。大規模な移行では、オンプレミスインフラストラクチャの設定と同様に、ワークロードをサブネットにグループ化します。移行を簡素化するために、最初は大規模でフラットなサブネット設計が推奨され、その後、モダナイゼーション中に必要に応じてサブネットを再設計します。	ポートフォリオ評価でインフラストラクチャインベントリに関する十分な情報が得られたら、オンプレミスのネットワーク構造を評価し、できるだけ早くランディングゾーンの設計に組み込んでください。
何台のサーバを並行して複製および移行する予定ですか?	最大の移行波の規模はサブネット要件に影響し、AWSサービスクォータ。	大まかな移行計画を見直し、それに基づいてサブネットを設計してください。たとえば、200 台のサーバーを 1 つのサブネットに移行する予定の場合、そのサブネットのクラスレスドメイン間ルーティング (CIDR) 範囲には、目標数のサーバーをサポートするのに十分な IP アドレスが必要です。また、増やしてくださいAWS必要に応じて、各ターゲットアカウントのサービスクォータを設定します。
移行リソースのセキュリティグループ戦略は特定できましたか?	セキュリティグループは、以下のインバウンドトラフィックとアウトバウンドトラフィックの管理に使用されます。AWS資源。移行を遅らせないためには、セキュリティグループを早期に設計することが重要です。	アプリケーションの優先順位付けのためのランブックで、移行戦略を確認してから、移行戦略に基づいてセキュリティグループを設計します。たとえば、移行戦略がほとんどのワークロードを再ホストすることである場合は、ネットワークをリファクタリングしてアプリケーション固有のセキュリティグループを適用するのではなく、移行カットオーバーをサポートする一時的な汎用セキュリティグループを検討してください。
ロードバランサーは使用されていますか?	通常、ロードバランサーのある環境でサーバーを移行する場合、ロードバランサーの設定を評価してからロードバランサーを移行する必要があります。ロードバランサーの移行オプションには、Elastic Load Balancing（ELB）またはパートナーのアプライアンスベースのソリューションの使用が含まれます。	ロードバランサーの評価は、カスタム構成を考慮に入れるために、発見フェーズの早い段階で開始する必要があります。ほとんどの環境では、ロードバランサーの構成はかなり標準的ですが、ELB に移行できるか、パートナーのアプライアンスベースのソリューションに移行できるかを決定する複雑なロジックを持つ環境もあります。
送信元 IP アドレスを保持する必要のあるサーバーはありますか?	サーバーをクラウドに移行する最も安全で簡単な方法は、移行したインスタンスに新しい IP アドレスを割り当てることです。状況によっては、送信元サーバーと同じ IP アドレスを維持する必要がある場合があります。たとえば、レガシーアプリケーションには、変更方法がわからないハードコーディングされた IP アドレスがある場合があります。	送信元 IP アドレスを保持しておくと、ウェーブプランニング時のムーブグループの形成方法に影響します。最も一般的な方法は、サブネット全体を次のように移行することです。AWSネットワークレベルでのルーティングと切り替えが簡単になるため、1つのムーブグループに属します。 IP アドレスを保持するための主なアクションは次のとおりです。 サーバー間のサブネット間通信を慎重に評価してください。 移行したサーバーの IP アドレスのルーティングをどのように切り替えるかを決めてください。一般的なオプションには、サブネット全体を切り替えたり、サブネット上の静的 IP ルーティングを管理するネットワークテクノロジーを導入したりすることが含まれますserver-by-server基礎。
ソースとソース間の許容可能なレイテンシーAWS?	移行は VPN リンクから開始するのが一般的です。VPN リンクはすぐにセットアップでき、その後で確立された直接接続に移行できるためです。AWS Direct Connect。通常、VPN リンクの遅延はより大きく、変動しやすいため、データスループットに影響し、さらに重要なのはアプリケーションの応答時間に影響します。	高遅延接続タイプまたは可変遅延接続タイプを使用している場合は、各アプリケーションの要件を確認し、それに応じて移行計画を立ててください。低レイテンシー接続を必要とするアプリケーションは、代替の接続タイプが利用可能になったときに、後で導入することを計画してください。

運用上の考慮事項

考えたことはありますか？	説明	アクション
特定しましたかAWSランディングゾーンのアカウント戦略?	アーキテクチャが適切に設計された環境の AWS ベストプラクティスでは、リソースとワークロードを複数の AWS アカウントに分けることをお勧めします。思いつくでしょうAWS独立したリソースコンテナとしてのアカウント:ワークロードを分類でき、災害発生時の影響範囲を縮小できます。	アプリケーションの優先順位付けのためのランブックで、選択した移行戦略を確認し、それに基づいてアカウント戦略を決定してください。たとえば、できるだけ早く移行したいが、リホストが最も一般的な移行戦略である場合は、アカウント数が少ないほど管理しやすくなります。ただし、移行戦略でアプリケーションの最新化が必要で、コンプライアンス上の理由でビジネスユニットを分ける必要がある場合は、アカウント戦略にビジネスユニットごとに 1 つ以上のアカウントを含める必要があります。
移行中に監視ツールを切り替える必要がありますか? もしそうなら、これは移行プロセスの一部ですか、それとも移行の前か後ですか？	監視ツールはクラウドの運用に不可欠です。互換性やライセンス上の理由により、既存のツールがクラウドで機能しない場合があります。設計の一環として、次のワークロードにどの監視ツールを使用するかを決定する必要がありますAWS クラウド。	移行を開始する前に監視ツールを選択してください。移行チームが移行パターンに監視を設定するための指示を組み込んでいることを確認してください。必要に応じて、監視ツールを置き換えたり再利用したりする自動化スクリプトを作成することをお勧めします。
アプリケーションの所有者を特定し、クラウドで正しく機能させるためにアプリケーションに変更を加える必要があることを認識していますか？	大規模な移行は、単なるインフラプロジェクトではなく、変革です。移行をサポートしてもらうために、早い段階でアプリケーションオーナーを参加させてください。たとえば、アプリケーションの所有者はウェーブプランを検証し、テストプランを作成し、カットオーバーに参加します。	プロジェクト管理オフィスや Cloud Enablement Engine チームと協力してアプリケーションチームのリーダーと連携し、すべてのアプリケーションチーム間で明確なコミュニケーションが取れるようにします。コミュニケーションとプロジェクトの透明性について詳しくは、のプロジェクトガバナンスプレイブックAWS大規模な移行。
バックアップとリカバリのソリューションを選択しましたか？移行後のワークロードでも機能しますか？	バックアップとリカバリのツールはクラウドの運用に不可欠です。互換性やライセンス上の理由により、既存のツールがクラウドで機能しない場合があります。設計の一環として、次のワークロードにどのバックアップツールとリカバリツールを使用するかを決定する必要がありますAWS クラウド。	移行を開始する前に、バックアップとリカバリのツールを選択してください。移行チームが移行パターンにバックアップとリカバリの設定手順を組み込んでいることを確認してください。必要に応じて、バックアップツールとリカバリツールを置き換えたり再利用したりする自動化スクリプトを作成することをお勧めします。
すべての共有サービスを特定し、ランディングゾーンに導入しましたか?	共有サービス電子メール、Active Directory、共有データベース環境など、複数のアプリケーションをサポートするサービスです。通常、移行したアプリケーションが期待どおりに動作するように、移行前に共有サービスをクラウドにデプロイする必要があります。	ランディングゾーンの設計を完了する前に、インフラチームとアプリケーションチームのリーダーと深く掘り下げてみましょう。移行を開始する前に、クラウドにデプロイする必要がある共有サービスのリストを確認して確認してください。最も一般的な共有サービスは、Active Directory、ネットワークデバイス、ドメインネームシステム (DNS)、およびインフラストラクチャソフトウェアです。
レビューしましたかAWSターゲットのサービスクォータAWS地域とアカウント?	ごとAWSサービスにはサービスクォータがあります。これらのクォータの一部は増やすことができます。カットオーバーの前にクォータを確認することが重要です。使用可能なリソースが不十分な場合、カットオーバーが失敗する可能性があります。	移行計画を確認してください。サービスクォータの引き上げを必要とするターゲットアカウントについては、増加をリクエストしてください。詳細と手順については、以下を参照してください。AWSサービスクォータ。
アップグレードする必要がありますかAWSサポートプラン?	AWSエンタープライズサポートプランでは、年中無休の電話サポートが提供され、他のプランよりも応答時間が短くなります。カットオーバー期間は通常非常に短いため、大規模な移行を成功させるには、カットオーバーの問題を解決する経験豊富なエンジニアに相談できることが不可欠です。	あなたに連絡してくださいAWSアカウントチームがさまざまなサポートオプションについて話し合い、大規模な移行プロジェクトに適したサポートプランを選択します。
通知しましたかAWSテクニカルアカウントマネージャー (TAM) による大規模な移行計画について教えてください。	ザ・AWSEnterprise On-Rampサポートチームが、プロアクティブなプログラム、予防プログラム、およびサポートへのアクセスを調整するテクニカルアカウントマネージャ（TAM）のプールを割り当てます。AWS対象分野の専門家。TAM は、必要に応じてサポートリソースの提供をスケジュールできます。	通知を送信AWS今後予定されている大規模な移行プロジェクトのテクニカルアカウントマネージャーと、移行計画を共有します。TAM が必ず確認しますAWSサポートリソースは必要に応じて利用できます。たとえば、TAM はカットオーバー中にサポートエンジニアをスケジュールし、エンジニアは技術的な問題の軽減とカットオーバーの合理化を支援できます。

セキュリティに関する考慮事項

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