AWS Migration Hub のよくある質問

ドキュメント内の入門ガイドに従って使用を開始します。 

Migration Hub のほとんどの機能 (Refactor Spaces を除く) を使用する前に、[Migration Hub Settings] (Migration Hub 設定) ページから、または Migration Hub Config API を使用して、Migration Hub ホームリージョンを選択する必要があります。 

Migration Hub ホームリージョンに保存されたデータは、ポートフォリオ全体の検出および移行計画情報の単一リポジトリと、複数の AWS リージョンへの移行の単一ビューを提供します。移行ツールがサポートしている任意のリージョンに移行でき、選択した Migration Hub ホームリージョンに移行ステータスが表示されます。Migration Hub ホームリージョンの詳細については、ドキュメントをご参照ください。

一度設定すると、Migration Hub ホームリージョンは変更できません。

AWS Migration Hub は、リージョンで移行ツールが利用できる限り、すべての AWS リージョンで移行ステータスを追跡できます。Migration Hub と統合するための移行ツール (AWS Application Migration Service、AWS Database Migration Service など) は、選択した Migration Hub ホームリージョンに移行ステータスを送信します。ホームリージョンは、検出および移行追跡データの保存に使用し、サービスを初めて使用する前に設定します。移行ステータスはすべての移行先リージョンから集められ、ホームリージョンに表示されます。統合ツールは、Migration Hub コンソールの [Tools] (ツール) ページでユーザーが許可 (接続) しない限り、ステータスを送信しません。

AWS Migration Hub は、アプリケーションが現在どこにあるのかに関係なく、世界中のどこからでもアプリケーションの移行状況を追跡するために利用できます。インベントリの収集、計画とレコメンデーション、およびモダナイゼーション機能における Migration Hub ツールの可用性については、AWS リージョン表をご覧ください。

AWS Migration Hub には、初めて管理者ユーザーとしてコンソールにアクセスしたときに自動的に追加される AWS アカウントのロールが必要です。統合移行ツールは、Migration Hub コンソールの [Tools] ページで許可できます。詳細については、AWS Migration Hub ユーザーガイドの Authentication and Access Control セクションを参照してください。

AWS Migration Hub で IT アセットを表示するには、最初に AWS 検出ツールを使用して検出を実行するか、統合移行ツールを使用して移行するときに検出を実行します。次に、Migration Hub 内から環境を探索できます。Migration Hub コンソールの [Servers] (サーバー) ページに表示されるサーバー ID をクリックすると、検出されたリソースに関する詳細を確認できます。次に、サーバーの詳細ページが表示されます。AWS 検出ツールを使用してサーバーを検出した場合、技術仕様、平均使用率などの収集されたデータが表示されます。

最初に AWS Migration Hub にアクセスしたときに、検出を実行するか、移行を開始するように指示されます。検出を実行せずに移行を開始することを決定した場合、Migration Hub コンソールで許可した統合移行ツールを使用してアプリケーションサーバーとデータベースサーバーを移行すると、そのサーバーが Migration Hub にリソースとして表示されます。

検出を実行する場合、2 つのデータ収集オプションがあります。VMware 環境を使用していて、エージェントをインストールしたくない場合は、AWS Application Discovery Service エージェントレスコレクターを使用できます。より詳細な情報が必要な場合は、リソース使用率、サーバーで実行されているプロセス、およびサーバーのネットワーク依存関係に関する詳細を含む、さまざまな情報を収集するエージェントをサーバーにインストールできます。プロセスとネットワーク依存関係の情報は、AWS Migration Hub 以外の場所にエクスポートして分析するために使用できます。AWS Discovery Collectors の詳細については、Application Discovery Service ユーザーガイドを参照してください。

サーバーをアプリケーションにグループ化する前に、AWS Migration Hub のサーバーリストに入力する必要があります。AWS 検出ツールを実行するか、統合移行ツールを使用すると、サーバーがサーバーリストに追加されます。サーバーリストに入力されたら、Migration Hub コンソールの [サーバー] ページで 1 つ以上のリソースを選択し、[Group as Application] (アプリケーションとしてグループ化) をクリックします。 AWS Discovery エージェントを使用してサーバーを検出している場合は、ネットワーク可視化ツールを使用して、サーバーをアプリケーションごとにグループ化することも可能です。ネットワークグラフから 1 つ以上のサーバーを選択した上で、[Group as Application] (アプリケーションとしてグループ化) をクリックします。

