パブリックサブネットを持たない Web配信基盤の現在地

パブリックサブネットを持たない Web配信基盤の現在地 — CloudFront VPCオリジンの仕組みと2026/7/16障害を解説します クラスメソッド株式会社 鈴木 亮（@suzryo） SHIFT トラック ｜ 2026/11/07 15:05〜15:20 #jawsug #jawsfesta2026

CloudFront の後ろに ALB を置いていますか？

VPCオリジンを 使っていますか？

3月の私 3月の JAWS DAYS で、この構成を紹介しました。

7/16に止まったのはVPCオリジンだけ • 3月から約4か月後の7/16、16:45頃（JST）から、国内外の 多くのWebサービスが閲覧しづらい状態に • S3オリジンや Public ALB を使っていたサイトは、無事だっ た • DevelopersIO も、影響を受けた側だった

そもそも、 パブリックサブネットって 何のためにあったの？

CloudFront だけを通すための Public ALB CloudFront 以外からのアクセスを防ぐために、自前で組んでいたもの: • Public ALB 用の WAF • セキュリティグループ: CloudFront の IP 一覧だけ許可 • ALB のリスナールール: 合言葉のカスタムヘッダーを検証

ALBはプライベートのまま 入口は CloudFront だけ。インターネットに開いた口が、なくなります。 Public ALB 用の WAF、CloudFront の IP を許可するセキュリティグループ、ヘッダーを 検証する ALB ルール。全部要らなくなりました。

なんで、みんな そっちに向かったの？

二重管理もPublic IPv4も要らない！ • CloudFront と Public ALB の両方で、WAF や防御設定を持 たなくてよくなる • 台数が増えても、Public IPv4 が増えない

で、CloudFront と ALB の間は、 誰がつないでるの？

預けた区間 この区間を、AWS に預けています。VPCオリジンは、CloudFront からオリジンへの接 続経路そのものを預ける機能です。

預けた区間は、見えるが、触れない • 通り道は、AWS が利用者のサブネットに作る ENI （service-managed ENI）。コンソールで見える • ただし、メトリクスは提供されない。VPC フローログで推 測はできるが、観測の手がかりは乏しい • 設定は、利用者側では触れない

7/16、 何が起きたの？

16:53、正常率が急落した AWS の報告では16:45に始まり、自社ログでは16:53から異常が見えました。

原因は預けた区間の中にあった AWS の最終報告が示した原因は、VPCオリジン接続を管理するフリートが、内部の制約に達 したことです。ルーティング構成を配るシステムが、更新データを読み込めませんでした。

タイムアウトの考慮が漏れていました • VPCオリジンが無応答のとき、約30秒待ってから切り替わった（Origin Group: プライマ リ = VPCオリジン、セカンダリ = Cloudflare Workers） • P95（遅い側5%の境界）は約30.4秒。標準ログだけでは、どのタイムアウトかは判別でき なかった • 最初から入れておくもの: 待ち時間（タイムアウト）の設計と、標準ログ v2 • 詳しくは DevelopersIO の記事に書いています

障害のタイムライン 16:45 AWS の報告で、VPCオリジン利用環境の5xxが増え始める 16:53 自社ログで、エラーが増え始める 18:42 迂回経路で動的機能が復旧 20:18 AWS の最終報告が示す影響の終了

迂回路を40分で作った • 18:03、原因は未確定。VPC の中は正常、S3 オリジンも正常 • 外から VPC に入る箇所（VPCオリジンか、東京の IGW）を疑った • 東京の本番 VPC は触らず、バージニアに VPC と Public ALB を作った • 18:42、迂回経路で動的機能が復旧

で、 それでも預けていいの？

預けられる根拠は12年の実績 経験と調査で知る限り、CloudFront 自身の問題で広範囲に止まったのは、2014年11月 27日（日本時間の午前、約90分間）の DNS 障害以来、約12年ぶりです。 2020年9月26日には、日本のエッジロケーション1か所で約1時間、エラーが出ました （DevelopersIO に調査記事）。 これはVPCオリジン固有の数字ではなく、CloudFront 全体の実績です。7/16 を6時間、 2020年9月と2014年11月を各1時間の停止とみなして数えると: 期間 総時間 稼働率 1年 8,760時間 99.931% 約6年（2020年9月から） 53,592時間 99.987% 約12年（2014年11月から） 104,712時間 99.992%

VPCオリジンがIPv6に対応！ • 2026年10月15日にデュアルスタックに対応し、CloudFront から ALB まで End-to-End で IPv6 が使える • 7月の原因は、VPCオリジン接続を管理するフリートが内部の制 約に達し、ルーティング構成を配るシステムが更新データを読み 込めなかったこと（AWS の最終報告） • 対策の詳細は非公開。ただ、原因を放置したまま機能を足すとは 考えにくい（個人の見解）

