VMware Cloud™ on AWS は、VMware のエンタープライズクラスの SDDC ソフトウェアを AWS クラウドで利用できるようにするサービスです。AWS のサービスにも容易にアクセスできます。VMware Cloud Foundation を基盤とする VMware Cloud on AWS は、VMware のコンピュート、ストレージ、ネットワーク仮想化の製品（VMware vSphere®、VMware vSAN™、VMware NSX®）と VMware vCenter による管理機能が統合されており、伸縮性のある専用のベアメタル AWS インフラストラクチャで稼働するように最適化されています。

AWS 米国東部（バージニア北部）、AWS 米国東部（オハイオ）、AWS 米国西部（北カリフォルニア）、AWS 米国西部（オレゴン）、AWS カナダ（中部）、AWS 欧州（フランクフルト）、AWS 欧州（アイルランド）、AWS 欧州（ロンドン）、AWS 欧州（パリ）、AWS アジア パシフィック（シンガボール）、AWS アジア パシフィック（シドニー）、AWS アジア パシフィック（東京）、AWS アジア パシフィック（ムンバイ）、AWS 南米（サンパウロ）、AWS アジア パシフィック（ソウル）、AWS 欧州（ストックホルム）、AWS 欧州（ミラノ）、AWS アジア パシフィック（大阪）、および AWS GovCloud（米国西部）と AWS GovCloud（米国東部）でご利用いただけます。なお一部のリージョンでは、お客様が明示的にオプトインして、独自の AWS アカウントを SDDC にリンクする必要があります。

はい、SDDC Groups with Transit Gateway機能は、この地域ではまだサポートされていません。

はい。お客様には、こちらの手順に従って明示的にオプトインしていただく必要があります。

機能の最新情報については、ロードマップのページをご覧ください。

はい。VMware Cloud on AWS の SDDC は、広帯域および低遅延で AWS サービスに接続できる、柔軟性の高いベアメタル AWS インフラストラクチャ上で直接実行されます。仮想マシン ワークロードから、AWS のサービス（AWS Lambda、Amazon Simple Queue Service（SQS）、Amazon S3、Elastic Load Balancing など）のパブリック API エンドポイント、お客様の Amazon VPC のプライベート リソース（Amazon EC2 など）、およびデータ サービスや分析サービス（Amazon RDS、Amazon DynamoDB、Amazon Kinesis、Amazon Redshift など）にアクセスできます。さらに、フルマネージド ファイル サービスの Amazon Elastic File System（EFS）を利用して、ファイルベースのストレージをペタバイト規模まで自動的に拡張したり、複数のアベイラビリティ ゾーンによる高可用性と耐久性を実現したりできるほか、最新世代の VPC エンドポイントを利用してすべてのトラフィックを AWS のネットワーク内に留めながら AWS のサービスにアクセスすることもできます。

VMware のアカウント チーム、VMware Partner Network、AWS のアカウント チーム、または AWS Partner Network までお問い合わせください。

VMware Cloud on AWS では多層的な保護が採用されています。AWS のインフラストラクチャの物理的な保護とネットワーク保護のすべてが継承されるほか、vSphere、vSAN、NSX に組み込まれているセキュリティ機能が専用のコンピュートおよびストレージで効果的に機能します。お客様のサイトと VMware Cloud on AWS サービスの間で送信されるすべてのデータを VPN で暗号化できます。VMware Cloud on AWS サービスと SDDC の間で送信されるすべてのデータが暗号化され、保存データも暗号化されます。また、VMware Cloud on AWS のインフラストラクチャでは、さらなるセキュリティの強化のために、セキュリティの脆弱性の監視と定期的なテストが行われています。

オンプレミス環境の VMware テクノロジーによるソフトウェア制御が高度であればあるほど、VMware Cloud on AWS から得られる価値は高まります。今回のリリースではサポートが拡張され、VMware vSphere® 6.0 U3 パッチ c 以降を実行しているオンプレミスの vCenter がサポートされるようになりました。仮想マシンのコールド マイグレーションを実行して VMware Cloud on AWS との間でワークロードを双方向に移動することもできます。変換や変更は必要ありません。また、VMware Cloud on AWS を単体で使用することもできます。その場合、必要なのは Web ブラウザーのみです。詳細については、VMware 互換性ガイドを参照してください。（https://www.vmware.com/resources/compatibility/search.php）

VMware Cloud on AWS では、ドイツ語、日本語、英語に加えて、フランス語、スペイン語、韓国語、簡体字中国語、繁体字中国語の各言語と地域の設定がサポートされるようになりました。VMware Cloud on AWS コンソールのほか、ID およびアクセスの管理、請求とサブスクリプションなどのクラウドサービス プラットフォーム機能、およびサポート センターの一部がこれらの言語に対応しています。表示言語の指定は、VMware Cloud on AWS コンソールにログインする前や、アカウント設定で行うことができます。詳細については、言語と地域設定の変更をご覧ください。

こちらのサービス説明書をご確認ください。

VMware Cloud on AWS インフラストラクチャは、AWS が単一のアカウントに提供する専用のシングル テナント ホスト上で実行されます。各ホストは Amazon EC2 I3.metal インスタンス（ソケットあたり 18 コアの 2 ソケット、512 GiB の RAM、15.2 TB Raw SSD ストレージ）に相当します。1 台のホストで多数の VMware 仮想マシンを実行できます（コンピュート、メモリ、ストレージの要件により数十台から数百台）。クラスタは、クラスタあたり最小 2 台から最大 16 台のホストで構成できます。各 SDDC 環境には、それぞれ単一の VMware vCenter Server が展開されます。

VMware アカウント チームにお問い合わせください。サブスクリプション購入プログラム（SPP）またはハイブリッド購入プログラム（HPP）のクレジットをご購入いただき、それらのクレジットを使用してサービスをご利用いただけます。これらのクレジット プログラムの詳細については、次の Web サイトを参照してください。 SPP プログラム ガイド HPP プログラム ガイド 本サービスには、クレジット カードまたは請求書払いをご利用いただけます。

VMware Cloud on AWS については現在、次の 6 通貨に対応しています。米ドル、英国、ユーロ、日本円、豪ドル、人民元。これらの通貨で料金をお支払いいただき、VMware Cloud on AWS が利用可能ないずれかの AWS リージョンでワークロードを実行できます。

このサービスは、VMware が提供、販売、サポートするサービスで、料金も直接 VMware から請求されます。VMware SDDC ソフトウェアの料金と、基盤となる AWS リソースの料金を含む、このサービスの利用料金の合計金額が記載された 1 つの請求書が届きます。なお、AWS コンソールや AWS API を使用して（つまり VMware の管理ツール、API、オーケストレーション ツールを使用せずに）直接プロビジョニングした AWS リソースの料金は、AWS アカウントを通じてお客様に直接請求されます。

VMware Cloud on AWS は、オンデマンド、1 年間または 3 年間のサブスクリプションでご利用いただけます。最新の料金については 料金のページでご確認ください。 

課金は、VMware Cloud on AWS インスタンスの利用を開始した時点から始まります。具体的には、コンソールまたは API を使用して SDDC のプロビジョニングを開始した時点です。

課金の終了は、VMware Cloud on AWS インスタンスの利用を終了した時点です。具体的には、SDDC が削除された時点です。

詳細については、この FAQ の「シングル ホストの SDDC」セクションと、料金のページを参照してください。

いいえ。サブスクリプションの購入後は、どのパラメーターも変更できません。購入する前に、SDDC を展開済みのリージョン、または展開予定のリージョンを正しく選択していることを確認してください。

柔軟なサブスクリプションは、現在プレビュー版についてご利用いただける、VMware Cloud on AWS の新しいサブスクリプション タイプです。これは VMware Cloud コンソールで、サブスクリプション購入フローの一部として選択することができます。柔軟なサブスクリプションのメリットは、VMware Cloud on AWS の柔軟なサブスクリプションを、任意の新しい VMware Cloud on AWS 期間限定サブスクリプションと交換できることです。柔軟なサブスクリプションをご購入いただくと、既存の柔軟な期間限定サブスクリプション（1 年間または 3 年間契約）を早期に終了して、残りの金額を新しい 1 年間または 3 年間のサブスクリプションの購入に当てることができます。

柔軟なサブスクリプションは、VMware Cloud コンソールからご購入いただけます。営業部門とご相談のうえ、柔軟なサブスクリプションが自社に適しているかどうかをご判断ください。柔軟なサブスクリプションは現在、AWS リセラーとマネージド サービス プロバイダーを除くすべての販売ルートでご購入いただけます。

現在、VMware Cloud on AWS のすべてのリージョンで、i3.metal インスタンス タイプのサブスクリプションを、柔軟なサブスクリプションとして利用できます。現時点では、i3en.metal インスタンス タイプのサブスクリプションは柔軟なサブスクリプションとしてご利用いただけません。

料金を前払いでお支払いいただいた VMware Cloud on AWS サブスクリプションはすべて、柔軟なサブスクリプションと交換できます。柔軟なサブスクリプションは、別の柔軟なサブスクリプション タイプ、または柔軟でないサブスクリプション タイプと交換することができます。

交換の手続きは VMware Cloud コンソールから開始できます。その後の手順については、サポート チームのメンバーがご案内いたします。

いいえ、交換する場合は、柔軟なサブスクリプションのすべてのホストを交換する必要があります。現時点では、部分的な交換を行うことはできません。

はい。柔軟なサブスクリプションは、料金を前払いでお支払いいただいたあらゆる全期間サブスクリプションと交換できます。

いいえ、受け取ったクレジットは、新規の VMware Cloud on AWS 全期間サブスクリプションのご購入にのみご利用いただけます。

交換は金銭的な契約にのみ影響を与えるものであり、ワークロードに影響はありません。ただし、新しいサブスクリプションでカバーされないワークロードを実行されている場合は、オンデマンド料金が請求される場合があることにご注意ください。

当初ご契約いただいた柔軟なサブスクリプションは終了されます。

いいえ、クレジットでの返金は行われません。残りの金額はすべて、新しいサブスクリプションのご購入に適用されます。

いいえ。サブスクリプションの購入後は、どのパラメーターも変更できません。購入する前に、選択したホストのタイプと数が正しいことを確認してください。ホストの数は、追加のサブスクリプションを購入して、いつでも増やすことができます。

1 年間および 3 年間のサブスクリプションでは、全額前払いか、1 年間および 3 年間の契約期間を通して月単位で料金をお支払いいただきます。

サブスクリプションは、VMware Cloud on AWS コンソールにログイン後、ナビゲーション バーの [サブスクリプション] タブをクリックして作成します。サブスクリプションを作成した後は、ホストを割引価格で購入できます。サブスクリプションは、現在のお客様の支払い方法に対し前払いまたは月単位で課金されますので、ご注意ください。

サブスクリプションが有効になるまでに最大で 30 分ほどかかります。有効になったことはサブスクリプションのステータスでわかります。

いいえ。サブスクリプションは自動更新されません。追加のサブスクリプションはいつでもご購入いただけます。

いいえ。サブスクリプション期間の終了前にキャンセルすることはできません。

いいえ。プロビジョニングはサブスクリプションの購入とは無関係です。サブスクリプションは金銭的な契約です。

いいえ。サブスクリプションを購入した時点で金銭的な契約を結んだことになります。それを最終的にどれだけ利用するかはお客様次第です。

はい。追加のサブスクリプションをご購入いただけます。各サブスクリプションにはそれぞれ独自の開始日と終了日が設定され、調整は行われません。

はい。その場合は超過使用とみなされます。

各リージョンの 1 時間あたりのホスト使用数から、そのリージョンのすべてのサブスクリプションでコミットされたホストの合計数を差し引きます。その結果が超過分です。超過分の料金は、VMware Cloud on AWS の価格表に従ってオンデマンドの料金で請求されます。超過分は後払いで請求され、請求日以降に届く請求書に反映されます。

サイジングおよび評価ツールを使用すると、VMware Cloud on AWS に移行した場合のワークロードのサイジングできます。ストレージ、コンピューティング、メモリ、IOPS など、ロジックに含まれる要素のサイズを指定して、VMware Cloud on AWS のサーバおよび SDDC の最適な構成を調べることができます。ワークロードのサイジングが完了したら、それらのワークロードの総所有コスト（TCO）を計算して、オンプレミスの仮想環境と比較できます。このツールでは、VMware Cloud on AWS の SDDC でワークロードを実行するのに必要となるホストとクラスタの数を計算できます。こちらからご利用いただけます。 

このツールは、認証情報がなくてもアクセスできますが、総所有コスト（TCO）を計算するには、メール アドレスを登録してログインする必要があります。

1 ～ 10 個のワークロード プロファイルを作成して、複数のワークロードが混在する環境をシミュレートできます。このプロセスを簡素化するために、VDI ワークロード、データベース ワークロード、汎用ワークロードなど、一般的なワークロードのワークフローが含まれています。

ツールで入力できる情報に加えて、次のような要素が考慮されます。• CPU：安定状態および障害時の CPU ヘッドルーム • IOPS：ディスク グループあたりの IOPS、I/O プロファイル、I/O の増幅 • キャパシティ：スラック スペース、スワップ領域、重複排除、圧縮、ディスク フォーマット、10 進から 2 進への基数変換 • その他：FTT、N+ = 1、RAID 1、RAID 5、RAID 6

現時点では、i3 および i3en インスタンス タイプに基づいて「Fixed Server」プロファイルが推奨されます。将来的には、VMware Cloud on AWS でサポートされるインスタンスとプロファイルの種類が増えて、環境に最適な種類のプロファイルとインスタンスが推奨されるようになります。

実際の環境では、すべての仮想マシンが同じ使用率で実行されるわけではありません。Resource Utilization Plan では、このことを考慮して、アプリケーションを実行する仮想マシンのグループにそれぞれ異なる使用率を割り当てます。ワークロード プロファイルの [Additional Workload Information] セクションにある [Advanced Settings] タブから Resource Utilization Plan（RUP）を使用することで、オーバーコミットメントの値を変更できます。これらの値を目的の統合度に合わせて変更します。たとえば、クラスタ全体の正味使用率を 80 % にするには、100 % の仮想マシンが 80 % の CPU 使用率で実行されるように値を変更します。

I/O プロファイルは、基盤となる VMware Cloud on AWS のパフォーマンス データに関連付けられています。パフォーマンスを最適化するには、必要な比率にもっとも近い比率を選択します。

