📌 結論：両方とも根本原因になりうる！
ジャンボフレーム（MTU 9001）で「Don't Fragment」フラグが設定されている場合、
インターネット経由とVPN経由の両方で転送失敗が発生します
9001バイトのパケットは通過できず、
Don't Fragmentフラグにより分割もできない
→ パケットドロップ！
実効MTUは約1300～1400バイト
9001バイトのパケットは通過できず、
→ パケットドロップ！
🚛 トラックとトンネルで理解するMTU問題
📦 MTU = トラックの最大積載サイズ
MTU（Maximum Transmission Unit）とは、1回で送れるデータの最大サイズです。
これを「トラックに積める荷物の最大サイズ」に例えましょう！
✅ VPC内の通信（成功）
❌ インターネット経由（失敗）
このフラグがあると、トラックを小さく分けることができず、立ち往生してしまいます
📏 各経路のMTUサイズ比較
🚫 Don't Fragment（DF）フラグとは？
「このパケットは分割しないでください」という指示をIPヘッダーに設定するフラグです
（DFフラグ付き）
（インターネット）
DFフラグがある...
ICMP「Fragmentation Needed」送信
🏠 たとえ話でいうと...
「この大きな荷物は絶対に分けないで配送してください！」という指示がついた荷物を、
小さなトンネルしかない道で運ぼうとしている状態です。
分割が禁止されているため、配送員は「配達不能」として返送するしかありません。
🗺️ 経路別：転送成功・失敗マップ
同じVPC内のEC2間では
ジャンボフレームがサポート
パブリックインターネットは
標準MTUのみサポート
VPNオーバーヘッドにより
さらにMTUが小さくなる
⚙️ 問題発生のメカニズム
💡 解決策
MTUを調整する
外部と通信する場合は、MTUを標準の1500バイトに設定します。
sudo ip link set dev eth0 mtu 1500
DFフラグを無効化
Don't Fragmentフラグを外して、パケットの分割を許可します。
# ソケットオプションを変更
Path MTU Discoveryを活用
経路上の最小MTUを自動検出し、適切なサイズでパケットを送信します。
# セキュリティグループを確認
Direct Connectを使用
プライベートVIFでMTU 9001、トランジットVIFでMTU 8500のジャンボフレームをサポート。ただしVPNと同じルートを共有しないこと！
# アドバタイズすると1500に制限
Transit Gateway使用時の注意
Transit GatewayはMTU 8500が上限です。9001ではありません。
sudo ip link set dev eth0 mtu 8500
EC2インスタンスタイプ確認
C1、CC1、T1、M1はジャンボフレーム非対応。現行世代のインスタンスを使用してください。
aws ec2 describe-instance-types \
--query "InstanceTypes[*].NetworkInfo"
🔌 AWS Direct Connect のジャンボフレーム詳細
AWS公式ドキュメントより：Direct Connectの仮想インターフェイス別MTU制限
プライベート仮想インターフェイス
VPCへの接続用。仮想プライベートゲートウェイまたはDirect Connectゲートウェイにアタッチ可能。
トランジット仮想インターフェイス
Transit Gateway経由での接続用。9001ではなく8500が上限なので注意！
パブリック仮想インターフェイス
AWSパブリックサービスへの接続用。ジャンボフレームはサポートされません。
⚠️ 重要：VPNと共存時のMTU制限
同じルートをアドバタイズするが異なるMTU値を使用する2つのプライベート仮想インターフェイスがある場合、
または同じルートをアドバタイズするSite-to-Site VPNがある場合には、
🚫 自動的に 1500 MTU が使用されます！
→ これが今回の問題の重要なポイント！Direct Connectがあっても、VPNが同じルートを持つと1500に制限される可能性があります。
📋 EC2インスタンスタイプ別ジャンボフレーム対応
C1、CC1、T1、M1以外のすべてのEC2インスタンスタイプ
（現行世代のほとんどのインスタンス）
C1、CC1、T1、M1
これらの古いインスタンスタイプではジャンボフレームがドロップされます
🔧 技術詳細：イーサネットフレームサイズ
Direct Connectがリンクレイヤーでサポートするフレームサイズ：
標準: 1522バイト = 14(イーサネットヘッダー) + 4(VLANタグ) + 1500(IPデータグラム) + 4(FCS)
ジャンボ: 9023バイト = 14(イーサネットヘッダー) + 4(VLANタグ) + 9001(IPデータグラム) + 4(FCS)
📊 経路別MTU比較表（詳細版）
| 経路 | MTUサイズ | ジャンボフレーム対応 | 9001バイトパケット |
|---|---|---|---|
| 🏠 VPC内（同一リージョン） | 9001 バイト | ✅ | ✅ 通過 |
| 🔗 VPCピアリング（同一リージョン） | 9001 バイト | ✅ | ✅ 通過 |
| 🌉 Transit Gateway | 8500 バイト | ✅ | ❌ 要調整（8500以下に） |
| 🌐 インターネットゲートウェイ | 1500 バイト | ❌ | ❌ ドロップ |
| 🔒 Site-to-Site VPN | ~1300-1400 バイト | ❌ | ❌ ドロップ |
| 🔌 Direct Connect（プライベートVIF） | 9001 バイト | ✅ | ✅ 通過 |
| 🔌 Direct Connect（トランジットVIF） | 8500 バイト | ✅ | ❌ 要調整（8500以下に） |
| 🔌 Direct Connect（パブリックVIF） | 1500 バイト | ❌ | ❌ ドロップ |
| ⚠️ DX + VPN共存（同一ルート） | 1500 バイト | ❌ 強制制限 | ❌ ドロップ |
※ Direct Connectでジャンボフレームを使用するには、オンプレミス側のルーター設定も必要です
※ 同じルートにVPNがある場合は自動的に1500 MTUに制限されます（AWS公式ドキュメントより）
❓ よくある質問
1,024バイトはMTU 1500バイト以下なので、どの経路でも問題なく転送できます。
一方、1,024MB以上のファイルは多数のパケットに分割され、そのうち9001バイトのパケットがMTU境界で問題を起こします。
HPC（高性能コンピューティング）やビッグデータ処理など、インスタンス間通信が多いワークロードに最適です。
同一AZ内に配置されるため、ジャンボフレーム（MTU 9001）が完全にサポートされます。
IPsec VPNでは、元のパケットにVPNヘッダー（約100～200バイト）が追加されます。
そのため、実際に送れるデータ部分のMTUは1300～1400バイト程度に制限されます。
1. パブリック仮想インターフェイスを使用する場合（ジャンボフレーム非対応）
2. 同じルートをアドバタイズするSite-to-Site VPNがある場合（自動的に1500に制限）
3. 異なるMTU値を使用する2つのプライベートVIFが同じルートを持つ場合
4. オンプレミス側のルーターがジャンボフレームに対応していない場合
5. C1、CC1、T1、M1インスタンスとの通信（これらはジャンボフレーム非対応）
・プライベートVIF（Direct Connectゲートウェイ経由）：MTU 9001まで対応
・トランジットVIF（Transit Gateway経由）：MTU 8500まで対応
Transit Gatewayは複数VPCのハブとして便利ですが、ジャンボフレームのサイズが8500バイトに制限される点に注意してください。
9001バイトのパケットはTransit Gateway経由では通過できません。
AWSグローバルネットワークを使って、リージョンを経由せずにオンプレミス拠点間を接続できます。
SiteLinkは仮想インターフェイスの種類に応じて、最大8500または9001のジャンボフレームMTUサイズをサポートします。
※AWS GovCloud (US)および中国リージョンでは使用できません。
📚 AWS公式ドキュメント
Direct Connect - ジャンボフレームの設定
AWS Direct Connectでジャンボフレームを使用する際の設定方法、MTUサイズの考慮事項、 仮想インターフェイスでのMTU設定について詳しく解説されています。
🔗 AWS公式ドキュメントを見る →🎓 まとめ
VPC内では高速通信が可能
外部通信では問題発生の可能性
MTUが小さい経路では
パケットがドロップされる
インターネット: 1500バイト ⚠️
VPN: ~1300バイト ⚠️