アクセスパターン分析によるS3ストレージクラスのコスト最適化

こんにちは！バクラク事業部Platform Engineering部SREグループのtaddy( id:sadayoshi_tada )です。

バクラクではオブジェクトストレージとしてAmazon S3（以降、S3と呼称します）を使用しています。保存するオブジェクトの増加にともなってS3のコストが上昇したことを契機に、アクセスパターンにもとづいてオブジェクトのストレージクラスを見直しました。その過程で使ったS3のストレージクラス分析について、概要と設定手順、分析結果からストレージクラスの変更を行った後のコスト推移を本記事で紹介します。

• ストレージクラス分析の概要

ストレージクラス分析の設定手順

• 分析結果の見方

• アクセスパターン分析後のストレージクラス変更およびS3コスト推移

• 終わりに

お知らせ：AIカンファレンス「Bet AI Day 2026」を開催します！

ストレージクラス分析の概要

S3のコストを最適化するアプローチの1つに、アクセスパターンに応じてストレージクラスを変更することがあります。そのアクセスパターンを自動で収集してくれるのが、S3のストレージクラス分析（Storage Class Analysis）です。

docs.aws.amazon.com

ストレージクラス分析はバケット内のオブジェクトのアクセスパターンを観測し、S3 StandardからS3 Standard-IAへ移行してよい経過日数を提案してくれる機能です。

アクセス頻度はリクエスト数ではなく、バイト転送量ベースで判定されます。

主な特徴は以下のとおりです。

• 分析対象はS3 Standardの128KB超のオブジェクトのみ

• レコメンデーションはSTANDARDからSTANDARD_IAへの移行のみ

• 適用範囲はバケット全体、プレフィックス、オブジェクトタグから選べる（1バケットあたり最大1,000フィルタ）

• 日次のCSVエクスポートを別バケットに出力できる

なお、ストレージクラス分析にかかるコストは東京リージョンだと月間監視対象100万件に対して$0.10かかります。

aws.amazon.com

ストレージクラス分析の設定手順

設定の最小手順を記すと以下のようになります。

• 対象バケットを開き、「メトリクス」タブの「ストレージクラス分析」から「分析設定の作成」を選ぶ

• 設定名を入力し、適用範囲をバケット全体、プレフィックス、タグから選ぶ

• 任意で日次のCSVエクスポート先（S3バケットとプレフィックス）を指定する

• エクスポート先バケットに、S3が書き込めるバケットポリシーを付与する

エクスポート先バケットには以下のようなバケットポリシーが必要です。別アカウントのバケットも指定できますが、分析対象バケットと同一リージョンである必要があります。

{

"Version": "2012-10-17",

"Statement": [

{

"Sid": "AllowS3AnalyticsExport",

"Effect": "Allow",

"Principal": { "Service": "s3.amazonaws.com" },

"Action": "s3:PutObject",

"Resource": "arn:aws:s3:::[エクスポート先バケット]/[プレフィックス]/*",

"Condition": {

"ArnLike": {

"aws:SourceArn": "arn:aws:s3:::[分析対象バケット]"

},

"StringEquals": {

"aws:SourceAccount": "[AWSアカウント番号]",

"s3:x-amz-acl": "bucket-owner-full-control"

}

}

}

]

}

docs.aws.amazon.com

Terraformで管理する場合はaws_s3_bucket_analytics_configurationリソースを使います。以下は簡素な設定例ですが、バケット全体を分析対象にした設定になります。エクスポート先バケット（aws_s3_bucket.analytics）には、前述のバケットポリシーをaws_s3_bucket_policyで別途付与しておく必要があります。

output_schema_versionとformatは省略すると、それぞれデフォルトのV_1とCSVが使われます。

resource "aws_s3_bucket_analytics_configuration" "target-entire-bucket" {

bucket = aws_s3_bucket.target.id

name = "EntireBucket"

storage_class_analysis {

data_export {

destination {

s3_bucket_destination {

bucket_arn = aws_s3_bucket.analytics.arn

}

}

}

}

}

resource "aws_s3_bucket_policy" "analysis-bucket-policy" {

bucket = aws_s3_bucket.target.id

policy = jsonencode({

Version = "2012-10-17"

Statement = [

{

Sid = "AllowS3AnalyticsExport"

Effect = "Allow"

Principal = { Service = "s3.amazonaws.com" }

Action = "s3:PutObject"

Resource = "${aws_s3_bucket.analytics.arn}/*"

Condition = {

ArnLike = {

"aws:SourceArn" = aws_s3_bucket.target.arn

}

StringEquals = {

"aws:SourceAccount" = "[AWSアカウント番号]"

"s3:x-amz-acl" = "bucket-owner-full-control"

}

}

}

]

})

}