Cluster Settings：• CPU Headroom：ワークロード アクティビティが急激に増加した場合に遅延を回避するために予約されるコア数。このオプションを使用すると、障害時だけでなく安定状態時のコア数も予約できます。• Host Failure Scenario：冗長性のための追加のホストが考慮される N+1 のシナリオに相当します。Advanced Settings：• Resource Utilization Plan（RUP）：「Resource Utilization Plan」とそのサイジングへの影響に関する上記の質問を参照してください。

いいえ。ユーザーは、1 年間または 3 年間のサブスクリプション期間中に、VMware Cloud on AWS SDDC のホスト タイプまたは展開するリージョンを変更できません。

全額前払いまたは月単位でのお支払いをお選びいただけます。いずれの方法も、契約期間 1 年間と 3 年間の両方でご利用になれます。

いいえ。サブスクリプションのキャンセルは承りかねます。1 年間または 3 年間の期間満了まで契約をご継続いただくことになります。

営業担当者またはお客様サポート担当者に連絡して、1 年間または 3 年間の契約期間に見合ったクレジットを確保する方法をお問い合わせください。

2,000 ドルは、今後のご利用に対するクレジットとして使用されます。

最初の SDDC を展開すると、2,000 ドルが請求されます。その後の SDDC の展開に対して料金が請求されることはありません。

料金は、My VMware アカウントのプロファイルに設定されている請求先住所に対応する通貨で請求されます。

このクレジットは、VMware Cloud on AWS の利用料金としてのみ使用できます。クレジットは 60 日間で期限切れになり、ほかの VMware Cloud サービスと引き換えることはできません。

いいえ。この料金は払い戻しできません。クレジットの有効期限は、60 日間です。

支払い方法は、CSP ポータルで変更できます。詳細については、こちらをご覧ください。料金は、請求書が生成された時点でデフォルトに設定されていた支払い方法で請求されることに注意してください。

今回、初めて SDDC を展開する場合は、料金が請求されます。

支払い方法がクレジット カードで、初めて SDDC を展開する場合にのみ、料金が請求されます。

いいえ。

サポート チームにご連絡ください。VMware Cloud on AWS コンソールからサポート チームに連絡する方法については、こちらをご覧ください。

個人名義または法人名義の Mastercard、Visa、American Express、Discover、JCB、または Diners Club ブランドのクレジット カードをご利用いただけます。ただし、Discover、JCB、Diners Club は一部の国と地域でのみの対応となります。デビット カードは、Mastercard、Visa、American Express であればご利用いただけます。

クレジットカードは、初期導入中に追加するか、Cloud コンソールから追加できます。

いいえ。VMware ではクレジット カードが有効であることを確認するために検証しますが、検証は 0 ドルのオーソリゼーションを使って行います。

はい、できます。

支払いの最高額は、クレジット カードの利用限度額と決済代行会社によって決まります。1 回の購入で可能な最高額は、25,000 ドルです。クレジット カードの利用限度額については、お使いのクレジット カードを発行した銀行にお問い合わせください。詳細については、こちらをご覧ください。

いいえ。1 年、3 年のサブスクリプションは、クレジット カードでは購入できません。1年または3年のサブスクリプションを購入するために別の支払い方法を使用するか、VMwareのサポートに連絡して例外を要求してください。

販売者とは、組織の請求アカウントです。言い換えると、請求書をお客様に送る会社です。これは、最終消費者に対して個別の製品の登録販売者として特定されている法人または個人を指します。登録販売者は多くの場合、その特定の取引に対する取引税を会計処理する責任を負います。販売者には、その販売者独自の販売特性（販売者に固有の場合も固有でない場合もあります）があります。たとえば、支払い方法、利用規約、サービス カタログ、価格設定、地域、取り扱い通貨、さまざまな請求書テンプレートと請求ビジネス ルールを備えた請求プログラムです。2021 年 3 月時点では、次の販売者を利用できます。VMware と AWS

現在、組織では AWS と VMware の 2 つの販売者を利用できます。新しいサブスクリプションと SDDC を作成するときに、販売者を選択できます。

複数の組織がなくても複数の登録販売者をサポートできます。また、VMware Cloud on AWS SDDC を複数の組織で使用することはおすすめしません。

VMC コンソール内または VMware プロパティのほかの場所で AWS および VMware によってサポートされている VMware 製品のリストは、こちらで入手できます。

これは、2 つの販売者と取引を実行している VMware Cloud on AWS の商用顧客が利用できます。複数の販売者を設定して使用する前にアカウント チームに相談し、必要に応じて製品管理リソースに連絡してもらうようにしてください。

いいえ。それはできません。

いいえ。それはできません。

いいえ。ファンドの追加とサブスクリプションの作成は、2 つの独立した行為です。新しいファンドを追加してもサブスクリプションに変換することはできません。お客様は VMC コンソールでサブスクリプションを作成する必要があります。

いいえ。1 つのサブスクリプションで利用できるホストは、その販売者のホストのみです。例：それぞれ 4 つのホストを持つ 2 つの SDDC があり、1 つは VMware、1 つは AWS で、VMware を販売者とする 4 つのホストには 3 年間のサブスクリプションがあるとします。この場合、AWS を販売者とする 4 つのホストの SDDC は、オンデマンドで課金されます。

いいえ。組織は 2 つの販売者を利用できますが、組織の SDDC 1 つに対し利用できる販売者は 1 つのみです。

この危機的な状況下でお客様を支援するために、VMware はさまざまな事業継続対策ソリューションと特別なサービスを提供しています。詳細についてはこちらをご覧ください。 

VMware Cloud on AWS は、企業がビジネス中断による混乱の可能性を低減するのに次の 3 つの方法で役立ちます。

• インフラストラクチャのサプライ チェーンおよびメンテナンスの中断の回避：世界 17 か所にわたる AWS リージョンで、クラウドのキャパシティをわずか 2 時間で用意でき、突発的なビジネス需要にも対応できます。お客様の要件に従い、必要に応じて数分でインフラストラクチャを拡張できます。
• インフラストラクチャのリスクの低減：VMware Cloud on AWS では VMware Site Recovery により、災害の回避にプロアクティブに対応します。
• リモート ワーカーの支援と移動制限による影響の緩和：VMware Cloud on AWS から Horizon VDI 環境を提供することで、テレワーク環境をサポートします。

VMware は、お客様がこの危機を乗り越えられるように、VMware Cloud on AWS を活用した事業継続対策ソリューションとして、特別プログラムを期間限定で提供しています。ご利用可能なオプションについて VMware の営業担当者にお問い合わせいただくか、エキスパートに相談してください。 

