たとえ話で理解する Hyperplane

AWS Hyperplane を「都市の交通インフラ」にたとえて理解しましょう。

🚇 たとえ話:「都市の地下トンネルネットワーク」

大都市には、地上の道路だけでなく、地下に張り巡らされたトンネルネットワークがあります。 水道管、ガス管、電線、地下鉄 — これらは市民には見えませんが、街のすべてのインフラを支えています。 AWS Hyperplaneは、AWSクラウドにおけるこの「地下インフラ」です。 NLB(ロードバランサー)やNAT Gatewayなどのサービスは「地上の建物」にあたり、 それらの裏側でパケット転送・フロー追跡を高速に処理しているのがHyperplaneです。

🏢
地上の建物 = AWSサービス
NLB、NAT Gateway、PrivateLink、Transit Gatewayなど、利用者が直接操作するサービスたち。たとえるなら「レストラン」「オフィス」「病院」のような地上施設です。
🚇
地下トンネル = Hyperplane
利用者からは見えないが、建物同士を繋ぐ高速地下トンネル。水・電気・通信をマイクロ秒で届ける基盤。これがないと地上の建物は機能しません。

Hyperplane の主要スペック

公開されている技術情報から、Hyperplaneの規模感を理解しましょう。

数十μs
トランザクション
レイテンシ
5 GB/s
ノード1台あたり
帯域幅
数百万
秒間接続数
(リージョン全体)
Tbps級
リージョン全体
帯域幅
💡
Hyperplaneは大容量メモリを搭載した専用EC2インスタンス上で動作しています。 すべてのトランザクションをメモリ内で処理することで、ディスクI/Oのボトルネックを排除し、数十マイクロ秒という超低レイテンシを実現しています。

Hyperplane アーキテクチャ全体像

AWSサービス → Hyperplane → 物理インフラの3層構造を図解します。

Hyperplane 3層アーキテクチャ
利用者が触るサービス → Hyperplane基盤 → 物理インフラ
▲ 利用者が操作するサービス層
⚖️ NLB
🌐 NAT Gateway
🔒 PrivateLink
🔗 Transit GW
Lambda VPC
📁 EFS
🚀 App Runner
🛡️ Gateway LB
すべて Hyperplane を利用
🔶 AWS Hyperplane
Network Function Virtualization(NFV)基盤
📡 パケット転送
🔄 フロー追跡
🧩 シャッフルシャーディング
大容量メモリ EC2 上で動作
▼ 物理インフラ層(利用者からは見えない)
🖥️ EC2 インスタンス
(大容量RAM)
🌍 各AZに分散配置
(高可用性)
🔌 VPC物理ネットワーク
(パケットカプセル化)

コントロールプレーン vs データプレーン

Hyperplaneの内部は「頭脳」と「手足」の2つの役割に分かれています。

🗺️ たとえ話:「GPSナビ」と「道路そのもの」

カーナビ(GPS)は「どのルートで行くべきか」を判断・計画します。 一方、道路そのものは車が実際に走る場所です。 仮にGPSが一時的に故障しても、すでに道を知っている車は走り続けられます。 コントロールプレーンはGPSナビ、データプレーンは道路にあたります。

Hyperplane の 2つのプレーン
設定管理と実際のトラフィック処理を分離する設計
🧠 コントロールプレーン
🗺️ GPSナビに相当
📝 DynamoDBに顧客設定(NLBルール、NATマッピング等)を保存
📦 定期タスクで設定をS3ファイルに書き出す
🔄 データプレーンにルーティング設定を配信
🛡️ 障害時もデータプレーンは既存の設定で動作継続
設定配信
🚗 データプレーン
🛣️ 道路そのものに相当
📡 実際の顧客トラフィック(パケット)を処理・転送
🗄️ S3から設定をダウンロードしてローカルキャッシュに反映
メモリ内トランザクションで数十μsの超低レイテンシ
🔄 各AZに分散配置されたHyperplaneノードで実行
⚠️
なぜ分離するのか? コントロールプレーンが一時的にダウンしても、データプレーンはすでにキャッシュした設定で稼働し続けます。 これにより、設定変更のための管理系の障害が「通信断」に直結しない耐障害性を実現しています。

