Amazon Web Services ブログ

AWS MGN と AWS RAM を使ってAWSへの大規模なマイグレーションを統制する

この記事は、Use AWS RAM and AWS MGN to Govern your Migration at scale in AWSを翻訳したものです。

はじめに

多くのAWSのお客様は、クラウドにおける価値である、スピード、コスト削減、ビジネスの俊敏性、オペレーショナル レジリエンス、スタッフの生産性などのメリットを得るために、最初の段階としてリホスト（リフト＆シフト）によるマイグレーションを考えます。そして、移行計画の一環として、AWSの基盤を大規模に構築するためにマルチアカウント戦略を採用します。その際、組織的にマイグレーションを行う上で、異なる仮想プライベートクラウド (Amazon VPC) 内の複数のネットワークを管理することの複雑さが1つの課題となります。

このブログでは、AWS Application Migration Service (AWS MGN) とAWS Resource Access Manager (AWS RAM) を使用したマルチアカウント戦略を組み合わせることで、ネットワークガードレールを使った大規模な移行を行う方法を紹介します。

ソリューションの概要

このソリューションは、マイグレーションを実行する際のネットワークインフラストラクチャを一箇所で管理できるようにするものとなります。図-1の構成をご覧ください。AWS Organization の中に4つのアカウントを持った構成で、アカウント A が VPC を所有するメインアカウントとなっています。そして、アカウント B、C、D はマイグレーション先となるアカウントで、アカウント A から VPC を共有してもらいます。このマルチアカウント環境では、アカウント A が残りのアカウントのネットワークインフラストラクチャを一箇所で管理します。アカウント A は AWS Transit Gateway を持ち、アカウント間の接続管理を行います。ネットワークチームは、アカウント A が管理するサブネットを他のアカウントに共有します。そして、アカウント B、C、D では AWS MGN を利用し、個々のアカウント用のステージング領域を用いてマイグレーションを行います。このようにすることで、アカウント B、C、D は、アカウント A のネットワークチームが適切に構成、保護、監視しているサブネットを利用することができます。

Figure 1. Diagram of subnets shared across multi-accounts for MGN resources

図1. マルチアカウント間でサブネットを共有して AWS MGN を使用する

前提条件

AWS RAM と AWS MGN を使い大規模なマイグレーションを成功させるための要件は以下となります。

ソリューションのデプロイ

設定手順

1.    AWS RAM を使用してアカウント間でサブネットを共有する
このシナリオでは、AWS RAM を使ってアカウント B、C、D と共有する3つのサブネットが用意してあります。

  1. VPC の所有者(アカウント A )の AWS RAM で[リソースの共有] を作成します。

  1. 共有リソースに対してデフォルトの権限を関連付けます。

  1. [自分の組織内でのみ共有を許可] を選択し、VPC への参加者 (アカウント B、C、D ) の AWS アカウント ID を追加します。

注:リソースの共有を作成してからリソースとアカウントの関連付けが完了するまでに数分かかることがあります。

2. 共有されたサブネットをレプリケーションに使用するために AWS MGN を設定する

アカウント A から共有されたサブネットを、VPC への参加者 (アカウント B、C、D ) の AWS MGN で使用するために、レプリケーションの設定を変更する必要があります。

まず、アカウント B の設定を変更します。AWS コンソールで AWS MGN を開きます。左側のパネルの [Settings]をクリックします。

  1. [Replication template]の[Edit template]をクリックします。

  1. ステージング領域のサブネットとして、アカウント A から共有されたサブネットを選択します。

  1. 移行元のオンプレミスの仮想マシンに AWS MGN エージェントをインストールして、リホスト（リフト＆シフト）を始めます。

3. 共有されたサブネットをカットオーバーに使用するために AWS MGN を設定する

AWS MGN エージェントをインストールすると、レプリケートされたオンプレミスサーバーが AWS MGN のコンソールに表示されます。

次の例では、Server-1 と Server-2 の2台のオンプレミスサーバーがレプリケートされています。

ステージング領域にレプリケートされたデータから新しい Elastic Cloud Compute (EC2) インスタンスを起動するにはカットオーバーを行う必要があります。その際、EC2 起動テンプレートを用いてインスタンスが起動されます。

    A. 各サーバーの起動テンプレートを変更して、デフォルトのサブネットを VPC の所有者(アカウントA)から共有されたサブネットに変更します。

注:この例では、Server-2 というサーバーの名をクリックして作業を開始します。

  1. [launch settings] タブをクリックし、[EC2 Launch Template]の[Modify] を選択します。

これにより EC2 起動テンプレートにリダイレクトされ、デフォルトのサブネットを VPC 所有者 (アカウント A) の共有サブネットに変更します。

  1. [Modify] ボタンをクリックして続行します。

  1. [ネットワーク設定] で、アカウント A から共有されたサブネットを設定します。

  1. [テンプレートのバージョンを作成] ボタンをクリックして、新しいテンプレートを作成します。

注:新しい起動テンプレートを作成したら、そのテンプレートを使用するように EC2 の起動テンプレートを設定する必要があります。

  1. [起動テンプレートを表示] ボタンをクリックして、起動テンプレートのリストに戻ります。

  1. 起動テンプレート ID を選択して、[アクション] ボタンをクリックし、[デフォルトバージョンを設定] を選択します。

  1. ドロップダウンメニューから最新のテンプレートバージョン (この場合はバージョン2) を選択し、[デフォルトバージョンとして設定] をクリックします。

  1. その他のサーバーについても、VPC の所有者(アカウント A )から共有されたサブネットを使用するよう設定を変更します。

これで、AWS MGN でテスト/カットオーバーを実行した際に、EC2 インスタンスが共有されたサブネットに配置されるようになりました。

クリーンアップ

  1. VPC 参加者 (アカウント B、C、D) の AWS MGN コンソールで [Source servers] を選択し、[Actions] の [Disconnect form service] をクリックします。

  1. [Actions] の [Mark as archived] をクリックします。

注:これで [Source servers] のリストが空になるはずです。

  1. VPC の所有者(アカウント A )にログインし、AWS RAM コンソールを開きます。以前に作成したリソース共有グループをクリックし、[削除] をクリックします。

  1. 数分後、VPC 参加者 (アカウント B、C、D) から共有サブネットが削除されます。

まとめ

この記事では、ネットワークガードレールを活用して一元的に移行プロセスを管理する方法を説明しました。大規模なリホスト（リフト＆シフト）によるマイグレーションは、ネットワークチームにとって困難な場合があり、制御されたネットワーク環境を持つことがクラウドへのマイグレーションを成功させるための第一歩です。さらに、VPC を共有されたチームにとっては、制御されたランディングサブネット内にワークロードをデプロイすることでメリットを得ることができます。AWS RAM と AWS MGN のおかげで、責任を分担しながら共通の目標に向かって取り組むことで、大規模なマイグレーションが可能になります。

翻訳はソリューションアーキテクト 小宮山 裕樹 が担当しました。原文はこちらです。