{"id":"IL-0151","org":"Amazon Web Services","date":"2023-06-13","docs":[],"title":{"en":"A latent defect in the AWS Lambda Frontend, set off when one us-east-1 cell scaled past a size never reached before, raised errors for Lambda and for services that depend on it, including new EKS cluster provisioning","ko":"us-east-1 의 Lambda 셀 하나가 처음 겪는 규모로 커지며 잠재 결함이 드러나 Lambda 호출이 실패했고, Lambda 에 기대는 EKS 의 새 클러스터 생성도 오류와 지연을 겪었다."},"domain":["aws","kubernetes"],"impact":{"scope":"Lambda invocations in one us-east-1 cell and the services that depend on them: STS, AWS Sign-in SAML federation, the Management Console, EKS new cluster provisioning, Connect, EventBridge and Support Center","users":"unknown","region":"us-east-1"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"A fleet that scales automatically can grow into a size that was never tested, and a defect that only appears at that size stays hidden until ordinary daily growth reaches it. AWS's answer is to cap every cell at a well-tested size.\n\nFor EKS users, the event shows that provisioning new clusters in us-east-1 depended on Lambda, while clusters that were already running were not affected.","ko":"셀 구조여도 셀 하나가 한 번도 겪지 않은 크기로 커지면 잠재 결함이 드러날 수 있다. 이번 장애로 Lambda Frontend 를 확장할 때 셀 구조에 빈틈이 있다는 것이 드러났다. Lambda 함수 호출에 기대는 STS, 콘솔, EKS 같은 서비스도 함께 오류와 지연이 늘었다. EKS 에서는 새 클러스터 생성만 실패했고 이미 돌던 클러스터는 영향이 없었다."},"related":[],"sources":[{"url":"https://aws.amazon.com/message/061323/","kind":"official-status","license":"unknown","archived":null}],"summary":{"en":"AWS Lambda is built from cells. In each cell the Lambda Frontend receives and routes invocations, and the Lambda Invocation Manager manages the compute capacity, called execution environments, that runs customer code. From 10:01 AM PDT on 13 June 2023 the Frontend fleet in us-east-1 scaled out for normal daily traffic. At 11:49 AM one cell grew past a capacity threshold no single cell had reached before, which set off a latent software defect: execution environments were allocated for incoming requests but never fully used by the Frontend. Lambda could not provision new execution environments, so invocations in that cell failed or slowed down. Invocations in other cells were not affected.\n\nEngineers identified the defect by 12:26 PM. Having confirmed that traffic had subsided, they scaled the Frontend fleet down to a size that no longer triggered it. New invocations began to recover at 1:30 PM and synchronous invocations were fully recovered at 1:45 PM, when most dependent services, including EKS cluster provisioning, recovered too. Lambda then worked through the backlog of asynchronous events according to each event source's retry policy, and by 3:37 PM Lambda and all dependent services were operating normally.\n\nAWS disabled the Frontend scaling activity that set off the event, fixed the latent bug and deployed the fix to all Regions. The event also exposed a gap in Lambda's cellular architecture for scaling the Frontend, which let a latent bug cause impact as a cell grew.","ko":"AWS Lambda 는 리전의 용량을 셀이라는 독립된 단위로 나누는 셀 구조를 쓴다. 셀마다 Lambda Frontend 와 Lambda Invocation Manager 가 있다. Lambda Frontend 는 함수 호출을 받아 라우팅하고, Lambda Invocation Manager 는 함수와 계정별 트래픽 규모에 맞춰 컴퓨트 용량을 Lambda Execution Environment 형태로 관리한다.\n\n2023년 6월 13일 10:01 AM PDT 에 us-east-1 에서 트래픽이 평소 하루 패턴 범위 안에서 늘어 Lambda Frontend 플릿이 확장하기 시작했다. 11:49 AM 에 셀 하나가 이전에 도달한 적 없는 용량 임계를 넘으면서 잠재된 소프트웨어 결함이 드러났다. Execution Environment 는 들어온 요청에 맞게 할당됐지만 Lambda Frontend 가 이를 끝내 쓰지 못했다. 새 Execution Environment 를 공급하지 못하자 그 셀의 함수 호출에서 오류율과 지연이 늘었다. 다른 셀의 호출은 영향이 없었다.\n\nLambda 를 쓰는 STS, AWS Sign-in, Management Console, EKS, Connect, EventBridge, Support Center 가 함께 영향을 받았다. EKS 는 새 클러스터 생성에서 오류율과 지연이 늘었고 기존 클러스터는 영향이 없었다. EKS 오류율은 1:45 PM 에 Lambda 호출 문제가 풀리면서 정상으로 돌아왔다.\n\n엔지니어들은 12:26 PM 에 결함과 그 결함이 컴퓨트 용량 공급에 준 영향을 찾았다. 트래픽이 줄어든 것을 확인하고 Lambda Frontend 플릿을 결함이 나타나지 않는 규모로 줄였다. 1:30 PM 에 새 호출이 회복하기 시작했고 1:45 PM 에 동기 호출이 완전히 회복했다. 3:37 PM 까지 비동기 이벤트 백로그를 처리했고 모든 서비스가 정상으로 돌아왔다."},"trigger":{"en":"At 11:49 AM PDT, while adding capacity for normal daily traffic growth, the Lambda Frontend fleet in one cell crossed a capacity threshold that no single cell had reached before.","ko":"트래픽이 평소 하루 패턴 범위 안에서 늘어 10:01 AM 부터 Lambda Frontend 플릿이 확장했고, 11:49 AM 에 셀 하나가 한 번도 도달한 적 없는 용량 임계를 넘었다."},"severity":"unknown","symptoms":["high-error-rate","high-latency","credentials-unavailable"],"timeline":{"detected_after":null,"resolved_after":"3h 48m"},"date_kind":"incident","detection":{"en":"Engineering teams were engaged immediately and began investigating; by 12:26 PM PDT they had identified the latent defect and its effect on provisioning compute capacity.","ko":"엔지니어링 팀이 곧바로 투입돼 조사를 시작했고, 12:26 PM 에 잠재 결함과 그 결함이 컴퓨트 용량 공급에 준 영향을 찾았다."},"components":["serverless-functions"],"root_cause":"software-bug","remediation":[{"text":{"en":"scaled the Lambda Frontend fleet down to a size that no longer triggered the latent defect","ko":"트래픽이 줄어든 것을 확인하고 Lambda Frontend 플릿을 결함이 나타나지 않는 규모로 줄였다."}}],"action_items":[{"text":{"en":"Disable the Lambda Frontend scaling activities that triggered the event","ko":"장애를 일으킨 Lambda Frontend 플릿의 확장 작업을 곧바로 막았다."}},{"text":{"en":"Fix the latent bug and deploy the fix to all Regions","ko":"잠재 결함을 고쳐 모든 리전에 배포했다."}},{"text":{"en":"Complete action items addressing the immediate concern with cellular scaling","ko":"셀 확장에서 드러난 시급한 문제에 대응하는 여러 조치를 마쳤다."}},{"text":{"en":"Bound all cells to a well-tested size to avoid unexpected scaling issues","ko":"모든 셀을 충분히 시험한 크기 안에 묶어 예상하지 못한 확장 문제를 막는 더 큰 작업을 2023년 안에 마친다."}}],"contributing":["limit-unknown"],"recurrence_of":null,"symptoms_text":{"en":"From 11:49 AM PDT on 13 June 2023, Lambda function invocations in the Northern Virginia (us-east-1) Region returned more errors and took longer. Customers that triggered functions from asynchronous or streaming event sources saw their event backlogs grow because the events were not being processed.\n\nServices that depend on Lambda were affected too. Amazon EKS had higher error rates and latency when provisioning new clusters, while existing EKS clusters were not affected. Amazon STS had elevated error rates in three separate periods between 11:49 AM and 2:10 PM, and SAML federation through AWS Sign-in failed more often between 1:13 PM and 2:11 PM, when throttles were put on STS; existing IAM sessions kept working. EventBridge deliveries to Lambda were delayed by up to 801 seconds.\n\nThe AWS Management Console for us-east-1 showed either 'AWS Management Console is currently unavailable' or a '504 Time-out' error page between 11:48 AM and 2:02 PM. Amazon Connect calls failed to connect and chats and tasks failed to start, and AWS Support Center call and chat were unavailable until dependent services recovered.","ko":"2023년 6월 13일 11:49 AM PDT 부터 us-east-1 리전에서 Lambda 함수 호출의 오류율과 지연이 늘었다. Amazon EKS 에서는 새 클러스터를 만들 때 오류율과 지연이 늘었고, 기존 EKS 클러스터는 영향을 받지 않았다.\n\n영향은 Lambda 에 기대는 다른 서비스로 번졌다. STS 는 11:49 AM 부터 2:10 PM 사이 세 차례 오류율이 올라갔다. STS 에 스로틀을 걸자 1:13 PM 부터 2:11 PM 사이 AWS Sign-in 의 SAML 페더레이션 오류가 늘었고, 기존 IAM 세션은 영향이 없었다. EventBridge 에서는 Lambda 로 보내는 이벤트의 전달 지연이 최대 801초까지 늘었다.\n\nus-east-1 의 Management Console 은 11:48 AM 부터 2:02 PM 사이 'AWS Management Console is currently unavailable' 또는 '504 Time-out' 오류 페이지를 보였다. Amazon Connect 에서는 통화가 연결되지 않고 채팅과 작업이 시작되지 않았으며 상담원 로그인에 문제가 생겼다. AWS Support Center 에서는 처음 11분 동안 지원 케이스를 만들거나 보거나 고치는 요청이 실패할 수 있었고, 전화와 채팅 지원은 2:38 PM 까지 쓸 수 없었다.\n\n비동기나 스트리밍 이벤트 소스로 Lambda 를 호출하는 고객은 이벤트가 처리되지 않아 백로그가 쌓였다."},"updated_at":"2026-11-10T00:00:36.274997Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0151","org_slug":"amazon-web-services"}