AWS CloudFront 장애 3시간 반... Hugging Face·PayPay·마이너포털 마비

장애 원인: VPC Origins의 '내부 연결 관리 한계'

이번 장애는 CloudFront 전체가 아닌 VPC Origins라는 특정 기능을 사용하는 고객에게만 영향을 미쳤다 . VPC Origins는 2024년 11월 출시된 비교적 새로운 기능으로, CloudFront가 고객의 VPC(Virtual Private Cloud) 내부에 있는 프라이빗 리소스(예: 내부 ALB, EC2 인스턴스)로 직접 트래픽을 라우팅할 수 있게 해준다. 즉, 인터넷에 직접 노출되지 않는 보안성이 높은 구성을 가능하게 하는 기능이다.

AWS의 사후 보고서에 따르면, VPC Origins로의 프라이빗 연결을 관리하는 컨트롤 플레인(Control Plane) 시스템 내에서 내부 연결 관리 한도(Internal Connection-Management Limit)에 도달한 것이 근본 원인이었다 . 이 한도가 초과되면서 라우팅 설정을 네트워크 프로세서에 제대로 배포하지 못했고, 결국 CloudFront의 엣지 로케이션(Edge Location)에서 고객 VPC 내 리소스로의 모든 요청이 실패하며 HTTP 504(Gateway Timeout) 및 502(Bad Gateway) 오류를 반환하게 됐다.

AWS 엔지니어들은 이 문제가 패킷 처리 서브시스템(Packet Processing Subsystem) 과 관련되어 있으며, 설정 데이터를 로드하는 시스템이 제대로 작동하지 않았다고 설명했다 .

"VPC Origins 연결을 관리하는 플릿(Fleet)에 내부 제약이 발생했습니다. 이 제약에 도달하자 라우팅 구성을 네트워크 프로세서에 올바르게 로드하는 시스템이 실패했습니다." — AWS 사후 보고서 인용

이 장애는 CloudFront 전체의 붕괴가 아니었다. S3 오리진, 인터넷을 통한 ALB 오리진 등 다른 유형의 오리진을 사용하는 서비스는 영향을 받지 않았다 . 따라서 '정적 자산(S3 제공)은 살아있지만, 동적 API 호출(VPC Origins 경유)만 5xx 오류가 발생하는' 부분 장애 패턴이 나타난 서비스도 많았다 .

장애 규모 및 영향 타임라인

장애 시간 (한국 시간 기준)

• 장애 발생: 2026년 7월 16일 오후 5시 45분경 (PDT 7월 16일 12:45 AM)
• AWS 인지 및 조사 시작: 오후 6시 44분경 (PDT 1:44 AM)
• 원인 파악: 오후 7시 57분경 (PDT 2:57 AM)
• 완전 복구: 오후 9시 18분경 (PDT 4:18 AM) — 총 지속 시간 약 3시간 33분

주요 피해 서비스

참고: 이 장애는 주로 CloudFront + 내부 ALB(Application Load Balancer) 조합으로 '보안 강화' 아키텍처를 채택한 서비스에 집중되었다. 이러한 구성은 널리 사용되는 '모범 사례'였기에, 단일 기능의 한계가 광범위한 피해를 낳은 것이다 .

반복되는 AWS 장애와 클라우드 집중 위험

이번 장애는 2025년 이후 AWS에서 발생한 세 번째 대규모 장애로, 인터넷 인프라가 소수의 하이퍼스케일 클라우드 제공업체에 지나치게 집중되어 있다는 '클라우드 집중 위험(Cloud Concentration Risk)'에 대한 우려를 다시 불러일으켰다.

최근 주요 AWS 장애 연혁

• 2025년 10월 20일 (US-EAST-1 리전 대규모 장애): Perplexity, Snapchat, Fortnite, Canva, Slack, Signal, PlayStation, Ring 카메라 등 70,000개 이상의 조직에 영향. DNS 문제가 DynamoDB 등 핵심 서비스로 전파되어 연쇄적 마비 발생. 시간당 약 7,500만 달러(약 1,000억 원)의 손실 추정 .
• 2025년 12월 24일 (크리스마스 이브 장애): 또 다른 주요 서비스 중단 .
• 2026년 7월 16일 (이번 장애): CloudFront VPC Origins 기능의 제어 평면 용량 한계 초과 .

왜 이런 일이 계속되는가?

현재 인터넷은 컴퓨팅, 스토리지, 네트워킹, DNS, 인증, CDN, 보안 등 거의 모든 핵심 인프라가 AWS, Microsoft Azure, Google Cloud라는 세 기업에 집중되어 있다. AWS는 글로벌 클라우드 시장의 약 30%를 차지하고 있으며, Azure와 Google이 각각 20%, 13%를 점유하고 있다 .

아이오와 주립대학(Iowa State University)의 연구진은 과거 10년 동안 DNS, 인증, 이메일, 보안 인프라라는 네 가지 핵심 인터넷 서비스가 소수의 글로벌 플랫폼으로 통합되었다고 지적한다. 이로 인해 한 공급자의 장애가 순식간에 여러 산업으로 '폭포수(cascade)'처럼 전파되는 구조가 만들어졌다는 것이다 .

2026년 7월의 클라우드 집중 위험 분석 보고서는 "하나의 서비스가 세 개의 가용 영역(AZ)에서 실행되더라도, 하나의 리전 제어 플레인 또는 하나의 네트워크 중개자에 의존한다면 여전히 실패할 수 있다"고 경고한다 .

이번 CloudFront 장애는 이러한 현상의 전형적인 사례다. 광범위한 인프라 붕괴가 아니라 단일 기능(VPC Origins)의 제어 평면 용량 한계가 금융, AI, 게임, 정부 등 전혀 다른 분야의 수십 개 서비스를 동시에 마비시켰다. 그 이유는 이 모든 서비스가 프라이빗 오리진 전달을 위해 동일한 AWS 경로를 공유하고 있었기 때문이다.

업계 한 분석은 "3개월 만에 두 번의 AWS 장애는 대부분의 CTO가 인정하기 두려워했던 사실을 입증했다: 단일 클라우드 의존성은 실존적 위험(Existential Risk)이다"라고 평가했다 .

결론: 클라우드 '탈중앙화'와 멀티 클라우드 전략의 필요성

이번 장애는 '보안'을 위한 아키텍처 선택(CloudFront + 내부 ALB)이 오히려 취약점이 될 수 있음을 보여주었다. 전문가들은 클라우드 의존성을 완전히 제거하는 것은 현실적으로 어렵지만, 최소한 다음과 같은 대비는 필요하다고 조언한다:

• 핵심 업무의 멀티 클라우드 분산: 하나의 클라우드에 모든 것을 의존하지 않고, 중요 워크로드를 AWS, Azure, GCP 등에 분산 배치
• 종속성 매핑(Dependency Mapping): 자사의 서비스가 어떤 클라우드 기능과 공급자에 의존하는지 명확히 파악
• 우회 경로 확보: 특정 기능(예: VPC Origins)에 장애 발생 시 다른 오리진 타입으로 빠르게 전환할 수 있는 매뉴얼 준비

AWS는 이번 장애에 대해 "VPC Origins에 의존하지 않는 다른 오리진 유형으로 변경하면 오류를 해결할 수 있다"고 안내했지만 , 사후 대응보다는 근본적인 제어 평면의 내결함성(Fault Tolerance) 확보가 더 시급한 과제로 남았다.