Lapis Lazuli

technical blog for web developer

S3を効率的に使ってコスト削減したい

前回に引き続き、今回はよく使われるS3について。

S3の料金体系って皆さん知っての通り、保存したオブジェクトの容量と、アウトバウンド転送量で課金される仕組みになっています。
今回は保存容量を削減して上手くコストカットするやり方を勉強したので書きたいと思います。

そのオブジェクト、無駄じゃないですか?

S3のstandardストレージはGBあたり0.025$なので、単価はかなり安いです。(50TBまで。それ以降は更に安くなる)
なのでついつい保存したままになっちゃうんですよね・・・特に容量の少ないファイルは。
けど保存しただけで使わないファイルや、たまにしか使わないファイルってあると思うんですよ。何年も使ってると。
そういったファイル。どうにかしたくなってきませんか?(僕はしたいです)

ライフサイクルを設定して段階的に移行する

最もポピュラーで比較的簡単なのは、ライフサイクルを設定することです。
1週間、1ヶ月などの期間が経過したら、standard-IAに移行するのがポピュラーなやり方じゃないでしょうか。
まぁファイルの種類によるんですが・・・ログファイルなど、滅多に取り出す必要のないものに関しては、いっそGracierを使うのがいいかなと思います。
数年前のログなんて調査するときにしか必要ないですしね。もっとも、取り出すのに時間がかかるので、そこはケースバイケースです。

マルチパートアップロード

S3にはマルチパートアップロードという機能があります。
一つのオブジェクト自体は最大5TBまでアップロードできるのですが、一度に遅れるのは5GBまでとなっています。
なのでSDKで分割して送信することになります。
が、送信に失敗すると部分ファイルがS3に残り、しかもコンソールから見えない厄介な存在と成り果てます。
コイツを処理するためにはcliから

aws s3api list-multipart-uploads --bucket バケット

と打ち込めば一覧が出てくるので削除するだけです。
けど5GB以上をアップロードする機会なんてそうそう無いかな・・・こういう機能もあるということを覚えておけば大丈夫かと。

まとめ

やっぱりバケット作る時にはライフサイクルを設定するようにしたほうがいいです。
それと同時に使うことのないファイルを消すよう、システムの中に組み込むのがいいですね。ユーザーが解約したらデータを消すとか。
ちなみにうちのプロジェクトではほぼ放置になっています()