VMware Cloud on AWS での VPC との接続ガイド: 接続手順からレイテンシー、料金、メリットの比較まで！

# はじめに
:::note info
本投稿は vExperts Advent Calendar 2023 の13日目として作成しました。
:::

https://adventar.org/calendars/8879

この投稿では、2023年12月時点で広く使われている VMware Cloud on AWS と Amazon VPC の接続パターン 3 つを取り上げ、それぞれのメリットの比較を行います。また、それぞれの接続パターンによって ネットワークレイテンシーがどう変わるのか、比較をした情報があまりない為、実環境で計測し、どの程度差が出てくるのか見てみたいと思います！

:::note warn
本稿における計測結果及び掲載内容はあくまで私自身の見解・確認結果であり、必ずしも私の所属団体・企業における立場、戦略、意見を代表するものではありませんのでご了承下さい。
:::


# VMware Cloud on AWS と Amazon VPC の接続パターン

本投稿執筆時点では、VMware Cloud on AWS の Software-Defined Data Center (SDDC) と Amazon VPC の接続は、広く以下の 3 つのパターンが利用されています。

1. Elastic Network Interface (ENI) 経由での接続
1. VTGW 経由での接続
1. VTGW - AWS Transit Gateway (TGW) 経由での接続
※ VTGW: VMware Transit Connect サービスにおける AWS Transit Gateway 機能の総称

（その他 VTGW を使わずに TGW に直接 VPN アタッチメントで接続するパターンもありますが、あまり利用されていない為、今回は割愛します）

AWS から VMware Cloud on AWS の Networking Reference Architecture が公開されています。要件に応じた接続パターンを検討する上で参考になります。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/58e4446a-12db-ea6d-b269-ae09226d8877.png" width="750" />

*図は [VMware Cloud on AWS – Networking Reference Architecture](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/vmware-cloud-on-aws-networking-ra.pdf) からの抜粋*

# 今回の構成図

実際に SDDC を作成し、VPC と接続をしてみます。
このように 1つの SDDC から ENI 経由での接続、 VTGW 経由での接続、VTGW - TGW 経由での接続の組み合わせが可能です。
この構成図では 一例として SDDC 上の仮想マシンと Amazon EC2 との疎通を表していますが、もちろん EC2 以外のサービスとも連携が可能です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/5ea79570-5db9-1ee3-ea85-77730d09d7d5.png)

# それぞれの接続パターンの詳細な構成ステップ

## 1. ENI 経由での接続

ENI 経由での接続は、SDDC 作成時に自動的に構成がされます。
詳細について以前の投稿でまとめておりますので、そちらも是非合わせて参照下さい。

https://qiita.com/mtoyoda/items/99c9b5af4392fdc3c170#eni-%E7%B5%8C%E7%94%B1%E3%81%A7%E3%81%AE%E6%8E%A5%E7%B6%9A%E3%81%AE%E4%BB%95%E7%B5%84%E3%81%BF

## 2. VTGW 経由での接続

VTGW 経由で接続をするには、まず SDDC グループというものを作成します。
SDDC グループにメンバーとなる SDDC を追加する過程で、VTGW が作成され、その SDDC と VTGW の接続が行われます。
SDDC グループの作成手順については、既に DevelopersIO で記事がある為、そちらを参照下さい。

https://dev.classmethod.jp/articles/vmware-cloud-on-aws-sddc-group/

本投稿では、SDDC グループを作成した後の Amazon VPC との接続の部分を紹介します。

1. まず SDDC グループから、[外部 VPC] タブを開き、[アカウントの追加]ボタンをクリックします。
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/bd321d09-bad1-530c-0f9e-2ca50165f196.png" width="600" />

1. 接続したい VPC の AWS アカウント ID を入力し、[追加] ボタンをクリックします。
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/9c23041a-4cf5-6e93-4506-aa1a1a224e0f.png" width="350" />

1. VPC を所有している AWS アカウントの AWS マネジメントコンソールにて、 Resource Access Manager -> 自分と共有 -> リソースの共有 の部分に、"保留中" のステータスのリソースが表示される為、その名前をクリックします。
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/ded7c583-32c7-4675-593b-8ac979ebdd32.png" width="600" />

