結論
ストレージクラスGlacier Flexible Retrievalと Glacier Deep Archive では、静的ウェブサイトホスティングをしてHTTPで単純に取得を試みてもエラーになります。
なお、これは静的ウェブサイトホスティングでなくCloudFront経由でのアクセスにしても結果は変わりません。
状況設定
あんまり見ないけどちょっとしたときに参照したいドキュメントを、Webサイトホスティングで簡易にブラウザからアクセスできるようにすることを考えます。
このときどのS3ストレージクラスを選択するのがよいでしょうか。
検討
候補となるストレージクラス
各ストレージクラスのなお、名称はS3料金1から"S3"を省いたものを、識別子はAWS CLI2のものを使います。
| 名称 | 識別子 | 特徴 | 注意点 |
|---|---|---|---|
| 標準 | STANDARD | デフォルトのストレージクラスです。 | 特にありません。 |
| 標準 - 低頻度アクセス | STANDARD_IA | 標準より可用性に劣りますが安価です。 | オブジェクトへのアクセスが標準より割高でGBあたりの取り出しコストが発生します。 また、128KB未満のオブジェクトは128KBとして課金されます。 さらに、30日の最低ストレージ日数があり、1分置いて消しても残り30日分が日割りで請求されます。 |
| One Zone - 低頻度アクセス | ONEZONE_IA | 標準 - 低頻度アクセスより更に安価かつ可用性に劣ります。 | 標準 - 低頻度アクセスと同様です。 また、AZ障害に弱いのでマスターが別にあるようなオブジェクト向きです。 |
| Glacier Instant Retrieval | GLACIER_IR | 低頻度アクセスシリーズより取り出しコストが割高ですが、安価で標準並みの可用性を備えています。 | こちらもオブジェクトの最小単位が128KBで、1Bのオブジェクトでも128KBとして課金されます。 さらに、90日の最低ストレージ日数があります。 |
| Glacier Flexible Retrieval | GLACIER | すぐに取り出す必要はないが、万が一のときは素早く取り出したいオブジェクトに向いています | すぐに取り出すことはできません。迅速取り出しでも数分かかり、さらに迅速取り出しは1000リクエストあたり10USD程度とかなり割高です。こちらも90日の最低ストレージ料金があります。 |
| Glacier Deep Archive | DEEP_ARCHIVE | すぐに取り出す必要のないオブジェクトを長期保存するのに向いています。 | 復元に半日程度は見る必要があります。こちらは180日の最低ストレージ料金があります。 |
| 低冗長化 | REDUCED_REDUNDANCY | Amazon S3のページからもしれっと消えていた3ので、今となってはあまり選択する理由がなさそうです。本記事ではただの興味で入れています。 |
なお、Amazon S3 Express One Zoneは静的ウェブサイトホスティングができないと明記があったので、今回の検証からは外しています。4
また、Intelligent-Tieringは各Tierに対応するストレージクラスが上記表の中にあるので検証からは外しています。
検証
HTMLファイルの準備
以下のようなHTMLファイルを、各ストレージクラスごとに用意します。
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>STANDARD</title>
</head>
<body>
<h1>ストレージクラス: スタンダード (STANDARD)</h1>
<p><a href="index.html">戻る</p>
</body>
</html>
S3バケットに、対応するストレージクラスで格納します。
ウェブサイトホスティングの設定
静的ウェブサイトホスティングを有効にします。
index.htmlは各ページへの目次にしています。
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Hello</title>
</head>
<body>
<h1>Storage Class</h1>
<ul>
<li><a href="standard.html">STANDARD</a></li>
<li><a href="standard-ia.html">STANDARD_IA</a></li>
<li><a href="onezone-ia.html">ONEZONE_IA</a></li>
<li><a href="glacier-ir.html">GLACIER_IR</a></li>
<li><a href="glacier.html">GLACIER</a></li>
<li><a href="deep-archive.html">DEEP_ARCHIVE</a></li>
<li><a href="reduced-redundancy.html">REDUCED_REDUNDANCY</a></li>
</ul>
</body>
</html>
アクセス結果
| 名称 | アクセス結果 |
|---|---|
| 標準 | ◯ |
| 標準 - 低頻度アクセス | ◯ |
| One Zone - 低頻度アクセス | ◯ |
| Glacier Instant Retrieval | ◯ |
| Glacier Flexible Retrieval | ✕ |
| Glacier Deep Archive | ✕ |
| 低冗長化 | ◯ |
ミリ秒レベルでの取り出しがサポートされているストレージクラスでは静的ウェブサイトホスティングが有効で、少なくとも取り出しに数分オーダーの時間がかかるストレージクラスでは Operation invalid for object's storage class として403エラーになりました。
復元が必要なストレージクラスなのに瞬時にHTTPリクエストできたらおかしいだろうと言われたらそれまでなのですが、Glacierの中でもInstant Retrievalは静的ウェブサイトホスティングに対応しているというのは直感的に判断しづらい面白い結果なのではないかなと思います。
考察
さて、ウェブサイトホスティングでのアクセス可能かつ低冗長化は省いた4つのストレージクラスのうち、冒頭の状況設定を考えるとどのストレージクラスを使うのがよいでしょうか。
標準
アクセス頻度が低いとしても、最も無難な選択肢だと思います。
S3標準は、ストレージクラス間で比較すると保存容量あたりの単価が高くてリクエストあたりの単価が安いという特徴があります。
オブジェクトサイズは読みやすくリクエスト数は読みにくいので、コストを予測しやすいという大きなメリットがあります。
予算を取る、見積もりをするというようなときは、標準を選択した時にかかるお金をベースラインとして考えると確度が高そうです。(ディフェンシブかつ妥当な金額が出そうだという意味です)
残りのストレージクラスは後述しますが非常にコスト算出にクセがあり、見積もりを誤りやすいです。
標準 - 低頻度アクセス
コスト最適化を目指すには悪くない選択肢だと思います。
アクセス頻度が低いことが体感的に正しいと思われれば、最初から標準 - 低頻度アクセスを選択してリクエスト数をウォッチするという作戦もありだと思います。
注意すべきは最小オブジェクトサイズと最低ストレージ日数です。
- 128KB未満のオブジェクトは128KBとして請求される
- 30日未満の保存日数であれば30日分の料金が日割り請求される
という特徴があり、何か入れた瞬間に128KBぶんのオブジェクトが30日保存されたに等しい料金が最終的にかかります。
数KBのオブジェクトを大量に入れているという使い方や、数日で別のストレージクラスに移行するという使い方をしていると却って高額になります。
僕が入れた高々200バイト程度のファイルも、きっちり128KBぶん課金(されるはず)です。
なにかの分厚いマニュアルを格納しておく、などのケースだと威力を発揮するでしょうか。
One Zone - 低頻度アクセス
基本的な考え方は標準 - 低頻度アクセスと同じですが、別の場所にマスターとなるものがない限りは使用を避けたほうが無難です。1つのAZにしか保管されないぶんデータ損失のリスクが大きいためです。
逆に、失われてもほかにマスターがあるから別に困らないという場合は標準 - 低頻度アクセスの上位互換の選択肢になるでしょう。
Glacier Instant Retrieval
コスト削減にしても攻めているなという印象です。128KBの最低オブジェクトサイズは低頻度アクセスシリーズと同じですが、最低ストレージ日数は90日であり、より長いです。
ストレージクラスの説明3内にあるパフォーマンスチャートにも、ユースケースとして「年に数回アクセスがあり、瞬時に取り出される長期間のデータ」とあります。本当にそのくらい長く保存すること、アクセスが稀であることが分かっていれば選択の余地があります。
おわりに
ここまで書いておいて何ですが、Intelligent-Tieringをオプションのアーカイブなしで使う、が非常に無難で正解な気がします。
コスト予測だけちょっと立てにくいですが、S3標準だけのときよりも安くなる可能性が高いのでS3標準だけ使った時の料金で算出しておけば大外しはしないでしょう。
ただ、そうする場合は最初からIntelligent-Tieringに入れましょう！ S3標準にドカッと入れてあとからIntelligent-Tieringに移すと今度はライフサイクル移行リクエストコストがかかります！
Intelligent-Tieringへのライフサイクル移行リクエストは1000件あたり0.01USDと決してお安くないです。
-
Amazon S3 の料金
https://aws.amazon.com/jp/s3/pricing/ ↩ -
put-object -- AWS CLI Command Reference
https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/put-object.html ↩ -
Amazon S3 ストレージクラス
https://aws.amazon.com/jp/s3/storage-classes/ ↩ ↩2 -
S3 Express One Zone の違いとは
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/s3-express-differences.html ↩