Hyperplane が支えるAWSサービス

Hyperplaneは8つ以上のAWSサービスのバックエンドとして機能しています。

⚖️
NLB
Network Load Balancer
L4ロードバランサー。静的IPを維持しつつ、裏側のHyperplaneノードが水平スケール。
Hyperplaneの役割:フロー追跡でクライアントを同一ターゲットに維持
🌐
NAT Gateway
ネットワークアドレス変換
プライベートサブネットからのインターネット接続を仲介。IPポートの一意性を保証。
Hyperplaneの役割:IP:ポートペアの一意性管理とアドレス変換
🔒
PrivateLink
VPC間プライベート接続
VPCピアリングなしでサービスにプライベートアクセス。インターネットを経由しない安全な通信。
Hyperplaneの役割:VPC間のトンネル接続を実現
🔗
Transit GW
VPCハブ接続
複数VPCやオンプレミスを中央ハブで接続。AZアフィニティを維持した転送。
Hyperplaneの役割:VPC間パケット転送とAZ内ルーティング
Lambda VPC
Lambda関数のVPC接続
Lambda関数がVPCリソースにアクセスする際のENI共有。同一サブネット+SGの関数はENIを共有。
Hyperplaneの役割:Hyperplane ENIを通じたVPC接続の効率化
📁
EFS
Elastic File System
複数AZのEC2やLambdaから同時アクセス可能な共有ファイルシステム。
Hyperplaneの役割:マウントターゲットへの高スループット接続
🚀
App Runner
マネージドWebアプリ
Fargate VPCとユーザーVPCを接続。VPCコネクタ作成時にHyperplane ENIを生成。
Hyperplaneの役割:Fargate-顧客VPC間のトンネル通信
🛡️
Gateway LB
サードパーティアプライアンス
ファイアウォール等のサードパーティアプライアンスにトラフィックを透過的に転送。
Hyperplaneの役割:トラフィックのインラインインスペクション

シャッフルシャーディング — ノイジーネイバー対策

マルチテナント環境で、特定顧客の大量トラフィックが他の顧客に影響しない仕組みを図解します。

🏥 たとえ話:「病院の担当医ランダム割り当て」

病院に8人の医師がいるとします。従来の方法では4つの部門に2人ずつ配置(通常シャーディング)。 1部門に患者が殺到すると、その部門の医師が手一杯になり他の患者も診られません。 シャッフルシャーディングでは、各患者にランダムに3人の医師を割り当てます。 ある患者が大量に医師を使っても、他の患者と共有する医師は確率的に少なくなり、影響範囲が最小化されます。

通常シャーディング vs シャッフルシャーディング
8つのHyperplaneノードを3ユーザーで利用する場合の比較
❌ 通常シャーディング
固定でノードを分割
N1
N2
N3
N4
N5
N6
N7
N8
🔴 影響範囲
= 全ユーザーの25%
↓ シャッフルシャーディングに変更すると...
✅ シャッフルシャーディング
ランダムにノードを割当
N1
N2
N3
N4
N5
N6
N7
N8
🟢 影響範囲
≒ 確率的に極小
🔴 ノイジーネイバー(大量トラフィック発生) 🟢 通常ユーザーA 🟣 通常ユーザーB
📐
ポイント:実際のHyperplaneでは非常に多くのノード数とユーザー数があるため、 あるノイジーネイバーと別のユーザーが同じノードを共有する確率はさらに低下します。 ノード数が増えるほど、シャッフルシャーディングの効果は指数的に高まります。

Hyperplane ENI の仕組み

Hyperplaneがサービスとユーザーのリソースを接続する「窓口」の仕組みを理解しましょう。