1. [リソース共有を承認] をクリックし、次に現れるポップアップで [承認] をクリックします。
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/d17f558d-ee9b-5ef1-4d3b-e2d555d6267b.png" width="350" />

1. 続いて、VPC -> Transit Gateway -> Transit Gateway アタッチメントから、[Transit Gateway アタッチメントを作成] をクリックします。
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/30c7ef19-aff0-62e0-de08-e2fdd560d459.png" width="650" />

1. [Transit Gateway アタッチメントを作成] 画面が表示されます。
    - 名前タグ: 任意の名前を指定します
    - Transit Gateway ID: "TGW for region xx-xxxxxx-xx"という名前の Transit Gateway が表示されますのでそれを指定します。
    - VPC ID: VTGW に接続をしたい VPC を指定します。
    - サブネット ID: 各 AZ に複数サブネットがある場合は、サブネットを指定します。
    - 最後に「Transit Gateway アタッチメントを作成」ボタンをクリックします。

    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/0499df2c-c98f-114d-a923-f2666e1022eb.png" width="500" />
    
    作成したアタッチメントが "Pending Acceptance"の状態となる為、次に VMware Cloud サービスポータル側で受け入れ処理を行います。

1. SDDC グループの管理画面に戻ります。[外部 VPC]タブにて、AWS アカウント ID の横にある ">>" をクリックします。
    承認保留中のリソースが表示されたら、チェックボックスにチェックを入れて、「承諾」ボタンをクリックします。

    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/9e0fb795-71f6-d5a3-ba49-61c9c5d48b73.png" width="650" />

    :::note info
    アタッチメントの作成をしてから、この表示が表示されるまで10分程度かかります。
    
1. ステータスが [利用可能] になると [ルートの追加] がクリックできるようになりますので、クリックをし、接続する VPC の CIDR を入力し、[終了] をクリックします。

    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/26dc4385-d60c-dcda-b535-2b5e76d62d1a.png" width="650" />

    これで VMware Cloud on AWS 側の設定は完了です。

1. 最後に、AWS マネジメントコンソールにて VPC -> 仮想プライベートクラウド -> ルートテーブル から Transit Gateway アタッチメントを作成したサブネットに関連づけられたルートテーブルに対して、SDDC のワークロード用のセグメント（今回でいうと 192.168.2.0/24）への通信を Transit Gateway アタッチメント経由で疎通させるようルートの追加を行います。
以前の投稿で詳細ステップを載せていますので、そちらを参照下さい。

https://qiita.com/mtoyoda/items/7d411575a69b655ee021#a-5-vpc-%E3%81%AB%E3%83%AB%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E3%81%AE%E8%BF%BD%E5%8A%A0

以上で VTGW 経由での接続構成は完了です！

## 3. VTGW - TGW 経由での接続

VTGW 経由での接続と同じく、まず SDDC グループの作成が必要です。

こちらでは SDDC グループを作成した後の手順をAmazon VPC との接続の部分を紹介します。

1. まず TGW の作成を行います。既に AWS を利用しており、既存の TGW がある場合はそれを利用しても問題ありません。
AWS マネジメントコンソールにて、VPC -> Transit Gateway -> Transit Gateway から、[Transit Gateway を作成] をクリックし、Transit Gateway を作成します。
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/44182c18-64ba-95ad-959a-56458651f097.png" width="550" />

    状態が Available になるまで待ちます。
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/15ea76bf-6a5e-6591-00dd-438de656a3cb.png" width="550" />

1. VMware Cloud サービスコンソールに移動し、SDDC グループから、[外部 TGW] タブを開き、[TGW の追加]ボタンをクリックします。
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/c50170d7-f2b5-71b9-82f4-9260cd028845.png" width="600" />

1. 接続する TGW の情報を入力します。
    - AWS アカウント ID: 一つ前のステップで TGW を作成したアカウント ID を入力します。
    - TGW ID: 一つ前のステップで作成した TGW の ID を入力します。
    - TGW の場所: 一つ前のステップで TGW を作成したリージョンを指定します。通常は、SDDC と同じリージョンになるかと思います。（この例では東京リージョンに SDDC を作成しており、TGW も 東京リージョンで作成しています）
    - ルート: 接続する VPC の CIDR を入力します。
    - 最後に [追加] ボタンをクリックします。
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/0eadeeed-2003-45ed-ad32-3fb81c068e9f.png" width="500" />