AWS Migration Hub コンソールの [Migrate] セクションで [Applications] ページにアクセスして、アプリケーションのリストとその現在の移行ステータスを確認できます。[Discover] セクションの [Servers] ページまたは AWS SDK/CLI を使用してアプリケーションにグループ化されたリソースのみが [Applications] ページに表示されます。アプリケーションには、「未開始」、「進行中」、「完了」の 3 つの移行ステータスのいずれかが割り当てられます。

はい。アカウント内のいずれかの IAM ユーザーによって作成されたアプリケーションは、AWS Migration Hub へのアクセスが許可されている同じアカウント内の他のすべての IAM ユーザーに表示されます。行われた変更は、アクセス許可のあるすべてのユーザーに表示されます。

ユーザーは、AWS アカウントに関連付けられた IAM ユーザーを使用して、AWS Migration Hub にアクセスします。このため、自分の AWS アカウントからのみ詳細を表示でき、他のアカウントは確認できません。

AWS Migration Hub のインポート機能には、Migration Hub コンソール から、または Application Discovery Service APIを呼び出すことでアクセスできます。インポートされたデータは Application Discovery Service データリポジトリに暗号化形式で保存されます。

Migration Hub インポートによって、サーバーの仕様、使用、タグ、サーバーに連結されているアプリケーションなどを含むサーバー詳細をインポートできます。データが Migration Hub CSV インポートテンプレートを使って入力される限り、どんなソースからもデータのインポートが可能です。

はい。[Discover] (検出) > [Tools] (ツール) > [Imports] (インポート) のセクションに行き、「インポートしたデータを削除」のオプションを選択することで、間違ったファイルを削除できます。インポートしたファイルを上書きするには、ファイルを削除し、正しいコードの新しいファイルをアップロードします。

いいえ、アップロードできるインポートファイルに数の制限はありせん。しかしながら、インポートできるレコードおよびサービスの数に制限があります。詳細はこのドキュメントの Migration Hub インポートの制限セクションを参照してください。

いいえ、データのインポートは課金されません。

はい。インポートテンプレートの全てのフィールドにデータを入力しなくてもデータのインポートは可能です。独自のマッチングキー (「ExternalId」) を入力する場合、レコードを一意的に識別し、インポートするために各行にそのキーを使用します。マッチングキーを特定しない場合、「IPAddress」、「HostName」、「MACAddress」のために特定した値または「VMware.MoRefId」と「VMware.vCenterId」の組み合わせを使用して、各行にサーバーの一意性を決定します。マッチングキー (「ExternalId」) または上記のフィールドのいずれかの値を含まない行はインポートされません。

インポート機能は CSV インポートテンプレートに含まれるすべてのインポートされたフィールドにおいて、データ検証チェックを行います。たとえば、「IPAddress」の値が無効であれば、インポート機能はそのレコードを間違いとしてフラグ付けします。加えて、「ExternalId」、「MACAddress」、「HostName」、「IPAddress」、あるいは「VMware.VCenterId」と「VMware.MoRefId」の組み合わせの、少なくとも 1 つ以上が入力されていないインポートレコードは無効と見なされ、インポートされません。

EC2 インスタンス推奨機能は、サーバーの仕様、CPU、メモリ使用率など、各オンプレミスサーバーから収集されたデータを分析し、オンプレミスワークロードの実行に必要な最も安価な EC2 インスタンスを推奨する、AWS Migration Hub の機能です。AWS 購入オプション、AWS リージョン、EC2 インスタンスタイプを除外したり、CPU/RAM 使用率のメトリクス (平均、ピーク、パーセンタイル) の設定を指定したりすることによって、推奨を微調整することもできます。

いいえ。EC2 インスタンスのレコメンデーションを使用するには、オンプレミスサーバーの詳細が AWS Migration Hub で利用可能であることを確認する必要があります。コンテンツ管理データベース (CMDB) などのソースから既存のサーバーインベントリ情報をインポートするか、AWS Application Discovery Service を使用して環境から直接データを収集できます。

