45만 달러 AWS 비용 알림이 왔다 — 빌링 오류보다 아쉬웠던 대응

시작은 메일 한 통이었다. AWS Cost Management가 한 고객 계정에서 평소보다 높은 비용을 탐지했다는 알림이었다. 원인 후보는 서울 리전의 Amazon S3, 사용 유형은 APN2-DataTransfer-Out-Bytes. 하루 최대 비용 영향은 $455,441.87로 표시됐다.

숫자를 보는 순간 여러 생각이 겹쳤다. 그래도 첫 판단은 단순했다. 오류라고 확인되기 전까지는 사고로 다룬다.

45만 달러를 보고 가장 먼저 의심한 것은 계정 침해였다

해당 계정에는 이 정도 S3 외부 전송이 발생할 워크로드가 없었다. 서비스 변화나 대규모 데이터 이관 일정도 없었다. 비용이 낯선 이유가 설명되지 않으면 자격증명 탈취, 버킷 정책 변경, 비정상 객체 요청부터 의심해야 한다.

더 조심스러웠던 이유는 고객이 소유한 계정이었기 때문이다. 휴일이었지만 양측 담당자가 연락해 각자의 범위를 나눠 확인했다. 우리는 비용 항목과 운영 로그를 보고, 고객은 계정 접근과 최근 변경 사항을 점검했다. 익숙하지 않은 숫자라는 이유만으로 오탐이라고 넘길 수 없었다.

이런 상황에서는 비용 화면 하나만 반복해서 보는 것으로 충분하지 않다.

1. AWS Health와 Support 공지를 확인한다. 같은 시간대의 서비스 공통 이슈인지 먼저 분리한다.
2. 비용 항목을 실제 사용 증거와 대조한다. 서비스, 리전, 사용 유형을 좁히고 S3 요청 로그, CloudTrail 데이터 이벤트, 네트워크 전송 지표가 같은 증가를 말하는지 본다.¹
3. 자격증명과 정책 변경을 확인한다. 새 IAM 사용자·역할·액세스 키, 버킷 정책과 공개 설정, 평소와 다른 소스 IP를 찾는다. 침해 정황이 있으면 분석보다 자격증명 차단을 앞세운다.²
4. 계정 소유자와 판단 기록을 공유한다. 고객 계정에서는 기술 점검만큼 연락 경로와 의사결정 주체가 중요하다.

점검에서는 45만 달러에 해당하는 실제 S3 전송이나 침해 흔적을 찾지 못했다. AWS Support에 문의하려고 들어간 화면에서야 퍼즐의 다른 조각이 보였다.

계정 문제가 아니라 AWS 빌링 시스템의 추정치 오류였다.

우리에게는 45만 달러, 다른 계정에는 4천억 달러가 넘었다

이 오류는 한 계정에 국한되지 않았다. 소셜 미디어에는 평소 몇 센트나 몇 달러를 쓰던 계정에 수십억·수천억 달러가 표시됐다는 화면이 잇따라 올라왔다. 첨부받은 일본어 콘솔 화면에는 월 누적 비용이 약 $419.1 billion, 월말 예상 비용이 약 $465.5 billion으로 표시돼 있었다.

보도된 사례는 더 컸다. 평소 한 달 비용이 1파운드도 안 되던 영국 자선단체의 앱에 58억 파운드가 표시됐고, 공개된 사례 중에는 1.5조 달러까지 있었다.³ 숫자가 비현실적으로 클수록 오류를 의심하기 쉽다. 하지만 수십만 달러처럼 실제 침해나 설정 실수로도 가능한 범위라면 운영자는 훨씬 오래 판단해야 한다.

AWS는 Health Dashboard에서 잘못된 추정 비용 데이터가 7월 16일 오후 7시 38분(PDT)부터 표시됐다고 밝혔다. 이후 직접 원인을 추정 청구 계산 서브시스템의 단가(unit pricing) 문제로 좁혔고, 잘못 계산된 데이터를 수정하기 위해 백필을 진행했다.⁴ 실제 사용량과 확정 청구를 반영한 금액은 아니었으며 고객이 취할 조치도 없다고 안내했다.

여기까지는 큰 오류를 발견하고 복구하는 과정이다. 더 아쉬운 장면은 공식 소셜 채널에서 나왔다.

보안 사고로 받아들인 고객에게 “그 돈으로 뭘 할 건가”라고 물었다

AWS 공식 X 계정의 첫 반응은 사과보다 농담에 가까웠다. 일부 고객에게 수천조 달러 규모의 추정치가 보였다며 이를 “정말 약간의 계산 오류”라고 표현했고, 그 돈으로 무엇을 할 것인지 물었다.

이 문구가 왜 문제였는지는 우리가 보낸 몇 시간을 떠올리면 분명하다. 비용 알림을 받은 담당자는 웃기 전에 계정이 털렸는지 확인한다. 고객 계정이면 휴일에도 연락망을 열고, 누가 무엇을 바꿨는지 묻고, 서비스와 데이터의 안전을 점검한다. 수천억 달러를 실제로 낼 수 있는지가 핵심이 아니다. 그 숫자가 나타난 동안 고객 조직이 사고 대응 비용을 이미 지불했다.