📮 たとえ話:「共有私書箱」

通常のENI(ネットワークインターフェース)は、1つのEC2に対して1つの「専用ポスト」のようなものです。 一方、Hyperplane ENI は「共有私書箱」です。 複数のLambda関数やApp Runnerサービスが同じサブネット + セキュリティグループの組み合わせであれば、 1つのHyperplane ENIを共有できます。 これにより、ENI上限に達することなく、大量のサービスをVPCに接続できます。

Hyperplane ENI が作成される流れ
Lambda VPC接続の場合の例
1
Lambda関数作成
VPC接続設定でサブネットとセキュリティグループを指定
2
ENI検索
同じサブネット+SG組み合わせの既存Hyperplane ENIがあるか確認
3
ENI作成 or 再利用
なければ新規Hyperplane ENIを作成(約90秒)、あれば既存のものを共有
4
トンネル確立
LambdaのVPCとユーザーのVPCがHyperplane ENI経由で接続完了
🔌
通常の ENI
1つのEC2インスタンスに紐づく専用のネットワークインターフェース。プライベートIPが割り当てられ、そのインスタンスだけが使用する。ENI数にはVPCの上限がある。
Hyperplane ENI
同じサブネット+セキュリティグループの組み合わせを使う複数のサービス間で共有できる特殊なENI。ENI上限を節約しつつ、高スループット・低レイテンシの接続を実現。

フロー追跡(Flow Tracking)

Hyperplaneの中核機能であるフロー追跡の仕組みと重要性を解説します。

🎯 たとえ話:「ホテルのフロント係」

ホテルのフロント係は、チェックイン時にお客さまに部屋番号を割り当て、 お客さまが滞在中は常に同じ部屋に案内します。 もし毎回ランダムな部屋に案内したら、荷物は迷子になり大混乱です。 Hyperplaneのフロー追跡は、通信の「お客さま」であるパケットフローを追跡し、 常に正しい宛先に届ける役割を担っています。

サービス フロー追跡で保証すること 追跡しないとどうなるか
⚖️ NLB 同じクライアントの通信を常に同じターゲットインスタンスへ転送 セッションが切れ、TCPコネクションが壊れる
🌐 NAT GW 各「送信元IP:ポート」ペアに一意な外部ポートを割り当て ポート衝突が発生し、通信が混線する
🔒 PrivateLink プロバイダーVPCとコンシューマーVPC間のセッション維持 VPC間の通信が断続的に切断される
🛡️ Security Groups 受信トラフィックに対応する送信ポートの自動解放(ステートフル) 戻りトラフィックがブロックされ通信不能に

Hyperplane の進化タイムライン

2015年の本番投入から現在まで、Hyperplaneは対応サービスを拡大し続けています。

2015年 — 本番環境で稼働開始
AWSの内部サービスとしてHyperplaneが本番環境にデプロイ。初期はNAT Gatewayのバックエンドとして利用。
2017年 — NLBリリース & re:Invent公開
Network Load Balancerの基盤として採用。re:Invent 2017の「Another Day, Another Billion Flows」セッションで初めて公に紹介。
2019年 — Lambda VPCネットワーキング刷新
Lambda関数のVPC接続がHyperplane ENIベースに刷新。コールドスタート問題が大幅に改善。ENI共有によりスケーラビリティが向上。
2020年〜 — 対応サービス拡大
Transit Gateway、Gateway Load Balancer、App Runner VPC接続など、より多くのサービスがHyperplaneベースに。AWSのネットワーキングの共通基盤として確立。

VPCアイソレーションとHyperplane

Hyperplaneは顧客のVPC分離をどう維持しているのか、セキュリティの観点から解説します。

🏨 たとえ話:「ホテルの配管システム」

