{"id":"IL-0438","org":"ANDPAD","date":"2026-07-16","docs":[],"title":{"en":"Builder Work became almost entirely unreachable with 504 errors when the Amazon CloudFront VPC Origins feature failed","ko":"CloudFront VPC Origins 장애로 Builder Work 가 504 오류를 내며 거의 모든 접속이 막혔다"},"domain":["aws","networking","kubernetes"],"impact":{"scope":"Builder Work was almost entirely unreachable; other ANDPAD services showed no problems after login","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"VPC Origins keeps the ALB off the internet and simplifies the traffic path, but it makes the service depend on an AWS-managed shared subsystem, and when that fails the service stops even though CloudFront is healthy. ANDPAD kept VPC Origins and instead prepared the escape route ahead of time, accepting the cost of an ALB that always runs, because recreating the Ingress and attaching it to the Rollout had taken so long during this incident.","ko":"VPC Origins 는 ALB 를 Private 서브넷에 두어 인터넷에서 오는 직접 접근을 막고 통신 경로를 단순하게 해 운영 부담을 줄인다. 그 대신 CloudFront 와 오리진 사이의 통신이 AWS 가 관리하는 공유 서브시스템을 거치므로, 그 서브시스템이 망가지면 CloudFront 전체가 정상이어도 통신이 끊긴다. ANDPAD 는 VPC Origins 의 이점을 버리지 않고 장애 때 쓸 우회 경로를 미리 마련해, 다음에 같은 위험이 드러날 때의 대응 비용을 낮추기로 했다. 상시 켜 둔 ALB 의 유지 비용은 치르지만, 이번에 Ingress 재생성과 Rollout 연결에 시간이 걸린 것을 반성해 주석만 풀면 전환할 수 있게 했다."},"related":[],"sources":[{"url":"https://tech.andpad.co.jp/entry/2026/08/06/100000","kind":"blog","archived":"https://web.archive.org/web/20260806043309/https://tech.andpad.co.jp/entry/2026/08/06/100000"}],"summary":{"en":"VPC Origins lets CloudFront deliver content from applications hosted in private VPC subnets, with an ALB, an NLB or EC2 instances as the origin. Builder Work runs as containers on EKS, the AWS Load Balancer Controller turns Kubernetes Ingress resources into ALBs, and the surrounding AWS infrastructure is managed with Terraform. Builder Work had used a domain-sharding layout with separate front-end and API domains, which caused CORS errors in browsers and 401 errors during Cognito authentication because the CloudFront domain and the Host header the ALB received did not match, and the Ingress rules written to work around them were hard to operate. To remove these problems the ALB was moved from a public subnet to a private one and used as CloudFront's VPC origin, so outside traffic came only through CloudFront. Traffic between CloudFront and the origin therefore passed through an AWS-managed shared subsystem. On 16 July 2026, according to the AWS Health notice, a capacity constraint in the internal shared subsystem that manages VPC Origins connections broke that path from about 16:45 to about 20:20 JST, while CloudFront as a whole kept working.\n\nVPC Origins was the only origin configured, so ANDPAD decided to route traffic temporarily to an internet-facing ALB without CloudFront. The internet-facing Ingress and ALB had been deleted when VPC Origins was introduced, so there was nothing simple to roll back to and the Ingress had to be created again. The existing WAF was a global WAF for CloudFront, managed in the us-east-1 global scope, which cannot be attached to a regional ALB, so a regional WAF for the ALB was created with the security team. A new IngressClass combined the ACM certificate, the WAF and access log settings, and Ingresses for normal traffic, the admin screens (Cognito authentication with VPN access restriction) and redirects were added. Builder Work's deployments are managed by Argo Rollouts, so the new Ingress also had to be attached to the Rollout resource and promoted, which made the switch take considerable time. Builder Work recovered once requests were served through this layout. The SRE team handled the infrastructure and the Builder Work development team checked the application.","ko":"2026년 7월 16일 일본 시간 16시 45분쯤부터 20시 20분쯤까지 약 3.5시간 동안 Amazon CloudFront 의 VPC Origins 기능에 장애가 났다. VPC Origins 는 CloudFront 가 VPC 의 Private 서브넷에 있는 ALB, NLB, EC2 인스턴스 같은 애플리케이션의 콘텐츠를 배포하게 하는 기능이다. 나중에 AWS Health 에서 온 알림에 따르면 원인은 VPC Origins 연결을 관리하는 내부 공유 서브시스템의 용량 제약이었다. CloudFront 전체는 정상이었지만 이 서브시스템을 거치는 CloudFront 와 오리진 사이의 통신이 끊겼다.\n\nANDPAD 에서 영향을 받은 것은 Builder Work 하나였다. Builder Work 는 EKS 위에서 돌고 AWS Load Balancer Controller 가 Ingress 리소스를 ALB 에 반영하며, 주변 인프라는 Terraform 으로 관리한다. 이전에는 Public 서브넷의 ALB 와 CloudFront 로 프런트와 API 도메인을 나눴다. 그런데 CORS 오류와 Cognito 인증 때의 401 오류를 피하려고 만든 복잡한 Ingress 규칙이 부담이 되어, ALB 를 Private 서브넷으로 옮기고 CloudFront VPC Origin 으로 통신 경로를 하나로 묶었다. CloudFront 의 오리진은 VPC Origins 하나뿐이었다.\n\nSRE 팀은 CloudFront 를 거치지 않고 Internet-facing ALB 로만 라우팅하기로 했다. VPC Origins 를 도입할 때 Internet-facing Ingress 와 ALB 를 지웠으므로 Ingress 를 다시 만들어야 했다. Argo Rollouts 의 Rollout 리소스에 묶고 promote 하는 절차까지 있어 시간이 걸렸다. 기존 WAF 는 us-east-1 글로벌 범위의 CloudFront 용이라 ALB 에 연결할 수 없어, 보안 팀과 함께 리전 WAF 를 따로 만들었다. ACM 인증서, WAF, 액세스 로그 설정을 묶은 IngressClass 와 용도별 Ingress 를 더해 라우팅을 되살렸고 Builder Work 가 복구되었다. 그 뒤 ANDPAD 는 VPC Origins 와 CloudFront 구성으로 돌아가되 Internet-facing 으로 바꾸는 수단을 코드에 남겨 두었다."},"trigger":{"en":"The Amazon CloudFront VPC Origins feature failed; AWS Health later reported a capacity constraint in an internal shared subsystem that manages connections for VPC Origins.","ko":"CloudFront 의 VPC Origins 연결을 관리하는 AWS 내부 공유 서브시스템에서 용량 제약이 생겼다."},"severity":"unknown","symptoms":["service-unavailable","high-error-rate"],"timeline":{"detected_after":"15m","resolved_after":null},"date_kind":"incident","detection":{"en":"Datadog raised an alert, and at about the same time 5xx errors were seen rising on the CloudFront distributions that used VPC Origins.","ko":"17시쯤 Datadog 이 알림을 울렸고, 거의 같은 때 VPC Origins 연결을 쓰는 CloudFront 배포에서 5xx 오류가 늘고 있는 것을 알았다."},"components":["cdn","cloud-load-balancer","ingress","waf"],"root_cause":"cloud-provider","remediation":[{"text":{"en":"Decided to route traffic temporarily through an internet-facing ALB without CloudFront","ko":"CloudFront 의 오리진이 VPC Origins 하나뿐이었으므로, CloudFront 를 거치지 않고 Internet-facing ALB 로만 라우팅하도록 임시로 바꾸기로 했다."}},{"text":{"en":"Recreated the internet-facing Ingress, attached it to the Argo Rollouts Rollout resource and promoted it","ko":"VPC Origins 도입 때 지운 Internet-facing Ingress 를 다시 만들고, Argo Rollouts 의 Rollout 리소스에 묶은 뒤 promote 했다."}},{"text":{"en":"Created a regional WAF for the ALB with the security team","ko":"기존 WAF 는 us-east-1 글로벌 범위의 CloudFront 용이라 ALB 에 연결할 수 없어, 보안 팀과 함께 ALB 용 리전 WAF 를 따로 만들었다."}},{"text":{"en":"Created a new IngressClass with the ACM certificate, the WAF and access log settings","ko":"ACM 인증서, WAF, 액세스 로그 설정을 묶은 IngressClass 를 새로 만들었다."}},{"text":{"en":"Added Ingresses for normal traffic, the admin screens and redirects, which restored routing","ko":"일반 트래픽용, Cognito 인증과 VPN 접근 제한을 건 관리 화면용, 리다이렉트용 Ingress 를 더해 라우팅을 되살렸다."}}],"action_items":[{"text":{"en":"Return to the CloudFront and VPC Origins layout while keeping a way to switch to internet-facing in code","ko":"VPC Origins 와 CloudFront 구성으로 돌아가면서, 다음 장애에 대비해 Internet-facing 으로 바꾸는 수단을 코드에 넣어 둔다."}},{"text":{"en":"Keep the internet-facing ALB, limited to approved CIDRs through spec.inboundCIDRs in IngressClassParams, so commenting out securityGroupInboundCidrs in values.yaml opens it to 0.0.0.0/0","ko":"복구 때 만든 Internet-facing ALB 를 남기고, AWS Load Balancer Controller 의 IngressClassParams spec.inboundCIDRs 로 Security Group 인바운드를 사내 CIDR 과 제한 공개용 CIDR 에만 허용한다. values.yaml 의 securityGroupInboundCidrs 를 주석 처리하면 inboundCIDRs 가 빠져 0.0.0.0/0 으로 열리게 했다."}},{"text":{"en":"Point the Terraform-managed Route53 A record back to CloudFront and keep the ALB alias commented out in code, so uncommenting and applying switches DNS to the ALB","ko":"Terraform 으로 관리하는 Route53 A 레코드를 CloudFront 로 되돌렸다. ALB 로 가는 별칭 설정 route53_alias_name 은 주석 처리한 채 코드에 남겨, 주석을 풀고 apply 하면 Route53 을 ALB 로 돌릴 수 있게 했다."}}],"contributing":["single-point-of-failure"],"recurrence_of":null,"symptoms_text":{"en":"At about 17:00 JST on Thursday 16 July 2026, Datadog alerted, and at almost the same time 5xx errors began to rise on the Amazon CloudFront distributions that used VPC Origins connections. Builder Work, ANDPAD's job and career service for the construction industry, became almost entirely unreachable.\n\nCloudFront itself kept working; only the VPC Origins feature failed, and distributions using it returned many 504 Gateway Time-out errors. The SRE team found that among ANDPAD's products only one CloudFront distribution, Builder Work's, used VPC Origins. Screens and functions after login in the other ANDPAD services showed no problems.\n\nThe failure lasted about 3.5 hours, from about 16:45 to about 20:20 JST. Builder Work's ALB sat in a private subnet and was reached only through CloudFront VPC Origins, so the only options during the failure were to wait for AWS to recover or to switch the ALB back to internet-facing.","ko":"2026년 7월 16일 17시쯤 Datadog 이 알림을 울렸고, 거의 같은 때 CloudFront 에서 VPC Origins 연결을 쓰는 배포에 5xx 오류가 늘기 시작했다. CloudFront 자체는 정상으로 돌았지만 VPC Origins 기능에만 장애가 나서 504 Gateway Time-out 이 잇따랐다.\n\nSRE 팀이 조사하니 VPC Origins 를 설정한 CloudFront 배포는 ANDPAD 제품 가운데 건설업 구인·이직 서비스 Builder Work 하나뿐이었다. Builder Work 는 거의 전면적으로 접속할 수 없었고, 다른 ANDPAD 서비스는 로그인한 뒤의 화면과 기능에 이상이 없었다.\n\nBuilder Work 는 Private 서브넷의 ALB 를 CloudFront 의 VPC Origin 으로만 두었기 때문에, AWS 가 회복하기를 기다리거나 ALB 를 Internet-facing 으로 되돌리는 것 말고는 방법이 없었다."},"updated_at":"2026-11-14T12:34:08.772106Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0438","org_slug":"andpad"}