1. TGW を作成した AWS アカウントの AWS マネジメントコンソールにて、VPC -> Transit Gateway -> Transit Gateway アタッチメント を開き、"Pending Acceptance" のステータスのアタッチメントが表示される為、対象を選択し、[アクション] - [Transit Gateway アタッチメントを承諾] をクリックし、確認画面で [承諾] をクリックします。
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/efdc288b-f73e-ed78-d68d-e287ed001d31.png" width="650" />

1. 続いて、同じ Transit Gateway アタッチメントの画面から、[Transit Gateway アタッチメントを作成] をクリックします。
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/c2ed46b9-ed3a-3621-f44f-4c89cf114ed0.png" width="650" />

1. [Transit Gateway アタッチメントを作成] 画面が表示されます。
    - 名前タグ: 任意の名前を指定します
    - Transit Gateway ID: "TGW for region xx-xxxxxx-xx"という名前の Transit Gateway が表示されますのでそれを指定します。
    - VPC ID: VTGW に接続をしたい VPC を指定します。
    - サブネット ID: 各 AZ に複数サブネットがある場合は、サブネットを指定します。
    - 最後に「Transit Gateway アタッチメントを作成」ボタンをクリックします。

    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/70eb03c9-7cec-3b98-ddde-4eb5c78361f2.png" width="600" />

1. 続いて、VPC -> Transit Gateway -> Transit Gateway ルートテーブル から、対象の Transit Gateway ルートテーブルを選択し、[ルート] タブから [静的ルートを作成] をクリックします。

    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/f1052ea1-95e2-9100-5bfb-86ac36c6948c.png" width="650" />

1. CIDR として SDDC のワークロード用のセグメント（今回でいうと 192.168.2.0/24）を指定し、アタッチメントとして Peering のアタッチメントを指定し、[静的ルートを作成] をクリックします。
    <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/cc21a384-b21c-dab2-291d-e6d9962b73da.png" width="500" />

1. 最後に、AWS マネジメントコンソールにて VPC -> 仮想プライベートクラウド -> ルートテーブル から Transit Gateway アタッチメントを作成したサブネットに関連づけられたルートテーブルに対して、SDDC のワークロード用のセグメントへの通信を Transit Gateway アタッチメント経由で疎通させるようルートの追加を行います。
VTGW 経由での接続でも記載した通り、[以前の投稿](https://qiita.com/mtoyoda/items/7d411575a69b655ee021#a-5-vpc-%E3%81%AB%E3%83%AB%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E3%81%AE%E8%BF%BD%E5%8A%A0)で詳細ステップを載せていますので、そちらを参照下さい。

以上で VTGW -TGW 経由での接続構成は完了です！

## おまけ：トラブルシューティング

うまく疎通が出来ない場合、トレースフローを使う事により切り分けが簡単になります。トレースフローの使用方法については以下の投稿を参照下さい。

https://qiita.com/mtoyoda/items/80b19fe57f207d1c86c0

また、VPC Reachability Analyzer も非常に有用です。トレースフローと併用するとより切り分けが楽になります。

# レイテンシーの計測
## 計測方法

今回は SDDC 上の Linux 仮想マシンから それぞれの VPC の EC2 インスタンスに対して ping と netperf を実施します。
- 送信元の仮想マシンは全テストで同じ仮想マシンを利用します。
- EC2 インスタンスのサイズは各 VPC とも同じサイズを利用します。
- netperf は TCP Request/Response (TCP_RR) テストを利用します。
- ping と netperf とも 10 ミリ秒間隔で実行し、平均値を結果として利用します。ping は 1000 回実施の平均値とします。

## 計測結果

|                   | ENI 経由での接続 | VTGW 経由での接続 | VTGW - TGW 経由での接続 |
| ----------------- | ---------- | ----------- | ----------------- |
| ping              | 0.354 ms        | 0.495 ms      | 0.577 ms             |
| netperf (TCP_RR)  | 0.204 ms       | 0.291 ms       | 0.455 ms               |


# 通信料金

## ENI 経由での接続の場合の料金

ENI 経由での接続は、同じ AZ 内の通信に関してはデータ転送費用が発生しません。この為最も安価な接続方法となります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/78cf8888-1d5a-3a99-2c66-2da09721e932.png)



