AWS EC2 の「最大 10Gbps」は帯域確保ではない

baseline bandwidth / burst / flow 制約から読む EC2 ネットワーク性能

AWS EC2 のインスタンスタイプには、Up to 10 Gbps や 25 Gigabit のようなネットワーク性能表記があります。

しかし、この値をそのまま「その帯域が常時確保されている」と読むのは適切ではありません。

AWS 公式ドキュメントでは、EC2 インスタンスで利用できるネットワーク帯域は、vCPU 数、通信先、single-flow / multi-flow、Internet Gateway / Local Gateway 経由の有無、PPS、tracked connections、network I/O credit、baseline bandwidth など、複数の要素に依存すると説明されています。

この記事では、EC2 のネットワーク帯域を、設計上どのように読むべきかを整理します。

1. EC2 の帯域仕様は inbound / outbound の両方に適用される

AWS 公式ドキュメントでは、インスタンスの帯域仕様は inbound と outbound の両方に適用されると説明されています。たとえば up to 10 Gbps のインスタンスであれば、受信方向に最大10Gbps、同時に送信方向にも最大10Gbpsという意味になります。

ただし、これは「常に双方向合計20Gbpsを処理できる」という意味ではありません。

正確には、同じ帯域仕様が受信方向と送信方向にそれぞれ適用されるということです。実際にその帯域を利用できるかどうかは、baseline、burst、flow、経路、allowance など、後述する複数の制約に依存します。

2. Up to 表記は帯域確保ではない

EC2 で誤解しやすいのが、Up to 10 Gbps のような表記です。

AWS 公式ドキュメントでは、通常 16 vCPU 以下、つまり 4xlarge 以下のインスタンスは up to 表記になり、これらのインスタンスには baseline bandwidth があると説明されています。これらのインスタンスは、network I/O credit mechanism によって baseline を超えて burst できますが、burst できる時間はインスタンスサイズにより異なり、通常 5〜60 分程度とされています。

構造としては、以下のように読むと分かりやすいです。

Up to bandwidth
  = baseline bandwidth
  + burst bandwidth

ここで重要なのは、burst は永続的な性能として扱うべきものではないという点です。

インスタンスは起動時に network I/O credit を持っています。通信量が baseline bandwidth を下回っている間は credit を獲得し、baseline を超える通信では credit を消費します。credit を使い切ると、インスタンスは baseline bandwidth に戻ります。また、credit が残っていても、burst bandwidth は shared resource であるため best effort とされています。

したがって、Up to 10 Gbps は 10Gbps の帯域確保ではありません。

正確には、baseline bandwidth を持ち、条件が揃えば一時的に baseline を超えて burst できる可能性があるという意味で読むべきです。

3. baseline / burst のイメージ

Up to 表記は、baseline と burst の組み合わせとして見ると理解しやすくなります。

帯域
 ^
 |                         burst bandwidth
 |                    ┌───────────────┐
 |                    │               │
 | baseline ──────────┘               └──────────
 |
 +------------------------------------------------> 時間
        credit蓄積        credit消費        baselineへ戻る

通信量が baseline bandwidth を下回っている間、インスタンスは network I/O credit を獲得します。需要が増えると、その credit を消費して baseline を超えて burst できます。ただし、credit を使い切ると baseline bandwidth に戻ります。また、burst bandwidth は shared resource であるため best effort です。

このため、短時間のスパイクや一時的な通信には Up to の恩恵が出る可能性がありますが、継続的な帯域要件を Up to の値だけで設計するのは避けるべきです。

4. baseline bandwidth は設計基準になるが、保証帯域ではない

EC2 上で安定したネットワーク性能を設計する場合、Up to の最大値ではなく baseline bandwidth を見る必要があります。

ただし、baseline bandwidth も、専用線の CIR や SLA 上の保証帯域と同義ではありません。AWS の文書上、baseline は network I/O credit を使い切った後に戻る基準帯域として説明されています。実際の帯域は、PPS、tracked connections、通信先、経路、flow 制約などにも依存します。