[VMware Cloud on AWSは、ISO 27001、ISO 27017、ISO 27018、SOC 2、HIPAA、PCI-DSS、OSPAR、IRAPを含む多くの主要コンプライアンスプログラムに準拠していることが第三者によって検証されています。詳細については、 VMware Cloud Trust Center をご確認ください（[Services] のフィルタで「VMware Cloud on AWS」を検索してください）。

VMware Cloud on AWS クラウドプラットフォームは、PCI コンプライアンスでレベル 1 のサービス プロバイダーの要件を満たすと評価されています。

PCI SDDC は、次の VMware Cloud on AWS リージョンで利用できます。米国東部（バージニア北部）、米国西部（オレゴン）、米国西部（北カリフォルニア）、米国東部（オハイオ）、欧州（ミラノ）、欧州（ロンドン）、欧州（フランクフルト）、欧州（アイルランド）、アジア パシフィック（シドニー）、アジア パシフィック（東京）、アジア パシフィック（大阪）。

いいえ。ホワイトペーパー『VMware Cloud on AWS への PCI ワークロードの移行』では、責任共有モデルと PCI コンプライアンスとがどのように関連しているかを説明しています。責任は VMware とお客様の間で共有されます。VMware は、VMware Cloud on AWS クラウドサービスとクラウドプラットフォームの PCI コンプライアンスを維持する責任があります。同様に、VMware Cloud on AWS で実行されているお客様のワークロードは、お客様が単独で管理する別個の PCI 評価に合格する必要があります。お客様は、Qualified Security Assessor（QSA：認定審査機関）に依頼して PCI SDDC 構成を評価および検証し、ワークロードが PCI コンプライアンスに準拠していることを確認する必要があります。

バージョン 1.14 以降の SDDC でのみ SDDC をアップグレードできます。新しい PCI 構成の変更はバージョン 1.14 より前の SDDC には適用できず、バージョン 1.14 以降の SDDC の初期プロビジョニング中にのみ有効にできます。新しい SDDC は、新規または既存の PCI 対応組織でプロビジョニングできます。

PCI SDDC には、非順守のサービスが PCI コンプライアンスのステータスに影響を与えるのを防ぐために、次の点で標準 SDDC とは大きく異なります。

• SDDC コンポーネント（vCenter、vSAN、ESXi）は、GovCloud から組み込まれた VMware セキュリティ基準に基づいて「セキュリティの強化」が施されています。NSX の各アプライアンスは NSX セキュリティ強化ガイドラインに従ってセキュリティが強化されています。
• PCI のお客様は、ローカルの NSX Manager を使用して SDDC のネットワークとセキュリティを管理する必要があります。それには、VMC コンソールで [Networking & Security] タブを無効にします。
• お客様は SDDC のセットアップ中に非順守の VMware Cloud on AWS アドオンを使用できますが、PCI 監査人は、VMware HCX および Site Recovery アドオンを無効にする必要があると判断しました（これらのアドオンは現在 PCI コンプライアンスに準拠しておらず、VMC コンソールでお客様の管理者によって無効にしていただく必要があります）。
• vRealize Automation Cloud アドオン サービスも PCI コンプライアンスに準拠していないため、PCI SDDC では機能しません。

いいえ、これらのアドオンは現在 PCI コンプライアンスに準拠していません。 

はい。すべての PCI 構成は SDDC レイヤーで行われ、基盤となる物理ホストから独立しています。

VMware Cloud on AWS の PCI 監査人は Coalfire です。

いいえ。コストの点では、必要なのはベアメタルの VMware Cloud on AWS の公開価格のみです。PCI SDDC の追加料金はかかりません。

VMware は、開発、本番、および PCI ワークロード用に個別の SDDC を導入することをおすすめします。そうすることで PCI 監査範囲を PCI 本番システムに限定し、PCI コンプライアンスの維持に関連するコストを最小限に抑えることができます。

はい。1.14 以降でプロビジョニングされた標準の SDDC のように、標準ライフサイクル プロセスに従い VMware 運用チームによってパッチ適用とアップグレードが自動的に処理されます。

はい。Terraform と API は PCI SDDC の構成に使用できます。

はい。実行できますが、VMC コンソールからは実行できません。VMware サポートにお問い合わせのうえ、リクエストを行うようお願いします。

VMware が機能フラグを介して PCI SDDC を有効にすると、お客様は VMC コンソールで [Networking & Security] タブを無効にできるようになります。このタブを無効にすると、ローカルの NSX Manager の URL と NSX Manager にログインするためのローカル NSX アカウントの認証情報が [Settings] タブに表示されます。

標準の SDDC で利用できるのと同じ接続オプションを使用できます。直接接続、VPN、Connected VPC、およびトランジット接続を選択できます。

お客様は次の手順を実行する必要があります。

• 組織を特定するか、PCI SDDC を作成する新しい組織を作成します
• VMware のサポートでチケットを作成（SRE）して、組織の PCI DSS 機能フラグを有効にするための PM の承認を要求します
• 変更が VMware によって実装されていることを確認します
• 新しい SDDC を展開します
• PCI ワークロードをホストするために SDDC を準備します。オンプレミスへのネットワーク接続を構成します。
• ワークロードの移行
• 管理ゲートウェイ ファイアウォールにルールを作成して、ローカル NSX Manager へのアクセスを有効にし、アクセスが正しく設定されていることを確認します。
• VMC コンソールの [Components Control] セクションを使用して、[Networking & Security] タブを無効にします。
• Site Recovery や HCX コンポーネントが構成されている場合は非アクティブ化します
• VMC コンソールの [Components Control] セクションを使用して、Site Recovery や HCX アドオンを無効にします
• QSA（認定審査機関）を使用してお客様の PCI DSS 監査を完了します
• お客様の QSA が、お客様が PCI DSS コンプライアンスの 仮想マシン、アプリケーション、および本番環境のカード会員データをいつ実行開始できるか確認します。

vCenter のハイブリッド リンク モードや vCenter Cloud Gateway などのハイブリッド ソリューションを含む、VMware Cloud on AWS のすべての機能について、サービス内のチャットによるサポート機能を利用できます。チャットによるサポートは英語で提供され、すべての国/地域から週 5 日、24 時間ご利用いただけます。ただしオンプレミス環境のみのソリューションでは現在ご利用いただけません。

VMCコンソールの左メニューにある「通知設定」をクリックし、受信したい通知を選択してください。選択した内容でよろしければ、「変更を保存」をクリックしてください。

今のところ、これらはユーザーレベルで有効になっています。つまり、通知の設定は各ユーザーの責任で行い、その設定をコントロールできるのは自分だけということです。自分のVMCコンソール内で行った変更は、他のユーザーには影響しません。

通知設定にアクセスするには、関連する組織に所属し、組織オーナーまたは組織ユーザーのいずれかである必要があります。また、次のサービス ロールのいずれかが割り当てられている必要があります。
VMC Admin
NSX Cloud Admin
NSX Cloud Auditor

有効期限がある新しいシングル ホストの SDDC スターター構成により、シングル ホストの VMware Cloud on AWS 環境をご購入いただけるようになりました。有効期限内であれば、データを保持したままホスト数をシームレスにスケールアップできます。有効期限は 60 日です。このシングル ホストのサービスは、VMware Cloud on AWS の価値を実際の環境で確かめたいというお客様のために低価格での導入を実現するものです。

シングル ホストの SDDC はオンデマンドのみの提供で、料金は 7 ドル/ホスト/時間です（米国市場での参考価格）。最新の料金については料金のページでご確認ください。

シングル ホスト SDDC は、現在 VMware Cloud on AWS が利用可能なすべてのリージョンで利用できます。

オンプレミスと VMware Cloud on AWS の間のハイブリッド運用など、複数のホストを必要としない機能が含まれています。複数のホストを必要とする操作や機能はご利用いただけません。たとえば、高可用性（HA）、2 つの AWS アベイラビリティ ゾーンにわたるストレッチ クラスタなどがこれに当たります。シングル ホストの SDDC は、その性質上 FTT=0 であるため、ホストで障害が発生するとデータが失われます。また、現時点では、シングル ホストの SDDC にはパッチやアップグレードは提供されていません。シングル ホストの SDDC の主な特長は次のとおりです。• 迅速な導入。 • オンプレミスと VMware Cloud on AWS の間の移行機能：大規模な移行を迅速化する VMware HCX、ライブ マイグレーションを実現する VMware vMotion、およびコールド マイグレーション。• AWS のネイティブ サービスへの広帯域、低遅延のシームレスなアクセス。 • ディザスタ リカバリ：VMware Cloud on AWS に最適化されたクラウドベースのディザスタ リカバリ サービス、VMware Site Recovery の評価。VMware Site Recovery は、アドオン サービスとして仮想マシン単位で別途ご購入いただけます。• 卓越したサポート：シングル ホストの SDDC でも、24 時間 365 日、回数無制限の VMware グローバル サポート サービスと、週 5 日 24 時間のライブ チャット サポートをご利用いただけます。 • ハイブリッド リンク モードのサポート：オンプレミスと VMware Cloud on AWS のリソースを単一の論理ビューで表示できます。 • オールフラッシュ vSAN ストレージ：オールフラッシュ vSAN 構成（キャッシュとキャパシティの両方にフラッシュを使用）によってストレージのパフォーマンスが最大化されます。

もちろんです。詳細については、Partner Central を参照してください。Technology Alliance Partner である場合は、下にスクロールして、この FAQ の「サードパーティ製テクノロジー ソリューション」のセクションを参照してください。

一度にプロビジョニングできるシングル ホストの SDDC は 1 つだけです。一部のパートナー様は、一度に 2 つまでプロビジョニングできます。

シングル ホストの SDDC は 60 日後に削除されます。SDDC 上のデータもすべて失われます。シングル ホストの SDDC からホスト 2 台の SDDC にスケールアップする場合、すべてのデータが保持されます。ホスト 2 台の SDDC には有効期限はありません。

いいえ。ただし、シングル ホストの SDDC の制限内であれば、新しいシングル ホストの SDDC を作成できます。

はい。シングル ホスト SDDC は、いつでも中断なしで 2 ホスト SDDC にスケールアップできます。

はい。

[Scale Up] ボタンをクリックするだけで、標準の本番環境 SDDC サービスに拡張できます。データもそのまま保持されます。営業部門にお問い合わせいただく場合はチャット サービスをご利用ください。

シングル ホスト SDDC のアカウント リンクは最大 14 日間延期できますが、AWS アカウントに接続していない状態では、シングル ホスト SDDC を 4 ホスト構成にスケール アップすることはできません。

いいえ。シングル ホストの SDDC はシングル ホストとして作成する必要があります。ホスト 2 台の SDDC からシングル ホストの SDDC にスケール ダウンすることはできません。

シングル ホストの SDDC でも、24 時間 365 日、回数無制限の VMware グローバル サポート サービスをご利用いただけます。また、VMware Cloud on AWS コンソールおよび vSphere Client から、週 5 日 24 時間のライブ チャット サポートをご利用いただけます。

シングル ホストの SDDC では、SLA は提供されません。コンポーネントやホストで障害が発生すると、データが失われる可能性があります。

本サービスでは 3 種類の支払い方法をご利用いただけます。クレジット カードでのお支払い、請求書でのお支払い、あるいは Subscription Purchasing Program（SPP）や Hybrid Purchasing Program（HPP）のクレジットを購入してそれらのクレジットを本サービスに利用するという方法から選択できます。

2 ホスト クラスタの機能を利用すると、2 台のホストだけで VMware Cloud on AWS に永続的な本番クラスタをプロビジョニングできます。以前は、VMware Cloud on AWS で永続的なクラスタを稼働させるには 3 台のホストが必要でした。ワークロードが少ないために 3 台のホストで構成される本番クラスタを必要としないお客様、またはシングル ホストの SDDC で利用可能な期間よりも長く VMware Cloud on AWS の価値を実証したいと思われるお客様には、2 ホスト クラスタが適しています。

ホスト 1 台あたりのコストは、3 台以上のホストで構成されるクラスタと同じです。つまり、1 つのクラスタで考えると、2 ホスト クラスタでは、33% 安いコストで永続的な本番環境の利用を開始できます。

はい。既存の SDDC 内のセカンダリ 2 ホスト クラスタで、カスタムのコア数を使用できます。

2 ホスト クラスタは、現在、Amazon EC2 i3.metal インスタンス タイプの VMware Cloud on AWS を利用できる、すべての AWS リージョンで提供されています。ただし、AWS GovCloud（米国西部）は除きます。VMware Cloud on AWS が利用可能な地域の詳細については、FAQ を参照してください。

2 ホスト クラスタに含まれる機能は、3 台以上のホストで構成される本番環境の SDDC と同じです。ただし、Elastic DRS ポリシーの最適化（コストの最適化、パフォーマンスおよび短期間のスケールアウトについての最適化）とストレッチ クラスタは含まれません。

プロビジョニングできる 2 ホスト クラスタの数に制限はありません。2 ホスト クラスタと 3 台以上のホストを含むクラスタの混在は可能です。ただし、2 ホスト クラスタを含む SDDC とシングル ホスト SDDC を混在させることはできません。

はい、可能です。2 ホスト クラスタの有効期限に制限はありません。

2 ホスト クラスタでは、24 時間 365 日、回数無制限の VMware グローバル サポート サービスをご利用いただけます。また、VMware Cloud on AWS コンソールおよび vSphere Client から、週 5 日 24 時間のライブ チャット サポートをご利用いただけます。

2 ホスト クラスタ サイズは、それが利用可能なすべての場所で本番環境対応になっています。また、SLA は、3 台以上のホストを含むクラスタ サイズと同じです。現在の SLA の要件は、こちらを参照してください。

はい。2 ホスト クラスタでは、デフォルトの Elastic DRS ポリシーだけでなく、手動によるスケール アップも利用可能です。

はい。3ホストのProduction SDDCは、2ホストのクラスタにスケールダウンすることが可能です。

はい、できます。DRaaS は、2 台以上のホストを含むすべての SDDC で有効です。

はい。2 ホスト クラスタでは Horizon VDI ワークロードがサポートされます。サイジングに関する具体的な質問については、VMC Sizer ツールを参照してください。

いいえ。現時点では、2 ホスト クラスタでストレッチ クラスタを使用することはできません。

いいえ。現在利用できるのは、デフォルトのストレージ EDRS ポリシーだけです。

2 ホスト クラスタは、ほかの SDDC と同じ方法で購入することができ、シングル ホスト SDDC や ホスト 3 台の SDDC と同様に、数時間で稼働を開始できます。プロビジョニングした 2 ホスト クラスタは、ホスト 3 台の SDDC にわずか数分でスケール アップできます。

はい、できます。クレジット カードをご利用の場合は、複数の SDDC を作成することも、2 ホスト クラスタまたは 3 ホスト クラスタの SDDC を追加することもできません。クレジット カードによるお支払いの詳細については、FAQ の「クレジット カードでのお支払い」セクションを参照してください。

はい、MSP は、2 ホストのクラスタ サイズを利用できます。MSP が管理する組織の SLA は、MSP とテナント間の特定の条件に従い、VMware の SLA による制約は受けません。

プレビュー版でプロビジョニングされていたすべての 2 ホスト クラスタ SDDC は、SLA のフル サポートの対象になります。お客様が変更の手続きをしていただく必要はありません。すべて VMware で対応いたします。プレビュー版は、ほかの 2 ホスト SDDC と同等になりました。

2 ノード クラスタはほかの構成と同じ数の仮想マシンをホストごとにサポートしますが、アドミッション コントロールにより、2 ノード クラスタで一度に使用できるワークロード仮想マシンは 36 以下です。これは、障害が発生した場合に vSphere HA が実行中のワークロードを再起動できるようにするためです。

VMware Cloud Disaster Recovery に関する詳細な FAQ はこちらをご覧ください。 

VMware Site Recovery は、レプリケーション、オーケストレーション、自動化の信頼性に優れたテクノロジーを VMware Cloud on AWS で利用できるようにするサービスです。これにより、サイトで障害が発生した場合でもアプリケーションを保護できます。このサービスは、VMware Site Recovery Manager™ と、VMware vSphere® Replication™ によるハイパーバイザーベースのネイティブ レプリケーションなど、業界をリードするリカバリ プラン自動化ソリューションを基盤としています。このサービスにより、エンドツーエンドのディザスタ リカバリ ソリューションが提供され、セカンダリ リカバリ サイトの要件の削減、保護までの時間の短縮、ディザスタ リカバリの運用の簡素化が実現されます。

AWS GovCloud（米国）リージョンを含む、VMware Cloud on AWS が利用可能なすべてのリージョンでご利用いただけます。

VMware Site Recovery は、オンプレミスのデータセンターで実行されているワークロードの VMware Cloud on AWS の SDDC による保護、VMware Cloud on AWS の SDDC で実行されているワークロードのオンプレミスのデータセンターによる保護、VMware Cloud on AWS の異なる SDDC 間の保護に対応しています。

VMware Site Recovery を導入するにあたり、ペアリングされたオンプレミス データセンターに必要な vCenter のバージョンは、そのオンプレミス データセンターに展開されている Site Recovery Manager と vSphere Replication のバージョンによって異なります。VMware vCenter Server と Site Recovery Manager の間の VMware 製品の相互運用性マトリックスを使えば、ペアリングされたオンプレミス データセンターに展開されている Site Recovery Manager のバージョンから、必要とされる vCenter の最小バージョンがわかります。同様に、こちらの VMware vCenter Server と vSphere Replication の間の VMware 製品の相互運用性マトリックスを使えば、ペアリングされたオンプレミス データセンターに展開されている vSphere Replication のバージョンに基づいて必要とされる vCenter の最小バージョンがわかります。たとえば、ペアリングされたオンプレミス データセンターに現在展開されている Site Recovery Manager と vSphere Replication のバージョンが 8.2 の場合、VMware 製品の相互運用性マトリックスに基づいて、サポートされる vCenter の最小バージョンは 6.0 U3 であることがわかります。なお、次の FAQ で説明するように、ペアリングされたオンプレミス データセンターの Site Recovery Manager と vSphere Replication の最小バージョンは、VMware Cloud on AWS SDDC 上の VMware Site Recovery の Site Recovery Manager および vSphere Replication コンポーネントの 1 バージョン前となります。

いいえ。VMware Site Recovery は、オンプレミスのデータセンターでお客様が展開しているコンポーネントと VMware Cloud on AWS で VMware が展開および管理しているコンポーネントのバージョンの違いに柔軟に対応するように設計されています。ペアリングされたオンプレミス データセンターでは、1 バージョン前までの Site Recovery Manager および vSphere Replication がサポートされます。たとえば、VMware Site Recovery の現バージョンが 8.3 である場合、ペアリングされたオンプレミス データセンターでは、バージョン 8.2 以降の Site Recovery Manager および vSphere Replication を使用できます。

はい。ディスク サイズをシームレスに変更する新機能を利用するには、オンプレミス データセンターに vSphere バージョン 7.0 以降と vSphere Replication バージョン 8.3 以降を展開する必要があります。

VMware Site Recovery は VMware Cloud on AWS のインフラストラクチャ スタックでのみご利用いただけます。

VMware Site Recovery は独立したアドオン サービスで、VMware Cloud on AWS とは別に料金が請求されます。最新の料金については料金のページでご確認ください。VMware Site Recovery の標準価格には、VMware Cloud on AWS SDDC インスタンスとオンプレミス データセンターの両方に対応する vSphere Replication コンポーネントと Site Recovery Manager コンポーネントが含まれます。サポートも価格に含まれています。

いいえ。VMware Site Recovery サービスは、別途料金が発生し、別のライセンスが必要となるソリューションです。最新の料金については料金のページでご確認ください。

はい。シングル ホストの SDDC スターター構成でも VMware Site Recovery のすべての機能を別売りのアドオンとしてご利用いただけます。これにより、ハイブリッド クラウドのディザスタ リカバリ ソリューションを低コストで開始できます。ただし、シングル ホストの SDDC サービスには有効期限があり、データの耐久性も低いため、すべてのオンプレミス ワークロードのメインのディザスタ リカバリ ソリューションとして使用するのは、ホスト 3 台の SDDC にスケールアップしてからにすることをおすすめします。

NSX-v SDDC で利用可能な VMware Site Recovery のすべての機能は、Firewall Rule Accelerator を除いて、NSX-T SDDC でも使用できます。NSX-T SDDC で VMware Site Recovery を使用するために必要なファイアウォール ルールを構成するには、こちらのドキュメントに記載されている手順に従ってください。VMware Site Recovery の一般的な注意事項、制限事項、および既知の問題については、『VMware Site Recovery リリース ノート』を参照してください。特に指定がない限り、これらの内容は NSX-v SDDC と NSX-T SDDC の両方に適用されます。

VMware Cloud on AWS 内の NSX-T SDDC 上の VMware Site Recovery とオンプレミス データセンターを組み合わせるには、オンプレミス データセンターを NSX-T に対応した Site Recovery Manager 8.1.2 にアップグレードする必要があります。または、オンプレミス データセンターで以前のバージョンの Site Recovery Manager を使用する場合は、NSX-v を導入するか、NSX を未導入にする必要があります。VMware Site Recovery Manager は、バージョン 8.1.2 からオンプレミス環境の NSX-T との相互運用がサポートされています。詳細については、『VMware Site Recovery Manager 8.1.2 リリース ノート』をご覧ください。

1 つまたは複数のオンプレミス サイトとの間でレプリケーションを行う際に、受信および送信レプリケーションの合計数が 500 を超える場合は、各サイトに最低 1 台の vSphere Replication Server を追加導入する必要があります。これらの追加コンポーネントの導入方法については、VMware Site Recovery のドキュメントを参照してください。追加した vSphere Replication Server との間の受信/送信トラフィックを許可するには、オンプレミス ファイアウォールの構成も変更する必要があります。一方、VMware Cloud on AWS SDDC との間で 500 を超える仮想マシンをレプリケーションする場合には、追加のコンポーネントをインストールまたは構成する必要はありません。VMware Cloud on AWS SDDC のレプリケーション数がデフォルトの特定のしきい値に達した場合、VMware Site Recovery サービスは自動的に新しい vSphere Replication Server を SDDC に追加し、新しいサーバに SDDC の既存の vSphere Replication ファイアウォール構成をシームレスに拡張します。

VMware Site Recovery をファンイン、ファンアウト、またはほかの複雑なトポロジーのマルチサイト構成で使用する場合でも、追加料金はかかりません。VMware Site Recovery を使用して保護するすべての仮想マシンに対して標準価格が適用されます。

はい。この構成はサポートされます。サポートされるさまざまな構成のタイプと、このようなマルチサイト トポロジーの展開手順の詳細については、VMware Site Recovery のドキュメントを参照してください。  

次のいずれかの方法で、新しい VMware Site Recovery の期限付きサブスクリプションを購入できます。

• セルフサービス：VMware Cloud コンソールの [Add-Ons] タブから
• セールス担当者による通常の見積もりと注文プロセスを使用する

VMware Site Recovery の期限付きサブスクリプション 1 件につき、1 ～ 10,000 台の間で任意の数の仮想マシンを購入できます。

• VMware Site Recovery の期限付きサブスクリプションは、VMware Cloud on AWS リージョンごとに固有となります。VMware Cloud on AWS 上の 2 つの異なるディザスタ リカバリ サイトでワークロードを保護する場合、VMware Site Recovery の期限付きサブスクリプションは VMware Cloud on AWS のリージョンごとに個別に必要となります。

• ディザスタ リカバリによる保護を VMware Cloud on AWS の 2 つの SDDC 間で行う場合、期限付きサブスクリプションはリカバリ用 SDDC を配置する予定のリージョンに 1 件購入するだけで構いません。

はい。次のいずれかの場合には請求が発生します。

• 最終の月払い請求から VMware Site Recovery 期間限定サブスクリプションが始まるまでの期間に発生した VMware Site Recovery オンデマンド利用分については、該当するオンデマンド料金で請求が行われます。これはお客様の組織の請求日（ABD）によって異なります。
• VMware Site Recovery 期間限定サブスクリプションで購入した数を超える仮想マシンを保護した場合、超過分の仮想マシンについては VMware Site Recovery オンデマンド料金で請求が行われます。
• VMware Site Recovery の期限付きサブスクリプションを 1 件購入して VMware Cloud on AWS の 2 つの SDDC 間でディザスタ リカバリ保護を行い、その後（たとえば再保護ワークフローの結果として）ディザスタ リカバリ保護の方向を変更した場合、再保護される仮想マシンについては、ターゲットの VMware Cloud on AWS リージョンに適用されるオンデマンド料金が課せられます。

現在、2 つの期限付きサブスクリプションはそれぞれ独立しています。VMware Site Recovery はアドオンであるため、使用するには VMware Cloud ホストが必要です。ホストのサブスクリプション期間が VMware Site Recovery のサブスクリプション期間よりも前に終了し、それ以降もワークロードの保護を希望する場合は、ホストのサブスクリプションを新たにご購入いただくか、ホストの使用についてオンデマンド料金でお支払いいただく必要があります。

いいえ。VMware Cloud on AWS ホストのサブスクリプションと VMware Site Recovery のサブスクリプションは、それぞれ独立しています。

VMware vSphere® vMotion® を使用すると、オンプレミスのホストから VMware Cloud on AWS のホストに実行中の（パワーオン状態の）仮想マシンを移行できます（ライブ マイグレーション）。アプリケーションのダウンタイムはゼロで（切り替え時間は 1 秒未満）、サービスの利用が中断されることもなく、トランザクションの完全な整合性が維持されます。この機能を VMware Cloud on AWS でご利用いただけるようになりました。さらに、特定の高度な構成を有効にすると、さまざまな vSphere Distributed Switch のバージョンで vMotion を有効化できます。要件は次のとおりです。• AWS Direct Connect（プライベート仮想インターフェイス経由）と NSX レイヤー 2 VPN を設定する必要があります。これらがないとサポートされません。• オンプレミスの vSphere のバージョンは 6.0 U3 以上である必要があります。• 250 Mbps 以上の持続帯域幅が必要です（最適なパフォーマンスのため）。• vSphere Distributed Switch バージョン 5.0/5.5 はサポートされません。また、5.0/5.5 でホストされている仮想マシンの移行はブロックされます。要件の詳細については、こちらを参照してください。

1 台の仮想マシンの vMotion：• UI：HTML5 クライアントから vMotion をオーケストレーションするにはハイブリッド リンク モードを設定する必要があります。• PowerCLI：PowerCLI から直接 API で操作できます。バルク vMotion：• UI：VMware HCX によって UI からのバルク マイグレーションが実現されます。• PowerCLI：バルク マイグレーションのシナリオを実現するサンプル スクリプトがこちらにあります。

はい。スナップショットがある仮想マシンを vSphere 6.5(d) との間で vMotion によって移行すると失敗します。6.5 U1 にアップデートしてこの問題を解決するか、スナップショットを削除してください。

はい。暗号化された vMotion は標準でサポートされています。オンプレミス環境ですでにサポートされていれば、新たな設定は必要ありません。

はい。オンプレミスのホストに互換性があれば、VMware Cloud on AWS からオンプレミスへの vMotion も実行できます。Enhanced vMotion Compatibility（EVC）モードはクラスタ間では機能しないため、VMware Cloud on AWS で仮想マシンが再起動されて、VMware Cloud on AWS の新しいハードウェア バージョンで実行される可能性があります。このようなシナリオでは、オンプレミスのホストのバージョンが古いため、ライブ マイグレーションがサポートされなくなる場合があります。

VMware Cloud on AWS では EVC は無効になっています。VMware Cloud on AWS のホストはすべて同じ構成であるため、互換性チェックは必要ありません。

その名のとおり、仮想マシン単位の EVC では、この設定がクラスタから仮想マシンのレベルに抽象化されています。これにより、仮想マシンが再起動されても EVC モードが維持されるようになりました。

仮想マシン単位の EVC にはハードウェア バージョン 14 が必要です。さらに、この機能を有効にするには仮想マシンの電源を切る必要があります。

両方でご利用いただけます。仮想マシンごとの編集設定属性を変更して特定の EVC モードを設定することも、スクリプトで API を使用して複数の仮想マシンで自動的に設定することもできます。

VMware Cloud on AWS ではクラスタの EVC は無効になっています。設定できるのは仮想マシン単位の EVC のみです。

はい。現時点では、VMware Cloud on AWS のホストはすべて同じ構成です。仮想マシン単位の EVC 設定は、VMware Cloud on AWS からオンプレミスに戻すときに互換性の問題が起こらないようにするために使用されます。

VMware HCX（旧称 Hybrid Cloud Extension および NSX Hybrid Connect）とは、オンプレミスとクラウドのさまざまな vSphere のバージョンにおいて、アプリケーションの可搬性とインフラストラクチャのハイブリッド化を提供する SaaS 製品です。詳しくはこちら

VMware HCX サービスには、あらゆる vSphere バージョンの間でアプリケーション環境の双方向モビリティとデータセンターの拡張を行う機能があります。VMware HCX には、vMotion、バルク マイグレーション、高スループット ネットワーク拡張、WAN 最適化、トラフィック エンジニアリング、ロードバランシング、強力な Suite B 暗号化機能を備えた自動化 VPN、ハイブリッド抽象化およびハイブリッド相互接続が組み込まれたセキュアなデータセンター相互接続が含まれています。VMware HCX を利用すれば、ソースのインフラストラクチャを改良することなくクラウドを導入できます。また、アプリケーションをリスクにさらしたり、複雑な移行評価を行ったりすることなく、vSphere 5.0 以上から VMware Cloud on AWS への移行がサポートされます。詳しくはこちら

VMware HCX は、vSphere ベースのオンプレミス リソースとクラウド リソースを抽象化してインフラストラクチャのハイブリッド化を行い、1 つの連続的なリソースとしてアプリケーションに提供します。このハイブリッド化の核となるのは、高スループットで WAN 向けに最適化され、ロードバランシングやトラフィック エンジニアリングに対応した、暗号化されたセキュアな相互接続によるネットワーク拡張です。これにより、アプリケーションの可搬性をはじめとしたハイブリッド サービスをサポートできます。アプリケーションはその下のハードウェアやソフトウェアにしばられることなく、インフラストラクチャのハイブリッド化のどこにあるかも意識することがなくなります。詳しくはこちら

たとえば、オンプレミス データセンターのクラウドへの拡張、SDDC の変革、仮想マシンのライブ/バルク マイグレーション、アプリケーション環境の透過性とアプリケーション コンポーネントの分散のための継続的なハイブリッド化などの用途があります。詳しくはこちら

はい。VMware HCX はマルチサイト相互接続をサポートしています。たとえば、小規模なデータセンターの VMware Cloud on AWS への統合、地理的に異なる場所にある複数の VMware Cloud on AWS への拡張などのユースケースがあります。詳しくはこちら

VMware HCX は、NSX-V SDDC および NSX-T SDDC のすべての機能をサポートしています。NSX-T SDDC では、VMware HCX との相互接続に AWS Direct Connect プライベート仮想インターフェイス オプションを利用することもできます。インターネットをご利用中で、HCX 相互接続をプライベート仮想インターフェイス オプションに移行することをご要望の場合は、VMware にお問い合わせのうえ、相互接続構成の切り替えに関する支援を受けてください。

ターゲット環境が HCX 対応のパブリッククラウドである場合、不要です。ターゲットがプライベートまたはオンプレミスの vSphere 環境である場合、NSX が必要になります。また、ソース環境に NSX をインストールして、NSX 論理スイッチのネットワーク拡張機能を利用することもできます。

VMware HCX の料金は、VMware Cloud on AWS のすべての SDDC 構成に含まれています。

VMware HCX は 2017 年 12 月に提供が開始されました。現在、このサービスは VMware Cloud on AWS のサブスクリプションに含まれています。有効化するには、VMware Cloud Services ポータル（https://cloud.vmware.com）にログインして、VMware Cloud on AWS の SDDC で HCX を有効にします。VMware HCX は vSphere Web Client に統合されているため、同じ管理環境で日常的な運用を行うことができます。

Cloud Motion with vSphere Replication とは、オンプレミスから VMware on AWS へのワークロードの大規模移行を実現する、新しい革新的な方法です。Cloud Motion with vSphere Replication では、ダウンタイムなし（ライブ）で仮想マシンを大規模に移行できます。

従来は、HCX を使用した移行の方法が 2 つありました。1. vMotion ベース：vMotion ベースの移行はライブ（ダウンタイムなし）ですが、その性質上、逐次です。vSphere の同時実行数とクロスクラウドの制約から、一度に vMotion で移行できる仮想マシンはあまり多くありません。vMotion はライブ マイグレーション オプションであるものの、大規模な移動はサポートしていません。2.ウォーム マイグレーション：ウォーム マイグレーションは仮想マシンを大規模に移動させることができる大規模移行ですが、この移行では仮想マシンを再起動する必要があります。Cloud Motion with vSphere Replication は、両方の長所を兼ね備えています。仮想マシンはレプリケーション テクノロジーを使用して移行先にレプリケーションされます。仮想マシンがレプリケーションされると、最終移行が vMotion を介して行われます。これにより、再起動することなく大規模移行を実現できます。この機能によって、再起動したり再読み込みしたりすることなく、アプリケーションをライブで大規模に移動させることができます。

vSphere Replication を使用したクラウドへの移行では、3 つの方法で移行の計画と作業を簡素化します。• 従来は、アプリケーションを再起動するメンテナンス時間を計画する必要がありました。メンテナンス時間は管理と維持を行う非常に退屈な作業で、アプリケーションの再読み込み/再起動に対応するときはさらに複雑になります。クラウドへの移行では、メンテナンス時間を一切スケジューリングすることなく、移行元から VMware Cloud on AWS に大規模に移行を行えます。• Cloud Motion では、詳細な分析、依存関係マッピング、時間のかかる移行計画プロジェクトが不要になります。• Cloud Motion では、お客様がフェイルオーバーをスケジューリングします。そのため、アプリケーションがいつ移行されるか予測できます。vMotion の場合、仮想マシンは vMotion 関連の処理が終わった時点ですぐに移行されるため、予測性がありません。大規模なライブ マイグレーションと予測可能なスケジュールを組み合わせることで、移行プロセスの計画と実行のパラダイム シフトがもたらされます。

この機能では、vSphere バージョン 5.5 以降のオンプレミスが必要です。

詳細については、こちらをご覧ください。VMware HCX のハンズオン ラボをご利用ください。

Migration Assessment を使用すると、クラウド管理者は、プライベート クラウドから VMware Cloud on AWS へのワークロードの移行に必要なキャパシティとコストを計算することができます。

VMware Cloud on AWS のお客様は、CSP コンソールから、Cost Insight 経由で Migration Assessment にアクセスできます。Cost Insight のアクティベーションを別途行う必要はありません。

VMware vRealize Network Insight Cloud と Migration Assessment との連携はオプションです。この連携により、アプリケーションの依存関係を可視化し、アプリケーションを VMware Cloud on AWS に移行した場合のコストの推定額を提示します。そのため、より効果的な移行計画の作成に役立ちます。

VMware Cloud on AWS Migration では、手順ごとに詳細な説明が提供され、オンプレミスから VMware Cloud on AWS への移行をサポートします。移行プロセスは、計画、構築、移行の 3 つの段階に分かれています。各段階はさらに個別のステップに分割され、各ステップに関連するドキュメントとツールへのリンクが記載されています。3 つの段階がすべて終了すると、SDDC が作成され、ワークロードがオンプレミスのインフラストラクチャからクラウドに移行されます。

VMware Cloud on AWS Migration は、無償でご利用いただけます。VMware Cloud on AWS Migration は、お客様がオンプレミスのデータセンターから VMware Cloud on AWS にワークロードを移行するプロセスを段階を追って支援するガイドです。お客様がクラウド環境を構築するために使用するツールとインフラストラクチャには、別途、料金が発生します。

いいえ。VMware Cloud on AWS Migration は、VMware Cloud on AWS へのワークロードの移行に関する情報を集約し、情報とツールの中心となるハブを作成します。VMware Cloud on AWS Migration は、移行プロセスを簡略化し、時間を節約することを目的としていますが、VMware Cloud on AWS への移行に使用する必要はありません。

いいえ。VMware Cloud on AWS Migration は、だれでも利用可能です。VMware Cloud on AWS にログインする必要はなく、VMware Cloud on AWS アカウントも不要です。ただし、移行の進捗状況を確認するには、ログインが必要です。また、SDDC の作成に必要なステップを実行するには、VMware Cloud on AWS の組織を作成し、ログインする必要があります。

プライベート IP アドレスへの解決は、VPN または Direct Connect（DX）経由で HCX Manager に接続する場合に便利です。

手順については、VMware Cloud on AWS のドキュメントを参照してください。 

いいえ。ESXi はベアメタル AWS のインフラストラクチャ上で直接実行されるため、ネストされた仮想化環境はありません。

仮想マシンを導入するにはいくつかの方法があります。1 つ目の方法では、オンプレミスのコンテンツ ライブラリを VMware Cloud on AWS の SDDC に公開して（VMware Cloud on AWS の SDDC が参照インスタンスとして関連付けられます）、コンテンツをすぐに同期するか、オンデマンドで同期します。2 つ目の方法では、VMware Cloud on AWS の SDDC にローカル コンテンツ ライブラリを作成して、使用する ISO や OVA をそのリポジトリにアップロードします。3 つ目の方法では、テンプレートをインポートし、PowerCLI を使用して新しい仮想マシンを一括で作成します。4 つ目の方法では、オンプレミスの vCenter Server から VMware Cloud on AWS の SDDC に仮想マシンを個別に移行するために、仮想マシンをパワーオフした状態でコールド マイグレーションを実行するか、実行中の仮想マシンを vMotion で移行することができます。

仮想マシン テンプレートは、仮想マシン コンテンツの管理の一貫性および簡素化を実現します。仮想マシン テンプレートをコンテンツ ライブラリに追加したり削除したりできるほか、名前の変更、[Notes] の更新、新しい仮想マシンの作成などを行うこともできます。• コンテンツ ライブラリにテンプレートを作成または追加するには、仮想マシンを選択し、[Clone] をクリックして、クローンを仮想マシン テンプレートとしてライブラリに追加するオプションを選択します。注：ライブラリはローカル ライブラリでなければなりません（公開ライブラリは不可）。• コンテンツ ライブラリの仮想マシン テンプレートから仮想マシンを作成するには、仮想マシン テンプレートを選択し、[New VM from this Template] をクリックして、ウィザードの手順に従います。このウィザードは、コンテンツ ライブラリ以外の場所で使用する OVF テンプレートのウィザードに似ています。

仮想マシン テンプレートを公開ライブラリに追加することはできません。仮想マシン テンプレートではまだ公開ライブラリと購読済みライブラリの同期（データ配信）がサポートされていないためです。また、コンテンツ ライブラリで仮想マシン テンプレートを仮想マシンに変換することもできません。ただし、すべての機能を含む同じテンプレートを vCenter Server インベントリ/フォルダで使用できます。

VMware Cloud on AWS で作成できる最小サイズの SDDC は、シングル ホスト SDDC の 1 ホストです。ただし、1 ホスト SDDC には制限付きのサービス レベル アグリーメント（SLA）があり、本番環境には使用できません。サポートされている最小の本番環境 SDDC は 3 ホストです。シングル ホストの SDDC スターター構成を使用すると、シングル ホストの SDDC 環境を構築できます。詳細については、この FAQ の「シングル ホストの SDDC」のセクションを参照してください。

はい。3 ホストのみのため、「RAID 5」SPBM ポリシーを実装することはできません。RAID 5 には最低 4 ホストが必要です。選択できるストレージの冗長性は RAID 1 のみです。

いいえ。シングル ホストとは異なり、3 ホスト SDDC はフル機能の本番環境 SDDC です。ほかの本番環境 SDDC と同様に、ホストを追加するだけでスケール アップできます。

はい。ストレッチ クラスタでないすべてのクラスタでは、3 ホストのクラスタ サイズが最小です。

クラスタの最大サイズは ESXi ホスト 16 台です。

はい。必要に応じてホストを追加できます。ESXi ホストは最小構成の 3 台までなら、必要に応じて削除することもできます。

マルチクラスタ サポートとは、SDDC 管理者が既存の SDDC にクラスタを追加できる機能です。SDDC に複数のクラスタを作成して、共通の管理仮想マシンとネットワークを共有することができます。

VMware Cloud on AWS でサポートされているクラスタの最大数は、SDDC あたり 20 個です。これより低い「ソフト」リミットが設定されている場合もあります。この制限の引き上げをご希望の場合は、カスタマー サクセス チームまでお問い合わせください。

新しいクラスタのプロビジョニングが完了したら、オンプレミスで仮想マシンを移動する場合と同じように、vCenter からコールド マイグレーションまたは vMotion を使用してそのクラスタに仮想マシンを移動できます。

いいえ。削除できるのは追加のクラスタだけです。SDDC にはクラスタが 1 つ必要で、そのクラスタは、SDDC の作成時に展開された最初のクラスタである必要があります。

はい。現在のホストと同じように、クラスタを SDDC に追加したり SDDC から削除したりできます。

VMware Cloud on AWS では、複数の SDDC をプロビジョニングして複数の AWS アカウントに接続できます。

はい。VMware Cloud on AWS が利用可能などのリージョンにも配置できます。

VMware Cloud on AWS] 。SDDCはAWSのアカウントに接続されている必要があります。シングル ホスト SDDC のアカウント リンクは最大 14 日間延期できますが、AWS アカウントに接続していない状態では、シングル ホスト SDDC を 4 ホスト構成にスケール アップすることはできません。