EC2 インスタンスの推奨機能は、AWS 購入オプション、AWS リージョン、EC2 インスタンスタイプの除外や、CPU/RAM 使用率のメトリクス (平均、ピーク、パーセンタイル) など、選択したインスタンスタイプの設定を考慮しながら、指定された CPU および RAM の要件を満たすことができる最も費用効果の高い EC2 インスタンスタイプを推奨します。

はい。EC2 インスタンスのレコメンデーションは、バーストパフォーマンスインスタンスに推奨事項を提供します。この機能は「平均」および「ピーク」の CPU データポイントを使用して、予想される価格をほかのインスタンスファミリーとより正確に比較するために、推定消費 CPU クレジット数と関連コストを計算します。

同じサーバー向けの検出データが複数のソースで入手可能な場合、EC2 インスタンスの推奨機能は、最新の完全なデータを使用してインスタンス推奨事項を提供します。たとえば、Migration Hub インポートを使用して特定のサーバーの CPU/RAM 仕様をアップロードすると、インポートされたデータに基づいてレコメンデーションが生成されます。その後このサーバーに AWS Application Discovery Service (ADS) の Discovery Agent をインストールすると、ADS エージェントはサーバー仕様の詳細も取得します。次回そのサーバーに対する EC2 インスタンスの推奨事項を要求すると、エージェントのデータは最新かつ完全であるため、ADS エージェントが収集した仕様を使用してレコメンデーションが生成されます。

はい。EC2 インスタンスのレコメンデーションでは、現行世代のインスタンスのみが推奨されます。旧世代のインスタンスは推奨されません。

コンピューティングリソースのサイジング適正化は、総所有コスト (TCO) を理解するための 1 つの側面です。予測される EC2 コストを理解したい場合は、Migration Hub の EC2 インスタンスレコメンデーションを使用してください。また、AWS の TSO Logic を使用して、Microsoft ライセンスやストレージコストの最適化などといったより詳細な評価も提供しています。詳細な評価については、AWS 日本担当チームまたは AWS パートナーにお問い合わせください。

AWS 検出ツールを使用して検出された、または統合移行ツールを使用して移行を開始することで検出されたサーバーから 1 つ以上のアプリケーショングループを作成した後で、Migration Hub の外側でサーバーまたはデータベースの移行を開始または続行できます。アプリケーション内の各リソースの移行ステータスを確認するには、Migration Hub に戻ります。 

確認するには、Migration Hub コンソールでそのアプリケーションのページにアクセスします。そこで、アプリケーションを構成するすべてのリソースを含んだ図表と、移行ステータスの詳細が入力されたテーブルを確認します。リソースごとに、全般的なステータスと詳細ステータスが図表とテーブルの両方として表示されます。例えば、AWS Server Migration Service によって移行されているサーバーの場合、そのステータスは、「進行中/レプリケーション開始」、「進行中/レプリケーション完了」、または「完了/AMI 作成済み」として報告される可能性があります。 

移行が完了すると、Migration Hub には、その移行によって作成されたリソースに関する詳細も表示されます。AWS Application Migration Service、AWS Server Migration Service、および ATADATA によって移行されたサーバーの場合、Migration Hub では、(ツールに応じて) 作成された AMI または実行中の EC2 インスタンスへのリンクを提供します。AWS Database Migration Service によって移行されたデータベースの場合、Migration Hub では、Database Migration Service コンソールで検索フィルターとして使用できるターゲットエンドポイント ID を提供します。

いいえ。AWS Migration Hub では、移行ステップを自動化しません。移行するアプリケーションの進行状況を追跡できる一元的な場所を提供します。

AWS Migration Hub で移行の進行状況を表示するには、以下の 2 つの条件を満たす必要があります。移行するリソースは AWS Discovery リポジトリに格納されている必要があります。また、サポートされているツールを使用して移行を実行する必要があります。AWS 検出コレクターを使用して検出を実行せずに移行を開始した場合、サポートされている移行ツールによって報告されたサーバーまたはデータベースが AWS Application Discovery Service リポジトリに自動的に追加されます。これらのサーバーが追加されると、サーバーをアプリケーションとしてグループ化し、移行の進行中に 1 つのグループとしてそのステータスを追跡できます。

