IPv4とVPCエンドポイントからの卒業

とVPCエンドポイント依存からの卒業 IPv4 の最新アップデートとIPv6サポートを活用した 次世代Web配信アーキテクチャ AWS JAWS DAYS 2026 | Track E | 2026/03/07 14:50 （鈴木亮） / @suzryo suzryo 1

自己紹介 略歴 鈴木亮 (@suzryo) クラスメソッド株式会社 AWSよろず支援の傍ら、DevelopersIOのバッ クエンドを構築・運用 好きなサービス: Kiro 本セッションの構成は すべて本番稼働中 年 現職ジョイン AWS Summit 2019 ウルトラクイズ優勝 2014 Japan AWS Top Engineers 2019–2025 AWS All Certifications Engineers 2021–2025 GameDay @re:Invent 2023, 2025 優勝 2

本セッションの構成（すべて本番稼働中） 3

こんなお悩みありませんか？ コスト系 パブリックIPv4アドレス課金が気になる NAT Gatewayの固定費・通信費が高い IaCテンプレート展開で大量VPCエンドポイ ント作成に戸惑い 運用・設計系 マルチAZを活かしきれていない の在庫切れ問題 AZごとのルーティングテーブル管理が負担 EC2/RDS/Aurora しかも専任インフラ担当やMSPなし。本業の片手間でこれを管理している。 4

アーキテクチャ全体像: Before 「AWSリファレンスアーキテクチ ャで素直に組んだ場合」 リソース サブネット 構成 パブリック+プライベ ート × 3AZ NAT Gateway AZ別 × 3 パブリック + オリジン ALB + WAF 保護 VPCエンドポイ Interface型 4〜5個 × ント 3AZ + ALB×3 = 6 パブリックIPv4 NAT×3 個〜 ネットワーク固定費だ 合計 けで 月額 ~$136 ~$22 ~$123 ~$22 ~$303 5

アーキテクチャ全体像: After（現在の構成） リソース サブネット 構成 プライベートのみ × 3AZ NAT Gateway Regional（全AZカバー） ELB Internal（VPCオリジン経由） VPCエンドポイ Gateway型 2個（S3, ント DynamoDB）= 無料 ルートテーブル 1つ * AWS WAF はCloudFrontエッジで継続 （L7防御） オリジン保護WAF（ALB側）は不要に シンプルなEgress設計前提。検査/オンプレ接続等の要件がある 場合は複数RT * 6

ネットワーク固定費 Before / After 項目 Before 別×3 = ~$136 VPCエンドポイント（Interface型） 4〜5個×3AZ = ~$123 Public IPv4課金（EIP/ALB） NAT×3+ALB×3 = 6個 ~$22 オリジン保護WAF（ALB側のみ） ~$22 NAT Gateway AZ Egress-Only IGW - VPC - エンドポイント（Gateway型） 合計（固定費のみ） 月〜 ~$303/ （現在） Regional 1つ = ~$136 0個 = $0 （将来） $0 $0* $0 After オリジンで不要 無料 無料 ~$136/月〜 VPC After $0 不要 無料 無料 月（固定費のみ・到達目標） ~$0/ 現在 約55%削減（~$167/月減）→ 将来（IPv6 Only / NAT GWレス）ネットワーク固定費ゼロへ のPublic IPv4 address課金: 当環境の請求実績上$0（2026/2）。課金有無はリージョン・機能で変わり得るため各自の明細で要確認 ※ NAT GWのBefore理論値は3AZ×$0.062×730h。After(Regional)は稼働AZ分の時間課金で結果的に同水準。実績はP13参照。CloudFront WAF(Edge)はBefore/After 共通のため比較対象外。従量課金は別途 * EIP/ALB 7

断捨離"を実現する3つの鍵 " クラウドは「サーバーを持たない」から始まった。 次は「ネットワークリソースを持たない」番。 目標: ネットワーク固定費（NAT/VPCe/IPv4/WAF等）を減らす設計。IPv6は最優先に検討すべき手段 # 1 2 3 卒業するもの パブリックサブネット + レガシーなNAT Gateway パブリックALB + オリジン保護用のWAF VPCエンドポイント（Interface型） 使う技術 Regional NAT GW + Egress-Only IGW オリジン IPv6ネイティブDB + VPCエンドポイント（Gateway型） ECS Express Mode + CloudFront VPC 8