AWS アカウントに接続すると、SDDC と AWS リソース間で広帯域、低遅延の固有の接続が作成され、クロス AZ の料金がかからずに AWS のサービスを利用できます。アカウント リンクを延期すると、SDDC を展開するアベイラビリティ ゾーン（AZ）を選択することができません。

SDDC の作成時に、SDDC の作成の手順 1 で [Choose an AWS Account] ドロップダウンから [Connect to a New AWS Account] を選択します。

現在サポートされていません。

SDDC の作成時に、新たに利用可能になったリージョンを選択してください。非常にシンプルです。新たに利用可能になったリージョンでも、既存のリージョンと同様の方法で SDDC をプロビジョニングできます。リージョンの選択メニューに新しいリージョンのオプションが追加されています。新しいリージョンに作成した SDDC は、ほかの SDDC とともにダッシュボードに表示されます。さらに、異なるリージョンの SDDC を含めることもできます。

SPP クレジットまたは HPP クレジットのファンドか、クレジット カードをご利用いただけます。

いいえ。SDDC が配置されているリージョンに関係なく、同じエンドポイントを使用して VMware Cloud on AWS API やコンソールにアクセスできます。

VMware Cloud on AWS で実行されているバージョンは、クラウド運用に最適化されていて、標準の vSphere リリースとの互換性も確保されています。アップデートの頻度が通常より高くなることがありますが、これは、定期的なサービスの強化を反映するためです。

