昨日に引き続きAWS Direct Connectのお勉強です。大切なことなので繰り返しますが、私はネットワークについては苦手なので、勘違いしていることがあれば容赦のないマサカリをお願いいたします。
AWS Direct Connectの勉強 - プログラマでありたい
AWS Direct Connectの勉強その２ プライベートVIFの接続パターン - プログラマでありたい
2021-01-07 AWS Direct Connectの勉強その３ パブリックVIF - プログラマでありたい
AWS Direct Connectの勉強その４ Direct Connect GatewayとTransit Gateway - プログラマでありたい
AWS Direct Connectの勉強その５ 経路選択と冗長化 - プログラマでありたい
プライベート接続
単一VPCへの接続
まずはプライベート接続からです。一番、基本的なオンプレミス側のデータセンターとAWSのVPCを一つ接続するパターンです。
データセンター側にルーターが必要となります。ルーターの機能要件としては、下記の4つです。
- BGP サポート
- MD5認証 サポート
- IEEE802.1q サポート
- VLAN サポート
Private VIFをVGW（Virtual Private Gateway）にアタッチし、VPCとデータセンター間の通信を確立します。その際に、異なる2つのネットワークの経路を制御するのがBGP（Border Gateway Protocol）です。BGPを介して、双方のネットワークを広告します。図中に、eBGPと書いていますが、これはExternal BGPの略です。External（外部）という言葉から解るように、異なるネットワーク（AS）間の経路交換です。同一ネットワーク間の間の経路交換の場合はiBGP（Internal BGP）を利用します。この辺りは経路の冗長化のところで説明します。
複数VPCへの接続
開発用VPC・検証用VPC・本番用VPC或いは、システムA用VPC・システムB用VPCと複数のVPCを利用するケースは多いと思います。Direct Connectを利用する企業の場合、むしろ複数VPCを活用しているケースの方が多いのではないでしょうか？ Direct Connectのみで、複数VPCに接続する方法が次の図です。
その解決方法は、ずばりVPCごとにPrivate VIFを用意して異なるVLANを割り振ってそれぞれ接続するという方法です。Direct Connectは基本的には論理的接続であるPrivate VIF単位ではなく物理的な回線であるConnection単位です。そのため、一本のConnectionを複数のPrivate VIFに分割しても料金は基本的には変わりません。（パートナー経由でPrivate VIFを提供されている場合は、そうでないケースは多いと思います。）
一方で、Connectionの全体の帯域をPrivate VIFで分け合うので、Private VIFが増えるとVIF単位の帯域は狭める必要があります。そもそも、VPCの数が数個くらいであれば大きな問題にはなりませんが、10や20或いは100といった単位で利用している場合はVPCごとにPrivate VIFを用意するのは困難です。そこで今まで色々なパターンの接続方法が編み出されてきました。その辺りも紹介していきます。
Transit VPC
複数のVPCに接続するパターンとして昔からあるパターンの一つがTransit VPCです。いわゆるハブアンドスポークネットワークトポロジーの接続形態で、オンプレミスの拠点とハブとなるVPCを接続し、ハブVPCから複数のスポークVPCに接続するというパターンです。スポークとは、車や自転車のタイヤで中心から伸びてるあれです。
※Wikipediaさんから拝借
概念的には普遍的な接続形態だと思うのですが、AWSの場合はTransit VPCというとハブVPC内にCiscoのルーターを置いたものを指すようです。
オンプレミス拠点とハブVPCは、VPNもしくはDirect Connectで接続します。まぁこの文脈だとDirect Connectを利用してくださいですが。ポイントはハブVPCとスポークVPCの接続です。これはハブVPC内に起動したルーター機能を果たすec2インスタンスとスポークVPC間でVPN接続をします。なぜ、AWSの機能であるSite to Site VPNを使わないかというと、AWSのVGWはIPSECのネゴシエーションはしないので、VPC同士でVPNを貼れないからです。そこでルーターの仮想アプライアンスを利用するという形になっています。
実際のTransit VPCの構成は、可用性を確保するために2つのAZにそれぞれ仮想アプライアンスを配置し冗長化した構成になっています。詳細は、下記のページを参照してください。
VPCピアリングのパターン
先程のTransit VPCのパターンと同様にVPC Peeringを使ってHub VPCとSpoke VPCを形成することも可能です。VPCピアリングはVPWを利用したVPN通信ではなく、VPC同士をネットワーク的に通信可能にする機能です。通常のAZ間、或いはリージョン間の通信として扱われるため、Direct Connect GatewayやTransit Gatewayを介した通信より低コストで運用できることが多く、VPCピアリングは今でも採用されるケースが多いように思えます。
ちなみにVPC Peeringは、隣接するVPC同士の通信のみサポートするので、オンプレからspoke VPCのインスタンスに対して直接通信するような透過的通信はできません。
※上のTransit VPCでも同様だと思います。（未確認）
プライベートVIFからのVPC外のAWSサービスへの接続方法
ここまででプライベートVIFの接続パターンや構成パターンを幾つか見ました。さて、S3やLambdaのようなVPC外のAWSサービスにアクセスしたい場合はどうしたら良いのでしょうか？次の図のようにプライベートVIF経由では、VPC外のAWSサービスに直接アクセスすることが出来ません。Direct Connect経由でS3にアクセスしたいというユースケースはわりとありまして、そういった時の接続パターンの一つとしてはVPC内にプロキシ的な役割を果たすEC2インスタンスを用意するといった方法があります。ちょっと面倒くさいですね
そういった用途に応えるためのAWSサービスとして、インターフェース型のVPCエンドポイント（Private Link）があります。これは、VPC内にAWSサービスのエンドポイントをのばしてきて、あたかもVPC内のリソースにアクセスするというサービスです。
なおS3とDynamoDBはVPCエンドポイントに対応しているのですが、ゲートウェイ型VPCエンドポイントという形式です。これを利用しても、オンプレからプライベートVIF経由でS3にアクセスすることはできません。2020年のre:Inventの発表でS3もインターフェース型VPCエンドポイント（Private Link）に対応するという宣言があったので、近い将来利用できるようになるです。
まとめ
Direct ConnectのプライベートVIFについて接続パターンをまとめてみました。プライベートVIFはVPCと１対１で接続するため、複数のVPCを利用している場合は接続パターンに工夫が必要です。今回はプライベートVIFのみで解決する方法を幾つか紹介しています。が、どれも使いにくいというのが正直なところです。その改善として、AWSはDirect Connect GatewayやTransit Gatewayを出してきています。これもそのうち紹介したいです。
今回のDirect Connectの勉強シリーズは、自身の苦手なところの補強。そして、BGPの理解のために書いています。が、なかなかそこまでたどり着かないので、来週に控えたAWS認定アドバンストネットワークに合格できるか不安になってきました