鍵1: パブリックサブネットと レガシーなNAT Gatewayからの 卒業 Regional NAT Gateway + Egress-Only IGW — アウトバウンド通信の最適化 AZ単位 → リージョン単位。ルートテーブル 1つ で全AZカバー サブネット配置不要（ 指定、 なし） デフォルトモード: 全AZ自動カバー、IP自動管 理・自動スケール Egress-Only IGW: IPv6アウトバウンド専用、無 料 VpcId Regional NAT Gateway (GA: 2025-11) はなくVPCに直接作成 SubnetId は従来のAZ別NATとは異なり、サブネットで 9

鍵2: パブリックALBとオリジ ン保護用のWAFからの卒業 オリジ ECS Express Mode + CloudFront VPC ン インバウンド通信の最適化 VPCオリジンで不要になるもの: パブリックサブネット オリジン証明書の運用負担（Express Modeが自 動提供） オリジン保護用WAF（ALB側） セキュリティ: Internal ALBのSGは「CloudFrontのマネージドプ レフィックスリスト」で制限 オリジンは閉域、到達制御はSGで実施 — 10

実践: Express Modeの使い分け 導入経緯: すべてExpress Modeから開始 当初: すべてのECS（本番・開発）をExpress Modeで利用開始 課題: 開発環境のエラーログ、メトリクスが混在 対応: 本番環境は独立したECS、ELBへ移行 なぜ移行できたのか 「器（インフラ）」と「中身（アプリ）」の完全分離 から通常ECSへ移す際も、VPCレベルの変更は一切不要 Express Mode 11

実践: Express Modeの知見 実践知見 新規環境の増設は 約6分、設定項目も数個 新タスクの追加が容易 → バックエンドAPI開発が捗る ベクトルDB検索、類似記事案内など、新機能を実戦投入済み コツ: 初期スタックでモックコンテナ → 本命タスクにアップデート 移行方法 新規ELB＋通常ECSクラスタを作成し、CloudFrontのオリジンに追加してBehaviorを切り替えるだけ。 CI/CDはデプロイ先の変更のみ。VPCはそのまま。 12

鍵3: VPCエンドポイント （Interface型）からの卒業 ネイティブデータストア + VPCエンド ポイント（Gateway型） IPv6 データスト ア Aurora DSQL DynamoDB S3 通信経路 ECS →(Egress-Only IGW)→ Public IPv6 endpoint 型VPCエンドポイント GW型VPCエンドポイント GW コスト VPCe不 要 無料 無料 → IPv6で直接通信 or Gateway型（無料）で完結 → 配信側はS3経由のRead最適化設計。S3ダンプ＆イ ンメモリ展開でDB依存も解消（DB接続ゼロ） ※ DSQLはPublic endpointだがIPv6 + TLS + IAM認証。PrivateLinkは未提供のため閉 域化は現時点で割り切り 13

課題: 外部IPv4のみSaaSへの対処 現実的な対処法 等のIPv4のみSaaS → 過渡期にCloudFront+Lambdaで変換 最終的にAWSデータストアに置き換えてCDA依存を排除 Contentful CDA がIPv4のみの場合 SaaS 多くのCDNは既にDual Stack / IPv6をサポート済み 自力で変換する前に、まずIPv6対応をフィードバック → 受け入れられる可能性は十分ある 14

実績: NAT Gatewayのコスト 実績（2026年2月） NAT Gateway 項目 固定費（時間課金・稼働AZ分） データ処理（約385GB） 合計 金額 $122.94 $23.85 $146.79 は稼働AZ分だけ時間課金。EIPの割当・スケール管理は不要 Regional NAT GW 型VPCエンドポイントとの比較 Interface 前提: NAT GWは外部SaaS向けで既に必要。VPCeを追加する増分 と比較 Interface型4種×3AZ = ~$88/月（固定費） NAT GW追加データ処理 = $24/月（従量課金） → 損益分岐点を大幅に下回るため、Interface型は不要 データ処理の約半分は外部SaaS通信。AWS側(SSM等)はごくわずか 15

2AZ → 3AZ化の副次効果 従来構成では、AZ追加 = NAT GW追加 + VPCエンドポイント追加 → コスト増が大きく2AZに留めがち 今回の構成なら AZ追加のたびにNAT/VPCeを増設する必要がなく、増分が小さい 3AZで耐障害性向上 + インスタンス在庫確保の運用負荷を軽減 利用AZが増えると、在庫枯渇・スポット強制停止リスクが低下 DevelopersIOでも 100%スポット稼働 を実現済み 16

