はじめに
クラウドインテグレーション事業部の緒方です。
S3のストレージのクラスをStandardからGlacierに変更した際に、請求額が大変なことになったので、その要因と回避方法などについてまとめました。
S3のストレージクラスとは
AWS S3(Simple Storage Service)ではユーザーの利用形態に合わせて複数のストレージクラスが用意されています。
簡単に紹介するとStandardはよく出し入れする場合に最適で、Glacierは出し入れの頻度が少ない場合に最適です。
リクエスト数と料金について
| PUT、COPY、POST、LIST リクエスト | GET、SELECT、他のすべてのリクエスト | ライフサイクル移行リクエスト | データ取り出しリクエスト | データ取り出し | |
|---|---|---|---|---|---|
| S3標準 | 0.0047[USD/1,000Request] | 0.00037[USD/1,000Request] | 該当なし | 該当なし | 該当なし |
| S3 GlacierInstant Retrieval | 0.02[USD/1,000Request] | 0.01[USD/1,000Request] | 0.02[USD/1,000Request] | 該当なし | 0.03[USD/GB] |
(2023/3/3時点)
再現してみた
1ファイル10MBのダミーファイルを20個用意します。
dummy_1〜10をS3にアップロードします。
これをGlacierに移すときにリクエスト数は20回になると思っていました。
しかし、データ移行後、リクエスト数を確認するとこんな感じに。。
リクエスト数は直感的に20くらいかと思うところですが、2倍超のリクエスト数にりました。
これではおちおちストレージクラスの移行ができないですね。そこで原因と回避策を調べてみました。
原因と回避策
原因
ある一定以上のサイズのオブジェクトがコピーされる際に、処理速度を速くするために、オブジェクトが一定サイズに分割されマルチパートアップロードの仕組みが用いられるようです。
AWS CLI version 1 では、1 パートのサイズは multipart_chunksize で指定された設定値となり、multipart-chunksize のデフォルト値は 8MB だそうです。
つまり、multipart-chunksizeがデフォルトのままでは今回作成した10MBのファイルは2つ以上に分割されることになります。
回避策
例えば、しきい値を10MBと指定するためには以下のコマンドで変更できます。
$ aws configure set default.s3.multipart_threshold 10MB $ aws configure set default.s3.multipart_chunksize 10MB
上記の設定を行うことにより、10MGBに満たないオブジェクトのストレージクラス移行にはマルチパートアップロードが適用されなくなります。
また、10.1MBでも、切り上げられてリクエスト数2となります。
その他の方法として、S3 ライフサイクルを利用する方法があります。
S3 ライフサイクルをご利用いただくことで、オブジェクトが作成されてからの経過日数を元にオブジェクトのストレージクラスを移行することが可能です。オブジェクトクラス移行に際し S3 ライフサイクルにより発行されるリクエストは、オブジェクト一つにつきストレージクラス移行リクエスト数が1つとなります。
※ライフサイクルによる移行は非同期的に行われます。
まとめ
今回はS3のストレージクラス変更の際に気をつけることについて書きました。
移行がお急ぎでない場合は、ライフサイクルを利用して移行することで、びっくりする様な料金請求が防げるようです。
参考
AWS S3ストレージクラス：https://aws.amazon.com/jp/s3/storage-classes/
S3の料金について：https://aws.amazon.com/jp/s3/pricing/
AWSコマンドリファレンス：https://docs.aws.amazon.com/cli/latest/topic/s3-config.html
