IL-0438 ANDPAD · 2026-07-16awsnetworkingkubernetes
Builder Work became almost entirely unreachable with 504 errors when the Amazon CloudFront VPC Origins feature failed
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.
VPC 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.
- Severity
- –
- Scope
- Builder Work was almost entirely unreachable; other ANDPAD services showed no problems after login
- Users affected
- –
- Region
- –
- Time to detect
- 15m
- Time to resolve
- –
Symptoms
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.
CloudFront 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.
The 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.
Symptom Service outageHigh error rate
Root cause
Root cause Cloud provider outage
- Trigger
- 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.
Detection
Datadog raised an alert, and at about the same time 5xx errors were seen rising on the CloudFront distributions that used VPC Origins.
Remediation
- Decided to route traffic temporarily through an internet-facing ALB without CloudFront
- Recreated the internet-facing Ingress, attached it to the Argo Rollouts Rollout resource and promoted it
- Created a regional WAF for the ALB with the security team
- Created a new IngressClass with the ACM certificate, the WAF and access log settings
- Added Ingresses for normal traffic, the admin screens and redirects, which restored routing
Action items
- Return to the CloudFront and VPC Origins layout while keeping a way to switch to internet-facing in code
- 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
- 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
Lessons
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.
Sources
Related cases
IL-0364A quarter of Cloud Platform ingress traffic was slow because an AWS NLB stopped health-checking targets in one zoneUK Ministry of Justice · 2022same root cause · shared Cloud load balancer, Ingress controller
IL-0463Secure Connect connectors timed out after a GKE control plane upgrade left Harness's internal load balancer unreachableHarness · 2026same root cause · shared Cloud load balancer
IL-0357Up to 22% of Vercel static file requests failed when part of its global cache was lost during the AWS us-east-1 outageVercel · 2025same root cause · shared CDN and edge network
IL-0542Twingate authentication and authorization requests failed at higher rates after traffic moved onto a smaller GKE clusterTwingate · 2025same root cause · shared Cloud load balancer
IL-0584Cloud CDN at Osaka served corrupted JavaScript files, and a single-page app failed with a SyntaxError in western JapanMonicle · 2024same root cause · shared CDN and edge network
IL-0446About 20% of requests to an ITANDI ECS service got ALB 5XX errors, apparently from one zone, right after a deployITANDI · 2020same root cause · shared Cloud load balancer
IL-0014A GKE upgrade to a withdrawn version stalled on slow drains and a stuck node pool, then broke an ingress and confused the HPAloveholidays · 2019same root cause · shared Ingress controller
IL-0494Netlify's central load balancer IP stopped responding when Rackspace null-routed it in a DDoS, and A-record sites hungNetlify · 2016same root cause · shared Cloud load balancer
Check your cluster for this
For AI tools and scripts
- This case as JSON: https://incidentlib-api.benchlet.com/cases/IL-0438
- The cases most like it: https://incidentlib-api.benchlet.com/cases/IL-0438/similar
- MCP server (Streamable HTTP, no key):
https://incidentlib-mcp.benchlet.com/mcp
The API needs no key. The MCP server offers search_incidents, get_incident, list_incidents, get_topic and vocab; both are explained on API and MCP.