はじめに

2025/6/25、26の2日間に渡りAWS Summit Japan 2025が開催されました。
私は25日の方に参加し、いくつかセッションを見てきました。

25日のセッションの中の一つに「クラウドストレージのコスト最適化戦略－AWSストレージの賢い活用法」があり、S3とEBSのコスト管理について改めて勉強になったためこちらに記載します！

人がいっぱいだった

セッション概要

タイトル：クラウドストレージのコスト最適化戦略－AWSストレージの賢い活用法
内容：S3、EBSのコストを最適化する実践的なアプローチ
　　　システム運用の改善を加速させる転換のヒント

S3、EBSのコスト最適化をしたいけど

始めに前置きとして、こちらのお話がありました。
確かに、そうだな・・(∵)と思いながら聞いていました。

EC2、RDSのコスト最適化は、最適化する方法のイメージがわきやすい
(Savings Plansやリザーブドインスタンス、様々なインスタンスタイプを選択できるなど)

しかし、S3、EBSのコスト最適化に関しては下記のような理由で後回しになってしまうことが多々ある

データに対する漠然とした不安
可視性の欠如(データの使用頻度がわからない)
運用負荷への懸念
そもそもコスト最適化の手法がわからない
とりあえずS3 Standardを選ぶ→それ以降何もしない

→そして、データ量、費用が日々増え続けてしまうことがある

S3のコスト最適化

S3のコスト最適化方法は２つのデータのパターン別に考えられると紹介していました。

①アクセスパターンが既知または予測できるデータ

こちらの場合、利用頻度が少なくなるにつれてコストの低いクラスへ移行することが大切で、ストレージクラス別にどのくらいコスト削減ができるかのお話もありました。

ストレージクラスの移行方法として、S3ライフサイクルの紹介がありました。

ライフサイクルルールを作成して、指定した期間が過ぎたら他のストレージクラスへ移行
指定した期間が過ぎたらオブジェクトを削除

といった設定をすることがコスト最適化に繋がります。

しかし、

ライフサイクルルールで経過時間に基づいて何でもオブジェクトを移行させればコストが安くなるという訳ではない
移行時に発生する移行コストはオブジェクトの個数単位であってサイズは関係ない

とお話がありました。
そうなの？と思っていた所、具体的な説明がありました。

S3 Standardに下記のオブジェクトがあったとして、
1000万個の40KB未満のオブジェクト
100万個の200KB未満のオブジェクト
10万個の10MB以上のオブジェクト

これらをGlacier Flexible Retrievalに移行すると、
ストレージコストの差分が移行コストを相殺するのに15カ月かかるそうです。

そしてこれがもし、
100万個の200KB未満のオブジェクト
10万個の10MB以上のオブジェクト
であれば、ストレージコストの差分が移行コストを相殺するのに4カ月、

また、
10万個の10MB以上のオブジェクト
であれば、ストレージコストの差分が移行コストを相殺するのに2カ月との事でした。

サイズより個数が重要
一時的に発生する移行コストを無駄なく設計する事が大事
(何でも移行すれば良いという訳ではない)
オブジェクトサイズフィルターを使用して〇〇KB以上の物だけ移行するといった設定を活用する

②アクセスパターンが不明または変化しているデータ

こちらの場合はS3 Intelligent-Tieringが有用とお話がありました。

上記に記載の通りですが、S3 Intelligent-Tieringは基本的に3つのアクセス階層があります。
・高頻度アクセス階層
・低頻度アクセス階層
・アーカイブインスタントアクセス階層

基本的な3つの階層の仕組みは、
オブジェクトを新規アップロードすると、まず高頻度アクセス階層に保存される
↓
30日連続でアクセスがないオブジェクトは、自動的に低頻度アクセス階層へ移動
ストレージコストが最大45%削減される
↓
さらに60日アクセスがないオブジェクトは、自動的にアーカイブインスタントアクセス階層へ移動
ストレージコストが最大80%削減される
となり、自動的にコストを削減してくれます。

また、3つともオブジェクトの取り出し料金はかからず、
S3 Standardと同じパフォーマンスを備えているという点も良いなと思いました。

またオプションでアーカイブ機能を備えた2つの階層があります。
・アーカイブアクセス階層
・ディープアーカイブアクセス階層
これらも有効にすると最大92%コスト削減が可能になるそうです。

参考：S3 Intelligent-Tiering の仕組み

S3の利用状況を確認するには

2つのS3コスト最適化方法の紹介の後に、
使用しているS3の以下のことを把握していますか？とお話がありました。

データのサイズ、個数
予測できるアクセスパターンなのか、変化するアクセスパターンなのか

改善をするためには測定が必要ということで、
S3 Storage Lens、ストレージクラス分析の紹介がありました。

Storage Lens
S3のコンソールから確認できるダッシュボード
最も容量を使用しているバケットや、バケット毎のオブジェクト数など組織全体のS3使用状況が確認できる

ストレージクラス分析
バケットのレポートを作成できる機能で、レポートでオブジェクトの経過日グループ別にストレージの容量や、データ取り出し量が確認できる。
n日経過したらあまり使用されなくなっているため、よりコストの低いストレージクラスに移行しようといった分析ができる機能 (参考)

