{"id":"IL-0409","org":"AssemblyAI","date":"2026-01-29","docs":[],"title":{"en":"AssemblyAI's async and LLM Gateway APIs returned 5xx after its auth service could not get ENIs and scaled to zero","ko":"배치 작업이 몰려 AWS ENI 한도가 바닥나고 인증 서비스의 태스크가 0개로 줄어 AssemblyAI 의 Async API 와 LLM Gateway 가 25분 멈췄다"},"domain":["aws","ai-infra"],"impact":{"scope":"Async Transcription API and LLM Gateway down for 25 minutes, then two hours of degraded performance with elevated turnaround times; website down and logins affected during recovery","users":"unknown","region":"NA API endpoints; streaming API and EU endpoint not affected"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"AssemblyAI calls the outage preventable: ENI utilisation was not monitored, and because the authentication service shared resources with batch workers, a traffic spike in one starved the other. The warning signs were there but were not connected, and a tool built for recovery ended up blocking recovery.","ko":"AssemblyAI 는 ENI 사용률을 모니터링하지 않은 것과, 인증 서비스가 배치 워커와 자원을 함께 쓴 것을 실제 잘못으로 꼽았다. 한쪽에 몰린 트래픽이 다른 쪽이 쓸 자원을 빼앗았다. 장애 대응을 돕도록 만든 Lambda 함수가 오히려 복구를 막았다. AssemblyAI 는 이 장애를 막을 수 있었고, 경고 신호가 있었지만 그 신호들을 함께 놓고 보지 못했다고 밝혔다."},"related":[],"sources":[{"url":"https://status.assemblyai.com/incidents/cshs4z0mkvr7","kind":"official-status","archived":"https://web.archive.org/web/20260513005058/https://status.assemblyai.com/incidents/cshs4z0mkvr7"}],"summary":{"en":"AssemblyAI's traffic had been growing steadily when an influx of batch transcription jobs, larger than usual, arrived. Autoscaling added workers as intended: it ran out of spot instances, fell back to on-demand instances and then hit the AWS Elastic Network Interface (ENI) limit. Every ECS task needs an ENI. With no ENIs left, the authentication service, which shared resources with the batch workers, could not rotate its tasks and scaled to zero, and the Async Transcription API and LLM Gateway stopped. While the team tried to recover, a Lambda function built to help with failures flooded the AWS API with describe calls and got the operations needed for recovery rate-limited. After 25 minutes of outage and two hours of degraded performance, the backlog was cleared and turnaround times returned to normal. AssemblyAI says it did not monitor ENI utilisation, that the traffic spike on the batch side starved the authentication service through the shared resources, and that it had warning signs it did not connect.","ko":"AssemblyAI 의 트래픽은 꾸준히 늘고 있었고, 2026년 1월 29일에는 평소보다 많은 배치 전사 작업이 한꺼번에 들어왔다. 오토스케일링은 워커를 늘렸다. spot 인스턴스가 바닥나 on-demand 로 넘어갔고, 그다음 AWS 의 Elastic Network Interface 한도에 걸렸다. ECS 태스크는 저마다 ENI 가 하나씩 필요하다. 남은 ENI 가 없자 배치 워커와 자원을 함께 쓰던 인증 서비스가 태스크를 교체하지 못했고, 인증 서비스의 태스크가 0개로 줄면서 모든 것이 멈췄다. Async Transcription API 와 LLM Gateway 는 25분 동안 멈췄다.\n\nAssemblyAI 가 복구하려 할 때는 장애 대응을 돕도록 만든 Lambda 함수가 AWS API 에 describe 호출을 마구 보내 rate limit 을 일으켰고, 서비스를 되살리는 데 필요한 작업까지 막았다. 서비스가 돌아온 뒤에도 쌓인 요청을 처리하느라 두 시간 동안 처리 완료 시간이 길어졌고, 19:32 UTC 에 쌓인 요청을 다 처리하고 정상으로 돌아왔다. AssemblyAI 는 ENI 사용률을 모니터링하지 않았고, 인증 서비스가 배치 워커와 자원을 함께 써서 한쪽의 트래픽 급증이 다른 쪽의 자원을 빼앗았다고 밝혔다."},"trigger":{"en":"An influx of batch transcription jobs higher than usual made autoscaling add workers until spot instances ran out, on-demand instances were used, and the AWS Elastic Network Interface limit was reached.","ko":"평소보다 많은 배치 전사 작업이 한꺼번에 들어왔다. 오토스케일링이 워커를 늘리다가 spot 인스턴스가 바닥나 on-demand 로 넘어갔고, 그다음 AWS 의 Elastic Network Interface 한도에 걸렸다."},"severity":"unknown","symptoms":["service-unavailable","high-error-rate","high-latency","cloud-api-rate-limited"],"timeline":{"detected_after":null,"resolved_after":"2h 25m"},"date_kind":"incident","detection":null,"components":["ecs"],"root_cause":"capacity","remediation":[{"text":{"en":"Worked through the backlog of requests until turnaround times were back to normal","ko":"쌓인 요청을 모두 처리했고, 처리 완료 시간이 정상으로 돌아왔다."}}],"action_items":[{"text":{"en":"Add alerts on ENI utilisation","ko":"ENI 사용률에 알림을 건다."}},{"text":{"en":"Run the authentication service on dedicated capacity, separate from batch workers","ko":"인증 서비스를 전용 자원으로 떼어 낸다."}},{"text":{"en":"Fix the Lambda function that rate-limited the AWS API during recovery","ko":"AWS API 를 마구 호출한 Lambda 함수를 고친다."}},{"text":{"en":"Run everything in multiple regions","ko":"중기적으로 모든 서비스를 완전한 다중 지역 구성으로 옮긴다."}}],"contributing":["blast-radius-too-wide","monitoring-blind-spot","automation-amplified","early-signal-ignored"],"recurrence_of":null,"symptoms_text":{"en":"On 29 January 2026 AssemblyAI's Async Transcription API and LLM Gateway on the NA API endpoints went down for 25 minutes, returning 500 errors, and then ran degraded for two hours. The status page first reported the investigation at 17:54 UTC.\n\nAs requests began to complete again, some still returned 500 errors, the website was down and logins could be affected. Completed requests had elevated turnaround times while a backlog of requests was worked off, and turnaround times were back to normal by 19:32 UTC. An update at 18:09 UTC said the streaming API and the EU endpoint were running normally.\n\nRecovery was held back by a Lambda function meant to help with failures: it sent so many describe calls to the AWS API that the API rate-limited the very operations AssemblyAI needed to bring the services back.","ko":"2026년 1월 29일 AssemblyAI 의 Async Transcription API 와 LLM Gateway 가 500 오류를 내며 25분 동안 멈췄다. 상태 페이지에는 17:54 UTC 에 첫 공지가 올라왔다.\n\n영향은 NA API 엔드포인트의 async 와 LLM gateway 에 한정됐고, streaming API 와 EU 엔드포인트는 정상이었다. 18:29 UTC 부터 요청이 다시 성공하기 시작했지만 일부는 여전히 500 오류를 냈다. 18:30 UTC 에는 웹사이트가 내려가 있었고 로그인도 영향을 받을 수 있었다.\n\n서비스가 돌아온 뒤에도 두 시간 동안 성능이 떨어졌다. 쌓인 요청을 처리하는 동안 처리 완료 시간이 길어졌고, 19:32 UTC 에 쌓인 요청을 다 처리하고 완료 시간이 정상으로 돌아왔다.\n\nAssemblyAI 가 복구하려 할 때, 장애 대응을 돕도록 만든 Lambda 함수가 AWS API 에 describe 호출을 마구 보내고 있었다. 이 호출 때문에 rate limit 이 걸려, 서비스를 되살리는 데 필요한 작업이 막혔다."},"updated_at":"2026-11-14T12:34:05.975938Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0409","org_slug":"assemblyai"}