基盤となるインフラストラクチャ コンポーネントのバージョンをお客様が選択できるようにする予定はありません。この一貫性によって大規模運用が実現されています。

VMware Cloud on AWS では、ネストされた ESXi 仮想マシンの実行はサポートされていません。

はい。ハイブリッド リンク モードを使用すると、VMware Cloud on AWS で実行されている vCenter Server をオンプレミスの vCenter Server に接続して、クラウドとオンプレミスの両方のリソースを 1 つのインベントリ ビューに表示できます。

コンピューティング ポリシーとは、ビジネスの需要に対応し続けるために必要な柔軟性、制御、ポリシーベースの自動化を実現できる新しいフレームワークです。次のポリシーが導入されています。• シンプルな仮想マシンとホスト間のアフィニティ • 仮想マシン間の非アフィニティ • DRS vMotion の無効化

DRS が動作するきめ細かいクラスタ レベルを考えると、基盤となるインフラストラクチャの拡大（仮想マシン、ホスト、アプリケーションの数）とともに静的ルール（最初に策定）の管理、レプリケーション、更新を行うのは困難になります。また、時間が経つうちにルールがもともと作成された意図（「理由」と「内容」）がわからなくなります。こうした事態を避けるために、コンピューティング ポリシーではより高いレベルの抽象化を実現し、DRS が動作するクラスタ レベルではなく SDDC レベルでお客様の意図を記録します。そのため、1 つのポリシーを SDDC 内の複数のクラスタに同時に適用できます。これは、仮想マシンの配置とロードバランシングの決定を可能にするだけでなくワークロード全体を処理できるフレームワークを提供することを目的としたものです。

必須ポリシーは、DRS の「must」（必須）ルールと同等です。推奨ポリシーは DRS の「should」（推奨）ルールに類似します。推奨ポリシーでは、ホストがメンテナンス モードに切り替わらないようにブロックすることができません。ただし、クラスタのアンバランスやホストの過度な使用を修正するためにポリシーに違反することはできません。

ポリシーに関連付けられているタグを削除すると、ポリシーが有効でなくなり、削除されます。

現時点では、ポリシーの作成と削除のみができます。ポリシーを更新するには、削除してから、必要な変更を行ったポリシーを追加してください。

コンピューティング ポリシーでは、SDDC ごとに合計 20 のポリシーに対応できます。

いいえ。すべての定義済みポリシー（DRS vMotion の無効化を除く）は同じように扱われます。ほかのポリシーよりも優先されるポリシーはありません。そのため、別のポリシーを修正するためにポリシーに違反することはできません。

現在の実装では、競合の検出はありません。つまり、ユーザーが互いに競合する 2 つのポリシーを設定しても、エラーや警告は表示されません。以下に記載されたとおり、DRS はすべてのポリシーを可能なかぎり最適な方法で適用します。

必須ポリシーは VMware Cloud on AWS 環境では使用できません。そのため、仮想マシンとホスト間のアフィニティは推奨ポリシーです。

はい。仮想マシンとホスト間のアフィニティ ポリシーを定義するときに、必要な AZ でタグ付けされたホストを選択できます。

状況によります。仮想マシンとホスト間のアフィニティは推奨ポリシーです。ISV ベンダーに問い合わせて、ライセンス契約の条項に従って推奨ポリシーを許容できるか確認してください。

VMware Cloud on AWS では、VM Power ON、メンテナンス、可用性はポリシー適用よりも優先されます。ただし、ポリシー適用はホストの使用よりも優先されます。その結果、指定したホストで仮想マシンが動作しない状況があります。VMware Cross-Cloud Services を活用されているお客様の取り組みを一部ご紹介いたします。• 障害でホストがダウンした場合、HA が有効になっていれば、リカバリ対象の仮想マシンがクラスタ内の使用可能なホストでパワーオンになります。• 同様に、予約が使用されているときに順守状態のホストが仮想マシンの予約を満たせない場合、予約を満たすことができる使用可能な（非順守状態の）ホストで仮想マシンがパワーオンになります。• 順守状態のホストがない場合（ポリシーで指定されたホスト タグを持つホストがない場合）、仮想マシンは使用可能なホストでパワーオンになります。• ユーザーが仮想マシンとホスト間のアフィニティ ポリシーを複数設定していて、それらが仮想マシンと競合している場合、ポリシーは無視され、仮想マシンは DRS によって選択された適切なホストでパワーオンになります。ただし、どのような場合でも、コンピューティング ポリシーは仮想マシンを順守状態のホストに戻そうとし続けます。

仮想マシン間の非アフィニティ ポリシーを適用すると、DRS はさまざまなホストの各仮想マシン（ポリシーで指定された仮想マシン タグを持つ）を維持するよう試みます。DRS は、仮想マシンのパワーオン、ホストのメンテナンス モード、ロードバランシングのときにこの仮想マシン間の非アフィニティ関係を考慮します。仮想マシン間の非アフィニティ ポリシーに仮想マシンが関係している場合、DRS はポリシーで指定された仮想マシン タグを持つパワーオン状態の仮想マシンが存在しないホストを、常に候補として優先します。

プロビジョニング先のホストを指定する、対応する API 呼び出しによって発行されたプロビジョニング処理では、ポリシーの違反が許容されている場合があります。ただし、DRS は以降の修正サイクルで仮想マシンを移動させようと試みます。仮想マシン間の非アフィニティ ポリシーに従って仮想マシンを配置できない場合、ポリシーが取り下げられ、処理（パワーオンまたはホストをメンテナンス モードに切り替える）が続きます。つまり、最初に DRS はポリシーを満たすことのできる仮想マシンを配置しようと試み、それが不可能な場合は、ポリシーに違反するホストであっても、そのほかの要素に従って最適なホストの探索を続けます。仮想マシンがポリシーに従って配置されないその他の状況には次のようなものがあります。• クラスタ内の各ホストに、仮想マシン間の非アフィニティ ポリシーによって指定されたタグを持つ 1 つ以上の仮想マシンがある。• ポリシーで優先されるホストのいずれも、仮想マシンの CPU/メモリ/vNIC 予約の要件を満たすことができない。

最初に DRS はできる限り異なるホストにできる限り多くの仮想マシンを配置するよう試みます。この場合、ホストの数はクラスタ内の使用できるホストの数と等しくなります。その後、DRS はポリシーを強制せず、そのほかの要素に基づいて残りの仮想マシンを配置します。これにより、同じホストに複数の仮想マシンが配置される可能性があります。この違反を修正するために、新たなホストがクラスタに追加されます。ホストが追加された後、DRS はポリシーに違反している仮想マシンを新たに追加されたホストに移動します。

必須ポリシーは VMware Cloud on AWS 環境では使用できません。そのため、仮想マシンとホスト間の非アフィニティは、推奨ポリシーです。

はい。DRS はポリシーに準じた仮想マシンの配置を常に試みますが、それが不可能な場合（ポリシーに準拠するホストが存在しない、クラスタ内のすべてのホストに、ポリシーで指定されたホスト タグが付いている、条件を満たすホストは存在するが、仮想マシンのリソース予約量を確保できないなど）、ポリシーには違反するものの、そのほかの要素に基づいて最適と考えられるホストが選択されます。クラスタのアンバランスな状態やホストの過度な使用を是正するためにポリシー違反が発生することはありません。ただし、仮想マシンのパワーオンが妨げられることはありません。ユーザーが複数のアフィニティ/非アフィニティ ポリシーを設定していて、それらが仮想マシンと競合している場合、そのポリシーは無視され、仮想マシンは DRS によって選択された適切なホストでパワーオンされます。

仮想マシン間のアフィニティ ポリシーを適用すると、DRS は、そのポリシーの仮想マシン タグが付いているすべての仮想マシンを同一ホストに配置するよう試みます。DRS は、仮想マシンのパワーオン、ホストのメンテナンス モード、ロードバランシングのときにこの仮想マシン間のアフィニティ関係を考慮します。

DRS は、アフィニティ ポリシーで指定された仮想マシンをできるだけ多く同じホストに配置することを試みます。それ以上の仮想マシンを同一ホストに配置できなくなると、DRS はポリシーに違反しても、ほかのホスト上で仮想マシンをパワーオンします。ホストがポリシーで指定されている仮想マシンの予約量に対応できない場合、このような問題が発生します。ただし、DRS はクラスタを継続的にスキャンし、ポリシーに準拠する機会が見つかり次第、仮想マシンを移動します。