設計上は、次のように扱うのが安全です。

Up to bandwidth
  = カタログ上の最大値

Baseline bandwidth
  = burst に依存しない設計上の基準値

Burst bandwidth
  = credit と共有リソース状況に依存する一時的な上振れ

つまり、継続通信や帯域要件のあるシステムでは、Up to ではなく baseline を基準に考えるべきです。

5. C5 系インスタンスで見る Up to と baseline の違い

AWS 公式ドキュメントには、C5 系インスタンスの例が掲載されています。これが Up to 表記と baseline の違いを理解するうえで分かりやすい例です。

この表から分かることは明確です。

c5.large は Up to 10 Gigabit と表示されますが、baseline は 0.75Gbps です。

c5.4xlarge でも Up to 10 Gigabit に対して baseline は 5Gbps です。

つまり、Up to 10 Gigabit と書かれていても、すべてのインスタンスが 10Gbps を継続的に利用できるわけではありません。

一方、c5.9xlarge 以上では、Network Performance と baseline が一致しています。このようなサイズでは、Up to 表記の小さいインスタンスとは読み方が変わります。

AWS の General Purpose インスタンス仕様ページでも、baseline bandwidth を持つインスタンスは network I/O credit mechanism により baseline を超えて best effort で burst できる一方、その他のインスタンスタイプは最大性能を継続できると説明されています。

6. single-flow は通常 5Gbps に制限される

EC2 の帯域設計では、インスタンス全体の帯域だけでなく、single-flow の上限も重要です。

AWS 公式ドキュメントでは、同一 cluster placement group に属していないインスタンス間の single-flow traffic は 5Gbps に制限されると説明されています。single-flow bandwidth を引き上げる方法として、cluster placement group で最大 10Gbps、MPTCP による複数パス化、ENA Express による同一 AZ 内最大25Gbpsが挙げられています。

整理すると、以下です。

この制約は、バックアップ、レプリケーション、トンネル、単一セッションの大容量転送などで問題になりやすいポイントです。

7. flow の定義は TCP/UDP と GRE/IPsec で異なる

AWS 公式ドキュメントでは、single-flow の定義も説明されています。

TCP/UDP の場合、flow は 5-tuple、つまり source IP、destination IP、source port、destination port、protocol によって定義されます。

一方、GRE や IPsec のように IP ヘッダの後ろに続くプロトコルでは、source IP、destination IP、next protocol の 3-tuple で flow が定義されます。

ここで重要なのは、IPsec / GRE の中に多数の TCP/UDP セッションが流れていても、AWS 側の flow 定義では外側ヘッダの 3-tuple で分類されるという点です。

たとえば、ある拠点Aから拠点Bへ GRE または IPsec トンネルを張り、その中に多数のユーザー通信が流れているケースを考えます。

トンネル内部では、1,000 人分の Web アクセスや多数の TCP/UDP セッションが存在しているかもしれません。しかし、AWS の flow 定義では、GRE や IPsec のようなプロトコルは source IP、destination IP、next protocol の 3-tuple で分類されます。

そのため、AWS 側から見ると、内側の通信数ではなく、外側のトンネル通信として少数の flow に見える可能性があります。この場合、インスタンス全体の multi-flow 帯域ではなく、single-flow 制約に寄る可能性があります。

VNF / ゲストOSから見た論理:
  多数のユーザー通信
  多数のTCP/UDPセッション

AWS側のflow分類:
  外側ヘッダに基づく 3-tuple flow

性能上の帰結:
  multi-flow帯域ではなく single-flow 上限に寄る可能性

ここでは、AWS 内部実装がどのように構成されているかを断定する必要はありません。公式文書から言えるのは、AWS が single-flow を定義する際、TCP/UDP では 5-tuple、GRE/IPsec では 3-tuple を使うという点です。