サポートされているツールを使用していて、アプリケーションにステータスが表示されない場合は、最初に [Updates] (更新) ページをチェックして、ステータスがツールから受信されていることを確認します。ステータスが [Updates] (更新) ページに表示されない場合は、[Tools] (ツール) ページで、ステータスを Migration Hub に送信できるようにツールを許可していることを確認します。許可されていない場合は、[Authorize] (承認) をクリックして、適切な IAM アクセス許可を追加します。

移行ステータスが [Updates] (更新) ページに表示される場合、リソースがアプリケーションにグループ化されていない可能性があります。[Servers] ページにアクセスし、サーバーをアプリケーションにグループ化します。[Migrate/Applications] (移行/アプリケーション) ページからアプリケーションを表示して、移行ステータスを確認します。

AWS Migration Hub では、サポートされているツールを使用して行われるリソースの移行のステータスを表示します。ただし、リソースはアプリケーションにグループ化されている必要があります。厳密なリホスト移行である必要はありません。例えば、AWS Database Migration Service を使用してデータベースの内容を移動した場合、そのデータベースの移行に対応するサーバーがアプリケーションにグループ化されている場合、Migration Hub に更新情報が表示されます。

AWS Migration Hub と統合されていないツールは、Migration Hub マネジメントコンソールでステータスを報告しません。アプリケーション内の他のリソースのステータスまたはアプリケーションレベルのステータスは表示できます。また、CLI または API を使用して、独自のオートメーションによりステータスを更新できます。

AWS Migration Hub API に記述することで、移行ツールから AWS Migration Hub にステータスを発行できます。オンボーディングに関心をお持ちのパートナーは、AWS コンピテンシープログラムを通じて移行コンピテンシーを取得する必要があります。コンピテンシープログラム、および移行コンピテンシーの申し込みの詳細については、こちらをご覧ください。

AWS Migration Hub Strategy Recommendations では、オンプレミスや AWS で稼働しているアプリケーションの移行、近代化戦略を簡単に構築できるようになりました。Strategy Recommendations は、大規模な移行とモダナイズに役立つ戦略とツールに関するガイダンスを提供します。

Strategy Recommendations は、カスタマイズされた移行や最新化の戦略を大規模に特定し、その戦略の実行を支援するツールやサービスを提供します。また、これらのレコメンデーションを実行するために解決しなければならないソースコードの非互換性 (アンチパターン) の特定ができます。

戦略レコメンデーションは、Windows Server 2003 以上、または Ubuntu、RedHat、Oracle Linux、Debian、Fedora などの様々な Linux ディストリビューションで動作するアプリケーションの潜在的なリホスト (EC2) やリプラットフォーム (RDS や Elastic BeanStalk などのマネージド環境、コンテナ、および OS アップグレード) オプションの分析をサポートします。戦略レコメンデーションでは、C# や Java で書かれたカスタムアプリケーションや、ライセンスされたデータベース (Microsoft SQL Server、Oracle など) のリファクタリング分析を追加で提供しています。

ドキュメント内の入門ガイドに従って使用を開始します。

詳しくは、AWS で Windows ワークロードを最新化する をご覧ください。

アプリケーションの変換は、アプリケーションをリファクタリング、再設計、および書き換えることで、クラウドでの実行による可用性、スケーラビリティ、ビジネスの俊敏性、およびコスト最適化といった利点を最大化するプロセスです。

Refactor Spaces は、AWS でのコンピューティングを最大限に利用するためにアプリケーションのリファクタリングを高速化し、本稼働環境での運用中にリファクタリングプロセスを簡単に管理できるようにすることで、アプリの変換を簡素化します。Refactor Spaces を使用すると、リファクタリングを可能にする基本的なインフラストラクチャの作成と管理ではなく、アプリケーションのリファクタリング自体に注力できます。プリケーションのリファクタリングに焦点を当てることができます。Refactor Spaces は、アプリケーションがマイクロサービスになったり、マイクロサービスに書き込まれる新たな機能では変更できないレガシーアプリケーションが拡張されたりするビジネス上のリスクを低減できるようにします。

