AWS 예상 청구액이 17억 달러로 표시됨, 평소 사용료는 5달러 미만

 (news.ycombinator.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 평소 사용료가 5달러 미만인 AWS 계정에 이번 달 예상 청구액이 17억 달러로 표시됨
  • 실제 사용량과 청구액의 차이가 지나치게 커 예상 청구 데이터가 부정확한 상황으로 보고 있음
  • 게시자는 문제를 확인하고 대응하기 위해 긴급 AWS 지원 티켓을 생성함
  • AWS 서비스 상태는 AWS Health Dashboard에서 확인할 수 있음
  • 같은 현상을 겪는 사용자가 있는지 확인을 요청했으며, 이후 관련 Reddit 게시물도 추가함

비정상적인 예상 청구액

  • 이번 달 AWS 예상 청구액은 17억 달러로 표시됐지만, 해당 계정의 평소 사용료는 5달러 미만임
  • 게시자는 이처럼 큰 차이가 실제 사용량이 아닌 부정확한 예상 청구 데이터에서 비롯된 것으로 보고 있음

확인 및 대응

  • 문제 확인을 위해 긴급 AWS 지원 티켓을 생성함
  • 서비스 상태는 AWS Health Dashboard에서 확인할 수 있음
  • 다른 사용자에게도 같은 현상이 발생했는지 질문했으며, 이후 관련 Reddit 게시물을 공유함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • AWS에서 같은 오류를 처리한 적이 있는데, 원인은 단위 설정 오류였음. GB당 약 5센트를 청구하려 했지만 요금제에서 GB를 빠뜨리자 시스템이 기본 단위인 바이트로 처리했고, 바이트당 5센트가 되어 몇 시간 만에 일부 고객에게 수백만 달러짜리 청구서가 표시됨
    새벽 2시쯤 지원팀 호출을 받아 3~4시까지 수정과 청구 정정을 마쳤고 곧바로 사과 메일도 보냈음. 서비스가 내보내는 사용량 값은 가격과 직접 연결되지 않으며, 각 SKU나 청구 항목은 단위 유형·리전·단위당 가격을 포함한 요금제로 정의됨. 계정 ID·리전·SKU 등을 기준으로 사용량 기록과 요금제를 결합하므로, 단위 유형을 잘못 지정하면 변환이 깨져 터무니없는 청구액이 나옴

    • 테스트가 없었던 건가? 평범해 보이는 세부 사항 하나를 잘못 설정하면 수십만 명의 관리자에게 새벽 호출과 심장마비를 안길 수 있다는 건가?
      물론 “이건 평범한 세부 사항이 아니야, Michael!”이라고 하겠지만: https://www.youtube.com/watch?v=3fGHaVn5rGo
    • AWS 청구 시스템이 아직도 데이터 전달에 CSV 파일을 쓰는지 궁금함. 10여 년 전 AWS에서 첫 당직을 맡았을 때, 어느 “똑똑한” 엔지니어가 운영 데이터의 설명 필드에 “이 필드에, 쉼표를 넣으면 어떻게 될까” 같은 실험용 레코드를 넣어 청구 처리가 깨졌음
      그 레코드가 퍼지면서 리전들이 차례로 같은 방식으로 실패하는 모습을 지켜봤고, 한 사람이 수많은 이의 저녁을 망쳐 놓았음. 테스트 엔드포인트를 쓸 수 있었지만 굳이 운영 환경에서 시험한 셈임
    • 농담으로 넘길 일이 아님. 심혈관 질환 같은 기저 질환이 있는 사람이 갑자기 이런 청구액을 보면 불안·충격·무력감 때문에 실제로 사망할 가능성도 있음
    • 어리석은 기본값을 택하기보다 항상 크게 실패하도록(fail loud) 만드는 이유가 이것임
    • 혹시 gp3 EBS 볼륨이 출시된 날 벌어진 일이었는지 궁금함

  • 예산이 18달러 한도를 넘었다는 경고 메일을 연달아 세 통 받고 확인했더니 비용이 7,800만 달러였음. 피싱인 줄 알고 실제 계정으로 직접 로그인했지만 여전히 7,800만 달러여서 정신적 충격이 상당했음

    • 오늘 안에 이 채용 공고의 설명이 수정될지 내기하고 싶음: “Software Development Engineer II, AWS Invoicing”
      https://www.amazon.jobs/de/jobs/10428480/software-developmen...
      생성형 AI·대규모 언어 모델·지식 그래프·에이전트형 아키텍처로 출시 준비, 클라우드 네이티브 서비스 조정, 지속적 검증을 자동화한다는 화려한 직무 설명이 붙어 있음
    • 내 청구액은 10억 달러 이상이었음. 처음에는 피싱이라 생각해 버릴 뻔했지만 너무 진짜 같아 AWS에 직접 로그인했고, 예상 청구액을 보고 심장마비가 올 뻔했음
      나중에 지원 페이지에서 장애 배너를 찾았지만, 정작 “당신이 10억 달러를 빚졌다”고 표시하는 청구 페이지에는 왜 안내 배너가 없었는지 의문임
    • 나도 awstrack.me URL이 몹시 수상했고 이런 경고를 처음 받아 피싱이라고 확신했음. 링크를 누르지 않고 콘솔에 들어가 보니 청구액이 잘못 표시되는 장애가 있었지만 이메일 경고 이야기는 없었고, 오히려 공격자가 장애를 틈타 탐지를 피한 건 아닌지 걱정됨
      로그를 확인한 뒤 장애 안내가 영향 범위를 빠짐없이 적지 않았을 뿐임을 깨닫고 다시 커피를 마시러 갔음. 다음부터는 여기부터 확인해야겠음
    • 오래된 농담을 바꾸면, AWS 청구서가 7만8천 달러라면 내 문제지만 7,800만 달러라면 Amazon의 문제임
    • 기업 계정에는 3조 달러가 넘는 청구액이 표시됐음

  • 이번 오류는 너무 터무니없어 곧 수정되겠지만, 2010년대 초에는 실제 청구서에 숨어 있던 오류를 발견한 적이 있음. 일부 서버의 EC2 예약 할인을 잘못 계산하고 있었고, 18개 탭짜리 스프레드시트로 세부 사용량을 정기 분석해도 금액이 맞지 않아 몇 달간 차이를 추적했음
    원인을 찾은 뒤에도 AWS 시스템이 틀렸다고 설득하는 데 상당한 시간이 들었고 그동안 차액은 계속 쌓였음. 14개월 후 7,000달러 환불을 받았으며 AWS 책임자의 승인이 필요했다고 들었고, 이후 AWS 측 계산 오류는 다시 보지 못했음

    • 7,000달러 크레딧 자체는 당시 가까운 제품 관리자나 디렉터도 큰 감독 없이 발급할 수 있었음. 문제는 14개월이라는 기간으로, 같은 청구 주기의 수정은 쉽고 직전 주기도 번거롭지만 흔한 반면, 이전 회계연도들까지 정정하려면 재무 부서를 거쳐야 해서 훨씬 고통스러움
    • 동료들은 내가 Cost Explorer를 지나치게 자세히 본다고 여기지만, 이상한 비용을 찾아내는 시간은 대체로 충분히 본전을 뽑고도 남았음. 이 오류를 추적하는 데 7,000달러어치 시간을 쓰지는 않았을 것이고, 그 과정에서 더 큰 비용 최적화 기회도 찾았을 가능성이 큼
      돈을 낭비해 Jeff Bezos의 요트를 더 크게 만들어 주는 것도 싫음
    • “곧 수정될 것”이라기엔 이미 12시간째임. 사람이 에이전트가 작성해 반영한 코드를 이해하지 못하는 모양임

  • 원래 GB of storage consumed여야 할 단위가 Bytes of storage consumed와 뒤섞여 2^30배 오류가 난 듯함
    “계산을 의심할 만합니다. 필드 정의를 조회하려 했지만 MCP 서버 연결에 실패했고, 검증 대신 추측했습니다. 제 잘못입니다. 하지만 늘어난 매출을 보세요!”

    • 고객에게 청구할 금액을 계산해 달라며 0.45, 1.67, 2.50을 줬으니 합은 4.62지만 다른 숫자일 수도 있음. 이어 붙여야 할 수도 있고, 점이 곱셈을 뜻한다면 0 . 45 . 1 . 67 . 2 . 50은 3,015,000이 됨
      0을 곱하면 0이어야 하지만 아무것도 청구하지 않을 수는 없으니 3,015,000천 달러가 정답임
    • “계산을 의심할 만합니다”가 패러디인지 실제 응답인지 이제는 구분조차 어려움. LLM이 절대로 내놓지 못할 만큼 어리석은 문장을 써 보라고 해도 그런 어리석음의 한계는 없을 듯함
    • 오늘 로컬 에이전트에 사람이 읽을 수 있는 크기 단위가 담긴 CSV를 주고 GB 구간별 행 수를 세게 했는데, 이상하게 MB를 GB로 해석해 완전히 틀렸음. 돌이켜 보면 Excel로 직접 계산하는 편이 더 빨랐을 것임
    • 2*30이면 60이므로 2,830만 달러만 내면 되지만, 의도한 것은 아마 2^30 이고 그러면 1.5달러가 됨
    • 청구 시스템을 바이브 코딩해 매출을 9,000% 올렸으니 승진 자료로는 훌륭함

  • 아침에 청구 경고 메일을 보고 AWS 키를 실수로 유출해 4,370억 달러를 쓴 줄 알았음. 다행히 내게는 그만한 돈이 없으며, 커피 없이도 전에 없던 아드레날린이 분출됐으니 AWS에 감사함

    • AWS에 43만7천 달러를 빚졌다면 내 큰 문제지만, 4,370억 달러를 빚졌다면 AWS의 큰 문제임
    • 이 일로 실제 심근경색을 겪거나 사망한 사람이 있을지도 모름. Amazon이 이런 값을 사용자에게 그대로 표시한 것은 무책임한 처리임
    • 잠들려던 중 경고를 받았는데, 내가 설정한 16달러 한도를 확실히 넘긴 금액이었음
    • 탈취된 계정 때문에 AWS와 두 달간 싸웠음. 이전 3년 동안 월 사용료가 약 20달러였는데도 2만 달러를 잃고 수만 달러짜리 청구서가 더 들어왔으며, AWS는 내가 직접 침해를 막기 전까지 돕지 않았음
      퇴근 후 밤을 새워 AWS 인프라 스크립팅을 배워 침해를 통제했지만 계정 폐쇄도 거부당했고, 사례를 검토하려면 공동 책임 합의서에 서명하라는 요구도 거절했음. 결국 주 법무장관실에 연락하자 그곳에서 AWS에 직접 이메일을 보냈고, 24시간도 안 돼 AWS 관리자가 전화해 계정을 정리하고 2만 달러를 환불해 줬음. 그런데도 계정 폐쇄는 끝내 거부해 AWS에서 완전히 빠져나갈 방법이 없는 듯하며, 최악의 사업 방식으로 느껴짐
    • 내 경우는 5억 달러였고 손이 너무 떨려 비밀번호조차 입력하기 어려웠음

  • 계정 담당자에게 예산 사정을 알리고, 다시 형편이 나아질 때까지 매달 수십억 달러씩 성의 있게 상환할 수 있는지 관대하게 봐 달라고 요청하면 됨

    • 약한 모습을 보여서는 안 됨. 정면으로 해결하고 한도가 더 큰 신용카드를 발급받아야 함

  • 은행에 100달러를 빚지면 내 문제지만, 17억 달러를 빚지면 은행의 문제임

    • 아내가 이전 직장에서 중견 기업 행사를 맡았을 때 행사 후 법인 Amex 잔액이 보통 30만 달러를 넘었음. 출산 휴가 중 대체 담당자가 청구서를 내지 않아 복귀했을 때는 미납액이 50만 달러 이상이었고 Amex의 이메일과 음성 메시지가 잔뜩 쌓여 있었음
      메시지는 처음엔 정중했다가 점차 다급해졌지만, 한 번도 위협적이거나 적대적으로 변하지 않았음
    • 이 농담은 실제로 AWS에 17억 달러의 비용을 안겼을 때만 성립함. 이유 없이 청구서만 발행한 것이라면 여전히 사용자의 문제임
    • 그렇다면 은행에 1조7천억 달러를 빚지면 어떻게 되는지가 다음 질문임
    • Elon Musk라면 해당되지 않을 수 있음

  • AWS가 Anthropic이 사용량 0인 사람에게 1,600만 달러를 청구한 것을 보고 수백만 달러에서 멈출 이유가 없다고 생각한 모양임
    https://www.techtimes.com/articles/320266/20260712/anthropic...

    • AI 청구 감사 스타트업 Vaudit가 기업 고객 60곳의 청구서 3,400만 달러어치를 검토해 약 170만 달러의 과다 청구, 즉 약 5%의 오류율을 발견했다면 상당히 심각함

  • 최근 Whole Foods에서 결제할 때 Chase Amazon Prime 카드를 더는 자동으로 안정적으로 인식하지 않아 할인가가 자동 적용되지 않는다는 사실을 알았음. 수년간 잘 작동하던 방식대로 결제하면서 정가를 내는 고객이 얼마나 될지 궁금함
    매장 고객 서비스 직원에 따르면 지난 1년 사이 바뀌었으며, 손바닥 결제 기능을 없앤 데 따른 의도치 않은 부작용으로 추측함. 직접 관련된 일은 아니지만 Amazon이 또 무엇을 제대로 계산하지 못하고 있을지 떠오름

    • 이제 집단소송이나 수천 건의 소액재판을 진행할 차례임. 중재 조항이 있더라도 이를 처리하는 부담은 막대하므로, 누군가 옳은 결정을 내려 자동 환불하기를 바람
    • 예전에는 단순하고 안정적이던 시스템에서 이런 작은 문제가 수없이 생기고 있음. 모두가 바이브 코딩 때문은 아니겠지만, 그중 얼마나 많은 문제가 바이브 코딩의 결과인지 궁금해짐

  • 한 번은 2만 달러 청구액이 은행 계좌에서 실제 인출됐고, 해결해 돈을 돌려받기까지 몇 달과 주 법무장관실의 개입이 필요했음. 이후 AWS 제품은 전혀 쓰지 않고 작은 작업도 Azure로 옮겼음
    AWS 청구 문제는 수년째 이어졌으며, 탈취된 계정에서 암호화폐 채굴 서버가 몇 달 동안 돌아가 학생에게 6만 달러가 청구됐는데도 AWS가 탐지하거나 차단하지 못한 일들을 온라인에서 쉽게 찾을 수 있음

    • AWS는 사실상 공공 서비스 사업자에 가까우므로, 청구를 부주의하게 다루다 보면 결국 그에 준하는 규제를 받게 될 수밖에 없음
    • 변동 비용 서비스에는 항상 지출 한도 카드를 사용해야 함
    • 탈취 계정 탐지가 100% 정확할 수는 없다고 봄. 사람이 직접 보면 명백해도 모든 계정의 사용량을 사람이 선제적으로 검토할 수는 없음
    • 서비스 제공자 이용의 첫 번째 교훈은 자동 결제를 절대 활성화하지 않는 것임. 편리함이나 할인보다 업체가 자율적으로 계좌의 돈을 모두 빼 갈 위험이 훨씬 큼
    • 한동안 홈랩 일부를 AWS에 두었음. 학생들이 클라우드를 배우는 교실의 교육자였고 강사가 실습용 환경을 만들도록 권해 나도 무료 등급 EC2에 LAMP 스택 MediaWiki를 설치했는데, 초기 구성은 어렵지 않았지만 두 가지 이유로 영원히 떠나게 됐음
      첫째, 오늘날에도 인터넷에 노출된 평범한 Linux 시스템을 충분히 보호하기가 불가능하거나 지나치게 노동집약적이었음. fail2ban을 설치하고 많은 포트를 막아도 스팸 공격은 응용 계층으로 들어왔음. 둘째, 청구 주기마다 클라우드 지출 상한을 강제하는 것이 실제로 불가능했음. 대부분 무료 한도 안에 들어와도 설정 하나가 틀리거나 자원이 폭주하면 이의를 제기하기 어려운 큰 청구서가 생기며, 특히 외부 사용자가 VPC 자원과 외부 전송 트래픽을 소비하는 등 통제 밖의 원인으로도 발생할 수 있었음. 그래서 계정을 닫았고, 자체 설비 대신 클라우드를 강제로 쓰면서도 비용을 통제할 수 없는 기업들에 깊이 공감하게 됐음
답변달기