그래프
사례3건
3건 중 1~3번째
- 증상
2026년 7월 16일 17시쯤 Datadog 이 알림을 울렸고, 거의 같은 때 CloudFront 에서 VPC Origins 연결을 쓰는 배포에 5xx 오류가 늘기 시작했다. CloudFront 자체는 정상으로 돌았지만 VPC Origins 기능에만 장애가 나서 504 Gateway Time-out 이 잇따랐다.
- 촉발
CloudFront 의 VPC Origins 연결을 관리하는 AWS 내부 공유 서브시스템에서 용량 제약이 생겼다.
- 원인
- 구성 요소
- 기여 요인
- 감지
17시쯤 Datadog 이 알림을 울렸고, 거의 같은 때 VPC Origins 연결을 쓰는 CloudFront 배포에서 5xx 오류가 늘고 있는 것을 알았다.
- 조치
- CloudFront 의 오리진이 VPC Origins 하나뿐이었으므로, CloudFront 를 거치지 않고 Internet-facing ALB 로만 라우팅하도록 임시로 바꾸기로 했다.
- VPC Origins 도입 때 지운 Internet-facing Ingress 를 다시 만들고, Argo Rollouts 의 Rollout 리소스에 묶은 뒤 promote 했다.
- 기존 WAF 는 us-east-1 글로벌 범위의 CloudFront 용이라 ALB 에 연결할 수 없어, 보안 팀과 함께 ALB 용 리전 WAF 를 따로 만들었다.
- ACM 인증서, WAF, 액세스 로그 설정을 묶은 IngressClass 를 새로 만들었다.
- 일반 트래픽용, Cognito 인증과 VPN 접근 제한을 건 관리 화면용, 리다이렉트용 Ingress 를 더해 라우팅을 되살렸다.
- 후속 조치
- VPC Origins 와 CloudFront 구성으로 돌아가면서, 다음 장애에 대비해 Internet-facing 으로 바꾸는 수단을 코드에 넣어 둔다.
- 복구 때 만든 Internet-facing ALB 를 남기고, AWS Load Balancer Controller 의 IngressClassParams spec.inboundCIDRs 로 Security Group 인바운드를 사내 CIDR 과 제한 공개용 CIDR 에만 허용한다. values.yaml 의 securityGroupInboundCidrs 를 주석 처리하면 inboundCIDRs 가 빠져 0.0.0.0/0 으로 열리게 했다.
- Terraform 으로 관리하는 Route53 A 레코드를 CloudFront 로 되돌렸다. ALB 로 가는 별칭 설정 route53_alias_name 은 주석 처리한 채 코드에 남겨, 주석을 풀고 apply 하면 Route53 을 ALB 로 돌릴 수 있게 했다.
- 교훈
VPC Origins 는 ALB 를 Private 서브넷에 두어 인터넷에서 오는 직접 접근을 막고 통신 경로를 단순하게 해 운영 부담을 줄인다. 그 대신 CloudFront 와 오리진 사이의 통신이 AWS 가 관리하는 공유 서브시스템을 거치므로, 그 서브시스템이 망가지면 CloudFront 전체가 정상이어도 통신이 끊긴다. ANDPAD 는 VPC Origins 의 이점을 버리지 않고 장애 때 쓸 우회 경로를 미리 마련해, 다음에 같은 위험이 드러날 때의 대응 비용을 낮추기로 했다. 상시 켜 둔 ALB 의 유지 비용은 치르지만, 이번에 Ingress 재생성과 Rollout 연결에 시간이 걸린 것을 반성해 주석만 풀면 전환할 수 있게 했다.
- 증상
2025-10-20 07:45 UTC 부터 Vercel CDN 의 정적 파일 제공이 실패하기 시작했고, 실패는 최대 트래픽의 약 22% 에 이르렀다. 이 시간대가 그날 사고 전체에서 피해가 가장 컸다.
- 촉발
Vercel 이 iad1 이라 부르는 AWS us-east-1 리전에 예상치 못한 장애가 났다. 이 리전을 잃은 뒤 07:45 UTC 에 연쇄 장애가 일어나 Vercel 의 전역 캐시 인프라 일부가 사라졌다.
- 원인
- 구성 요소
- 기여 요인
- –
- 감지
06:55 UTC 에 Vercel 서비스 전반의 오류로 첫 자동 알림이 울렸고, 사고가 자동으로 만들어져 당직 엔지니어가 호출됐다. 이 알림은 us-east-1 장애가 시작될 때 울린 것으로, 캐시 장애가 시작되기 50분 전이었다.
- 조치
- 07:15 UTC 에 iad1 의 트래픽을 이웃 데이터센터로 옮기기로 했고, 07:20 에 단계적으로 옮기기 시작해 07:44 에 마쳤다.
- 07:25 UTC 부터 백업 리전이나 보조 리전을 설정한 고객의 함수 호출을 다른 리전으로 돌려 그 고객들의 서비스를 모두 되살렸다.
- 08:18 UTC 에 서비스를 복구했고, 이 연쇄 장애의 근본 원인을 완화했다.
- 후속 조치
- 이번 장애로 드러난 장애 모드를 체계적으로 막을 수 있도록 아주 자세한 기술 포스트모템을 쓴다.
- 큰 리전 장애를 미리 연습하는 훈련을 이어 가고 더 강화한다.
- 증상
일부 사용자가 시스템을 쓸 수 없다고 알려 왔다. 그 사용자들의 브라우저에서 SPA 가 SyntaxError 를 내며 동작하지 않았다. 동일본 사용자는 문제가 없었고 서일본 사용자만 영향을 받았다.
- 원인
- 구성 요소
- 기여 요인
- –
- 감지
일부 사용자가 시스템을 쓸 수 없다고 알려 와서 알았다. 대상 제품과 영향 범위를 보고 바로 워룸을 열었다.
- 조치
- Cloud CDN 의 오리진이 도쿄의 NRT 일 때는 재현되지 않고 오사카의 KIX 일 때 재현돼서 우선 Cloud CDN 캐시를 퍼지했다.
- Cloud Load Balancing 에서 꺼져 있던 Cloud CDN 의 콘텐츠 압축을 compression_mode 로 켰고, 그 뒤 사용자 쪽에서 시스템이 정상으로 동작했다.
- 후속 조치
- 서비스 운영에서 단일 장애 지점이 된 곳을 파악해 두고, 비용을 감당할 수 있으면 그런 곳을 없앤다. PaaS 와 SaaS 에서 난 장애에도 기민하게 대처할 수 있게 준비한다.
- 교훈
글쓴이는 이 장애에 맞춘 구체적인 대책은 아직 없다고 했다. 대신 서비스 운영에서 단일 장애 지점이 된 곳을 파악해 두고, PaaS 나 SaaS 에서 난 장애에도 기민하게 대처할 수 있도록 준비해야 한다고 정리했다.
이 3건에서 가장 많이 나오는 구성 요소: CDN 과 엣지 네트워크, 클라우드 로드 밸런서. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.
원인별1
클라우드 제공자 장애3건
- 기여 요인