{"id":"IL-0368","org":"PlanetScale","date":"2025-10-20","docs":[],"title":{"en":"PlanetScale's control plane went down and some database branches failed queries during the AWS us-east-1 outage","ko":"AWS us-east-1 장애 동안 PlanetScale 컨트롤 플레인이 멈추고, 이어 일부 데이터베이스 브랜치가 네트워크 분할로 쿼리에 실패했다"},"domain":["aws","database","networking"],"impact":{"scope":"PlanetScale control plane (creating, resizing and configuring database branches), dashboard, SSO login and status page; queries, replication and query routing for some database branches in us-east-1","users":"unknown","region":"AWS us-east-1"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Keeping the control plane separate from the data plane meant the control plane outage did not affect customer databases, and redundancy, automated failover and zonal traffic routing limited the effect of the network partitions. Network partitions are hard to reason about, test and tolerate: with three availability zones a system survives losing one zone only if the other two can still reach each other reliably.","ko":"PlanetScale 은 컨트롤 플레인과 데이터 플레인을 확실히 나눠 둔 덕분에 컨트롤 플레인 장애가 고객 데이터베이스에 번지지 않았다고 봤다. 중복 구성과 자동 장애 조치로 프라이머리 데이터베이스 서버가 네트워크 분할의 다수 쪽으로 옮겨 갔고, 영역을 고려한 트래픽 라우팅이 분할의 영향을 최대한 줄였다. 네트워크 분할은 장애 양상 가운데 따져 보기도, 시험하기도, 견디기도 가장 어려운 편이다. 가용 영역 세 개를 쓰면 하나가 망가져도 버틸 수 있지만, 나머지 두 영역 사이의 네트워크 연결이 믿을 만할 때만 그렇다."},"related":[],"sources":[{"url":"https://planetscale.com/blog/aws-us-east-1-incident-2025-10-20","kind":"blog","archived":"https://web.archive.org/web/20260516134625/https://planetscale.com/blog/aws-us-east-1-incident-2025-10-20"}],"summary":{"en":"The incident had two phases. In the first, the PlanetScale control plane service that creates, resizes and configures database branches, which is hosted in AWS us-east-1, was unavailable. That service depends on PlanetScale's internal secret-distribution service, which depends on Amazon S3, which depends on AWS STS, and AWS STS was impacted by the Amazon DynamoDB outage. The dashboard, hosted by a provider that also runs in us-east-1, was intermittently available, SSO logins failed and the status site could not be updated. No database branch lost capacity or connectivity. PlanetScale engineers investigated but took no corrective action, and service returned at 9:30 UTC once the upstream providers recovered.\n\nIn the second phase, from 10:05 UTC, new EC2 instances could not be launched in us-east-1, so branch creates and resizes stayed queued while existing MySQL and Postgres servers kept running. To need fewer new instances, engineers disallowed new databases in us-east-1 and made us-east-2 the default region, delayed new backups and cancelled pending ones that were waiting for an instance (a PlanetScale backup launches an extra replica that restores the previous backup and catches up on replication before taking the new one), asked PlanetScale Managed customers with vtgate autoscaling to shed load, paused the routine draining of instances older than 30 days, and kept vacant instances for reuse instead of terminating them. The most important change was to bin-pack vtgate processes more tightly than usual, closer to CPU capacity, for customers with autoscaling, so there was enough vtgate capacity for the US work day.\n\nFrom about 14:30 UTC partial network partitions between availability zones made many queries fail for some customers, depending on which zones a branch used and whether its traffic crossed zones. Automated failover moved primaries to the majority side of the partitions, and engineers sent manual reparent requests to move primaries to healthier zones or next to the customer's application. The partitions healed gradually between about 18:30 and 19:30 UTC. PlanetScale's edge load balancer and some vtgate processes could not recover on their own because of how those processes had experienced the partition, and engineers restarted them. The incident commander declared the incident resolved at 20:32 UTC.","ko":"2025년 10월 20일 PlanetScale 은 서비스 제공자 한 곳의 DNS 설정 오류로 시작해 몇 시간 동안 이어진 용량 제약과 네트워크 불안정의 영향을 받았다. 장애는 두 단계로 나뉘었다. 첫 단계에서는 PlanetScale 컨트롤 플레인이 멈췄고, 둘째 단계에서는 AWS us-east-1 에 있는 일부 데이터베이스 브랜치가 영향을 받았다.\n\n첫 단계는 7:13 UTC 에 프로덕션 테스트가 실패하면서 드러났다. 데이터베이스 브랜치를 만들고 크기를 바꾸고 설정하는 서비스는 us-east-1 에 있었고, 내부 시크릿 배포 서비스에 기댔다. 이 시크릿 배포 서비스는 Amazon S3 에, S3 는 AWS STS 에 기댔는데, AWS STS 가 Amazon DynamoDB 장애의 영향을 받았다. us-east-1 에 있는 제공자가 호스팅하는 대시보드도 됐다 안 됐다 했고, SSO 로그인과 상태 페이지 업데이트도 막혔다. 고객 데이터베이스 브랜치는 용량과 연결을 잃지 않았다. 엔지니어들은 조사만 하고 고치는 조치는 하지 않았고, 9:30 UTC 에 상위 서비스 제공자가 복구되자 서비스가 돌아왔다.\n\n둘째 단계는 10:05 UTC 에 한 고객 환경의 Kubernetes operator 가 자원을 다 쓰고 있다는 알림으로 시작했다. 원인은 us-east-1 에서 새 EC2 인스턴스를 띄울 수 없는 것이었다. 미국 동부의 월요일 업무가 곧 시작될 참이었다. Vitess 클러스터의 vtgate 를 하루 주기로 자동 확장하는 큰 고객 일부는 지난주의 절반도 안 되는 vtgate 용량으로 주간 최대 트래픽을 맞을 상황이었다. 엔지니어들은 띄워야 할 EC2 인스턴스를 줄이고 돌고 있는 인스턴스를 지키는 조치를 했다. vtgate 프로세스는 평소보다 빽빽하게 배치했다. 14:30 UTC 쯤부터는 부분적인 네트워크 분할로 가용 영역 사이의 쿼리 라우팅과 복제가 끊겨 일부 고객의 쿼리가 많이 실패했다. 엔지니어들은 프라이머리를 더 건강한 영역으로 옮겼고, 분할이 18:30 UTC 에서 19:30 UTC 사이에 풀린 뒤 스스로 복구하지 못한 프로세스를 재시작했다. 인시던트 커맨더는 20:32 UTC 에 장애가 끝났다고 선언했다."},"trigger":{"en":"The incident started with a DNS misconfiguration at one of PlanetScale's service providers. An Amazon DynamoDB outage impacted AWS STS, and several hours of capacity constraints and network instability in AWS us-east-1 followed.","ko":"PlanetScale 의 서비스 제공자 한 곳에서 DNS 설정 오류가 났고, 이어서 AWS us-east-1 에 몇 시간 동안 용량 제약과 네트워크 불안정이 이어졌다."},"severity":"unknown","symptoms":["service-unavailable","autoscaler-scale-up-failed","network-unreachable","high-error-rate","replication-lag","dns-resolution-failures"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":{"en":"PlanetScale's continuous testing in production started failing and alerted engineers at 7:13 UTC. At 10:05 UTC an alert fired for a Kubernetes operator in a large single-tenant customer installation exhausting its resources.","ko":"첫 단계는 7:13 UTC 에 프로덕션에서 계속 도는 테스트가 실패하면서 엔지니어들에게 알림이 갔다. 둘째 단계는 10:05 UTC 에 한 고객 환경의 Kubernetes operator 가 쓸 수 있는 자원을 모두 쓰고 있다는 알림으로 알았다."},"components":["database","database-replication","database-proxy","object-storage"],"root_cause":"cloud-provider","remediation":[{"text":{"en":"Disallowed new databases in us-east-1 and made us-east-2 the default region for new databases","ko":"us-east-1 에 새 데이터베이스를 만드는 것을 잠시 막고, 새 데이터베이스의 기본 리전을 AWS us-east-2 로 바꿨다."}},{"text":{"en":"Delayed new backups and cancelled pending backups that were waiting for an EC2 instance","ko":"추가 백업 예약을 미루고, EC2 인스턴스를 띄우려고 기다리던 백업을 취소했다. PlanetScale 의 표준 백업은 백업 동안 데이터베이스의 용량과 장애 내성이 줄지 않도록 복제본을 하나 더 띄워 이전 백업을 복원하고 복제를 따라잡은 뒤 새 백업을 뜬다."}},{"text":{"en":"Advised PlanetScale Managed customers with vtgate autoscaling to shed load","ko":"vtgate 자동 확장을 쓰는 PlanetScale Managed 고객에게 큐 처리를 미루거나 ETL 작업을 멈추는 식으로 줄일 수 있는 부하를 줄이라고 권했다."}},{"text":{"en":"Paused draining and terminating EC2 instances older than 30 days","ko":"30일이 넘은 EC2 인스턴스를 비우고 종료하던 상시 작업을 멈췄다."}},{"text":{"en":"Kept vacant EC2 instances for reuse instead of terminating them","ko":"비게 된 EC2 인스턴스를 종료하지 않고 다시 쓰려고 남겨 뒀다."}},{"text":{"en":"Bin-packed vtgate processes more tightly for customers with autoscaling","ko":"자동 확장을 설정한 고객의 vtgate 프로세스를 평소보다 빽빽하게 배치해 CPU 용량에 더 가깝게 돌리면서, 미국 업무 시간 동안 쓸 용량을 넉넉히 확보했다."}},{"text":{"en":"Sent manual reparent requests to move primaries to healthier availability zones","ko":"가능한 곳에서는 손으로 reparent 요청을 보내 프라이머리 데이터베이스를 더 건강하다고 알려진 가용 영역이나 고객 애플리케이션과 같은 영역으로 옮겼다."}},{"text":{"en":"Restarted the edge load balancer and vtgate processes that did not recover after the partitions healed","ko":"네트워크 분할이 풀린 뒤 스스로 복구하지 못한 엣지 로드 밸런서와 vtgate 프로세스를 재시작해 서비스를 되살렸다."}}],"action_items":[{"text":{"en":"Understand and become resilient to the failure modes of SaaS dependencies for CI/CD, SSO, web application hosting and incident communication","ko":"CI/CD, SSO, 웹 애플리케이션 호스팅, 장애 공지에 쓰는 SaaS 의 장애 양상을 더 잘 이해하고, 그 장애에 버틸 수 있게 한다."}},{"text":{"en":"Investigate more ambitious ways to reduce runtime dependence on internal and AWS services","ko":"런타임에 내부 서비스와 AWS 서비스에 기대는 정도를 더 크게 줄이는 방법을 조사한다."}},{"text":{"en":"Look into using all six us-east-1 availability zones to tolerate zonal outages and partitions","ko":"AWS us-east-1 에 있는 가용 영역 여섯 개를 모두 더 잘 써서, 영역 장애와 영역 사이의 네트워크 분할에 더 잘 버티는 방법을 살핀다."}}],"contributing":[],"recurrence_of":null,"symptoms_text":{"en":"At 7:13 UTC on 20 October 2025, PlanetScale's continuous tests in production started failing because they could not create new database branches. The service that creates, resizes and configures database branches was unavailable, a near-total control plane outage, while existing database branches kept their capacity and connectivity.\n\nDuring the same phase the PlanetScale dashboard was available only on and off, customers who sign in with SSO could not log in unless they were already logged in, and PlanetScale could not post updates to its status site, which was itself down for at least half an hour.\n\nAt 10:05 UTC an alert showed a Kubernetes operator in a large single-tenant customer installation using up all its resources, which usually means rising latency or control plane requests failing and being retried. Responders found that new EC2 instances could not be launched in us-east-1, so requests to create or resize database branches stayed queued. With the US East Coast about to start its Monday, some of the largest customers, who autoscale the vtgate component of their Vitess clusters on a daily cycle, were heading into their weekly peak traffic with less than half the vtgate capacity of the week before.\n\nFrom about 14:30 UTC partial network partitions in us-east-1 made a significant share of some customers' queries fail. Some database servers were reachable from the Internet but could not talk across availability zones for query routing, replication or both. Some replicas started and reached container registries but could not replicate from their MySQL or Postgres primary. Some servers could not resolve internal DNS names, and others could not connect to the internal services those names resolved to.","ko":"7:13 UTC 에 프로덕션에서 계속 도는 PlanetScale 테스트가 실패하기 시작했다. 테스트는 새 데이터베이스 브랜치를 만들지 못하고 있었다. 데이터베이스 브랜치를 만들고 크기를 바꾸고 설정하는 서비스가 응답하지 않았다.\n\n거의 전면적인 컨트롤 플레인 장애였다. 고객 데이터베이스 브랜치는 이 동안 용량이나 연결을 잃지 않았다.\n\n같은 시기에 PlanetScale 대시보드는 됐다 안 됐다 했고, SSO 를 쓰는 고객은 이미 로그인한 상태가 아니면 로그인하지 못했다. https://planetscalestatus.com 에는 업데이트를 올릴 수 없었고, 이 사이트 자체도 적어도 30분 동안 열리지 않았다. 9:30 UTC 에 상위 서비스 제공자가 복구되자 컨트롤 플레인도 돌아왔다.\n\n10:05 UTC 에 한 고객의 대형 싱글 테넌트 환경에서 PlanetScale 의 Kubernetes operator 하나가 쓸 수 있는 자원을 모두 쓰고 있다는 알림이 왔다. 이 알림은 보통 지연이 늘었거나 컨트롤 플레인 요청이 실패해 재시도되고 있다는 뜻이다. 대응자들은 us-east-1 에서 새 EC2 인스턴스를 띄울 수 없다는 것을 곧 찾았다. 고객이 데이터베이스 브랜치를 만들거나 크기를 바꾸는 요청은 끝나지 않고 장애가 끝날 때까지 큐에 남았다. 기존 MySQL 과 Postgres 서버는 계속 동작했다.\n\n14:30 UTC 쯤부터 us-east-1 에서 부분적인 네트워크 분할이 보였다. 일부 데이터베이스 서버는 인터넷에서는 닿았지만 쿼리 라우팅이나 복제, 또는 둘 다를 위해 가용 영역 사이에서 통신하지 못했다. 일부 복제본은 시작할 때 컨테이너 레지스트리에는 닿았지만 MySQL 이나 Postgres 프라이머리에서 복제하지 못했다. 일부 서버는 내부 DNS 이름을 풀지 못했고, 다른 서버는 그 이름이 가리키는 내부 서비스에 연결하지 못했다.\n\n네트워크 분할 때문에 일부 고객은 쿼리의 상당한 비율이 실패했다. 영향은 어느 가용 영역을 쓰는지와 트래픽이 영역 사이를 오가는지에 크게 좌우돼, 모든 데이터베이스 브랜치가 영향을 받지는 않았다. 분할은 18:30 UTC 에서 19:30 UTC 사이에 조금씩 풀렸다.\n\n분할이 풀린 뒤에도 PlanetScale 의 엣지 로드 밸런서와 vtgate 프로세스 몇 개는 분할을 겪은 방식 때문에 스스로 복구하지 못했다."},"updated_at":"2026-11-14T12:34:02.097567Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0368","org_slug":"planetscale"}