Refactor Spaces は、アプリケーションを変換する際に発生する実際的な問題のうち、一般的な 2 つの問題に対処します。つまり、アプリケーションのリファクタリング用のインフラストラクチャを設定し、進化するアプリケーションを大規模に運用します。Refactor Spaces は、既存のアプリケーションとマイクロサービスを 1 つのアプリケーションに結合すると同時に、アーキテクチャとテクノロジー、チームの調整、およびパート間のプロセスでさまざまなアプローチを実現します。Refactor Spaces を使用すれば、レガシーアプリケーションを変換したり、任意の AWS コンピューティングターゲットで実行されるマイクロサービス (EC2、Amazon Elastic Container Service、Amazon Elastic Kubernetes Service、AWS Fargate、AWS Lambda など) で拡張したりできます。Refactor Spaces は、アプリケーションを数分でリファクタリングするためのインフラストラクチャを作成することにより、時間を大幅に節約します。

リファクタリング、リライト、またはリファクタリングの対象となるアプリケーションは、外部インターフェイスが HTTP ベースのプロトコルであり、AWS で実行されている限り (または、Application Migration Service でリホストするか、最初にリプラットフォームすることが可能)、Refactor Spaces を使用する候補となります。Refactor Spaces は、一般的に古いレガシーアプリケーションやモノリシックアプリケーションをリファクタリングするために使用されますが、最新のサービスやアプリケーションのリファクタリングや再構築を操作する場合も役に立ちます。

Refactor Spaces は、他の AWS サービスを調整して、リファクタリング環境を作成し、既存のアプリケーションとマイクロサービスを、アプリの進化中に操作しやすい Refactor Spaces アプリケーションに統合します。アプリケーションリファクタリング環境は、Transit Gateway、Resource Access Manager、および API Gateway を使用して構築されます。Refactor Spaces はこれらを使用して、ネットワークとブリッジされたマルチアカウント構造により、既存のアプリケーションをマイクロサービスから分離して、アカウント間の通信を容易にします。

Refactor Spaces 環境は、AWSアカウント全体のネットワーク、アプリケーション、およびサービスの統合ビューを提供する、既存のアプリケーションと新しいマイクロサービスのコンテナです。この環境は、Transit Gateway、Resource Access Manager、および VPC を調整して、アカウント間のネットワークをブリッジし、新規サービスと旧サービス間の通信を簡素化します。環境所有者のアカウントに環境が作られます。所有者は環境を他の AWS アカウントと共有し、環境に追加されたアプリケーション、サービス、およびルートを管理することができます。

Refactor Spaces アプリケーションは、既存のアプリケーションと新しいマイクロサービスへの設定可能なリクエストルーティングを提供します。アプリケーションには、AWS でのストラングラーフィグのリファクタリングを簡素化するプロキシが含まれています。環境内でアプリケーションを作成する場合、Refactor Spaces は、API Gateway、Network Load Balancer (NLB)、および AWS Lambda リソースポリシーをオーケストレートします。アプリケーションのプロキシとルーティングは、アプリケーションの利用者に対して基盤となるアーキテクチャの変更を透過的に保つために使用されます。

Refactor Spaces サービスは、既存のアプリケーションまたは新しいマイクロサービスのエンドポイントを表します。サービスは、URL エンドポイントまたは AWS Lambda エンドポイントのいずれかを備えた VPC を持つことができます。Refactor Spaces は、Transit Gateway を使用して環境内でサービス VPC を自動的にブリッジし、環境内のすべてのアカウントにわたってサービス VPC 内のすべての AWS リソース間のトラフィックが許可されるようになります。サービスへのルートを設定するときに、サービスに Lambda エンドポイントがある場合、トラフィックは API Gateway の Lambda 統合を使用してルーティングされます。URL エンドポイントを持つサービスの場合、トラフィックは API Gateway VPC リンクと NLB ターゲットグループを使用してルーティングされます。

Refactor Spaces は、AWS マネジメントコンソール、AWS SDK/CLI、または CloudFormation (CFN) 経由で使用できます。通常、少なくとも 2 つのアカウントから始める必要があります。1 つは既存のアプリケーション用、もう 1 つは Refactor Spaces 環境を所有し、サービス間のトラフィックルーティングを管理するためのものです。AWS アカウントは、スタンドアロン、AWS Organization の一部、または AWS Control Tower によってプロビジョンされた新規アカウントまたは既存のアカウントにすることができます。 