AWS Japan 직원으로 소개된 계정도 공개적으로 문제를 제기하고 내부 에스컬레이션 의사를 밝혔다. 여러 AWS 사용자도 같은 지점을 비판했다. 회사 공식 계정의 유머는 고객과 문제의 맥락을 공유할 때만 작동한다. 이 상황에서는 AWS는 이미 오류임을 알았지만, 많은 고객은 아직 자신의 계정이 안전한지 몰랐다.

AWS는 이후 건조한 문장으로 문제 해결과 재발 방지 업데이트를 알리고, 예상 밖의 큰 금액을 본 고객에게 사과했다.

공개된 원인과 공개되지 않은 원인을 구분해야 한다

현재 AWS가 공개한 직접 원인은 단가 데이터가 추정 청구 계산에 잘못 반영된 문제다. 그러나 어떤 변경이 잘못된 단가를 넣었는지, 검증과 배포 통제가 왜 막지 못했는지, Cost Anomaly Detection까지 같은 잘못된 데이터를 고객에게 전파한 경로는 상세히 공개되지 않았다.

커뮤니티에서는 AI 코드 어시스턴트를 통제 없이 사용한 결과가 아니냐는 추측도 나왔다. 하지만 이를 뒷받침하는 AWS의 발표나 검증 가능한 증거는 없다. AI가 원인이었다고 쓰는 순간, 이번 사건에서 비판해야 할 검증·격리·커뮤니케이션 통제의 실패를 근거 없는 도구 탓으로 바꾸게 된다. 포스트모템이 나오기 전에는 추측으로 남겨야 한다.

오히려 확인된 구조적 질문이 더 중요하다.

• 추정 비용을 만드는 단가 변경에는 어떤 범위 검증과 상한 검사가 있었는가.
• 청구 추정치와 Cost Anomaly Detection이 같은 오류 영역을 공유할 때 독립 검증 수단은 무엇인가.
• 서비스 상태 공지가 비용 이상 메일보다 늦게 도착하면 고객은 어디에서 공통 장애를 확인해야 하는가.
• “실제 사용량과 청구가 아니다”라는 가장 중요한 문장을 모든 알림 채널에 얼마나 빨리 배포했는가.

하루 전 CloudFront 장애까지 겹치며 신뢰의 문제로 남았다

빌링 오류 바로 전날인 7월 16일에는 CloudFront VPC Origins를 사용하는 고객이 5xx 오류를 겪었다. 공개된 장애 요약에 따르면 라우팅 설정을 네트워크 프로세서에 배포하는 시스템이 갱신된 설정을 제대로 읽지 못하면서 VPC Origin 연결에 영향을 줬다.⁵ 실제 서비스 가용성 장애와 비용 데이터 오류가 짧은 간격으로 이어졌다.

두 사건의 기술 원인이 같다는 증거는 없다. 하나로 묶어 품질 전체를 단정할 일도 아니다. 다만 고객 입장에서는 연속된 경험이다. 전날에는 채택한 네트워크 기능 때문에 서비스가 멈췄고, 다음 날에는 존재하지 않는 거액의 비용을 보고 계정 침해를 의심했다. 이때 공식 채널의 첫 반응까지 가벼우면 개별 버그는 신뢰의 문제로 바뀐다.

글로벌 클라우드 사업자의 사고 대응은 복구 속도만으로 끝나지 않는다. 고객이 불확실성을 얼마나 오래 떠안았는지, 그동안 어떤 불필요한 조치를 했는지, 같은 일이 다시 생겼을 때 무엇을 믿어야 하는지도 설명해야 한다.

다음 비용 이상 알림에는 세 개의 독립된 신호가 필요하다

이번 경험 뒤에 남은 운영 원칙은 간단하다.

여기에 AWS Health 알림을 이메일·채팅·모바일 푸시로 연결하고, 조직 단위 이벤트를 모아 볼 수 있게 해야 한다.⁶ 다만 Public service event는 관리형 알림의 대상이 아니므로 Health Dashboard를 함께 확인하는 절차가 필요하다. 공급자 공지가 늦을 때를 대비해 고객 연락망과 의사결정 책임자도 런북에 넣어야 한다.

비용 알림은 숫자만 전달하는 기능이 아니다. 누군가 계정을 탈취했거나, 자동화가 폭주했거나, 공급자의 계산 계층이 잘못됐다는 신호다. 어느 경우든 고객은 움직인다. 그래서 이 채널의 정확성과 말투는 청구팀만의 문제가 아니라 보안과 운영 신뢰의 일부다.

계정 침해 대응, 비용 이상 탐지와 AWS Health 알림을 하나의 런북으로 묶는 일은 클라우드 & 인프라에서 함께 설계할 수 있다.

참고 자료

사건 시각과 원인 설명은 2026년 7월 19일 기준 공개된 AWS Health 안내와 보도를 확인했다. AWS가 상세 포스트모템을 발표하면 기술적 원인 범위는 달라질 수 있다.