S3のコスト削減に失敗した話｜ハンズラボ株式会社

2023.12.13

S3のコスト削減に失敗した話

こんにちは、POSグループのオオバです。
早速ですが皆さんに質問です。

上司から「S3のコストが高いんだけど削減できないかな」と言われたら、どんな対応が思いつきますか？

私の頭に浮かんだのは以下の2点です。

削除可能なオブジェクトを削除する
ストレージクラスをGlacierなどの低コストなものに変更する

この2点について実際に検討してみました。

削除可能なオブジェクトを削除する

実は削除って難しい。
法令により決められた期間保管しなければならないものや「いつかデータ分析に使うかもしれない」などの理由で削除できないものが多いからです。
そんな中で狙い目なのはバックアップです。
今回の場合、毎日取得されているバックアップのうち一切削除していないものがあったため、ライフサイクルルールを設定し、45日間経過後に削除するようにしました。
他にも作業前に一時的に取得したバックアップが放置されていたため、この機会に削除しました。
しかし、これらの作業で削除できたのはたったの60GBでした。

ストレージクラスをGlacierなどの低コストなものに変更する

こちらはAWS認定試験でよく登場しますね。
Amazon S3 Glacierはアーカイブ用のストレージクラスであり、スタンダードクラスと比べて低コストです。
長期保管が必要なものの、アクセスされることが少ない場合に選択されます。
今回はログデータをGlacierに移行できないか検討しました。
当チームでは毎日大量のログが発生しているものの、長期の保管が必要であり削除できないデータとなっています。
検討にあたり必要な情報は下記の通りです。

アクセス頻度
取り出しまでにかかる時間はどのくらい許容できるか

アクセス頻度は1日に何度もアクセスされるのか、ほどんどアクセスされることはないのかということです。
Glacierはアーカイブ用ストレージなのでアクセス頻度の高いデータには向きません。

取り出しまでにかかる時間はどのくらい許容できるかについては、すぐに取り出したいのか、数時間なら待てるのかということです。
これにより適切なストレージクラスが変わります。

今回対象となるログデータは作成されてから数ヶ月も経つとほどんどアクセスされることのないデータであり、取り出しまで数時間かかっても問題ないため、S3 Glacier Flexible Retrievalクラスがいいのではないかと判断しました。

これがわかったところでS3 StandardクラスからS3 Glacier Flexible Retrievalクラスへ移行した場合、どのくらいコストが削減できそうかAWS Pricing Calculatorを使って試算してみました。
すると・・・

え、むしろコスト上がってる！？

ここで重大な見落としに気づきました。
S3 Glacier Flexible Retrievalクラスには以下の注意点があったのです。

S3 Glacier Flexible Retrieval と S3 Glacier Deep Archive ストレージクラスでは、適切なストレージクラス料金が課される S3 Glacier のインデックスとメタデータに対して、オブジェクトあたり 32 KB のデータがさらに必要となります。Amazon S3 では、S3 Glacier Flexible Retrieval と S3 Glacier Deep Archive にアーカイブされるオブジェクトのユーザー定義名とメタデータを保存して維持するために、オブジェクトごとに 8 KB が必要です。
https://aws.amazon.com/jp/s3/pricing/

今回対象としているログデータは一つあたりが1KBもないような小さなオブジェクトが大量に存在する状態です。
1オブジェクトあたり32KB+8KBのデータが付加されるため、実際のログデータよりも付加データの方が非常に大きくなってしまいました。
オブジェクトのサイズが小さい場合、Glacierにしても安くなるどころか高くなってしまうんですね。
ちなみにS3 Glacier Instant Retrievalクラスでは128KBの最小オブジェクトサイズが設定されているため、こちらもまたコスト削減には至りませんでした。
AWS認定試験の知識だけだとなんとなく「Glacierにしたら安くなりそう」と思ってしまうのですが、実際には慎重に検討する必要がありますね。
というわけでS3のコスト削減は思うようにいきませんでした。