▲

us-east-1 지역에서 AWS의 여러 서비스 장애 발생

 (health.aws.amazon.com)
1P by GN⁺ 13일전 | ★ favorite | 댓글 1개
  • AWS의 us-east-1 리전에 있는 다양한 서비스에서 장애 발생
  • 이 장애로 인해 클라우드 인프라 이용 기업들이 서비스 중단 경험
  • API Gateway, Lambda 등 주요 서비스의 가용성 문제 보고
  • 엔지니어들은 우회 경로 마련 및 비상 대응책 검토 필요성 대두
  • AWS Health Dashboard를 통해 실시간 장애 정보 및 업데이트 제공

AWS us-east-1 지역 장애 개요

  • 2025년 10월 21일, AWS Health Dashboard에서 us-east-1 리전에 속한 여러 서비스에 장애가 발생함
  • 대표적으로 API Gateway, Lambda, S3 등 중요 서비스가 영향을 받아 다수 고객이 서비스 중단 경험을 함
  • 장애 발생 시점부터 AWS 측이 문제를 인지하고 원인 분석 및 복구 작업을 즉시 시작함
  • 해당 리전에 의존하는 SaaS, 스타트업, IT 기업에서 서비스 지연 및 다운타임 현상 보고됨
  • 엔지니어와 IT 관리자들은 비상 우회 경로 구축, 중요 서비스의 리전 다중화 전략 필요성 강조함

장애 영향 및 대응

  • us-east-1 리전은 글로벌 클라우드 인프라에서 가장 트래픽이 많은 지역 중 하나로, 장애 시 파급효과가 매우 큼
  • 실제로 다양한 고객사에서 서비스 제공 중단, API 응답 지연, 데이터 처리 장애 등 문제가 동시에 발생함
  • AWS는 Health Dashboard를 통해 실시간 상황을 알리고, 지원 문서 및 업데이트를 제공함
  • 고객사 IT팀은 장애 상황 모니터링, 임시 우회, 사용자 공지를 통해 피해 최소화 노력 실시함

엔지니어를 위한 시사점

  • 장애 발생 시 모니터링 시스템 및 장애 알림 체계 중요성 재확인 필요성 제기됨
  • 멀티 리전 배포, 자동화된 장애 조치, 백업 전략 등 resilient 아키텍처 설계의 가치가 부각됨
  • AWS Health Dashboard는 장애 상황에서 신속한 정보 확인과 의사결정 지원 도구로 활용됨

결론

  • 대규모 클라우드 서비스 사업자는 필수적으로 서비스 장애 가능성에 대한 대비책 마련이 필요함
  • 장애 발생 시 신속한 복구 과정과 투명한 커뮤니케이션, 그리고 효율적 인프라 장애 대응 역량의 중요성이 다시 한 번 부각됨
