AWSアカウントのコストを見直していく

この記事は Ateam Lifestyle Inc. Advent Calendar 2021 15日目の記事です。

概要

• AWSアカウント開設から数年経過し、コストが不要に嵩んでたので見直した話
• 目新しいものはない
• 泥臭いけど頑張る

コストの実績を分析

アカウントで生じている費用を分析しましょう。まずは現状把握から。
私の場合は以下のような観点で見直しました。

• Cost Explorerのグループ化：サービスから
  • どのサービスでどの程度コストが生じているかチェック
  • 総額から金額割合が大きいサービスが何か当たりをつける
    • 弊社環境だとRDS、EC2、EC2その他、OpenSearch、ELBあたりが大きめ
    • S3も把握しておいた方がいい（理由は後述）
  • 大きい順にやるのが効果的だが、個人的には数百ドル程度発生しているサービスはチェックするようにした
    • どこまでやるかの匙加減次第なので、お好みで
• Billing -> 請求書から
  • Cost Explorerで当たりをつけたサービスで、実際に何にお金がかかっているかドリルダウンして把握する
    • インスタンスの稼働時間
    • ストレージ容量
    • データ通信量による従量課金
    • リクエスト数による従量課金
    • etc...

注意点

Cost Explorerと請求書の費用はNotイコールなので気をつけてください。
私の場合はデータ通信量部分が異なっており、最初戸惑いました。

Cost Explorerではデータ通信量による課金がサービスに含まれていますが、請求書ではData Transferの分類になっています。
Data TransferはAWSアカウントにおける全体のデータ通信量に対する金額の提示ですので、サービス単位でどの程度使っているかは分かりません。
Cost Explorerと請求書を比較して、費用が一致していない分がデータ通信にかかる費用だとざっくり把握しました。

さらに細かく分析したい場合は、Billingにある Cost & Usage Reportを使って分析するのが良いと思います。
私はおおよそデータ通信部分で金額一致したので、そこまではやりませんでした

サービス別 コスト削減方法

EC2

EC2のインスタンスタイプ見直す

時間ないなら割愛してSP買うにすすんでもOK
でもできるなら機会を見つけてEC2のインスタンスタイプが過剰になっていないか見直した方が良いです

弊社環境では開発が進んだ結果、EC2から別リソースに移った環境がいくらかありました。
その結果として、過剰なインスタンスタイプになっているマシーンが数台ありました。
SP買った後にスケールダウンするとSP使用状況に影響を与えるので気をつけましょう。

SP買う

Savings Plans買いましょう。SPの解説は特にしません。
どういう観点で買うべきかですが、弊社は以下の観点で購入しています。

• 1年？3年？
  • 1年
    • 3年後まで未来見通せるなら3年でもいいけど、私は絶対に止めておけって言う
• 前払いした方がいい？
  • すべき
    • 前払いなしとありで、約5%程度変わる
    • 経理と折り合いつけたり事務手続きしたりが一番ハードルあったので、そこ超えれるかによる
• Compute？ EC2? どっちのタイプ買った方がいい？
  • ケースバイケース
    • インスタンスファミリーを１年間変更しない自信があるならEC2で個別に買ったほうがお安い
    • 上記でないなら素直にComputeに身を捧げる
• 何ドルで確約する？
  • 推奨事項を一定信じていい。過去実績は正しい
  • 未来は推奨事項では読めないので、事業部にヒアリングして今後のロードマップからマシンスペックが増えたり減ったりを予測する
  • とはいえ推奨事項100%の数字にするのはリスキー＆インスタンス数は増減するので、おおよそ80%ぐらいの数字に抑えて弊社は購入している
    • ここの割合はインスタンス増減のイベントがどの程度生じるかに依存するので、一定変更がなければもっとピーキーに数値を上げても問題ないと思う
    • 逆によく増減するならもっと下げた方が安パイだろう
  • こういうことを考えて決めるのが、この記事見てる人の仕事だと思うので、頑張って試算して決定しよう
• SPとRI、どっちがいいの？
  • SPの方が包括してみてくれるので、SP推奨
  • でもSP対象ではないサービスもあるので、気をつけよう
    • RDSとか、OpenSearchとか、ElatiCacheとか

RDS / OpenSearch / ElastiCache

インスタンスタイプ見直す

EC2と同じ
ただしマネージドであるため、Graviton2を利用しても影響が少ない。Graviton2にするのは良い判断だと思います
もしGraviton2にできたのなら、10%程度は安くなるはず

弊社の場合、RI購入期間なのでまだ変更できませんでした。
RI切れた暁にはGraviton2にしたいと密かに考えています

注意点
RDSをGraviton2にする際は、RDSのアップグレードが必要になるケースが多いです
現時点で利用しているRDSのバージョンはきちんと確認し、アップグレード必要有無を確認ください

OpenSearchは基本的にローリングアップデートで置き換えられるんで、RDSよりも気楽にやってしまって良いと思います。（きちんとアップグレードのドキュメントは読んでね！）

リザーブドインスタンス買う

インスタンスファミリーをきちんと定めて購入しましょう
全額前払いでRDSだと40%ぐらい削減できるんで、おすすめです

EC2 その他

その他ってなんだ？と最初は思いましたが、だいたいEBSです
gp3が昨年発表されましたが、gp2使用されている方はgp3にしましょう。
性能上がって安くなる、控えめにいって最高です。
操作も画面上からぽちぽちするだけ。オンライン更新。簡単。