## VTGW 経由での接続の場合の料金

VTGW は VMware マネージドの AWS Transit Gateway (TGW) です。
この為、料金としては、TGW と全く同じ料金が発生します。VMware Cloud on AWS の料金の一部として請求される形となります。

https://aws.amazon.com/jp/transit-gateway/pricing/

本稿執筆（2023年12月）時点での東京リージョンでの料金は以下の通りです。
 - AWS Transit Gateway のアタッチメントごとの料金 (USD)	0.07USD
 - 処理データ 1 GB あたりの料金 (USD)	0.02USD

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/b5c68fe0-bfd3-4102-9415-5b536e13bdf6.png)



## VTGW - TGW 経由での接続の場合の料金

VTGW で述べた料金に加えて、ピアリングの為のアタッチメントの料金がかかります。（VPC がアタッチされる時と同じ料金です）
ピアリングアタッチメントから VTGW / TGW に送信されるデータにはデータ処理料金は発生しません。

VTGW 側、TGW 側双方でアタッチメントの料金がかかりますが、TGW の料金の大多数は多くのケースで処理データ料金が占める為、VTGW 経由でのパターンと大きな料金の差はないでしょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/b0fc2091-e44d-4425-6512-351dde58b221.png)


# それぞれの接続方法のメリットと考慮点

これまでの内容を元にメリットと考慮点を、他の接続方法との差を中心にまとめてみました。

|      | ENI 経由での接続                                                                                                                          | VTGW 経由での接続                                                                         | VTGW - TGW 経由での接続                                                            |
| ---- | ----------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| メリット | 最も低遅延で接続が可能 <br> 同じ AZ 間の通信の場合、通信料金がかからない。 <br> SDDC デプロイ時に自動でデプロイされる為、シンプルに利用が可能 <br> ネットワークトラフィックの大量に発生するサービスとの接続（例：ストレージサービス）に最適 | SDDC から複数の VPC に接続が可能 <br> ENI に次いで低遅延で接続が可能                                        | 大規模な環境における複雑な通信要件を満たす接続構成 <br> SDDC から複数の VPC に接続できるだけでなく、VPC 同士の通信を含め幅広くカバー |
| 考慮点  | ENI で接続できる VPC は SDDC あたり 1つのみの為、複数の VPC との接続は他の接続パターンと組み合わせる必要がある。                                                                 | VTGW の費用がかかる。<br> VTGW では送信元、送信先のいずれかに SDDC を含んだ通信のみ許可する為、VPC 同士の通信などは Drop されてしまう。 | VTGW / TGW の費用がかかる。（ピアリングアタッチメントの料金分のみ VTGW 経由での接続よりかかる）<br> 他の２つの接続方法と比較すると遅延がやや大きくなる                           |

# まとめ

この投稿では、VMware Cloud on AWS と Amazon VPC の接続として広く利用されている 3 つのパターンについて以下の側面で記載・考察を行いました。

- それぞれの接続パターンの詳細な構成ステップ
- レイテンシーの比較
- 接続料金
- それぞれのメリットと考慮点

この接続方法が正解！というものではなく、要件に応じて使い分けを行います。
VMware Cloud on AWS は今回の構成図で記載した通り、一つの SDDC から複数の接続パターンを組み合わせることができます。
ですので、例えば大規模環境において、複数の VPC との接続を VPC 同士の接続も加味した上で実現するために、VTGW - TGW 経由での接続を行いつつ、トラフィックが大量に発生するストレージサービスとの接続のみ ENI 経由での接続を行う、といった組み合わせが可能です。

# 参考文献

- [VMware Cloud on AWS – Networking Reference Architecture](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/vmware-cloud-on-aws-networking-ra.pdf)
- [AWS Transit Gateway 製品ページ](https://aws.amazon.com/jp/transit-gateway/)