AWS CloudFront 3시간 33분 장애: VPC Origins 설정 로드 실패가 전 세계로 번진 과정
🤖 AI Summary
2026년 7월 16일 한국시간 오후 4시 45분부터 8시 18분까지, AWS CloudFront에서 VPC Origins를 쓰는 고객의 5xx 오류가 3시간 33분 이어졌습니다. AWS 공식 요약에 따르면 프라이빗 VPC 오리진 연결을 관리하는 플릿의 내부 제약에 도달하자, 라우팅 설정을 네트워크 프로세서에 배포하는 시스템이 갱신 데이터를 제대로 로드하지 못했어요. 다른 오리진 타입은 영향이 없었고, 공식 워크어라운드도 오리진 타입 임시 변경이었죠. Canvas, Blackboard, Hugging Face 같은 서비스가 연쇄로 멈췄습니다. 작년 GCP, Azure, Cloudflare 장애와 같은 글로벌 컨트롤플레인 계열이라는 점, 그리고 폴백을 미리 리허설한 팀만 워크어라운드를 쓸 수 있었다는 점이 이번 장애의 교훈입니다.
블로그 목차
한국시간 저녁, 엣지가 아니라 연결이 끊겼습니다
7월 16일 목요일 오후 4시 45분(한국시간), AWS CloudFront를 쓰는 서비스 일부에서 5xx 오류가 치솟기 시작했습니다. 정확히는 VPC Origins 연결을 쓰는 배포만이었죠. 엣지 로케이션은 살아 있었고, 고객의 오리진 서버도 멀쩡했습니다. 끊긴 것은 그 둘을 잇는 연결 계층이었어요. 복구까지 3시간 33분, 교육 플랫폼 Canvas와 Blackboard, AI 허브 Hugging Face 등이 연쇄로 멈췄습니다.
이 글은 AWS가 공식 상태 페이지에 게시한 이벤트 요약을 기준으로 무슨 일이 있었는지 재구성하고, 같은 계열 장애가 반복되는 이유와 운영자가 준비할 것을 정리합니다. 이달 중순 GCP 장애를 다룬 7월 20일(월) 발행 GCVE 스트레치 클러스터 글과 같은 형식의 분석입니다.
타임라인: 원인 식별까지 2시간 12분, 복구까지 3시간 33분
AWS 공식 요약의 시각(PDT)을 한국시간으로 옮기면 이렇습니다. 오후 4시 45분 오류 시작, 5시 44분 첫 공지, 6시 57분 원인 식별, 7시 52분 완화 조치 실행, 8시 18분 완전 복구. 오류 시작에서 첫 공지까지 59분, 거기서 원인 식별까지 다시 1시간 13분이 걸렸죠. 공지 중간마다 AWS는 같은 워크어라운드를 반복해서 안내했습니다. "VPC Origins가 꼭 필요하지 않다면 오리진 타입을 임시로 바꾸라"는 것이었어요.
VPC Origins가 뭐길래 연결만 끊겼나
VPC Origins는 프라이빗 서브넷 안의 ALB, NLB, EC2를 오리진으로 직접 연결하는 기능입니다. CloudFront는 엣지 로케이션에서 콘텐츠를 내보내고, 없는 콘텐츠는 고객의 오리진에서 가져오는데, 원래 오리진은 S3나 퍼블릭 엔드포인트처럼 공개된 대상이었죠. 2024년 말 도입된 이 기능 덕분에 오리진을 인터넷에 노출하지 않아도 되니 보안 관점에서 매력적입니다.
대신 새 계층이 하나 생깁니다. 엣지에서 고객 VPC 안까지 요청을 넣어 주는 연결 관리 계층이죠. 이번 장애의 진원이 바로 여기였습니다. AWS 요약을 그대로 옮기면, 프라이빗 VPC 오리진 연결을 관리하는 플릿의 내부 제약(internal constraint)에 도달하자, 라우팅 설정을 네트워크 프로세서에 배포하는 시스템이 갱신된 설정 데이터를 제대로 로드하지 못했습니다. 중간 공지에서는 문제 범위를 패킷 처리 서브시스템의 라우팅 테이블 용량으로 좁혔다고 밝혔고요. 그 제약이 구체적으로 무엇이었는지는 요약에 공개되지 않았습니다.
주목할 부분은 장애의 모양입니다. 데이터 평면의 서버가 죽은 것이 아니라, 설정을 배포하는 컨트롤플레인이 정지하면서 전 세계 연결이 한꺼번에 영향을 받았습니다. 문제의 플릿은 특정 리전에 있었지만 영향 범위는 글로벌이었죠. AWS 상태 페이지에도 이 이벤트의 리전은 Global로 표기되어 있습니다.
낯익은 무늬: 글로벌 컨트롤플레인 장애의 반복
이 모양이 낯익다면 정확히 본 것입니다. 장애 모니터링 서비스 IncidentHub의 분석에 따르면, 2025년 6월 GCP는 잘못된 설정 업데이트가 전 세계로 전파됐고, 10월 Azure는 호환되지 않는 메타데이터 변경이, 11월 Cloudflare는 봇 관리 시스템의 잘못된 설정 변경이 글로벌로 퍼졌습니다. 이번 CloudFront는 배포된 설정을 로드하지 못한 경우라 방향은 반대지만, 글로벌 컨트롤플레인 한 곳이 전 세계 데이터 평면을 흔든다는 구조는 같아요.
연쇄 피해의 폭도 컨트롤플레인 장애답습니다. IncidentHub가 감지한 것만 해도 인증 서비스 Frontegg, Hugging Face, 협업 도구 Coda, 원격의료 Doxy, 그리고 Canvas와 Blackboard까지 여덟 개 이상 서비스가 함께 흔들렸어요. Canvas와 Blackboard는 2025년 10월 AWS 장애 때도 17시간 넘게 멈춘 적이 있어서, 같은 의존 구조가 같은 지점에서 반복해서 무너진 셈입니다.
운영자가 준비할 것: 폴백은 리허설까지가 폴백입니다
이번 장애에서 AWS의 공식 워크어라운드는 처음부터 끝까지 하나였습니다. 오리진 타입을 임시로 바꾸는 것. 그런데 이 우회는 장애 중에 처음 해 보는 팀에게는 사실상 없는 선택지입니다. 배포 설정을 바꿔야 하고, 보안 그룹과 오리진 노출 구조를 건드려야 하니까요. IncidentHub도 같은 점을 짚습니다. 오리진 타입 폴백을 IaC로 만들어 두고 테스트까지 마쳐 두라는 것, 그래야 워크어라운드 안내가 나왔을 때 실제로 쓸 수 있다는 것이죠.
여기에 저희 판단을 덧붙이면 점검 순서는 이렇습니다. 첫째, 우리 스택이 CloudFront의 어떤 오리진 타입을 쓰는지, VPC Origins라면 대체 경로가 있는지 확인합니다. 둘째, 인증 공급자와 CDN 같은 2차 의존성 지도를 그려요. 앱이 살아 있어도 인증이 죽으면 사용자는 들어오지 못하니까요. 셋째, 벤더 상태 페이지를 모니터링에 편입해 워크어라운드 안내를 놓치지 않게 합니다. 넷째, 오리진 장애를 캐시로 버티는 구성은 Stale-While-Revalidate 글에서, 단일 클라우드 의존을 줄이는 설계는 다중화 설계 글에서 다뤘습니다.
정리하면 이번 장애의 교훈은 명확해요. 데이터 평면 이중화만으로는 컨트롤플레인 장애를 피할 수 없고, 리전을 나눠도 글로벌 컨트롤플레인은 경계를 무시합니다. 결국 장애 시 갈아탈 경로를 평시에 만들어 두고 리허설한 팀과 그렇지 않은 팀의 차이가 3시간 33분의 체감 피해를 갈랐죠. 여기까지의 사실관계는 AWS 공식 요약과 IncidentHub 분석 기준이고, 점검 순서는 저희 운영 판단입니다.
이것만 기억하세요
7월 16일 AWS CloudFront 장애는 VPC Origins 연결 관리 플릿의 내부 제약으로 라우팅 설정 로드가 실패하며 3시간 33분간 5xx 오류를 냈습니다. 다른 오리진 타입은 무사했고, 공식 워크어라운드는 오리진 타입 임시 변경이었어요. GCP, Azure, Cloudflare에 이어 반복된 글로벌 컨트롤플레인 계열 장애이며, 오리진 폴백을 IaC로 준비하고 리허설해 둔 팀만 우회할 수 있었습니다.
자주 묻는 질문 (FAQ)
Q. 이번 장애로 정확히 무엇이 영향을 받았나요?
CloudFront에서 VPC Origins 연결을 쓰는 고객의 트래픽입니다. 한국시간 7월 16일 오후 4시 45분부터 8시 18분까지 3시간 33분간 5xx 오류가 증가했고, S3 같은 다른 오리진 타입을 쓰는 배포는 영향이 없었다고 AWS가 공식 요약에서 밝혔습니다.
Q. VPC Origins가 무엇인가요?
CloudFront가 프라이빗 서브넷 안의 ALB, NLB, EC2를 오리진으로 직접 쓰게 해 주는 기능입니다. 2024년 말 도입됐어요. 오리진을 인터넷에 노출하지 않아도 되는 대신, 엣지에서 VPC 안까지 요청을 이어 주는 연결 관리 계층이 새로 생깁니다. 이번 장애는 그 계층에서 발생했습니다.
Q. 근본 원인은 무엇이었나요?
연결 관리 플릿의 내부 제약, 그리고 그로 인한 라우팅 설정 로드 실패입니다. AWS 공식 요약에 따르면 플릿이 내부 제약에 도달한 상태에서, 라우팅 설정을 네트워크 프로세서에 배포하는 시스템이 갱신된 설정을 제대로 로드하지 못했어요. 중간 공지는 문제 범위를 패킷 처리 서브시스템의 라우팅 테이블 용량으로 좁혔다고도 밝혔습니다. 내부 제약이 구체적으로 무엇인지는 공개되지 않았습니다.
Q. CloudFront를 쓰고 있다면 무엇을 점검해야 하나요?
배포가 어떤 오리진 타입을 쓰는지부터 확인하세요. VPC Origins를 쓴다면 오리진 타입을 바꾸는 폴백 절차를 IaC로 만들어 테스트까지 해 두는 것이 좋습니다. 장애 중에 처음 시도하는 폴백은 실전에서 쓰기 어렵습니다. 인증 공급자 같은 2차 의존성 지도와 벤더 상태 페이지 모니터링도 함께 챙기시길 권합니다. 이 점검 순서는 저희 운영 판단입니다.
Q. 멀티 CDN이었다면 피할 수 있었나요?
구성에 따라 다릅니다. 이번 장애는 CloudFront의 오리진 연결 계층에서 났으므로, 다른 CDN으로 트래픽을 돌릴 수 있는 팀은 우회 여지가 있었습니다. 다만 두 번째 CDN도 같은 오리진 구조에 묶여 있다면 효과가 제한되죠. 전환 경로와 오리진 접근 구성까지 함께 설계돼 있어야 하며, 이 판단 역시 저희 운영 관점의 해석입니다.
