AWS Amplifyの公式ガイドに従ったら$1,100の請求が発生
(elliott-king.github.io)- AWS AmplifyのOpenSearch連携公式ガイドで試した後、利用量は多くなかったにもかかわらず、Amazon OpenSearch Serviceの費用が1か月で**$1,124.88**まで増加
- 費用の原因は、
npx ampx sandboxが作成したOpenSearchドメインがサンドボックス終了・削除後も残り、次回実行時に新しいドメインが追加されて累積したため - 公式構成ではデフォルトで
r5.large.searchインスタンスが作成されるが、最低でも月額$134レベルのこのデフォルト値がボイラープレートコードやガイドで明示されていなかった - AWS SupportはOpenSearchとストレージについて一度限りのクレジットを提供し、再発防止のためAWS Budgetsの設定を求めた
- AmplifyとOpenSearchを併用する際は、サンドボックス削除後に残ったリソースとデフォルトのインスタンスタイプを自分で確認しないと、予期しない課金を避けられない
予期しないOpenSearch課金
- AWS AmplifyでOpenSearch連携公式ガイドに従って作業した後、数週間後にAWSの請求書が**$1,200超**になっていた
- Supportへの問い合わせで特定されたサービスはAmazon OpenSearch Serviceで、1か月の合計額は**$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 pipeline1つ、IAMロールなど複数のリソースが含まれる
- 公式ボイラープレートはデフォルトで
r5.large.searchOpenSearchインスタンスを作成する- このデフォルト値はボイラープレートコードやガイド内で明示的に示されていなかった
r5.large.searchは最低でも月額$134かかる
- 1日の作業を終えて
CTRL-Cでsandboxを停止すると、完全に削除するかを尋ねるプロンプトが表示され、ユーザーはYを選べる - このときDynamoDBは削除されるが、AWSコンソールで見るとOpenSearchドメインはそのまま残っている
- 翌日に
npx ampx sandboxを再実行すると新しいOpenSearchインスタンスが作成され、npx ampx sandbox deleteでも元のインスタンスは削除されない - 同じ手順を繰り返すと、同一プロジェクトに複数のOpenSearchドメインがバックグラウンドに残り、費用が積み上がる
バグの可能性とデフォルトのインスタンスタイプ
- この挙動は大きなfootgunに見え、AWS Supportチケットの後も当時は解決されていなかった
- 関連する古いバグ報告はあったが、1年以内の項目は見つけられなかった
- 例としてaws-amplify/amplify-cli issue #10523が挙げられている
- OpenSearchドメインがv1では正しく削除され、v2ではそうでない可能性はあるが、確定した原因ではない
- 現在のフローはAmplify CLIではなく、
npx経由で実行される r5.large.searchがデフォルトのマシンタイプである点も危険要因として残る- デフォルト値を持たせず必須フィールドにしたほうがよいと考えられる
- ガイドが
r5.large.searchをデフォルト値として表示していれば、ユーザーはより認識しやすい - このデフォルト値はAmplify専用ではなくAWS CDKの一部であるため、Amplifyチームだけの責任とは見ていない
AmplifyとOpenSearchを使う際の注意点
- 新しい技術の開発速度を高めるツールがbare metalより高価になり得ることは予想していたが、今回の費用はその範囲を超えていたという
- AWSのbudgetコンソールを使えば、予想支出が予算を超える際に警告を受け取れる
- OpenSearchセクションだけを進めても、IAMアカウント、OpenSearchドメイン、OSIS pipeline、log group、S3 storageが作成され、隠れたリソースが多い
- OpenSearchは企業顧客がよく使うサービスであるため、「高度な」サービスと見なされ、ユーザーがAWSエコシステムをより深く理解している前提があるのかもしれない
geo_pointbounding-boxクエリ対応のためOpenSearchを使ったが、もっと単純な製品で代用できたかは確信が持てない- 更新によるとAWSガイドはその後修正され、最初に問題提起した3か月前には更新されていなかったが、記事公開前にはドキュメントPR作業が始まっていたようだ
1件のコメント
Hacker Newsのコメント
課金アラートは冗談みたいなもので、実際に必要なのはハードな支出上限だ
オンボーディング中にその上限を設定する方法も提供すべきだ
白紙委任と偶発的な課金の上にビジネスを築くのは胡散臭く、導入障壁も高い
開発者が「20分のチュートリアルに従ったら一生かけて貯めた金額並みを請求され、今回はカスタマーサポートが免除してくれたけど次は家まで持っていかれそうだった」みたいな事例を見るほど、AWS製品を試したいと思えなくなる
AWSやDigitalOceanのようなリスクを顧客に押しつけるところと、怪しげな「無制限」「メータリングなし」料金プランを売るところだ
どちらも望んでいる形ではない
明確で文書化された上限のもとで適切に容量計画ができ、可用性リスクは顧客が負うとしても金銭的リスクは提供側が負う事業者があってほしい
法外でなければ、より高い固定料金を払ってもよい
重要なアプリケーションでダウンタイムやデータ損失を発生させるより安い偶発課金など、ほとんど存在しない
たとえオプションであっても経理部門が利用を強いる可能性があり、問題が起きた際にデータ損失事故につながる危険がある
インディー開発者や中小企業中心のクラウド事業者には理にかなうかもしれない
ここで知った内部事情の中でもかなり興味深い部類だ
後悔するより、安くて定額のVPSを使うほうが安全だ
Amazonに何かしてくれと頼んでも大して意味はない
Amazonや他社がユーザーの金を尊重するよう、法律で強制すべきだ
企業は基本的に倫理的によいことや経済にとってよいことではなく、金になることをする
比べれば些細な話だが、ECSにアプリをデプロイしようとして100ドルの請求を受け、AWSは二度と使わないと決めた
サービスが立ち上がらないエラーは自分のアプリ側の問題だったが、CloudWatchのログが2割程度しか出なかったため、ログを得るために5回再デプロイして修正し、その後さらに5回再デプロイする必要があった
失敗したデプロイのたびに課金され、2日ほど苦労した末にアカウントを削除してDigitalOcean App Platformへデプロイした
そこでもアプリのエラーでデプロイは失敗したが、ログは毎回出力され、10分以内に修正して動かせたし、請求総額は数セントだった
あの日以来、選択肢があるならAWSは絶対に使わないし、勧めもしないと心に決めている
開発・テスト用途では従量課金モデルが非常に安かった
大規模ワークロードではどうか分からないが、デプロイのたびに課金されるというのは妙だ
大きなプロジェクトならサポートはよりよいのかもしれないが、小規模から中規模ならGCPのほうがずっとよい
今どきのコンテナ利用に合った基本コンポーネントがあり、BigQueryもある
その
npxコマンドが実行するスクリプトには明らかなバグがあるように見える投稿者の言う通り、チュートリアルであるなら100%最も安いリソースを選ぶべきだし、
deleteサブスクリプトを実行したならリソースを片づけるべきだこういうものを実行したあとで、開発者がAWSアカウント全体を被害妄想的にくまなく調べ回り、取り残されたリソースを探すことを期待するのは不公平だ
スタートアップがこんな動きをしていたら、「こういうことは起こり得るから気をつけるべきだ」で済ませていただろうか
なぜAWSには別の基準が適用されるのか分からない
現在自分が料金を払っているすべてのリソースを簡単に確認する方法がない
仮にあるとしても見つけられていない
分かりやすい概要がなければ、自分のアカウントを完全に統制できていないように感じる
それ以上使ったらどうなるのか、予期しない課金を制限できるかも見る
できないなら別のものを探す
数年前のGoogle Mapsの課金変更以降、「無料」のGoogleサービスに深く依存させられることにも非常に慎重になっていて、結局かなりの費用がかかった
いつもサービスごと、リージョンごとに確認しなければならず、退屈でミスも起きやすかった
たとえバグだと考えていたとしても、自社の損益に直接打撃を与えるほかの案件よりはるかに優先度が低いだろう
ただ、現実的には合理的でもある
AWSで何かを作るときは、AWSを暴走した敵対的な金融機関のように扱っている
こうした事例のせいで、何年も AWS を掘り下げて学ぶのを先延ばしにしている
クレジットカード情報を要求せず、人々が無料で試せる標準的な教育コースが必要だ
その代わりに、「ユーザーのミス」であちこちから数千ドルを引き出せると計算している事務方がいるように見える
こうした課金は争うのも難しく、場合によってはまったく不可能だ
巨額の請求書が来るかもしれないというもっともな恐怖のせいで AWS 環境を避けた人は、私だけではないはずだ
正確で安価なチュートリアルを提供するより、返金対応のほうが負担が小さいと判断している可能性が高い
それで行動が正当化されるわけではないが、AWS Textract を使って正当に発生した 600 ドルの請求さえ取り消してもらえたことがある
当時私は数十億ドル規模の企業で働いていた
料金表は簡単にアクセスできるし、いつも分かりやすいわけではないが、ほとんどのコストはほぼ線形に増えるのでテストは比較的しやすい
AWS Amplify、CloudFormation、各種 Stack 系のようなラッパーサービスは避けたほうがいい
コアサービスを直接使えばいい
すべてのサービスには API があり、IAM ユーザーに紐づく API キーを受け取るのはボタンをクリックするくらい簡単だ
あとは適切なキャッシュと、コストモデルを売上モデルに合わせることで管理できる
自動スケールするサービスのコストが、現在の需要に関係なく売上のほぼ固定比率になるようにすればいい
帯域幅は AWS では本当に悪夢だが、コンソールで自動の長期割引が提供されるし、営業担当を通せば少し良い契約割引も得られる
このため EC2 は避けており、EC2 の内部帯域もより高いので、Lambda + S3 + CloudFront を直接使うほうがよいと思っている
3 か月ほど経つと、新しいユーザー向け機能を実装するときにどのサービスの組み合わせが最も費用対効果が高いか、かなり簡単に予測できるようになった
そういう用途向けのものかもしれないが、自分では使ったことがないので確実ではない
私の経験では AWS は、評判の悪化でもっと大きなコストが発生する問題を避けようとする側に近かった
AWS は安くはないし、場合によっては特にデータ転送コストのようにとてつもなく高いが、顧客をだまして数百ドル余計に偶発的支出をさせるのが彼らのやり方だとは思わない
いかにも AWS らしい
数か月前に Llama 2 を動かそうとして公式のSageMaker クイックスタートガイドに従ったら、本当にすぐ起動したが、翌日見たら 1 日400 ドルかかっていた
請求は取り消してもらえたが、公式ガイドを信用してはいけないとはっきり学んだ
製品初期の 2017〜2018 年ごろは、設定がかなり直感的だった
ノートブックインスタンス、推論、サービング用 REST API、少しの EFS、そしてサービスの中心が S3 であることが明確だった
価格も閉じた形で、驚かされることはなかった
全体として DigitalOcean のような感触で、インフラの基礎知識と好奇心があるデータサイエンティストでも、安価で予測可能かつシンプルな構成を作れた
今では Wrangler、Feature Store、RStudio があり、ノートブックのコンソール UX はひどく、内部では複数のサービスがデータを移動させてそのたびに課金している
AWS の肥大化した SDK の代わりに事情があって生の HTTP リクエストを送る必要があったのだが、
content-type: application/jsonヘッダーでは失敗し、content-type: application/x-amz-json-1.0では成功したこういう nonsense は本当にやめてほしい
明確な利点もなく、過剰に肥大化していたり、複雑すぎたり、奇妙な独自実装が多すぎる
内部的にはたいていのアプリが古いCoral フレームワークを使っており、入出力やエラー形式がよく定義されたこの JSON 形式を使っているからだ
すべての公式 AWS ガイドは、できるだけ多くの AWS サービスを使わせるよう設計されており、そのぶん支出リスクも増す
AWS が勧めるもの、つまり GUI のデフォルト、CLI ツール、ガイド、推奨アーキテクチャなどは、極めて批判的に見るべきだ
企業で AWS をコスト効率よく低リスクで使えるよう同僚を導く高給の職種が存在するのには理由がある
小規模デプロイやテストでは、最も高くつく部分はほぼ常に周辺的なものか、よりシンプルな代替手段ではなく推奨される最新サービスだったりする
geo_point境界ボックスクエリのために OpenSearch を使っているなら、PostgreSQL + PostGISはどうだろう？https://postgis.net/docs/using_postgis_query.html
こうした摩擦のないセットアップ、直感性の低い UX・インターフェース、クレジットカード登録への警戒心の低さ、AWS Batch + Lambda + EC2 のようなサービス間の抱き合わせ課金は、ビジネスモデルの一部だと思う
どう表現すべきか分からないが、入場料を払って中に入ったあと、すべてのアトラクションどころかトイレまで別料金の現代的な遊園地に近い
クラウドの課金モデルは、「柔軟性」と「カスタマイズ」という名目で責任をユーザーに押しつけている
レンタカー会社が、エンジンのカムシャフト回転、タイヤの回転、ワイパーの作動、シートヒーターの使用時間まで、あらゆる部品をミリ秒単位で課金しつつ、各項目ごとに通知を設定できるので顧客は使用量と予算を「制御」できると言っている状況を想像すればいい
デフォルトの時点でユーザーに敵対的で危険なコストモデルだ