8. multi-flow でも経路によって制限される

multi-flow であれば常にインスタンス全体の帯域を使える、というわけでもありません。

AWS 公式ドキュメントでは、Internet Gateway または Local Gateway を通過する multi-flow traffic について、32 vCPU 以上のインスタンスでは available bandwidth の 50%、または 5Gbps の大きい方に制限されると説明されています。32 vCPU 未満のインスタンスでは 5Gbps に制限されます。

たとえば、m5.16xlarge は 64vCPU で 20Gbps のネットワーク帯域を持つ例として説明されています。このインスタンスから同一リージョン内の別インスタンスへ通信する場合は full bandwidth を利用できる一方、Internet Gateway または Local Gateway を通過する通信では 50%、つまり 10Gbps までしか利用できない例が示されています。

つまり、帯域設計では次の区別が必要です。

インスタンス仕様上の available bandwidth
  ≠ 特定経路で実際に利用できる帯域

VPC 内部のインスタンス間通信と、Internet Gateway / Local Gateway を通過する通信では、同じインスタンスでも利用可能な帯域上限が変わる場合があります。

9. PPS / tracked connections / allowance も別の上限になる

EC2 のネットワーク性能は Gbps だけでは決まりません。

AWS 公式ドキュメントでは、インスタンスが packet per second や tracked connections などの instance-level network allowance を超えると、公称の available bandwidth を達成できない場合があると説明されています。

つまり、次のようなケースでは、帯域幅より先に別の制約に到達する可能性があります。

- 小さいパケットが大量に流れる
- セッション数が多い
- connection tracking が多い
- microburst が発生する
- firewall / NAT / IPsec gateway のように多数の通信を処理する

ここで重要なのは、Gbps の表記だけでは EC2 のネットワーク性能を評価しきれないという点です。

特に firewall、NAT、IPsec gateway、NFV のような用途では、PPS と tracked connections の観点も評価対象になります。

10. CloudWatch だけでは見えない場合がある

AWS 公式ドキュメントでは、CloudWatch メトリクスでインスタンスの帯域やパケット数を監視できる一方、ENA ドライバが提供する network performance metrics によって、EC2 が定義する instance-level network allowance の超過を監視できると説明されています。

また、CloudWatch のメトリクスが 1 分または 5 分粒度である場合、microburst のような短時間のスパイクを十分に反映できないことがあります。その結果、ENA 側では allowance exceeded や packet drop が見えていても、CloudWatch の通常メトリクスでは見えない場合があります。

ENA の network performance metrics では、たとえば以下のような allowance exceeded 系の指標を確認できます。

bw_in_allowance_exceeded
bw_out_allowance_exceeded
pps_allowance_exceeded
conntrack_allowance_exceeded

これらは、EC2 が定義するインスタンスレベルのネットワーク allowance に到達したかどうかを確認するための手掛かりになります。CloudWatch の平均帯域だけでは microburst を捉えきれない場合があるため、帯域未達や packet drop を調査する場合は、ENA 側の network performance metrics も確認対象に含めるべきです。

ただし、ここでも AWS 内部実装を推測する必要はありません。公式文書から言えるのは、CloudWatch の粒度では microburst を捉えきれない場合があり、ENA の network performance metrics が allowance 超過の確認に使えるという点です。

11. EC2 の帯域設計は「引き算」で読む

EC2 のネットワーク帯域は、カタログ上の最大値から順に制約を差し引いて読む必要があります。

EC2 のネットワーク帯域は、カタログ値を足し算で読むものではない。
baseline、flow、経路、allowance を順に適用する「引き算の設計」で読む必要がある。

設計上の見方としては、以下のようになります。

設計上利用できる帯域
=
min(
  インスタンスの available bandwidth,
  baseline bandwidth,
  single-flow 上限,
  multi-flow の経路制約,
  Internet Gateway / Local Gateway 経由の制約,
  PPS allowance,
  tracked connection allowance,
  ENA allowance,
  VNF / アプリケーション側の処理性能
)

