Maximum Transmission Unit を宅配便で理解する
「ネットワークの段ボールサイズ」で、データ転送の効率が劇的に変わる！
1回の通信で送れる最大パケットサイズ（バイト数）。宅配便の段ボールサイズに相当します。
1500バイト（標準フレーム）と 9001バイト（ジャンボフレーム）の2種類。現行世代は両方対応！
1回で6倍のデータ送信！オーバーヘッド削減でCPU効率アップ、スループット向上！
インターネット通信は1500限定。Transit Gatewayは8500。経路によってMTUが異なります！
データを送る作業は、荷物を段ボールに詰めて配送するのと同じです！
🏪 コンビニサイズの段ボール
🏭 業務用大型段ボール
同じ100MBのデータを送信する場合：
| MTU | 必要パケット数 | オーバーヘッド | 効率 |
|---|---|---|---|
| 1,500 (標準) | 約 69,906 パケット | 約 2.8MB | 97.3% |
| 9,001 (ジャンボ) | 約 11,654 パケット | 約 0.5MB | 99.5% |
経路によってMTUが異なります。通信経路全体で最も小さいMTUに合わせる必要があります！
最大MTU。高速通信に最適！
ジャンボフレーム対応！
Path MTU Discovery サポート
Transit Gateway経由時
プライベートVIF時
インターネット標準
暗号化オーバーヘッドあり
リージョン間は標準
VPC Peering（MTU 9001）からTransit Gateway（MTU 8500）に移行する際、非対称ルーティングが発生すると8500バイトを超えるパケットがドロップされる可能性があります。
対策：両方のVPCのルートテーブルを同時に切り替えるか、事前にEC2のMTUを8500に設定しておきましょう。
EC2インスタンスから外部へ接続する際、接続経路によってMTUが異なります。 特にDon't Fragment（DF）フラグが設定されている場合、MTUを超えるパケットはドロップされます。
IPヘッダに設定できるフラグで、「このパケットを分割しないでください」という指示です。
💡 ポイント：Path MTU Discovery（PMTUD）はDFフラグを利用して経路上の最小MTUを検出します。 セキュリティグループでICMPをブロックしているとPMTUDが機能せず、通信障害の原因になることがあります。
| 接続経路 | MTU | ジャンボフレーム | 用途・特徴 |
|---|---|---|---|
| 📡 Direct Connect（Private VIF） | 9001 | ✅ 対応 | 専用線接続。高帯域・低遅延 |
| 📡 Direct Connect（Transit VIF） | 8500 | ✅ 対応 | Transit Gateway経由の専用線 |
| 🔒 Site-to-Site VPN | 1500 | ❌ 非対応 | 暗号化オーバーヘッドあり |
| 🌍 Internet Gateway | 1500 | ❌ 非対応 | インターネット標準 |
| 🔀 Transit Gateway | 8500 | ⚠️ 制限あり | VPC間接続のハブ |
| 🔗 VPC Peering（同一リージョン） | 9001 | ✅ 対応 | VPC間直接接続 |
| 🔗 VPC Peering（クロスリージョン） | 1500 | ❌ 非対応 | リージョン間は標準MTU |
# プライマリネットワークインターフェイスのMTU確認
ip link show eth0
# または
cat /sys/class/net/eth0/mtu2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP
link/ether 02:90:c0:b7:9e:d1 brd ff:ff:ff:ff:ff:ff
# PowerShellでMTU確認
Get-NetAdapterAdvancedProperty -Name "*" -RegistryKeyword "*JumboPacket"
# または
netsh interface ipv4 show interfacesName : Ethernet Property : Jumbo Packet Value : 9015 ← ジャンボフレーム有効
# 宛先へのパスMTUを確認
tracepath <宛先IPアドレス>
# 例：別のEC2インスタンスへのパスMTU
tracepath 10.0.2.100 1?: [LOCALHOST] pmtu 9001
1: ip-10-0-2-100.ec2.internal 0.512ms reached
Resume: pmtu 9001 hops 1 back 1
# MTUを1500に一時変更（再起動で戻る）
sudo ip link set dev eth0 mtu 1500
# 変更を確認
ip link show eth0# 1. ネットワーク設定ファイルを編集
sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0
# 最終行に追加
MTU=1500
# 2. DHCPクライアント設定を編集
sudo vi /etc/dhcp/dhclient.conf
# 以下を追加（DHCPからのMTU上書きを防ぐ）
default interface-mtu 1500;
supersede interface-mtu 1500;
# 3. ネットワーク再起動
sudo systemctl restart network# systemd-networkdの設定ファイルを編集
sudo vi /usr/lib/systemd/network/80-ec2.network
# [Link]セクションに追加
[Link]
MTUBytes=1500
# ネットワーク再起動
sudo systemctl restart systemd-networkdクラスタープレイスメントグループ内のインスタンス間で大量のデータ転送を行う場合。最大スループットを実現。
Redshiftとの通信でジャンボフレームを使うと接続がハングする場合があります。安定性を重視。
Internet Gateway経由の通信は自動的に1500に制限。特別な設定不要。
TGW経由の場合は8500が上限。パケットドロップを避けるため調整が必要。
VPN接続はMTU 1500に制限。暗号化オーバーヘッドも考慮が必要。
VPCエンドポイント経由のS3アクセスやEBS通信はジャンボフレーム対応。
tracepath <宛先> でパスMTUを確認DF フラグをオフにしてフラグメンテーションを許可sudo ip link set dev eth0 mtu 1500EC2から宛先までの全ての経路（Internet Gateway, NAT Gateway, Transit Gateway, VPN等）を確認し、最も小さいMTUを把握しましょう。
VPC内部の高速通信にはジャンボフレーム（9001）、インターネット経由やVPN接続には標準フレーム（1500）を使い分けましょう。
VPC PeeringからTransit Gatewayへの移行など、MTUが異なる経路への切り替え時は、両端のルートテーブルを同時に更新してパケットロスを防ぎましょう。
一時的なMTU変更は再起動で元に戻ります。本番環境では設定ファイル（ifcfg-eth0, dhclient.conf等）を更新して永続化しましょう。
| 経路 | MTU | メモ |
|---|---|---|
| VPC内部 / VPC Peering（同一リージョン） | 9001 | 最大効率 |
| Transit Gateway / NAT Gateway | 8500 | PMTUD対応 |
| Internet / VPN / クロスリージョン | 1500 | 標準 |
Created by SSuzuki1063
AWS SAP Learning Resources