はじめに
AWS EC2 のインスタンスタイプには、Up to 10 Gbps、25 Gigabit のようなネットワーク性能表記がある。
この表記は、一見すると「そのインスタンスで利用できる帯域」を示しているように見える。
しかし、通信キャリア NFV、閉域接続サービス、仮想 Firewall、IPsec gateway、NAT gateway、IDS/IPS のように、EC2 をネットワークサービスの処理基盤として使う場合、この読み方は危険である。
重要なのは、EC2 が高性能なネットワークを提供できるかどうかではない。
問題は、EC2 のネットワーク性能モデルを、帯域確保サービスの根拠として扱えるかどうかである。
結論から言えば、EC2 の Up to 表記を帯域確保の根拠として扱うことはできない。
一方で、baseline bandwidth については慎重に扱う必要がある。AWS 公式情報から確認できる範囲では、baseline を guaranteed bandwidth と明示している記述は見つからない。また、baseline そのものを一般論として not guaranteed と直接定義している記述も確認できない。
また、burst bandwidth については shared resource に依存する best effort と説明されている。
したがって、EC2 のネットワーク帯域は「カタログ上の最大値」ではなく、「baseline を選定上の基準値として扱いつつ、flow、経路、allowance、VNF 処理性能などの制約を差し引いた結果として成立する実効性能」として読むべきである。
論点は「最大帯域」ではなく「帯域確保に耐えるか」
EC2 のネットワーク性能を語るとき、Up to 10 Gbps のような最大値に注目しやすい。
しかし、帯域確保型サービスの観点では、最大値よりも次の問いが重要になる。
その帯域を、どの条件で、どの時間幅で、どの通信形態に対して、サービス仕様上の根拠として提示できるのか。
この問いに対して、EC2 の Up to 表記だけでは答えられない。
なぜなら、Up to は baseline と burst を含む条件付きの最大性能であり、常時利用可能な帯域を意味しないためである。
帯域確保型サービスで必要になるのは、瞬間的に出る最大値ではない。継続通信、単一 flow、トンネル、PPS、セッション数、経路、障害時の切替まで含めて、サービスとして説明可能な性能境界である。
キャリア NFV 文脈での問題
通信キャリア NFV の文脈では、この問題が最初から中心になる。
キャリアサービスでは、顧客に対して「最大帯域」「保証帯域」「閉域接続」「SLA」「帯域確保」といった表現を使う場合がある。
このとき、EC2 の Up to 表記をそのまま提供帯域の根拠にすると、意味がずれる。
| 文脈 | 10 Gbps の意味 |
|---|---|
| キャリアサービス側 | 提供帯域または帯域確保の根拠 |
| EC2 側 | baseline と burst を含む条件付き最大値。baseline は選定基準になり得るが、Up to 全体は帯域確保の根拠ではない |
この 2 つを同じ意味として扱うと、設計、課金、SLA、責任分界の前提が崩れる。
AWS 上で NFV 的な構成を成立させるには、AWS 側の制約をサービス仕様へ写像する必要がある。
提供可能帯域は、少なくとも以下の最小値として考える必要がある。
| 評価対象 | 内容 |
|---|---|
| 自社アクセス回線帯域 | 顧客接続側や閉域網側で定義される帯域 |
| Direct Connect / VIF / Gateway 側の制約 | AWS 接続経路側の上限 |
| EC2 baseline bandwidth | インスタンスタイプ選定の基準帯域 |
| single-flow 上限 | 単一 flow や tunnel 外側 flow の制約 |
| PPS allowance | packet per second の上限 |
| tracked connection allowance | connection tracking の上限 |
| VNF 処理性能 | ゲスト OS、アプライアンス、暗号化、Firewall 処理の上限 |
ここでの論点は、AWS で NFV が技術的に動くかどうかではない。
サービスとして提示している帯域の意味を、AWS のネットワーク性能モデルへ正しく写像できるかである。
EC2 の帯域表記と baseline の扱い
EC2 のインスタンスタイプに記載される network performance は、帯域確保を意味しない。
特に Up to 表記のインスタンスでは、network I/O credit mechanism により、baseline bandwidth を超えて burst できる場合がある。
この構造は、次のように整理できる。
| 要素 | 意味 |
|---|---|
Up to bandwidth | baseline bandwidth と burst bandwidth を含む条件付き最大値 |
baseline bandwidth | burst に依存しないインスタンスタイプ選定上の基準値 |
burst bandwidth | network I/O credit と共有リソース状況に依存する一時的な上振れ |
baseline bandwidth は、AWS がインスタンスタイプ選定に使う性能属性である。
baseline bandwidth は、burst に依存しない基準値として扱える。
ただし、AWS が baseline を guaranteed bandwidth と明示しているわけではない。また、baseline そのものを一般論として not guaranteed と直接定義しているわけでもない。
確認できるのは、baseline が burst とは区別される値として扱われていること、EC2 SLA が帯域値を保証する形ではないこと、そして burst bandwidth は shared resource に依存する best effort と説明されていることである。
一方、burst bandwidth は network I/O credit と共有リソース状況に依存する一時的な上振れである。credit が残っていても、burst は shared resource に依存する best effort として扱われる。
したがって、Up to 10 Gbps と書かれていても、それは 10 Gbps の帯域確保を意味しない。
ここで分けるべきなのは、「設計基準にできる」「確保されると読めるか」「保証されると読めるか」という 3 つの意味である。
| 観点 | baseline bandwidth の扱い |
|---|---|
| 設計基準 | burst に依存しない基準値として扱える |
| AWS 公式の位置づけ | guaranteed bandwidth とも not guaranteed とも明示されていない |
| SLA 上の扱い | EC2 SLA は帯域値を保証する形ではない |
| burst | shared resource に依存する best effort と明示されている |
| 顧客提示の根拠 | 単独で帯域確保サービスの保証値として提示するのは危険 |
AWS の EC2 SLA が対象にしているのは、Region-Level / Instance-Level の稼働率や external connectivity であり、baseline bandwidth を何 Gbps 以上保証する、という形ではない。
さらに、実効性能は baseline だけで決まらない。次に見る flow、経路、PPS、tracked connections、ENA allowance、アプリケーション処理性能が別の上限になる。
flow 制約は帯域確保型サービスで問題になりやすい
baseline を満たすインスタンスタイプを選んでも、それだけで提供可能帯域は決まらない。
EC2 のネットワーク性能では、インスタンス全体の帯域だけでなく、single-flow の上限が重要になる。
特に、IPsec、GRE、VPN、トンネル、バックアップ、レプリケーション、閉域接続、NFV のような用途では、通信が少数の外側 flow に集約されやすい。
TCP / UDP の場合、flow は一般に source IP、destination IP、source port、destination port、protocol の 5-tuple で分類される。
一方、GRE や IPsec のような通信では、外側ヘッダの source IP、destination IP、next protocol によって分類される。
この場合、トンネル内部に多数のユーザー通信が存在していても、AWS 側の flow 分類では少数 flow として扱われる可能性がある。
| 視点 | 見え方 |
|---|---|
| VNF / ゲスト OS から見た論理 | 多数のユーザー通信、多数の TCP / UDP セッション |
| AWS 側の flow 分類 | 外側ヘッダに基づく少数 flow |
| 性能上の帰結 | multi-flow 帯域ではなく single-flow 上限に寄る可能性 |
これは、帯域確保型サービスにとって重要である。
サービス側で「多数ユーザーの合計帯域」として設計していても、AWS 側では外側トンネルの flow 制約に引っかかる可能性があるためである。
経路によって使える帯域は変わる
EC2 の available bandwidth は、すべての通信経路で同じように使えるわけではない。
VPC 内のインスタンス間通信、Internet Gateway 経由の通信、Local Gateway 経由の通信、Direct Connect 経由の通信では、それぞれ評価すべき制約が異なる。
つまり、インスタンス仕様上の available bandwidth は、そのまま特定経路の利用可能帯域にはならない。
インスタンス仕様上の available bandwidth と、特定経路で実際に利用できる帯域は区別して扱う必要がある。
帯域確保型サービスとして EC2 を使う場合、インスタンス単体の性能ではなく、通信経路全体で最小となる制約を見る必要がある。
Gbps だけでは評価できない
EC2 のネットワーク性能は Gbps だけでは決まらない。
小さいパケットが大量に流れる場合、PPS が先に上限になることがある。
多数のセッションを扱う場合、tracked connections が制約になることがある。
Firewall、NAT、IPsec gateway、IDS/IPS、VNF のような用途では、帯域よりも先に PPS、connection tracking、CPU、暗号化処理、カーネル処理、アプライアンス側の実装性能が上限になることがある。
したがって、帯域確保型サービスの設計では、少なくとも次の観点を分ける必要がある。
| 観点 | 評価対象 |
|---|---|
| 帯域 | Gbps / baseline / available bandwidth |
| flow | single-flow / multi-flow / tunnel 外側 flow |
| packet | PPS / packet size / microburst |
| session | tracked connections / NAT table / state table |
| 経路 | VPC 内、IGW、LGW、DX、TGW、GWLB |
| 処理 | VNF、暗号化、Firewall、OS、アプリケーション |
| 観測 | CloudWatch、ENA metrics、Flow Logs、アプリケーションログ |
EC2 の帯域設計は引き算で読む
EC2 のネットワーク帯域は、カタログ値を足し算で読むものではない。
最大値を見て「ここまで使える」と考えるのではなく、各制約を順に適用して、最後に残る性能を見る必要がある。
設計上は、以下の制約の最小値として読むのが安全である。
| 制約 | 内容 |
|---|---|
| available bandwidth | インスタンス仕様上の最大性能 |
| baseline bandwidth | burst に依存しない選定上の基準帯域 |
| single-flow 上限 | 単一 flow や tunnel 外側 flow の上限 |
| multi-flow の経路制約 | 通信経路によって変わる aggregate 側の上限 |
| IGW / LGW / DX / TGW 側の制約 | AWS 接続経路や gateway 側の上限 |
| PPS allowance | packet per second の上限 |
| tracked connection allowance | connection tracking の上限 |
| ENA allowance | ENA が示す instance-level network allowance |
| VNF / アプリケーション側の処理性能 | ゲスト OS、アプライアンス、暗号化、Firewall、アプリケーションの処理上限 |
この整理は厳密な AWS 内部実装の表現ではない。
設計者が EC2 のネットワーク性能を読むための考え方である。
EC2 の帯域は、最大値を根拠にするのではなく、制約の最小値として評価する必要がある。
EC2 は帯域確保サービスの基盤として使えるのか
ここで、最初の問いに戻る。
EC2 は帯域確保サービスの基盤として使えるのか。
答えは、条件付きである。
EC2 を使って高帯域な通信処理を行うことはできる。大きいインスタンス、適切な ENA、Placement Group、複数 flow、適切な経路設計、十分な PPS / conntrack 余力、VNF 側の処理性能が揃えば、高い実効性能を出せる。
しかし、EC2 の Up to 表記や baseline を、そのまま帯域確保の根拠として使うことはできない。
baseline は設計上の基準値としては使えるが、顧客向けの保証帯域として提示するには、flow、経路、PPS、tracked connections、ENA allowance、VNF 処理性能、実測値を含めてサービス仕様へ写像する必要がある。
帯域確保サービスとして扱うには、少なくとも次をサービス仕様へ明示的に取り込む必要がある。
| 項目 | 明示すべき内容 |
|---|---|
| baseline | burst に依存しない設計基準値として扱えるが、guaranteed bandwidth と明示されているわけではないこと |
| burst | 一時的な上振れであり、保証帯域ではないこと |
| flow | single-flow / multi-flow / tunnel flow の上限 |
| 経路 | DX、TGW、GWLB、IGW、LGW など経路ごとの制約 |
| PPS | 小パケット時の上限 |
| session | tracked connections / NAT / Firewall state の上限 |
| 観測 | CloudWatch だけでなく ENA metrics などを見ること |
| VNF 性能 | EC2 ではなくゲスト OS / アプライアンス側の処理上限 |
| SLA | AWS 側性能モデルと自社サービス仕様の責任分界 |
このように制約を明示し、提供帯域を各制約の最小値として定義するのであれば、EC2 を含むクラウド基盤上で帯域サービスを設計する余地はある。
一方で、オンプレミスやキャリア回線サービスの「帯域確保」の意味をそのまま EC2 に持ち込むと、説明が成立しにくい。
まとめ
EC2 の Up to 10 Gbps は、帯域確保を意味しない。
Up to 表記のインスタンスでは、baseline bandwidth と burst bandwidth を分けて読む必要がある。baseline は burst に依存しない設計基準値として扱える一方、burst は network I/O credit と共有リソース状況に依存する一時的な上振れである。
ただし、baseline を guaranteed bandwidth と明示している AWS 公式記述は確認できない。また、baseline そのものを一般論として not guaranteed と直接定義している記述も確認できない。
また、EC2 のネットワーク性能は Gbps だけでは決まらない。single-flow、multi-flow、トンネル外側 flow、経路制約、PPS、tracked connections、ENA allowance、VNF / アプリケーション側の処理性能が別の上限になる。
したがって、EC2 の帯域設計は、カタログ値や baseline だけで読むのではなく、制約を順に差し引いて読む必要がある。
帯域確保型サービスとして EC2 を使う余地はある。しかし、それは Up to 表記や baseline をそのまま保証帯域として扱うことではない。
EC2 を帯域確保サービスの基盤として扱うには、baseline をインスタンスタイプ選定の入口にしつつ、提供帯域を flow、経路、allowance、VNF 処理性能、実測で確認できる安定値へ写像し、その最小値として定義する必要がある。
EC2 のネットワーク性能は、最大帯域ではなく、制約を適用した後に残る実効性能として読むべきである。