ハマりどころ ①: Hostヘッダー問題（CDNあるある） オリジン × CloudFront × 共用ALBの罠 VPC オリジン特有の問題ではありませんが、Express Modeで複数サービスを共用ALBに相乗りさせる際に よく踏む罠です。 VPC 解決策 で を指定 等を使うと、CloudFrontのドメイン名がHostとして渡る → ALBのホストベースの振り分けルールが機能しなくなる Origin request policy AllViewerExceptHostHeader AllViewer 具体例: ALBがPathではなくHostで振り分ける場合 設定 値 Host AllViewer d123.cloudfront.net AllViewerExceptHostHeader ALB のDNS名 振り分け ルール不一致 → デフォルトへ 正常に振り分け ALB 教訓: CDNフレンドリーな設計は初期段階から。調整余地のある初期構築段階でテストも実施してください。 17

ハマりどころ ②: 定額プランでは使えない オリジン → Security Savings Bundle 非対応 CloudFront VPC オリジンは 従量課金プラン専用 2025年末リリースの定額プランでは利用不可 VPC ただし… 従量課金でも 1TB/月の無料枠 あり 請求代行（リセール）経由なら単価自体が大幅割引 定価: $0.114/GB → 割引後: $0.0399/GB（約65%OFF） → 大きなコスト要素にはなりにくい 定額プランが合うケース 完全S3オリジン、高度なWAF保護不要なワークロード等 補足: VPCブロックパブリックアクセスにも注意（アカウントレベルのデフォルトブロック） 18

ハマりどころ ③: Express Modeの制約 との相性 IaC はIaC管理外で動作 → 継続的なIaC管理との相性が良くない 設計思想: 器（インフラ）と中身（アプリ）のライフサイクルを分離 Express Mode 運用上の課題 共用ALBのため、ログ・メトリクスでサービス単位の切り分けが難しい エラー判別を容易にするため、フロント本番は通常ECSへ移行 バックエンドは開発中のため、Express Modeで継続 回避策: 初期スタック戦略 共用ELB + VPCオリジンを初期スタックで先行作成（タスク数0） 実環境はルール追加 + VPCオリジン使い回しのみ Express → 通常ECSへの移行は容易（本番サービスの一部は移行済み） 19

今後の展望 本セッションで紹介した構成: IPv6 Dual Stack（IPv4はRegional NAT GWで残存） 今後AWSサービスのIPv6対応が進めば → NAT Gatewayレス（IPv6 Only） も視野 コスト比較表の「将来: $0/月」がこれに該当 開発環境の別アカウント化 現在はNAT Gateway等の固定コストを避けるため、開発・本番が同一VPCに相乗り NAT Gatewayレス（IPv6 Only）になれば、開発環境専用アカウントへ移行予定 開発環境ではECSを1AZに限定しNAT Gateway費用を1/3に抑える運用もできるため、別アカウント化の前倒しも 検討中 20

まとめ この数年のAWSアップデートで、かつてのリファレンスアーキテクチャも 見直し時期 に来ています。 次に試すべきこと（チェックリスト） 1. まずは Regional NAT Gateway 2. 次に CloudFront VPCオリジン + Internal ALB 新規VPCは原則これ。AZ別NATは過去のもの 最小構成で検証。パブリックサブネット不要を体感 型VPCeは「損益分岐点」を見てから 3. Interface データ処理料金 vs VPCe固定費を比較 ネットワークリソースの「断捨離」を始めよう 今回紹介した構成は すべて本番稼働中。 試さないのはもったいない。まずは開発環境から、新規構築の機会があればお試しください！ 21

ありがとうございました 関連ブログ記事 @suzryo | DevelopersIO 22

Appendix 以降のスライドは本編では使用しません 質疑応答・補足資料用 23

が使えない場合の逃げ道 Appendix: CloudFront Global Accelerator + Internal ELB アプリ改修が間に合わない等でCloudFrontを諦めても、パブリックサブネットに先祖返りする必要は ない 閉域VPCのままセキュアに外部公開を維持 Global Acceleratorの固定費（約$18/月）はかかるが、パブリックサブネット+NAT GW維持よりシン プル 24

トンネル Appendix: IPv4 over IPv6 IPv6-only EC2 + Cloudflare WARP だけでSSM・IPv4通信可能に AWSにCloudflare WARP相当のトンネルやNAT64料金見直しを期待 IPv6-onlyなEC2からCloudflare WARPでIPv4通信してみた UserData 25

• https://dev.classmethod.jp/articles/ipv6-only-ec2-cloudflare-warp-ipv4/