Up to 10 Gbps という表記がある場合でも、それを帯域確保と見ることはできません。

安定した帯域設計をするなら、まず baseline bandwidth を確認し、そのうえで flow、PPS、connection tracking、経路制約を重ねて評価する必要があります。

12. 通信キャリアNFVの文脈では特に注意が必要

この仕様を通信キャリアNFVの文脈に持ち込むと、問題はさらに明確になります。

キャリアサービス側が「帯域確保型」「閉域接続」「SLA 付き回線」として設計されている場合、EC2 の Up to 表記をそのまま提供帯域の根拠にすることはできません。

特に、最大値を帯域確保の基準としているサービスでは、EC2 の Up to 表記と意味が一致しません。

キャリアサービス側:
  最大10Gbps = 提供帯域または帯域確保の根拠

EC2側:
  Up to 10Gbps = baseline + burst を含む条件付き最大値

この2つを同じ意味として扱うと、設計、課金、SLA、責任分界の前提が崩れます。

AWS 上で NFV 的な構成を成立させるには、少なくとも次のように、AWS 側の制約を明示的にサービス設計へ取り込む必要があります。

提供可能帯域
=
min(
  自社アクセス回線帯域,
  閉域網側の設計帯域,
  Direct Connect / VIF / Gateway 側の制約,
  EC2 baseline bandwidth,
  single-flow 上限,
  PPS allowance,
  tracked connection allowance,
  VNF処理性能
)

このように定義すれば、AWS を含むクラウド接続型サービスとして設計する余地はあります。

一方で、既存のキャリア回線サービスの帯域確保ロジックを、そのまま EC2 上の NFV へ持ち込む場合は、Up to、baseline、burst、single-flow、PPS、tracked connections などの制約を正しく写像しないと、サービス仕様上の説明が成立しにくくなります。

ここでの論点は、AWS で NFV が技術的に動くかどうかではありません。サービスとして提示している帯域の意味を、AWS のネットワーク性能モデルへ正しく写像できるかです。

結論

EC2 の Up to 10 Gbps は、帯域確保を意味しません。

Up to 表記のインスタンスでは、baseline bandwidth と burst bandwidth を分けて読む必要があります。burst は network I/O credit に依存し、credit を使い切ると baseline bandwidth に戻ります。また、credit があっても burst bandwidth は shared resource に依存する best effort です。

安定した帯域設計を行う場合は、最大値ではなく baseline bandwidth を基準にする必要があります。

さらに、NFV、IPsec、GRE のような用途では、インスタンス全体の帯域より先に、外側ヘッダで定義される flow 制約が上限になる可能性があります。PPS、tracked connections、ENA allowance、Internet Gateway / Local Gateway 経由の制約も評価対象です。

EC2 のネットワーク帯域は、カタログ値を足し算で読むのではなく、baseline、flow、経路、allowance を順に適用する 引き算の設計 で読むべきです。

参考資料

• Amazon EC2 instance network bandwidth
  https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html
• Specifications for Amazon EC2 general purpose instances
  https://docs.aws.amazon.com/ec2/latest/instancetypes/gp.html

Related posts:

AWS Direct Connect の要点整理 デスクワーカーが体を鍛えるメリットと楽しみ方 自作 PC のハードウェア構成 ジムに通い始めた 「ゴリゴリくりぃむ」の乳首ラジコン イルガ（ILGA）のシャンプーとトリートメントは最強 イームズチェアを買ったが座面が高すぎたので脚をノコギリでカットした CentOS 7 SELinux 無効化 CentOS7 Zabbixエージェント設定 数年間使い続けた Dr.Wallet からマネーフォワードへ乗り換え CentOS7 Apache Web サーバー構築 TLS 対応 自己署名証明書 近所のオリジン弁当が閉店