このポリシーは、DRS は仮想マシンがパワーオンされたホストからその仮想マシンを移行したりロードバランシングしたりしないことを表します。ただし、ホストがメンテナンス モードに切り替わっている場合についてはこの限りではありません。このポリシーは、遅延の影響を受けやすい大規模なリアルタイム データベースや VoIP アプリケーションなど、vMotion の影響を受けやすいアプリケーションに有用です。このポリシーの対象となる仮想マシンは、vSphere タグを使用して特定されます。このポリシーはパワーオン操作には適用できません。ただし、仮想マシンがパワーオンになるとこのポリシーの対象となり、その仮想マシンは、仮想マシンとホスト間のアフィニティ ポリシーまたは仮想マシン間の非アフィニティ ポリシーを修正するために移動されなくなります。

VMware Cloud on AWS コンソールにアクセスして SDDC をクリックし、[Add Cluster] アクションを選択します。[Cluster to Be Added] セクションで、ホストあたりの CPU コア数を指定できます。ワークロードに最適な値を選択し、アクションを完了します。

はい。i3en では物理カスタム コア数として、8、16、24、30、36、48 がサポートされています。

いいえ。この機能は追加のクラスタのみを対象としています。クラスタ 0 では常にすべてのコアが有効です。

次のカスタム CPU コア値は、ホスト タイプごとにサポートされています。

• I3 ホストの 2 ホスト クラスタ：ホストごとのカスタム物理 CPU コア数は 16、36
• I3 ホストの 3 台以上のホストを含むクラスタ：ホストごとのカスタム物理 CPU コア数は 8、16、36
• I3EN ホスト タイプ：ホストごとのカスタム物理 CPU コア数は 8、16、24、30、36、48

CPU コア数のカスタマイズ機能の具体的な制限は次のとおりです。• この機能は追加のクラスタのみを対象としています。クラスタ 0 では常にすべてのコアが有効です。• この機能は [Add Cluster] での展開時のみ使用できます。展開後に変更を行うことはできません。• ホストの追加または削除の操作を含め、クラスタ内のすべてのホストの CPU コア数は同一のものしか指定できません。

いいえ。コア数を変更してもホストの料金には影響しません。

ライセンス対象の CPU コア数を維持するため、VMware Cloud on AWS のコンピューティング ポリシー（仮想マシンとホスト間のシンプルなアフィニティ）を使用することを強く推奨します。このポリシーを使用すると、クラスタ内の該当するすべての仮想マシンとそのホストにタグを付けることにより、特定の仮想マシンを特定のホスト グループに固定することができます。VMware Cloud on AWS の通常のパッチ適用とアップグレード操作の際には、クラスタにホストが追加されます。したがって、初回のライセンス契約にはこの追加のホスト分のライセンスを含め、導入初日から N+1 にする必要があります。

はい。コア数を減らすと、そのホスト上のすべてのワークロードのコンピューティング パフォーマンスに影響し、システムのパフォーマンスが低下する可能性が高くなります。たとえば、vCenter と vSAN のオーバーヘッドが顕著になり、クラスタやホストの追加といった操作にかかる時間が増える可能性があります。

はい。設定済みの「CloudAdmin」ロールに加えて、独自のカスタム ロールを作成できます。「Authorization.ModifyRoles」権限を持つユーザーは、ロールを作成、更新、削除できます。「Authorization.ModifyPermissions」権限を持つユーザーは、ユーザーまたはグループにロールを割り当てることができます。

ロールの変更権限を持つユーザーは、自身の現在のロールと同等以下の権限のカスタム ロールを作成、変更、削除できます。「CloudAdmin」ロールより高い権限のロールは、作成はできますが、ユーザーやグループに割り当てることはできません。

ユーザーは、自身の現在のロールと同等以下の権限の、すべてのロールを変更または削除できます。

はい。管理オブジェクトは表示のみを行うことができます。管理オブジェクトには、ほかのユーザーまたはグループの読み取り専用のロールを割り当てることもできます。

はい。インベントリ ツリー全体にアクセスできるようになりました。ただし、作成される仮想マシン間の競合を防ぐため、引き続きコンピューティング リソース プールを仮想マシンの作成場所とすることを強くおすすめします。

いいえ。vCenter のカスタム ロールは NSX-V のネットワーク構成でサポートされていません。この機能でサポートされているのは NSX-T の構成のみです。

EDRS 高速スケール アップは、EDRS の反応を高速化し、複数のホストを同時に追加できるようにして、VDI などのワークロードにディザスタ リカバリ イベントが発生した際により迅速にクラスタをスケール アップすることを可能にします。

EDRS 高速スケール アップは、edrs-policy API から有効にします。

i3en.metal インスタンスは、96 個の仮想 CPU、768 GiB のメモリ、8 x 7,500 NvME SSD ストレージで構成されるインスタンスです。2.50 GHz の Intel Xeon Cascade Lake プロセッサーを使用しています。このインスタンスでは、East-West トラフィックに対して、デフォルトでネットワークレベルの暗号化が提供されます。

i3en.metal インスタンスでは、本番クラスタの最小サイズは 2、最大サイズは 16 です。

いいえ、現時点では、i3en.metal インスタンスを使用したシングル ホストまたは 2 ホストの SDDC はサポートされていません。

I3en.metal は、現在、オレゴン、バージニア北部、北カリフォルニア、オハイオ、カナダ（中部）、ロンドン、フランクルト、パリ、ストックホルム、アイルランド、シドニー、東京、シンガポール、ムンバイ、ソウル、サンパウロ、および GovCloud（米国西部）の AWS リージョンで利用できます。今後、VMware Cloud on AWS リージョンで段階的に利用可能になる予定です。AWS リージョン内の具体的な AWS アベイラビリティ ゾーンについては、VMware または AWS のカスタマー サクセス チームか営業担当にお問い合わせください。

i3en.metal インスタンスは、次のリージョンとそれぞれのアベイラビリティ ゾーンで利用できます。

• ストックホルム（ARN/eu-north-1）：eun1-az1、eun1-az2、eun1-az3
• ムンバイ（BOM/ap-south-1）：aps1-az1、aps1-az2、aps1-az3
• パリ（CDG/eu-west-3）：euw3-az1、euw3-az2、euw3-az3
• オハイオ（CMH/us-east-2）：use2-az1、use2-az2、use2-az3
• アイルランド（DUB/eu-west-1）：euw1-az1、euw1-az2、euw1-az3
• フランクフルト（FRA）/eu-central-1）：euc1-az1、euc1-az2、euc1-az3
• サンパウロ（GRU）/sa-east-1）：sae1-az1、sae1-az3
• バージニア北部（IAD）/us-east-1）：use1-az1、use1-az2、use1-az3、use1-az4、use1-az5、use1-az6
• ソウル（ICN/ap-northeast-2）：apne2-az1、apne2-az3
• ロンドン（LHR/eu-west-2）：euw2-az1、euw2-az2、euw2-az3
• 東京（NRT/ap-northeast-1）：apne1-az1、apne1-az2、apne1-az4
• オレゴン（PDX/us-west-2）：usw2-az1、usw2-az2、usw2-az3
• 北カリフォルニア（SFO/us-west-1）：usw1-az1、usw1-az3
• シンガポール（SIN/ap-southeast-1）：apse1-az1、apse1-az2、apse1-az3
• シドニー（SYD/ap-southeast-2）：apse2-az1、apse2-az2、apse2-az3
• カナダ中部（YUL/ca-central-1）：cac1-az1、cac1-az2
• GovCloud（米国西部）

パーティション配置グループは、あらゆるリージョンおよびアベイラビリティ ゾーンで自動的に有効になります。パーティション配置グループ用の構成オプションはありません。

VMware Cloud on AWS は、新しい SDDC、クラスタ、およびホストのプロビジョニング操作中にパーティション配置グループを自動的に有効にします。

ホストを除去する場合は、パーティション内に存在しないホストを除去することをおすすめします。新しいホストは、可能な場合は常にパーティションに追加されます。このようにして、SDDC は徐々に多くのパーティションのメリットを活かせるようになります。

パーティション配置はベストエフォートの操作です。物理ラックまたはキャパシティが不十分な場合は、配置が失敗する可能性があります。パーティション配置が失敗すると、ホストはパーティションの外部に追加されます。つまり、ホストは追加されますが、同じクラスタのホストがすでに存在している可能性があるラックに追加されることになります。パーティション配置が最適ではない場合でも、特別な操作は必要ありません。

パーティション配置は、お客様が構成したり表示したりすることはできません。

いいえ。既存の SDDC は、ホストが追加されたり除去されたりするにつれて、徐々にパーティション配置のメリットを活かせるようになります。

ストレッチ クラスタとは、ミッション クリティカルなアプリケーションのために目標復旧ポイント（RPO）ゼロのインフラストラクチャ可用性を実現する機能です。これにより、2 つの AWS アベイラビリティ ゾーン（AZ）にまたがるクラスタで、RPO ゼロでワークロードをフェイルオーバーできるようになります。開発者がインフラストラクチャの可用性ではなくコア アプリケーションの要件や機能に集中できるというメリットもあります。この機能を使用すると、1 つの SDDC を 2 つのアベイラビリティ ゾーンにまたがって展開できます。vSAN のストレッチ クラスタ機能を利用して、1 つの SDDC クラスタで 2 つのアベイラビリティ ゾーンへの同期書き込みが実現されます。また、ワークロードの論理ネットワークが拡張されて、アベイラビリティ ゾーン間で vMotion がサポートされます。一方のアベイラビリティ ゾーンで障害が発生すると、vSphere HA によってもう一方のアベイラビリティ ゾーンで仮想マシンが再起動されます。

2 つです。SDDC のプロビジョニング時に、従来と同じようにアベイラビリティ ゾーンを選択します。違いは、その後に 2 つ目のアベイラビリティ ゾーンを選択することだけです。その情報を使用して、SDDC が自動的に展開され、その 2 つのアベイラビリティ ゾーンにまたがるストレッチ クラスタが構成されます。

複数のストレッチ クラスタは、i3.Metal または i3en.Metal インスタンスに展開されている SDDC に作成できます。

いいえ。クラスタ タイプは混在できません。1 つの SDDC で利用できるのは、ストレッチ クラスタまたは非ストレッチ クラスタのいずれか一方です。

いいえ。ストレッチ クラスタと非ストレッチ クラスタのどちらを展開するかは SDDC の作成時に指定し、あとから変更することはできません。

はい。カスタム CPU コアは、2 つ以上のストレッチ クラスタを持つ SDDC で構成できます。ただし、1 つ目のストレッチ クラスタではカスタム CPU コアを構成することができません。

サポートされる最小のストレッチング・クラスターは2ホストで、99.9%の可用性を保証しています。
6 ホストで 99.99% まで可用性を保証するサービスです。これは、アベイラビリティ ゾーン全体で障害が発生した場合にクォーラムが必要になるからです。この場合、アベイラビリティ ゾーンごとに 3 つのノードが必要になるため、したがって、99.99%のSLAを提供するためには、6個が最小のストレッチクラスタとなる。

はい。通常のクラスタと同様に、いつでもホストを追加したり削除したりできます。ただし、ストレッチ クラスタではホストの追加や削除をペアで行う必要があります。両方のホストの数が常に同じでなければならないからです。したがって、クラスタを 6 ノードから 8 ノード、10 ノード、12 ノードなどに拡張できます。

サポートされるクラスタの最大サイズは 16 ホストです。

ストレッチ クラスタでは、リクエストしたホストのほかに、常に追加の ESXi ホストが 1 台プロビジョニングされます。このホストは「ウィットネス ノード」として機能します。これにより、ネットワークが分断された場合にスプリット ブレインなどの問題を回避できます。このホストは UI に表示されますが、クラスタのメンバーにはならず、ゲスト仮想マシンを実行することもできません。このホストは、ゲストとして実行される特別なバージョンの ESXi です。ウィットネス ESXi は物理ホストを占有しないため、サービス利用料金の節約になります。

いいえ。ストレッチ クラスタにより可用性が向上しますが、ディザスタ リカバリを目的としたものではありません。1 つの AWS リージョン内の AWS アベイラビリティ ゾーン（AZ）は、地理的に同じ地域に配置されています。災害により対象の地域に被害があった場合、1 つの AWS リージョン内のすべての AZ で障害が発生する可能性があります。

ゲストとしての ESXi は、この特殊なケースでのみサポートされます。ウィットネスではゲスト ワークロードは実行されないため、この目的に限ってのみ、仮想化された ESXi がサポートされます。

いいえ。ストレッチ クラスタを利用するかどうかは導入時に決定する必要があります。非ストレッチ クラスタをストレッチ クラスタにアップグレードすることはできません。

いいえ。ストレッチ クラスタを利用するかどうかは導入時に決定する必要があります。ストレッチ クラスタを非ストレッチ クラスタにダウングレードすることはできません。

いいえ。1 つの SDDC に含めることができるのは、単一のアベイラビリティ ゾーンのクラスタかストレッチ クラスタのいずれかです。

HCX を使用して単一の AZ のクラスタからオンプレミスのデータセンターにワークロードを移行した後、そのワークロードをオンプレミスからストレッチ クラスタに移行できます。

はい。仮想マシンの展開時に、目的のアベイラビリティ ゾーンにある ESXi ホストを選択できます。障害が発生した場合も、可能であれば、その仮想マシンは元のアベイラビリティ ゾーンにとどまります。

いいえ。ストレッチ クラスタは、同じリージョン内の 2 つのアベイラビリティ ゾーンにまたがる構成です。個別のリージョンの障害に対する保護が必要な場合は、Site Recovery サービスなどのディザスタ リカバリ ツールをご利用ください。

はい。2 つのアベイラビリティ ゾーンへの同期書き込みが行われるため、書き込みトランザクションのオーバーヘッドが増加します。これは、ストレッチ クラスタのすべての実装に当てはまります。

SPBM の設定によって異なります。仮想マシンのデフォルトの構成では、1 つのアベイラビリティ ゾーンのすべてのホストで障害が発生しても、データを失うことなく処理を継続できます。

vSAN データストアが再同期されます。この再同期に要する時間は、保存されているデータの量と、システムがセグメント化されていた時間によって決まります。この操作は自動的に行われ、VMware のオペレーション チームによって監視されます。

ストレッチ クラスタを使用するために、追加の料金は必要ありません。ストレッチ クラスタがアベイラビリティ ゾーン（AZ）をまたぐ場合の料金も、AZ をまたぐトラフィックのうち 1 か月あたり 10 ペタバイトまでについては免除されます。使用量はモニタリングされており、上記の制限を超過した場合、VMware はお客様に通知し、料金の全額を請求する権利を留保します。

