💸

4日で$62,000請求されそうになった話(CloudTrail Lake)

2023/06/21に公開

cloudtrail

背景

毎日の運動と食事制限ですこぶる身体の調子が良い @___nix___ です。

世の中には NatGateway の通信料金でご苦労された方も多いこととは思いますが、本件はこの比ではありません。

タイトルの通り、そのまま対応が少しでも遅れれば本当に4日で $62,000 請求されていたという実話です。

実際には 19時間程で $21,000 請求されました。

皆さんも十分に気を付けましょうという注意喚起の為に記事を書きました。

前提

コスト管理を毎日やろうとするとチェックが大変だったりするので、あるサービスでは次のように Budget の設定をしてありました。

前月比33%超過
前月比66%超過
前月比100%超過

つまり、1. の通知は10日前後、2. の通知は20日前後で届いていれば通常運転であることが確認できます。

事象発生当日

16:48(JST) に AWS Budgets alert | Account: ************ の通知が届く。
Slack に届いた通知を見ると...

え？！
今日はまだ14日なのに「前月比66%超過」の通知が！

調査開始

対象サービスを特定

コスト超過なのでやはり確認すべきは請求書です。(CostExplorerでも良いのですけどね）

早速確認してみると CloudTrail のコストが突出しており、詳細を確認すると $2.5 per GB for Ingestion-Bytes in Asia Pacific (Tokyo) と $2.5 per GB for Ingestion-Bytes in US West (Oregon) が凄いことになってました。

説明	使用量	金額USD
$2.5 per GB for Ingestion-Bytes in Asia Pacific (Tokyo)	4,283.44 GB	USD 10,708.60
$2.5 per GB for Ingestion-Bytes in US West (Oregon)	4,325.058 GB	USD 10,812.65

CloudTrailの確認

この情報を元に CloudTrail を確認すると、前日の夜22:01(JST)に実行した Lake の「イベントデータストアを作成」によるコストであることを特定し、直ちに停止及びイベントデータストアの削除を実施しました。

CloudTrail ログで確認するとこの削除実施が 17:19(JST) で、実際イベントデータストアの作成を停止したのはもう少しだけ前の時間でした。

CostExplorer で日別のコストを確認すると次の通り。

13日分 ... 約$13,000
14日分 ... 約 $8,000
合計 ... 約 $21,000
※4.3TB程のインデックス化 x 2リージョン分

何が起こっていたのか？

CloudTrail は全てのリージョンログを証跡ログの場所（S3）に保存します。
CloudTrail Lake はこの S3 のログをイベントデータストア化し、クエリによる検索がし易いようにインデックス化するのですが、このイベントデータストア化にコストが掛かります。

機能	月額料金
取り込みと保存 (料金は 7 年間のストレージを含む)	最初の 5 TB: 1 GB あたり 2.5 USD その後の 20 TB: 1 GB あたり 1 USD 25 TB 以上: 1 GB あたり 0.5 USD

ではログはどの位の量なのか？

これは CloudTrail の証跡ログの場所になっているS3バケットのメトリクスで確認できます。
証跡ログ用のS3のバケットメトリクスの「合計バケットサイズ」を確認すると約22TB でした。

※以下のリンクから遷移可能

途中で気が付かなかった場合...

では途中で「イベントデータストアの作成」を中止していなかった時の金額を試算してみます。

	S3(GB)	Price($/GB)	Cost($)	Cost(JPY)
最初の 5 TB	5,000	2.5	12,500	1,750,000
その後の 20 TB	17,000	1	17,000	2,380,000
小計	22,000		29,500	4,130,000
サポート料			1,770	247,800
合計			31,270	4,377,800

※1$ = 140円換算

ザックリで $31,000 程ですがこれは1リージョンのコストなので、2リージョン合わせると $62,000 となるわけです。

つまり作成から停止までの19時間18分程で4.3TBがイベントデータストア化されることから逆算すると、22TBのログは約99時間（4日と3時間）に相当します。

イベントデータストア化のパフォーマンスがもしこれ以上に爆速であった場合、1日で$62,000 となる可能性もあったはずです。（イベントデータストア化のパフォーマンスは非公開）

その後

AWSサポートとはサポートケースでやり取りするのみならず、担当者レベルで直接電話で話をする等長期に渡り交渉を重ねさせて頂きました。

もちろんAWSの責任共有モデルは承知していましたので、全額返金とまではいきませんでしたがある程度の妥協点で双方合意する形で終結しました。

気を付けるポイント

証跡ログのサイズ

CloudTrail Lake で「イベントデータストアの作成」をする際は必ず「証跡ログ」のサイズを確認しましょう。

マルチリージョンの証跡確認

CloudTrail Lake の「イベントデータストア」は「証跡ログ」のインデックス化です。もし CloudTrail の「マルチリージョンの証跡」が「はい」になっているのであれば複数リージョンで実行する必要はありません。

コスト肥大への対策

コスト監視はそれぞれの方法を利用しているかと思いますが、早期に気が付けるような設定内容や通知先にしておきましょう。

付録

証跡ログのサイズが大き過ぎませんか？

仰る通りです。
一般的にはそれ程証跡ログが大きいことは無いはずです。
実はこの事象が発生する前には AWS Config のコスト肥大化に遭遇していました。

サービス運用の中でAI処理が大量に ECS を RunTask するようなワークフローがあり、これが原因で AWS Config のコスト肥大が発生、結果的に CloudTrail の証跡ログも肥大化することになっていました。

※因みにこの事象に対しては「AWS EC2 NetworkInterface」のリソースタイプのみ除外すればOKでした。

その他 AWS におけるコスト肥大化

以下のように幾つか怖いポイントがあるので注意です。

編集後記

チャレンジすることは大切です。
CloudTrail Lake でクエリ使って証跡追うのを便利にしよう！と考えたまでは良かったのですが、理解しないまま使うとまさかの事象に遭遇する可能性もあるので注意してください。

AWSサポートの方々にも多大なご協力を頂きましたことをここに御礼申し上げます。
少しでも同じ事象で困る人達が出ないよう記事を執筆させて頂きました。