Appendix: 開発環境アカウント分離 でも今後、バックエンドAPIとフロントのサイドカー相乗り等の作り込みに合わせて開 発環境の隔離を計画中 その時点でIPv6サポートがさらに広がっていれば、無駄なコスト追加なく実現できる DevelopersIO 26

の証拠

Appendix: Regional NAT Gateway

が存在しない = パブリックサブネット配置不要

SubnetId

実出力（一次証拠）

1. CLI

// aws ec2 describe-nat-gateways --nat-gateway-ids nat-xxxxx
{
"NatGatewayId": "nat-xxxxx",
"ConnectivityType": "public",
"VpcId": "vpc-xxxxx",
"SubnetId": null,
// ← Regionalではサブネットに紐付かない
"State": "available"
}

2.

公式ドキュメント
https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-regional.html

定義（参考）

3. CloudFormation

# 従来（AZ別）
# Regional（GA: 2025-11）
SubnetId: !Ref PublicSubnet
VpcId: !Ref VPC # ← SubnetIdなし
AllocationId: !GetAtt EIP... AvailabilityMode: regional

27

• https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-regional.html

Appendix: 想定質問と回答 の障害時の挙動は？ Q1: Regional NAT Gateway デフォルトモードでは全AZを自動カバー。AWSが可用性を管理し、IPも自動スケール。AZ障害時も他 AZで継続稼働。 A: から通常ECSへの移行時のダウンタイムは？ Q2: Express Mode ゼロダウンタイム可能。新規ELB+ECSクラスタを作成し、CloudFrontのBehaviorで段階的に切り替え。 Blue/Green方式。 A: にした場合、既存のIPv4専用ツールは？ Q3: IPv6 Only で対応可能だが、Cloudflare WARPの方が簡単。UserDataだけで設定完了。 A: NAT64/DNS64 Q4: コスト削減の実績は？ ネットワーク固定費: $303→$136〜（理論値ベース、55%削減）。実績はP13参照。将来IPv6 Onlyで $0。ただし従量課金費用は別途。 A: 28

Appendix: パブリックサブネットレスの選択肢 接続方式 追加固定費 CloudFront + VPCオリジン なし API Gateway + VPC Link v2 なし Global Accelerator ~$18/月 ユースケース Web配信・CDN（今回採用） API管理・認証・スロットリング CDN不要・TCP/UDP・低レイテンシ いずれも パブリックサブネット不要、Internal ELBで完結 VPC Link v2 は 2025年11月のアップデートで追加固定費が不要に（v1は有料） 今回は API Gateway の機能が不要だったため CloudFront を選択 要件に応じて使い分けを 29

オリジンのセキュリティ Appendix: VPC の設定方法（2つの選択肢） SG のマネージドプレフィックスリスト 1. CloudFront com.amazonaws.global.cloudfront.origin-facing の全IPレンジを許可 設定が簡単、メンテナンス不要 CloudFront オリジン専用のSG許可（より厳密） 2. VPC がVPCオリジン作成時に自動生成するSGを指定 特定のVPCオリジンからのみ許可 より細かい制御が可能 CloudFront 推奨 本番環境では VPCオリジン専用のSG許可 を推奨（最小権限の原則） 30

Appendix: コスト表の詳細前提条件 前提条件（P7のコスト表） リージョン: 東京リージョン 固定費のみ: データ処理料金、従量課金は別途 Regional NAT GW: VPCに1つ。サブネット配置不要。稼働AZ分だけ時間課金。EIPの割当・スケール 管理は不要 Interface型VPCe: 時間課金のみ（データ処理料金は含まず） ALBのIPv4課金: AZ数（サブネット数）に依存 将来: ECS等の必須サービスがIPv6完全対応すればNAT GW自体が不要に 重要な注意事項 固定費ゼロ ≠ 総コストゼロ トラフィックに応じた従量課金費用は別途発生 トラフィックがない時の無駄な固定費を断捨離したのがポイント 31

ダンプ＆インメモリ展開の整合性 Appendix: S3 なぜDB直接接続ではなくS3経由？ スケールアウト時のDB同時接続問題を回避 配信側は Read最適化 に徹する設計 データ整合性の担保 項目 仕様 更新頻度 10分おきにDSQL → S3ダンプ（Step Functions） 許容遅延 最大10分（ブログ配信ワークロードとして許容） 障害時 前回スナップショットで継続（古いデータで応答） 書き込み CMS側（Contentful → Step Functions → DSQL）で別系統 通信経路 → S3: Gateway型VPCエンドポイント（無料） のみ DB直接接続ゼロ → Interface型VPCエンドポイントもNAT経由も不要 ECS 32