複数のストレッチ クラスタは、i3.Metal インスタンスと i3en.Metal インスタンスでサポートされます。

はい。同じ SDDC 内に i3.Metal と i3en.Metal のストレッチ クラスタを 1 つ以上混在させることができます。

いいえ、1 つのストレッチ クラスタには、同じインスタンス タイプのホストしか含められません。

ストレッチ クラスタでは、デフォルトのストレージのみのポリシーに加え、すべての EDRS ポリシー（コスト、パフォーマンス、高速スケール アウト）がサポートされます。

EDRS は、各アベイラビリティ ゾーンの使用率を監視します。スケールアウト イベントは、いずれかのアベイラビリティ ゾーンで使用率がしきい値を超えた場合にトリガーされます。一方、スケールインは、両方のアベイラビリティ ゾーンで使用率がしきい値を下回った場合にのみ発生します。

Elastic DRS（eDRS）は、vSphere のリソース管理機能を使用して SDDC で実行されている負荷を分析し、クラスタをスケール アップまたはスケール ダウンする機能です。この機能を使用することで、手動操作を行わなくても VMware Cloud on AWS がクラスタ サイズを管理できるようになります。

eDRS は、クラスタがキャパシティしきい値に達したときに自動的にスケール アップします。システムが現在のキャパシティを監視して傾向を判断し、クラスタにキャパシティを追加することを決定します。

「ストレージのみのスケール アップ」ポリシーは、SDDC に展開されるすべてのクラスタに設定されるようになったポリシーです。従来、SDDC には 30 % 以上のスラック スペースを確保することが推奨されるのみでしたが、これにより、スラック スペースが強制的に確保されるようになります。vSAN データストアの使用可能な最大キャパシティは 75 % で、このしきい値に達すると eDRS がクラスタにホストを追加するプロセスを自動的に開始し、vSAN データストアの拡張を行います。ストレージが解放されてしきい値を下回るようになっても、クラスタは自動的にスケールダウンされません。クラスタから手動でホストを削除する必要があります。詳細は、こちらのブログ記事をご覧ください。

はい。いずれかのクラスタがストレージのスケールアウト イベントの 5% 以内になると、メールおよびコンソール内の通知でお知らせします。また、ホストが追加された場合もすぐに通知されます。

既存のクラスタにホストを追加する場合の所要時間はおよそ 10 ～ 15 分です。eDRS は約 5 分ごとにスケーリングの提案を行います。

はい。クラスタの負荷が低い場合、eDRS では自動的にスケール ダウンも行われます。

eDRS を設定する際、許容する最小のクラスタ サイズと最大のクラスタ サイズを設定します。eDRS は利用者が設定した範囲内でのみスケールします。

いいえ。eDRS はホストを順々に追加するわけではありません。eDRS はクラスタのスケーリングが過剰になることを回避するよう調節されています。また、VMware のオペレーション チームもシステムを監視し、スケール操作が正しく行われていることを確認します。

最小台数のホストが必要な SPBM ポリシー（RAID 6 など）がある場合、eDRS は最小台数未満にはスケール ダウンしません。スケール ダウンを許可するには、RAID 1 など、そのような制限のないポリシーを使用するように SPBM を再設定してください。

VMware Cloud on AWS では、ホストあたりの料金が 1 時間単位で請求されます。eDRS は SDDC で実行しているホストの数を変えるだけです。手動で SDDC にホストを追加した場合と同様です。

はい。DRS はワークロードを自動的にリバランスします。

それは、ホストにかかっている負荷の高さによって異なります。負荷が低いホストは、クラスタから削除するのに数分しかかかりません。非常に負荷の高いホストでは数時間かかる可能性があります。eDRS の場合、VMware は負荷の低いホストのみを削除します。そのため、この操作の所要時間は短い方になると予想しています。ただし実際の退避時間は、実行中の仮想マシンの台数と、ホストから退避させる必要のあるデータの量によって大きく変わります。したがって、所要時間は変わります。

いいえ。eDRS は調節されているため、ディザスタ リカバリ イベントで発生するような突然の負荷の急増に対応できるようには設計されていません。そうした場合は、ディザスタ リカバリの手順の一部としてホスト追加プロセスのスクリプトを作成してください。ディザスタ リカバリ ワークロードが開始されたら、クラスタ内のホストを適切な台数に保つように eDRS に任せることができます。

いいえ。eDRS ではクラスタにホストを追加するため、それによって請求額が上がる可能性があります。したがって、デフォルトでは無効になっています。この機能を有効にするために、VMware Cloud UI または API を使用できます。

eDRS を有効にする場合は、クラスタ単位で行います。

EDRS 高速スケール アウトは、EDRS の反応を高速化し、複数のホストを同時に追加できるようにして、VDI などのワークロードにディザスタ リカバリ イベントが発生した際により迅速にクラスタをスケール アウトすることを可能にします。

EDRS 高速スケールアウトは、新しい EDRS ポリシー タイプとして UI から有効にするか、edrs-policy API から有効にします。

EDRS 高速スケール アウトの最大しきい値は、EDRS パフォーマンス ポリシーのしきい値を同じです。最小しきい値は 0% です。つまり、スケールインは手動で実行する必要があります。

4 台、8 台、または 12 台のホストを選択して、並行して展開できます。

i3.metal ホスト インスタンスの場合、各 ESXi ホストに NVMe SSD ストレージが搭載されています。vSAN を実行する ESXi ホスト 3 台のクラスタでは使用可能なストレージは約 15 TiB、vSAN を実行する ESXi ホスト 4 台のクラスタでは使用可能なストレージは約 21 TiB で、すべての仮想マシンがホスト 1 台の障害に対して保護されます（FTT=1）。i3en.Metal ホスト インスタンスの場合、各 ESXi ホストに NVMe SSD ストレージも搭載されています。vSAN を実行する ESXi ホスト 3 台のクラスタでは使用可能なストレージは、約 60 TiB です。使用可能なストレージの正確な値は、ワークロードのタイプによって異なります。すべての仮想マシンは、ホスト 1 台の障害に対して保護されます（FTT=1）。

現在、ハイブリッド ストレージ ソリューションは提供されていません。すべての i3.metal および i3en.metal ホストには NVME SSD ストレージが搭載されています。

ストレージ キャパシティを増やすにはホストを追加する必要があります。

SDDC の vSAN クラスタでは、ユーザーが以下の vSAN ポリシーのサブセットを構成できます。

• 許容障害数（FTT）：vSAN オブジェクトごとに設定できます。
• 仮想マシンのフォルト トレランス メソッド（FTM）と許容する障害の数の構成はお客様が選択できます。コスト、パフォーマンス、可用性を最適化するために、3 ノードのクラスタに対しては FTM = RAID 1 と FTT=1、4 ～ 5 ノードのクラスタに対しては FTM = RAID 5（イレイジャー コーディング）と FTT=1、6 ノード以上のクラスタに対しては FTM = RAID 6 と FTT=2 を使用することをおすすめします。
• IOPS の制限：仮想マシンごとに使用可能な IOPS の上限を設定することで、さまざまなワークロードのパフォーマンスの SLA 管理を向上させ、「帯域負荷の高い仮想マシン」の問題を排除できます。
• チェックサム：デフォルトで有効になっています。
• ディスク ストライプ：オブジェクトあたりのディスク ストライプ数の上限は 12 ですが、クラスタの構成（選択した FTT および FTM、ノードの数など）によって制限される場合もあります。
• 強制プロビジョニング：ストレージ ポリシーが満たされなくても仮想マシンをプロビジョニングできるようにします。

EC2 ベースの仮想ストレージ アレイから VMware Cloud on AWS のゲスト OS に提供されるストレージは、テストおよび開発、ビッグデータのワークロードのための柔軟性、ユーザー/ホーム ディレクトリなど、さまざまなユースケースに適しています。ブロック プロトコルとファイル プロトコルの両方がサポートされています。なお、外部ストレージにアクセスできるのは VMware Cloud on AWS のゲスト OS からのみです。VMware Cloud on AWS のクラスタ データストアから外部ストレージへのアクセスはサポートされていません。

VMware Cloud on AWS では、AWS EC2 ベースのさまざまな仮想ストレージ アレイや、ストレージ ボリュームや LUN をエクスポートする汎用オペレーティング システムがサポートされています。ストレージ パートナーのソリューションは、各パートナーによって独自にテストされ、ドキュメントが提供されます。

• 重複排除は冗長なデータ ブロックを排除する機能で、圧縮は各データ ブロックから冗長なデータを排除する機能です。この 2 つの組み合わせにより、データの保存に必要な物理ストレージ容量が削減されます。VMware vSAN では、データがキャッシュ層からキャパシティ層に移動されるときに、重複排除が適用されてから圧縮が適用されます。

• 重複排除は、キャッシュ層からキャパシティ層にデータがデステージされるときにインラインで実行されます。重複排除アルゴリズムは、効率とパフォーマンスの適度なバランスを確保するために 4K の固定ブロック サイズを使用して、各ディスク グループ内で実行されます。同一ディスク グループ内のブロックの冗長コピーは 1 つのコピーに集約されますが、複数のディスク グループにまたがる冗長ブロックの重複排除は行われません。
• 圧縮アルゴリズムは、重複排除の実行後、キャパシティ層にデータを書き込む前に適用されます。vSAN では、圧縮の割り当てマップ オーバーヘッドにコンピューティング リソースが無駄に使用されないように、4K ブロックを 2K 以下に縮小できる場合にのみ、圧縮データが格納されます。それ以外のブロックについては圧縮せずに書き込みます。

重複排除と圧縮によって節約されるストレージの量は、ワークロードのデータに大きく依存します。VMware Cross-Cloud Services を活用されているお客様の取り組みを一部ご紹介いたします。

• 複数の仮想マシンが利用するオペレーティング システム ファイルでは、重複排除には大きなメリットがある
• VDI ワークロードでは重複排除によって大幅に節約される
• ビデオ ファイルは圧縮率が低い

オンプレミスで vSAN を使用しているお客様からは、VDI ワークロードでストレージが 1/7 に節約されたという報告もありますが、現在の環境では平均 1/2 程度が一般的です。

いいえ。重複排除と圧縮はクラスタ全体の設定で、個別に有効にすることはできません。また、VMware Cloud on AWS では、すべてのボリュームでこの機能が自動的に有効になります。ユーザーによる構成には対応していないため、無効にすることはできません。

vSAN の重複排除と圧縮は非常に効率的ですが、多少の影響が生じる可能性はあります。ほとんどのワークロードでは、影響はごくわずかです。

vSAN は、キャッシュ層とキャパシティ層の両方ですべての保存データを暗号化しながら、重複排除と圧縮により高いストレージ効率を実現できます。

• お客様の保存データは vSAN によってネイティブに暗号化されます。vSAN は、AWS Key Management Service を使用してカスタマー マスター キー（CMK）を生成します。CMK は AWS から取得され、追加の 2 つのキーは vSAN で生成されます。これらのキーは、キー暗号化キー（KEK）とディスク暗号化キー（DEK）と呼ばれる中間キーです。

• カスタマー マスター キー（CMK）はキー暗号化キー（KEK）をラッピングし、KEK はディスク暗号化キー（DEK）をラッピングします。CMK は AWS の管理を決して離れません。キー暗号化（KEK）の暗号化と暗号化解除は標準の AWS API 呼び出しで行われます。
• クラスタごとに 1 つのカスタマー マスター キー（CMK）とキー暗号化キー（KEK）が必要で、クラスタ内のディスクごとに 1 つのディスク暗号化キー（DEK）が必要です。

重複排除および圧縮と同様に、保存中の vSAN 暗号化はクラスタごとに有効または無効にすることができません。これはクラスタ全体の設定であり、SDDC でクラスタがプロビジョニングされるときにデフォルトで常に有効にされています。

いいえ。外部ストレージは、マネージド サービス プロバイダー（MSP）を通してのみ追加できます。SDDC と外部ストレージの両方をマネージド サービス プロバイダー（MSP）が管理します。

SDDC には 3 つの NFS データストアが接続されています。データストアのサイズは、マネージド サービス プロバイダー（MSP）の提供するサービスによって異なります。マネージド サービス プロバイダー（MSP）にお問い合わせください。

はい。VMware Cloud on AWS の vSAN ローカル ストレージは、外部ストレージが接続されている場合も引き続きご利用いただけます。

外部ストレージと VMware Cloud on AWS の SDDC は、マネージド サービス プロバイダー（MSP）を通して購入します。

価格については、マネージド サービス プロバイダー（MSP）にお問い合わせください。

外部ストレージは、マネージド サービス プロバイダー（MSP）が世界各地の拠点からクラウド ストレージとして提供します。サポートされている場所についてはマネージド サービス プロバイダー（MSP）にお問い合わせください。

外部ストレージは、マネージド サービス プロバイダー（MSP）のクラウド ストレージと近接している特定のリージョンで提供されます。サポートされているリージョンについてはマネージド サービス プロバイダー（MSP）にお問い合わせください。

現在サポートされているマネージド サービス プロバイダー（MSP）のなかでは、Faction と Rackspace が VMware Cloud on AWS 向けの外部ストレージを合わせて提供しています。

提供される外部ストレージを使用する場合の注意事項と制限事項の一覧については、『VMware Cloud on AWS リリース ノート』でご確認ください。また、その他の詳細についてはマネージド サービス プロバイダー（MSP）にお問い合わせください。

はい。Storage vMotion をサポートしています。

最新のリリースでは、お客様のすべての保存データは vSAN によってネイティブに暗号化されます。vSAN は AWS キー管理サービスを使用してカスタマー マスター キー（CMK）を生成します。CMK は AWS から取得され、追加の 2 つのキーは vSAN で生成されます。これらのキーは、キー暗号化キー（KEK）とディスク暗号化キー（DEK）と呼ばれる中間キーです。カスタマー マスター キー（CMK）はキー暗号化キー（KEK）をラッピングし、キー暗号化キー（KEK）はディスク暗号化キー（DEK）をラッピングします。CMK は常に AWS の管理下に置かれます。キー暗号化キー（KEK）の暗号化と復号化は標準の AWS API 呼び出しを通じて提供されます。クラスタあたり 1 つのカスタマー マスター キー（CMK）と 1 つのキー暗号化キー（KEK）が必要で、クラスタの各ディスクに対して 1 つずつディスク暗号化キー（DEK）が必要です。

