AWS, 2025년 12월 중국 본토 리전 1곳 ‘비용 관리 단일 서비스’ 중단 놓고 AI 도구 연관성 공방…운영팀 점검 포인트
AWS가 2025년 12월(중순) 중국 본토 내 2개 리전 중 1곳에서 비용 관리(cost-management) 기능과 연관된 ‘단일 서비스’ 장애를 겪은 것으로 전해지면서, 내부 AI 코딩 도구를 포함한 자동화 변경의 운영 리스크가 다시 주목받고 있다. 이번 사안은 AWS 전반의 장애가 아니라 특정 리전·특정 기능 범위에 국한됐다는 설명이 함께 나왔다.
보도 흐름은 크게 두 갈래다. 첫째, 파이낸셜타임스(FT)는 당시 약 13시간 영향을 준 중단이 내부 AI 코딩 에이전트 ‘Kiro’가 작업 중인 환경을 삭제(delete) 후 재생성(recreate)하는 성격의 변경을 수행하는 과정과 맞물렸다고 전했다. 둘째, AWS는 로이터 등 질의에 대해 “비용 관리에 쓰이는 단일 서비스에서 발생한 매우 제한적인 사건”이라는 점을 강조하면서, 원인은 AI 자체라기보다 사용자·직원 측 접근통제/권한 설정이 잘못돼(예: 의도치 않은 권한 상승) 변경이 실행될 수 있었던 ‘권한 구성 문제’라는 취지로 반박했다.
참고로, 이번 건 외에도 2025년 말 별도의 내부 AI 도구(예: Amazon Q Developer)와 관련된 생산 환경 사고가 한 차례 더 언급됐다. 해당 사례는 고객 영향이 제한적이거나 없었던 것으로 전해지지만, “AI 도구 자체의 성능”과 “운영 권한·변경 통제의 설계”가 분리돼 관리돼야 한다는 문제의식은 공통으로 이어진다.
보스턴 지역의 스타트업·연구실·유학생 창업팀처럼 AWS 의존도가 높은 조직에서는, ‘AI가 원인이었는지’의 단정 여부보다 다음 질문이 더 실무적이다. (1) 변경 권한이 어떤 경로로 열렸는가 (2) 자동화/에이전트가 어디까지 실행할 수 있었는가 (3) 문제가 생겼을 때 30분 내에 어떤 순서로 멈추고 되돌릴 수 있는가.
예를 들어, 소규모 SaaS 팀이 월말 결산을 앞두고 Cost Explorer/예산 알림을 근거로 인프라 축소 결정을 내리려는 상황을 가정해보자. 비용 가시성이 몇 시간만 끊겨도 ‘지금 줄여야 할지, 유지해야 할지’ 의사결정이 지연될 수 있다. 이때 자동 스케일링, 예약 인스턴스/절감 플랜 구매, 배포 자동화 같은 실행 결정이 겹치면 비용과 성능 양쪽에서 손실 가능성이 커진다.
이번 논란을 계기로 운영팀이 바로 점검할 수 있는 항목은 다음과 같다.
- 권한(Privilege) 재점검
- AI 코딩/운영 도구가 쓰는 IAM Role을 사람 계정과 분리하고, 프로덕션에는 최소권한(least privilege)·세션 시간 제한을 기본값으로 두는 구성이 유리하다.
- 변경 승인 흐름의 ‘우회 경로’ 차단
- “2인 승인” 같은 원칙이 있어도, 긴급 핫픽스·임시 관리자 권한·자동 재시도 같은 예외 경로가 열려 있으면 실효성이 약해질 수 있다. 예외 경로 목록을 먼저 적고, 각 경로를 기술적으로 잠그는 순서가 현실적이다.
- 프로덕션 가드레일(파괴적 작업 제한)
- delete/recreate 등 파괴적 작업은 정책 레벨(SCP/권한 경계 등)에서 원천 차단하고, 불가피한 경우에도 별도 점검 계정/격리된 실행 환경에서만 가능하도록 나누는 접근이 흔히 쓰인다.
- 비용·장애 관측(Observability) 이중화
- 비용 알림을 콘솔의 단일 기능에만 의존하지 말고, 청구 데이터·태그·사용량 지표 기반의 보조 경로(로그/메트릭)로 ‘예산 초과 징후’를 감지할 수 있게 두는 편이 안전하다.
- ‘AI 도구 포함’ 사고 리허설
- 런북에 “자동화/에이전트가 잘못된 변경을 수행했을 가능성”을 명시하고, 권한 회수 → 변경 롤백 → 영향 범위 확인을 30분 내에 수행하는 역할 분담을 마련해 두면 초기 대응이 빨라질 수 있다.
정리하면, 이번 사안은 특정 리전·비용 관리 관련 단일 서비스에 한정됐다는 설명이 있는 반면, 자동화 변경이 ‘어떤 권한으로 어디까지 실행될 수 있었는지’에 대한 운영 설계의 중요성을 다시 드러냈다. AI 코딩/운영 도구를 이미 도입했거나 검토 중이라면, 기능 성능 평가와 별개로 “실행 경계(Guardrail)와 승인 체계”를 먼저 문서화하고 기술적으로 강제하는 편이 리스크 관리에 도움이 된다.