大きな追加遅延は見えなかった • 8構成・5万件強の応答時間を実測した（2026/11/03公開） • Origin Shield なしの平均で、Public ALB との差は最大でも約10ms（欧州・ HTTPS で +10.6ms）

内側はHTTPでもいい？ • CloudFront から ALB までは、AWS の中で閉じた経路 • 速さを優先するなら、内側を HTTP にする選択肢もある • HTTPS が必須なら、Origin Shield で遅延を縮められる

ECS Gatewayと組むと楽！ • 2026年10月20日に発表された Amazon ECS Gateway は、 ALB を複数の ECS サービスで共有できる（1つの ALB を最 大25サービス） • 入口は VPCオリジンに一元化したまま、コンテナの配信基 盤を組みやすくなる

1つのリージョンの VPC＋ALB を CloudFront で 公開するなら、 まずは VPCオリジンから 始めてみませんか？

……と言いつつ、DevelopersIOは10月に「VPCオリジンを卒業」しました • ここまでVPCオリジンを推してきましたが、DevelopersIO自身は2026年10月に VPCオリジンを卒業しました • 約10か月稼働した「VPCオリジン ＋ Internal ALB ＋ ECS」構成から、2026/10/ 12 GAの AWS Lambda Web Functions へ全面移行完了 • なぜ卒業したのか？（VPCオリジンへの不満ではない） • アクセス解析の結果、DevelopersIOへのリクエストの2/3以上が海外からだったため • 特定リージョン（東京）のVPCに縛られず、グローバル展開できるより良い仕組みへ乗 り換えた

なぜマルチリージョン化が必要だったのか？（AI検索と5リージョン化） • AI検索の復旧・普及によるトラフィック構造の激変 • 北米（特に東海岸）やEUから、数十並列のリクエストが相当数発生する状況に • 北米やEUのリージョンで直接オフロードできれば、東京リージョンは無事でいられる • オハイオも追加し「5リージョン展開」へ • 東京・バージニア・オハイオ・オレゴン・フランクフルトの5リージョンで稼働 • 現在、東京リージョンの稼働割合は全体の約25%程度にまで分散！ • コンテナイメージもECSも内部ALBも不要になり、北米・欧州のキャッシュミス応答 は 3.3〜12.2倍高速化

副産物：NAT GatewayのIP集約による「CMSスロットリング問題」の解消 • 従来（ECS ＋ プライベートサブネット構成）の課題 • プライベートサブネットのECSから外部CMSへAPI通信する際、出口の NAT Gateway のIPアドレスに集約されていた • AI検索ボット等の数十並列リクエストでキャッシュミスが重なると、CMS側のIP制限 でスロットルして配信エラーに至っていた • Lambda Web Functions化による解消 • 5リージョンへ分散し、NAT Gatewayによる単一IP集約から脱却したことで、CMSのIP スロットリング問題がほぼ解消！

【補足①】キャッシュ機構の刷新：Lambda Web Functions + Valkey Serverless ※ローカルキャッシュからの移行と高速化 • 移行前（ECS on EC2 Spot）： • EC2のインスタンスストアおよびメモリで独自のキャッシュ機構を実現していた • 移行後（Lambda Web Functions ＋ Valkey Serverless）： • ステートレスなLambdaから Valkey Serverless を利用する構成へ刷新 • キャッシュヒット率は約90% を達成！ • さらに SWR（Stale-While-Revalidate）による時差更新 なども実装し、CMSへの負荷 を抑えつつパフォーマンスを大きく向上

【補足②】Lambda Web Functions 移行前後の定量比較データ 指標 インフラ構成 ビルド時間 (prd中央 値) デプロイ時間 (prd中 央値) 移行前：ECS (EC2 Spot) + VPCオ 移行後：Lambda Web Functions リジン VPC + Internal ALB + ECS (東京1 ZIP on S3 + グローバルエンドポイ リージョン) ント (5リージョン) 123.9 秒 62.8 秒 256.0 秒 76.2 秒 北米・欧州キャッシュ 0.4 〜 1.2 秒 (中央値) ミス応答 月額コスト概算 (5リージョン) 約 222 USD 0.075 〜 0.178 秒 (3.3〜12.2倍高 速) 約 200 USD 前後

【補足③】Lambda Web Functions 運用上の知見（クォータと監視） • サービスクォータの挙動 • `us-east-1` の vCPU 引き上げ申請は「not adjustable」で受け付けられなかった • 公式ドキュメントの通り、vCPUとリクエストレートのクォータは利用状況に応じて AWS側が自動で引き上げる仕様 • オブザーバビリティ（応答時間の計測） • `AWS/Lambda/Web` の標準メトリクスでは応答時間を取得できない • OTLP Traces endpoint へトレースを送り、`aws/spans` を CloudWatch Logs Insights で集計して可視化