この2つは、使いこなせたら便利だな～と思いました( ..)φ

EBSのコスト最適化

次に、EBSコスト最適化のお話がありました。
EBSでよくある課題として、下記が挙げられていました。

オンプレからリフト&シフトした。本来必要なデータ容量より大きく、
とりあえずオンプレ時代と同じ容量を設定した
→コストメリットが感じられていない
運用フェーズで使っていないボリューム、スナップショットが出てきたけど管理しきれていない

ちょっと心当たりがある気が|ω・)

EBSのコスト最適化については、SSD、HDDそれぞれで説明がありました。

汎用SSDボリューム

旧世代のgp2よりgp3の方がコスト、パフォーマンス共に優れているため、
gp2がもし残っていたら積極的にgp3への変更を検討することを推奨

プロビジョンドiopsボリューム

こちらも汎用SSDと同じく、旧世代(io1)よりio2の方がコスト、パフォーマンス共に優れているため、io1がもし残っていたら積極的にio2への変更を検討することを推奨

HDDボリューム

HDDボリュームに関しては、新旧比較ではありませんでした。

st1
・頻繁にアクセスされるワークロード向け
・データ量が多い、容量を多く必要とするけどスペックではSSDが必要でない場合に
　コスト面で優れている
・gp3と比較し、最大44%コスト削減できる

sc1
・最もコストが低いディスクタイプ
・アクセス頻度が低く、低コストであることを重視される場合に適している
・gp3と比較し、最大81%コスト削減できる

EBSのバックアップ管理

EBSバックアップのサービスとしてこちらの2つが紹介されていました。

Data Lifecycle Manager
EC2、EBSと同じ画面群から使える機能
EBSボリュームをバックアップするためスナップショット作成 → 保存 → 削除の
ライフサイクルを自動化できる

AWS Backup
EBS以外にもFSxなど複数のストレージのバックアップを一元管理できる

両方ともポリシーベースでスナップショットの作成、保存、削除の管理が可能ですが、
どちらが優れているという訳ではなく、一元管理をした方が楽である等、各自のワークロードに沿って検討することを推奨されていました。

Elastic Volumes

EBSコスト最適化の重要な機能としてElastic Volumesの紹介もありました。
実際の使用状況に応じてEBSの容量やボリュームタイプを変更できるため、
例えば要求の少ないワークロードの場合、最初は低価格のボリュームを使用し、
需要が高まったら高性能のボリュームに変更するといった方法でコスト最適化を図ることができるとの事でした。

EBSのコスト最適化管理に適したサービス

EBSのコスト最適化管理に適したサービスとして、
Cost Optimization Hub、Trusted Advisorの紹介がありました。
こちらのスライドに記載のそれぞれの利点についてお話されていました。
これも使いこなせたら便利ですね( ..)φ

ストレージのパフォーマンスがコストに及ぼす影響

昨今は高価なコンピューティングリソースを使用するパターンも多く
(データレイクや機械学習用のGPUなど)、
この高価な処理でストレージのパフォーマンスがボトルネックになるとワークロードが完了するのに時間がかかり、コンピューティングがアイドル状態になる→コンピューティングリソースのコストを増やしてしまうといった事があるそうです。

S3のリクエストのパフォーマンスがワークロードの遅延と関係し、
コストに影響が出ることについてのお話がありました。

クライアントがS3にGETリクエストを送信した時、2つのパートがあり、
(下記の図の棒の白い部分と、色がついた部分)

白部分＝データの最初のバイトがクライアントに到達するまでのオーバーヘッド時間
　　　　(接続、認証、ディスクへのアクセスなど)
色がついた部分＝実際のデータ転送が行われる2番目のパート

白部分(オーバーヘッド)を小さくすると、レイテンシーの改善が期待できるのですが、
このオーバーヘッドに影響する要因にオブジェクトのサイズが関係しているそうです。

下記のSmall requestとLarge requestを見比べてみると、
小さいオブジェクトのリクエストほどオーバーヘッドの部分が大きく、
ワークロードを遅くさせる要因となるそうです。

しかし単純にファイルサイズを大きくするという事もできない場合もあり、
解決方法のひとつとしてS3 Express one zoneの紹介がありました。
オーバーヘッドが大幅に改善され、リクエスト全体のパフォーマンスが改善されるそうです。

EBSに関しては、パフォーマンスを重視するのであればio2！とお話がありました。

gp3は99%の確率で1桁ミリ秒のレイテンシー
io2は99.999%の確率で1桁ミリ秒のレイテンシー
パフォーマンス重視するならio2！とのことでした。

また、昨年末のre:InventでEBSの詳細なパフォーマンス統計が発表され、
ボリュームのパフォーマンスを1秒単位でリアルタイムに確認できるようになり、
ボトルネックを特定しやすくなったそうです。

まとめ

このセッションの最後に、システムは作って終わりではなく長い運用の始まり、
日々の運用改善が重要とお話がありました。
削減できる部分は削減、投資する所にはしっかり投資することが大事と聞き、本当にそうだなぁと思いました。
また、S3とEBSのコスト削減というと、とりあえず不要な物を削除・・と思っていましたが、まだまだ色々考慮できる事があるんだなと改めて勉強になりました( ..)φ