AWS Amplify 공식 가이드를 따랐더니 $1,100 요금이 청구됨

 (elliott-king.github.io)
1P by GN⁺ | ★ favorite | 댓글 1개
  • AWS Amplify의 OpenSearch 연동 공식 가이드로 실험한 뒤, 사용량이 많지 않았는데도 Amazon OpenSearch Service 비용이 한 달 $1,124.88까지 늘어남
  • 비용은 npx ampx sandbox가 만든 OpenSearch domain이 샌드박스 종료·삭제 뒤에도 남고, 다음 실행 때 새 도메인이 추가되면서 누적됨
  • 공식 구성은 기본으로 r5.large.search 인스턴스를 만들며, 최소 월 $134 수준의 기본값이 보일러플레이트 코드나 가이드에서 드러나지 않았음
  • AWS Support는 OpenSearch와 스토리지에 대해 1회성 크레딧을 제공했고, 재발 방지를 위해 AWS Budgets 설정을 요구함
  • Amplify와 OpenSearch를 함께 쓸 때는 샌드박스 삭제 후 남은 리소스와 기본 인스턴스 타입을 직접 확인해야 예기치 않은 과금을 피할 수 있음

예기치 않은 OpenSearch 과금

  • AWS Amplify에서 OpenSearch 연동 공식 가이드를 따라 작업한 뒤, 몇 주 후 AWS 청구서가 $1,200 이상으로 나옴
  • Support 요청에 잡힌 서비스는 Amazon OpenSearch Service였고, 한 달 총액은 $1,124.88였음
  • 2020년에도 Amplify와 OpenSearch를 사용한 경험이 있었고, 개인 용도로는 보통 월 $50 정도로 비싸지만 $1,200 수준은 아니었다고 봄
  • AWS Customer Support는 상세 검토 후 예기치 않은 비용에 대해 one time courtesy 형태의 billing adjustment를 처리함
  • Support 과정에서 OpenSearch와 스토리지 서비스 크레딧이 제공됐고, AWS Budgets 설정도 요구됨
    • AWS Budgets는 특정 서비스나 AWS 전체의 향후 지출을 예측하고, 예산 초과가 예상되면 알림을 보낼 수 있음

공식 가이드가 생성하는 리소스

  • Amplify quickstart는 AWS 제공 코드로 TODO 노트용 장난감 앱을 만들고, Amplify가 DynamoDB 데이터베이스와 인증된 CRUD 요청을 생성함
  • 로컬 실행도 가능하지만, Amplify는 접속 가능한 도메인도 함께 만듦
  • OpenSearch 설정 단계에서는 Amplify 리소스를 선언하기 위해 TypeScript 보일러플레이트를 작성함
    • DynamoDB 테이블을 변수로 잡아 pipeline에서 참조함
    • OpenSearch 인스턴스, index, indexMapping을 생성함
    • OpenSearch에 있는 데이터에 접근하는 쿼리를 작성함
    • DynamoDB에서 OpenSearch로 복사하는 OpenSearchIngestionService pipeline을 생성함
  • 관련 구성은 프론트엔드 코드와 함께 저장소 안의 TypeScript/JavaScript로 관리됨
  • npx ampx sandbox는 AWS 서비스를 띄우고, 구성 변경을 감지해 기존 AWS 서비스를 자동 수정함

샌드박스 삭제 뒤에도 남은 도메인

  • 이 구성에는 DynamoDB 데이터베이스, OpenSearch 서비스 1개, OSIS pipeline 1개, IAM 역할 등 여러 리소스가 포함됨
  • 공식 보일러플레이트는 기본적으로 r5.large.search OpenSearch 인스턴스를 생성함
    • 이 기본값은 보일러플레이트 코드나 가이드 안에서 명시적으로 드러나지 않았음
    • r5.large.search는 최소 월 $134가 듦
  • 하루 작업을 끝내고 CTRL-C로 sandbox를 중지하면 영구 삭제 여부를 묻는 프롬프트가 나오고, 사용자는 Y를 선택할 수 있음
  • 이때 DynamoDB는 삭제되지만, AWS 콘솔에서 보면 OpenSearch domain은 그대로 남아 있음
  • 다음 날 npx ampx sandbox를 다시 실행하면 새 OpenSearch 인스턴스가 생성되고, npx ampx sandbox delete도 원래 인스턴스를 삭제하지 않음
  • 같은 과정을 반복하면 동일 프로젝트에 여러 OpenSearch domain이 백그라운드에 남아 비용이 쌓임