▲
GN⁺ 13일전  [-]
Hacker News 의견
  • 오늘은 정말 흥미로운 하루임. 새벽 3시부터 사고 대응 브릿지에 있었음. 시스템은 대부분 복구됐지만, 백오피스 쪽에서 아직 자원 부족으로 고전하는 부서가 있음. 우리 쪽에서 가장 크게 실수한 건, 멀티리전 동작이 가능하도록 설계를 해놓고도 페일오버 프로세스를 실행할 수 없었다는 점임. 그 이유는 보안팀이 우리를 Identity Center로 이전시켰는데, 이를 us-east-1에만 배치해 두어 회사 전체가 AWS 컨트롤 플레인에 완전히 잠김 상태였음. 루트 크리덴셜을 금고에서 꺼내왔을 때는 이미 시스템이 거의 복구되고 있었음. 이 일을 통해 약한 고리가 전체 강건함을 좌우함을 다시 한 번 상기하게 됨
    • 몇 년 전 구글 파리 데이터센터가 침수 후 화재로 난리였던 때가 떠오름. 우리가 거기에 컴퓨트 리소스를 직접 둔 건 아니었지만, AWS EU 데이터센터에서 컴퓨팅 중이었고, Google 서비스용 DNS 리졸버가 파리에 호스팅되어 있어서 접속 경로가 파리로 우선 라우팅됐었음. 임시해결책은 꽤 재밌었음. 그 때 쿠버네티스에 배포된 /etc/hosts 파일을 전역적으로 쉽게 수정할 수 있단 걸 처음 알았고, 실제로 그렇게 해야 할 만큼 절실했음. 평소라면 그런 용도로 /etc/hosts를 쓰진 않겠지만, 임시 패치로서는 딱 적당한 추상화였음
    • Facebook이 BGP 업데이트 실수로 금고 접근을 완전히 불가능하게 했던 비슷한 사례가 생각남. 인증 경로가 순환 구조라면 DNS가 한 번 깨졌을 때 아무 것도 할 수 없게 됨
    • 결국에는 누군가가 하드웨어 토큰을 들고 다른 데이터센터로 비행기를 타고 가서, 전 세계 시스템이 돌아가게 만드는 핵심 장치를 리셋해야 하는 순간이 옴
    • Identity Center를 us-east-1에만 둔다는 얘기가 나왔는데, 여러 리전에 둘 수 있는지 궁금함. 마지막으로 확인했을 때 한 리전에서만 사용할 수 있었고, 옮기려면 일단 삭제해야 했었음
    • 지나친 보안 장벽은 오히려 움직이지 못하게 만듦. 보안팀이 이번일에 대한 책임을 질 것인지 궁금함. 이 일로 인해 앞으로 모든 프로젝트가 느려질 것 같음. 보안팀이 지금까지 너무 과속 운전을 해온 것 같음. 감시자를 감시하는 이는 누구인지 의문임
  • 아직 주요 장애가 계속되고 있는 것 같음. 4시간 전보다 상태가 더 안 좋음. 나는 데이터 엔지니어이고, Redshift와 Airflow(AWS 관리 서비스)가 완전히 엉망임
    • 장애가 제법 오래 가고 있는데, 과연 몇 개의 9가 사라졌을지 궁금함. 365일 * 24시간 * 0.0001을 계산하면 약 8시간이고, 이미 99.99% 가용성을 잃은 셈임
    • 왜 많은 기업들이 여전히 us-east-1을 고집하는지 모르겠음. 장애 빈도로 따지면 압도적으로 최악임. 우리 회사는 예전에 us-east-1을 피하고 다른 리전만 쓰기로 결정했음. 물론, 서비스가 '글로벌'이라고 하면 실질적으로 us-east-1을 의미하는 경우가 많아 도움이 안 될 때도 있음
    • Lambda create-function의 컨트롤 플레인 작업이 아직도 InternalError로 실패하고 있음. 다른 서비스(Lambda, SNS, SQS, EFS, EBS, CloudFront)는 복구됨. 나는 클라우드 가용성 주제로 CS 석사 연구 중이라, 여러 AWS 테스트 계정에서 시험하며 장애 타임라인과 영향을 정리해 글로 남김. 분석 포스트
    • 다운 디텍터(Down Detector)에서는 AWS 장애가 계속 심각함을 보여주고 있음. Amazon 측에서는 ‘서비스가 복구 중’이라고 하지만, 실제로는 아마존닷컴에서도 상품 검색이 안 되고 있음. AWS 헬스 페이지
    • 다운디텍터 기준 12:52 AM 퍼시픽(3:53 동부)에 AWS 문제 신고가 5,755건이었는데, 4:22 AM 퍼시픽(7:22 동부)에는 1,190건으로 줄었다가, 9:32 AM 퍼시픽(12:32 동부)에 다시 9,230건으로 급증함. 미 서부지역이 깨어나면서 신고가 늘어난 것도 있겠지만, AWS가 아직 확실히 상황을 통제하지 못하는 듯함
  • 이번 장애가 내 일상에도 직접적으로 영향을 줌. 뉴욕 Hudson Yards Whole Foods에서 초콜릿 바를 사려는데 프라임 할인 적용이 안 됨. 그래서 안 샀고, 지금 초콜릿 수치가 아주 낮아짐
    • 오늘 아침에 "alexa 커피포트 켜줘"도 안 됨. 정신이 혼미해짐
    • 점심으로 핫바에서 음식을 담고 셀프 체크아웃을 시도했는데, 왜 Whole Foods 바코드가 작동하지 않는지 한참 생각했음. 20초쯤 지나서야 장애 때문이란 걸 깨달음
    • 재밌는 사례를 공유해줘서 좋음. 그런데 이 참에 AWS 장애 시 Amazon Go 매장에 있던 사람들은 어떻게 됐는지 궁금해짐
  • 오늘 AWS 계정 담당자와 미팅이 있음. 앞으로 “All in on AWS”에서 벗어나 워크로드를 분산하겠다는 기조를 설명할 예정임. 주요 이유는 코어 서비스의 혁신 속도가 느려지고, AI 서비스도 경쟁사에 비해 너무 뒤처졌기 때문임. AWS 팀은 항상 AWS의 극강 안정성을 이유로 클라우드 분산을 하지 말라고 주장함. 오늘 미팅이 기대됨
    • AWS, Cloudflare, Google Cloud, Akismet 등 어디든 한 번쯤은 장애를 겪게 됨. 그럴 때마다 인하우스 호스팅으로 갈지도 생각해보게 됨. 결국 환불 받고 다시 운영하게 됨. 결과는 비슷하니 굳이 더 고생할 필요 없다고 생각함
    • 지난번 실적 발표에서 Andy Jassy가 AWS가 혁신에서 뒤처진다는 지적을 받자, 내세운 건 안정성, 신뢰성, 내구성임. 하지만 지금 상황을 보면 이 변명이 통하지 않음
    • us-east-1을 제외하면 나머지 리전은 꽤 안정적으로 운영 중임. 우리 회사도 대부분 eu-west-1에만 올려두고 있는데, 별다른 사고 없이 잘 돌아가는 중임
    • AWS는 장기적으로 쇠퇴하는 중임. 지금은 그냥 기존 서비스 유지만 하고 있는 느낌임. 혁신적인 직원들이 내부 관료주의와 성과 압박에 짓눌리면서 AI 쪽에서도 뒤처지는 것임
    • AWS의 뛰어난 안정성 주장은 애초에 사실이 아니었음. 예전에 여러 클라우드와 전용 서버로 멀티클라우드 모니터링을 세팅한 적이 있었는데, 실제로 어디가 먼저 문제가 생기는지 생생하게 볼 수 있었음. 당시 결과를 보면 AWS가 늘 1등은 아니었음. netcraft.com의 데이터와 거의 일치했음
  • 오늘 프리미어리그도 VAR과 자동 오프사이드 판정 시스템이 AWS 장애 탓에 제한적으로만 운영될 예정임. 정말 기괴한 시대를 사는 중임 BBC 링크
    • 클라우드(장애)에 한 줌의 긍정적인 요소도 있음을 느끼게 됨
  • us-east-1을 주 리전으로 잡으면, 장애가 나면 모두 동시에 불통이니 혼자만 고생하는 일은 없음. 다른 미국 리전에서는 이런 특권을 누릴 수 없음
    • 기존 데이터센터에서 AWS로 옮겼을 때 예상치 못한 장점 중 하나는, 리전 전체가 다운되면 고객들이 훨씬 더 이해심이 늘어난다는 점임. 모두 동시에 불편하니 그냥 그러려니 넘어감
    • 가끔은 모두가 기술 다운타임을 한 번쯤 경험할 필요가 있음
    • 좋아, 우리 모두 US-East-1에 인프라를 올리자
    • 기업 환경에서 진짜로 중요한 게 뭔지 깨닫는 데 꽤 오래 걸림. 실제로는 가용성보다는 남 탓 할 수 있는 구조가 더 중요함. 직원 실수로 1년에 5분 다운되면 CTO 책임이고, AWS 장애로 5시간 다운되면 그냥 모두가 불편하니 '어쩔 수 없는 일' 취급임. AWS, Crowdstrike 등 결국 시스템 탄탄함이나 가성비, 위험 관리가 아니라, 남들도 같이 고생하는 시기가 더 중요함. 불편하지만 현실임. 기술 잘 굴러가는 걸 좋아하는 사람 입장에서는 화가 남
    • 도쿄 리전은 지금 잘 돌아감! 다만 콘솔 로그인 등 일부 기능에는 아직 문제가 있음
  • "조사 결과, US-EAST-1의 DynamoDB API 엔드포인트의 DNS 해석 문제와 관련 있어 보임. 우리는 복구를 가속화하기 위해 병렬 경로로 작업 중임"이라는 공지가 있었음. 역시 원인은 늘 DNS임
    • 이번 장애가 진짜 DNS 해석 문제인지, DNS 서버의 내부 설정/데이터 저장소 문제인지도 궁금함. 후자일 듯
    • 나중에 장애 공지에는 네트워크 로드 밸런서 실패가 원인이라고 나와 있음. DNS는 뿌리 원인의 '증상'임. DNS가 헬스체크를 망치긴 했을 수도 있겠지만, 내 생각엔 주 원인이 네트워크 쪽임
    • BGP가 DNS 문제로 위장한 것일 수도 있음
    • 원인은 언제나 us-east-1임
    • DNS가 아니어도 결국은 DNS임
  • 회복력을 염두에 두고 설계한 대로 작동함. CloudFront로 멀티 리전에 static 사이트 오리진을 두었고, 이번 장애에 영향이 없음. 컨트롤 플레인도 네이티브 멀티리전 구조라서 여러 서비스에 의존하지만 가용성은 유지됨. 각 리전이 독립적으로 동작하고, 데이터 복제는 하되 us-east-1 복제가 안 돼도 영향이 없음. 서비스 자체가 멀티리전 구조에다 페일오버를 여러 계층(DNS, 라우팅, 목적지 선택)에서 처리함. 물론 이 방식도 완벽하진 않고 실패 요인은 많지만, 이번엔 잘 돌아가서 뿌듯함. 내가 한 일은 결코 로켓 공학도 아니고 비싸지도 않지만, 관행과는 좀 다른 방법임. 궁금한 점 있으면 언제든 질문 바람
    • CloudFront로 멀티리전 static 오리진을 둬서 장애를 피했다니, 2025년엔 기본이 되어야 할 것 같은데, 아직도 이게 칭찬거리가 됨
    • active/active 구조인지, 그리고 데이터 스택이 어떻게 돼 있는지 궁금함. 이 부분이 특히 어렵다고 생각함
    • 키와 인증서를 위한 내결함 인증은 어떻게 구현했는지 궁금함
  • 한 가지 큰 문제는 IAM/인증 쪽 시스템이 과부하 또는 다운됨에 따라 연쇄적인 장애가 발생했다는 점임. DynamoDB가 원인이라는 말이 있는데, IAM도 내부적으로 Dynamo에 의존하는지 궁금함. 워낙 복잡한 대규모 시스템에서 여러 종속성이 꼬여있는데, Auth/IAM은 글로벌 단일 접점이 될 위험이 있으니 종속성을 최소화하고 싶음. 하지만 확장성, 일관성 등도 중요하니 검증된 DB를 활용하게 됨. 결국 종속성이 복잡해져서, 시스템이 다운될 때 복잡한 부트스트랩 과정을 거쳐야 하지 않나 하는 생각임. 어떻게 처리하는지 궁금함
    • 약 2017년쯤 DynamoDB 장애로 대규모 장애가 있었음. EC2가 서버 리스트를 DynamoDB에 저장했는데, DynamoDB가 다운되니 EC2도 다운됨. DynamoDB가 EC2 위에서 돌아가다 보니, EC2 인스턴스를 새로 띄워서 복구도 불가능했음. 그래서 몇 일을 수작업으로 인스턴스를 띄우며 회복해야 했음. 이 이후로 S3, DynamoDB, EC2 등 1티어 시스템 간 종속성을 최대한 분리하는 쪽으로 노력해 왔음. 물론 완전무결하긴 어려움
    • 많은 AWS 고객들이 잘못된 재시도 정책 때문에, 한쪽 시스템 장애 시 다른 쪽까지 과부하시키는 경우가 많음. DynamoDB 장애가 IAM까지 과부하로 이어짐
    • Amazon 내부적으로는 Dynamo라는 KV스토어 플랫폼이 따로 존재하는데, DynamoDB와는 다름. 그래서 장애 원인이 DNS 라우팅이나 노드 배포 문제일 수도 있음. 이런 이슈는 대형 장애의 포스트모템에서 반복해서 나타남
    • AWS에서 근무할 때는 IAM이 Dynamo에 의존하지 않았음. 지금은 바뀌었을지 모르나 확신은 없음. 대규모 네트워크 이슈로 인한 영향일 가능성이 더 높아 보임. Auth/IAM이 글로벌 단일 접점이 되면 안 되기 때문에 종속성을 최소화하려는 구조임. IAM은 각 리전마다 자체 읽기 전용 캐시가 있고, AWS SigV4도 리전별 작동을 염두에 둔 설계임. (참고 문서)
    • 최근 GCP 장애 원인도 이와 같은 문제임이 흥미로움
  • 3:03AM PT에 AWS가 복구 중이라고 공지했음. 그런데 상황이 오히려 악화됨. 9:13AM PT에는 다시 원인 분석 중이라고 함. AWS도 정확한 원인을 모르는 것 같아 불안함
    • 이번 일은 디왈리(인도 최대 명절) 주간이라 인도 엔지니어들이 휴가 중인 것도 영향을 준 듯함. 정말 운이 없음
답변달기