JAWS DAYS 2026登壇レポート — IPv4とVPCエンドポイントからの卒業
2026年3月7日、JAWS DAYS 2026にて「IPv4とVPCエンドポイント依存からの卒業。AWSの最新アップデートとIPv6サポートを活用した次世代Web配信アーキテクチャ」というタイトルで登壇させていただきました。
スライド公開
スライドは以下で公開しています。
セッション概要
DevelopersIOの本番環境で実践している、ネットワーク固定費を削減したAWS構成についてお話ししました。
コスト削減実績:
- Before: $303/月（ネットワーク固定費）
- 現在: $136/月（約55%削減）
- 将来: $0/月を目指す（IPv6完全移行時）
これは「固定費の断捨離」です。トラフィックに応じた従量課金は別途発生します。
背景：なぜこの構成を選んだのか
DevelopersIOは専任のシステム担当はおらず、有志が本業の合間に運用しています。そのため、ここ数年は費用対効果がよく、運用負荷の低い実行環境としてApp Runnerを採用していました。
一方で、AWSのリファレンスアーキテクチャ通りにECSを3AZ構成で組むと、以下のような構成になります：
- パブリックサブネット × 3AZ
- NAT Gateway × 3（AZ別）
- Interface型VPCエンドポイント × 12〜15個
- ルートテーブル × 3（AZ別管理）
ネットワーク固定費だけで月額$303です。
2024年から2025年にかけて、以下のアップデートがGAになりました：
- 2024年11月: CloudFront VPCオリジン
- 2025年11月: ECS Express Mode
- 2025年11月: Regional NAT Gateway
これらを組み合わせることで、パブリックサブネットの設置を省略し、ECSを採用した場合でも管理対象を大幅に削減した構成が実現可能になりました。
App Runnerでは不可能だったWebSocket対応や、より多くのリソースを利用可能な基盤の必要性が高まっていた事もあり、ECSを採用するに至りました。
Before / After 構成比較
Before: リファレンスアーキテクチャで素直に組んだ場合
| リソース | 構成 | 月額目安 |
|---|---|---|
| サブネット | パブリック × 3AZ + プライベート × 3AZ | - |
| NAT Gateway | AZ別 × 3 | ~$136 |
| ALB | パブリック | - |
| オリジン保護WAF（ALB側） | WebACL + ルール3個 | ~$22 |
| VPCエンドポイント | Interface型 4〜5個 × 3AZ | ~$123 |
| パブリックIPv4 | NAT×3 + ALB×3 = 6個〜 | ~$22 |
| ルートテーブル | AZ別 × 3 | - |
| ネットワーク固定費 | ~$303/月 |
注: DevelopersIOの旧環境ではありません。「ECSで普通に組むとこうなりがち」というリファレンス構成です。
After: 現在の構成
| リソース | 構成 |
|---|---|
| サブネット | プライベートのみ × 3AZ |
| NAT Gateway | Regional（全AZカバー） |
| ELB | Internal（VPCオリジン経由） |
| VPCエンドポイント | Gateway型 2個（S3, DynamoDB）= 無料 |
| ルートテーブル | 1つ |
コスト比較
| 項目 | Before | After（現在） | After（将来） |
|---|---|---|---|
| NAT Gateway | AZ別×3 = ~$136/月 | Regional 1つ = ~$136/月 | $0/月 |
| VPCエンドポイント（Interface型） | 4〜5個×3AZ = ~$123/月 | 0個 = $0/月 | $0/月 |
| Public IPv4課金 | ~$22/月 | $0/月* | $0/月 |
| オリジン保護WAF（ALB側） | ~$22/月 | 不要 | 不要 |
| 合計 | ~$303/月 | ~$136/月 | ~$0/月 |
現時点ではリファレンス構成に対し約55%削減です。将来的にはNAT Gatewayを撤去し、IPv6 Onlyでネットワーク固定費ゼロを目指しています。
"断捨離"を実現する3つの鍵
クラウドは「サーバーを持たない」から始まった。次は「ネットワークリソースを持たない」番。
目標: ネットワーク固定費（NAT/VPCe/IPv4/WAF等）を減らす設計。IPv6は最優先に検討すべき手段
| # | 卒業するもの | 使う技術 |
|---|---|---|
| 鍵1 | パブリックサブネット + AZ別NAT Gateway | Regional NAT GW + Egress-Only IGW |
| 鍵2 | パブリックALB + オリジン保護WAF | ECS Express Mode + CloudFront VPCオリジン |
| 鍵3 | VPCエンドポイント（Interface型） | IPv6ネイティブDB + Gateway型VPCエンドポイント |
鍵1: Regional NAT Gateway — アウトバウンド通信の最適化
2025年11月にGAとなったRegional NAT Gatewayにより、従来AZ別に個別管理していたNAT Gateway・パブリックサブネット・ルートテーブル・EIPが、すべてVPCレベルに集約されます。
CloudFormationでの設定は1行追加するだけです:
AvailabilityMode: regional
# 従来（AZ別）
SubnetId: !Ref PublicSubnet
AllocationId: !GetAtt EIP...
# Regional (GA: 2025-11)
VpcId: !Ref VPC # ← SubnetIdなし
AvailabilityMode: regional
実際のCLI出力でも、サブネットに紐付かないことが確認できます:
{
"NatGatewayId": "nat-xxxxx",
"ConnectivityType": "public",
"VpcId": "vpc-xxxxx",
"SubnetId": null,
"State": "available"
}
注: Regional NAT Gatewayはワークロードが存在するAZへ自動的に拡張し、AZ数分の時間課金が発生します。3AZでタスクを動かせば3AZ分の固定費（約$136/月）がかかるため、コスト削減ではなく管理対象の削減が主目的です。
新規VPCでNAT Gatewayが必要な場合、特殊な要件がない限りAZ別NATを選ぶ理由はありません。
なお、オートスケールが不要でAZ障害の影響を許容できる場合は、利用AZを限定してコストを抑えた運用も可能です。
公式ドキュメント: https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-regional.html
鍵2: CloudFront VPCオリジン + ECS Express Mode — インバウンド通信の最適化
CloudFront VPCオリジン（2024年11月GA）とECS Express Mode（2025年11月GA）の組み合わせにより、以下が不要になります:
- パブリックサブネット → 完全にプライベートサブネットのみ
- 自前の証明書管理 → AWS提供証明書で自動HTTPS
- オリジン保護用のWAF（ALB側） → VPCオリジンで保護
- パブリックIPv4 → Internal ELBで完結
通信経路:
ユーザー → AWS WAF（エッジ） → CloudFront
→ VPCオリジン → Internal ELB → ECS Express
CloudFrontエッジでのWAF（L7防御）は引き続き必要ですが、ALB側のオリジン保護用WAFは不要になります。
実践知見: Express Modeの柔軟性
Express Modeの最大の価値は「手軽さ」です。新規環境の増設は約6分、設定項目も数個で済むため、開発環境や「式年遷宮」的な環境刷新に向いています。
ただし、共用ALBではサービス単位でのメトリクス分離が困難です。DevelopersIOでもリリース後にノイズを避けるため、本番は通常ECSへ移行しELBを分離しました。移行はCloudFrontのオリジン追加とBehavior切り替えだけで完了し、VPCレベルの変更は一切不要でした。
Express Modeは開発環境のファーストチョイスとして有効で、高度な監視運用が必要になった段階で通常ECSへの移行を検討するのが最善と考えています。
なお、CloudFrontではなくAPI Gatewayの認証認可などの機能を必要とする場合は、VPC Link v2でも追加コストなく同様の構成が可能です。
鍵3: VPCエンドポイント（Interface型）からの卒業
DevelopersIOでは、Interface型VPCエンドポイントを完全に排除しています。
リファレンス構成ではECR、CloudWatch Logs、SSM等へのアクセスに4〜5個 × 3AZ = 12〜15個のInterface型エンドポイントが必要で、月額約$123です。
DevelopersIOの構成:
| データストア | 通信経路 | Interface型EP | コスト |
|---|---|---|---|
| Aurora DSQL | IPv6エンドポイント | 不要 | 通信無料 |
| DynamoDB Global Tables | Gateway型VPCエンドポイント | 不要 | 通信無料 |
| S3 | Gateway型VPCエンドポイント | 不要 | 通信無料 |
アーキテクチャの工夫:
- DSQLのデータを10分おきにS3へダンプ（Step Functions）
- ECSはS3から差分を読み込んでインメモリで高速応答
- 通信は、無料のGateway型VPCエンドポイント（S3）だけで完結
損益分岐点の判断
実績データ（2026年2月）を見ると、判断は明確です。
| 項目 | 月額 |
|---|---|
| Interface型VPCエンドポイント（3AZ換算） | 約$123/月 |
| NAT GWデータ処理（約385GB） | 約$24/月 |
外部CMSやECRなど一部AWSサービスの通信にNAT Gatewayを利用していますが、損益分岐点を大幅に下回るため、Interface型VPCエンドポイントは不要と判断しています。
なお、AWSコントロールプレーンAPI（CloudWatch, SSM等）は現時点でIPv4が必要なため、Regional NAT GWが残ります。これが将来IPv6対応すれば、NAT GW自体が不要になります（コスト表の「将来: $0/月」がこれに該当します）。
2AZ → 3AZ化の副次効果
従来構成では、AZ追加 = NAT GW追加 + VPCエンドポイント追加で、コスト増加するので2AZ利用にとどめていた事も多いかと思います。
今回の構成なら、「2→3AZ化のコスト増がほぼない」ため、耐障害性向上とインスタンス在庫確保の運用負荷を軽減できます。
利用AZが増えると、在庫枯渇・スポット強制停止リスクが低下します。
DevelopersIOでは複数インスタンスタイプを組み合わせたキャパシティプロバイダ設定も導入し、「100%スポット稼働」を実現済みです。
ハマりどころ
Hostヘッダー問題（CDNあるある）
VPCオリジン特有ではありませんが、Express Modeで複数サービスを共用ALBに相乗りさせる際、ホスト名ベースのバーチャルホストを利用する場合によく踏む罠です。
CloudFrontからInternal ELBへリクエストする際、Hostヘッダーをそのままフォワードすると、CloudFrontのドメイン名がHostとして渡ります。ELBに設定したホストベースの振り分けルールと一致しなくなるため、意図したバックエンドにリクエストが届きません。
解決策はOrigin request policyで AllViewerExceptHostHeader を指定することです。CachingDisabledやAllViewerなど、Hostを転送するマネージドポリシーが複数あるため要確認です。
CDNフレンドリーな設計は初期段階から意識しておくべきポイントです。調整余地のある初期構築段階でテストも実施してください。
CloudFront VPCオリジン → 定額プラン(Security Savings Bundle)では使えない
VPCオリジンは従量課金プラン専用の機能です。2025年末リリースの定額プランでは利用できないため、大規模トラフィックを計画している場合はオンデマンド料金でのコスト試算が必要です。
ただし、月間1TBの無料枠があり、請求代行（リセール）経由なら転送単価を定価の6割以上引き下げられるため、実務上大きな障害になることは稀です。定額プランにはリクエスト回数の上限やWAFカスタマイズの制約もあるため、AWSの進化に素早く追随するなら従量課金プランでの運用をお勧めします。
Express ModeとIaCの相性
Express ModeはIaC管理外で動作するため、器（インフラ）とアプリのライフサイクルを完全に分離する割り切りが必要です。
具体的には、共用ELBとVPCオリジンをIaCの初期スタックで先行作成し（タスク数0）、実環境はルール追加とVPCオリジン使い回しのみとします。器（VPC・ELB・VPCオリジン）はIaCで管理し、中身（タスク・ルーティング）はExpress Modeに委ねる構成です。
本編で紹介しきれなかった補足情報
パブリックサブネットを使わない構成の選択肢
パブリックサブネットを持たずに外部公開する方法は複数あります。
| 接続方式 | 追加固定費 | ユースケース |
|---|---|---|
| CloudFront + VPCオリジン | なし | Web配信・CDN（今回採用） |
| API Gateway + VPC Link v2 | なし | API管理・認証・スロットリング |
| Global Accelerator | ~$18/月 | CDN不要・TCP/UDP・低レイテンシ |
いずれもパブリックサブネット不要、Internal ELBで完結します。
VPC Link v2 は 2025年11月のアップデートで追加固定費が不要になりました（v1は有料）。
今回は API Gatewayの機能が不要だったため CloudFront を選択しました。要件に応じて使い分けてください。
VPCオリジンのセキュリティ
VPCオリジンのセキュリティグループ設定には2つの選択肢があります。
- CloudFrontのマネージドプレフィックスリスト
com.amazonaws.global.cloudfront.origin-facing- CloudFrontの全IPレンジを許可
- 設定が簡単、メンテナンス不要
- VPCオリジン専用のSG許可（より厳密）
- CloudFrontがVPCオリジン作成時に自動生成するSGを指定
- 特定のVPCオリジンからのみ許可
- より細かい制御が可能
なぜ直接DSQLに接続せず、S3を経由するのか
「なぜDB直接接続ではなくS3経由？」という質問をよくいただきます。ここには「ネットワークの断捨離」を貫くための、切実なトレードオフがありました。
当初はECSからDSQL（IPv6対応）へ直接接続する想定でしたが、実運用を見据えると2つの壁にぶつかりました。
1つ目はDSQLの特性です。 IAM認証に伴うレイテンシと、スケールアウト時の同時接続数のハンドリングが課題となり、前段にキャッシュ層が必須と判断しました。
2つ目はキャッシュ層のコストです。 スパイクアクセスに耐える性能のElastiCacheを採用すると、インフラ固定費が跳ね上がると判断しました。
そこで選んだのが、ECSタスクのメモリ上に記事の属性データを展開する方式です。RDBMSのインデックスやDynamoDBのGSIに相当するデータ構造をメモリに持たせることで、高速応答を実現しています。
ブログメディアは「Read高頻度・Write低頻度」であり、CloudFrontのページキャッシュで5〜10分の遅延を許容しています。バックエンド側のキャッシュ戦略にも同じ考え方を適用しました。
- DSQLからS3へ10分おきにダンプ（Step Functions）
- ECSはGateway型VPCエンドポイント経由でS3から差分を取得し、メモリに展開
キャッシュ層の固定費をゼロにする代わりに、ECSタスクのメモリ（従量課金）とデータ鮮度をトレードオフにした構成です。
データ整合性の担保:
| 項目 | 仕様 |
|---|---|
| 更新頻度 | 10分おきにDSQL → S3ダンプ（Step Functions） |
| 許容遅延 | 最大10分（ブログ配信ワークロードとして許容） |
| 障害時 | 前回スナップショットで継続（古いデータで応答） |
| 書き込み | CMS側（Contentful → Step Functions → DSQL）で別系統 |
通信経路:
- ECS → S3: Gateway型VPCエンドポイント（無料）のみ
- DB直接接続ゼロ → NAT Gatewayの従量課金も抑制
まとめ
この数年のAWSアップデートで、かつての「とりあえずパブリックとプライベートを分けて、各AZにNAT GWとVPCエンドポイントを置く」という王道のリファレンスアーキテクチャは、完全に見直し時期に来ています。
- まずは Regional NAT Gateway でAZの壁を越える
- 次に CloudFront VPCオリジン + Internal ALB でパブリックサブネットを消滅させる
- Interface型VPCエンドポイント は、「固定費 vs データ処理料金」の損益分岐点を見てから冷徹に判断する
これらを組み合わせることで、コストが下がるだけでなく、「設定ミスで意図せず外部に公開されてしまう」というリスクから解放されます。
今回紹介した構成はすべて本番稼働中です。Web配信基盤を新規に構築する際の参考となれば幸いです。
参考リンク
本編で紹介したブログ記事
- DevelopersIO基盤を「パブリックサブネットレス」なECS構成に移行してみた
- IPv6-onlyなEC2からCloudflare WARPでIPv4通信してみた
- ベクトルDB不要のセマンティック検索
関連技術記事（深掘り）
- Aurora DSQL Python Connector ベンチマーク
- Aurora DSQL MCP Skill で Kiro CLI から操作
- Aurora DSQL N+1チューニング with Kiro
AWS公式ドキュメント
最後に
JAWS DAYS 2026にご参加いただいた皆様、セッションにお越しいただいた皆様、ありがとうございました！
本記事では、時間の都合で本編に入れられなかった補足情報を中心に解説しました。
質問やフィードバックがあれば、SNSなどでお気軽にお声がけください。
導入のしやすさ
導入のしやすさでいえば、Regional NAT GWが圧倒的に簡単でした（CloudFormation 1行の変更）。次にCloudFront VPCオリジン。Express ModeはIaCとの相性を割り切れるかが判断ポイントで、実際に本番では通常ECSへ移行しています。これから試す方は、まずRegional NAT GWから始めるのがおすすめです。
