CloudFront VPCオリジン障害をInter-Region VPCピアリングで迂回してみた
はじめに
2026年7月16日 16:45 JST頃（12:45 AM PDT）、CloudFront の VPCオリジンを利用しているサービスで 5xx エラーが増加しました。AWS Service Health Dashboard には "Increased 5xx Errors" として障害が掲載されています。
Starting at 12:45 AM PDT, we are experiencing increased 5xx errors for CloudFront customers utilizing VPC Origins connectivity. We have confirmed that customers utilizing other origin types are not impacted by this issue.
根本原因について、AWS はパケット処理サブシステムのルーティングテーブル容量の問題と報告しています。このサブシステムは CloudFront のエッジロケーションから顧客 VPC 内のリソースへリクエストをルーティングするものです。
We have further scoped the issue down to routing table capacity within the packet processing subsystem responsible for routing requests from CloudFront's edge locations to resources within customer VPCs.
回避策として VPCオリジン以外のオリジンタイプへの変更（"change their origin type"）が案内されていました。本記事は、この推奨回避策の実践例として、VPCオリジンを経由しない経路をどう設計・構築し、どれくらいの時間で復旧できたかを記録するものです。対象サービスの前提構成については以下の記事で解説しています。
障害の観測
CloudFront アクセスログ v2 を Amazon Athena で抽出し、分単位で集計しました。
VPCオリジン障害と時間的に一致して増加した status=0（ClientCommError）の件数とレイテンシの推移です。
| 時刻 | 総数 | status=0 | 0率 | 404 | P95(s) | P99(s) |
|---|---|---|---|---|---|---|
| 16:45 | 1,542 | 1 | 0.1% | 8 | 0.796 | 1.224 |
| 16:46 | 1,724 | 0 | 0.0% | 6 | 0.871 | 1.134 |
| 16:47 | 1,346 | 0 | 0.0% | 16 | 0.770 | 1.187 |
| 16:48 | 1,441 | 1 | 0.1% | 3 | 0.765 | 1.253 |
| 16:49 | 1,273 | 0 | 0.0% | 8 | 0.831 | 1.646 |
| 16:50 | 1,331 | 0 | 0.0% | 17 | 0.792 | 1.408 |
| 16:51 | 1,657 | 0 | 0.0% | 3 | 0.799 | 1.446 |
| 16:52 | 1,479 | 0 | 0.0% | 34 | 0.802 | 1.469 |
| 16:53 | 1,152 | 39 | 3.4% | 26 | 0.751 | 1.700 |
| 16:54 | 729 | 200 | 27.4% | 53 | 30.518 | 30.784 |
| 16:55 | 732 | 250 | 34.2% | 60 | 30.326 | 30.554 |
| 16:56 | 643 | 245 | 38.1% | 53 | 30.311 | 30.613 |
| 16:57 | 826 | 278 | 33.7% | 42 | 30.339 | 30.627 |
| 16:58 | 703 | 261 | 37.1% | 62 | 30.312 | 30.562 |
| 16:59 | 674 | 299 | 44.4% | 69 | 30.312 | 30.448 |
主要な HTTP ステータス別の内訳です。正常率は「（総数 − status=0 − 404） / 総数」で算出しています。
| 時刻 | 総数 | 200 | 301 | 404 | 0 | 200率 | 正常率 |
|---|---|---|---|---|---|---|---|
| 16:45 | 1,542 | 1,417 | 87 | 8 | 1 | 91.9% | 99.4% |
| 16:46 | 1,724 | 1,561 | 126 | 6 | 0 | 90.5% | 99.7% |
| 16:47 | 1,346 | 1,263 | 37 | 16 | 0 | 93.8% | 98.8% |
| 16:48 | 1,441 | 1,369 | 43 | 3 | 1 | 95.0% | 99.7% |
| 16:49 | 1,273 | 1,210 | 27 | 8 | 0 | 95.1% | 99.4% |
| 16:50 | 1,331 | 1,191 | 49 | 17 | 0 | 89.5% | 98.7% |
| 16:51 | 1,657 | 1,600 | 29 | 3 | 0 | 96.6% | 99.8% |
| 16:52 | 1,479 | 1,364 | 41 | 34 | 0 | 92.2% | 97.2% |
| 16:53 | 1,152 | 1,028 | 33 | 26 | 39 | 89.2% | 94.4% |
| 16:54 | 729 | 436 | 27 | 53 | 200 | 59.8% | 65.3% |
| 16:55 | 732 | 357 | 47 | 60 | 250 | 48.8% | 57.7% |
| 16:56 | 643 | 311 | 19 | 53 | 245 | 48.4% | 53.7% |
| 16:57 | 826 | 445 | 47 | 42 | 278 | 53.9% | 61.3% |
| 16:58 | 703 | 328 | 36 | 62 | 261 | 46.7% | 54.1% |
| 16:59 | 674 | 259 | 31 | 69 | 299 | 38.4% | 45.4% |
障害の進行です。
- 16:52 まで正常（正常率 97% 以上、P95 は 1 秒未満）
- 16:53 兆候開始（ClientCommError が 39 件出現）
- 16:54 障害顕在化（
status=0が 200 件、P95 が 30 秒に急騰、ログ上の分単位件数が減少） - 16:55 以降 正常率 50% 前後で推移し、回復せず
ログ上の処理時間が約 30 秒まで伸びていたため、16:53 に発生した接続障害の多くは 16:54 のログに記録されたと考えられます。
既存フェイルオーバーの縮退動作
このサービスでは CloudFront のオリジンフェイルオーバーを設定しており、セカンダリオリジンとして Cloudflare Workers を登録していました。VPCオリジン経由での到達が失敗するようになった後も、トップページや記事ページはこの縮退先で正常に配信されていました。一方、投稿前プレビューといった動的機能は縮退先ではカバーできず支障が出ていたため、迂回構成による復旧対応を実施しました。
迂回構成の設計判断
方針は VPCオリジンを経由しない経路を CloudFront に追加することです。VPCオリジン経由のリクエストで失敗率が高まっているため、その区間を迂回して既存のバックエンド（東京リージョンの ALB → ECS）へ到達できれば機能を回復できると判断しました。
作業着手時点では VPCオリジン障害である確証はありませんでした。CloudFront から東京リージョンの VPCオリジンへ直接入る経路に問題がある可能性を考慮し、経路の入り口にはバージニア北部（us-east-1）の Public ALB を選定しました。
最終的な経路です。
CloudFront → バージニアALB(HTTPS) → Inter-Region VPC Peering → 東京NLB(固定IP) → 東京ALB → ECS
ALB のプライベート IP は変動するため、VPC ピアリング越しのターゲットを固定する目的で東京側に NLB（ターゲットタイプ ALB）を配置しています。
迂回構成の構築手順
最終的に到達した構成の手順を順に記載します。リソース識別子はダミー値に置換しています。
Inter-Region VPCピアリング作成
バージニア北部のデフォルト VPC（172.31.0.0/16）をリクエスタ、東京の本番 VPC（192.168.0.0/18）をアクセプタとして VPC ピアリング接続を作成しました。
aws ec2 create-vpc-peering-connection \
--vpc-id vpc-xxxxxxxxxxxxxxxxx \
--peer-vpc-id vpc-xxxxxxxxxxxxxxxxx \
--peer-region ap-northeast-1 \
--tag-specifications 'ResourceType=vpc-peering-connection,Tags=[{Key=Name,Value=temp-bypass-interregion}]' \
--region us-east-1
VpcPeeringConnectionId: pcx-xxxxxxxxxxxxxxxxx
Status: initiating-request
東京リージョン側で承認します。
aws ec2 accept-vpc-peering-connection \
--vpc-peering-connection-id pcx-xxxxxxxxxxxxxxxxx \
--region ap-northeast-1
Status: active
ルートテーブル設定（双方向）
両 VPC のルートテーブルに相手側 CIDR への経路を追加します。
# バージニア側: 東京VPC CIDR への経路を追加
aws ec2 create-route \
--route-table-id rtb-xxxxxxxxx \
--destination-cidr-block 192.168.0.0/18 \
--vpc-peering-connection-id pcx-xxxxxxxxxxxxxxxxx \
--region us-east-1
# 東京側: バージニアVPC CIDR への経路を追加
aws ec2 create-route \
--route-table-id rtb-xxxxxxxxxxxxxxxxx \
--destination-cidr-block 172.31.0.0/16 \
--vpc-peering-connection-id pcx-xxxxxxxxxxxxxxxxx \
--region ap-northeast-1
セキュリティグループ設定
バージニア側に ALB 用のセキュリティグループを作成し、インターネットからの HTTP/HTTPS を許可しました。
aws ec2 create-security-group \
--group-name temp-bypass-alb-sg \
--description "Temporary bypass ALB SG" \
--vpc-id vpc-xxxxxxxxxxxxxxxxx \
--region us-east-1
aws ec2 authorize-security-group-ingress \
--group-id sg-xxxxxxxxxxxxxxxxx \
--protocol tcp --port 443 --cidr 0.0.0.0/0 \
--region us-east-1
aws ec2 authorize-security-group-ingress \
--group-id sg-xxxxxxxxxxxxxxxxx \
--protocol tcp --port 80 --cidr 0.0.0.0/0 \
--region us-east-1
東京側は、既存 ALB のセキュリティグループにバージニア VPC からの HTTP を許可しました。
aws ec2 authorize-security-group-ingress \
--group-id sg-xxxxxxxxxxxxxxxxx \
--protocol tcp --port 80 --cidr 172.31.0.0/16 \
--region ap-northeast-1
東京: Internal NLB作成（固定プライベートIP、ターゲットタイプALB）
ピアリング越しのターゲットとして IP を固定するため、東京に内部向け NLB を作成しました。各サブネットにプライベート IP を明示的に割り当てています。
aws elbv2 create-load-balancer \
--name temp-bypass-nlb \
--type network \
--scheme internal \
--subnet-mappings \
SubnetId=subnet-xxxxxxxxxxxxxxxxx,PrivateIPv4Address=192.168.0.10 \
SubnetId=subnet-xxxxxxxxxxxxxxxxx,PrivateIPv4Address=192.168.16.10 \
SubnetId=subnet-xxxxxxxxxxxxxxxxx,PrivateIPv4Address=192.168.32.10 \
--region ap-northeast-1
固定IP: 192.168.0.10, 192.168.16.10, 192.168.32.10
ターゲットタイプ alb のターゲットグループを作成し、既存 ALB を登録、TCP:80 のリスナーを作成します。
aws elbv2 create-target-group \
--name temp-bypass-nlb-tg \
--protocol TCP \
--port 80 \
--target-type alb \
--vpc-id vpc-xxxxxxxxxxxxxxxxx \
--region ap-northeast-1
aws elbv2 register-targets \
--target-group-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/temp-bypass-nlb-tg/xxxxxxxxxxxxxxxx \
--targets Id=arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/existing-alb/xxxxxxxxxxxxxxxx \
--region ap-northeast-1
aws elbv2 create-listener \
--load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/net/temp-bypass-nlb/xxxxxxxxxxxxxxxx \
--protocol TCP \
--port 80 \
--default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/temp-bypass-nlb-tg/xxxxxxxxxxxxxxxx \
--region ap-northeast-1
バージニア: Internet-facing ALB作成（HTTPS、ACMワイルドカード証明書）
CloudFront のオリジンとなるインターネット向け ALB をバージニアに作成しました。
aws elbv2 create-load-balancer \
--name temp-bypass-alb \
--type application \
--scheme internet-facing \
--subnets subnet-xxxxxxxxxxxxxxxxx subnet-xxxxxxxxxxxxxxxxx \
--security-groups sg-xxxxxxxxxxxxxxxxx \
--region us-east-1
DNSName: temp-bypass-alb-xxxxxxxxxx.us-east-1.elb.amazonaws.com
ターゲットタイプ ip のターゲットグループを作成し、HTTPS リスナーに ACM ワイルドカード証明書を紐づけました。HTTP は HTTPS へリダイレクトさせています。
aws elbv2 create-target-group \
--name temp-bypass-tg \
--protocol HTTP \
--port 80 \
--target-type ip \
--vpc-id vpc-xxxxxxxxxxxxxxxxx \
--region us-east-1
aws elbv2 create-listener \
--load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/temp-bypass-alb/xxxxxxxxxxxxxxxx \
--protocol HTTPS \
--port 443 \
--certificates CertificateArn=arn:aws:acm:us-east-1:123456789012:certificate/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
--default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/temp-bypass-tg/xxxxxxxxxxxxxxxx \
--region us-east-1
aws elbv2 create-listener \
--load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/temp-bypass-alb/xxxxxxxxxxxxxxxx \
--protocol HTTP \
--port 80 \
--default-actions 'Type=redirect,RedirectConfig={Protocol=HTTPS,Port=443,StatusCode=HTTP_301}' \
--region us-east-1
バージニア ALB → 東京 NLB固定IP をターゲット登録
バージニア ALB のターゲットグループに、東京 NLB の固定プライベート IP を登録します。VPC ピアリング越しの IP ターゲットのため AvailabilityZone=all を指定しています。
aws elbv2 register-targets \
--target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/temp-bypass-tg/xxxxxxxxxxxxxxxx \
--targets Id=192.168.0.10,Port=80,AvailabilityZone=all \
Id=192.168.16.10,Port=80,AvailabilityZone=all \
Id=192.168.32.10,Port=80,AvailabilityZone=all \
--region us-east-1
DNS CNAMEレコード登録
bypass.example.com で ALB に到達できるようにし、このホスト名が ALB の HTTPS リスナーへ設定した ACM ワイルドカード証明書の対象ドメインと一致するようにしました。これにより、CloudFront から HTTPS オリジンとして利用できます。
CloudFrontにオリジン追加 + フェイルオーバーグループのprimary切り替え
CloudFront のディストリビューションに新オリジン bypass-alb-origin を追加しました。ドメインに bypass.example.com、プロトコルは HTTPS only（TLSv1.2）を指定しています。既存のオリジンフェイルオーバーグループのプライマリを bypass-alb-origin に切り替え、セカンダリは Cloudflare Workers オリジンを維持しました。
復旧確認
18:42 JST に迂回経路経由での正常動作を確認しました。障害発生（16:53）から約 1 時間は AWS 側の復旧を待ちましたが回復しなかったため、18:03 に迂回構成の構築に着手しました。着手から復旧までは約 39 分です。投稿前プレビューなどの正常動作を確認しました。
まとめ
今回の CloudFront VPCオリジン障害対応では、AWS Health で案内されていた「VPCオリジン以外のオリジンタイプへの変更」に従い、VPCオリジンを経由しない迂回経路へ切り替えました。これにより、影響を受けていた動的機能を復旧できました。
構築した迂回構成は一時的な復旧目的のため、増設した NLB・ALB は不要なコストとならないよう撤去予定です。今後は、同様の障害に備えて東京の VPC にパブリックサブネットをあらかじめ用意しておくかどうか、トレードオフを踏まえて検討していきたいと思います。
