AWSの中のネットワークってどうなってるの？
はじめに
ネットワークの仕事をしてますが、"かそう"と言っても仮想ではなくL2L3の"下層"なので、ついこの間までAWSを触る機会はありませんでした。つい最近、ひょんなことからAWSでPoC環境を構築することになり、その便利さに遅ればせながら感動しました。魔法のようにインスタンスを組み合わせ、仮想化基盤を構成できるネットワークサービスは、いったいどういう仕組みになってるんだろうと気になったので、この度検索したblog.ipspace.netや、pages.awscloud.com、sentiatechblog.comのメモを貼っていきます。まだ自分の中で消化できていないので、技術的な表層のみになりますが、詳細は別途続編としてポストしたいと思います。
また、マッピングサービスとBlackfootはAWS公式の情報だけではないので、真偽を保証するものではありません。
AWSインスタンス採用技術の推移
blog.ipspace.netによると、AWS仮想ネットワーキングは以下と解説されています。
AWS仮想ネットワーキングは、インターネットゲートウェイ、VPCからVPCへのピアリング、VPNゲートウェイ、トランジットゲートウェイ、またはダイレクトコネクト（専用線）ゲートウェイを介して外部に接続できる分離された仮想プライベートクラウド（VPC）で実装されます。
AWSの用語解説に関してはここでは割愛しますが、ともかく、用途毎にいろいろなGWを介して相互接続されているということでしょうか。
ではその仮想プライベートクラウド(VPC)と呼ばれるNWの中はどうなっているのかというと、基本はEC2という仮想のVM(インスタンス)を立てて、AWSの様々なサービスと接続されることになります。
その仮想インスタンスは、物理マシンの中にハイパーバイザという仮想化技術の上に構成されます。AWSではかつてハイパーバイザにXenを使っていましたが、今では、Nitroという仮想化専用ハードウェアとソフトウェアの構成で、AWS 開発のカスタムハイパーバイザー(KVMベース)を使っているようです。
Nitroの大きな特徴としてはそれまでソフトウェアで実現してきたことをハードウェアにオフロードする とのことです。
正直なんのこっちゃ、という感じですが、ハイパーバイザーにリソースを割く必要がない分、そうでないサーバと比較してパフォーマンスがあがる、と説明されています。
マッピングサービス
次に、その仮想化技術はどうやって接続されているか、というところですが、AWSの公開資料によると、VPC内部では、マッピングサービスというものを使っているようです。マッピングサービスは、パケットの転送時にARP解決や、フローテーブル生成などを代理で行ってくれるSDNのようです。
ここでsentiatechblog.comの記事を引用すると、インスタンス間で通信を行おうとすると、VirtualRouterに転送され、そこでMappingServiceを参照し、アンダーレイネットワークにて転送される、といった絵になっています。
ただ、blog.ipspace.netによると、以下とあり、詳細は不明のようです。
AWSはオーバーレイ仮想ネットワークを使用しています。どのカプセル化プロトコル（GRE、VXLANなど）またはそれらが使用するコントロールプレーンはわかりませんが、AWSサイズにスケーリングされないため、集中型コントロールプレーンまたはEVPNではないと確信できます。
もともとSDNはコントローラの信頼性が課題だったので、テナントの分離性という意味でも、ここでは分散型のアーキテクチャと見るのが自然でしょうか。
Blackfootエッジデバイス
次にAWS以外との接続はどのようにされているか、というところですが、こちらはBlackfoot edge deviceというものが使われているようです。
以下、IGW、VPG、DX、VPC EndpointといったものがBlackfoot edge deviceを介して接続されている絵になっています。
EIPなどの外部と通信するためのパブリックアドレスは、インスタンス上では確認されませんが、実際にはBlackfootエッジデバイスに割り当てられるようです。
Blackfootエッジデバイスは、パブリックIPアドレスとインスタンスのプライベートアドレスの間で1対1のNATを実行します。
内部的には、同じ仮想ルーターとマッピングサービスが使用されていますが、Blackfootエッジデバイスは、AWS以外のトラフィックとAWSトラフィック間の変換を提供します。
VPCカプセル化のフローは以下の通りとなります。
出典：https://www.sentiatechblog.com/amazon-vpc-the-picasso-of-software-defined-networking
VPCパケット転送の事実
マッピングサービスやBlackfootが使われることから、VPC内でのパケット転送には制限事項も多くあるようです。blog.ipspace.netから、VPCでのルーティング条件を一部引用します。VPCでのルーティング設計では留意が必要です。
・AWS VPCは、ユニキャストIPv4およびIPv6パケット転送をサポートします。
・IPv4マルチキャストはトランジットゲートウェイでサポートされています。
・VMのIPアドレスとMACアドレスは、オーケストレーションシステムによって制御されます。
・MACアドレスは（仮想）ハードウェアパラメータとしてVMに渡されます。
・DHCPは、オーケストレーションシステムで構成されたIPv4およびIPv6アドレスをVMに渡すために使用されます。
・VPCアドレス範囲内の宛先を持つパケットは、オーケストレーションシステムで設定されたIPアドレスに基づいて、入力vNIC（仮想ネットワークインターフェイスカード）から出力vNICに直接配信されます。
・ルートテーブルは、外部の宛先へのトラフィック転送に影響を与えるために使用されます。ルートテーブルのネクストホップは、IPアドレスではなくAWSインスタンス（VM、NIC、インターネットゲートウェイ、VPNゲートウェイ、VPCピアリングなど）です。
・VPC全体が単一の転送ドメイン（VRF）のように動作する場合でも、サブネットごとに異なるルートテーブルを持つことができます。
・別のルートテーブルを入力VPCトラフィックに使用して、サービス挿入を実装できます…ただし、インターネットゲートウェイまたはVPNゲートウェイを介してVPCに入るトラフィックにのみ適用されます。
・ルートテーブルにVPCアドレス範囲内のプレフィックスを含めることはできません。唯一の例外は、ゲートウェイに接続された入力ルートテーブルです。
・ルートテーブルは、オーケストレーションシステムを介して、または外部（VPNまたはDirectConnect）BGPセッションを介して入力できます。
・VMのIPまたはMACアドレスを変更すると、通常、VMが切断されます。
・HSRPやVRRPなどのファーストホップルーティングプロトコルは機能しません。
・あるVMから別のVMにIPアドレスを渡す唯一の方法は、オーケストレーションシステムコールを使用することです。通常のGARPトリックは機能しません。
・インスタンスとAWSVPCルーター間でルーティングプロトコルを実行することはできません。オーケストレーションシステムを使用して、VMインスタンスルートテーブルに基づいてサブネットルートテーブルを変更するか、VPNゲートウェイでBGPを実行することができます。
・同じサブネット内のVM間でルーティングプロトコルを使用し、ルーティングプロトコルがユニキャストIPトラフィックのみを使用する限り、ルーティングプロトコルから派生したルートを共有サブネット全体のパケット転送に使用できます。BGP FTW;）
最後に
ここまで調べて、分かったようで全然分かってないのかもしれませんが、とにかくAWSは、インフラの隅から隅までソフトウェアディファインドの構成をとっており、そのうえ圧倒的に便利で安いということは使ってみて分かりました。
かつて、SDNの登場で職を失うかも、と危惧するも、いまだにアプライアンスのL2L3SWのお仕事があり、世界は急には変わらないなーとお花畑にいる間に、SDNのお仕事ははるか昔にGAFAMに独占されてしまっていたようです。
これからのネットワークエンジニアのお仕事は、パブリッククラウドとパブリッククラウドをつなぐだけのお仕事になる可能性は十分あります。
その日に備えてまずはAWSの勉強を始めようと思います。
この記事が気に入ったらサポートをしてみませんか？