registry.terraform.io

設定後24〜48時間ほどでコンソールにデータが表示され始め、30日経過したころからレコメンデーションが得られるようになります。

分析結果の見方

CSVエクスポートを有効にすると、日次で以下のカラムを持つレコードがエクスポート先バケットに配信されます。以下レポートで出力されたカラムになります。

カラム

概要

Date

レコード処理日

ConfigId

分析設定名

Filter

フィルターフィールドは意図的に空の値になっている

StorageClass

対象ストレージクラス

ObjectAge

経過日数グループ（000-014、015-029等表示される）

ObjectCount

オブジェクト数

DataUploaded_MB

その日にアップロードされたデータ量（MB）

Storage_MB

グループ別の合計ストレージ（MB）

DataRetrieved_MB

GETで転送されたデータ量（MB）

GetRequestCount

GETリクエスト数

CumulativeAccessRatio

累積アクセス率（移行判定の基準）

ObjectAgeForSIATransition

STANDARD_IAへの移行のために監視された経過時間

RecommendedObjectAgeForSIATransition

STANDARD_IA移行のために考慮する必要があるオブジェクトの経過時間

サンプルとなりますが、CSVのレポート結果として以下のような項目ごとの数値が表示されます。

Date

StorageClass

ObjectAge

Storage_MB

DataRetrieved_MB

Cumulative

AccessRatio

Recommended

ObjectAgeFor

SIATransition

07-27-2026

STANDARD

000-014

51200.5

8450.2

4.25

07-27-2026

STANDARD

015-029

48300.0

2100.8

1.87

07-27-2026

STANDARD

030-044

45150.3

890.4

0.92

このレポートの情報から例えばObjectAge、CumulativeAccessRatioなどを見ながらバケットごとにアクセスパターン分析を行い、その結果からストレージクラスの変更を計画しました。

アクセスパターンの分析結果を踏まえ、まずはS3 Intelligent-Tieringへ移行したバケットのコスト推移をご紹介します。このストレージクラスはアクセス頻度に応じて自動的にストレージ階層を遷移するため、レスポンス速度を保ちながらコストを最適化できます。

ストレージクラス変更前の月を基準月とした場合、移行月は、S3 Intelligent-Tieringへの一括移行にかかるストレージクラス移行費が乗るため、コストは移行前より約58%ほど増えました。移行後は徐々にアクセス頻度が低いストレージ階層に遷移しており、移行前と比べて約36%の削減になりました。

imageストレージクラス変更前後のコスト推移のサマリ

その後もアクセスパターンの分析を継続しています。分析を続ける中で、S3 Intelligent-Tieringが常に最適とは限らないことも分かってきました。S3 Intelligent-Tieringはオブジェクト数に比例したモニタリング料金がかかるため、次のようなケースでは他の選択肢が有利になります。

• アクセスがほぼ発生しないと分かっているオブジェクトは自動階層化を待つよりライフサイクルルールで直接移行するほうが、モニタリング料金のぶん安くなります

• 128KB未満の小さいオブジェクトが大半を占めるバケットでは小さいオブジェクトは自動階層化の対象外で、高頻度アクセス階層の料金が課金され続けます

バクラクでもほぼアクセスされない期間に達したオブジェクトについてはS3 Intelligent-Tieringを使用せず、S3 Glacier Instant Retrievalへ移行しました。今後も状況を観測しながら、よりコスト効率の良いストレージクラスへの最適化を進めていきます。

終わりに

S3のストレージクラス分析の概要、設定手順、CSV出力の見方をまとめました。本記事がストレージクラスの見直しを検討している方の参考になれば幸いです。

お知らせ：AIカンファレンス「Bet AI Day 2026」を開催します！

AIは「使う」段階から「共に働く」段階へ。

2回目となる「Bet AI Day 2026」は "AIエージェントと働く未来に、Betしよう" のメッセージを軸に、LayerXにおけるAIエージェント活用の実践知などを余すことなく共有します。

昨年同様にオンラインでも開催しますので、全国どこからでも、PCやスマートフォンからお気軽にご視聴いただけます。AIエージェントと働く未来について興味のある方、ぜひ「Bet AI Day 2026」にご参加ください！

EVENT

AIカンファレンス「Bet AI Day 2026」開催概要

開催日時

2026年9月3日（木）12:00 開演

開催方法

オンライン配信

参加費用

無料（事前申込制）

connpass でお申し込み