EC2 のインスタンスタイプを見ると、ネットワーク性能として Up to 10 Gbps や 25 Gigabit のような表記があります。通常の Web サーバーや業務アプリケーションであれば、この値はおおまかな目安として使えます。
しかし、EC2 を仮想 Firewall、IPsec gateway、NAT gateway、IDS / IPS、閉域接続の中継点のようなネットワーク機能の実行基盤として使う場合は、読み方を変える必要があります。特に、一定の帯域を前提にサービスを説明する場合、カタログ上の最大値だけでは判断できません。
この記事では、EC2 のネットワーク性能を baseline、burst、single-flow、経路、ENA allowance、VNF 側の処理能力 に分解して読みます。結論は、EC2 はネットワーク機能の部品として使えるが、Up to 表記をそのまま帯域保証の根拠にしてはいけない、というものです。
書籍
Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂 4 版
AWS 上で EC2、VPC、ルーティング、サーバー構成を確認したい場合の参考書籍です。NFV や閉域接続の設計を考える前提整理として紹介します。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
まず結論
EC2 のネットワーク帯域は、次の 3 つを混ぜないことが重要です。
| 観点 | 意味 | 設計上の扱い |
|---|---|---|
| EC2 のネットワーク性能 | インスタンスタイプ、vCPU 数、network card、baseline、burst、allowance などで決まる基盤側の上限や目安 | サービス帯域そのものではなく、設計材料として読む |
| VNF / appliance の処理能力 | OS、kernel、暗号処理、状態管理、policy 評価、inspection、CPU 使用率などで決まる実効性能 | EC2 の帯域より先に詰まることがある |
| サービスとして説明できる帯域 | 継続的に維持でき、監視でき、障害時の挙動も含めて利用者に説明できる性能 | baseline、経路、flow、VNF 実測を重ねて控えめに見る |
この 3 つを混ぜると、EC2 が up to 10 Gbps と書いてあるから 10 Gbps の閉域サービスを作れる という雑な理解になります。ネットワーク機能を扱う場合、この読み方はかなり危険です。
Up to は保証値ではない
EC2 では、インスタンスタイプによって Up to 表記が使われます。AWS 公式ドキュメントでは、一般に 16 vCPU 以下のインスタンスでは baseline bandwidth があり、追加需要がある場合に network I/O credit を使って baseline を超える burst が可能になると説明されています。
ここで重要なのは、burst は継続的な帯域保証ではないことです。クレジットが尽きれば baseline に戻りますし、クレジットがあっても burst は共有リソース上の best effort として扱う必要があります。
| 分類 | 設計上の読み方 |
|---|---|
| baseline | 継続的に見込む基礎値。ただし、これも EC2 側の性能情報であり、サービス保証値そのものではない |
| burst | 短時間の余力。通常時の吸収には使えても、保証帯域の根拠にはしにくい |
| Up to | 最大到達可能性を含む表記。閉域接続や NFV の契約帯域にそのまま置き換えない |
baseline は AWS CLI で確認する
baseline bandwidth は EC2 コンソール上の文字列だけでは分かりにくい場合があります。AWS CLI では、インスタンスタイプ情報から BaselineBandwidthInGbps を確認できます。
aws ec2 describe-instance-types \
--filters "Name=instance-type,Values=c5.*" \
--query "InstanceTypes[].[InstanceType,NetworkInfo.NetworkPerformance,NetworkInfo.NetworkCards[0].BaselineBandwidthInGbps]" \
--output tableこの値を確認すると、同じ Up to 10 Gigabit と表示される系列でも、baseline はインスタンスサイズによって異なることが分かります。つまり、設計上見るべき値は Up to の文字列ではなく、baseline、経路、flow、allowance、VNF 処理能力を合わせた実効値です。
single-flow 制約は tunnel 系で効きやすい
EC2 のネットワーク性能を読む時に見落としやすいのが single-flow 制約です。AWS 公式ドキュメントでは、同一 cluster placement group にない場合、single-flow traffic は 5 Gbps に制限されると説明されています。
TCP / UDP の single-flow は通常 5-tuple で見ます。一方、GRE や IPsec のように IP ヘッダーの後ろに続くプロトコルでは、source IP、destination IP、next protocol の 3-tuple で flow が定義されます。
この差は NFV や閉域接続で大きく効きます。多数の利用者通信を IPsec tunnel や GRE tunnel に集約すると、内側では多数の flow があっても、外側から見ると少数の tunnel flow に潰れて見えることがあります。その場合、aggregate bandwidth より先に single-flow 制約や暗号処理能力が上限になる可能性があります。
| 通信の見え方 | 設計上の注意 |
|---|---|
| 多数の TCP / UDP flow | aggregate bandwidth を使いやすいが、PPS、tracked connection、VNF 処理が別の上限になる |
| GRE / IPsec tunnel | 内側の flow が外側の tunnel flow に集約され、single-flow 制約や暗号処理の影響を受けやすい |
| MPTCP / 複数経路 | 条件が合えば単一通信の帯域を伸ばせるが、使える構成は限定される |
経路によって使える帯域は変わる
EC2 の bandwidth は、どこへ向かう通信かによっても変わります。AWS 公式ドキュメントでは、Internet Gateway や Local Gateway を通る multi-flow traffic について、インスタンスタイプや vCPU 数に応じた制約が示されています。
たとえば、あるインスタンスが同一リージョン内の別 EC2 に対して full bandwidth を使えるとしても、Internet Gateway や Local Gateway を通る経路では利用可能帯域が変わる場合があります。Direct Connect、Transit Gateway、VPN、Local Gateway、Outposts などを組み合わせる場合は、EC2 単体の性能だけではなく、経路全体を見なければなりません。
| 経路 | 見るべきこと |
|---|---|
| 同一 Region 内 EC2 | インスタンスタイプ、placement、ENA、single-flow / multi-flow |
| Internet Gateway / Local Gateway | EC2 側の制約に加えて、経路ごとの上限や vCPU 数による扱い |
| Direct Connect / VPN | 回線、VIF、TGW、tunnel、暗号処理、flow の見え方 |
| Gateway Load Balancer / appliance 経由 | GENEVE、appliance 側の処理、戻り通信、flow symmetry |
ENA allowance と microburst を見る
EC2 のネットワーク性能をサービス設計に使うなら、平均帯域だけでなく allowance 超過も見る必要があります。AWS 公式ドキュメントでは、ENA driver metrics によって bandwidth、PPS、connection tracking、link-local service access などの上限超過を確認できると説明されています。
特に重要なのは、CloudWatch の通常メトリクスでは見えにくい短い spike、いわゆる microburst です。AWS 公式ドキュメントでも、network performance metrics では allowance exceeded と packet drop が見えていても、CloudWatch instance metrics では粒度の問題で見えない場合があると説明されています。
| ENA metric | 見る意味 |
|---|---|
bw_in_allowance_exceeded | inbound aggregate bandwidth の上限超過による queue / drop |
bw_out_allowance_exceeded | outbound aggregate bandwidth の上限超過による queue / drop |
pps_allowance_exceeded | bidirectional PPS の上限超過 |
conntrack_allowance_exceeded | connection tracking 上限超過による新規接続失敗や packet loss |
linklocal_allowance_exceeded | Amazon DNS、IMDS、Time Sync など link-local service への PPS 上限超過 |
NFV では EC2 の前に VNF の処理能力を見る
仮想 Firewall や IPsec gateway のようなネットワーク機能では、EC2 のネットワーク帯域だけではなく、VNF 自体の処理能力が重要です。
- 暗号化と復号の CPU 負荷
- Firewall policy の評価
- NAT や connection tracking の状態管理
- IDS / IPS の inspection
- kernel forwarding、DPDK、SR-IOV、ENA などの packet path
- PPS、tracked connection、bandwidth allowance の超過
つまり、ネットワーク機能の実効性能は EC2 の帯域 ではなく、EC2 の帯域、経路制約、flow 制約、VNF 処理能力、監視可能な allowance の最小値として見た方が現実に近くなります。
サービス帯域として説明するなら何を見るか
EC2 をネットワーク機能の実行基盤として使うこと自体は可能です。ただし、一定の帯域を利用者に説明するサービスに使うなら、少なくとも次の観点を分けて確認する必要があります。
| 確認項目 | 見る理由 |
|---|---|
| baseline bandwidth | 継続的に見込む基礎値を確認するため |
| burst の扱い | 短時間の余力を保証帯域と誤読しないため |
| single-flow / multi-flow | tunnel や NAT で flow の見え方が変わるため |
| 経路 | IGW、LGW、DX、TGW、VPN、GWLB などで上限や責任分界が変わるため |
| ENA / enhanced networking | 高 PPS、低 latency、SR-IOV 前提を満たしているか確認するため |
| ENA driver metrics | allowance 超過や microburst による drop を観測するため |
| VNF の実測 | 暗号、Firewall、NAT、inspection の処理が別の上限になるため |
EC2 は帯域保証の箱ではなく、制約を読んで使う部品
結論として、EC2 は NFV や閉域接続の構成要素として使えます。ただし、EC2 の Up to 表記をそのままサービス帯域として扱うべきではありません。
EC2 のネットワーク性能は、baseline、burst、single-flow、経路、allowance、VNF の処理能力を重ねて読む必要があります。特に IPsec や GRE のような tunnel 型通信では、外側 flow の見え方が性能上限に直結するため、aggregate bandwidth だけを見ても判断を誤ります。
したがって、EC2 上でネットワーク機能を設計する時は、次のように考えるのが安全です。
EC2 の帯域表示は、サービス帯域の答えではなく、設計時に差し引いて読むための材料である。
参考資料
- Amazon EC2 instance network bandwidth
- Enhanced networking on Amazon EC2 instances
- Monitor network performance for ENA settings on your EC2 instance
- EC2 instance bandwidth weighting configuration
関連記事
- パブリッククラウドで NFV は成立するのか – 仮想アプライアンスを置く前に考えること
- AWS Direct Connect は何を接続するのか – Connection / VIF / DXGW / TGW の責務分界
- AWS VPC に L2 はあるのか – VLAN / ARP / VIP をクラウドの到達性モデルへ翻訳する
- AWS Outposts の本質は「オンプレ AWS」ではなく、責任分界を変えるインフラである
- CPU ピニングを外すと何が変わるのか – 専有実行から共有実行へ変わるということ
- 単一 VM の vCPU はどこまで割り当てるべきか – 物理コア数、NUMA、オーバーコミットで考える
- クラウドという言葉の本質 – 場所ではなく運用モデルと責任分界で考える
Related posts:
AWS Outposts の本質は「オンプレ AWS」ではなく、責任分界を変えるインフラである
AWS Direct Connect は何を接続するのか – Connection / VIF / DXGW / TGW の責務分界
AWS VPC に L2 はあるのか – VLAN / ARP / VIP をクラウドの到達性モデルへ翻訳する
AWS Outposts racks と Outposts servers は別物として評価すべき
DPDK で VM ネットワークを高速化する考え方 – dataplane / NFV / kernel bypass を見る
パブリッククラウドで NFV は成立するのか – 仮想アプライアンスを置く前に考えること
AWS だけでクラウドを理解しない – パブリッククラウドと運用モデルを分けて考える