0. はじめに
運用拠点等とVPCをIPSecでセキュアに接続するための機能としてサイト間VPN(AWS Site-to-Site VPN)がありますが、AWS Global Acceleratorを使って高速化するAcceleratedサイト間VPNオプションがあることはご存知でしょうか。このオプションについて、実際にどの程度効果があるものなのかわからなかったため、簡易的に検証してみました。
Acceleratedサイト間VPNオプション
引用元:202110 AWS Black Belt Online Seminar AWS Site-to-Site VPN
目次
0. はじめに
1. サイト間VPNの構成
2. アクセラレーションの設定方法
3. 検証
4. まとめ
1. サイト間VPNの構成
サイト間VPNでは拠点側のルータとAWSリソースの間でIPSec接続しますが、接続できるAWS側のリソースとしてはVGW(Virtual private gateway)とTGW(Transit gateway)の2種類があります。TGW接続のほうが高機能な分、複雑でコストがかかるため要件に合わせて選択する必要があります。また、冗長化方法についてもいくつか検討要素があります。
■VGW接続
- 単一のVPCと接続する
- AWS→拠点の速度は複数VPN接続しても合計が1.25Gbps以内に制限される(注1)
- パブリックIPによるVPN接続のみ可能
■TGW接続
- 複数のVPCと接続できる
- VPN接続あたりは最大1.25Gbpsだが複数接続してECMP(Equal Cost Multi Path)でAct-Act接続により合計帯域を増やせる
- Transit VIFを使ってDirect Connect経由のプライベートIPによるVPN接続も可能
- Acceleratedサイト間VPNオプションによりAWS Global Acceleratorを使って接続を安定・高速化できる
- Transit gatewayの処理量・アタッチメントによる費用がかかる
(注1)読み解き辛いですが以下QAはこういう意味のようです。
AWS VPN のよくある質問
Q: 仮想プライベートゲートウェイには集約されたスループット制限がありますか?A: 仮想プライベートゲートウェイには、接続タイプごとの集約スループット制限があります。同じ仮想プライベートゲートウェイへの複数の VPN 接続は、AWS から最大 1.25 Gbps のオンプレミスへの集約スループット制限によってバインドされます。仮想プライベートゲートウェイ上の AWS Direct Connect 接続の場合、スループットは Direct Connect 物理ポート自体によって制限されます。複数の VPC に接続し、より高いスループット制限を達成するには、AWS Transit Gateway を使用します。
今回検証したアクセラレーションはTGW接続でだけ利用できるものです。
2. アクセラレーションの設定方法
サイト間VPNはマネジメントコンソールの「VPC」→「Site-toSite VPN 接続」→「VPN接続を作成する」から作成できます。アクセラレーション設定は「ターゲットゲートウェイのタイプ」で「Transit Gateway」を選択すると表示される「アクセラレーションの有効化」でチェックを付けて作成することで有効化できます。
3. 検証
サイト間VPNの性能をきちんと検証するには実際にトンネル接続してオンプレ機器とVPC上のリソースとを通信させる必要がありますが、今回は簡易的に検証するためアクセラレーションの有無でAWS側のVPN終端ポイントまでの通信遅延がどう変わるかを確認しました。
※限られた条件での検証なので場所や時間などによって変動する可能性があることに留意し、参考程度に見ていただければと思います。
以下のパターンで拠点からパブリックIPアドレスまでの通信にかかる時間とTTLをpingで確認しました。
- 拠点(ping送信元)のIPは東京都内のIPと、検証に使ったGoogle Cloud Shellで割り当てられた台湾のIP
- サイト間VPNでアクセラレーション有効/無効
- AWS側のIPはVPN接続を作成すると割り当てられる2トンネル分のIP
各IPアドレスが地理的にどのあたりとして登録されているかはこちらのサイトで確認してみました。
結果は以下の通りです。VPNは東京リージョンで作成し、オンプレミス拠点(ping送信元)としては東京都内のIPと、検証に使ったGoogle Cloud Shellで割り当てられた台湾のIPを使ってみました。
オンプレミス 拠点IP |
アクセラレータ 有効/無効 |
AWS側IP | 遅延 | TTL |
---|---|---|---|---|
東京都内 | 無効 | 東京都内 (1つ目) |
平均12ms (12ms~14ms) |
244 |
東京都内 | 無効 | 東京都内 (2つ目) |
平均13ms (13ms~14ms) |
247 |
東京都内 | 有効 | アクセラレータ用IP (1つ目) |
平均15ms (12ms~24ms) |
250 |
東京都内 | 有効 | アクセラレータ用IP (2つ目) |
平均11ms (11ms~12ms) |
250 |
台湾 | 無効 | 東京都内 (1つ目)) |
平均36ms (36.2ms~36.7ms) |
246 |
台湾 | 無効 | 東京都内 (2つ目) |
平均35ms (35.4ms~39.8ms) |
249 |
台湾 | 有効 | アクセラレータ用IP (1つ目) |
平均4ms (3.8ms~4.5ms) |
246 |
台湾 | 有効 | アクセラレータ用IP (2つ目) |
平均3.9ms (3.8ms~4.3ms) |
248 |
アクセラレータを無効にした状態では作成したリージョンである東京都内として登録されたIPがVPNに割り当てられましたが、アクセラレータを有効にした状態ではアメリカとして登録されたIPが割り当てられました。ただし、ドメインは「awsglobalaccelerator.com」というアクセラレータ用のものでありIP Anycastを利用して近くのエッジロケーションからアクセスするためのIPになっているようです。
都内からのpingではどちらにアクセスしても遅延はあまり変わらず、内部で選択される物理機器ごとの差のほうが大きそうでした。台湾からのpingではアクセラレーションによって大幅に遅延が短縮できました。TTLについてはそれほど大きな差は見えませんでした。
以上の結果と公式資料(35ページ目)から、都内のような通信設備が整った地域から同リージョンのVPNへの通信ではアクセラレーションの効果がほとんどなさそうです。通信が遅い地域を通ったり遠いリージョンにVPN接続する場合にはアクセラレーションで速度向上が見込める、ということになりそうです。ただし、同資料によるとアクセラレーション無しの場合時折可用性が低下が見られる場合もあるとのことなので長時間の検証では都内のような環境でも違いが見られるかもしれません。
ちなみに、冒頭で示したBlack Belt資料にあるGlobal Acceleraterのスピードテストでは東京都内から東京リージョンでも以下のように差が出ていましたが、これはあくまでファイルのダウンロードであり、Global Acceleraterを使った場合は拠点からエッジまでの接続となるためと考えられます。VPN接続する場合はエッジまでではなくリージョン内のTransit Gatewayまで接続する必要があるので、サイト間VPNの性能改善効果を見るにはあまり適切ではないと考えます。
4. まとめ
サイト間VPNのアクセラレーションにどのくらい効果があるかをpingにより検証したところ、接続する地域の通信設備の状況と距離によって効果の有無が変わりそうだという結果になりました。(Global Acceleraterの用途はそもそも海外拠点接続などの不安定要素を軽減するものということなので期待通りの結果ではあります。)
サイト間VPNのアクセラレーション採否の検討に当たっては要件として可用性の低下をどれだけ許容できるかを確認した上で、採用しようとしている区間で実際に遅延に差が出るかを検証してみるのが良さそうです。
※ 本ブログに記載した内容は個人の見解であり、所属する会社、組織とは全く関係ありません。