【補足④】VPCオリジン × IPv6検証（NRT P99等の詳細数値） • IPv6オリジンドメイン指定時の `time-taken`（HTTP / Origin Shieldなし / 単位: ms） • 全POPの平均・P95・P99ともに、Public ALBとVPCオリジン、IPv4とIPv6でほ ぼ同等のパフォーマンスを記録 構成 全POP 全POP 全POP avg P95 P99 NRT avg NRT P95 NRT P99 Public ALB (IPv4) 248 521.2 528.5 13 37 39 Public ALB (IPv6) 249 522.2 532.2 12 38 40 VPCオリジン (IPv4) 252 525.4 535.4 10 40 72 VPCオリジン (IPv6) 253 526.4 538.1 10 38 71

参考リンク 1/4: 7/16 の障害 そのとき・そのあと CloudFront VPCオリジン障害をInter-Region VPCピアリングで迂回してみた • 当日の迂回 • 約30秒の待ち CloudFront VPCオリジン障害（2026-07-16）で約30秒のタイムアウト待 ちが発生していたことをログから確認してみた • 設定とログ CloudFront VPCオリジンのフェイルオーバー待機時間を本番ログから最適化 してみた • stale-if-error CloudFrontのstale-if-errorはオリジンタイムアウト時にいつstaleを返すか検 証してみた

• https://dev.classmethod.jp/articles/cloudfront-vpc-origin-failure-inter-region-vpc-peering-bypass/
• https://dev.classmethod.jp/articles/cloudfront-vpc-origin-incident-20260716-log-analysis/
• https://dev.classmethod.jp/articles/cloudfront-vpc-origin-failover-timeout-optimization/
• https://dev.classmethod.jp/articles/cloudfront-stale-if-error-origin-timeout-behavior/

参考リンク 2/4: VPCオリジンの今、その後 VPCオリジンの今 • IPv6 VPC origin がデュアルスタックをサポート。CloudFrontのオリジンリクエストが ALB まで IPv6 で届くか試してみた • 応答時間 CloudFront から東京リージョンの ALB への応答時間を VPC オリジン・HTTP/ HTTPS・Origin Shield で比べてみた • ECS Gateway Amazon ECS の新機能 「ECS Gateway」 を試してみた DevelopersIO のその後 • Lambda 化 DevelopersIO のバックエンドを ECS から Lambda Web Functions に移行し て、マルチリージョン化してみた • 5リージョン化 Lambda Web Functions のリージョンを 4 つから 5 つに入れ替えてみた （オハイオ追加）

• https://dev.classmethod.jp/articles/aws-cloudfront-vpc-origin-dualstack/
• https://dev.classmethod.jp/articles/cloudfront-vpc-origin-http-origin-shield-latency/
• https://dev.classmethod.jp/articles/try-amazon-ecs-gateway/
• https://dev.classmethod.jp/articles/developersio-lambda-web-functions-multiregion/
• https://dev.classmethod.jp/articles/lambda-web-functions-multiregion-add-ohio/

参考リンク 3/4: AWS 公式ドキュメント VPCオリジン • 仕組みと制約 Restrict access with VPC origins（Amazon CloudFront） • 2026年10月 Amazon CloudFront announces dual-stack support for VPC origins • 2026年10月20日 Introducing Amazon ECS Gateway: A fully-managed ingress solution for ECS services 補足（オリジンが Lambda の場合の OAC） • Function URL Restrict access to an AWS Lambda function URL origin（Amazon CloudFront） • Web Function Restrict access to an AWS Lambda Web Function origin（Amazon CloudFront）

• https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-vpc-origins.html
• https://aws.amazon.com/about-aws/whats-new/2026/10/cloudfront-vpc-origin-dualstack/
• https://aws.amazon.com/jp/blogs/aws/introducing-amazon-ecs-gateway-a-fully-managed-ingress-solution-for-ecs-services/
• https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-lambda.html
• https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-lambda-web.html

参考リンク 4/4: 稼働率の根拠 稼働率の根拠 • SLA Content Delivery Network SLA（Amazon CloudFront） • 2020年9月26日 2020年9月26日CloudFront障害中のアクセスログを調査してみた • 2014年11月27日 AmazonのCloudFrontの障害規模はどれくらいだったのか？ （GIGAZINE）

• https://aws.amazon.com/cloudfront/sla/
• https://dev.classmethod.jp/articles/cloudfront-fault-20200926/
• https://gigazine.net/news/20141213-cloudfront-down/