vSAN の暗号化は、XTS AES 256 暗号化と Intel AES-NI ハードウェアを利用してパフォーマンスへの影響を最少に抑えた、業界をリードする暗号化です。ほとんどの場合、CPU オーバーヘッド、IOPS、遅延への影響はないと考えられます。暗号化計算の負荷が極端に高い場合は、ホスト 1 台あたり最大 1 CPU コアのオーバーヘッドが発生し、IOPS と遅延が最大 5 % 悪化することが確認されています。

お客様は、KEK（キー暗号化キー）を vSAN API または vSphere UI のいずれかを通して変更できます。このプロセスは浅いキー再生と呼ばれます。浅いキー再生成ではディスク暗号化キー（DEK）もカスタマー マスター キー（CMK）も変更されないことに注意してください。ディスク暗号化キー（DEK）とカスタマー マスター キー（CMK）の変更はサポートされていません。まれなケースとして、DEK または CMK を変更する必要がある場合、ユーザーは新しい CMK を使用して新しいクラスタを設定し、Storage vMotion で既存のクラスタからデータを移行できます。

前回のリリースに含まれるすべての既存クラスタが、最新のリリースに移行されます。移行の一環として、すべての既存クラスタで暗号化が有効になります。すべての新規クラスタは、デフォルトでは、暗号化を有効にしてプロビジョニングされます。

カスタマー マスター キー（CMK）は AWS キー管理サービスによって提供される機能であり、これが唯一の利用可能なオプションです。

ほかのストレージ システムと同様に、vSAN では、スラック スペースを使用してシステムの健全性を維持します。このスペースは、オブジェクトの再調整、重複排除などの操作の実行、ハードウェア障害からのリカバリに使用されます。

eDRS は、vSAN および ESXi のキャパシティ要件を認識し、ホストを自動的に追加または削除して、SDDC が健全な状態に保たれるようにします。eDRS は、SDDC を常に適切なサイズに維持するための最善の方法です。

圧縮は、i3en ベアメタル インスタンスで使用できます。重複排除は、i3en インスタンスではサポートされていません。

ストレージ ポリシーは、仮想マシンや VMDK の保護またはパフォーマンスのレベルを定義します。通常、ポリシーは、ユーザーが 1 つ以上の仮想マシンに対して手動で定義し、vCenter によって管理されます。データの可用性を高める vSAN ポリシーの自動調整では、お客様の VMware Cloud on AWS クラスタ内のノード数に基づいて、ポリシーが自動的に設定されます。

VMware Cloud on AWS は、SLA に定められているように、99.9% の可用性を保証しています。SLA 事由が発生した場合、つまり、サービス コンポーネントが利用できなくなった場合、お客様のクラスタがストレージ ポリシーで設定された保護の要件を満たしていることを前提に、SLA クレジットを請求する権利があります。VMware Cloud on AWS によってこれらのポリシーを自動的に設定することで、クラスタを最適なレベルで保護しながら、SLA クレジットを請求するための基準を満たすことができます。

「vSAN ポリシーの自動調整」機能は、VMware Cloud on AWS のバージョン 1.10 以降のリリースでサポートされます。

• 標準クラスタの場合：

5 ホスト以下：許容障害数 1（RAID-1）、6 ホスト以上：許容障害数 2（RAID-6）

• ストレッチ クラスタの場合：

デュアル サイト ミラーリング、許容障害数 1：RAID-1

クラスタのポリシーは自動的に変更されます。

はい、vSAN ポリシーの自動調整機能を上書きして、独自のポリシーを設定できます。

Trim/Unmap は、ゲスト OS が trim/unmap コマンドを実行して、vSAN が未使用のブロックを除去できるようにする vSAN 機能です。未使用のブロックを自動的に再利用できるため、シン プロビジョニングされている VMDK にとってメリットとなります。これは、vSAN 環境でのストレージ容量使用率を大幅に改善できる可能性のある便宜的な領域効率化機能です。

ゲスト OS が、これらのコマンドを自動的に実行し、すべての未使用ブロックが再利用されるまでバックグラウンドで実行されます。

このプロセスには、ストレージ スペースを解放するというメリットがありますが、それ以外の副次的なメリットもあります。

• より迅速な修復：再利用されたブロックは、デバイスに障害が発生した場合にリバランスや再ミラーリングをする必要はありません。
• ダーティ キャッシュ ページの除去：DRAM クライアント キャッシュで読み取りキャッシュを解放できます。

この機能はプレビュー版としてリリースされているため、VMware がお客様の設定に基づいてクラスタごとにこの機能を有効にします。ご使用のクラスタでこの機能を有効にするには、お客様のアカウント チームにご連絡ください。

このプロセスは、パフォーマンスに一定の影響を与えます。ただし、使用する帯域幅には一定のしきい値が設定されていて、このしきい値に達すると調整されます。

クラウドネイティブ ストレージ（CNS）は VMware Cloud on AWS と Kubernetes（K8s）の機能です。K8s が VMC のストレージを高度に自動化されたスケーラブルな方法で、オンデマンドでプロビジョニングする方法を認識するようにするとともに、管理者に vCenter 内の CNS UI を介してコンテナ ボリュームに対する可視性を提供します。VMC 上のクラウドネイティブ ストレージは、TKG および TKG Plus でサポートされています。

クラウドネイティブ ストレージ（CNS）は 2 つの部分で構成されています。Kubernetes 向けの Container Storage Interface（CSI）プラグインと、vCenter 内の CNS 制御プレーンです。この統合を機能させるために、サービス内でなにかをインストールまたは構成する必要はありません。vSphere CSI を使用して Kubernetes を展開するだけです。

この機能は、SLAに準拠しないポリシーを持つVMやオブジェクトをスキャンし、VMware Cloud on AWS のお客様に通知するものです。[intnt_tn_3]]VMware Cloud on AWS[[/intnt_tn_3]]のお客様には、非準拠ポリシーの詳細と、それらがどの VM/オブジェクトにマップされているかを含む通知メールが送信されます。ORGです。また、お客様はVMCコンソール内で非対応ポリシーのVMの全リストを確認することができ、ボタン1つでマネージドストレージポリシーに移行することができるようになる予定です。

ワークロードを確実に保護し、障害発生時にクレジットを受けるためには、SLAへの準拠が必要です（VMware Cloud on AWS の SLA の 詳細についてはこちらを参照してください）。SLAに準拠したポリシーとは、VMware Cloud on AWS に従ったポリシーのことです。SLAガイダンスに準拠したポリシーと、VMware Cloud on AWS に記載されている内容と異なるポリシーは、非準拠のポリシーとなります。SLA文書。

どのVMが非準拠のポリシーを持っているか、メールで通知されます。このメールには、VMCコンソールに誘導するリンクが含まれており、ORGのSLA非準拠ポリシーを持つVMとオブジェクトの全リストを表示することができます。

スキャンは毎日行われ、新たに非対応のポリシーがあった場合、そのポリシーについてのみ通知されます。以前に通知されたコンプライアンス違反のポリシーは、メールには含まれませんが、改善されていない場合はインベントリビューに表示されます。

いいえ。VMC コンソールのインベントリ ビューで、準拠ポリシーに変更する仮想マシンを選択するオプションが表示されます。修復したい特定の VM を選択するか、インベントリ全体を修復するかのオプションが表示されます。SLA準拠のポリシーに移行されていないVMは、インベントリに残ります。

はい。NGWを使用すると、メールの通知をミュートすることができます。各クラスタのウィンドウ内に、どのクラスタがポリシーに準拠していないかを示すタイルが表示されます。

デフォルトでは、VMware Cloud on AWS の SDDC にある vCenter Server システムに外部からアクセスすることはできません。vCenter Server システムにアクセスできるようにする方法は次のとおりです。• vCenter Server システムへのアクセスを許可するファイアウォール ルールを構成します。• vCenter にプライベートにアクセスできるように、オンプレミスのデータセンターと SDDC の間に IPsec VPN または Direct Connect を構成します。vCenter には、リンクされた VPC および SDDC 内のコンピューティング仮想マシンからもプライベートにアクセスできます。

NSX-T では、AWS VPC から管理コンポーネントの背後にあるコンポーネントへの接続があります。ユーザーは、AWS VPC に展開されている EC2 インスタンスから vCenter に到達できます。

VMware Cloud on AWS で SDDC を展開すると、管理ネットワークとコンピューティング ネットワークの 2 つのネットワークが構成されます。管理ネットワークは、SDDC ホスト、vCenter Server、NSX Manager、およびその他の管理機能のネットワーク トラフィックを処理します。コンピューティング ネットワークは、ワークロード仮想マシンのネットワーク トラフィックを処理します。ゲートウェイは、ユーザーがインターネット、オンプレミス、および接続された AWS VPC から、これらのネットワークにアクセスできるようにするものです。NSX Edge はゲートウェイとして機能します。

VMware Cloud on AWS には 3 つのトラフィック グループがあります。• VMkernel トラフィック（ESX 管理、vMotion） • 管理アプライアンス トラフィック（vCenter、SRM、vSphere Replication アプライアンス、NSX Manager） • ワークロード仮想マシン トラフィック

IPFIX は、仮想スイッチまたは物理スイッチが自スイッチを流れるフローの情報をコレクター ツールにエクスポートできるように許可する標準です。特定の論理スイッチのすべてのフローと論理スイッチのセットのすべてのフローのどちらを監視するかをお客様が決定できます。

IPFIX テンプレートは、収集されるフローについてのメタデータ フォーマットを提供します。たとえば、フロー テンプレートには「フローの開始時と終了時のタイムスタンプ」や「その時間中に許可されるバイト数」などが含まれます。

フローは、5 つのタプル（送信元 IP、送信先 IP、送信元ポート、送信先ポート、プロトコル）の組み合わせです。特定のポートで互いに通信する 2 つのアプリケーション間には常に固有のフローがあります。

コレクター ツールは、フロー分析と、アプリケーションの健全性とパフォーマンスに関する情報のレポートを行います。これらはアプリケーション監視ツールと呼ばれることもあります。お客様は 4 つのコレクター ツールを構成できます。

デフォルトでは、コンピューティング ゲートウェイと管理ゲートウェイが論理セグメントを通して接続されます。通信は、管理ゲートウェイのファイアウォール ポリシーで制御できます。

これらのツールは VMware Cloud on AWS SDDC 内、またはオンプレミスに導入でき、どちらに導入するかはお客様が選択できます。

サンプリング レートとは、フロー内のパケットがサンプリングされる頻度を表します。

ポート ミラーリングとは、ポートからすべてのパケットをキャプチャして送信先デバイスに送信する、仮想スイッチまたは物理スイッチの機能です。

はい。ポート ミラーリング セッションには、Local Switch Port Analyzer（SPAN）、Remote SPAN、Encapsulated Remote SPAN というタイプがあります。

VMware Cloud on AWS は Encapsulated Remote SPAN をサポートしています。

パケットは、Wireshark などのトラブルシューティング ツール、または IDS/IPS などのセキュリティ分析ツールにミラーリングされます。

ユーザーは、送信元として 1 つまたは複数の仮想マシンを選択できます。

いいえ。仮想マシンの 1 つの vNIC（仮想 NIC）をきめ細かく選択することはできません。すべての vNIC のトラフィックがミラーリングされます。

DNS ゾーンでは、異なるドメイン（FQDN）に基づいて異なる DNS サーバを指定できます。

5 つのゾーンがサポートされています。

DNS ゾーンは最大 5 つ構成できます。そのうち 1 つに、オンプレミスの DNS サーバを参照するオンプレミス ドメイン（FQDN）を設定してください。また、AWS 内の DNS サーバを参照する AWS ドメイン（FQDN）をほかのゾーンに設定する必要があります。

3 ノード以上の SDDC を展開する際に、デフォルトの論理ネットワークが作成されなくなりました。仮想マシンを展開する前に、ユーザーの責任において、適切な CIDR を持つネットワークを作成する必要があります。

デフォルトの論理ネットワークの CIDR（192.168.1.0/24）がオンプレミス ネットワークと重複し、接続の問題が発生するというインシデントが多数あったためです。こうした問題はトラブルシューティングが非常に困難です。

はい。1 ノードの SDDC ではデフォルトの論理ネットワークが作成されます。お客様にて、CIDR 192.168.1.0/24 との重複がないことを必ず確認してください。

はい。VMware Cloud on AWS は、ネイティブの DHCP 機能のほか、DHCP リレーも備えています。

[System] の [Networking & Security] タブから [DHCP] を選択して構成します。

いいえ。使用できるのは、ネイティブの DHCP 機能または DHCP リレーのいずれか一方のみです。ネイティブの DHCP 機能を使用しているネットワーク セグメントがある場合、DHCP リレーは使用できません。使用するには、先にネイティブの DHCP 機能を使用しているネットワーク セグメントを削除する必要があります。

はい。API Explorer に VMware Cloud on AWS の利用可能な NSX-T API がすべて表示されます。

NSX VMC Policy API には、SDDC での NSX 機能に必要な NSX のネットワークおよびセキュリティ API がすべて含まれています。NSX VMC AWS Integration API には、Direct Connect など AWS 特有の API が含まれています。

VMware Cloud on AWS SDDC の API Explorer を使用すると、NSX-T API を簡単に探してそのまま使用できます。さらに、キーワードで検索を実行することもできます。NSX-T API を大規模なスクリプトやアプリケーションに組み込む前に、API Explorer で簡単に検索して直接テストできます。

Developer Center から API Explorer にアクセスします。API Explorer で組織と SDDC を選択すると、「NSX VMC Policy」API と「NSX VMC AWS Integration」API の両方が表示されます。使用する API の種類をクリックします。該当する NSX API のリストが表示されます。要求された情報を入力し、[Execute] ボタンをクリックすると、API が実行されます。

VMware では、サードパーティの脆弱性スキャンと侵入テストが含まれる、包括的な脆弱性管理プログラムを提供しています。VMware は定期的なセキュリティ評価を実施することで、VMware Cloud on AWS のコンプライアンス プログラムを維持し、クラウドプラットフォームのセキュリティ制御とセキュリティ プロセスの改善を継続的に行っています。侵入テストの実施要件は業界の規制によって変化するものの、侵入テストの実施は仮想インフラストラクチャ（SDDC）およびアプリケーションにおけるセキュリティの有効性を測定するものであり、お客様の環境の保護に非常に有益です。侵入テストの実施を計画している場合、こちらのリクエスト フォームから、テスト計画に関する情報を VMware にお知らせください。VMware から承認のご連絡をメールでお送りします。侵入テストは、弊社の侵入テスト ルールに従って実施する必要があります。

VMware Cloud on AWS では、Direct Connect のネットワーク トラフィ