金額差は大きくないですが、EBSはリソース消す以外は基本ずっと残るので、将来にわたってボディーブローのように効いてきます。
なお、割り当てていないEBSがあれば削除しましょう。恐ければスナップショット取っておきましょう。
生EBSのまま残しておく意味は多分ないです。

なおEBSは一度プロビジョニングした容量を削れないので、不要なまでに容量割り当ててしまった人は諦めるか作り直しましょう。

ELB

弊社の場合はデータ通信の金額はほぼ全てなので、削減できることはありませんでした。
AWS以外のCDNでデータ通信料が安いものを使うなどは検討しています。

ELBは何故か消し忘れが多かったので、不要なELBは削除しています。
ELBに限った話ではありませんが、誰も使っていないけど残ってるリソースは結構あるので、時折整理すると良いのではないでしょうか

Cloudwatch Logs

意外とお金かかってる部分です。
RDSの監査ログだったり諸々のログをひたすら溜め込む状態になりやすいからでしょう。

S3と比較するとGBあたりの単価はCloudwatch Logsの方が安く見えますが、圧縮率の兼ね合いで実はS3の方が安いというレポートもあったりします。（ググったらすぐ出てくるんで割愛）
直接S3におけるリソースはS3へ、Cloudwatch Logsしか指定できない場合（RDSとか）はCloudwatch Logs to S3にエクスポートする設定をしましょう。

Cloudwatch Logsには失効期間を設けて、直近のデータはCloudwatch Logs、アーカイブはS3といった役割分担ができると節約できます。

S3

S3もCloudwatch Logsと同様、データを溜め込んだ結果コストに跳ね返ってくることが多いです。
直近のre:Inventでも発表がありましたが、GB単価が安くなったり、新しいストレージクラスが増えたりしているので、変更を検討しましょう。

バケットの分析

バケットは多数あると思いますが、いちいち１つ１つのバケットメトリクスを見ていると日が暮れます。
S3 Storage Lensを利用して、アカウント上に存在する全バケットの情報を参照しましょう。
Storage Lensで俯瞰してみると、バケットのストレージ利用サイズ、平均オブジェクトサイズなどが把握できます。

ストレージクラス変更の検討

使用状況が分析できたら、以下のフローでストレージクラスを変更可能か検討しましょう。
GB単価は高い順に以下の通りです。
StandardからGlacier DAにすれば、理論上95%カットできます。（そんなうまい話は滅多にないですが）

Standard > Intelligent-Tiering >  1 Zone IA >>（安くなる壁）>> Glacier IR > Glacier FR > Glacier DA

• オブジェクトサイズが128KBよりも小さい
  • Yes
    • S3 Standardしか使えない
  • No
    • 別のクラスを検討
• アクセス頻度が多数あるか？
  • Yes
    • S3 Standard
  • No
    • 別のクラスを検討
• データ消えてもいい？
  • Yes
    • 1 Zone IA （障害で消えたらデータ返ってこないから使うときは覚悟しよう）
  • No
    • Standard IA
• アクセス頻度高いときもあり、低い時もあり、どのオブジェクトにアクセスしてるかわからん
  • Yes
    • S3 Intelligent-Tiering
  • No
    • S3 Standard
• アーカイブ目的だしデータ取り出しとかほとんどしない（年１とか）
  • Yes、でも取り出しは早くしたい
    • Yes
      • Glacier Instant Retrieval （最近のre:Inventで発表されたやつ）
    • No
      • Glacier Flexible Retrieval （上記が発表されて名前変わった昔はGlacierだったやつ）
  • No、データ早く取り出せる必要もないぜ！
    • Glacier Deep Archive

ストレージクラス変更のためのライフサイクルポリシー設定

ログのような性質のデータを変更したい場合、オブジェクトが大量にあると思います。
オブジェクト数が多いと変換に時間かかるので、ライフサイクルポリシーに任せましょう。
XX日間経過したデータはGlacier Deep Archiveに変換する処理を入れればあとは待つだけです。

注意
ストレージクラス変換にはコストがかかります。
弊社の場合大量に溜まった数年間のログをGlacier DAに変更しましたが、変換で数百ドル発生しました。
実際の料金は AWS Pricing Calculatorで計算できるので、事前にいくらかかるかは見積もっておきましょう。
ちなみにショットでコストはかかりましたが、長い目で見ればS3コストはかなりカットできています。

またGlacierや低頻度アクセス系は取り出しにもコストが発生するため、バケット内オブジェクトにどの程度アクセスするのか？は変更前に一定の把握はしておきましょう。
バケットにストレージクラス分析を設定して利用実体を可視化するのもオススメです。

その他、Spot利用

弊社内ではAWS BatchによるECSインスタンス起動は全てSpotで稼働させています。
メモリ大量の処理を毎日１時間程度流すシステムがありますが、数ドル/月 とべらぼうに安いです。おすすめです。
今後はFargate Spot活用するなど、Spot利用できる環境をSpot化していけると、よりコスト的には素晴らしい結果が出ると期待しています。

まとめ

• なんぼかかってるか把握せよ
• RIやSPは神
  • １年後も使う予定があるなら積極的に買おう
• リソースごとに削減できる方法が変わるから手法は把握しておこう
• たまにリソース整理しような

おしまい

明日は @yuko1658 です。昨年もそうでした。奇遇ですね！

以上