第 11 章 コストを最適化したアーキテクチャの設計（20%）
ストレージのコスト
この章で学ぶこと
- アクセスのオプション（リクエスタ支払いのバケットなど）
- AWS のコスト管理のサービス機能（コスト割り当てタグ、複数アカウントの請求）
- 適切なユースケースを伴うコスト管理ツール（Cost Explorer、AWS Budgets、Cost and Usage Report）
- バックアップ戦略／データのライフサイクル／ストレージのアクセスパターン
- ブロックストレージのオプション（HDD・SSD のボリュームタイプ）
この章に出てくる用語
- リクエスタ支払い（Requester Pays）
- データを取り出す側が転送料を払う設定。 ふだんはバケットの持ち主が払うが、これを有効にすると、ダウンロードした人が自分のアカウントで払う。大きなデータセットを公開して配りたいが、転送料は負担したくないというときに使う。匿名アクセスは使えなくなる。
S3 には複数の保管クラスがあり、取り出しやすさと値段が逆の関係にある。設問は「どれくらいの頻度で読むか」「取り出しに何分待てるか」を書いてくる。
| クラス | 向く場面 | 最低保管期間 | 取り出し |
|---|---|---|---|
| S3 標準 | よく読む | 無し | すぐ |
| Intelligent-Tiering | 読む頻度が読めない | 無し | すぐ（階層により異なる） |
| 標準 − IA | たまに読むが、読むときはすぐ要る | 30 日 | すぐ（取り出し料あり） |
| 1 ゾーン − IA | 再作成できるデータ。1 つの AZ のみ | 30 日 | すぐ（取り出し料あり） |
| Glacier Instant Retrieval | めったに読まないが、読むならすぐ | 90 日 | ミリ秒 |
| Glacier Flexible Retrieval | めったに読まない。待てる | 90 日 | 数分〜数時間 |
| Glacier Deep Archive | ほぼ読まない。最も安い | 180 日 | 12 時間〜 |
試験では
最低保管期間より早く消すと、残り期間ぶんの料金が請求される。「30 日以内に消えるデータを標準 − IA に置く」という選択肢は、一見安そうに見えて逆に高くなる。この型は頻出。
補足
1 ゾーン − IA は 1 つの AZ にしか置かない。標準 − IA より 2 割ほど安いが、その AZ が失われるとデータも失われる。「再作成できる派生データ（サムネイル・変換結果）」のように消えても作り直せるものにだけ使う。
クラスを手で付け替えるのは現実的ではない。自動で移す仕組みが 2 つある。
| ライフサイクルルール | Intelligent-Tiering | |
|---|---|---|
| 決め方 | 日数で決める（30 日経ったら IA へ） | 実際のアクセスを見て自動で移す |
| 向く場面 | アクセスの傾向が分かっている | 読む頻度が読めない・ばらばら |
| 追加料金 | 無し（移行のリクエスト料はかかる） | オブジェクトごとの監視料 |
| 取り出し料 | クラスによる | 無し |
ライフサイクルには消すルールも書ける。期限切れの削除、古いバージョンの削除、未完了のマルチパートアップロードの後始末だ。
試験では
失敗したマルチパートアップロードの断片は、放っておくと課金され続ける。「身に覚えのない S3 の料金がある」という設問の答えがこれで、ライフサイクルで自動削除するルールを入れるのが対策。
| 手 | 効果 | 注意 |
|---|---|---|
| gp2 を gp3 に替える | 同じ性能でおよそ 2 割安い | 停止せずに変更できる |
| 順に読むだけのものを HDD（st1 / sc1）へ | 大きく下がる | ランダムアクセスには向かない |
| 使っていないボリュームを消す | 付けていなくても課金される | EC2 を終了してもボリュームが残ることがある |
| スナップショットを整理する | 増分とはいえ溜まる | Data Lifecycle Manager で自動化できる |
| 古いスナップショットをアーカイブ階層へ | さらに安くなる | 復元に時間がかかる |
補足
アタッチしていない Elastic IP には課金がある。EC2 を消したのに IP を解放し忘れている、という形で請求に残る。ストレージではないが、同じ「使っていないのに払っている」型として一緒に覚える。
| サービス | コストを下げる手 |
|---|---|
| Amazon EFS | ライフサイクル管理で IA クラスへ自動移動。1 ゾーンクラスを選ぶ |
| Amazon FSx | 必要な容量とスループットを見直す。デプロイタイプ（シングル AZ）を選ぶ |
| Amazon S3 | ストレージクラスとライフサイクル（前節） |
最後に、コスト管理の道具を役割で分ける。第 4 部のどの章でも同じ道具が出てくるので、ここでまとめて覚える。
| 道具 | 役割 | 使う場面 |
|---|---|---|
| AWS Cost Explorer | 見る | 過去の傾向をグラフで見る。将来の予測も出せる |
| AWS Budgets | 知らせる・止める | しきい値を超えたら通知。アクションを紐づけられる |
| Cost and Usage Report（CUR） | 明細 | 最も細かい行単位のデータ。分析は Athena などで |
| コスト割り当てタグ | 配分する | 部署・プロジェクトごとに費用を分ける |
| AWS Compute Optimizer | 適正化 | 過剰なインスタンスサイズを指摘する |
| AWS Trusted Advisor | 点検 | コスト・性能・セキュリティなどの定型チェック |
試験では
「予算を超えたら知らせたい」は Budgets、「どこにいくらかかったか見たい」は Cost Explorer、「明細を自分で分析したい」は CUR。3 つが選択肢に並ぶので、動詞（知らせる／見る／分析する）で選ぶ。
補足
複数アカウントを Organizations でまとめると、一括請求（Consolidated Billing）になる。使用量がアカウントをまたいで合算されるので、ボリューム割引やリザーブドインスタンスの割引が組織全体で効く（第 12 章）。
| 問題文に出る語 | 答えの方向 |
|---|---|
| アクセス頻度が読めない | S3 Intelligent-Tiering |
| 90 日後にはほとんど読まない | ライフサイクルで Glacier 系へ |
| ほぼ読まない・最も安く | Glacier Deep Archive |
| 再作成できる派生データ | 1 ゾーン − IA |
| 30 日以内に消えるデータ | 標準のまま（IA は最低保管期間で損をする） |
| 身に覚えのない S3 の料金 | 未完了のマルチパートアップロードを削除するルール |
| EBS を同じ性能で安く | gp2 → gp3 |
| 使っていないのに課金される | 未アタッチのボリューム・Elastic IP・古いスナップショット |
| 大きなデータを配りたいが転送料は払いたくない | リクエスタ支払い |
| 部署ごとに費用を分けたい | コスト割り当てタグ |
| 予算を超えたら知らせたい | AWS Budgets |
シナリオ演習
ログを S3 に保管している。直近 30 日はよく参照するが、それ以降はほとんど見ない。7 年間の保管が義務づけられている。
補足
答え：ライフサイクルルールで、30 日後に Glacier Flexible Retrieval、90 日後に Glacier Deep Archive へ移し、7 年後に削除する。
最初から Deep Archive に置くと、直近 30 日の参照に 12 時間かかってしまう。逆に標準のまま 7 年持つのは高い。
シナリオ演習
請求を見ると、どのバケットにも見当たらないストレージ料金が計上されている。
補足
答え：未完了のマルチパートアップロードの断片が残っている。ライフサイクルルールで自動削除を設定する。
失敗した分割アップロードの断片はオブジェクトとして一覧に出ないが、課金は続く。バージョニングの古い版も同様に見落としやすい。
この章のまとめ
- 読む頻度が読めないときの S3 クラス
- 標準 − IA と 1 ゾーン − IA の最低保管期間
- Glacier Flexible Retrieval の最低保管期間
- Glacier Deep Archive の最低保管期間
- 最低保管期間より早く消すとどうなるか
- 1 ゾーン − IA に置いてよいデータ
この章の根拠
最終確認 2026-10-04 ／ 対応バージョン DEA 2026-05-04 改訂版