大規模な移行に関するオンプレミスの考慮事項

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

このセクションでは、大規模な移行に備えてオンプレミスインフラストラクチャを準備する際に考慮すべきインフラストラクチャ、運用、およびセキュリティに関する質問について説明します。このセクションの質問に答えると、これらの決定は次のようになります。移行原則、に記載されている指示に従って文書化してください決定事項を大規模移行の原則として文書化する。

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

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

運用上の考慮事項

考えたことはありますか？	説明	アクション
ブロックされる予定日（別名：）はありますか？チェンジフリーズ、それが移行に影響する可能性はありますか？	移行中に変更が凍結されると、進行中の移行プロジェクトから重要なリソースと時間が奪われる可能性があります。	運用チームと一緒に変更管理プロセスを見直し、カットオーバー期間を計画する際には、ブロックされた日数を考慮に入れてください。
移行のための変更日の予約はお済みですか？	変更管理プロセスは複雑で、特定のメンテナンス期間にのみ変更を許可する組織もあります。	変更管理プロセスに応じて、少なくとも 5 回前もって変更のスケジュールを設定してください。これは遅延を防ぐのに役立ちます
移行対象のすべてのサーバーが最近再起動されましたか?	システムの変更やパッチのアンインストールによって移行中に問題が発生し、長いカットオーバーウィンドウやサーバーのロールバックが必要になることがあります。ベストプラクティスは、移行前にターゲット側でサーバーが最近再起動されたことを確認することです。	サーバーを最後に再起動した日付を確認してください。過去 90 日以内にサーバーが再起動されていない場合は、サーバーを移行する前に再起動をスケジュールしてください。
現在の災害復旧計画と事業継続計画はどのような仕組みになっていますか？また、ランディングゾーンの設計にはその要素が織り込まれていますか？	災害復旧計画と事業継続計画は、アプリケーションの復旧時間目標（RTO）と復旧ポイント目標（RPO）を達成するための重要な要素です。これらのプランがオンプレミスとオンプレミスの両方で機能することを確認する必要があります。AWS移行期間中のワークロード。	既存の災害復旧計画と事業継続計画を見直し、計画が目標に合っていることを確認するAWSアカウント。そうでない場合は、ワークロードを移行する前に新しい計画を設計してくださいAWS クラウド。

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

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