Migration Acceleration Program (MAP) の目的は、AWS のお客様が AWS への移行を加速できるようにすることです。お客様が既存のオンプレミスのワークロードを AWS に移行すると、移行されたワークロードは tagging と呼ばれるメカニズムによって識別されます。これにより、移行されたリソースに基づいて AWS のコストと使用状況レポート (CUR) を表示できます。移行されたワークロードの支出を報告し、適切なクレジットを生成するために利用できます。
移行したリソースにタグを付けることは、MAP 2.0 プログラムの一環としての要件です。 CUR を有効にしない、または移行されたリソースにタグを付けないことは、アカウントに MAP クレジットを適用しないことを意味します。
このガイドでは、移行されたワークロードにタグ付けを使用する方法を詳しく説明することで、移行アクセラレーションプログラムの一環としてAWSに移行するお客様を支援します。タグ付けにより、顧客は移行されたリソースに基づいてコストと使用状況レポート(CUR)を表示できます。これを利用して、移行されたワークロードの支出を報告し、適切なクレジットを生成できます。
お客様は、このドキュメントの情報を独自に評価する責任があります。このドキュメント:(a)情報提供のみを目的としており、(b)通知なしに変更される可能性のある現在のAWS製品の提供と慣行を表しており、(c)AWSおよびその関連会社、サプライヤー、ライセンサー。 AWSの製品またはサービスは、明示または黙示を問わず、いかなる種類の保証、表明、条件もなしに「現状有姿」で提供されます。お客様に対するAWSの責任と責任は、AWS契約によって管理されており、このドキュメントは、AWSとお客様の間の契約の一部ではなく、変更するものでもありません。
タグ付けは、AWS リソースにラベルを割り当てる方法です。タグを使用すると、AWS リソースをさまざまな方法で分類できます。たとえば、目的、所有者、部門、環境別に分類できます。各タグは、キーとオプションの値(例: Department:Finance
)で構成され、どちらもユーザーが定義します。
MAP の目的上、特定の map-migrated
タグ(タグキーは大文字と小文字が区別されます)は、で移行されたワークロードのタグ付けを行うことは、以下を行うために必要です。
タグ付けの演習は、ワークロードが AWS に移行されるときに行われます。通常、タグは、ワークロードを移行するワークロードの所有者によって適用されます。ワークロードが移動され、MAP 移行スコープ全体が移行されるまで、このプロセスが繰り返されます。
MAP 以外でも、AWS リソースにタグ付けすることはベストプラクティスとなっています。詳細については、 タグ付けのベストプラクティスホワイトペーパーを参照してください。
CUR には、利用可能な最も包括的なコストと使用状況データのセットが含まれています。CURを使用して、所有する Amazon Simple Storage Service (Amazon S3) バケットに AWS 請求レポートを発行できます。時間、日、月、製品または製品リソース、または自分で定義した タグ ごとにコストを分類したレポートを受け取ることができます。 AWS は、バケット内のレポートを 1 日 1 回コンマ区切り値 (CSV) 形式で更新します。 Microsoft Excel や Apache OpenOffice Calc などのスプレッドシート ソフトウェアを使用してレポートを表示するか、Amazon S3 API を使用してアプリケーションからレポートにアクセスできます。
CUR は、AWS使用状況を追跡し、アカウントに関連する推定料金を提供します。各レポートには、AWS アカウントで使用する AWS 製品、使用タイプ、およびオペレーションの一意の組み合わせごとに項目が含まれています。 CUR をカスタマイズして、時間、日、または月ごとに情報を集計できます。
CUR レポートは次のことを行います:
CUR の詳細については、以下を確認してください。リンク
AWS内で公開されている既存のサービス、カスタムタグ、CUR、およびAWS MigrationHubに依存しています。 MAPの移行追跡メカニズムは、3つのステップで構成するネイティブAWS機能を使用します。
ここで全体の流れを図示したものを示します:
次のセクションではこの手順をステップ・バイ・ステップで実施します。
AWS アカウントで CUR を有効にして MAP の準備を整えるための既存の方法が 2 つあります。 CUR セットアップは、AWS CloudFormation スクリプトを使用した自動化によるものと、手動によるものです。
お客様のニーズにより適したプロセスを以下で確認してください。
自動化(推奨!) | 手動 | 自動化(AMS Customers) |
---|---|---|
![]() |
![]() |
![]() |
これは、ペイヤーアカウントごとに行われる 1 回限りのプロセスであり、計画された移行の少なくとも48時間前に行う必要があります。
SAP ワークロードの場合、これは、実際の移行ではなく、RI または Savings Plan を購入する48時間前に行う必要があります。
自動化オプションを利用して、移行計画にリストされているペイヤーアカウントでコストと使用状況レポート(CUR)をすばやく設定し、MAP対象ワークロードのタグ付けに使用するサーバーIDを生成できます。
自動化オプションでは、CloudFormation テンプレートを使用して、必要なリソースと設定をアカウントで作成し、Migration Acceleration Program(MAP) のコストと使用状況レポート (CUR) を正しくセットアップします。
単一のMPE番号を使用してAWSアカウントを初めてCURに設定する場合は、次の手順を使用する必要があります。複数のMPE契約番号については、この後の手動による手順こちら で追加アカウントを加えてください。
これでCURが作成されたはずです。確認するには、Services > Billing > Cost & Usage Reports にアクセスしてください。 map-migrated-report レポート名が表示されます。
作成されたCUR S3バケットは、このプロセスの一部として生成したサーバーIDでタグ付けされています。これは、AWSがアカウントでのクレジット生成を検証するのに役立ちます。
次の24時間以内に、最初のレポートがレポート作成時に設定したAmazonS3バケットに配信されます。
ステップ 1 - CURのセットアップとサーバーID の生成 が完了しました! ステップ 2 - タグの有効化に進んでください。
このページでは、CURを手動でセットアップし、AWS Migration Hub でサーバーID を生成する方法について説明します。 CURの設定 - 自動化 アプローチをすでに使用している場合、ここでの手順は不要で、手順2-タグの有効化にスキップできます。
このビデオチュートリアルは、ガイドのこのセクションで説明されているように、CURをセットアップしてタグを有効化するために必要な手順を実行するためのガイダンスを提供します。
CUR は、ペイヤーアカウントに対する適切な権限を持つチームによって、ペイヤーアカウントごとに1回有効になります。次に、MAPタグ付きリソースの追跡を可能にするために関連する CUR を作成する必要があります。
コストと使用状況のレポートが次のようにコンソールに表示されます。
次の24時間以内に、最初のレポートがレポート作成時に設定したAmazon S3バケットに配信されます。
一般的なMAPワークロードの場合、タグキー map-migrated、 および map-migrated-app を使用します。Specialized MAPプログラムの場合は代替タグが必要になります。 SAP、およびデータベースと分析のワークロードについては、「どのタグを使用すべきか?」を参照してください。
CUR を設定した後、MAPタグのタグ割り当てを有効化する必要があります。これを行うには、最初に少なくとも1つのリソースに対してこれらのタグを使用する必要があります。この目的のために、前のステップでレポートを配信するように設定したAmazon S3バケットを使用して、次のタグを適用しますが、値はありません。
タグ名では大文字と小文字が区別されます。すべてのタグ名に小文字を使用してください。
次に、csvファイルをMigration Hub にインポートする必要があります。
このページでは、Amazon AMSチームにあなたのアカウントでCURを設定するようにリクエストする方法について説明します。この手順は、Amazon AMSをご利用の場合にのみ使用してください。
MAP 2.0自動化ソリューションをインストールするには、ペイヤーアカウントからサブミットされる必要のある手動RFCが1つあります。 RFCが完了すると、AMSチームは、移行されたワークロードにタグを付けてMAP2.0クレジットを獲得するために使用されるサーバーID値を提供します。タグ付けの詳細については、MAP2.0の手順を参照してください。
IAMロールのデプロイと CloudFormation スタックの作成を要求する「Create other RFC」をサブミットします。 RFCの詳細については、次の言語を使用してください。
Account: Management account
RFC Type: Create other
Details:
次の手順を実行してください。 このリンクから、MAP 2.0Automatorに必要なIAMロールを作成します。
https://map-automation.s3.us-west-2.amazonaws.com/cur-server-ids-automator-iam.yaml
このリンクから次の CloudFormation を使用してスタックを作成します。https://map-automation.s3.us-west-2.amazonaws.com/cur-server-ids-automator-ams.yaml
スタック名:
map-automator
パラメータ
S3Region - {{Choose the home region for MALZ}}
MPE - {{Customer MPE ID (e.g: MPE12345)}}
最後に、スタック出力から、顧客に 「サーバーID」値を提供します。これは、ワークロードにタグを付けるときに使用する必要がある値です。
CURを設定した後、次の手順を実行する前に24時間待つ必要があります。
自動化 または 手動 プロセスの使用に関係なく、タグは課金コンソールで手動でアクティブ化する必要があります。
このプロセスの一環として、MAPに使用できるすべてのタグを生成します。一般的なMAPワークロードの場合、map-migrated タグを有効化するだけで済みます。 SAP、およびデータベースと分析のワークロードについては、付録を参照してください。
タグキーでは大文字と小文字が区別されます。 MAPプログラムのすべてのコスト割り当てタグは小文字です。
前のセクションで使用した Cloudformation テンプレートは、必要なタグを作成します。次の手順を使用して、ワークロードに適用されるコスト割り当てタグを有効化する必要があります。
これらのタグを有効化するためには:
初めてコスト割り当てタグを作成すると(マップの移行など)、アカウントに表示されるまでに最大24時間かかる場合があります。上記のようにアカウントにタグが表示されない場合は、24時間後にこの手順に再度アクセスしてください。
AWS CURがセットアップされ、AWSタグがCURでアクティブ化され、サーバーID が既にあるので、移行されたリソースのタグ付けを開始して、関連するクレジットを受け取ります。
Infrastructure-As-Codeツール(AWS CloudFormationやTerraformなど)を使用してAWSで移行済みリソースを作成している場合は、手順1で生成されたサーバーIDを使用してテンプレートにタグラインを追加できます。
AWSコンソールを使用してリソースを直接作成している場合は、リソースに個別にタグを付けるか、AWSタグエディターを使用して一括タグを付けることができます。
手動 | AWS タグエディター |
---|---|
![]() |
![]() |
タグ付けを開始するには、ステップ1 - CUR設定とサーバーIDの生成で生成されたサーバーIDが必要です。
このセクションでは、移行されたリソースの1つに手動でタグを付ける簡単な例を示します。そのためにAWSマネジメントコンソールを使用します。
ステップ1 - CUR設定とサーバーIDの生成プロセスを使用してサーバーIDを生成した場合、cloudformationの出力値であるサーバーIDをタグとして使用してください。
タグの追加
を選択します。Add tags
ボックスで、map-migrated
を Tag Key
として使用し、前の手順でコピーした Server ID
を Value
として使用し、Add
をクリックします。
リソースのタグ付けの詳細については、AWSドキュメントを使用してください。
タグ付けを開始するには、ステップ1 - CUR設定で生成されたサーバーIDが必要です。
このセクションでは、移行されたリソースの1つに手動でタグを付ける簡単な例を示します。そのためAWSマネジメントコンソールを使用します。
ステップ1 - CUR設定プロセスを使用してサーバーIDを生成した場合、CloudFormationの出力値であるサーバーIDをタグの参照として使用してください。
このツールは、ワークロードに適したタグを選択するためのガイドとして開発されました。
データベースとアナリティクスのワークロードを含むMAP契約の場合
SAPワークロードを含むMAP契約の場合
MAP2.0の移行中に使用するタグの例
ソースを選択 | 目的地を選択 |
環境: | |
使用するタグキー : | |
タグの例: | |
その他の注意事項: |
データベースと分析のワークロードを含むMAP契約の場合、代替タグをコスト割り当てタグで有効化し、移行されたリソースに使用する必要があります。次の表に、移行元と移行先に基づくいくつかのシナリオを示します。
移行元 | 移行先 | タグキー | タグ値 |
---|---|---|---|
オンプレミス Oracle/SQL Server | EC2 Oracle/SQL Server | map-migrated | ステップ1で生成された サーバーID |
オンプレミス Oracle/SQL Server | RDS Oracle/SQL Server | map-migrated | ステップ1で生成された サーバーID |
オンプレミス Oracle/SQL Server | RDS PostgreSQL/MySQL/etc. | map-dba | ステップ1で生成された サーバーID |
オンプレミス Oracle/SQL Server | Amazon Aurora | map-dba | ステップ1で生成された サーバーID |
オンプレミス Oracle/SQL Server | Amazon DynamoDB | map-dba | ステップ1で生成された サーバーID |
EC2 Oracle/SQL Server | RDS Oracle/SQL Server | map-migrated aws-migration-project-id |
ソースEC2インスタンスのARN値 MPE番号 |
EC2 Oracle/SQL Server | Amazon Aurora | map-dba aws-migration-project-id |
ソースEC2インスタンスのARN値 MPE番号 |
EC2 Oracle/SQL Server | DynamoDB | map-dba aws-migration-project-id |
ソースEC2インスタンスのARN値 MPE番号 |
RDS Oracle/SQL Server | RDS PostgreSQL/MySQL/etc. | map-dba aws-migration-project-id |
ソースRDSインスタンスのARN値 MPE番号 |
RDS Oracle/SQL Server | Amazon Aurora | map-dba aws-migration-project-id |
ソースRDSインスタンスのARN値 MPE番号 |
RDS Oracle/SQL Server | DynamoDB | map-dba aws-migration-project-id |
ソースRDSインスタンスのARN値 MPE番号 |
For more information on ARN format, please check the ARN section on Additional Resources page.
SAPワークロードのMAP契約の場合、代替タグ、map-sap
をアクティブにして、MAPプログラムで使用する必要があります。
移行元 | 移行先 | タグキー | タグ値 |
---|---|---|---|
オンプレミス | AWS | map-sap | ステップ1で生成された サーバーID |
AWS Resources for SAP は、支出の計算で考慮される3年間のリザーブドインスタンス(RI)またはセービングプラン(SP)を消費している必要があります。
お客様は、リフト&シフト(リホスト)移行パターンを使用してオンプレミスからAWSに移行しており、移行にCloudEndureを使用することを決定しました。
タグキー(自動化) | 値(自動化) |
---|---|
map-migrated |
ステップ 1で生成された ServerID |
お客様は、一般的なMAPの一部としてさまざまな移行パターン(リホスト、リアーキテクトなど)を使用して、さまざまなワークロードをオンプレミスからAWSに移動しています。
タグキー | 値 |
---|---|
map-migrated |
ステップ 1で生成された サーバーID |
お客様は、MAP for Databaseの一部として、MS SQLデータベースをAWS上のAmazonEC2インスタンスからAmazonRDS for SQLサーバーに移動しています。
タグキー | 値 |
---|---|
map-migrated |
ソースEC2インスタンスのARN値 |
お客様はオンプレミスのMSSQLサーバーからAmazonAuroraに移行しています。この例は、オンプレミスから直接モダナイゼーションする場合と、MAPの最初のステージとしてEC2に移行した後にモダナイゼーションする場合の両方を含む、ワークロードがDBAモダナイゼーションのメリットを享受するためのものです。
タグキー | 値 |
---|---|
map-dba |
ステップ 1で生成された サーバーID |
For more information on ARN format, please check the ARN section on Additional Resources page.
Amazon EKSの移行追跡は、引き続き既存のMAP2.0タグ付けプロセスに依存します。 tag-keyとtag-valueは、MAPタグ付けガイドで詳しく説明されている標準のMAPタグと同じになります。
Amazon EKSは複数のAWSサービスを起動する可能性があるため、Amazon EKSによって起動されるすべてのリソースとサービスにタグを付ける必要があります。以下のガイドは、すべてのAmazon EKSリソースに正しくタグを付ける方法の詳細な手順を示しています。
現在、EKSはタグを伝播しません。 EKSがタグの伝播をサポートするまでの代替ソリューションとして、以下に詳述する以下の手順が必要です。
Kubernetes APIでは、クラスターのコンテキスト内から複数のリソースタイプを定義できますが、リソースを複数のクラスターまたはAWSリソース間で共有できない場合、AWSはこれらのリソースをクラスターの内部としてモデル化します。料金は、Amazon EKSクラスター時間と以下の内部クラスターリソースに基づいています。
Kubernetesクラスター自体と、ノード、ロードバランサー、EBSボリュームなどのすべての有料内部クラスターリソースにタグを適用するには、以下の手順に従います。
タグは、Amazon EKSコンソール、eksctl、AWS CLI、AWS API、またはInfrastructure-as-a-Codeツールを使用して、新規または既存のKubernetesクラスターに追加できます。
ノードグループ内のノードのタグ付け -AmazonEKSクラスターは、自己管理ノードとEKS管理ノードの任意の組み合わせでポッドをスケジュールできます。管理対象ノードまたは自己管理対象ノードが適切にタグ付けされていることを確認するには、以下の手順に従ってください。
マネージド ノード: マネージドノードグループのノードにタグを付けるには、カスタム起動テンプレートを使用します。起動テンプレートの TagSpecificationparameter を使用して、ノードグループ内のノード(EC2インスタンス)に適用するタグを指定します。タグ指定の詳細については、こちらにアクセスしてください。管理対象ノードグループは、EKS API、AWS CLI、CloudFormation、またはEKSコンソールを使用してカスタム起動テンプレートで起動できます。詳細については、こちらをご覧ください。
セルフマネージドノード: タグパラメータを使用してeksctlでノードグループを作成することにより、タグを自己管理ノードに適用できます。タグは、セルフマネージドノードグループ作成の一部として作成されたすべてのEC2インスタンスに適用されます。タグは、AWSマネジメントコンソールを使用してセルフマネージドノードに適用することもできます。詳細については、こちらをご覧ください。
AWSロードバランサーコントローラーは、KubernetesクラスターのためのAWS Elastic LoadBalancerを管理します。コントローラーは以下をプロビジョニングします。 AWS Load Balancer Controllerは、KubernetesクラスターのためのElastic Load Balancingを管理します。AWS Load Balancer Controllerは以下をプロビジョニングします。
Application Load Balancer (ALB): Kubernetes Ingress を作成すると、コントローラーがALBの作成をトリガーします。 ALBにタグを付けるには、ALB Ingress コントローラーのアノテーションalb.ingress.kubernetes.io/tagsを追加し、作成されたALBに適用する必要のある追加のタグを指定する必要があります。タグアノテーションの詳細については、こちらにアクセスしてください。EKSのアプリケーション負荷分散の設定詳細については、こちらにアクセスしてください。
Network Load Balancer(NLB): IPターゲットを使用してタイプLoadBalancerのKubernetes Serviceを作成すると、コントローラーがNLBの作成をトリガーします。詳細については、こちらにアクセスしてください。NLB にタグを付けるには、作成時にアノテーションservice.beta.kubernetes.io/aws-load-balancer-additional-resource-tagsをNLBに追加する必要があります。詳細については、こちらにアクセスしてください。EKSでのNLBの使用詳細については、こちらを参照してください。
Amazon EBS Container Storage Interface (CSI) ドライバーは、Amazon EKSクラスターがEBSボリュームのライフサイクルを管理できるようにする CSIインターフェースを提供します。動的にプロビジョニングされたEBSボリュームにタグを追加するには、CSIドライバーでコマンドオプション -extra-tags を使用します。詳細な手順については、ドキュメントを参照してください。
AWS Fargateは請求目的でEKSの下に製品グループとしてリストされているため、EKSクラスターにタグを付けるとFargateの使用コストが組み込まれます。
タグ付けの手順は、EKSのドキュメントにも記載されています。
顧客がすでにCURを作成している場合、同じスクリプトで既存のCURを検証できます(既存のレポート名は map-migrated で始まる必要があります)。現在のCURに、MAP要件に従って設定されていないパラメーターが含まれている場合、スクリプトはCloudWatchにログを投げ、設定の誤りとその修正方法をユーザーに通知します。
これは、CloudWatchでの不備のあるレポート検証の例です。
ログ画面に移動するには、CloudFormationのリソースに移動し、Lambda関数リソースをクリックして、Monitoring > View logs in CloudWatchに移動します。
CURはペイヤーアカウントで作成する必要があるため、顧客がペイヤーアカウント以外でスクリプトを実行すると、スクリプトはそれを検出し、レポートを作成しません。CloudWatchのお客様に、ペイヤーアカウントに切り替える必要があることを通知します。
CUR は、ペイヤーアカウントに対する適切な特権を持つチームによって、ペイヤーアカウントごとに1回有効になります。次に、MAPタグ付きリソースの追跡を可能にするために、関連する CUR を作成する必要があります。
ターゲットAWSリソースにタグを付けた後、移行プランの各ペイヤーアカウントでターゲットAWSリソースがどれだけ使用されているかを確認する場合は、コストエクスプローラーを使用してターゲットAWSリソースのおおよその量を確認できます。詳細については、AWS Billing and Cost Management - Analyzing your cost with Cost Explorer User Guideを参照してください。
CUR-Server-Ids Automatorスクリプトは何をしますか?
このスクリプトは2つのことを行います。最初にお客様のAWSアカウントでCURを作成して構成し、次にお客様がMAP移行ワークロードにタグを付けるために使用する必要のあるサーバーIDを生成します。
ステップ1 - CUR設定とサーバーIDの生成にログインして実行するために顧客が使用する必要があるAWSアカウントはどれですか?
移行は同じマスターペイヤーアカウントで行う必要がありますか?
移行が発生するすべてのアカウントは、コストと使用状況レポート(CUR)が有効になっているペイヤーアカウントにリンクする必要があります
ドキュメントには、MPE番号が必要であると記載されています。その番号はどこにありますか?
MPE番号は、ステップ1 - CUR設定とサーバーIDの生成の一部として移行計画で識別される必要があります。これは、お客様毎およびアカウント毎に複数の移行計画を容易にするためです。この番号は、貴社アカウントチームによる申請手続きを行う際に入手できます。
ステップ1 - CUR設定とサーバーIDの生成 を完了後、サーバーID情報を取得するにはどうすればよいですか?
情報を取得するには 2 つの方法があります。
map-migrated タグを使用して AWS で移行したリソースに タグを付けるにはどうすればよいですか ?
AWS のリソースにタグを付ける方法はいくつかあります。AWS管理コンソールの各リソースに移動してタグを作成するか、作成中または作成後にリソースを一括タグ付けするカスタムスクリプトを記述するだけで簡単にできます。
私はすでにMAP2.0を進めており、各ソースサーバーにサーバーIDを必要とするタグ付けプロセスに従っています。今後はどのように進めればよいですか?
各ソースサーバーのサーバーIDを使用して移行されたリソースに既にタグを付けている場合、そのプロセスは引き続きサポートされるため、継続可能です。または、Migration Hub から1つ(1つ/任意)のサーバーIDを選択して、移行されたすべてのリソースにタグを付けることにより、将来の移行のタグ付けを簡素化するオプションがあります。これにより、移行ワークロードごとに完全なサーバーインベントリをアップロードする必要がなくなります。
タグ付けできないがMAPにも含まれているベースラインAWSサービス(Amazon S3、VMware on AWS、Amazon Connect、AWSマネージドサービス)のプロセスは何ですか?
Amazon S3のベースラインを提供する必要があります。 Amazon Connect、VMware on AWS、およびAmazon Managed Services(AMS)の場合、これは自動化されたプロセスです。
既存の AWS リソースにタグを付けることはできますか ?
プログラム規約には、契約日以降に移行されるワークロードのみがインセンティブの対象となることが明記されています(移行プランで特定された既存のAmazonストレージリソースと、ガイドの付録Bで利用できる特定のDB&Aワークロードを除く)。
MAP の対象となるのはどのサービスですか ?
MAP の対象となるすべてのサービスは、 Included Services and DB Freedom Sourcesにあります。
ステップ1 - CUR設定とサーバーIDの生成 の実行コストはいくらですか?
ステップ1-CUR設定とサーバーIDの生成 は、S3を使用してCURとアップロードされたインベントリをそれぞれ保存します。これらのファイルは通常小さく(数KB)、料金が発生するまでに時間がかかります。詳細については、Amazon S3の価格を確認してください。ステップ1 - CUR設定とサーバーIDの生成 - 自動化 は、顧客のアカウントに料金が発生しないように十分短い時間(数秒)、Lambda関数を使用します(ラムダフリーティア)。詳細については、AWS Lambda の料金を確認してください。ステップ1 - CUR設定とサーバーIDの生成は1回だけ実行する必要があり、サーバーIDはすでに作成されているため、どちらも料金は発生しないと言っても過言ではありません。
セキュリティについて懸念があります。 ステップ1 - AWSアカウントでCUR設定とをサーバーIDを生成 するために必要なアクセス許可についての詳細が必要です。詳細はどこで確認できますか?
タグは大文字と小文字が区別されますか?
はい。AWSカスタムタグは、大文字と小文字が区別されます。MAPプログラムで使用される全てのタグキーは小文字であり、以下に記載されている例と一致している必要があります。
MAP2.0の一部としてAmazonEC2専有ホストを使用可能ですか??
はい。 MAP2.0の一部としてAmazon EC2 専有ホストを使用することが可能です。