AWSでDynamoDBのコストが意図せず増えていた時の調査方法覚書

この記事では、個人開発でAWSを使用する際に発生する余計なコストを特定する方法が紹介されています。コストエクスプローラーを使用してコストを調査し、プロビジョンドキャパシティーモードのDynamoDBテーブルなどの設定を見直すことでコスト削減が行われました。AWS Community Builderやクーポンの活用による運用方法に注意が喚起され、定期的なコストエクスプローラーの確認が重要であることが示唆されています。

広告ここから
広告ここまで

目次

    この記事ではAWSを使って個人開発に取り組んでいた際に発生していた余計なコストを特定する方法を紹介しています。「開発でチャレンジして、失敗・成功したことをシェアしよう Advent Calendar 2024」15日目の記事として作成しました。

    結論

    • サービスのセットアップや初挑戦時に、コストのかかるリソースや設定を選んでいないかちゃんと確認しよう
    • よくわからずに作成した or 横着して作成した場合に備えて、コストレポートは定期的にみよう
    • AWS Community Builderになっておくと、クーポンが貰えるのでお得

    ことの始まり

    AWS Community Builderとして活動しているため、AWSの利用料金はだいたい月5から10ドル程度に収まっています。クーポンの対象外リソースであるAWS Marketplaceの利用料金やRoute 53で購入したドメインの料金などへの請求がほとんどで、それ以外のEC2やDynamoDB等で発生した料金はクーポンにて賄っています。

    AWSのマネージメントコンソールTOPページなどに月ごとのリソース利用状況が見れるのですが、ある日レポートウィジェットに目を向けると、妙にDynamoDBでコストが発生していることに気づきました。

    かなり数を減らしたとはいえ、まだ10から20のAlexaスキルでDynamoDBを使っているため、そこが原因ではないか?と思いつつ、念のためコストエクスプローラーで調べてみることにします。

    コストエクスプローラーで利用状況を調査する

    AWSの利用状況はコストエクスプローラーで調査できます。早速レポートを見ていきましょう。

    クーポンで割引されたリソースは、コストエクスプローラーのデフォルト設定に出てこない

    コストエクスプローラーを見ると、このような表示でした。クーポンで割引された後の請求額に関する請求しか表示されていないため、DynamoDBはカウントされていません。

    料金タイプをUsageに変更すると、割引前のコストが出てくる

    割引前の利用状況は、レポートの「料金タイプ」をUsageに変更すると確認できます。

    設定を変えると、先ほどは表示されていなかったサービスが色々と出てきました。余談ですが、EC2やWorkMailは実際に使っているリソースですが、Pinpointは消し忘れの気配があります・・・

    Pinpointが気になるものの、先に金額の大きいDynamoDBを調査します。フィルターの[サービス]をDynamoDBにすることで、DynamoDBだけのレポートが作れます。

    ディメンションでコストが嵩んでいるリソースを調査する

    個人開発でAlexaスキルやWebアプリなどを複数作るため、AWS Organizationを使ってアカウントを分割して運用しています。そのため、どのサービス群で使っているかを特定するため、ディメンションを[連結アカウント]に設定して、コストが発生しているAWSアカウントがどれかを調べましょう。

    明らかにコストのかかっているAWSアカウントが1つ出てきました。続いてどのリージョンで使われているかを調べるため、ディメンションをリージョンに変更します。

    最後にディメンションをAPIオペレーションへ変更して、どんなAPIリクエストにコストが嵩んでいるかを見つけましょう。

    us-east-1にあるDynamoDBテーブルのWrite操作にお金がかかっている様子なのがわかりました。ここからはAWSのリソース設定を調べにいくことにします。

    DynamoDBのテーブル設定を調査する

    具体的にプログラムコードを調べる前に、まずはテーブルを調査しましょう。該当アカウント・リージョンにアクセスすると、このようなテーブルが並んでいました。[プロビジョンド (5)]のテーブルが複数並んでおり、この時点で「あっ」となっています。読み取りと書き取りのキャパシティを事前に確保している状態になっているため、これでコストが発生している可能性が高そうです。

    キャパシティの設定はすぐに変更できる項目ですし、CloudWatchなどを見てもAPIリクエストが集中している様子もありませんでした。そのため、一旦4・5つのテーブルでキャパシティーモードをオンデマンドに変更してみます。

    設定を変更する前に、念のためプレビューで使用量はチェックしておきましょう。下のスクリーンショットのように平坦なグラフならば、オンデマンドにしちゃって大丈夫なはずです。

    半月ほど様子見してからレポートを再度見る

    本当にキャパシティモードが原因であれば、コストのグラフが大きく変わるはずです。半月ほど経ったタイミングでレポートを見ると、次のようにガクッと数字が下がっていました。

    ここまで大きく変わっていればほぼ確定だろうということで、すべてのテーブルをオンデマンドキャパシティに変更しました。

    まとめ

    Alexaスキルを大量作成していたころ、デフォルトの設定で横着したのか、ASK SDK経由でテーブルを作ったのかは不明ですが、プロビジョンキャパシティモードのDynamoDBテーブルを複数作成していた様子です。そしてAWS Community BuilderやAlexaスキル公開でのクーポンを活用した運用を行っていたことが原因で、コストに気付きにくい状況が発生していました。

    コストアラートの設定もそうですが、定期的にUsageモードでコストエクスプローラーを見る習慣をつけることが、余計な出費に泣かないためにも大切ですね・・・

    広告ここから
    広告ここまで
    Home
    Search
    Bookmark