まず、リファクタリングに使用する予定の各 AWS アカウントに Refactor Spaces サービスリンクロール (SLR) をインストールします。アカウントの Refactor Spaces コンソールにアクセスするか、IAM のコンソールまたは API を使用して SLR を作成することにより、リファクタリングに使用することを計画しています。次に、環境所有者として選択したアカウントに Refactor Spaces 環境を作成し、環境を他のアカウントと共有します。他のアカウントが環境共有の招待を受け入れると、Refactor Spaces は環境に含まれる AWS リソース (Transit Gateway など) を指定された他のアカウントと自動的に共有します。 

次に、最初のアプリケーションを作成します。Refactor Spaces アプリケーションは、サービスがどのアカウントにあるかに関係なく、(API Gateway を介して) 構成可能なリクエストのルーティングを Refactor Spaces サービスに提供します。アプリケーションを作成したら、その中に 1 つ以上のサービスを作成します。最初は、すべてのトラフィックが既存のアプリケーションに流れるため、既存のアプリを表示するサービスにすべてのトラフィックを送信するデフォルトルートを作成します。時間の経過とともに、新しいマイクロサービスによって提供されるビジネス機能へのトラフィックを削減するためのルートを追加します。

はい。VPC エンドポイントを作成すると、VPC (Amazon Virtual Private Cloud を使用して作成) から Refactor Spaces の API にプライベートにアクセスできます。VPC エンドポイントを使用すると、VPC と Refactor Spaces の間のルーティングが AWS ネットワークによって処理されます。インターネットゲートウェイ、NAT ゲートウェイ、仮想プライベートネットワーク (VPN) 接続は必要ありません。Refactor Spaces で使用される最新世代の VPC エンドポイントでは、AWS PrivateLink が使用されています。AWS PrivateLink は、VPC でのプライベート IP アドレスと Elastic Network Interface (ENI) を使用することにより、AWS のサービス間でのプライベート接続を実現するテクノロジーです。 PrivateLink サポートの詳細については、Refactor Spaces PrivateLink のドキュメントを参照してください。

移行オーケストレーションは、テンプレートを使用し、複数のタスクをワークフローに同期させ、依存関係を管理して、移行プロジェクトの望ましい目標を達成するプロセスオートメーションの仕組みです。

AWS Migration Hub Orchestrator は、アプリケーションの AWS への移行を自動化および簡素化するように設計されています。Orchestrator は、大規模なエンタープライズアプリケーションの移行に関連する手動タスクの多くを削除し、さまざまなツール間の依存関係を管理し、移行の進行状況を一箇所で可視化することで、移行のコストと時間を削減するのに役立ちます。複雑なワークフローと相互に依存するタスクをオーケストレートする所定の移行タスク、移行ツール、およびオートメーションの機会を提供する Orchestrator にある定義済みおよびカスタマイズ可能なワークフローテンプレートを使用し、AWS への移行プロセスを簡素化します。 

Orchestrator は、移行の加速、移行プロセスの簡素化、ユースケースに合わせた移行ツールやプロセスの適応を支援します。

• 移行を加速する: AWS が移行した類似パターンの数千のアプリケーションを基にした実証済みの定義済みワークフローテンプレートを使用して、アプリケーションの移行を加速します。
• オートメーションによる簡素化: AWS Application Discovery Service、AWS Application Migration Service、AWS Launch Wizard などの複数のツールで、同じ移行ワークフローに対して移行前のタスク、移行ワークフロー、移行タスクを自動化し、手作業を最小限に抑えることができます。 
• 適応と効率化: ベースラインのレコメンデーションの上に構築し、特定のワークロードやユースケースのニーズに対応するようにステップや依存関係を変更することで、ワークフローテンプレートをカスタマイズして再利用します。

Orchestrator は、アプリケーションの AWS への移行を簡素化し、加速します。

