先月のAWS費用を見て泣くと
AWSのBilling and Cost Managementを見て、少し首をかしげました。
Elastic Load Balancingが爆上がりしている！
上の画像の12月の赤い部分Elastic Load BalancingがALBの費用と思われます。ちょうどGoogle Search Consoleに登録をしたので、クローラーがアクセスしに来ているのが原因かと思います。正直、EC2をスケールアップしたのでEC2の費用ばかり気にしていてALB（アプリケーションロードバランサー）はノーマークでした。。しかし、全体の30%くらいここで使ってる…。大体20$弱。日本円にして月額3,000円程度アップ。「おい！こりゃ上がりすぎだろ！」
ALBの課金は「起動しているだけ」＋「使われた分」
あまり意識していなかったが、チャッピーに聞いたところALBの課金体系は
- 時間課金 → ALBを作って存在しているだけで発生
- LCU課金（Load Balancer Capacity Unit） → どれくらい処理したかに応じて加算
つまり、アクセスが少なくてもALBが動いていれば最低限の料金は必ずかかるという仕組みのようです。
ただ、それだけならこんなに跳ね上がらないはず。問題は処理した量に応じて課金される LCU課金 でした。
CloudWatchでALBのメトリクスを確認してみる
原因調査のため、CloudWatchでALBのメトリクスを確認しました。
見たのは主にこの2つ。
- RequestCount → ALBに届いたリクエスト数
- ConsumedLCUs → 実際に消費されたLCU
すると、違和感に気づきました。
８時から１０時の間にLCUが跳ね上がる
RequestCountのグラフを見ると、8時から10時までの間は１秒間に１回程度のアクセス。それ以外の時間も１秒間に0.2回程度のアクセスがある模様。そして8時から10時はLCUが跳ね上がり、CloudWatchの棒グラフが綺麗な台形になっています。
どうも単位がわかりにくいですが、
3e-3 = 0.003 LCU
らしいです。指数表記とのこと。むずいよ。。0.003と言われると少ないですが、積み上がってこの費用になってるんですね。
この時間以外も常にリクエストが発生している。
人気のブログだったらいいのですが、こんな個人がひっそりやっているブログにこんな常時アクセスあるわけないでしょう。GoogleのBotかイタズラかどっちかだろう。詳しいサーバーログはまだ見てないので正体は未定ですが、多分そうでしょう。また、チャッピーによるとWordPressサイトは狙われやすいとのこと。
LCU課金がやっかいな理由
LCUは、
- 新規接続数
- 同時接続数
- リクエスト数
- 転送量
この 4項目のうち一番大きいもの で決まるようです。
つまり、アクセス元がBotでも人でも関係なくALBに届いた時点で「仕事をした」扱いになる。
ApacheやWordPress側で弾いても、ALBを通過した時点で課金は確定。
転送量も関わるってことは記事の画像とかも関係してくるってことですね。これは意識してなかったですが、地味にお財布に効きます。人が見てくれてるならいいですが、イタズラでアクセスされてお金かかるんじゃ癪ですからね。
個人ブログ × ALB は意外と贅沢構成だって
今回あらためてチャッピーに確認したところ、
「個人ブログ用途だとALBはコスパが悪くなりやすい」
ですって。元々チャッピーと話しながら作ったはずなんだけど。。「お前がALB使えって言ったんだろ！」って感じですが、AIってしれっと手のひらを返してくるよねぇ。。まぁチャッピーがいなかったらサイト自体が立ち上がってなかったので、感謝の方が勝ってますよ！いつもありがとう。チャッピー。
今後の対策（予定）
現時点でチャッピーと共に考えている対策は以下。
- CloudFrontを前段に置く
- ALB構成自体を見直す
- BotをALBに届く前で止める
このあたりは、実際に構成を変えたら別記事で検証結果を書こうと思っています！
まとめ
- ALBは「何もしてなくても」お金がかかる
- BotアクセスでもLCUは消費される
- CloudWatchを見ると原因は意外と分かりやすい
- 課金状況は定期的に確認しよう
AWSは便利ですが「動いている＝課金されている」 を忘れると
お財布の中身を容赦なく奪い取って行きますね。アラートとかちゃんと設定すればいいんでしょうが、一歩一歩やっていきましょう！
最終的には収益化してAWS運用費くらいは賄えるようにしたい！