버그 가능성과 기본 인스턴스 타입

  • 이 동작은 큰 footgun으로 보였고, AWS Support 티켓 이후에도 당시에는 해결되지 않았음
  • 오래된 관련 버그 리포트는 있었지만, 1년 이내 항목은 찾지 못함
  • OpenSearch domain이 v1에서는 제대로 삭제됐지만 v2에서는 그렇지 않을 가능성은 있으나, 확정된 원인은 아님
  • 현재 흐름은 Amplify CLI가 아니라 npx를 통해 실행됨
  • r5.large.search가 기본 머신 타입인 점도 위험 요소로 남음
    • 기본값 없이 필수 필드로 지정하는 편이 낫다고 봄
    • 가이드가 r5.large.search를 기본값으로 보여주면 사용자가 더 쉽게 인지할 수 있음
    • 이 기본값은 Amplify 전용이 아니라 AWS CDK의 일부라서 Amplify 팀만의 책임으로 보지는 않음

Amplify와 OpenSearch 사용 시 주의점

  • 새 기술의 개발 속도를 높여주는 도구가 bare metal보다 비쌀 수 있다는 점은 예상했지만, 이번 비용은 그 수준을 넘어섰다고 봄
  • AWS의 budget 콘솔을 사용하면 예상 지출이 예산을 넘을 때 경고를 받을 수 있음
  • OpenSearch 섹션만 따라도 IAM 계정, OpenSearch domain, OSIS pipeline, log group, S3 storage가 생성되어 숨은 리소스가 많아짐
  • OpenSearch는 기업 고객이 자주 쓰는 서비스라서 “고급” 서비스로 간주되고, 사용자가 AWS 생태계를 더 잘 이해한다고 기대될 수 있음
  • geo_point bounding-box 쿼리 지원 때문에 OpenSearch를 사용했지만, 더 단순한 제품으로 가능했는지는 확신하지 못함
  • 업데이트에 따르면 AWS 가이드는 이후 수정됐고, 처음 문제를 제기한 3개월 전에는 업데이트되지 않았지만 게시글 공개 전 문서 PR 작업이 시작된 것으로 보임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 결제 알림은 농담 수준이고, 실제로는 하드 지출 한도를 줘야 함
    온보딩 중에 그 한도를 설정하는 방법도 제공해야 함
    백지수표와 우발적 과금 위에 비즈니스를 세우는 건 수상하고, 도입 장벽도 큼
    개발자들이 “20분짜리 튜토리얼을 따라 했다가 평생 모은 돈만큼 청구됐고, 이번 한 번은 고객지원이 면제해줬지만 다음엔 집까지 가져갈 기세였다” 같은 사례를 볼수록 AWS 제품을 탐색하고 싶지 않아짐

    • AWS만의 문제는 아니고, 클라우드 제공자는 대체로 두 부류뿐인 듯함
      AWS나 DigitalOcean처럼 위험을 고객에게 넘기는 곳과, 수상한 “무제한”·“미터링 없음” 요금제를 파는 곳
      둘 다 원하는 형태가 아님
      명확하고 문서화된 한도로 용량 계획을 제대로 할 수 있으면서, 가용성 위험은 고객이 지되 금전적 위험은 공급자가 지는 제공자가 있었으면 함
      과하지 않다면 더 높은 고정 요금도 낼 의향이 있음
    • 하드 지출 한도는 AWS의 핵심 고객인 엔터프라이즈 고객에게는 역기능에 가까움
      중요한 애플리케이션에서 다운타임이나 데이터 손실을 만드는 것보다 값싼 우발 과금은 거의 없음
      옵션으로만 있어도 회계팀이 사용을 압박할 수 있고, 문제가 생겼을 때 데이터 손실 사고로 이어질 위험이 있음
      인디 개발자나 중소기업 중심 클라우드 업체에는 말이 될 수 있음
    • AWS 결제 코드는 거대한 스파게티 코드라서 큰 변경을 건드리는 데 내부적으로 두려움이 크다는 얘기가 HN 댓글에 여러 번 나왔음
      여기서 알게 된 내부 사정 중 꽤 흥미로운 축에 듦
    • AWS에 관심은 있었지만 이런 이유로 한 번도 제대로 발을 담그지 못했음
      후회하는 것보다 싸고 정액인 VPS를 쓰는 게 안전함
    • 규제해야 함
      Amazon에게 뭔가 해달라고 요청하는 건 별 의미가 없음
      Amazon과 다른 업체들이 사용자 돈을 존중하도록 법으로 강제해야 함
      기업은 기본적으로 윤리나 경제에 좋은 일이 아니라, 돈이 되는 일을 함

  • 비교하면 사소하지만, ECS에 앱을 배포하려다 100달러 청구서를 받고 AWS는 다시 쓰지 않기로 했음
    서비스가 뜨지 않는 오류는 내 앱 쪽 문제였지만, CloudWatch 로그가 20% 정도만 나와서 로그를 얻으려고 다섯 번 재배포하고 수정한 뒤 또 다섯 번 재배포해야 했음
    실패한 배포마다 과금됐고, 이틀쯤 고생한 뒤 계정을 삭제하고 DigitalOcean App Platform에 배포했음
    거기서도 앱 오류 때문에 배포는 실패했지만 로그가 매번 나왔고, 10분 안에 고쳐서 실행했으며 총 청구액은 몇 센트였음
    그날 이후 선택지가 있으면 AWS는 절대 쓰지 않고 추천하지도 않겠다고 다짐함

    • Azure만 써봤는데 ECS는 Azure Container Apps에 해당하는 것 같음
      개발·테스트용으로는 소비 기반 과금 모델이 매우 저렴했음
      큰 워크로드에서는 어떤지 모르겠지만, 배포마다 과금한다는 건 이상함
    • GCP처럼 컨테이너를 바로 EC2에 배포할 수 없다는 걸 알고 AWS를 포기했음
      큰 프로젝트라면 지원이 더 낫겠지만, 소규모에서 중간 규모라면 GCP가 훨씬 나음
      요즘 컨테이너 사용 방식에 맞는 기본 구성요소가 있고, BigQuery도 있음

  • 그 npx 명령이 실행하는 스크립트에 명백한 버그가 있어 보임
    작성자 말이 맞고, 튜토리얼이라면 100% 가장 싼 리소스를 선택해야 하며 delete 하위 스크립트를 실행하면 리소스를 정리해야 함
    이런 걸 실행한 뒤 개발자가 AWS 계정 전체를 편집증적으로 훑으며 떠돌이 리소스를 찾아야 한다고 기대하는 건 공정하지 않음
    스타트업이 이런 식으로 동작했다면 “원래 이런 일이 있으니 조심해야 한다”고 넘겼을까?
    왜 AWS에는 다른 기준을 적용하는지 모르겠음

    • AWS에서 가장 짜증 나는 점이 바로 그 부분임
      현재 내가 돈을 내고 있는 모든 리소스를 쉽게 확인하는 방법이 없음
      혹시 있다 해도 찾지 못했음
      이해하기 쉬운 개요가 없으면 내 계정을 완전히 통제하지 못하는 느낌이 듦
    • 새로운 걸 써야 할 때 가장 먼저 확인하는 건 매달 고정 청구서를 받을 수 있는지임
      그 이상을 쓰면 어떻게 되는지, 예상치 못한 과금을 제한할 수 있는지도 봄
      안 되면 다른 걸 찾음
      몇 년 전 Google Maps 과금 변화 이후 “무료” Google 서비스에 우리를 깊게 묶는 것도 매우 조심하고 있고, 결국 비용이 많이 들었음
    • AWS 계정에 존재하는 모든 리소스를 간단히 나열하는 방법이 있긴 한가?
      늘 서비스별, 리전별로 확인해야 했고 지루하면서 오류가 나기 쉬웠음
    • Amazon 입장에서는 손쉽게 1000달러를 벌 수 있으니 버그가 아니라 기능임
      설령 버그라고 생각해도, 자기들 손익에 직접 타격을 주는 다른 일보다 훨씬 낮은 우선순위일 것임
    • 개발자에게 편집증적 점검을 기대하는 건 공정하지 않다는 데 동의함
      다만 현실적으로는 합리적임
      AWS에서 뭔가 만들 때는 AWS를 폭주한 적대적 금융기관처럼 대함

  • 이런 사례 때문에 몇 년째 AWS를 파보는 걸 미루고 있음
    신용카드 정보를 요구하지 않고 사람들이 무료로 실험할 수 있는 표준 교육 과정이 있어야 함
    대신 “사용자 실수”로 여기저기서 수천 달러를 뽑아낼 수 있다고 계산하는 사무직들이 있는 듯함
    이런 과금은 다투기도 어렵고, 아예 불가능한 경우도 있음
    거액 청구서를 보고 일어날 수 있다는 합리적 두려움 때문에 AWS 환경을 피한 사람이 나뿐은 아닐 것임

    • 이런 상황에서 AWS가 환불을 안 해주는 건 매우 이례적이라, 사용자 실수에서 수천 달러를 짜내려는 전략이라고 보긴 어려움
      정확하고 저렴한 튜토리얼을 제공하는 것보다 환불 처리가 덜 부담스럽다고 판단했을 가능성이 큼
      그게 행동을 정당화하진 않지만, AWS Textract를 쓰다 정당하게 발생한 600달러 청구도 취소받은 적이 있음
      당시 나는 수십억 달러 규모 기업에서 일하고 있었음
    • 사람들이 이런 결제 상황에 빠지는 이유는 실제로 AWS를 깊게 파보지 않기 때문이라고 봄
      가격표는 쉽게 접근 가능하고 항상 이해하기 쉽진 않지만, 대부분의 비용은 거의 선형으로 늘어서 테스트하기는 비교적 쉬움
      AWS Amplify, CloudFormation, 각종 Stack 류 같은 래퍼 서비스는 피하는 게 좋음
      핵심 서비스를 직접 쓰면 됨
      모든 서비스에는 API가 있고, IAM 사용자에 묶인 API 키를 받는 건 버튼 클릭만큼 간단함
      나머지는 적절한 캐싱과 비용 모델을 매출 모델에 맞추는 것으로 관리 가능함
      자동 확장되는 서비스 비용이 현재 수요와 상관없이 매출의 거의 고정 비율이 되게 만들면 됨
      대역폭은 AWS에서 진짜 악몽이지만, 콘솔에서 자동 장기 할인을 제공하고 영업 담당자를 통하면 약간 더 나은 계약 할인도 받을 수 있음
      이 때문에 EC2는 피하고, EC2의 내부 대역폭도 더 비싸므로 Lambda + S3 + CloudFront를 직접 쓰는 편이 낫다고 봄
      3개월쯤 지나면 새 사용자-facing 기능을 구현할 때 어떤 서비스 조합이 가장 비용 효율적인지 꽤 쉽게 예측 가능해졌음
    • A Cloud Guru / Pluralsight에는 “Cloud Playground”나 “sandboxes”라고 부르는 기능이 있음
      그런 용도를 제공할 수도 있지만 직접 써보진 않아서 확실하진 않음
    • 이런 종류의 사용자 실수로 생기는 돈은 AWS 전체로 보면 새 발의 피일 것임
      내 경험상 AWS는 평판 손상으로 더 큰 비용이 생기는 문제를 피하려는 쪽에 가까웠음
      AWS는 싸지 않고, 어떤 경우에는 특히 데이터 전송 비용처럼 엄청나게 비싸지만, 고객을 속여 몇백 달러를 우발적으로 더 쓰게 만드는 건 그들의 방식이 아니라고 봄

  • AWS답다고 봄
    몇 달 전 Llama 2를 돌리려고 공식 SageMaker 빠른 시작 가이드를 따라 했는데, 정말 빨리 뜨긴 했지만 다음 날 보니 하루 400달러가 나가고 있었음
    청구는 취소받았지만 공식 가이드를 믿으면 안 된다는 건 확실히 배웠음

    • SageMaker는 제품 관점에서 가장 실망스러운 축이고, 엔시티피케이션의 명확한 사례임
      제품 초기인 2017~2018년에는 설정이 꽤 직관적이었음
      노트북 인스턴스, 추론, 서빙용 REST API, 약간의 EFS, 그리고 서비스 중심이 S3라는 점이 분명했음
      가격도 닫힌 형태라 놀랄 일이 없었음
      전체적으로 DigitalOcean 같은 느낌이었고, 인프라에 대한 기초 지식과 호기심이 있는 데이터 과학자도 저렴하고 예측 가능하며 단순한 구성을 만들 수 있었음
      지금은 Wrangler, Feature Store, RStudio가 있고 노트북 콘솔 사용자 경험은 끔찍하며, 내부에서 여러 서비스가 데이터를 옮기고 그걸 과금함

  • AWS의 비대한 SDK 대신 사정상 원시 HTTP 요청을 보내야 했는데, content-type: application/json 헤더로는 실패하고 content-type: application/x-amz-json-1.0으로는 성공했음
    이런 nonsense는 정말 그만했으면 함

    • 커리어 동안 만져본 AWS의 거의 모든 부분에서 비슷하게 느꼈음
      명확한 이득 없이 지나치게 비대하고, 지나치게 복잡하거나, 이상한 자체 구현이 많음
    • 솔직히 내부 세부사항이 새어 나온 것임
      내부적으로 대부분의 앱이 오래된 Coral 프레임워크를 쓰고, 입력·출력·오류 형태가 잘 정의된 이 JSON 형식을 사용하기 때문임

  • 모든 공식 AWS 가이드는 가능한 한 많은 AWS 서비스를 쓰게 설계되어 있고, 그만큼 지출 위험도 커짐
    AWS가 추천하는 것, 즉 GUI 기본값, CLI 도구, 가이드, 추천 아키텍처 등을 극도로 비판적으로 봐야 함
    회사에 AWS를 비용 효율적이고 낮은 위험으로 쓰도록 동료들을 안내하는 고액 연봉 직무가 있는 데는 이유가 있음

    • 맞음
      소규모 배포나 테스트에서는 가장 비싼 부분이 거의 항상 부수적인 것들이거나, 더 단순한 대안 대신 추천되는 최신 서비스들임

  • geo_point 경계 상자 쿼리 때문에 OpenSearch를 쓰는 중이라면, PostgreSQL + PostGIS는 어떤가?
    https://postgis.net/docs/using_postgis_query.html

  • 이런 마찰 없는 설정, 낮은 직관성의 사용자 경험·인터페이스, 신용카드 등록에 대한 낮은 경계심, AWS Batch + Lambda + EC2 같은 서비스 간 묶음 과금은 비즈니스 모델의 일부라고 봄
    어떻게 표현해야 할지 모르겠지만, 입장료를 내고 들어간 뒤 모든 놀이기구와 심지어 화장실까지 따로 돈을 내는 현대식 놀이공원과 비슷함

    • 나도 그렇게 느낌
      클라우드 과금 모델은 “유연성”과 “맞춤화”라는 명목으로 책임을 사용자에게 넘김
      렌터카 회사가 엔진 캠축 회전, 타이어 회전, 와이퍼 작동, 좌석 열선 시간 같은 모든 부품을 밀리초 단위로 과금하면서 각 항목마다 알림을 설정할 수 있으니 고객이 사용량과 예산을 “통제”한다고 말하는 상황을 상상해보면 됨
      기본값부터 사용자에게 적대적이고 위험한 비용 모델임
답변달기