• 規定された方法論を使用してアプリケーションを移行: AWS が移行した類似パターンの数千のアプリケーションを基にした定義済みワークフローテンプレートを使用することで、迅速に移行を開始することができます。
• 移行ワークフローのカスタマイズ: 独自のステップ、依存関係、オートメーションを追加してワークフローをカスタマイズし、特定のユースケースのニーズに対応することができます。
• 元の環境での移行前タスクのオーケストレート: 移行準備の確認、エージェントのインストール、AWS に移行したくない不要なログファイルの削除などが必要になることがよくあります。これらのタスクをオンプレミスの各サーバーで手動で行うのは、面倒でミスが発生しやすい作業です。Orchestrator を使えば、これらのタスクを自動化することで、時間とコストを削減しながら、エラーを減らすことができます。
• 異なる移行ツールで移行タスクをオーケストレート: 最適な移行プロセスでは、同じ移行ワークフローに対して AWS Application Discovery Service、AWS Application Migration Service、AWS Launch Wizard など、複数のツールを使用する場合があります。Orchestrator を使用すると、インベントリメタデータ、設定仕様、および環境コンテキストを再利用して移行タスクをオーケストレートし、これらの各ツールで提供する必要がある入力を最小限に抑えることができます。手動で行っていた移行作業を自動化し、さまざまなツール間の依存関係を管理し、移行の進行状況を一箇所で可視化することで、Orchestrator は移行のコストと時間を削減するのに役立ちます。
• 移行したアプリケーションを設定、検証、起動する: 大規模な移行では、インスタンス、データベース、ネットワーク接続の状態を確認し、移行先のサーバーにアプリケーションをインストールまたはアンインストールし、ステージング環境をシャットダウンするため、カットオーバー期間とダウンタイムが長くなってしまいます。Orchestrator を使用すると、これらの定型的な移行ステップを自動化し、カットオーバー時間を 50% 以上短縮することができます。

AWS Migration Hub コンソールまたは AWS Command Line Interface (CLI) から Orchestrator にアクセスすることができます。Orchestrator を使用して、ソースサーバーの検出またはインポート、検出されたサーバーのアプリケーションへのグループ化、ソース環境へのプラグインのインストールなどの前提条件を完了させることができます。次に、定義済みのワークフローテンプレートのいずれかを選択して、アプリケーションの移行をオーケストレートするためのワークフローを作成します。必要であれば、ワークフローの一部として自動化または手動で完了するカスタムステップを指定することもできます。ワークフローを定義した後は、実行、一時停止、削除が可能です。また、Orchestrator のステップレベルおよびステップグループレベルでワークフローの状態を追跡することができます。

ワークフローテンプレートは、移行タスク、依存関係、適切な移行ツール、および推奨されるオートメーションの機会について規定されたプレイブックです。例えば、SAP NetWeaver ベースのアプリケーションを HANA データベースで移行するための定義済みワークフローテンプレートには、ソースサーバーとプラグイン間の接続性の自動検証、AWS Launch Wizard を使用して新しい SAP 環境をプロビジョニングする機能、ソースとターゲット環境の自動検証、HANA データベースとアプリケーションの自動移行、移行後検証のステップバイステップタスクが含まれています。 

オーケストレーターでは現在、5 つの定義済みワークフローテンプレートをサポートしており、使用することができます。1 つ目のテンプレートは、AWS Launch Wizard と HANA System Replication を使用して、SAP NetWeaver ベースのアプリケーションを HANA データベースで移行するのに役立ちます。2 つ目のテンプレートは、AWS Application Migration Service (MGN) を使用して、あらゆるアプリケーションのリホストを高速化するのに役立ちます。3 つ目と 4 つ目のテンプレートは、SQL Server データベースを Amazon RDS にリプラットフォームし、ネイティブバックアップとリストアを使用して SQL Server データベースを Amazon EC2 にリホストするのに役立ちます。5 つ目のテンプレートでは、オンプレミスの仮想マシン (VM) イメージを AWS にインポートすることができるようになりました。IT セキュリティ、設定管理、コンプライアンス要件を満たすように構築した VM イメージから Amazon マシンイメージ (AMI) を生成するコンソールベースのエクスペリエンスが得られます。これらのテンプレートにはすべて、新しいステップとオートメーションスクリプトを追加するオプションがある、タスクの事前定義されたオートメーションが含まれています。