【要約】【AWS障害】2026年7月16日のCloudFront VPC Origins障害まとめ [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
VPC Originsを利用してセキュリティを強化していたユーザーが、通信断に直面した。プライベートサブネット内のリソースを安全に配信するため、本機能を採用していた構成が標的となった。詳細は以下の通りである。
- ・対象: VPC Originsを利用してALBやEC2をオリジンとする構成。
- ・原因: VPC Origins専用の接続基盤における内部制約の発生。
- ・事象: ルーティング構成のロード失敗により、5xxエラーが増加した。
- ・影響: PayPayやnote、ニコニコ生放送などの大規模サービスが影響を受けた。
// Approach
AWSは、通信経路をパブリックな経路へ変更することで、障害の影響を回避する手法を提示した。専用基盤を介さない既存のオリジンタイプへ切り替えることが、暫定的な解決策となる。具体的な手法は以下の通りである。
- ・回避策: internet-facing ALBなどのパブリックオリジンへの切り替え。
- ・課題: ALBのスキームは作成後に変更できず、再作成が必要となる。
- ・推奨対策: IaCによる代替構成の事前コード化。
- ・検知策: EventBridgeを用いたAWS Health Dashboardの早期通知。
// Result
障害は21:21に完全復旧したが、利用者には構成設計の重要性が示された。AWS側の基盤修正により、VPC Origins接続は正常な状態に戻った。今後の展望として、以下の点が明確になった。
- ・復旧: AWSによる接続基盤の修正とルーティングの正常化。
- ・教訓: 新機能採用時には、障害時のフェイルオーバー手順を具体的に設計すべきである。
- ・備え: IaCによる代替構成の保持が、復旧時間の短縮に直結する。
Senior Engineer Insight
> セキュリティ向上を目的とした新機能の採用が、逆に可用性のリスクを招いた事例だ。VPC Originsは強力だが、専用基盤の内部制約という「ブラックボックスなリスク」を内包している。実戦投入においては、単なる機能の利便性だけでなく、障害時の切り替えコスト（ALBの再作成など）を考慮した設計が不可欠だ。IaCによる「逃げ道」の事前構築こそが、真のレジリエンスを担保する。