概要
Amazon S3 には、データのアクセス頻度や取り出しにかけられる時間に合わせて選べる「ストレージクラス」が複数用意されています。毎日読み書きするデータと、監査のために何年も置いておくだけのデータを同じ料金体系で保存し続けると、保存コストが無駄にかさみます。
一方で、保存料金が安いストレージクラスほど、取り出し料金・最小保存期間・最小課金サイズといった条件が付きます。安さだけで選ぶと、かえって高くつくことがあります。また、オブジェクトごとに手作業でストレージクラスを切り替えるのは現実的ではないため、S3 には「作成から何日たったら移行する」「何日たったら削除する」を自動で行う S3 ライフサイクル が用意されています。
この記事では、S3 の主なストレージクラスの違いを比較表で整理したうえで、ストレージクラスを指定したアップロード、既存オブジェクトのストレージクラス変更、プレフィックスを絞ったライフサイクルルールの作成までを体験します。S3 の基本操作は Amazon S3 でバケットを作成しオブジェクトを管理する で扱っているので、あわせて参照してください。
クラウドおさる毎朝食べるバナナと、長老会が非常時に備えて蓄えるバナナを、同じ倉庫に置いておくのはもったいないでござる。この記事では、S3 で置き場所を使い分けて保存コストを下げる方法を確かめるのでござる。
この記事のメリット
- S3 の主なストレージクラス（Standard / Intelligent-Tiering / Standard-IA / One Zone-IA / Glacier Instant Retrieval / Glacier Flexible Retrieval / Glacier Deep Archive）の違いを比較表で把握できる
- 最小保存期間・最小課金サイズ・取り出し料金など、保存料金以外にかかるコストの考え方を理解できる
- Glacier Flexible Retrieval / Deep Archive の復元（取り出し）オプションと所要時間の目安を把握できる
- ライフサイクルルールの「移行」と「有効期限」の役割と、設定時の制約を理解できる
- コンソールからストレージクラスの指定・変更とライフサイクルルールの作成を体験できる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
ストレージクラスとは
クラウドおさるとひさん、S3 にはストレージクラスというものがたくさんあると聞いたでござる。そもそも、ストレージクラスとは何でござるか？
土肥ストレージクラスは、オブジェクトを「どんな条件で保存するか」の種類だよ。オブジェクト 1 つ 1 つに設定する属性で、アクセス頻度や取り出しの速さ、保存するアベイラビリティーゾーン（AZ）の数によって保存料金が変わるんだ。アップロードするときに何も指定しなければ、デフォルトの S3 Standard になるよ。
クラウドおさるバケットごとではなく、オブジェクトごとに決めるのでござるか。
土肥そうそう。同じバケットの中に、Standard のオブジェクトと Glacier のオブジェクトを混在させられるんだ。主なストレージクラスを比べるとこうなるよ。耐久性はどれも 99.999999999%（イレブンナイン）で同じなんだ。
| ストレージクラス | 想定するアクセス頻度 | 最初の 1 バイトまで | 可用性 | AZ 数 | 最小保存期間 | 最小課金サイズ | 取り出し料金 |
|---|---|---|---|---|---|---|---|
| S3 Standard | 頻繁（月 2 回以上） | ミリ秒 | 99.99% | 3 以上 | なし | なし | なし |
| S3 Intelligent-Tiering | 不明・変化する | ミリ秒（※1） | 99.9% | 3 以上 | なし | なし | なし（オブジェクトごとのモニタリング料金あり） |
| S3 Standard-IA | 低頻度（月 1 回程度） | ミリ秒 | 99.9% | 3 以上 | 30 日 | 128 KB | GB 単位で発生 |
| S3 One Zone-IA | 低頻度・再作成可能なデータ | ミリ秒 | 99.5% | 1 | 30 日 | 128 KB | GB 単位で発生 |
| S3 Glacier Instant Retrieval | 四半期に 1 回程度のアーカイブ | ミリ秒 | 99.9% | 3 以上 | 90 日 | 128 KB | GB 単位で発生 |
| S3 Glacier Flexible Retrieval | 年 1 回程度のアーカイブ | 数分〜数時間（復元が必要） | 99.99%（復元後） | 3 以上 | 90 日 | なし（※2） | GB 単位で発生 |
| S3 Glacier Deep Archive | 年 1 回未満のアーカイブ | 数時間（復元が必要） | 99.99%（復元後） | 3 以上 | 180 日 | なし（※2） | GB 単位で発生 |
※1 オプションのアーカイブアクセス階層・ディープアーカイブアクセス階層を有効にした場合、その階層に移ったオブジェクトは復元が必要です。 ※2 アーカイブしたオブジェクトごとに、メタデータ用として 40 KB（Glacier / Deep Archive の料金で 32 KB、Standard の料金で 8 KB）が追加で課金されます。
クラウドおさる下に行くほど保存は安くなる代わりに、「最低何日分は払う」「取り出すときにもバナナが要る」という条件が増えていくのでござるな！
土肥その通り！ 保存料金だけを見て Glacier 系を選ぶと、頻繁に取り出したときの取り出し料金や、すぐ消したときの最小保存期間分の料金で、結局 Standard より高くなることもあるんだ。
最小保存期間と最小課金サイズ
クラウドおさる「最小保存期間」と「最小課金サイズ」は、具体的にはどういうことでござる？
土肥最小保存期間は「最低これだけの日数分は保存料金がかかる」という決まりだよ。例えば Standard-IA は 30 日だから、10 日で削除しても 30 日分の料金がかかる。Glacier Instant Retrieval と Glacier Flexible Retrieval は 90 日、Deep Archive は 180 日だね。期間内に削除・上書きしたり、別のクラスへ移したりすると、残りの日数分が課金されるんだ。
土肥最小課金サイズのほうは、Standard-IA、One Zone-IA、Glacier Instant Retrieval で 128 KB。1 KB のファイルでも 128 KB として課金されるんだよ。
クラウドおさる小さなファイルをたくさん IA に置くと、実際の大きさより多く払うことになるのでござるな……。猿山の倉庫で、豆粒みたいなバナナ 1 本にも棚 1 段分の家賃を取られるようなものでござる。
土肥うまい例えだね。だから小さいオブジェクトが大量にある場合は、Standard のままにするか、まとめて大きなファイルにしてからアーカイブするのが定番なんだ。
S3 Intelligent-Tiering
クラウドおさるアクセス頻度が読めないデータは、どれを選べばよいのでござるか？
土肥そういうときは S3 Intelligent-Tiering だよ。オブジェクトへのアクセスを S3 が見ていて、30 日間連続でアクセスがなければ低頻度アクセス階層へ、90 日間連続でなければアーカイブインスタントアクセス階層へ自動で移してくれるんだ。アクセスがあれば高頻度アクセス階層に戻る。取り出し料金はかからない代わりに、オブジェクトごとに少額のモニタリング・オートメーション料金がかかるよ。
土肥ただし 128 KB 未満のオブジェクトはモニタリングの対象外で、ずっと高頻度アクセス階層に置かれるんだ。
クラウドおさる当番猿が毎日倉庫を見回って、しばらく誰も手を付けていないバナナを奥の棚へ移してくれるのでござるな！
One Zone-IA を選ぶときの注意
クラウドおさるOne Zone-IA は、Standard-IA よりさらに安いのでござるよな。何か落とし穴はあるのでござるか？
土肥One Zone-IA はデータを 1 つの AZ にしか保存しないんだ。その AZ が災害などで失われると、データも失われてしまう。だから「失っても再作成できるデータ」や、別リージョンに複製してあるデータのコピー向けなんだよ。替えのきかない原本を置く場所ではないね。
クラウドおさる安いからといって、大事な記録を One Zone-IA に置いてはならぬのでござるな。
Glacier からの取り出し（復元）
クラウドおさるGlacier Flexible Retrieval と Deep Archive は「復元が必要」とあったでござる。すぐにはダウンロードできないのでござるか？
土肥そうなんだ。この 2 つに置いたオブジェクトはリアルタイムでは読めなくて、まず「復元」をリクエストして一時コピーを作る必要があるんだ。一時コピーは指定した日数だけ使えて、期限が来ると消える。元のオブジェクトはアーカイブされたまま残るよ。復元にかかる時間は、取り出しオプションで変わるんだ。
| 取り出しオプション | Glacier Flexible Retrieval | Glacier Deep Archive |
|---|---|---|
| 迅速 | 1〜5 分 | 利用不可 |
| 標準 | 3〜5 時間 | 12 時間以内 |
| 大容量 | 5〜12 時間 | 48 時間以内 |
土肥ちなみに Glacier Instant Retrieval は名前のとおり、Standard と同じようにミリ秒で読めるよ。「アーカイブだけど、たまにすぐ読みたい」ならこちらだね。
クラウドおさる「Instant はすぐ読める、Flexible と Deep Archive は復元を待つ」と覚えておけばよいのでござるな。
ライフサイクルルール（移行と有効期限）
クラウドおさるオブジェクトごとにストレージクラスを手で変えるのは大変でござる。自動で移してくれる仕組みはあるのでござるか？
土肥それが S3 ライフサイクル だよ。バケットにライフサイクルルールを設定すると、条件に合うオブジェクトに対して S3 が自動でアクションを実行してくれるんだ。アクションは大きく 2 種類あるよ。
| アクション | 内容 | 例 |
|---|---|---|
| 移行（Transition） | 指定した日数がたったら、別のストレージクラスへ移す | 作成 30 日後に Standard-IA へ、90 日後に Glacier Flexible Retrieval へ |
| 有効期限（Expiration） | 指定した日数がたったら、オブジェクトを期限切れ（削除）にする | 作成 365 日後に削除 |
土肥ルールの対象は、バケット全体にもできるし、プレフィックス（logs/ のようなキーの先頭）やタグ、オブジェクトサイズで絞り込むこともできるんだ。設定は既存のオブジェクトにも、あとから追加されるオブジェクトにも効くよ。
クラウドおさるバージョニングを有効にしたバケットだと、古いバージョンはどうなるのでござる？
土肥いいところに気づいたね！ バージョニングが有効なバケットでは、「現在のバージョン」と「以前のバージョン（最新でないバージョン）」に別々のアクションを設定できるんだ。現在のバージョンの有効期限は、オブジェクトを完全に消すのではなく削除マーカーを付ける動きになる。以前のバージョンを本当に消したいときは、「最新でなくなってから何日後に完全に削除する」というアクションを別に設定するんだよ。
クラウドおさる長老会が「収穫から 1 か月たったら奥の倉庫へ、3 か月たったら山の上の貯蔵庫へ、1 年たったら処分」と決まりを作っておけば、当番猿が毎日そのとおりに動いてくれるようなものでござるな！
ライフサイクルの移行で気を付けること
クラウドおさるどのクラスからどのクラスへでも、自由に移せるのでござるか？
土肥ライフサイクルの移行は「ウォーターフォール（滝）」のように、基本的に上から下への一方通行なんだ。例えば Standard から Standard-IA や Glacier 系へは移せるけど、Glacier Flexible Retrieval から移行できるのは Deep Archive だけ。Deep Archive から別のクラスへは移行できない。上のクラスに戻したいときは、復元して一時コピーを作ってから、ストレージクラスを指定してコピーし直す必要があるよ。ほかにも、こんな制約があるんだ。
| 制約 | 内容 |
|---|---|
| 128 KB 未満は移行しない | 128 KB 未満のオブジェクトは、デフォルトではどのストレージクラスにも移行されない（移行リクエストの料金が節約額を上回りやすいため）。オブジェクトサイズフィルターで変更できる |
| 最小保存期間をまたぐ移行 | 1 つのルールの中で、移行先クラスの最小保存期間が過ぎる前に次のクラスへ移す設定はできない（例: 4 日後に Glacier Instant Retrieval、20 日後に Deep Archive は不可。少なくとも 94 日後にする） |
| 移行リクエスト料金 | 移行はオブジェクトごとにリクエスト料金がかかる。小さなオブジェクトが大量にあると割高になる |
| 実行タイミング | ルールの条件を満たしてから実際に移行・削除されるまで遅れることがある。ただし請求は条件を満たした時点から変わる |
クラウドおさる「下へは流せるが、上へは自力で戻せない」「小さいものはそもそも流れない」でござるな。ルールを作る前に、移した先の最小保存期間も確かめておくのでござる。
実践
ここでは、バージョニングを有効にした S3 バケットを作成し、ストレージクラスを指定したアップロード、既存オブジェクトのストレージクラス変更、logs/ プレフィックスに絞ったライフサイクルルールの作成と確認を行います。
ライフサイクルによる移行・削除は日単位で実行されるため、この実践ではルールが正しく設定されたことの確認までを行い、実際に移行されるのを待つ手順は扱いません。また、Glacier Flexible Retrieval / Deep Archive からの復元は時間と料金がかかるため、技術解説での説明に留めます。
前提条件
- リージョン:
ap-northeast-1（東京） - AWS マネジメントコンソールにログイン済みで、S3 バケットの作成・ライフサイクル設定の権限を持っていること
- アップロード用の小さなテキストファイルを 2 つ手元に用意しておくこと（例:
access.log、report.txt。中身は任意の数行で構いません）
作成するリソース一覧
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| S3 バケット | s3-storage-class-lab-<アカウントID> | ハンズオン用バケット（バージョニング有効） |
| S3 オブジェクト | archive/report.txt | アップロード時にストレージクラスを指定する例 |
| S3 オブジェクト | logs/access.log | アップロード後にストレージクラスを変更する例 |
| ライフサイクルルール | logs-lifecycle | logs/ 配下の移行・有効期限・以前のバージョンの削除 |
バケットを作成する
- AWS マネジメントコンソールにログインし、リージョンが
ap-northeast-1（東京）であることを確認します - 上部の検索バーに
S3と入力し、表示された「S3」を選択します - 左側ナビゲーションの「汎用バケット」を選択し、「バケットを作成」をクリックします
- 以下を設定します
- バケット名:
s3-storage-class-lab-<アカウントID>（例:s3-storage-class-lab-123456789012） - バケットのバージョニング:
有効にする - その他の項目はデフォルトのままにします
- ページ下部の「バケットを作成」をクリックします
バケット一覧に s3-storage-class-lab-<アカウントID> が表示されれば作成完了です。
ストレージクラスを指定してアップロードする
アップロード時にストレージクラスを指定しないと S3 Standard になります。ここでは、アーカイブ用のファイルを最初から S3 Glacier Instant Retrieval に置きます。
- バケット一覧から
s3-storage-class-lab-<アカウントID>をクリックして開きます - 「フォルダの作成」をクリックし、フォルダ名に
archiveと入力して「フォルダの作成」をクリックします - 同じ手順で
logsフォルダも作成します archive/フォルダをクリックして開き、「アップロード」をクリックします- 「ファイルを追加」をクリックし、
report.txtを選択します - 下部の「プロパティ」セクションを展開し、「ストレージクラス」で
Glacier Instant Retrievalを選択します - 一覧には「低冗長化」も表示されますが、画面上でも推奨されていないクラスのため、本記事では扱いません
- 「アップロード」をクリックします
アップロードが完了したら「閉じる」をクリックします。
続いて、logs/ フォルダに access.log をアップロードします。こちらはストレージクラスを指定せずにアップロードします。
- バケットのトップに戻って
logs/フォルダをクリックして開き、「アップロード」をクリックします - 「ファイルを追加」をクリックし、
access.logを選択します - 「プロパティ」のストレージクラスは変更せず、「アップロード」をクリックします
- アップロードが完了したら「閉じる」をクリックします
archive/ と logs/ のオブジェクト一覧で、「ストレージクラス」列を確認します。report.txt は Glacier Instant Retrieval、access.log は スタンダード（S3 Standard）になっていることが確認できます。
既存オブジェクトのストレージクラスを変更する
アップロード済みの logs/access.log を、S3 Standard-IA に変更します。
logs/のオブジェクト一覧でaccess.logのチェックボックスを選択します- 「アクション」をクリックし、表示されたメニューから「ストレージクラスを編集する」を選択します
- 「ストレージクラス」の一覧で
標準 - IAを選択します - 「その他のコピー設定」は
ソース設定をコピー（デフォルト）のままにします - 「変更の保存」をクリックします
完了画面で「閉じる」をクリックし、logs/ のオブジェクト一覧に戻ります。access.log のストレージクラスが 標準 - IA に変わっていることを確認します。
コンソールでのストレージクラスの変更は、オブジェクトを新しいストレージクラスで同じ場所にコピーする操作です。そのため、バージョニングが有効なバケットでは新しいバージョンが作られます。オブジェクト一覧上部の「バージョンの表示」をオンにすると、access.log に 2 つのバージョンがあり、現在のバージョンが 標準 - IA、以前のバージョンが スタンダード のまま残っていることが確認できます。
この以前のバージョンも保存料金の対象です。次のライフサイクルルールで、以前のバージョンを自動で削除する設定を入れます。確認できたら「バージョンの表示」をオフに戻します。
クラウドおさるreport.txt は Glacier Instant Retrieval、access.log は標準 – IA に置いたでござる。どちらも最小保存期間があるので、ハンズオンのあとすぐ消しても 90 日分・30 日分の料金はかかるのでござる。小さなファイルでも最小課金サイズの 128 KB として数えられるので、試すファイルは小さく、少なくしておくのが安心でござるよ。
ライフサイクルルールを作成する
logs/ プレフィックスのオブジェクトだけを対象に、次の内容のルールを作成します。
| アクション | 設定値 |
|---|---|
| 現在のバージョンを移行 | 作成から 30 日後に 標準 - IA、90 日後に Glacier Flexible Retrieval |
| 現在のバージョンを期限切れにする | 作成から 365 日後 |
| 以前のバージョンを完全に削除 | 最新でなくなってから 30 日後 |
- バケットのトップに戻り、「管理」タブを選択します
- 「ライフサイクルルール」セクションの「ライフサイクルルールを作成する」をクリックします
- 以下を設定します
- ライフサイクルルール名:
logs-lifecycle - ルールスコープを選択:
1 つ以上のフィルターを使用してこのルールのスコープを制限する - プレフィックス:
logs/
- 「ライフサイクルルールのアクション」で、以下の 3 つにチェックを入れます
現行バージョンのオブジェクトをストレージクラス間で移行するオブジェクトの現行バージョンを有効期限切れにするオブジェクトの非現行バージョンを完全に削除- 「現行バージョンのオブジェクトをストレージクラス間で移行する」にチェックを入れると、移行コストに関する確認のチェックボックスが表示されます。内容を確認してチェックを入れます
- 「オブジェクトの現行バージョンをストレージクラス間で移行する」で、以下を設定します
- ストレージクラスの移行を選択:
標準 - IA、オブジェクト作成後の日数:30 - 「移行を追加する」をクリックし、ストレージクラスの移行を選択:
Glacier Flexible Retrieval (旧 Glacier)、オブジェクト作成後の日数:90 - 「オブジェクトの現行バージョンの有効期限が切れる」で、オブジェクト作成後の日数に
365を入力します - 「オブジェクトの非現行バージョンを完全に削除」で、オブジェクトが現行バージョンでなくなってからの日数に
30を入力します - その他の項目はデフォルトのままにします
画面下部の「移行と有効期限切れのアクションを確認」に、設定したアクションが「最新バージョンのアクション」「非現行バージョンのアクション」に分かれて時系列で表示されます。日数とストレージクラスが表の内容どおりになっていることを確認します。
- 「ルールの作成」をクリックします
作成したルールを確認する
「管理」タブの「ライフサイクルルール」に logs-lifecycle が表示され、ステータスが Enabled、スコープが フィルタリング済み（プレフィックスで絞り込んだルール）になっていることを確認します。「最新バージョンのアクション」列には標準 – IA・Glacier Flexible Retrieval への移行と有効期限、「非現行バージョンのアクション」列には完全な削除が表示されます。
このルールは logs/ で始まるオブジェクトにだけ適用されるため、archive/report.txt は対象外です。なお、今回アップロードした access.log は 128 KB 未満なので、デフォルトの動作ではストレージクラスの移行の対象になりません。一方、有効期限と以前のバージョンの削除はサイズに関係なく適用されます。
クラウドおさる移行は日数がたつのを待たないと目に見えぬでござるが、ルールのタイムラインを見れば「いつ、どこへ流れるか」は確かめられるのでござる。実際の運用では、移行先の最小保存期間と 128 KB の線引きを先に確かめてからルールを書くのでござるな。
まとめ
- S3 のストレージクラスはオブジェクトごとに設定し、指定しなければ S3 Standard になる
- 下位のクラスほど保存料金は下がるが、最小保存期間（Standard-IA / One Zone-IA は 30 日、Glacier Instant Retrieval / Flexible Retrieval は 90 日、Deep Archive は 180 日）、最小課金サイズ（IA 系と Glacier Instant Retrieval は 128 KB）、取り出し料金が加わる
- アクセスパターンが読めないデータには、取り出し料金がかからず自動で階層を移す S3 Intelligent-Tiering が向いている
- One Zone-IA は単一 AZ に保存するため、再作成できるデータ向けである
- Glacier Flexible Retrieval と Deep Archive は読む前に復元が必要で、取り出しオプションにより数分〜48 時間かかる。Glacier Instant Retrieval はミリ秒で読める
- ライフサイクルルールの「移行」で日数に応じてストレージクラスを移し、「有効期限」で削除できる。プレフィックスやタグで対象を絞れる
- バージョニングが有効なバケットでは、現在のバージョンの有効期限は削除マーカーの追加になる。以前のバージョンは別のアクションで完全に削除する
- ライフサイクルの移行は上から下への一方通行で、128 KB 未満のオブジェクトはデフォルトで移行されない
関連する記事として、バケット名の命名方式を扱った S3 アカウントリージョナル名前空間 ── バケット名の乗っ取りを防ぐ新しい命名方式 もあわせて参照してください。
参照先
- Amazon S3 ストレージクラスの理解と管理
- オブジェクトのストレージクラスを設定
- S3 Intelligent-Tiering の仕組み
- アーカイブ取得オプションを理解する
- Amazon S3 ライフサイクルを使用したオブジェクトの移行
- オブジェクトの有効期限
- バケットに S3 ライフサイクル設定を設定する
- バージョニングが有効なバケットへのオブジェクトの追加
