マルチクラウドにおけるVPNネットワーク相互接続について

GCP入門

Publish Date: 2019-07-20

Update Date: 2020-11-25

Word Count: 1.5k

Read Times: 6 Min

今後「クラウドファースト」から「マルチクラウド」へシフトし「コンテナファースト」となる潮流ではあるが、SD-WANが流行るこのご時世、オンプレとクラウド、クラウド内のリージョン間、クラウドとクラウドをどのようにネットワーク接続するのが最適解なのか、インフラエンジニアとしての興味にかりたたれ、クラウド各社（AWS、Azure、GCP）のネットワーク関連のサービスについて、執筆時点の最新情報を収集しまとめてみました。

カテゴリ：GCP入門合わせて読みたい

1.同一クラウド内のリージョン間のネットワーク接続について

1-1.構成例

日本企業がAWS、Azure、GCPといったクラウドサービスにて環境を構築する場合、

本番環境・・・東京リージョン（or 大阪リージョン）
災対環境・・・本番環境とは別のリージョン

となることがほとんどであり、本番環境と災対環境とでデータの同期を行う場合、双方のネットワークを接続する必要があるが、AWSとAzureはリージョンに紐づくVPCしか作れないため、双方のネットワークを以下のいずれかのサービスを使って接続することがほとんどである。
なお、GCPはデフォルトで1個のVPCはすべてのリージョンにまたがるネットワークを作れるため、ピアリングは不要となる。

AWS・・・VPC ピアリング接続
Azure・・・仮想ネットワークピアリング
GCP・・・Virtual Private Cloud（VPC） | Google Cloud

1-2.問題点

AWSとAzureについては、リージョン毎にVPCが分かれるため、VPCが増えるとネットワーク構成が複雑になり、ネットワーク運用管理が大変となる。
GCPはリージョンをまたぐVPCを作るタイミングで全体最適化を考える思想、設計のため、問題が起こることは少ないと思われる。

AWSのピアリング接続の問題点
- CIDRブロックが一致・重複するVPC間のピアリングが出来ない
- 3個以上のVPCを相互接続する際、フルメシュでピアリング接続しないといけない
Azureのピアリング接続の問題点
- CIDRブロックが一致・重複するVPC間のピアリングが出来ない

2.オンプレミスとクラウドを繋ぐネットワーク構成について

AWS、Azure、GCPを相互接続する場合も、基本はこちらの構成となる。
VPN接続を受ける側はクラウド各社の標準サービスで良いが、VPN接続を開始する側については、IaaS上に「VyOS」等を立てたりする等の工夫が必要であったが、2019年2月にAWSがIKEv2対応したため、標準サービスのみで相互接続することが可能となった。

2-1.構成例

AWS
VPN・・・AWS VPN・・・「AWS サイト間 VPN」と「AWS Client VPN」の2種類がある
専用線・・・Direct Connect
Azure
VPN・・・VPN Gateway・・・「Basic」、「VpnGw1～3」の4種類ある
専用線・・・ExpressRoute

2-2.問題点

AWS、Azure共に「専用線」は高価であり、「VPNゲートウェイ」も性能面、機能面ですべての顧客要件を満たせる万能なサービスではない。いずれもインフラエンジニアがいなくても使えるサービスではあるが、ネットワーク設計を軽んじて、その場しのぎの接続を行っていると、担当者以外が管理出来ないネットワーク構成となる恐れがある。

AWSのVPN接続の問題点
- VPC毎にVPNゲートウェイを作成する必要がある
- VPNトンネル最大10個
AzureのVPN接続の問題点
- 信頼性と可用性をさらに高めるために可用性ゾーン構成が必要である
- VPNトンネル最大30個

3.各社のソリューション（新サービス）について

3-1.AWSの対応

2018/11/26（米国時間）に開幕したイベント「AWS re:Invent 2018」にて発表された「AWS Transit Gateway」というVPCを束ね、VPC同士を中継可能にするサービスがあり、東京リージョンでも使用可能となっているため「VPC毎にVPNゲートウェイを作成する必要がある」という問題は解消する。
ただし、「Azure Firewall」のようなサービスが、執筆時点ではAWSでは提供されていないため、サードパーティ製のセキュリティアプライアンス（WAF、FW等）をセットで組み合わせて使用しないと、公開サービス用途（WEBサイト等）での利用は難しいものと思われる。
余談だが、AWSにはWAFサービスがあり、それをまとめて管理できる「AWS Firewall Manager（東京リージョン対応）」というサービスが出ており、こちらの記事を見ると2018年12月25日にリリースされたようだ。
機能的には「AWS WAF ルール」を一元管理するのみで「Azure Firewall」とはまったく異なるサービスである。

3-2.Azureの対応

「AWS Transit Gateway」のAzure版というイメージを描かせるようなサービス「Azure Virtual WAN」が2018/07/10にプレビューとなっている。このサービスはVPNトンネルが「最大30個」という上限値が「最大1000個」まで引き上げ可能となる。
なお、同時期に「Azure Firewall」もプレビューとなっており、AWSに比べ、機能的には充実しているように感じられる。

3-3.GCPの対応

GCPの場合は、標準でリージョンを跨るネットワークが構成出来るため、AWSやAzureに比べ、東京リージョンのComputeEngine1台と大阪リージョンのComputeEngine1台の合計2台で同一ネットワークで冗長化するという夢のような構成が実現できるため、DRも考慮した設計が可能となる。
この点においては、AWSやAzureに追随を許さない、GCP（Google Cloud Platform）ならではのアドバンテージのように思う。

リージョンまたがりのVPCが作れる
ダウンタイムなしでサブネットの IP 空間を増やすことができる（例：/20→/16）
Google サービスへのプライベートアクセスが可能

なお、「Google Cloud VPN」を使えばオンプレとの接続も可能となっている。
ただし、1拠点のみしかオンプレと繋ぐことができない規約があるようなので注意が必要だ。

VPN と GCP ネットワークを使用して 2 つ以上のオンプレミスロケーションを相互にリンクするハブアンドスポーク構成を作成することは技術的には可能ですが、このような設定は利用規約に違反します。複数のオンプレミスロケーションが関係していなければ、GCP ネットワークのハブアンドスポークリンクを作成できます。
引用元

4.まとめ

2019年2月にAWSがIKEv2に対応したため、AWSをハブとし、Azure、GCPをそれぞれスポークとしたVPN接続構成が可能になっている。各社の良い点を組み合わせた構成とし、プライベートネットワークで連携することで、夢が広がりそうだ。
2020年1月14日の「Windows 7やWindows Server 2008のサポート終了」をきっかけに「Office365」を組み合わせるのであれば「Azureファースト」で検討、「G Suite」を組み合わせるのであれば「GCPファースト」で検討という流れになりそうな気配である。

既にAWSもしくはAzure利用中
GCPへ相互接続（VPN接続）し、GCPが一歩先行く「Kubernetes」でコンテナ化を進めるのが最適であり「Anthos Migrate」を利用することになるだろう
クラウド未利用
　GCPを中心に東京リージョンと大阪リージョンでDR構成を組み、GCPが一歩先行く「Kubernetes」でコンテナ化を進める
　なお、拠点との接続については「Azure Virtual WAN」を利用して複数拠点をハブアンドスポーク接続する
　※GCPとAzureのVPN相互接続については「VPN 相互運用ガイド | Cloud VPN | Google Cloud」にまとめられている

というような方向に進み、2025年頃には「Azure」＞「GCP」＞「AWS」という並び順になるのでは？と勝手に推測しているダディ伯爵である。