こちらはHubble Advent Calendar 2025の3日目の記事です。
はじめに
株式会社HubbleでSREを担当している @krabbe16 です。
プロダクトの成長に伴いS3のストレージコストが増加していく中で、バックアップ用途のS3バケットに対してストレージクラスの最適化を実施しました。本記事ではS3バケットのレプリケーション設定の変更とライフサイクルルールの追加を行うことで、ストレージコストの約80%を削減した取り組みについて紹介します。
課題
ユーザー数の増加に伴うストレージコストの増加
弊社ではアプリケーションで扱うドキュメントファイルをS3で管理しています。プロダクトの成長とユーザー数の増加に伴い、ストレージ使用量が1年間で倍増し数十TBに達していました。現在のインフラ構成ではメインリージョンのS3バケットを別リージョンのS3バケットにレプリケーションしてバックアップを取っており、レプリケーション先のS3バケットのストレージクラスはデフォルトのStandardが設定されていました。
バージョニング設定によるオブジェクト数の増加
レプリケーション先のS3バケットではオブジェクトのバージョニング機能が有効化されていました。オブジェクトの更新時に古いバージョンが非現行バージョンとして保存されるため、現行バージョンと非現行バージョンのオブジェクトに対してコストが発生している状態でした。
対策
オブジェクトのストレージクラスの変更
レプリケーション先のS3バケットはバックアップ用途のため以下の特徴があります。
- 通常はバックアップしたオブジェクトにアクセスする機会はほとんどない
- 万が一の事態が発生した場合にはバックアップしたオブジェクトをすぐに取り出せる必要がある
S3には複数のストレージクラスが用意されていますが、上記の要件に対応できるものを選択する必要がありました。Glacier Flexible RetrievalやGlacier Deep Archiveなどはオブジェクトの取り出しに数時間から数日かかるため要件を満たしませんでした。検討の結果、Standardと比較してストレージコストが低く、即時取り出しが可能なGlacier Instant Retrievalを選択しました。
レプリケーション設定の変更とライフサイクルルールの追加
レプリケーション設定のみを変更した場合、新規作成されるオブジェクトのストレージクラスはGlacier Instant Retrievalに変更されますが、すでに存在するオブジェクトのストレージクラスは変更されずStandardのままです。
また、レプリケーション先のS3バケットはバージョニング機能が有効化されているため、オブジェクトの現行バージョンと非現行バージョンの両方のストレージクラスを変更する必要がありました。そのため、今回は以下の2つのアプローチを組み合わせて対応しました。
- 既存のレプリケーション設定を変更し、レプリケーション先のS3バケットに新規作成されるオブジェクトのストレージクラスを変更する（これからレプリケーションされるオブジェクトへの対応）
- 新規のライフサイクルルールを追加し、レプリケーション先のS3バケットにすでに存在するオブジェクトのストレージクラスを変更する（すでにレプリケーションされたオブジェクトへの対応）
成果
レプリケーション先のS3バケットのストレージクラスをStandardからGlacier Instant Retrievalへ変更したことにより、ストレージコストを約80%削減することができました。
ただし、S3バケットにすでに存在していた数千万個のオブジェクトのストレージクラスを変更する際に一時的な移行コストが発生しました。これはライフサイクルルールによってストレージクラスが変更される際に1回だけ発生するコストであり、今回の取り組みによる継続的なコスト削減効果により数ヶ月程度で回収できる計算でした。
おわりに
今回の取り組みでバックアップ用途のS3バケットのストレージコストを約80%削減することができました。この取り組みが少しでもご参考になりましたら幸いです。
明日は @yamaopanku さんです！