はじめに
2025年10月22日に、Amazon S3 Metadataが東京リージョンを含む追加3リージョンでGA(一般提供)となったことが発表されました。これにより、国内の多くの企業でデータの保管先としているであろう東京リージョンのS3バケットにおいても、保存されているオブジェクトのメタデータの扱いがより容易となりました。
本記事では、東京リージョンにもやってきたS3 Metadataとはどんなものか、また簡単な使用感をまとめます。
S3 Metadataとは
S3 Metadataがいつ登場し、どんなものであるか整理しましょう。
登場
re:Invent 2025も終わった今更の話題となりますが、S3 Metadataはその前年のre:Invent 2024でプレビュー版の公開が発表されました。この年のre:Inventでは、同時にS3 Tables、S3 Vectorsも発表されており、S3のバラエティが一気に豊かになった年という印象です。
当時は、私がちょうどre:Inventに参加していたこともあり、リリースされたばかりのS3 Metadataに関するChalk Talkに参加して、聴講者の熱い興味・関心を感じたのを覚えています。その時の様子は以下の記事に記載しています。
その後の2025年1月には、先行してプレビュー公開されていた米国のリージョンではGAになりました。
どんなもの？
S3 Metadataは、S3上のオブジェクトに関連付けられたメタデータを自動で管理するサービスです。これにより、オブジェクトの属性情報を効率的に取得・更新できるようになります。メタデータは、Athenaからのクエリにも対応しています。
オブジェクトの追加や変更があった場合は、自動でメタデータも更新されるため、ユーザーが管理する必要もなく、情報が古いままであることを気にする必要もありません。また、ユーザーによるカスタムのメタデータにも対応しています。
中身は、同時に発表されたS3 Tablesで実装されています。S3 Tablesでは、データはApache Iceberg形式で保管されています。
構成
S3 Metadataは、以下の2種類のテーブルで構成されています。
- ジャーナルテーブル：オブジェクトに対するアクティビティを記録するテーブル
- ライブインベントリテーブル：オブジェクトのメタデータを記録するテーブル
S3 Metadataを使用するときは、ジャーナルテーブルは必須で、ライブインベントリテーブルは使用するかどうかを選択することができます。
ジャーナルテーブル
ジャーナルテーブルは、オブジェクトに対するアクティビティ（追加、変更、削除など）を記録します。これにより、オブジェクトの履歴を追跡し、変更があったタイミングを把握できます。
ライブインベントリテーブル
ライブインベントリテーブルは、オブジェクトのメタデータ（サイズ、作成日、所有者など）を記録します。これにより、オブジェクトの属性情報を効率的に取得できます。
テーブルスキーマ
2つのテーブルのスキーマを比較してみます。
以下の表に示す通り、ジャーナルテーブルとライブインベントリテーブルのスキーマ的な差は、オブジェクト操作関連の情報があるかどうかとなっています。
| 列名 | ジャーナル テーブル |
ライブインベントリ テーブル |
|---|---|---|
bucket |
● | ● |
key |
● | ● |
sequence_number |
● | ● |
record_type |
● | |
record_timestamp |
● | |
version_id |
● | ● |
is_delete_marker |
● | ● |
size |
● | ● |
last_modified_date |
● | ● |
e_tag |
● | ● |
storage_class |
● | ● |
is_multipart |
● | ● |
encryption_status |
● | ● |
is_bucket_key_enabled |
● | ● |
kms_key_arn |
● | ● |
checksum_algorithm |
● | ● |
object_tags |
● | ● |
user_metadata |
● | ● |
requester |
● | |
source_ip_address |
● | |
request_id |
● |
テーブルのスキーマの詳細に関しては、公式ドキュメントをご参照ください。
使ってみた
実際に東京リージョンにあるS3バケットで、メタデータを有効にしてクエリしてみましょう。
利用開始まで
S3 Metadataが利用可能なリージョンでは、バケットの詳細画面に「メタデータ」タブが出現しています。「メタデータ」タブを開き、「メタデータ設定を作成」をクリックすると利用開始できます。
ウィザードが表示されるので、暗号化やレコードの有効期限を適宜設定し、一番下の「メタデータ設定を作成」をクリックします。
すると、メタデータ作成のリクエストが進行中となり、テーブルステータスが「作成中」になります。
リクエストの処理が完了すると、ステータスが「アクティブ」に変わります。
私が試した限りでは、ジャーナルテーブルは作成完了までの時間が短く、ライブインベントリテーブルは30MB程度のオブジェクトが1つしか保存されていないバケットでも完了するまで20分程度かかりました。
ジャーナルテーブルは、有効化後の操作を記録するため、テーブルを用意するだけでよいですが、ライブインベントリテーブルは、既存のオブジェクトに対してもメタデータのテーブルを用意する必要がある(バックフィル)ため、時間がかかっているようです。もしかすると、内部でのジョブのキューの状況によっても所要時間は変わるかもしれません。
利用開始後に作成されたもの
前述の通り、S3 MetadataはS3 Tablesを使用したサービスであるため、利用を開始するとaws-s3という名前のテーブルバケットが自動で作成されます。
ちなみに、テーブルバケットの命名規則によりawsで始まる名前を付けることができないため、ユーザーはaws-s3という名前のテーブルバケットを作成できません。
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/s3-tables-buckets-naming.html#table-buckets-naming-rules
テーブルバケットの中には、ジャーナルテーブル(journal)とライブインベントリテーブル(inventory)がそれぞれ作成されています。テーブルの元となっているバケットは、名前空間によって区別でき、バケット名の前にb_が付与された名前空間が自動的に設定されています。
テーブルの中身の確認
テーブルの中身を確認してみましょう。
「メタデータ」タブの「プレビュー」ボタンから各テーブルの中身を簡易的にプレビューできます。
ジャーナルテーブル
まずは、ジャーナルテーブルをプレビューしてみます。対象のバケットは、過去の記事で紹介したQiita記事のメトリクスを格納しているバケットです。
処理の詳細は過去の記事を参照いただきたいのですが、GitHub Actionsによりメトリクスのデータが自動的にアップロードされた履歴が記録されています。スクリーンショットでは見切れていますが、リクエスターやソースのIPアドレスも記録されています。
ライブインベントリテーブル
次に、ライブインベントリテーブルをプレビューしてみます。
記録されている内容は、ジャーナルテーブルのうち、操作記録関連を除いた部分です。
Athenaでクエリ
Athenaでもクエリしてみましょう。ライブインベントリテーブルからサイズが小さいオブジェクトトップ5を取得してみます。クエリは以下の通りです。
SELECT bucket, key, size, last_modified_date, e_tag FROM "inventory" WHERE is_delete_marker = false ORDER BY size ASC LIMIT 5;
クエリ結果自体は面白みに欠けるのですが、サイズが小さいオブジェクトの情報を取得できました。
使えそう？
実際に使ってみたところで、S3 Metadataが実用的であるか整理してみます。
ここが便利、ここで活躍しそう
個人的に思ったところ
これまでスクリプトで自動とはいえ自前でメタデータを取得して加工していた方にとっては、S3 Metadataを活用すると、以下のような点が嬉しい点かと思いました。
-
ListObjectsなどのAPIを使って自分でデータを加工する必要がない(ページネーションを気にする必要もない) - 自分で管理が必要な余計なリソースを作る必要がない
- AWSマネージドで自動でデータを更新してくれる
- Athenaで直接クエリできる
公式ドキュメントでは
公式ドキュメントによれば、ジャーナルテーブルが活躍する場面として以下の場面が挙げられています。
- S3 ライフサイクルによって過去 24 時間に削除されたオブジェクトはどれか。
- 最新の PUT リクエストはどの IP アドレスから送信されたか。
- 過去 7 日間に PUT リクエストに使用された AWS Key Management Service (AWS KMS) キーはどれか。
- バケット内のどのオブジェクトが Amazon Bedrock によって過去 5 日間に作成されたものか
引用元：https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/metadata-tables-schema.html
同様に、ライブインベントリテーブルが活躍する場面として以下が挙げられています。
- S3 Glacier Deep Archive ストレージクラスに保存されているすべてのオブジェクトを検索します。
- オブジェクトタグのディストリビューションを作成するか、タグなしでオブジェクトを検索します。
- AWS Key Management Service (AWS KMS) キーによるサーバー側の暗号化 (SSE-KMS) を使用して暗号化されていないすべてのオブジェクトを検索します。
引用元：https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/metadata-tables-inventory-schema.html
また、S3 Metadataのテーブルでは、S3 InventoryやS3のREST APIで利用可能な情報すべてを扱えるわけではなく、例えば以下の情報は含まれないということです。
- S3 ライフサイクルの有効期限または移行ステータス
- Object Lock の保持期間またはガバナンスモード
- オブジェクトのアクセスコントロールリスト (ACL) 情報
- レプリケーションステータス
引用元：https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/metadata-tables-restrictions.html
re:Inventのセッションでは
re:Invent 2024のセッション「STG353-NEW | [NEW LAUNCH] Accelerate data discovery with Amazon S3 Metadata」では、ユースケースとして以下の3つのケースが紹介されていました。ビッグデータを扱うケースでは活躍しそうです。
処理するオブジェクトを探し出す
-- List the objects in my bucket (without using the LIST API)
SELECT bucket, key, storage_class, user_metadata
FROM aws_s3_metadata.my_metadata_table
WHERE key LIKE '{SOME_PREFIX)%';
データの来歴を理解し追跡する
-- Who is deleting data? What are they deleting?
SELECT DISTINCT bucket, key, record_type, record_timestamp, requester, source_ip_address
FROM aws_s3_metadata.my_metadata_table
WHERE record_type = 'DELETE';
ストレージの使用量を把握する
-- How much storage are my tagged objects using?
SELECT object_tags['MyTag'] as mytag, storage_class, count(*) as count,
sum(size) / 1024 / 1024 as usage
FROM aws_s3_metadata.my_metadata_table
GROUP BY tags['Module'], storage_class;
コストは？
利用にあたってコストも把握しておく必要があります。
S3 Metadataを利用するにあたっては、S3 MetadataによるコストとベースとなっているS3 Tablesの利用に係るコストの2つのコストが発生します。2025年12月現在の東京リージョンの料金を確認しておきましょう。
S3 Metadataのコスト
S3 Metadataのコストは以下の通りです。
| テーブル | コスト |
|---|---|
| ジャーナルテーブル | USD 0.30/100万回アップデート |
| ライブインベントリテーブル | USD 0.10/100万オブジェクト |
ここでのジャーナルテーブルのアップデートには、オブジェクトの追加・削除、メタデータの変更、ライブインベントリテーブル作成時のバックフィルが含まれます。
また、ライブインベントリテーブルのコストはオブジェクト数が10億個以下のバケットでは発生しません。
私がS3 Metadataを試した時点では、日本語のページにはコストの記載がありませんでしたが、執筆時点では追加されていました。「管理と洞察」のタブに記載されています。
S3 Tablesのコスト
S3 Tablesのコストは以下の通りです。
| 項目 | コスト |
|---|---|
| ストレージ(最初の50TB) | USD 0.0288/GB |
| リクエスト(PUT、POST、LIST) | USD 0.0047/1000リクエスト |
| リクエスト(GET、その他) | USD 0.00037/1000リクエスト |
ストレージのコストは通常のS3より15%程度高いですが、リクエストの料金は同額です。マネージドでテーブルが更新される場合にもリクエストに対する課金が発生するかは不明です。
利用事例
公式サイトでは、PayPal、Flickr、New Relicなどの有名企業内での活用事例がいくつか紹介されています。何億、何兆ものオブジェクトを扱うユーザーにとっては、データ管理の堅牢化、合理化に一役買っているようです。
まとめ
本記事では、東京リージョンでも利用可能になったS3 Metadataについて取り上げました。
S3 Metadataにより、S3上に保管されているオブジェクトのメタデータを効率的に管理することができそうです。特に、ビッグデータを解析するようなユースケースでは、実際に利用事例もあり、データ管理の効率化に重宝しそうです。
一方で、コストが追加で発生するサービスでもあるので、自分でメタデータを管理し保管する場合の労力やコストと、S3 Metadataを利用してAWSにオフロードする場合のコストを比較して、使うべきかを判断するのがよさそうです。
今後もS3 Metadataの活用事例や新機能の追加などに注目していきたいと思います。