背景
年明けから愛犬ツイートで1,500いいねに迫る勢いの @___nix___ です。
以前から話題になっている 第1回 AWSコスト削減 天下一武道会 ではコスト削減がテーマですが、ここではコスト事故がテーマです。
ランキング（認識している範囲）
現在までのランキング
7位 ... AWS Private CA（$400/月）
6位 ... Amazon Kendra （$810/月）
5位 ... NatGateway（$1,000/月）
4位 ... Amazon RDS Proxy（$1,190/月）
3位 ... 500万円のAWSサービスを申し込んでしまった話 ($36,000/年）
2位 ... AWS CloudTrail Lake （$62,000/4日）
1位 ... Amazon EC2 （$65,000/2日）
見事にランキング第3位に食いんだ以下の記事は中々パンチ力のある内容でしたね。
素晴らしい！（いやいやいや...）
本記事を含むランキング
8位 ... AWS Private CA（$400/月）
7位 ... Amazon Kendra （$810/月）
6位 ... NatGateway（$1,000/月）
5位 ... Amazon RDS Proxy（$1,190/月）
4位 ... 500万円のAWSサービスを申し込んでしまった話 ($36,000/年）
3位 ... 🌟[New] AWS CloudTrail Insights （$10,840/17時間）
2位 ... AWS CloudTrail Lake （$62,000/4日）
1位 ... Amazon EC2 （$65,000/2日）
前回2位のコスト事故は CloudTrail Lake によるものでしたが、今回は CloudTrail Insights によるものをご紹介します。
事故分類としては CloudTrail Lake に近いですね。なので費用も単価は近いです。
請求額
CloudTrail の通常時は大体このような請求額でした。
今回の事故による請求額はこちら。
巨額な請求額であることは桁の数だけでも俯瞰できるかと思いますが、詳細は後述します。
コスト事故の経緯
インシデントの発生
とあるインシデントが発生し、大量のイベントログの調査が必要になりました。
CloudTrail の「イベント履歴」ではどうしても限界があり、CloudTrail Insights の力を借りることを決定しました。
CloudTrail Insights とは？
CloudWatch Logs Insights と同じようにクエリを実行することでデータを集計する機能です
調査の為に CloudTrail Insights を有効化
CloudTrail Insights を有効化、つまり データストアの構築 が必要になります。
具体的には Insights の画面で [Create Event data store] から有効化します。
調査
イベント履歴を Insights でクエリ検索してインシデントの原因調査が可能となり、無事インシデントが解消されました。
ここでは詳細を説明していませんが、 Insights は CloudWatchLogs Insights と同様の使用感です。
調査完了の為、 CloudTrail Insights を無効化
CloudTrail Insights を無効化、つまり データストアの構築 の停止を実施したことになります。
コスト事故に関する解説
約17時間で $10,000 の請求額
これは前述した「請求書」の内容の通りです。
何故？？
CloudTrail Insights の課金内容を紐解くと以下の通りでした。
説明 : 0.0000035 per event analyzed in US West (Oregon) region
使用量 : 3,097,675,901 Events （30億イベント）
金額 : USD 10,841.87
合計時間 : 約17時間
| 日時 | Cost | 実行時間 | 割合 |
|---|---|---|---|
| 某月/n日 | $8,444.85 | 11:00(UTC) ～ 23:59(UTC) … 13h | 78% |
| 某月/n+1日 | $2,398.78 | 00:00(UTC) ～ 04:00(UTC) … 4h | 22% |
※182,216,229 Events/h （1.8億イベント/時間）
CloudTrail Insights の有料利用枠は以下の通り。
100,000 Eventsあたり $0.35 ですので 30億 Events もあればそれはそれは...
つまり、 CloudTrail Insights のデータストア構築によるコスト肥大化が事故の原因です。
同じ事象に遭遇しない為に
CloudTrail のログ(S3)のファイルサイズを事前に確認すること
ポイントは CloudTrail Lake と同様、データストア構築の元となるログです。
このログが肥大化していると、当然データストア構築にコストが掛かってしまいますので注意です。
S3ログの設定場所
CloudTrail 証跡の「全般的な詳細」で確認できます。
S3ファイルサイズの確認方法
ログの場所が確認できたら「合計バケットサイズ」を確認しましょう。
このスクショだと 45.5TB 程のサイズですが、このレベルだと間違い無く事故りますので気を付けてください。
S3ログ肥大化し易い環境
あくまで経験則に過ぎませんが、CloudTrail のログが肥大化し易い環境は主に以下のようなサービスや運用に関わるものだと考えています。
- 大量のECSタスクスケジュール
- 根っこには Config
- 更に根っこはリソースタイプ AWS EC2 NetworkInterface
- 根っこには Config
- Timestream のクエリ
- これはどこかで記事執筆の予定
特に Timestream は非常に便利な完全マネージド型時系列データベースですが、Timestream が必要となるような巨大なサービスを相手にする場合は多くのノウハウが必須になります。
今回はここまでとします。
編集後記
やはりこんな記事ばかり書いていると「おい、パリピ！お前んところは問題だらけじゃないか！」のご指摘はその通りなのかもしれません。（いや、そんな指摘は一度も受けたことないですが）
ただ、このような多くの経験や実績が積めるのも全ては「精神と時の部屋」のお陰なのです。
それでは皆さんもぜひこの「AWSコスト事故 天下一武道会」に参加したい方は @___nix___ までご一報ください。