はじめに

こんにちは、アプリケーションチームの小沼です。

以前の記事にて紹介した、AWS Cost and Usage Reports の活用事例を紹介したいと思います。

tech.motex.co.jp

見える化したかった内容

アプリケーションチームの中に、
- 自分たちの作った機能の維持費にどれくらいかかっているのだろう.
- 作ったけど、どれくらい使われているのだろう.
- 使われ方に対して、維持費は見合っているのだろうか.
という、AWS コストと利用状況に対する疑問が出てきました。
その疑問を解消するために、「機能毎の維持費と機能の利用状況」をまとめた QuickSightのダッシュボードを作成しました。

月額の維持費だけでなく、API Gataway経由で呼ばれるLambdaのInvoke数を並べることで、簡易的な利用状況とコストを横並べにできるのがポイントです。

使用したパラメータの紹介

各リソースに紐づく「タグ」

LANSCOPE エンドポイントマネージャークラウド版（以下、LANSCOPE クラウド版）ではAWS サービスのリソースそれぞれの「タグ」として、

キー：RESOURCE
値：リソースの名前

を付与しています。リソース名には命名規則を定めているため、こういった機能ごとの可視化を可能としました。
参考までに、LANSCOPE クラウド版で使用しているの代表的な命名規則は

${ctx}-${method}-${use}-${env}

となっています。

この「タグ」を設定することで、CUR上でresource_tags_user_r_e_s_o_u_r_c_eの項目に反映されます。
※resource_tag_user_XXXX はタグとして付与したキー名に応じて自動でCUR上に項目が作成されます。
QuickSight でダッシュボードを構成する際には、resource_tags_user_r_e_s_o_u_r_c_eに対して${ctx}などでフィルタすることで機能ごとの可視化を実現しています。

Lambda のInvoke 数を表すCUR の項目

line_item_usage_amountの合計を使用することでLambdaのInvoke 数を表現しています。
ダッシュボード作り始めは、CloudWatch メトリクスから新しくデータのインポートも検討していたのですが、 AWS のサポートケースに質問してみると、上記の項目がLambdaのInvoke 数とみなせる旨の返事をいただきました。そのため、QuickSight のデータソースがCUR1つのみとなっております。

QuickSight ダッシュボードを作成するうえで苦戦したこと

QuickSight ダッシュボードに使用するパラメータに「タグ」を使用していますが、
Amazon ECS がオートスケーリングでインスタンスの起動停止を繰り返すことにより、
タグが大量に発行されておりました。
そのため、
- 動的にダッシュボードに反映されない（新しいインスタンス分のタグ追加が必要）.
- ダッシュボードのフィルタ上限に抵触する.
が課題事項でした。

こちらについてはまだ解決ができておりません。
解決次第、続報をテックブログで公開しようと思います。

終わりに

AWS Cost and Usage Reports と Amazon QuickSight の活用事例についてご紹介しました。ダッシュボードは作成して間もないため、コスト改善の実績紹介ができないですが、活用実績ができ次第、ブログ公開していこうと思います。 AWS コストの改善などに関わっている方の参考になれば幸いです。