CloudFront VPCオリジン障害（2026-07-16）で約30秒のタイムアウト待ちが発生していたことをログから確認してみた
はじめに
2026-07-16（JST 16:45〜20:18）にCloudFrontのVPCオリジンで障害が発生しました。AWS Service Health Dashboardの最終報告では、根本原因について以下のように説明されています。
We identified the root cause of the issue as an internal constraint on the fleet that manages connections to private VPC origins. When this constraint was reached, the system responsible for distributing routing configuration to our network processors failed to load the updated configuration data correctly, affecting routing of VPC Origin connections.
VPCオリジンへのプライベート接続を管理するフリートが内部制約に到達し、ネットワークプロセッサへのルーティング設定の配信に失敗したことが原因でした。
障害当日の暫定対処（Inter-Region VPCピアリングによる迂回構成の構築）については以下の記事で紹介しています。
本記事では、VPCオリジンの前後にあるCloudFrontアクセスログとALBアクセスログから障害の影響を分析しました。対象システムはCloudFront Origin Failover Groupで以下の2系統を構成しています。
- primary： CloudFront → VPC Origin → Internal ALB（3AZ）→ ECS
- secondary： CloudFront → Cloudflare Workers（縮退運転用）
検証内容
検証環境
| 項目 | 値 |
|---|---|
| 対象 | dev.classmethod.jp（DevelopersIO） |
| CloudFront Distribution | E2XXXXXXXXXXXX |
| VPC Origin | vo_XXXXXXXXXXXXXXXXXXXXXXXX → Internal ALB（3AZ） |
| Failover Group | primary = VPC Origin、secondary = Cloudflare Workers（縮退運転用） |
| ALBノード | 3AZ（AZ-a、AZ-c、AZ-d） |
| ConnectionTimeout（障害当時） | 10秒 |
| ConnectionAttempts（障害当時） | 3回 |
| OriginReadTimeout（障害当時） | 30秒 |
ALBログから見た障害の発生
障害発生前（07:30〜07:53）のALBは全AZで正常に処理しており、HTTPレスポンスはほぼ200/308/404（500は2件のみ）、平均レスポンスタイムは0.097〜0.102秒でした。
以下は07:53:30〜07:53:55（UTC）の1秒単位のリクエスト数です。
| 時刻 (UTC) | AZ-a | AZ-c | AZ-d | 合計 |
|---|---|---|---|---|
| 07:53:30 | 5 | 2 | 4 | 11 |
| 07:53:31 | 0 | 4 | 1 | 5 |
| 07:53:32 | 2 | 2 | 2 | 6 |
| 07:53:33 | 2 | 1 | 2 | 5 |
| 07:53:34 | 1 | 1 | 1 | 3 |
| 07:53:35 | 1 | 2 | 6 | 9 |
| 07:53:36 | 5 | 3 | 0 | 8 |
| 07:53:37 | 2 | 4 | 2 | 8 |
| 07:53:38 | 3 | 0 | 2 | 5 |
| 07:53:39 | 0 | 2 | 1 | 3 |
| 07:53:40 | 3 | 2 | 4 | 9 |
| 07:53:41 | 2 | 3 | 2 | 7 |
| 07:53:42 | 3 | 1 | 0 | 4 |
| 07:53:43 | 0 | 2 | 0 | 2 |
| 07:53:44 | 3 | 2 | 4 | 9 |
| 07:53:45 | 1 | 1 | 3 | 5 |
| 07:53:46 | 1 | 0 | 1 | 2 |
| 07:53:47 | 0 | 1 | 0 | 1 |
| 07:53:48 | 0 | 0 | 0 | 0 |
| 07:53:49 | 0 | 0 | 1 | 1 |
| 07:53:50 | 1 | 0 | 0 | 1 |
| 07:53:51 | 0 | 0 | 0 | 0 |
| 07:53:52 | 0 | 0 | 0 | 0 |
| 07:53:53 | 0 | 0 | 0 | 0 |
| 07:53:54 | 0 | 0 | 0 | 0 |
| 07:53:55 | 0 | 0 | 0 | 0 |
各AZの最終リクエストはAZ-c: 07:53:47、AZ-d: 07:53:49、AZ-a: 07:53:50で、約3秒の間に相次いで途絶しています。特定AZの障害ではなく、全AZで一斉にリクエストが到達しなくなったと分かります。
ALB/ECS側には障害の兆候がなく、障害はALBに到達する前の段階で発生していたと判断できます。この観測結果はAWSが公表したVPCオリジン接続への影響と整合しています。
CloudFrontログから見たタイムアウトの実態
以下は障害前後のCloudFrontアクセスログ（origin_request 29,251件）を1分単位で集計した時系列データです。ok列はsc_statusが2xx/3xxのリクエスト数、err列はsc_statusが0または5xxのリクエスト数を示します。4xxはどちらにも含めていないため、ok+errがtotalと一致しない行があります。
| 時刻 (UTC) | total | ok | err | ok率 | p95_t (秒) | 備考 |
|---|---|---|---|---|---|---|
| 07:50 | 367 | 367 | 0 | 100.0% | 1.315 | 正常 |
| 07:51 | 404 | 404 | 0 | 100.0% | 1.397 | 正常 |
| 07:52 | 385 | 381 | 0 | 99.0% | 1.452 | 正常 |
| 07:53 | 310 | 271 | 39 | 87.4% | 4.765 | 最初のエラー発生（07:53:45） |
| 07:54 | 260 | 60 | 200 | 23.1% | 30.624 | 障害本格化 |
| 07:55 | 307 | 57 | 250 | 18.6% | 30.382 | 障害継続 |
| 07:56 | 332 | 87 | 245 | 26.2% | 30.313 | 障害継続 |
| 07:57 | 376 | 98 | 278 | 26.1% | 30.363 | 障害継続 |
| 07:58 | 339 | 78 | 261 | 23.0% | 30.328 | 障害継続 |
07:53:45に最初のエラー（sc_status=0）が発生し、07:54以降はp95レスポンスタイムが約30.3秒に張り付いています。この値は設定されたタイムアウト（OriginReadTimeout 30秒、またはConnectionTimeout 10秒×3回）に相当する約30秒と整合しており、VPCオリジンとの通信がいずれかの段階で停滞しタイムアウトに達していた状態です（どちらが支配的だったかは後述します）。
全量テーブル（07:30〜08:29 UTC）
| 時刻 (UTC) | total | ok | err | ok率 | avg_t | p95_t |
|---|---|---|---|---|---|---|
| 07:30 | 355 | 355 | 0 | 100.0% | 0.493 | 1.285 |
| 07:31 | 409 | 405 | 0 | 99.0% | 0.516 | 1.188 |
| 07:32 | 314 | 314 | 0 | 100.0% | 0.471 | 1.243 |
| 07:33 | 328 | 328 | 0 | 100.0% | 0.374 | 1.088 |
| 07:34 | 339 | 339 | 0 | 100.0% | 0.454 | 1.201 |
| 07:35 | 340 | 340 | 0 | 100.0% | 0.474 | 1.207 |
| 07:36 | 489 | 489 | 0 | 100.0% | 0.535 | 1.264 |
| 07:37 | 384 | 384 | 0 | 100.0% | 0.535 | 1.231 |
| 07:38 | 339 | 339 | 0 | 100.0% | 0.421 | 1.165 |
| 07:39 | 368 | 368 | 0 | 100.0% | 0.430 | 1.182 |
| 07:40 | 344 | 340 | 0 | 98.8% | 0.438 | 1.128 |
| 07:41 | 375 | 375 | 0 | 100.0% | 0.460 | 1.309 |
| 07:42 | 347 | 347 | 0 | 100.0% | 1.132 | 1.345 |
| 07:43 | 382 | 378 | 0 | 99.0% | 0.438 | 1.269 |
| 07:44 | 290 | 290 | 0 | 100.0% | 0.446 | 1.242 |
| 07:45 | 380 | 379 | 1 | 99.7% | 0.475 | 1.187 |
| 07:46 | 464 | 464 | 0 | 100.0% | 0.503 | 1.089 |
| 07:47 | 305 | 305 | 0 | 100.0% | 0.461 | 1.165 |
| 07:48 | 310 | 309 | 1 | 99.7% | 0.467 | 1.189 |
| 07:49 | 322 | 322 | 0 | 100.0% | 0.486 | 1.420 |
| 07:50 | 367 | 367 | 0 | 100.0% | 0.469 | 1.315 |
| 07:51 | 404 | 404 | 0 | 100.0% | 0.513 | 1.397 |
| 07:52 | 385 | 381 | 0 | 99.0% | 0.509 | 1.452 |
| 07:53 | 310 | 271 | 39 | 87.4% | 1.006 | 4.765 |
| 07:54 | 260 | 60 | 200 | 23.1% | 11.771 | 30.624 |
| 07:55 | 307 | 57 | 250 | 18.6% | 11.022 | 30.382 |
| 07:56 | 332 | 87 | 245 | 26.2% | 14.046 | 30.313 |
| 07:57 | 376 | 98 | 278 | 26.1% | 14.017 | 30.363 |
| 07:58 | 339 | 78 | 261 | 23.0% | 12.366 | 30.328 |
| 07:59 | 368 | 69 | 299 | 18.8% | 10.746 | 30.303 |
| 08:00 | 377 | 102 | 275 | 27.1% | 13.573 | 30.513 |
| 08:01 | 531 | 82 | 449 | 15.4% | 11.630 | 30.316 |
| 08:02 | 553 | 76 | 477 | 13.7% | 11.451 | 30.305 |
| 08:03 | 453 | 90 | 359 | 19.9% | 12.650 | 30.317 |
| 08:04 | 526 | 83 | 443 | 15.8% | 11.058 | 30.299 |
| 08:05 | 651 | 105 | 546 | 16.1% | 11.660 | 30.299 |
| 08:06 | 640 | 116 | 524 | 18.1% | 12.257 | 30.297 |
| 08:07 | 739 | 94 | 645 | 12.7% | 10.724 | 30.288 |
| 08:08 | 535 | 97 | 438 | 18.1% | 11.361 | 30.313 |
| 08:09 | 608 | 98 | 510 | 16.1% | 11.294 | 30.285 |
| 08:10 | 793 | 99 | 694 | 12.5% | 11.047 | 30.287 |
| 08:11 | 785 | 113 | 672 | 14.4% | 11.355 | 30.288 |
| 08:12 | 804 | 107 | 697 | 13.3% | 10.195 | 30.294 |
| 08:13 | 663 | 105 | 558 | 15.8% | 10.845 | 30.294 |
| 08:14 | 405 | 79 | 326 | 19.5% | 11.618 | 30.301 |
| 08:15 | 657 | 89 | 568 | 13.5% | 10.381 | 30.285 |
| 08:16 | 670 | 111 | 559 | 16.6% | 11.818 | 30.299 |
| 08:17 | 784 | 96 | 688 | 12.2% | 10.840 | 30.282 |
| 08:18 | 752 | 97 | 655 | 12.9% | 10.990 | 30.262 |
| 08:19 | 823 | 103 | 716 | 12.5% | 11.632 | 30.278 |
| 08:20 | 754 | 82 | 672 | 10.9% | 10.117 | 30.214 |
| 08:21 | 719 | 96 | 619 | 13.4% | 10.930 | 30.300 |
| 08:22 | 700 | 100 | 600 | 14.3% | 10.379 | 30.300 |
| 08:23 | 430 | 81 | 349 | 18.8% | 11.878 | 30.312 |
| 08:24 | 450 | 79 | 371 | 17.6% | 11.145 | 30.313 |
| 08:25 | 651 | 102 | 549 | 15.7% | 11.279 | 30.307 |
| 08:26 | 678 | 104 | 570 | 15.3% | 11.179 | 30.297 |
| 08:27 | 545 | 85 | 460 | 15.6% | 10.498 | 30.298 |
| 08:28 | 461 | 91 | 370 | 19.7% | 12.365 | 30.362 |
| 08:29 | 482 | 103 | 379 | 21.4% | 12.060 | 30.361 |
エラーの内訳です。
| エラータイプ | 件数 | 割合 | 意味 |
|---|---|---|---|
| ClientCommError | 15,672 | 89.3% | CloudFrontとviewer間の通信中断として記録される分類 |
| ClientHungUpRequest | 1,872 | 10.7% | viewerが応答完了前に接続を切断 |
ClientHungUpRequest（1,872件）はviewerが応答完了前に接続を切断したケースです。残りの大半はClientCommError（CloudFrontとviewer間の通信中断として記録される分類）であり、障害時間帯との相関から、オリジンのタイムアウトを背景に発生したものと推定されます。
エラーは複数リージョンの広範なCloudFrontエッジロケーションで同時に発生しており、特定PoPへの偏りは見られませんでした。
パス別では /articles/* がエラーの72.4%を占めており、サイトのトラフィック構成を反映した分布でした。
オリジンフェイルオーバーの効果と限界
障害中にも、1分あたり60〜116件の正常応答があり、障害継続中（07:54〜08:29）を通してok率は10〜27%で推移していました。VPCオリジンが応答できない状態で2xxが返されていることから、secondaryオリジンとして設定したCloudflare Workersが応答を返していたと推定されます。
Cloudflare Workers（devio-front-failback）では、通常ほぼ0だったInvocationsが最大2.1k/分まで増加していました。
Cloudflare Workers（devio-front-failback）のInvocations
実際に縮退運転用のバナーが表示されたページも確認しました。
縮退運転中に表示されたバナー
ただし、フェイルオーバーが発動するまでの過程に問題がありました。CloudFrontはprimaryオリジンへの接続確立またはレスポンス取得でタイムアウトに達した場合、設定されたフェイルオーバー条件に従ってsecondaryを試行します。今回のログでは約30秒の待機が観測されており、ユーザーはその待機の後に縮退ページが返される構造になっていました。
オリジンフェイルオーバーグループを構成した時点では、primaryオリジンがフェイルオーバー対象として設定したHTTPエラー（5XX等）を返すケースを想定していました。しかし実際に発生したのは「オリジンから一切応答が返らない」事象であり、タイムアウト（約30秒）の満了を待ってからsecondaryが試行される動作となりました。
暫定措置の方針
見直し対象のタイムアウト設定は以下のとおりです。
| 設定 | 現行値 |
|---|---|
| OriginReadTimeout | 30秒 |
| ConnectionTimeout | 10秒 |
| ConnectionAttempts | 3回 |
今回の障害はVPCオリジンのルーティング設定配信の失敗が原因とされています。p95がOriginReadTimeoutの30秒に一致することから、TCP接続は確立したうえで応答が返らなかった可能性が考えられますが、本記事のログからは接続確立の有無を直接特定できていません。OriginReadTimeoutの短縮が本命の改善策ですが、通常運用時のSSRレスポンスタイムとのバランスを考慮する必要があるため、適切な値は検証後に決定します。ConnectionTimeout/ConnectionAttemptsの短縮は、接続確立自体が失敗するケースへの備えとして併せて実施する予定です。
今回の分析で明らかになった改善点
前述の制約を解消するため、CloudFrontアクセスログへのフィールド追加を実施しました。origin-fbl（オリジンファーストバイトレイテンシ）、origin-lbl（オリジンラストバイトレイテンシ）、timestamp(ms)（ミリ秒精度のタイムスタンプ）の3つです。
まとめ
今回のログ分析により、VPCオリジン障害時にはCloudFront側で約30秒のタイムアウト待ちが発生する状態であったことを確認しました。オリジンフェイルオーバーは機能していたものの、primaryオリジンのタイムアウト判定を待つため、縮退応答までの待ち時間が課題となっていました。
また、今回特定できなかったタイムアウト種別やリクエスト単位の挙動についても、追加したログフィールドを活用することで、今後はオリジン側レイテンシや時刻相関をより詳細に捉えられる見込みです。
今後は再現環境で挙動を検証したうえで、CloudFrontのタイムアウト設定とオリジンフェイルオーバー設定を最適化し、再発防止策として反映する予定です。
