こんなに変わった！ AWSネットワークの常識

NW-JAWS 10周年イベントのKeynote資料です

1. NW-JAWS DAY Keynote こんなに変わった！ AWSネットワークの常識 2016年のベストプラクティスは、2026年のアンチパターン？ Shota SHIRATORI(NW-JAWS) @whitebird_sp #NW_JAWS ※本資料に記載の内容は2026年11月14日時点のものとなります ※本資料の見解・知見については所属する組織を代表するものではありません @whitebird_sp #NW_JAWS 1 / 20
2. 自己紹介 保有資格(レベル別) Business Practitioner Associate Professional しらとり しょうた 白鳥 翔太 Specialty ネクストモード・NTT東日本 その他 IPA ネットワークスペシャリスト IPA 情報セキュリティスペシャリスト 実績 経歴 2009年入社(NTT東日本)/ネットワークエンジニア〜セールス 〜サービス開発/2025年ネクストモード出向 好きなAWSサービス Amazon VPC ▸ 2020-2022 APN AWS Top Engineers / 2023-2026 Japan AWS Top Engineers ▸ 2023-2026 Japan AWS All Certifications Engineers ▸ 2024-2026 AWS Ambassadors ▸ AWS Ambassador - Certification All-Star Award 2024/2025 好きな言葉 Knowledge is Power. / Insist on the Highest Standards. 今ハマってるAWS関連 Any sufficiently advanced technology is indistinguishable from magic. ▸ Amazon Connect CustomerでAIコンタクトセンタを作る @whitebird_sp #NW_JAWS 2 / 20
3. クイズ 2016年、ネットワーク系の新サービス・新機能・ソリューション Q. この中に一つ、2026年現在ではアンチパターンのものがあります。それはどれでしょう？ A 3月 ピアリング先VPCのセキュリティグループ参照 B 4月 Amazon S3 Transfer Acceleration C 6月 Elastic Network Adapter（ENA） D 7月 Transit VPC ソリューション E 7月 VPCピアリングのDNS解決 F 8月 Application Load Balancer（ALB） G 12月 AWS Shield Slidoで投票 QRコード貼付位置 A〜H から1つ選んでください H 12月 VPC／EC2のIPv6対応 @whitebird_sp #NW_JAWS 3 / 20
4. 正解 正解は D：Transit VPC 当時は… AWS Cloud Transit VPC オンプレ CSR1000v (EC2) Spoke VPC 1 AWSが公式ソリューションとし て出した「最新のベストプラク ティス」 Spoke VPC 2 当時のコスト感 $0.21〜8.40 /時 CSR1000v (EC2) Spoke VPC 3 ＋ スポークVPCごとに $0.10/時 なぜ正解だったのか オレンジ破線：IPsec VPN（BGP） @whitebird_sp #NW_JAWS ピアリングは非推移、マネージドなハブ 機能がなかった 4 / 20
5. 本日のメッセージ 今日の制約は明日の限界ではない 各テーマを「2016年の正解 → なぜそうだったか → 2026年の構成」で見ていきます テーマ① テーマ② テーマ③ AWSへの接続 VPC間接続 グローバル＆マルチクラウド テーマ④ テーマ⑤ テーマ⑥ IPアドレス設計 外部への接続 アプライアンス冗長化 判定スタンプ 引退 役目を終えた／今はアンチパターン @whitebird_sp #NW_JAWS 進化 形を変えて今も使う 殿堂入り 10年経っても変わらない 5 / 20
6. テーマ① AWSへの接続 2016年の常識 VPCの数だけVGWとVIFを張る AWS Cloud（東京リージョン） なぜそうだったか（当時の制約） VPC A ▸ Direct Connect Gatewayがまだな い（2017年11月〜） Private VIF 1 ▸ Transit Gatewayもない（2018年 11月〜） ▸ VGWはVPCと1対1 オンプレミス VPC B Private VIF 2 ルーター Direct Connect 当時のベストプラクティス VPC C Private VIF 3 VPCごとにVGWを置き、 Private VIF／VPNをVPCの数 だけ張る VPCが増える ＝ VIF・BGPセッションも増える @whitebird_sp #NW_JAWS 6 / 20
7. テーマ① AWSへの接続 2026年の常識 DX Gateway＋Transit Gatewayで集約する 引退 AWS Cloud VPC A VPCごとの個別VIF DXGW＋TGW／Cloud WANで集約が基本 殿堂入り オンプレミス VPC B ルーター Direct Connect （MACsec） DX Gateway VPC C Transit Gateway 接続の冗長化 DXの複数ロケーション＋VPNバックアップ 次の常識？ AWS Interconnect - last mile VPC D 回線手配からBGP・VLAN設定まで、コン ソールから。1〜100Gbpsで帯域変更でき 、MACsecが既定で有効（2026年4月GA） ※現時点は米国（Lumen）のみ VPCが増えた場合の接続はTGWへのアタッチメントを追加 @whitebird_sp #NW_JAWS 7 / 20
8. テーマ② VPC間接続 2016年の常識 ピアリングのフルメッシュかTransit VPC なぜそうだったか（当時の制約） VPC A 5 VPCで ピアリング10本 VPC E VPC B ▸ VPCピアリングは推移的ルーティ ング不可 ▸ マネージドなハブ（TGW）がない ▸ EC2ルーターをAWS Marketplace で購入するか、ルーティング機能 が強いOSを選択 必要な本数 ＝ n(n−1)/2 10 VPC 45本 当時のベストプラクティス VPC D VPC C 20 VPC 190本 50 VPC 1,225本 少数ならフルメッシュ、多数な らTransit VPC（EC2ルーター ） ルートテーブルとSGの管理も本数分 @whitebird_sp #NW_JAWS 8 / 20
9. テーマ② VPC間接続 2026年の常識 VPC間接続はマネージドサービスに移行 L3でつなぐ 引退 サービスを公開する EC2ルーターでのハブ自作 Transit VPCの役割はTGW／Cloud WANへ 利用側 VPC A 提供側 進化 VPC F VPC B エンドポイント NLB PrivateLink VPCピアリング 少数VPC間・大容量通信では今も有力（データ 処理料金なし） 進化 サービス単位の公開 PrivateLink／VPC Latticeで必要な分だけ VPC E VPC C VPC Lattice サービスネットワークで、アカウント・ VPCをまたいでサービス単位に接続と認可 VPC D Transit Gateway／Cloud WAN CIDR重複があってもつながる 使い分けのヒント ネットワーク同士を広くつなぐ ⇒ TGW 特定サービスだけ見せる ⇒ PrivateLink／ Lattice 2VPC間の太い通信 ⇒ ピアリング 「L3でつなぐ」から「サービスを公開・共有する」へ @whitebird_sp #NW_JAWS 9 / 20
10. テーマ③ グローバル＆マルチクラウド 2016年の常識 リージョン間はオンプレ経由かEC2同士のVPN 東京リージョン シンガポールリージョン なぜそうだったか（当時の制約） ▸ リージョン間VPCピアリングがな い（2017年11月〜） ▸ TGWピアリングもCloud WANもな い EC2同士のIPsec （インターネット経由） ▸ 他クラウドとはコロケーションで 物理接続 オンプレミス 当時のベストプラクティス VPC VPC 折り返し通信 DX経由でオンプレを中継するか 、EC2でVPNルーターを立てる AWS外部のネットワークサービスを使うか、EC2を自分で運用するか @whitebird_sp #NW_JAWS 10 / 20
11. テーマ③ グローバル＆マルチクラウド 2026年の常識 AWSバックボーンをWANとして使う 引退 AWS Cloud 東京 オンプレ経由の折り返し通信 リージョン間ピアリング／TGWピアリング／ Cloud WAN シンガポール Google Cloud 引退 EC2同士のIPsec 運用も帯域もAWSバックボーンに任せる OCI Cloud WAN コアネットワーク 大阪 新常識：AWS Interconnect multicloud AWS Interconnect - multicloud バージニア北部 Azure（予定） ▸ 2026年4月GA（Google Cloud） ▸ OCIも7月にGA、Azureは2026年後半 予定（プレビュー中） ▸ 仕様はApache 2.0でGitHubに公開 ※提供リージョンに東京はまだ含まれていません クラウド同士がAPIでつながる時代へ @whitebird_sp #NW_JAWS 11 / 20
12. テーマ④ IPアドレス設計 2016年の常識 とりあえず10.0.0.0/16、パブリックIPは付け放題 なぜそうだったか（当時の制約） アカウントA：VPC 10.0.0.0/16 アカウントB：VPC 10.0.0.0/16 × Public IP Public IP 10.0.1.0/24 Public IP Public IP Public IP Public IP ▸ パブリックIPv4は無料（使用中の もの） ▸ VPCのCIDRは後から追加できない （2017年8月〜） ▸ IPv6は2016年12月にオハイオから 開始したばかり 10.0.1.0/24 当時のベストプラクティス 数年後に起きること 合併・統合でVPCをつなごうとしたら、CIDRが全部重複していて、つなげない … VPCは大きめの/16で決め打ち 。パブリックIPを付ければ早い パブリックIPv4は限りある資源 @whitebird_sp #NW_JAWS 12 / 20
13. テーマ④ IPアドレス設計 2026年の常識 IPv4はコスト、IPAMで計画しIPv6を前提に パブリックIPv4（2024年2月〜） アンチパターン VPC IPAM $0.005 パブリックIPv4の乱用 コストに直結。Public IP Insightsで棚卸し トップ 10.0.0.0/8 アンチパターン /IP/時 CIDRの重複・決め打ち IPAMで組織全体を計画 100 IPで 月 約$360 東京 10.0.0.0/12 大阪 10.16.0.0/12 VPC 10.0.0.0/20 VPC 10.16.0.0/20 進化 IPv6 デュアルスタック／IPv6オンリー前提で設計 VPC（デュアルスタック） デュアルスタック サブネット IPv6 Only サブネット IPv4 ＋ IPv6 IPv6のみ。IPv4宛はDNS64＋NAT64 若手の方へ IP設計は最初が肝心。CIDRの重複は 追加設計が必要。（できるけどしない に越したことはない） アドレスは「タダの番号」から「計画して払う資源」へ @whitebird_sp #NW_JAWS 13 / 20
14. テーマ⑤ 外部への接続 2016年の常識 NATインスタンス＋フェイルオーバースクリプト なぜそうだったか（当時の制約） インターネット VPC AZ-a AZ-c パブリック NAT Gatewayは2015年12月に出た ばかり ▸ NATインスタンスの方が安く、慣 れていた ▸ 冗長化はスクリプトで自作 パブリック NATインスタンス＋監視スクリプト （送信元/送信先チェック無効） プライベート ▸ NATインスタンス＋監視スクリプト （送信元/送信先チェック無効） プライベート 当時のベストプラクティス AZごとにNATインスタンス。ヘ ルスチェックしてルートを切り 替え 障害時はスクリプトでルートを書き換え。S3通信もNAT経由 @whitebird_sp #NW_JAWS 14 / 20
15. テーマ⑤ 外部への接続 2026年の常識 リージョナルNAT GatewayとVPCエンドポイント Amazon S3 引退 インターネット NATインスタンス 検証環境のコスト削減用途を除く VPC 進化 ゲートウェイエンドポイント （VPCエンドポイント） AZ-a リージョナルNAT Gateway （パブリックサブネット不要） AZ-c AZごとのNAT Gateway リージョナルNAT GWが自動でAZを拡張・縮 退 アンチパターン AZ-d S3通信のNAT経由 ゲートウェイエンドポイントで無料に プライベート プライベート プライベート 使い分けの注意 リージョナルNAT GWはプライベート NAT非対応。その用途はゾーナルNAT GWを使います S3・DynamoDB宛はゲートウェイエンドポイント経由（無料） @whitebird_sp #NW_JAWS 15 / 20
16. テーマ⑥ アプライアンス冗長化 2016年の常識 スクリプトでルートテーブルを書き換える なぜそうだったか（当時の制約） VPC AZ-a AZ-c FW-A（稼働） EC2上の仮想FW FW-B（待機） EC2上の仮想FW ▸ VPCのルーティングは静的 ▸ アプライアンスをLBで挟む仕組み がない ▸ ENI付け替えやルート書き換えを自 作 ヘルスチェック ルートテーブル 0.0.0.0/0 → eni-FW-A 書き換え ⇒ eni-FW-B 当時のベストプラクティス 監視スクリプト／Lambda Active/Standbyの仮想FWを、 スクリプトでフェイルオーバー 切り替え時間もスクリプトの品質次第 @whitebird_sp #NW_JAWS 16 / 20
17. テーマ⑥ アプライアンス冗長化 2026年の常識 GWLB・Network Firewall・VPCでBGP インスペクション 引退 動的ルーティング スクリプトでの経路切替 GWLB／Network Firewallへ ワークロード 検査用 VPC BGP 新常識 GWLB 仮想アプライアンス VPC Route Server VPC Route Server アプライアンスからBGPでルートを動的更新 ネットワーク屋さんへ ルートテーブル AWS Network Firewall VPCで、BGPが使える時代 BGPで受けた経路を自動反映 マネージドなステートフル検査（ TGWに直接アタッチも可） オーバーレイやカスタムスクリプトなしで 、経路の冗長化を標準のBGP属性で制御で きます 2025年4月GA フェイルオーバーはマネージド側で @whitebird_sp #NW_JAWS 17 / 20
18. まとめ 10年で変わった常識、変わらない常識 テーマ 2016年の常識 2026年の常識 判定 ① AWSへの接続 VPCごとにVGW＋VIF DXGW＋TGW／Cloud WANで集約 引退 ② VPC間接続 フルメッシュ／Transit VPC TGW＋PrivateLink／ Lattice 引退 ③ グローバル オンプレ経由の折り返しまた はIPSec VPN Cloud WAN＋AWS Interconnect 引退 ④ IP設計 10.0.0.0/16決め打ち・IPv4無 料 IPAMで計画・IPv6前提 アンチパターン ⑤ 外部への接続 NATインスタンス＋スクリプ ト リージョナルNAT GW＋ VPCエンドポイント 引退 ⑥ アプライアンス スクリプトでルート書き換え GWLB／NFW／VPC Route Server 引退 殿堂入り 10年経っても変わらない常識 1 マルチAZで設計する 障害は必ず起きる前提 2 CIDRではなくSGで制御 2016年3月のSG参照拡張 3 接続は冗長化する DXの複数ロケーション＋VPN 4 IP設計は最初が肝心 重複IP対応は大変 ※VPCピアリング・ゾーナルNAT GWなど、用途次第で今も有力な選択肢は「進化」しています @whitebird_sp #NW_JAWS 18 / 20
19. 最後に 今日の制約は明日の限界ではない 「なぜそうしたいか」を理解しよう 次の10年の常識を一緒に作っていきましょう @whitebird_sp #NW_JAWS 19 / 20