ホテルの各部屋には水道があり、配管は建物全体で共有されています。 しかし、別の部屋の蛇口から他の部屋の水を出すことは絶対にできません。 Hyperplaneも同様に、複数の顧客のトラフィックを処理しますが、 VPCパケットのカプセル化により、他のVPCのデータが見えることはありません。 Hyperplaneはフロー追跡のみを行い、VPCの分離は物理ネットワーク層が担保します。

🔒
VPCカプセル化
パケットはVPC固有のヘッダでカプセル化され、物理ネットワーク上でも他のVPCのデータと混在しない。
🧩
フロー単位の処理
Hyperplaneはフロー(通信の流れ)単位でしか処理せず、パケットの中身には一切アクセスしない。
🛡️
多層防御
仮にHyperplane層に脆弱性があっても、VPCアイソレーションは下位レイヤーが担保するため、分離は維持される。

よくある質問

Q Hyperplaneは直接設定したり操作したりできますか?
いいえ。Hyperplaneは完全にAWSの内部サービスであり、利用者が直接操作することはできません。NLBやNAT Gatewayなどのサービスを使うと、自動的にHyperplaneが裏側で動作します。利用者はHyperplaneの存在を意識する必要はありませんが、トラブルシューティング時にHyperplane ENIのIDがCloudTrailログに出現することがあります。
Q Hyperplaneに障害が起きたらどうなりますか?
Hyperplaneは各AZに分散配置されており、シャッフルシャーディングにより単一ノードの障害の影響範囲は極めて小さくなっています。また、コントロールプレーンとデータプレーンが分離されているため、設定系の障害がトラフィック処理に直結しません。AWSのサービスSLAは、このHyperplaneの高可用性設計を前提として提供されています。
Q 「Hyperplane ENIの上限を超えました」エラーが出たらどうすればいいですか?
Lambda関数をVPCに接続する場合、Hyperplane ENIにも上限があります。同じサブネット+セキュリティグループの組み合わせを使う関数はENIを共有するため、不要な組み合わせの多様化を避けることが重要です。上限緩和はAWSサポートに申請できます。CloudTrailのデータイベントでHyperplane ENI IDを確認し、どの関数がどのENIを使用しているか監査することも可能です。
Q Transit Gatewayを使うとVPCピアリングより遅くなるのはHyperplaneのせいですか?
Transit Gatewayは確かにVPCピアリングに比べてネットワークホップが増えるため、わずかなレイテンシが加わります。これはHyperplaneノードを経由するためですが、AWSはAZアフィニティ設計により同一AZ内でのトラフィック転送を優先するなど最適化しています。ほとんどのユースケースでは影響は軽微ですが、超低レイテンシが求められる場合はVPCピアリングが適切な選択肢です。
Q ALB(Application Load Balancer)もHyperplaneを使っていますか?
ALBはHyperplaneベースではありません。ALBとNLBは異なる技術基盤で構築されています。NLBがHyperplane上で動作するのに対し、ALBは独自のスケーリングシステムを持っています。このため、NLBは静的IPを提供できますが、ALBはDNSベースのスケーリングを行い、IPが変動します。
📝 まとめ:AWS Hyperplane の要点
HyperplaneはNLB・NAT GW・PrivateLink・Lambda VPCなど多くのサービスを支える内部NFV基盤
大容量メモリEC2上で動作し、メモリ内トランザクションで数十μsのレイテンシを実現
コントロールプレーン(設定管理)とデータプレーン(トラフィック処理)の分離で高可用性を確保
シャッフルシャーディングによりノイジーネイバー問題の影響を確率的に最小化
Hyperplane ENIは共有可能な特殊ENIで、Lambda等のスケーラビリティ問題を解決
VPCアイソレーションはHyperplaneの下位レイヤーが担保し、セキュリティは多層防御
利用者がHyperplaneを直接操作することは不可 — 完全にAWS内部のサービス
2015年から本番稼働し、AWSのネットワーキングの共通基盤として進化し続けている

Created by SSuzuki1063

AWS SAP Learning Resources