# オブジェクトメタデータの使用
Amazon S3 には、*システム定義*メタデータと*ユーザー定義*メタデータの 2 種類のオブジェクトメタデータがあります。システム定義メタデータには、オブジェクトの作成日、サイズ、ストレージクラスなどのメタデータが含まれます。ユーザー定義メタデータは、オブジェクトのアップロード時に設定できるメタデータです。このユーザー定義メタデータは、名前と値のペアのセットです。詳細については、「[システムで定義されたオブジェクトメタデータ](#SysMetadata)」および「[ユーザー定義のオブジェクトメタデータ](#UserMetadata)」を参照してください。
オブジェクトを作成するときは、Amazon S3 バケット内のオブジェクトを一意に識別する*オブジェクトキー* (または*キー名*) を指定します。詳細については、「[Amazon S3 オブジェクトに命名する](object-keys.md)」を参照してください。オブジェクトをアップロードする時に Amazon S3 で[ユーザー定義メタデータ](#UserMetadata)を設定することもできます。
オブジェクトをアップロードした後で、このユーザー定義メタデータを変更することはできません。このメタデータを変更する唯一の方法は、オブジェクトのコピーを作成し、メタデータを設定することです。Amazon S3 コンソールを使用したメタデータの編集の詳細については、「[Amazon S3 コンソールでのオブジェクトメタデータの編集](add-object-metadata.md)」を参照してください。
**S3 メタデータを使用してメタデータをクエリし、データ検出を高速化する**
S3 オブジェクトのメタデータを簡単に検索、保存、クエリするには、S3 メタデータを使用できます。S3 メタデータを使用すると、ビジネス分析、コンテンツ取得、人工知能と機械学習 (AI/ML) モデルトレーニングなどで使用するデータをすばやく準備できます。
S3 メタデータは、汎用バケット内のオブジェクトのメタデータを自動的にキャプチャし、クエリできる読み取り専用のフルマネージド Apache Iceberg テーブルに保存することで、データ検出を高速化します。これらの読み取り専用テーブルは*メタデータテーブル*と呼ばれます。オブジェクトが汎用バケットに追加、更新、削除されると、S3 メタデータは対応するメタデータテーブルを自動的に更新して、最新の変更を反映します。
デフォルトでは、S3 メタデータは、オブジェクトの作成時刻やストレージクラスなどの[システム定義のオブジェクトメタデータ](#SysMetadata)、およびオブジェクトのアップロード中に含められたタグや[ユーザー定義のメタデータ](#UserMetadata)などのカスタムメタデータを提供します。S3 メタデータは、オブジェクトが更新または削除されたときや、リクエストを行った AWS アカウントなどのイベントメタデータも提供します。
メタデータテーブルは、表形式データ用に最適化されたストレージを提供する S3 テーブルバケットに保存されます。メタデータをクエリするために、テーブルバケットを Amazon Athena、Amazon Redshift、Amazon Quick などの AWS 分析サービスと統合できます。
S3 メタデータの詳細については、「[S3 メタデータテーブルを使用したデータの検出](metadata-tables-overview.md)」を参照してください。
## システムで定義されたオブジェクトメタデータ
Amazon S3 では、バケットに格納されるオブジェクトごとに、一連のシステムメタデータが維持されます。Amazon S3 はこのシステムメタデータを必要に応じて処理します。例えば、Amazon S3 ではオブジェクトの作成日とサイズに関するメタデータが維持され、オブジェクト管理の目的でこの情報が使用されます。
システムメタデータには 2 つのカテゴリがあります。
+ **システム制御** – オブジェクトの作成日などのメタデータはシステムによって制御されます。つまり、Amazon S3 だけがその日付値を変更できることを意味します。
+ **ユーザー制御** – 他のシステムメタデータ (オブジェクトに設定済みのストレージクラスや、オブジェクトでサーバー側の暗号化が有効になっているかどうかなど) は、ユーザーが値を制御するシステムメタデータの例です。バケットをウェブサイトとして設定している場合、ページリクエストを別のページか外部 URL のいずれかにリダイレクトする場合があります。この場合、ウェブページはバケット内のオブジェクトです。Amazon S3 は、ページリダイレクト値をシステムメタデータとして保存し、ユーザーがその値を制御できます。
オブジェクトを作成するときに、このようなシステムメタデータ項目の値を設定したり、必要に応じてその値を更新したりできます。ストレージクラスの詳細については、「[Amazon S3 ストレージクラスの理解と管理](storage-class-intro.md)」を参照してください。
Amazon S3 は Amazon S3 オブジェクトを暗号化する AWS KMS キーを使用します。AWS KMS はオブジェクトデータのみを暗号化します。チェックサムと指定されたアルゴリズムは、オブジェクトのメタデータの一部として保存されます。サーバー側でオブジェクトに対する暗号化が要求された場合、チェックサムは暗号化された形式で保存されます。サーバーサイドの暗号化の詳細については、「[暗号化によるデータの保護](UsingEncryption.md)」を参照してください。
**注記**
`PUT` リクエストヘッダーのサイズは 8 KB に制限されています。`PUT` リクエストヘッダー内のシステム定義メタデータのサイズは 2 KB に制限されています。システム定義メタデータのサイズは、キーと値の各ペアを US−ASCII にエンコードしたバイト数の合計に基づいて測定されます。
次の表は、システム定義のメタデータのリストとユーザーがそれを更新できるかどうかをまとめたものです。
| 名前 | 説明 | ユーザーが値を変更することはできますか? |
| --- | --- | --- |
| Date | 現在の日付と時刻。 | いいえ |
| Cache-Control | キャッシュポリシーを指定するために使用される一般的なヘッダーフィールド。 | はい |
| Content-Disposition | オブジェクトのプレゼンテーション情報。 | はい |
| Content-Encoding | オブジェクトのデータに適用されたコンテンツエンコード (圧縮など) | はい |
| Content-Length | オブジェクトのサイズ (バイト単位)。 | いいえ |
| Content-Type | オブジェクトのタイプ。 | はい |
| Last-Modified | オブジェクト作成日または最終更新日のいずれか遅い方。マルチパートアップロードの場合、オブジェクトの作成日はマルチパートアップロードの開始日です。 | いいえ |
| ETag | オブジェクトのエンティティタグ (ETag) は、そのオブジェクトの特定のバージョンを表します。マルチパートアップロードとしてアップロードされず、暗号化されていない、または Simple Storage Service (Amazon S3) 管理キー (SSE-S3) を使用したサーバー側の暗号化によって暗号化されているオブジェクトの場合、ETag はデータの MD5 ダイジェストです。 | いいえ |
| x-amz-server-side-encryption | オブジェクトでサーバー側の暗号化が有効であるか、そして暗号化が AWS Key Management Service (AWS KMS) または Amazon S3 で管理された暗号化 (SSE−S3) によるものかを示すヘッダー。詳細については、「[サーバー側の暗号化によるデータの保護](serv-side-encryption.md)」を参照してください。 | はい |
| x-amz-checksum-crc64nvme, x-amz-checksum-crc32, x-amz-checksum-crc32c, x-amz-checksum-sha1, x-amz-checksum-sha256 | オブジェクトのチェックサムまたはダイジェストが含まれるヘッダー。Amazon S3 に使用するように指示したチェックサムアルゴリズムに応じて、これらのヘッダーの最大 1 つが一度に設定されます。チェックサムアルゴリズムの選択の詳細については、「[Amazon S3 でのオブジェクトの整合性のチェック](checking-object-integrity.md)」を参照してください。 | いいえ |
| x-amz-checksum-type | チェックサムタイプ。マルチパートオブジェクトのオブジェクトレベルのチェックサムを作成するために、パートレベルのチェックサムをどのように組み合わせるかを決定します。 | はい |
| x-amz-version-id | オブジェクトのバージョン。バケットのバージョニングを有効にすると、Amazon S3 ではバケットに追加されたオブジェクトにバージョン ID が割り当てられます。詳細については、「[S3 バージョニングによる複数のバージョンのオブジェクトの保持](Versioning.md)」を参照してください。 | いいえ |
| x-amz-delete-marker | オブジェクトが削除マーカーであるかどうかを示すブール値マーカー。このマーカーは、バージョニングが有効になっているバケットでのみ使用されます。 | いいえ |
| x-amz-storage-class | オブジェクトの保存に使われるストレージクラス。詳細については、「[Amazon S3 ストレージクラスの理解と管理](storage-class-intro.md)」を参照してください。 | はい |
| x-amz-website-redirect-location | 関連付けられたオブジェクトのリクエストを同じバケット内の別のオブジェクトまたは外部 URL にリダイレクトするヘッダー。詳細については、「[(オプション) ウェブページリダイレクトの設定](how-to-page-redirect.md)」を参照してください。 | はい |
| x-amz-server-side-encryption-aws-kms-key-id | オブジェクトの暗号化に使用された AWS KMS 対称暗号化 KMS キーの ID を示すヘッダー。このヘッダーは、x-amz-server-side-encryption ヘッダーが存在し、値が aws:kms である場合にのみ使用されます。 | はい |
| x-amz-server-side-encryption-customer-algorithm | お客様が用意した暗号化キーを使用したサーバー側の暗号化 (SSE−C) が有効であるかどうかを示すヘッダー。詳細については、「[お客様が指定したキーによるサーバー側の暗号化 (SSE−C) の使用](ServerSideEncryptionCustomerKeys.md)」を参照してください。 | はい |
| x-amz-tagging | オブジェクトのタグセット。タグセットは URL クエリパラメータとしてエンコードする必要があります。 | はい |
## ユーザー定義のオブジェクトメタデータ
オブジェクトをアップロードするときに、そのオブジェクトにメタデータを割り当てることもできます。このオプション情報は、オブジェクトを作成するための `PUT` リクエストまたは `POST` リクエストを送信するときに、名前と値 (キーと値) のペアとして指定します。REST API を使用してオブジェクトをアップロードするときは、オプションのユーザー定義メタデータ名を「`x-amz-meta-`」で始め、他の HTTP ヘッダーと区別する必要があります。REST API を使用してオブジェクトを取得するときは、このプレフィックスが返されます。SOAP API を使用してオブジェクトをアップロードする場合、このプレフィックスは不要です。SOAP API を使用してオブジェクトを取得するときは、オブジェクトのアップロードに使用した API にかかわらず、プレフィックスは削除されます。
**注記**
SOAP API for Amazon S3 は新規顧客には利用できず、2025 年 8 月 31 日にサポート終了 (EOL) となります。REST API か AWS SDK を使用することをお勧めします。
REST API を介してメタデータを取得するとき、同じ名前を持つヘッダー (大文字と小文字は区別されません) は Amazon S3 によってカンマ区切りリストに結合されます。出力不可能な文字が含まれているメタデータは返されません。その代わりに、`x-amz-missing-meta` ヘッダーが、出力不可能なメタデータエントリの数を示す値と共に返されます。`HeadObject` アクションは、オブジェクト自体を返さずに、オブジェクトからメタデータを取得します。このオペレーションは、オブジェクトのメタデータのみに関心がある場合に役立ちます。`HEAD` を使用するには、オブジェクトへの `READ` アクセス権が必要です。詳細については、*Amazon Simple Storage Service API リファレンス*の「[HeadObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_HeadObject.html)」を参照してください。
ユーザー定義メタデータはキーと値のペアのセットです。Amazon S3 はユーザー定義メタデータキーを小文字で保存します。
Amazon S3 では、任意の Unicode 文字をメタデータ値で使用できます。
これらのメタデータ値の表示に関連した問題を回避するために、REST を使用する場合は US−ASCII 文字を使用してください。SOAP またはブラウザベースのアップロードを `POST` 経由で使用する場合は UTF−8 を使用してください。
US−ASCII 以外の文字をメタデータ値で使用すると、指定した Unicode 文字列に US−ASCII 以外の文字が含まれていないかどうか調べられます。そのようなヘッダーの値は、保存される前に [RFC 2047](https://datatracker.ietf.org/doc/html/rfc2047) に従って文字デコードされます。さらに、[RFC 2047](https://datatracker.ietf.org/doc/html/rfc2047) に従ってエンコードされ、メールセーフになってから返されます。文字列に US−ASCII 文字のみが含まれている場合は、そのまま表示されます。
以下に例を示します。
```
PUT /Key HTTP/1.1
Host: amzn-s3-demo-bucket.s3.amazonaws.com
x-amz-meta-nonascii: ÄMÄZÕÑ S3
HEAD /Key HTTP/1.1
Host: amzn-s3-demo-bucket.s3.amazonaws.com
x-amz-meta-nonascii: =?UTF-8?B?w4PChE3Dg8KEWsODwpXDg8KRIFMz?=
PUT /Key HTTP/1.1
Host: amzn-s3-demo-bucket.s3.amazonaws.com
x-amz-meta-ascii: AMAZONS3
HEAD /Key HTTP/1.1
Host: amzn-s3-demo-bucket.s3.amazonaws.com
x-amz-meta-ascii: AMAZONS3
```
**注記**
`PUT` リクエストヘッダーのサイズは 8 KB に制限されています。`PUT` リクエストヘッダー内のユーザー定義メタデータのサイズは 2 KB に制限されています。ユーザー定義メタデータのサイズは、キーと値それぞれの UTF−8 エンコーディングの合計バイト数を使用して測定されます。
アップロード済みオブジェクトのメタデータの変更 (オブジェクトのコピーを作成し、それを変更して古いオブジェクトと置き換える場合、または新しいバージョンを作成する場合) については、[Amazon S3 コンソールでのオブジェクトメタデータの編集](add-object-metadata.md) を参照してください。
# Amazon S3 コンソールでのオブジェクトメタデータの編集
Amazon S3 コンソールを使用して、**[コピー]** アクションを使用して既存の S3 オブジェクトのメタデータを編集できます。メタデータを編集するには、オブジェクトを同じ宛先にコピーし、適用する新しいメタデータを指定します。これにより、オブジェクトの古いメタデータが置き換えられます。一部のメタデータは、オブジェクトをアップロードするときに Amazon S3 によって設定されます。例えば、`Content-Length` および `Last-Modified` は、ユーザーが変更できない、システム定義のオブジェクトメタデータフィールドです。
また、オブジェクトのアップロード時にユーザー定義のメタデータを設定し、必要に応じて後で置き換えることもできます。例えば、`STANDARD` ストレージクラスに最初に保存したオブジェクトのセットがあるとします。時間の経過とともに、このデータを高可用性にする必要がなくなる可能性があります。そのため、`x-amz-storage-class` キーの値を `STANDARD` から `GLACIER` に置き換えて、ストレージクラスを `GLACIER` に変更できます。
**注記**
Amazon S3 でオブジェクトメタデータを置き換える場合は、次のことを考慮してください。
保持する既存のメタデータ、追加するメタデータ、および編集するメタデータを指定する必要があります。
オブジェクトが 5 GB 未満の場合は、S3 コンソールで **[コピー]** アクションを使用してオブジェクトメタデータを置き換えることができます。オブジェクトが 5 GB を超える場合は、[AWS CLI](mpu-upload-object.md#UsingCLImpUpload) または [AWS SDK](CopyingObjectsMPUapi.md) を使用してオブジェクトをマルチパートアップロードでコピーするときに、オブジェクトメタデータを置き換えることができます。詳細については、「[マルチパートアップロードを使用したオブジェクトのコピー](CopyingObjectsMPUapi.md)」を参照してください。
メタデータを置き換えるために必要な追加のアクセス許可のリストについては、「[Amazon S3 API オペレーションに必要なアクセス許可](using-with-s3-policy-actions.md)」を参照してください。このアクセス許可を付与するポリシーの例については、「[Amazon S3 のアイデンティティベースのポリシー例](example-policies-s3.md)」を参照してください。
このアクションにより、更新された設定と最終更新日を持つオブジェクトの*コピー*が作成されます。S3 バージョニングが有効になっている場合は、オブジェクトの新しいバージョンが作成され、既存のオブジェクトが古いバージョンになります。S3 バージョニングが有効になっていない場合は、元のオブジェクトがオブジェクトの新しいコピーに置き換えられます。プロパティを変更する IAM ロールに関連付けられた AWS アカウント も、新しいオブジェクトまたは (オブジェクトバージョン) の所有者になります。
メタデータを編集すると、既存のキー名の値が置き換えられます。
お客様が用意した暗号化キー (SSE−C) で暗号化されたオブジェクトは、コンソールを使用してコピーすることはできません。AWS CLI、AWS SDK、または Amazon S3 REST API を使用する必要があります。
Amazon S3 コンソールを使用してオブジェクトをコピーすると、"Copied metadata can't be verified." というエラーメッセージが表示されることがあります。コンソールは、ヘッダーを使用してオブジェクトのメタデータを取得し、設定します。ネットワークまたはブラウザの設定によってネットワークリクエストが変更された場合、この動作により、コピーしたオブジェクトに意図しないメタデータ (変更された `Cache-Control` ヘッダーなど) が書き込まれる可能性があります。Amazon S3 はこの意図しないメタデータを検証できません。
この問題に対処するには、ネットワークとブラウザの設定をチェックして、`Cache-Control` などのヘッダーが変更されていないことを確認します。詳細については、「[The Shared Responsibility Model](https://docs.aws.amazon.com/whitepapers/latest/applying-security-practices-to-network-workload-for-csps/the-shared-responsibility-model.html)」を参照してください。
**警告**
フォルダのメタデータを置き換える場合は、**[コピー]** アクションが完了するのを待ってから、フォルダに新しいオブジェクトを追加します。そうしないと、新しいオブジェクトも編集される可能性があります。
以下のトピックでは、Amazon S3 コンソールで **[コピー]** アクションを使用してオブジェクトのメタデータを置き換える方法について説明します。
## システム定義メタデータの置き換え
S3 オブジェクトのシステム定義メタデータを置き換えられます。システム定義のメタデータと変更可能な値のリストについては、「[システムで定義されたオブジェクトメタデータ](UsingMetadata.md#SysMetadata)」を参照してください。
**オブジェクトのシステム定義メタデータを置き換えるには**
1. AWS マネジメントコンソール にサインインし、Amazon S3 コンソール [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) を開きます。
1. 左のナビゲーションペインで、**[汎用バケット]** または **[ディレクトリバケット]** を選択します。
1. バケットのリストで、変更するオブジェクトが含まれるバケットの名前を選択します。
1. 変更するオブジェクトのチェックボックスをオンにします。
1. **[アクション]** メニューに表示されるオプションのリストから **[コピー]** を選択します。
1. 送信先パスを指定するには、**[S3 の参照]** を選択し、ソースオブジェクトと同じ送信先に移動して、送信先にあるチェックボックスをオンにします。右下の **[Choose destination]** (送信先を選択する) を選択します。
または、送信先パスを入力します。
1. バケットバージョニングを有効にしていない場合は、バケットバージョニングを有効にして、オブジェクトを意図しない上書きまたは削除から保護することを推奨する警告が表示されます。**このバケットのオブジェクトの全バージョンを保持する場合は、**[バケットのバージョニングを有効にする]** をクリックします。**[送信先の詳細]** で、デフォルトの暗号化プロパティと Object Lock プロパティを確認することもできます。
1. **[追加のコピー設定]** で、**[設定を指定]** を選択して、**[メタデータ]** の設定を指定します。
1. **[メタデータ]** セクションまでスクロールし、**[すべてのメタデータを置き換え]** を選択します。
1. **[メタデータの追加]** を選択します。
1. メタデータの [**Type (タイプ)**] には、[**System−defined (システム定義)**] を選択します。
1. 一意の [**Key (キー)**] とメタデータの [**Value (値)**] を指定します。
1. 追加のメタデータを編集するには、[**Add metadata (メタデータの追加)**] を選択します。[**削除**] をクリックして、タイプ、キー、値のセットを削除することもできます。
1. **[コピー]** を選択します。Amazon S3 はメタデータの変更を保存します。
## ユーザー定義メタデータの置き換え
メタデータプレフィックス、`x-amz-meta-`、およびカスタムキーを作成するために選択した名前を組み合わせて、オブジェクトのユーザー定義メタデータを置き換えられます。例えば、カスタム名 `alt-name` を追加した場合、メタデータキーは `x-amz-meta-alt-name` になります。
ユーザー定義メタデータの合計サイズは最大 2 KB です。ユーザー定義メタデータの合計サイズを計算するには、キーと値ごとの UTF−8 エンコーディングのバイト数を合計します。キーと値の両方が US−ASCII 標準に従っている必要があります。詳細については、「[ユーザー定義のオブジェクトメタデータ](UsingMetadata.md#UserMetadata)」を参照してください。
**オブジェクトのユーザー定義メタデータを置き換えるには**
1. AWS マネジメントコンソール にサインインし、Amazon S3 コンソール [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) を開きます。
1. ナビゲーションペインで **[バケット]** を選択してから、**[汎用バケット]** または **[ディレクトリバケット]** タブをクリックします。変更するオブジェクトを含む Amazon S3 バケットまたはフォルダに移動します。
1. 変更するオブジェクトのチェックボックスをオンにします。
1. **[アクション]** メニューに表示されるオプションのリストから **[コピー]** を選択します。
1. 送信先パスを指定するには、**[S3 の参照]** を選択し、ソースオブジェクトと同じ送信先に移動して、送信先にあるチェックボックスをオンにします。[**コピー先の選択**] を選択します。
または、送信先パスを入力します。
1. バケットバージョニングを有効にしていない場合は、バケットバージョニングを有効にして、オブジェクトを意図しない上書きまたは削除から保護することを推奨する警告が表示されます。**このバケットのオブジェクトの全バージョンを保持する場合は、**[バケットのバージョニングを有効にする]** をクリックします。**[送信先の詳細]** で、デフォルトの暗号化プロパティと Object Lock プロパティを確認することもできます。
1. **[追加のコピー設定]** で、**[設定を指定]** を選択して、**[メタデータ]** の設定を指定します。
1. **[メタデータ]** セクションまでスクロールし、**[すべてのメタデータを置き換え]** を選択します。
1. **[メタデータの追加]** を選択します。
1. メタデータの [**タイプ**] には [**ユーザー定義**] を選択します。
1. `x-amz-meta-` に続いて、一意のカスタム [**キー**] を入力します。メタデータの [**Value (値)**] も入力します。
1. さらにメタデータを追加するには、[**Add metadata (メタデータの追加)**] を選択します。[**削除**] をクリックして、タイプ、キー、値のセットを削除することもできます。
1. **[コピー]** を選択します。Amazon S3 はメタデータの変更を保存します。
# S3 メタデータテーブルを使用したデータの検出
Amazon S3 Metadata は、汎用バケット内のオブジェクトのメタデータを自動的にキャプチャし、クエリできる読み取り専用のフルマネージド Apache Iceberg テーブルに保存することで、データ検出を高速化します。これらの読み取り専用テーブルは*メタデータテーブル*と呼ばれます。オブジェクトが汎用バケットに追加、更新、削除されると、S3 Metadata は対応するメタデータテーブルを自動的に更新して、最新の変更を反映します。
デフォルトでは、S3 メタデータは次の 3 種類のメタデータを提供します。
+ オブジェクトの作成時刻やストレージクラスなどの[システム定義メタデータ](UsingMetadata.md#SysMetadata)
+ オブジェクトのアップロード時に含められたタグや[ユーザー定義メタデータ](UsingMetadata.md#UserMetadata)などのカスタムメタデータ
+ オブジェクトが更新または削除されたときや、リクエストを行った AWS アカウントなどのイベントメタデータ
S3 メタデータを使用すると、S3 オブジェクトのメタデータを簡単に検索、保存、クエリできるため、ビジネス分析、コンテンツ取得、人工知能と機械学習 (AI/ML) モデルトレーニングなどで使用するデータをすばやく準備できます。
汎用バケットごとに、2 つの補完メタデータテーブルを含むメタデータテーブル設定を作成できます。
+ **ジャーナルテーブル** – デフォルトでは、メタデータテーブル設定には、バケット内のオブジェクトで発生したイベントをキャプチャする*ジャーナルテーブル*が含まれます。ジャーナルテーブルは、データに加えられた変更をほぼリアルタイムで記録するため、バケットにアップロードされた新しいデータの特定、最近削除されたオブジェクトの追跡、ライフサイクルの移行のモニタリングなどに役立ちます。ジャーナルテーブルには、新しいオブジェクトと、オブジェクトとそのメタデータに対する更新 (`PUT` または `DELETE` オペレーションを必要とする更新) が記録されます。
ジャーナルテーブルは、メタデータテーブル設定を作成した後に発生する変更イベント (アップロード、更新、削除など) のメタデータのみをキャプチャします。このテーブルはクエリ可能であるため、単純な SQL クエリを使用してバケットへの変更を監査できます。
ジャーナルテーブルは、メタデータテーブル設定ごとに必要です。(S3 Metadata の初回リリースでは、ジャーナルテーブルは「メタデータテーブル」と呼ばれていました)。
ジャーナルテーブルに保存されるデータの詳細については、「[S3 Metadata ジャーナルテーブルスキーマ](metadata-tables-schema.md)」を参照してください。
ストレージコストを最小限に抑えるために、ジャーナルテーブルレコードの有効期限を有効にするように選択できます。詳細については、「[ジャーナルテーブルレコードを期限切れにする](metadata-tables-expire-journal-table-records.md)」を参照してください。
+ **ライブインベントリテーブル** – オプションで、メタデータテーブル設定に*ライブインベントリテーブル*を追加できます。ライブインベントリテーブルは、バケット内のすべてのオブジェクトとそのバージョンのシンプルでクエリ可能なインベントリを提供するため、データの最新の状態を判断できます。
ライブインベントリテーブルを使用すると、さまざまなワークロードに対して処理するオブジェクトを特定することで、ビジネスワークフローとビッグデータジョブを簡素化および高速化できます。例えば、ライブインベントリテーブルをクエリして、特定のストレージクラスに保存されているすべてのオブジェクト、特定のタグを持つすべてのオブジェクト、 AWS Key Management Service (AWS KMS) キー (SSE-KMS) を使用したサーバー側の暗号化で暗号化されていないすべてのオブジェクトなどを検索できます。
メタデータテーブル設定のライブインベントリテーブルを有効にすると、テーブルは*バックフィル*と呼ばれるプロセスを実行し、そのプロセス中に Amazon S3 は汎用バケットをスキャンして、バケットに存在するすべてのオブジェクトの初期メタデータを取得します。バケット内のオブジェクトの数によっては、このプロセスに数分 (最小 15 分) から数時間かかる場合があります。バックフィルプロセスが完了すると、ライブインベントリテーブルのステータスが **[バックフィル]** から **[アクティブ]** に変わります。バックフィルが完了すると、通常、オブジェクトの更新は 1 時間以内にライブインベントリテーブルに反映されます。
インベントリテーブルのバックフィルの実行は課金されます。汎用バケットに 10 億個を超えるオブジェクトがある場合は、ライブインベントリテーブルの月額料金も請求されます。詳細については、[Amazon S3 の料金](https://aws.amazon.com/s3/pricing/) を参照してください。
ライブインベントリテーブルに保存されるデータの詳細については、「[S3 Metadata ライブインベントリテーブルスキーマ](metadata-tables-inventory-schema.md)」を参照してください。
メタデータテーブルは、表形式データ用に最適化されたストレージを提供する AWS マネージド S3 テーブルバケットに保存されます。メタデータをクエリするために、テーブルバケットを Amazon SageMaker Lakehouse と統合できます。AWS Glue Data Catalog および AWS Lake Formation を使用するこの統合により、AWS 分析サービスがテーブルデータを自動的に検出してアクセスできるようになります。
テーブルバケットが AWS Glue Data Catalog と統合されると、Amazon Athena、Amazon EMR、Amazon Redshift などの AWS 分析サービスを使用してメタデータテーブルを直接クエリできます。そこから、Amazon Quick を使用して、クエリデータでインタラクティブなダッシュボードを作成できます。AWS マネージド S3 テーブルバケットと Amazon SageMaker Lakehouse の統合の詳細については、「[Amazon S3 Tables と AWS 分析サービスの統合](s3-tables-integrating-aws.md)」を参照してください。
AWS Glue Iceberg REST エンドポイント、Amazon S3 Tables Iceberg REST エンドポイント、または Apache Iceberg クライアントカタログの Amazon S3 Tables Catalog を使用して、Apache Spark、Apache Trino、および Apache Iceberg 形式をサポートする他のアプリケーションでメタデータテーブルをクエリすることもできます。メタデータテーブルへのアクセスの詳細については、「[テーブルデータへのアクセス](s3-tables-access.md)」を参照してください。
S3 メタデータの料金については、「[Amazon S3 の料金](https://aws.amazon.com/s3/pricing/)」を参照してください。
## メタデータテーブルの仕組み
メタデータテーブルは Amazon S3 によって管理され、Amazon S3 自体の外部にある IAM プリンシパルによって変更することはできません。ただし、メタデータテーブルを削除することはできます。その結果、メタデータテーブルは読み取り専用になり、汎用バケットの内容が正しく反映されます。
オブジェクトメタデータを生成して AWS マネージドメタデータテーブルに保存するには、汎用バケットのメタデータテーブル設定を作成します。Amazon S3 は、汎用バケットで設定がアクティブである限り、メタデータテーブルを継続的に更新してデータへの最新の変更を反映するように設計されています。
メタデータテーブル設定を作成する前に、メタデータテーブルを作成および管理するために必要な AWS Identity and Access Management (IAM) アクセス許可があることを確認してください。詳細については、「[メタデータテーブルを設定するためのアクセス許可の設定](metadata-tables-permissions.md)」を参照してください。
**メタデータテーブルのストレージ、整理、暗号化**
メタデータテーブル設定を作成すると、メタデータテーブルは AWS マネージドテーブルバケットに保存されます。アカウントと同じリージョンのすべてのメタデータテーブル設定は、単一の AWS マネージドテーブルバケットに保存されます。これらの AWS マネージドテーブルバケットの名前は `aws-s3` であり、Amazon リソースネーム (ARN) 形式は次のようになります。
`arn:aws:s3tables:region:account_id:bucket/aws-s3`
例えば、アカウント ID が 123456789012 で、汎用バケットが米国東部 (バージニア北部) (`us-east-1`) にある場合、AWS マネージドテーブルバケットも米国東部 (バージニア北部) (`us-east-1`) で作成され、次の ARN があります。
`arn:aws:s3tables:us-east-1:123456789012:bucket/aws-s3`
デフォルトでは、AWS マネージドテーブルバケットは、Amazon S3 マネージドキーによるサーバー側の暗号化 (SSE-S3) を使用して暗号化されます。最初のメタデータ設定を作成したら、AWS マネージドテーブルバケットのデフォルトの暗号化設定を設定して、AWS Key Management Service (AWS KMS) キーによるサーバー側の暗号化 (SSE-KMS) を使用できます。詳細については、「[Encryption for AWS managed table buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-aws-managed-buckets.html#aws-managed-buckets-encryption)」および「[テーブルバケットでの AWS KMS キーによるサーバー側の暗号化 (SSE-KMS) の指定](s3-tables-kms-specify.md)」を参照してください。
AWS マネージドテーブルバケット内では、設定のメタデータテーブルは通常、次の命名形式の名前空間に保存されます。
`b_general-purpose-bucket-name`
**注記**
汎用バケット名にピリオドが含まれている場合、ピリオドは名前空間名のアンダースコア (`_`) に変換されます。
汎用バケットが 2018 年 3 月 1 日より前に作成された場合、その名前には大文字とアンダースコアが含まれ、最大 255 文字の長さになる場合があります。バケット名にこれらの特性がある場合、メタデータテーブル名前空間の形式は異なります。汎用バケット名には `b_` というプレフィックスが付けられ、63 文字に切り捨てられ、すべて小文字に変換されて、ハッシュでサフィックスが付けられます。
メタデータテーブルには、メタデータテーブルのテーブル ID を含む次の Amazon リソースネーム (ARN) 形式があります。
`arn:aws:s3tables:region-code:account-id:bucket/aws-s3/table/table-id`
例えば、米国東部 (バージニア北部) リージョンのメタデータテーブルには、次のような ARN があります。
`arn:aws:s3tables:us-east-1:111122223333:bucket/aws-s3/table/a12bc345-67d8-912e-3456-7f89123g4h56`
ジャーナルテーブルの名前は `journal` で、ライブインベントリテーブルの名前は `inventory` です。
メタデータテーブル設定を作成するときに、AWS マネージドメタデータテーブルを AWS Key Management Service (AWS KMS) キーを使用したサーバー側の暗号化 (SSE-KMS) で暗号化することを選択できます。SSE-KMS を使用する場合は、汎用バケットと同じリージョンにカスタマーマネージド KMS キーを指定する必要があります。テーブルの暗号化タイプは、テーブルの作成中にのみ設定できます。AWS マネージドテーブルの作成後は、暗号化設定を変更することはできません。メタデータテーブルに SSE-KMS を指定するには、特定のアクセス許可が必要です。詳細については、「[SSE-KMS のアクセス許可](metadata-tables-permissions.md#metadata-kms-permissions)」を参照してください。
メタデータテーブルの暗号化設定は、デフォルトのバケットレベルの暗号化設定よりも優先されます。暗号化を指定しない場合、テーブルはバケットのデフォルト暗号設定を継承します。
AWS マネージドテーブルバケットは、S3 Tables クォータにはカウントされません。AWS マネージドテーブルバケットと AWS マネージドテーブルの操作の詳細については、「[Working with AWS managed table buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-aws-managed-buckets.html)」を参照してください。
メタデータテーブル設定の更新をモニタリングするには、AWS CloudTrail を使用できます。詳細については、「[CloudTrail ログ記録によって追跡される Amazon S3 バケットレベルのアクション](cloudtrail-logging-s3-info.md#cloudtrail-bucket-level-tracking)」を参照してください。
**メタデータテーブルのメンテナンスとレコードの有効期限**
メタデータテーブルのパフォーマンスを最適な状態に維持するために、Amazon S3 は、圧縮や参照されていないファイルの削除などの定期的なメンテナンスアクティビティをテーブルに対して実行します。これらのメンテナンスアクティビティは、メタデータテーブルの保存コストを最小限に抑え、クエリのパフォーマンスを最適化するのに役立ちます。このテーブルのメンテナンスは自動的に行われるため、オプトインや継続的な管理は必要ありません。
**注記**
ジャーナルテーブルまたはインベントリテーブルスナップショットの有効期限を制御することはできません。テーブルごとに、Amazon S3 は最低 1 つのスナップショットを最大 24 時間保存します。
コストを最小限に抑えるために、ジャーナルテーブルレコードの有効期限を設定できます。デフォルトでは、ジャーナルテーブルレコードは期限切れにならず、ジャーナルテーブルレコードは最低 7 日間保持する必要があります。詳細については、「[ジャーナルテーブルレコードを期限切れにする](metadata-tables-expire-journal-table-records.md)」を参照してください。
**Topics**
+ [
## メタデータテーブルの仕組み
](#metadata-tables-how-they-work)
+ [
# メタデータテーブルの制限と制約
](metadata-tables-restrictions.md)
+ [
# S3 Metadata ジャーナルテーブルスキーマ
](metadata-tables-schema.md)
+ [
# S3 Metadata ライブインベントリテーブルスキーマ
](metadata-tables-inventory-schema.md)
+ [
# メタデータテーブルの設定
](metadata-tables-configuring.md)
+ [
# メタデータテーブルのクエリ
](metadata-tables-querying.md)
+ [
# S3 Metadata のトラブルシューティング
](metadata-tables-troubleshooting.md)
# メタデータテーブルの制限と制約
Amazon S3 Metadata には、次の制限と制約があります。
+ S3 メタデータは、現時点では特定のリージョンでのみ利用可能です。詳細については、「[S3 メタデータ AWS リージョン](#metadata-tables-regions)」を参照してください。
+ S3 Metadata は、汎用バケットでサポートされているすべてのストレージクラスをサポートします。S3 Intelligent-Tiering ストレージクラスの場合、特定の階層はメタデータテーブルに表示されません。
+ メタデータテーブル設定を作成すると、メタデータテーブルは AWS マネージドテーブルバケットに保存されます。設定をカスタマーマネージドのテーブルバケットに保存することはできません。
+ S3 Metadata は、ディレクトリバケット、テーブルバケット、またはベクトルバケットではサポートされていません。メタデータテーブル設定は、汎用バケットに対してのみ作成できます。ジャーナルテーブルは、メタデータテーブル設定を作成した後に発生する変更イベント (アップロード、更新、削除など) のメタデータのみをキャプチャします。
+ ジャーナルテーブルまたはインベントリテーブルスナップショットの有効期限を制御することはできません。テーブルごとに、Amazon S3 は最低 1 つのスナップショットを最大 24 時間保存します。
コストを最小限に抑えるために、ジャーナルテーブルレコードの有効期限を設定できます。デフォルトでは、ジャーナルテーブルレコードは期限切れにならず、ジャーナルテーブルレコードは最低 7 日間保持する必要があります。詳細については、「[ジャーナルテーブルレコードを期限切れにする](metadata-tables-expire-journal-table-records.md)」を参照してください。
+ メタデータテーブル設定は、汎用バケット全体に対してのみ作成できます。プレフィックスレベルでメタデータテーブル設定を適用することはできません。
+ メタデータテーブルの更新を一時停止および再開することはできません。ただし、ジャーナルテーブルまたはライブインベントリテーブルの関連付けられたメタデータ設定は削除できます。設定を削除しても、関連付けられたジャーナルまたはインベントリテーブルは削除されません。設定を再作成するには、まず古いジャーナルテーブルまたはインベントリテーブルを削除してから、Amazon S3 で新しいジャーナルテーブルまたはインベントリテーブルを作成できます。インベントリテーブルを再度有効にすると、Amazon S3 は新しいインベントリテーブルを作成し、新しいインベントリテーブルのバックフィルに対して再度課金されます。
+ メタデータテーブルには、S3 インベントリまたは Amazon S3 REST API で利用できるメタデータと同じものがすべて含まれているわけではありません。例えば、次の情報はメタデータテーブルでは使用できません。
+ S3 ライフサイクルの有効期限または移行ステータス
+ Object Lock の保持期間またはガバナンスモード
+ オブジェクトのアクセスコントロールリスト (ACL) 情報
+ レプリケーションステータス
+ Amazon Athena または Amazon Redshift を使用してメタデータテーブルをクエリする場合は、メタデータテーブルの名前空間名を引用符 (`"`) またはバックティック (```) で囲む必要があります。囲まない場合、クエリが機能しない可能性があります。例については「[メタデータテーブルクエリの例](metadata-tables-example-queries.md)」を参照してください。
+ Amazon EMR または他のサードパーティーエンジンで Apache Spark を使用してメタデータテーブルをクエリする場合は、Amazon S3 Tables Iceberg REST エンドポイントを使用することをお勧めします。このエンドポイントを使用しないと、クエリが正常に実行されない可能性があります。詳細については、「[Amazon S3 Tables Iceberg REST エンドポイントを使用したテーブルへのアクセス](s3-tables-integrating-open-source.md)」を参照してください。
## S3 メタデータ AWS リージョン
S3 メタデータは現在、次の AWS リージョンで利用可能です。
| AWS リージョン 名 | AWS リージョン コード |
| --- | --- |
| アフリカ (ケープタウン) | `af-south-1` |
| アジアパシフィック (香港) | `ap-east-1` |
| アジアパシフィック (ジャカルタ) | `ap-southeast-3` |
| アジアパシフィック (メルボルン) | `ap-southeast-4` |
| アジアパシフィック (ムンバイ) | `ap-south-1` |
| アジアパシフィック (大阪) | `ap-northeast-3` |
| アジアパシフィック (ソウル) | `ap-northeast-2` |
| アジアパシフィック (シンガポール) | `ap-southeast-1` |
| アジアパシフィック (シドニー) | `ap-southeast-2` |
| アジアパシフィック (東京) | `ap-northeast-1` |
| カナダ (中部) | `ca-central-1` |
| カナダ西部 (カルガリー) | `ca-west-1` |
| 欧州 (フランクフルト) | `eu-central-1` |
| 欧州 (チューリッヒ) | `eu-central-2` |
| 欧州 (アイルランド) | `eu-west-1` |
| 欧州 (ロンドン) | `eu-west-2` |
| 欧州 (ミラノ) | `eu-south-1` |
| 欧州 (パリ) | `eu-west-3` |
| 欧州 (スペイン) | `eu-south-2` |
| 欧州 (ストックホルム) | `eu-north-1` |
| イスラエル (テルアビブ) | `il-central-1` |
| 中東 (バーレーン) | `me-south-1` |
| 中東 (アラブ首長国連邦) | `me-central-1` |
| 南米 (サンパウロ) | `sa-east-1` |
| 米国東部 (バージニア北部) | `us-east-1` |
| 米国東部 (オハイオ) | `us-east-2` |
| 米国西部 (北カリフォルニア) | `us-west-1` |
| 米国西部 (オレゴン) | `us-west-2` |
# S3 Metadata ジャーナルテーブルスキーマ
ジャーナルテーブルは、データに加えられた変更をほぼリアルタイムで記録するため、バケットにアップロードされた新しいデータの特定、最近削除されたオブジェクトの追跡、ライフサイクルの移行のモニタリングなどに役立ちます。ジャーナルテーブルには、新しいオブジェクトと、オブジェクトとそのメタデータに対する更新 (`PUT` または `DELETE` オペレーションを必要とする更新) が記録されます。このテーブルはクエリ可能であるため、単純な SQL クエリを使用してバケットへの変更を監査できます。
セキュリティ、監査、コンプライアンスのユースケースにジャーナルテーブルを使用して、バケット内のアップロード、削除、変更されたオブジェクトを追跡できます。例えば、ジャーナルテーブルにクエリを実行して、次のような質問に答えることができます。
+ S3 ライフサイクルによって過去 24 時間に削除されたオブジェクトはどれか。
+ 最新の `PUT` リクエストはどの IP アドレスから送信されたか。
+ 過去 7 日間に `PUT` リクエストに使用された AWS Key Management Service (AWS KMS) キーはどれか。
+ バケット内のどのオブジェクトが Amazon Bedrock によって過去 5 日間に作成されたものか。
Amazon S3 Metadata ジャーナルテーブルには行と列が含まれています。各行は、汎用バケット内のオブジェクトを作成、更新、または削除したミューテーションイベントを表します。これらのイベントの大部分はユーザーアクションの結果ですが、これらのイベントの一部は、S3 ライフサイクルの有効期限切れやストレージクラスの移行など、Amazon S3 がユーザーに代わって実行したアクションの結果です。
S3 Metadata ジャーナルテーブルは、最終的に汎用バケットで発生した変更と一致します。オブジェクトが作成または更新されたことが S3 Metadata に通知されるまでに、そのオブジェクトがバケットで既に上書きまたは削除されている場合があります。このような場合、オブジェクトを取得できなくなり、一部の列にメタデータスキーマが欠落していることを示す NULL 値が表示されることがあります。
以下は、`amzn-s3-demo-bucket:` という名前の汎用バケットのジャーナルテーブルの例です。
```
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
amzn-s3-demo-bucket Finance/statement1.pdf 80e737d8b4d82f776affffffffffffffff006737d8b4d82f776a00000000000000000000000000000000000000000000000072 CREATE 2024-11-15 23:26:44.899 FALSE 6223 11/15/2024 23:26 e131b86632dda753aac4018f72192b83 STANDARD FALSE SSE-KMS FALSE arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890df SSECRC32 {} {count -> Asia, customs -> false, family -> true, location -> Mary, name -> football, user -> United States} 111122223333 192.0.2.1 CVK8FWYRW0M9JW65
amzn-s3-demo-bucket s3-dg.pdf 80e737d8b4e39f1dbdffffffffffffffff006737d8b4e39f1dbd00000000000000000000000000000000000000000000000072 CREATE 2024-11-15 23:26:44.942 FALSE 3554 11/15/2024 23:26 9bb49efc2d92c05558ddffbbde8636d5 STANDARD FALSE DSSE-KMS FALSE arn:aws:kms:us-east-1:936810216292:key/0dcebce6-49fd-4cae-b2e2-5512ad281afd SSESHA1 {} {} 111122223333 192.0.2.1 CVKAQDRAZEG7KXAY
amzn-s3-demo-bucket Development/Projects.xls 80e737d8b4ed9ac5c6ffffffffffffffff006737d8b4ed9ac5c600000000000000000000000000000000000000000000000072 CREATE 2024-11-15 23:26:44.966 FALSE 7746 11/15/2024 23:26 729a6863e47fb9955b31bfabce984908 STANDARD FALSE SSE-S3 FALSE NULL SSECRC32 {} {count -> Asia, customs -> Canada, family -> Billiards, filter -> true, location -> Europe, name -> Asia, user -> United States} 111122223333 192.0.2.1 CVK7Z6XQTQ90BSRV
```
ジャーナルテーブルには次のスキーマがあります。
| 列名 | 必須? | データ型 | |
| --- | --- | --- | --- |
| `bucket` | はい | String | 汎用バケット名。詳細については、「[汎用バケットの命名規則](bucketnamingrules.md)」を参照してください。 |
| `key` | はい | String | バケット内のオブジェクトを一意に識別するオブジェクトのキー名 (またはキー)。詳細については、「[Amazon S3 オブジェクトに命名する](object-keys.md)」を参照してください。 |
| `sequence_number` | はい | String | シーケンス番号。特定のオブジェクトのレコードに含まれる序数です。同じバケットとキーのレコードを順に並べるには、`sequence_number` でソートできます。特定のバケットとキーについて、`sequence_number` 値が辞書順で大きいほど、レコードがより最近バケットに導入されたことを意味します。 |
| `record_type` | はい | String | このレコードのタイプ。`CREATE`、`UPDATE_METADATA`、または `DELETE` のいずれかです。 `CREATE` レコードは、新しいオブジェクト (またはオブジェクトの新しいバージョン) がバケットに書き込まれたことを示します。 `UPDATE_METADATA` レコードは、ストレージクラスやタグなど、既存のオブジェクトの変更可能なメタデータへの変更をキャプチャします。 `DELETE` レコードは、このオブジェクト (またはオブジェクトのこのバージョン) が削除されたことを示します。バージョニングが有効になっている場合、`DELETE` レコードは削除マーカーまたは永続的な削除のいずれかを表します。オプションの `is_delete_marker` 列を参照することで、さらに曖昧さが解消されます。 詳細については、「[バージョニングが有効なバケットからのオブジェクトバージョンの削除](DeletingObjectVersions.md)」を参照してください。 永続的な削除では、`bucket`、`key`、`sequence_number`、`record_type`、`record_timestamp`、および `version_id` (つまり、必須とマークされた列) を*除く*すべての列に `NULL` が保持されます。 |
| `record_timestamp` | はい | Timestamp NTZ (タイムゾーンなし) | このレコードに関連付けられているタイムスタンプ。 |
| `version_id` | いいえ | String | オブジェクトのバージョン ID。バケットのバージョニングを有効にすると、Amazon S3 はバケットに追加されたオブジェクトにバージョン番号を割り当てます。詳細については、「[S3 バージョニングによる複数のバージョンのオブジェクトの保持](Versioning.md)」を参照してください。 バージョニング状態を設定する前にバケットに保存されたオブジェクトのバージョン ID は null です。 |
| `is_delete_marker` | いいえ | ブール値 | オブジェクトの削除マーカーのステータス。削除マーカーである DELETE レコードの場合、この値は `TRUE` です。永続的な削除の場合、この値は省略されます (`NULL`)。他のレコードタイプ (CREATE および UPDATE\$1METADATA) には値 `FALSE` があります。詳細については、「[削除マーカーの使用](DeleteMarker.md)」を参照してください。 削除マーカーに追加される行の `record_type` 値は `DELETE` ではなく `UPDATE_METADATA` です。S3 ライフサイクルの有効期限が切れた結果として削除マーカーが作成された場合、`requester` 値は `s3.amazonaws.com` です。 |
| `size` | いいえ | Long | バイト単位のオブジェクトサイズ。不完全なマルチパートアップロードまたはオブジェクトメタデータのサイズは含まれません。`is_delete_marker` が `TRUE` の場合、サイズは `0` です。詳細については、「[システムで定義されたオブジェクトメタデータ](UsingMetadata.md#SysMetadata)」を参照してください。 |
| `last_modified_date` | いいえ | Timestamp NTZ (タイムゾーンなし) | オブジェクト作成日または最終更新日のいずれか遅い方。マルチパートアップロードの場合、オブジェクトの作成日はマルチパートアップロードが開始された日付です。詳細については、「[システムで定義されたオブジェクトメタデータ](UsingMetadata.md#SysMetadata)」を参照してください。 |
| `e_tag` | いいえ | String | エンティティタグ (ETag) は、オブジェクトのハッシュです。ETag は、変更をオブジェクトのコンテンツにのみ反映し、メタデータには反映しません。ETag は、オブジェクトデータの MD5 ダイジェストである場合があります。ETag が MD5 ダイジェストであるかどうかは、オブジェクトの作成方法と暗号化方法によって異なります。詳細については、「**Amazon S3 API リファレンス」の「[https://docs.aws.amazon.com/AmazonS3/latest/API/API_Object.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_Object.html)」を参照してください。 |
| `storage_class` | いいえ | String | オブジェクトの保存に使用されるストレージクラス。`STANDARD`、`REDUCED_REDUNDANCY`、`STANDARD_IA`、`ONEZONE_IA`、`INTELLIGENT_TIERING`、`GLACIER`、`DEEP_ARCHIVE`、`GLACIER_IR` のいずれかです。詳細については、「[Amazon S3 ストレージクラスの理解と管理](storage-class-intro.md)」を参照してください。 |
| `is_multipart` | いいえ | ブール値 | オブジェクトのアップロードタイプ。オブジェクトがマルチパートアップロードとしてアップロードされた場合、この値は `TRUE` です。それ以外の場合は、`FALSE` です。詳細については、「[Amazon S3 でのマルチパートアップロードを使用したオブジェクトのアップロードとコピー](mpuoverview.md)」を参照してください。 |
| `encryption_status` | いいえ | String | 使用される暗号化キーの種類に応じた、オブジェクトのサーバー側の暗号化ステータス。Amazon S3 マネージドキーによるサーバー側の暗号化 (SSE-S3)、AWS Key Management Service (AWS KMS) キーによるサーバー側の暗号化 (SSE-KMS)、AWS KMS keys による二層式サーバー側の暗号化 (DSSE-KMS)、またはお客様が指定したキーによるサーバー側の暗号化 (SSE-C) のいずれかとなります。オブジェクトが暗号化されていない場合、この値は null です。可能な値は、`SSE-S3`、`SSE-KMS`、`DSSE-KMS`、`SSE-C`、または null です。詳細については、「[暗号化によるデータの保護](UsingEncryption.md)」を参照してください。 |
| `is_bucket_key_enabled` | いいえ | ブール値 | オブジェクトの S3 バケットキーの有効化ステータス。オブジェクトが SSE-KMS に S3 バケットキーを使用する場合、この値は `TRUE` です。それ以外の場合は、`FALSE` です。詳細については、「[オブジェクトレベルで S3 バケットキーを設定する](configuring-bucket-key-object.md)」を参照してください。 |
| `kms_key_arn` | いいえ | String | `encryption_status` が `SSE-KMS` または `DSSE-KMS` の行の場合、オブジェクトの暗号化に使用される KMS キーの Amazon リソースネーム (ARN)。オブジェクトが SSE-KMS または DSSE-KMS で暗号化されていない場合、値は null です。詳細については、「[AWS KMS キーによるサーバー側の暗号化 (SSE-KMS) の使用](UsingKMSEncryption.md)」および「[AWS KMS キーによる二層式サーバー側の暗号化 (DSSE-KMS) の使用](UsingDSSEncryption.md)」を参照してください。 行が、削除または上書きイベントが処理された時点で存在しなくなったオブジェクトバージョンを表す場合、`encryption_status` 列の値が `SSE-KMS` または `DSSE-KMS` であっても、`kms_key_arn` には null 値が含まれます。 |
| `checksum_algorithm` | いいえ | String | オブジェクトのチェックサムを作成するために使用されるアルゴリズム。`CRC64NVME`、`CRC32`、`CRC32C`、`SHA1`、または `SHA256` のいずれかです。チェックサムが存在しない場合、この値は null です。詳細については、「[サポートされているチェックサムアルゴリズムの使用](checking-object-integrity-upload.md#using-additional-checksums)」を参照してください。 |
| `object_tags` | いいえ | Map | オブジェクトに関連付けられたオブジェクトタグ。オブジェクトタグは、キーと値のペアのマップとして保存されます。オブジェクトにオブジェクトタグがない場合、空のマップ (`{}`) が保存されます。詳細については、「[タグを使用したオブジェクトの分類](object-tagging.md)」を参照してください。 `record_type` 値が `DELETE` の場合、`object_tags` 列には null 値が含まれます。`record_type` 値が `CREATE` または `UPDATE_METADATA` の場合、削除または上書きイベントが処理された時点で存在しなくなったオブジェクトバージョンを表す行には、`object_tags` 列に null 値が含まれます。 |
| `user_metadata` | いいえ | Map | オブジェクトに関連付けられているユーザーメタデータ。ユーザーメタデータは、キーと値のペアのマップとして保存されます。オブジェクトにユーザーメタデータがない場合、空のマップ (`{}`) が保存されます。詳細については、「[ユーザー定義のオブジェクトメタデータ](UsingMetadata.md#UserMetadata)」を参照してください。 `record_type` 値が `DELETE` の場合、`user_metadata` 列には null 値が含まれます。`record_type` 値が `CREATE` または `UPDATE_METADATA` の場合、削除または上書きイベントが処理された時点で存在しなくなったオブジェクトバージョンを表す行には、`user_metadata` 列に null 値が含まれます。 |
| `requester` | いいえ | String | リクエストを行ったリクエスタまたは AWS のサービスプリンシパルの AWS アカウント ID。例えば、リクエスタが S3 ライフサイクルの場合、この値は `s3.amazonaws.com` です。 |
| `source_ip_address` | いいえ | String | リクエストの送信元 IP アドレス。ユーザーリクエストによって生成されたレコードの場合、この列にはリクエストの送信元 IP アドレスが含まれます。ユーザーに代わって Amazon S3 または別の AWS のサービスによって実行されたアクションの場合、この列には null 値が含まれます。 |
| `request_id` | いいえ | String | リクエストに関連付けられたリクエスト ID。 |
# S3 Metadata ライブインベントリテーブルスキーマ
ライブインベントリテーブルは、バケット内のすべてのオブジェクトとそのバージョンのシンプルでクエリ可能なインベントリを提供するため、データの最新の状態を判断できます。オブジェクトの更新は、通常 1 時間以内にインベントリテーブルに反映されます。
このテーブルを使用すると、さまざまなワークロードに対して処理するオブジェクトを特定することで、ビジネスワークフローとビッグデータジョブを簡素化および高速化できます。例えば、インベントリテーブルをクエリして、以下を実行できます。
+ S3 Glacier Deep Archive ストレージクラスに保存されているすべてのオブジェクトを検索します。
+ オブジェクトタグのディストリビューションを作成するか、タグなしでオブジェクトを検索します。
+ AWS Key Management Service (AWS KMS) キーによるサーバー側の暗号化 (SSE-KMS) を使用して暗号化されていないすべてのオブジェクトを検索します。
メタデータテーブル設定のインベントリテーブルを有効にすると、テーブルは*バックフィル*と呼ばれるプロセスを実行し、そのプロセス中に Amazon S3 は汎用バケットをスキャンして、バケット内のすべてのオブジェクトの初期メタデータを取得します。バケット内のオブジェクトの数によっては、このプロセスに数分 (最小 15 分) から数時間かかる場合があります。バックフィルプロセスが完了すると、インベントリテーブルのステータスが **[バックフィル]** から **[アクティブ]** に変わります。バックフィルが完了すると、通常、オブジェクトの更新は 1 時間以内にインベントリテーブルに反映されます。
**注記**
インベントリテーブルのバックフィルの実行は課金されます。汎用バケットに 10 億個を超えるオブジェクトがある場合は、インベントリテーブルの月額料金も請求されます。詳細については、[Amazon S3 の料金](https://aws.amazon.com/s3/pricing/) を参照してください。
Amazon S3 Metadata インベントリテーブルには行と列が含まれています。各行は、汎用バケット内のオブジェクトの現在の状態を表します。インベントリテーブルは、バケット内のすべてのオブジェクトのシンプルでクエリ可能なインベントリを提供するため、データの現在の状態を判断できます。
以下は、`amzn-s3-demo-bucket:` という名前の汎用バケットのインベントリテーブルの例です。
```
bucket key sequence_number 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
amzn-s3-demo-bucket Finance/statement1.pdf 80e737d8b4d82f776affffffffffffffff006737d8b4d82f776a00000000000000000000000000000000000000000000000072 FALSE 6223 11/15/2024 23:26 e131b86632dda753aac4018f72192b83 STANDARD FALSE SSE-KMS FALSE arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890df SSECRC32 {} {count -> Asia, customs -> false, family -> true, location -> Mary, name -> football, user -> United States}
amzn-s3-demo-bucket s3-dg.pdf 80e737d8b4e39f1dbdffffffffffffffff006737d8b4e39f1dbd00000000000000000000000000000000000000000000000072 FALSE 3554 11/15/2024 23:26 9bb49efc2d92c05558ddffbbde8636d5 STANDARD FALSE DSSE-KMS FALSE arn:aws:kms:us-east-1:936810216292:key/0dcebce6-49fd-4cae-b2e2-5512ad281afd SSESHA1 {} {}
amzn-s3-demo-bucket Development/Projects.xls 80e737d8b4ed9ac5c6ffffffffffffffff006737d8b4ed9ac5c600000000000000000000000000000000000000000000000072 FALSE 7746 11/15/2024 23:26 729a6863e47fb9955b31bfabce984908 STANDARD FALSE SSE-S3 FALSE NULL SSECRC32 {} {count -> Asia, customs -> Canada, family -> Billiards, filter -> true, location -> Europe, name -> Asia, user -> United States}
```
インベントリテーブルには次のスキーマがあります。
| 列名 | 必須? | データ型 | |
| --- | --- | --- | --- |
| `bucket` | はい | String | 汎用バケット名。詳細については、「[汎用バケットの命名規則](bucketnamingrules.md)」を参照してください。 |
| `key` | はい | String | バケット内のオブジェクトを一意に識別するオブジェクトのキー名 (またはキー)。詳細については、「[Amazon S3 オブジェクトに命名する](object-keys.md)」を参照してください。 |
| `sequence_number` | はい | String | シーケンス番号。特定のオブジェクトのレコードに含まれる序数です。同じバケットとキーのレコードを順に並べるには、`sequence_number` でソートできます。特定のバケットとキーについて、`sequence_number` 値が辞書順で大きいほど、レコードがより最近バケットに導入されたことを意味します。 |
| `version_id` | いいえ | String | オブジェクトのバージョン ID。バケットのバージョニングを有効にすると、Amazon S3 はバケットに追加されたオブジェクトにバージョン番号を割り当てます。詳細については、「[S3 バージョニングによる複数のバージョンのオブジェクトの保持](Versioning.md)」を参照してください。 バージョニング状態を設定する前にバケットに保存されたオブジェクトのバージョン ID は null です。 |
| `is_delete_marker` | いいえ | ブール値 | オブジェクトの削除マーカーのステータス。オブジェクトが削除マーカーの場合、この値は `True` です。それ以外の場合は、`False` です。詳細については、「[削除マーカーの使用](DeleteMarker.md)」を参照してください。 削除マーカーに追加される行の `record_type` 値は `DELETE` ではなく `UPDATE_METADATA` です。S3 ライフサイクルの有効期限が切れた結果として削除マーカーが作成された場合、`requester` 値は `s3.amazonaws.com` です。 |
| `size` | いいえ | Long | バイト単位のオブジェクトサイズ。不完全なマルチパートアップロードまたはオブジェクトメタデータのサイズは含まれません。`is_delete_marker` が `True` の場合、サイズは `0` です。詳細については、「[システムで定義されたオブジェクトメタデータ](UsingMetadata.md#SysMetadata)」を参照してください。 |
| `last_modified_date` | いいえ | Timestamp NTZ (タイムゾーンなし) | オブジェクト作成日または最終更新日のいずれか遅い方。マルチパートアップロードの場合、オブジェクトの作成日はマルチパートアップロードが開始された日付です。詳細については、「[システムで定義されたオブジェクトメタデータ](UsingMetadata.md#SysMetadata)」を参照してください。 |
| `e_tag` | いいえ | String | エンティティタグ (ETag) は、オブジェクトのハッシュです。ETag は、変更をオブジェクトのコンテンツにのみ反映し、メタデータには反映しません。ETag は、オブジェクトデータの MD5 ダイジェストである場合があります。ETag が MD5 ダイジェストであるかどうかは、オブジェクトの作成方法と暗号化方法によって異なります。詳細については、「**Amazon S3 API リファレンス」の「[https://docs.aws.amazon.com/AmazonS3/latest/API/API_Object.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_Object.html)」を参照してください。 |
| `storage_class` | いいえ | String | オブジェクトの保存に使用されるストレージクラス。`STANDARD`、`REDUCED_REDUNDANCY`、`STANDARD_IA`、`ONEZONE_IA`、`INTELLIGENT_TIERING`、`GLACIER`、`DEEP_ARCHIVE`、`GLACIER_IR` のいずれかです。詳細については、「[Amazon S3 ストレージクラスの理解と管理](storage-class-intro.md)」を参照してください。 |
| `is_multipart` | いいえ | ブール値 | オブジェクトのアップロードタイプ。オブジェクトがマルチパートアップロードとしてアップロードされた場合、この値は `True` です。それ以外の場合は、`False` です。詳細については、「[Amazon S3 でのマルチパートアップロードを使用したオブジェクトのアップロードとコピー](mpuoverview.md)」を参照してください。 |
| `encryption_status` | いいえ | String | 使用される暗号化キーの種類に応じた、オブジェクトのサーバー側の暗号化ステータス。Amazon S3 マネージドキーによるサーバー側の暗号化 (SSE-S3)、AWS Key Management Service (AWS KMS) キーによるサーバー側の暗号化 (SSE-KMS)、AWS KMS keys による二層式サーバー側の暗号化 (DSSE-KMS)、またはお客様が指定したキーによるサーバー側の暗号化 (SSE-C) のいずれかとなります。オブジェクトが暗号化されていない場合、この値は null です。可能な値は、`SSE-S3`、`SSE-KMS`、`DSSE-KMS`、`SSE-C`、または null です。詳細については、「[暗号化によるデータの保護](UsingEncryption.md)」を参照してください。 |
| `is_bucket_key_enabled` | いいえ | ブール値 | オブジェクトの S3 バケットキーの有効化ステータス。オブジェクトが SSE-KMS に S3 バケットキーを使用する場合、この値は `True` です。それ以外の場合は、`False` です。詳細については、「[オブジェクトレベルで S3 バケットキーを設定する](configuring-bucket-key-object.md)」を参照してください。 |
| `kms_key_arn` | いいえ | String | `encryption_status` が `SSE-KMS` または `DSSE-KMS` の行の場合、オブジェクトの暗号化に使用される KMS キーの Amazon リソースネーム (ARN)。オブジェクトが SSE-KMS または DSSE-KMS で暗号化されていない場合、値は null です。詳細については、「[AWS KMS キーによるサーバー側の暗号化 (SSE-KMS) の使用](UsingKMSEncryption.md)」および「[AWS KMS キーによる二層式サーバー側の暗号化 (DSSE-KMS) の使用](UsingDSSEncryption.md)」を参照してください。 行が、削除または上書きイベントが処理された時点で存在しなくなったオブジェクトバージョンを表す場合、`encryption_status` 列の値が `SSE-KMS` または `DSSE-KMS` であっても、`kms_key_arn` には null 値が含まれます。 |
| `checksum_algorithm` | いいえ | String | オブジェクトのチェックサムを作成するために使用されるアルゴリズム。`CRC64-NVME`、`CRC32`、`CRC32C`、`SHA1`、または `SHA256` のいずれかです。チェックサムが存在しない場合、この値は null です。詳細については、「[サポートされているチェックサムアルゴリズムの使用](checking-object-integrity-upload.md#using-additional-checksums)」を参照してください。 |
| `object_tags` | いいえ | Map | オブジェクトに関連付けられたオブジェクトタグ。オブジェクトタグは、キーと値のペアのマップとして保存されます。オブジェクトにオブジェクトタグがない場合、空のマップ (`{}`) が保存されます。詳細については、「[タグを使用したオブジェクトの分類](object-tagging.md)」を参照してください。 `record_type` 値が `DELETE` の場合、`object_tags` 列には null 値が含まれます。`record_type` 値が `CREATE` または `UPDATE_METADATA` の場合、削除または上書きイベントが処理された時点で存在しなくなったオブジェクトバージョンを表す行には、`object_tags` 列に null 値が含まれます。 |
| `user_metadata` | いいえ | Map | オブジェクトに関連付けられているユーザーメタデータ。ユーザーメタデータは、キーと値のペアのマップとして保存されます。オブジェクトにユーザーメタデータがない場合、空のマップ (`{}`) が保存されます。詳細については、「[ユーザー定義のオブジェクトメタデータ](UsingMetadata.md#UserMetadata)」を参照してください。 `record_type` 値が `DELETE` の場合、`user_metadata` 列には null 値が含まれます。`record_type` 値が `CREATE` または `UPDATE_METADATA` の場合、削除または上書きイベントが処理された時点で存在しなくなったオブジェクトバージョンを表す行には、`user_metadata` 列に null 値が含まれます。 |
# メタデータテーブルの設定
Amazon S3 メタデータは、汎用バケット内のオブジェクトのメタデータを自動的にキャプチャし、クエリできる読み取り専用のフルマネージド Apache Iceberg テーブルに保存することで、データ検出を高速化します。これらの読み取り専用テーブルは*メタデータテーブル*と呼ばれます。オブジェクトが汎用バケットに追加、更新、削除されると、S3 メタデータは対応するメタデータテーブルを自動的に更新して、最新の変更を反映します。
S3 メタデータを使用すると、S3 オブジェクトのメタデータを簡単に検索、保存、クエリできるため、ビジネス分析、人工知能と機械学習 (AI/ML) モデルトレーニングなどで使用するデータをすばやく準備できます。
オブジェクトメタデータを生成して AWS マネージドメタデータテーブルに保存するには、汎用バケットのメタデータテーブル設定を作成します。Amazon S3 は、バケットで設定がアクティブである限り、メタデータテーブルを継続的に更新してデータへの最新の変更を反映するように設計されています。さらに、Amazon S3 はメタデータテーブルを継続的に最適化して、ストレージコストを削減し、分析クエリのパフォーマンスを向上させます。
メタデータテーブル設定を作成するには、メタデータテーブルを作成および管理するために必要な AWS Identity and Access Management (IAM) アクセス許可があることを確認してください。
メタデータテーブル設定の更新をモニタリングするには、AWS CloudTrail を使用できます。詳細については、「[CloudTrail ログ記録によって追跡される Amazon S3 バケットレベルのアクション](cloudtrail-logging-s3-info.md#cloudtrail-bucket-level-tracking)」を参照してください。
**Topics**
+ [
# メタデータテーブルを設定するためのアクセス許可の設定
](metadata-tables-permissions.md)
+ [
# メタデータテーブル設定の作成
](metadata-tables-create-configuration.md)
+ [
# メタデータテーブルへのアクセスの制御
](metadata-tables-access-control.md)
+ [
# ジャーナルテーブルレコードを期限切れにする
](metadata-tables-expire-journal-table-records.md)
+ [
# ライブインベントリテーブルを有効または無効にする
](metadata-tables-enable-disable-inventory-tables.md)
+ [
# メタデータテーブル設定の表示
](metadata-tables-view-configuration.md)
+ [
# メタデータテーブル設定の削除
](metadata-tables-delete-configuration.md)
+ [
# メタデータテーブルの削除
](metadata-tables-delete-table.md)
# メタデータテーブルを設定するためのアクセス許可の設定
メタデータテーブル設定を作成するには、メタデータテーブル設定の作成と管理、およびメタデータテーブルとメタデータテーブルが保存されているテーブルバケットの作成と管理の両方に必要な AWS Identity and Access Management (IAM) アクセス許可を持っている必要があります。
メタデータテーブル設定を作成および管理するには、次のアクセス許可が必要です。
+ `s3:CreateBucketMetadataTableConfiguration` – このアクセス許可により、汎用バケットのメタデータテーブル設定を作成できます。メタデータテーブル設定を作成するには、次のセクションで説明するように、S3 Tables のアクセス許可を含む追加のアクセス許可が必要です。必要なアクセス許可のリストについては、「[バケットオペレーションとアクセス許可](using-with-s3-policy-actions.md#using-with-s3-policy-actions-related-to-buckets)」を参照してください。
+ `s3:GetBucketMetadataTableConfiguration` – このアクセス許可により、メタデータテーブル設定に関する情報を取得できます。
+ `s3:DeleteBucketMetadataTableConfiguration` – このアクセス許可により、メタデータテーブル設定を削除できます。
+ `s3:UpdateBucketMetadataJournalTableConfiguration` – このアクセス許可により、ジャーナルテーブル設定を更新してジャーナルテーブルレコードを期限切れにすることができます。
+ `s3:UpdateBucketMetadataInventoryTableConfiguration` – このアクセス許可により、インベントリテーブルの設定を更新して、インベントリテーブルを有効または無効にできます。インベントリテーブル設定を更新するには、S3 Tables のアクセス許可を含む追加のアクセス許可が必要です。必要なアクセス権限のリストについては、「[バケットオペレーションとアクセス許可](using-with-s3-policy-actions.md#using-with-s3-policy-actions-related-to-buckets)」を参照してください。
**注記**
`s3:CreateBucketMetadataTableConfiguration`、`s3:GetBucketMetadataTableConfiguration`、および `s3:DeleteBucketMetadataTableConfiguration` アクセス許可は、V1 と V2 両方の S3 Metadata 設定に使用されます。V2 の場合、対応する API オペレーションの名前は `CreateBucketMetadataConfiguration`、`GetBucketMetadataConfiguration`、および `DeleteBucketMetadataConfiguration` です。
テーブルとテーブルバケットを作成して操作するには、特定の `s3tables` アクセス許可が必要です。メタデータテーブル設定を作成するには、少なくとも次の `s3tables` アクセス許可が必要です。
+ `s3tables:CreateTableBucket` – このアクセス許可により、AWS マネージドテーブルバケットを作成できます。アカウントと同じリージョンのすべてのメタデータテーブル設定は、`aws-s3` という名前の単一の AWS マネージドテーブルバケットに保存されます。詳細については、「[メタデータテーブルの仕組み](metadata-tables-overview.md#metadata-tables-how-they-work)」および「[AWS マネージドテーブルバケットの使用](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-aws-managed-buckets.html)」を参照してください。
+ `s3tables:CreateNamespace` – このアクセス許可により、テーブルバケットに名前空間を作成できます。メタデータテーブルは通常、`b_general_purpose_bucket_name` 名前空間を使用します。メタデータテーブル名前空間の詳細については、「[メタデータテーブルの仕組み](metadata-tables-overview.md#metadata-tables-how-they-work)」を参照してください。
+ `s3tables:CreateTable` – このアクセス許可により、メタデータテーブルを作成できます。
+ `s3tables:GetTable` – このアクセス許可により、メタデータテーブルに関する情報を取得できます。
+ `s3tables:PutTablePolicy` – このアクセス許可により、メタデータテーブルポリシーを追加または更新できます。
+ `s3tables:PutTableEncryption` – このアクセス許可により、メタデータテーブルのサーバー側の暗号化を設定できます。AWS Key Management Service (AWS KMS) キーによるサーバー側の暗号化 (SSE-KMS) を使用してメタデータテーブルを暗号化する場合は、追加のアクセス許可が必要です。詳細については、「[SSE-KMS のアクセス許可](#metadata-kms-permissions)」を参照してください。
+ `kms:DescribeKey` – このアクセス許可により、KMS キーに関する情報を取得できます。
+ `s3tables:PutTableBucketPolicy` – このアクセス許可により、新しいテーブルバケットポリシーを作成または更新できます。
すべてのテーブルとテーブルバケットのアクセス許可の詳細については、「[Access management for S3 Tables](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-setting-up.html)」を参照してください。
**重要**
メタデータテーブルをクエリできるようにテーブルバケットを AWS 分析サービスと統合する場合は、追加のアクセス許可が必要です。詳細については、「[Integrating Amazon S3 Tables with AWS analytics services](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-integrating-aws.html)」を参照してください。
**SSE-KMS のアクセス許可**
AWS Key Management Service (AWS KMS) キーによるサーバー側の暗号化 (SSE-KMS) を使用してメタデータテーブルを暗号化するには、追加のアクセス許可が必要です。
1. ユーザーまたは AWS Identity and Access Management IAM ロールには以下のアクセス許可が必要です。IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を使用してこれらのアクセス許可を付与できます。
1. テーブル暗号化を設定する `s3tables:PutTableEncryption`
1. 使用する AWS KMS キーの `kms:DescribeKey`
1. KMS キーのリソースポリシーでは、次のアクセス許可が必要です。AWS KMS コンソール ([https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms)) を使用してこれらのアクセス許可を付与できます。
1. `metadata.s3.amazonaws.com` および `maintenance.s3tables.amazonaws.com` に `kms:GenerateDataKey` アクセス許可を付与します。
1. `metadata.s3.amazonaws.com` および `maintenance.s3tables.amazonaws.com` に `kms:Decrypt` アクセス許可を付与します。
1. 呼び出し AWS プリンシパルへの `kms:DescribeKey` アクセス許可を付与します。
これらのアクセス許可に加えて、テーブルの暗号化に使用されるカスタマーマネージド KMS キーがまだ存在し、アクティブであり、汎用バケットと同じリージョンにあることを確認します。
**ポリシーの例**
メタデータテーブルとテーブルバケットを作成して操作するには、次のポリシー例を使用できます。このポリシーでは、メタデータテーブル設定を適用する汎用バケットを `amzn-s3-demo-bucket` と呼びます。このポリシーを使用するには、`user input placeholders` をユーザー自身の情報に置き換えます。
メタデータテーブル設定を作成すると、メタデータテーブルは AWS マネージドテーブルバケットに保存されます。アカウントと同じリージョンのすべてのメタデータテーブル設定は、`aws-s3` という名前の単一の AWS マネージドテーブルバケットに保存されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PermissionsToWorkWithMetadataTables",
"Effect": "Allow",
"Action": [
"s3:CreateBucketMetadataTableConfiguration",
"s3:GetBucketMetadataTableConfiguration",
"s3:DeleteBucketMetadataTableConfiguration",
"s3:UpdateBucketMetadataJournalTableConfiguration",
"s3:UpdateBucketMetadataInventoryTableConfiguration",
"s3tables:*",
"kms:DescribeKey"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3tables:us-east-1:111122223333:bucket/aws-s3",
"arn:aws:s3tables:us-east-1:111122223333:bucket/aws-s3/table/*"
]
}
]
}
```
------
メタデータテーブルをクエリするには、次のポリシー例を使用できます。メタデータテーブルが SSE-KMS で暗号化されている場合は、次に示すように `kms:Decrypt` アクセス許可が必要です。このポリシーを使用するには、`user input placeholders` をユーザー自身の情報に置き換えます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PermissionsToQueryMetadataTables",
"Effect": "Allow",
"Action": [
"s3tables:GetTable",
"s3tables:GetTableData",
"s3tables:GetTableMetadataLocation",
"kms:Decrypt"
],
"Resource": [
"arn:aws:s3tables:us-east-1:111122223333:bucket/aws-s3",
"arn:aws:s3tables:us-east-1:111122223333:bucket/aws-s3/table/*"
]
}
]
}
```
------
# メタデータテーブル設定の作成
Amazon S3 Metadata を生成してフルマネージド Apache Iceberg メタデータテーブルに保存するには、汎用バケットのメタデータテーブル設定を作成します。Amazon S3 は、バケットで設定がアクティブである限り、メタデータテーブルを継続的に更新してデータへの最新の変更を反映するように設計されています。さらに、Amazon S3 はメタデータテーブルを継続的に最適化して、ストレージコストを削減し、分析クエリのパフォーマンスを向上させます。
汎用バケットごとに、2 つの補完メタデータテーブルを含むメタデータテーブル設定を作成できます。
+ **ジャーナルテーブル** – デフォルトでは、メタデータテーブル設定には、バケット内のオブジェクトで発生したイベントをキャプチャする*ジャーナルテーブル*が含まれます。ジャーナルテーブルは、データに加えられた変更をほぼリアルタイムで記録するため、バケットにアップロードされた新しいデータの特定、最近削除されたオブジェクトの追跡、ライフサイクルの移行のモニタリングなどに役立ちます。ジャーナルテーブルには、新しいオブジェクトと、オブジェクトとそのメタデータに対する更新 (`PUT` または `DELETE` オペレーションを必要とする更新) が記録されます。
ジャーナルテーブルは、メタデータテーブル設定を作成した後に発生する変更イベント (アップロード、更新、削除など) のメタデータのみをキャプチャします。このテーブルはクエリ可能であるため、単純な SQL クエリを使用してバケットへの変更を監査できます。
ジャーナルテーブルは、メタデータテーブル設定ごとに必要です。(S3 Metadata の初回リリースでは、ジャーナルテーブルは「メタデータテーブル」と呼ばれていました)。
ジャーナルテーブルに保存されるデータの詳細については、「[S3 Metadata ジャーナルテーブルスキーマ](metadata-tables-schema.md)」を参照してください。
ストレージコストを最小限に抑えるために、ジャーナルテーブルレコードの有効期限を有効にするように選択できます。詳細については、「[ジャーナルテーブルレコードを期限切れにする](metadata-tables-expire-journal-table-records.md)」を参照してください。
+ **ライブインベントリテーブル** – オプションで、メタデータテーブル設定に*ライブインベントリテーブル*を追加できます。ライブインベントリテーブルは、バケット内のすべてのオブジェクトとそのバージョンのシンプルでクエリ可能なインベントリを提供するため、データの最新の状態を判断できます。
ライブインベントリテーブルを使用すると、さまざまなワークロードに対して処理するオブジェクトを特定することで、ビジネスワークフローとビッグデータジョブを簡素化および高速化できます。例えば、ライブインベントリテーブルをクエリして、特定のストレージクラスに保存されているすべてのオブジェクト、特定のタグを持つすべてのオブジェクト、 AWS Key Management Service (AWS KMS) キー (SSE-KMS) を使用したサーバー側の暗号化で暗号化されていないすべてのオブジェクトなどを検索できます。
メタデータテーブル設定のライブインベントリテーブルを有効にすると、テーブルは*バックフィル*と呼ばれるプロセスを実行し、そのプロセス中に Amazon S3 は汎用バケットをスキャンして、バケットに存在するすべてのオブジェクトの初期メタデータを取得します。バケット内のオブジェクトの数によっては、このプロセスに数分 (最小 15 分) から数時間かかる場合があります。バックフィルプロセスが完了すると、ライブインベントリテーブルのステータスが **[バックフィル]** から **[アクティブ]** に変わります。バックフィルが完了すると、通常、オブジェクトの更新は 1 時間以内にライブインベントリテーブルに反映されます。
ライブインベントリテーブルのバックフィルの実行は課金されます。汎用バケットに 10 億個を超えるオブジェクトがある場合は、ライブインベントリテーブルの月額料金も請求されます。詳細については、[Amazon S3 の料金](https://aws.amazon.com/s3/pricing/) を参照してください。
ライブインベントリテーブルに保存されるデータの詳細については、「[S3 Metadata ライブインベントリテーブルスキーマ](metadata-tables-inventory-schema.md)」を参照してください。
メタデータテーブルには、メタデータテーブルのテーブル ID を含む次の Amazon リソースネーム (ARN) 形式があります。
`arn:aws:s3tables:region-code:account-id:bucket/aws-s3/table/table-id`
例えば、米国東部 (バージニア北部) リージョンのメタデータテーブルには、次のような ARN があります。
`arn:aws:s3tables:us-east-1:111122223333:bucket/aws-s3/table/a12bc345-67d8-912e-3456-7f89123g4h56`
ジャーナルテーブルの名前は `journal` で、ライブインベントリテーブルの名前は `inventory` です。
メタデータテーブル設定を作成すると、メタデータテーブルは AWS マネージドテーブルバケットに保存されます。アカウントと同じリージョンのすべてのメタデータテーブル設定は、単一の AWS マネージドテーブルバケットに保存されます。これらの AWS マネージドテーブルバケットの名前は `aws-s3` であり、Amazon リソースネーム (ARN) 形式は次のようになります。
`arn:aws:s3tables:region:account_id:bucket/aws-s3`
例えば、アカウント ID が 123456789012 で、汎用バケットが米国東部 (バージニア北部) (`us-east-1`) にある場合、AWS マネージドテーブルバケットも米国東部 (バージニア北部) (`us-east-1`) で作成され、次の ARN があります。
`arn:aws:s3tables:us-east-1:123456789012:bucket/aws-s3`
デフォルトでは、AWS マネージドテーブルバケットは、Amazon S3 マネージドキーによるサーバー側の暗号化 (SSE-S3) を使用して暗号化されます。最初のメタデータ設定を作成したら、AWS マネージドテーブルバケットのデフォルトの暗号化設定を設定して、AWS Key Management Service (AWS KMS) キーによるサーバー側の暗号化 (SSE-KMS) を使用できます。詳細については、「[Encryption for AWS managed table buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-aws-managed-buckets.html#aws-managed-buckets-encryption)」および「[テーブルバケットでの AWS KMS キーによるサーバー側の暗号化 (SSE-KMS) の指定](s3-tables-kms-specify.md)」を参照してください。
AWS マネージドテーブルバケット内では、設定のメタデータテーブルは通常、次の命名形式の名前空間に保存されます。
`b_general-purpose-bucket-name`
メタデータテーブル名前空間の詳細については、「[メタデータテーブルの仕組み](metadata-tables-overview.md#metadata-tables-how-they-work)」を参照してください。
メタデータテーブル設定を作成するときに、AWS マネージドメタデータテーブルを AWS Key Management Service (AWS KMS) キーを使用したサーバー側の暗号化 (SSE-KMS) で暗号化することを選択できます。SSE-KMS を使用する場合は、汎用バケットと同じリージョンにカスタマーマネージド KMS キーを指定する必要があります。テーブルの暗号化タイプは、テーブルの作成中にのみ設定できます。AWS マネージドテーブルの作成後は、暗号化設定を変更することはできません。メタデータテーブルに SSE-KMS を指定するには、特定のアクセス許可が必要です。詳細については、「[SSE-KMS のアクセス許可](metadata-tables-permissions.md#metadata-kms-permissions)」を参照してください。
メタデータテーブルの暗号化設定は、デフォルトのバケットレベルの暗号化設定よりも優先されます。暗号化を指定しない場合、テーブルはバケットのデフォルト暗号設定を継承します。
AWS マネージドテーブルバケットは、S3 Tables クォータにはカウントされません。AWS マネージドテーブルバケットと AWS マネージドテーブルの操作の詳細については、「[Working with AWS managed table buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-aws-managed-buckets.html)」を参照してください。
メタデータテーブル設定は、Amazon S3 コンソール、AWS Command Line Interface (AWS CLI)、AWS SDK、または Amazon S3 REST API を使用して作成できます。
**注記**
2025 年 7 月 15 日より前に S3 Metadata 設定を作成した場合は、ジャーナルテーブルレコードを期限切れにしてインベントリテーブルを作成できるように、設定を削除して再作成することをお勧めします。詳細については、「[2025 年 7 月 15 日より前に作成されたメタデータ設定でインベントリテーブルを有効にする](#metadata-tables-migration)」を参照してください。
メタデータテーブル設定を削除し、同じ汎用バケットの設定を再作成する場合は、まず AWS マネージドテーブルバケットから古いジャーナルテーブルとインベントリテーブルを手動で削除する必要があります。削除しない場合、新しいメタデータテーブル設定の作成は、それらのテーブルが既に存在するため失敗します。メタデータテーブルを削除するには、「[メタデータテーブルを削除する](metadata-tables-delete-table.md#delete-metadata-table-procedure)」を参照してください。
メタデータテーブル設定を削除すると、設定のみが削除されます。メタデータテーブル設定を削除しても、AWS マネージドテーブルバケットとメタデータテーブルは引き続き存在します。
**前提条件**
メタデータテーブル設定を作成する前に、以下の前提条件が満たされていることを確認してください。
+ メタデータテーブル設定を作成する前に、メタデータテーブルを作成および管理するために必要な AWS Identity and Access Management (IAM) アクセス許可があることを確認してください。詳細については、「[メタデータテーブルを設定するためのアクセス許可の設定](metadata-tables-permissions.md)」を参照してください。
+ Amazon Athena または他の AWS クエリエンジンを使用してメタデータテーブルをクエリする場合は、AWS マネージドテーブルバケットを AWS 分析サービスと統合してください。詳細については、「[Amazon S3 Tables と AWS 分析サービスの統合](s3-tables-integrating-aws.md)」を参照してください。
このリージョンに既存のテーブルバケットを既に統合している場合は、AWS マネージドテーブルバケットも自動的に統合されます。このリージョンのテーブルバケットの統合ステータスを確認するには、Amazon S3 コンソールを開き、左側のナビゲーションペインで **[テーブルバケット]** を選択します。**[AWS 分析サービスとの統合]** で、リージョンを確認し、統合ステータスが **[有効]** になっているかどうかを確認します。
## メタデータテーブル設定を作成する
### S3 コンソールの使用
**メタデータテーブル設定を作成するには**
メタデータテーブル設定を作成する前に、必ず[前提条件](#metadata-table-config-prereqs)を確認して満たし、[メタデータテーブルの制限と制約](metadata-tables-restrictions.md) を確認してください。
1. AWS マネジメントコンソール にサインインし、Amazon S3 コンソール [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) を開きます。
1. 左のナビゲーションペインで、**[汎用バケット]** を選択します。
1. メタデータテーブル設定を作成する汎用バケットを選択します。
**注記**
この汎用バケットが、テーブルバケットが使用可能な AWS リージョンであることを確認します。テーブルバケットは、米国東部 (バージニア北部)、米国東部 (オハイオ)、および米国西部 (オレゴン) リージョンでのみ使用できます。
1. バケットの詳細ページで、**[メタデータ]** タブを選択します。
1. **[メタデータ]** タブで、**[メタデータ設定を作成]** を選択します。
1. **[メタデータ設定の作成]** ページの**ジャーナルテーブル**で、AWS Key Management Service (AWS KMS) キーを使用したサーバー側の暗号化 (SSE-KMS) でテーブルを暗号化するかどうかを選択できます。デフォルトでは、ジャーナルバケットは、Amazon S3 マネージドキーによるサーバー側の暗号化 (SSE-S3) を使用して暗号化されます。
SSE-KMS を使用する場合は、汎用バケットと同じリージョンにカスタマーマネージド KMS キーを指定する必要があります。
**重要**
メタデータテーブルの暗号化タイプは、テーブルの作成中にのみ設定できます。AWS マネージドテーブルの作成後は、暗号化設定を変更することはできません。
+ ジャーナルテーブルを SSE-S3 (デフォルト) で暗号化するには、**[暗号化タイプを指定しない]** を選択します。
+ ジャーナルテーブルを SSE-KMS で暗号化するには、**[暗号化タイプを指定する]** を選択します。**[暗号化タイプ]** で、**[AWS Key Management Service (AWS KMS) キー (SSE-KMS) を使用したサーバー側の暗号化]** を選択します。**[AWS KMS キー]** で、既存の KMS キーから選択するか、KMS キー ARN を入力します。KMS キーがまだない場合は、**[KMS キー ARN を入力]** を選択し、**[KMS キーを作成する]** を選択します。
SSE-KMS に必要なアクセス許可が設定されていることを確認します。詳細については、「[SSE-KMS のアクセス許可](metadata-tables-permissions.md#metadata-kms-permissions)」を参照してください。
1. (オプション) デフォルトでは、ジャーナルテーブルのレコードは期限切れになりません。ジャーナルテーブルのストレージコストを最小限に抑えるには、**[レコードの有効期限]** で、**[有効]** を選択します。
ジャーナルテーブルレコードの有効期限を有効にすると、ジャーナルテーブルレコードを保持する日数を設定できます。**[レコードの有効期限が切れるまでの日数]** を設定するには、`7`～`2147483647` の任意の整数を指定できます。例えば、ジャーナルテーブルレコードを 1 年間保持するには、この値を `365` に設定します。
レコードは期限切れの対象になってから 24～48 時間以内に無効になります。
**重要**
ジャーナルテーブルレコードの有効期限が切れると、復元できません。
**[ジャーナルテーブルレコードは指定された日数後に期限切れになる]** で、チェックボックスをオンにします。
1. (オプション) メタデータテーブル設定にインベントリテーブルを追加する場合は、**[ライブインベントリテーブル]** で、**[設定ステータス]** の **[有効]** を選択します。
AWS Key Management Service (AWS KMS) キー (SSE-KMS) を使用してサーバー側の暗号化でテーブルを暗号化するかどうかを選択できます。デフォルトでは、インベントリテーブルは、Amazon S3 マネージドキーを使用してサーバー側の暗号化 (SSE-S3) を使用して暗号化されます。
SSE-KMS を使用する場合は、汎用バケットと同じリージョンにカスタマーマネージド KMS キーを指定する必要があります。
**重要**
メタデータテーブルの暗号化タイプは、テーブルの作成中にのみ設定できます。AWS マネージドテーブルの作成後は、暗号化設定を変更することはできません。
+ インベントリテーブルを SSE-S3 (デフォルト) で暗号化するには、**[暗号化タイプを指定しない]** を選択します。
+ インベントリテーブルを SSE-KMS で暗号化するには、**[暗号化タイプを指定する]** を選択します。**[暗号化タイプ]** で、**[AWS Key Management Service (AWS KMS) キー (SSE-KMS) を使用したサーバー側の暗号化]** を選択します。**[AWS KMS キー]** で、既存の KMS キーから選択するか、KMS キー ARN を入力します。KMS キーがまだない場合は、**[KMS キー ARN を入力]** を選択し、**[KMS キーを作成する]** を選択します。
SSE-KMS に必要なアクセス許可が設定されていることを確認します。詳細については、「[SSE-KMS のアクセス許可](metadata-tables-permissions.md#metadata-kms-permissions)」を参照してください。
1. **[メタデータテーブル設定を作成]** を選択します。
メタデータテーブルの設定が成功すると、メタデータテーブルの名前と ARNs が、AWS マネージドテーブルバケットと名前空間の名前とともに **[メタデータ]** タブに表示されます。
メタデータテーブル設定のインベントリテーブルを有効にすることを選択した場合、テーブルは*バックフィル*と呼ばれるプロセスを実行し、そのプロセス中に Amazon S3 は汎用バケットをスキャンして、バケットに存在するすべてのオブジェクトの初期メタデータを取得します。バケット内のオブジェクトの数によっては、このプロセスに数分 (最小 15 分) から数時間かかる場合があります。バックフィルプロセスが完了すると、インベントリテーブルのステータスが **[バックフィル]** から **[アクティブ]** に変わります。バックフィルが完了すると、通常、オブジェクトの更新は 1 時間以内にインベントリテーブルに反映されます。
メタデータテーブル設定の更新をモニタリングするには、AWS CloudTrail を使用できます。詳細については、「[CloudTrail ログ記録によって追跡される Amazon S3 バケットレベルのアクション](cloudtrail-logging-s3-info.md#cloudtrail-bucket-level-tracking)」を参照してください。
### AWS CLI の使用
次のコマンドを実行するには、AWS CLI をインストールして設定する必要があります。AWS CLI をまだインストールしていない場合は、「*AWS Command Line Interface ユーザーガイド*」の「[AWS CLI の最新バージョンのインストールまたは更新](https://docs.aws.amazon.com//cli/latest/userguide/getting-started-install.html)」を参照してください。
別の方法として、AWS CloudShell を使用してコンソールから AWS CLI コマンドを実行することもできます。AWS CloudShell は、AWS マネジメントコンソールから直接起動できる、ブラウザベースの事前認証済みシェルです。詳細については、「AWS CloudShell ユーザーガイド」の「[CloudShell とは](https://docs.aws.amazon.com//cloudshell/latest/userguide/welcome.html)」と「[AWS CloudShell の使用開始](https://docs.aws.amazon.com//cloudshell/latest/userguide/getting-started.html)」を参照してください。**
**AWS CLI を使用してメタデータテーブル設定を作成するには**
メタデータテーブル設定を作成する前に、必ず[前提条件](#metadata-table-config-prereqs)を確認して満たし、[メタデータテーブルの制限と制約](metadata-tables-restrictions.md) を確認してください。
次のコマンド例を使用する際は、`user input placeholders` をユーザー自身の情報に置き換えます。
1. メタデータテーブル設定を含む JSON ファイルを作成し、保存します (例: `metadata-config.json`)。以下は、設定例です。
ジャーナルテーブルレコードの有効期限を有効または無効にするかどうかを指定する必要があります。レコードの有効期限を有効にする場合は、ジャーナルテーブルレコードの有効期限が切れるまでの日数も指定する必要があります。`Days` 値を設定するには、`7`～`2147483647` の任意の整数を指定できます。例えば、ジャーナルテーブルレコードを 1 年間保持するには、この値を `365` に設定します。
オプションで、インベントリテーブルの設定を選択できます。
ジャーナルテーブルとインベントリテーブルの両方で、オプションで暗号化設定を指定できます。デフォルトでは、メタデータテーブルは Amazon S3 マネージドキー (SSE-S3) を使用したサーバー側の暗号化で暗号化されます。この暗号化は、`SseAlgorithm` を `AES256` に設定することで指定できます。
AWS Key Management Service (AWS KMS) キー (SSE-KMS) を使用してサーバー側の暗号化でメタデータテーブルを暗号化するには、`SseAlgorithm` を `aws:kms` に設定します。また、汎用バケットがあるリージョンと同じリージョンで、カスタマーマネージド KMS キーの ARN に `KmsKeyArn` を設定する必要があります。
```
{
"JournalTableConfiguration": {
"RecordExpiration": {
"Expiration": "ENABLED",
"Days": 10
},
"EncryptionConfiguration": {
"SseAlgorithm": "AES256"
}
},
"InventoryTableConfiguration": {
"ConfigurationState": "ENABLED",
"EncryptionConfiguration": {
"SseAlgorithm": "aws:kms",
"KmsKeyArn": "arn:aws:kms:us-east-2:account-id:key/key-id"
}
}
}
```
1. 次のコマンドを使用して、メタデータテーブル設定を汎用バケット (例: `amzn-s3-demo-bucket`) に適用します。
```
aws s3api create-bucket-metadata-configuration \
--bucket amzn-s3-demo-bucket \
--metadata-configuration file://./metadata-config.json \
--region us-east-2
```
1. 設定が作成されたことを確認するには、次のコマンドを使用します。
```
aws s3api get-bucket-metadata-configuration \
--bucket amzn-s3-demo-bucket \
--region us-east-2
```
メタデータテーブル設定の更新をモニタリングするには、AWS CloudTrail を使用できます。詳細については、「[CloudTrail ログ記録によって追跡される Amazon S3 バケットレベルのアクション](cloudtrail-logging-s3-info.md#cloudtrail-bucket-level-tracking)」を参照してください。
### REST API の使用
REST リクエストを送信して、メタデータテーブル設定を作成できます。詳細については、「**Amazon S3 API リファレンス」の「[https://docs.aws.amazon.com//AmazonS3/latest/API/API_CreateBucketMetadataConfiguration.html](https://docs.aws.amazon.com//AmazonS3/latest/API/API_CreateBucketMetadataConfiguration.html)」を参照してください。
### AWS SDK の使用
AWS SDK を使用して、Amazon S3 でメタデータテーブル設定を作成できます。詳細については、「*Amazon S3 API Reference*」にある「[サポートされる SDK のリスト](https://docs.aws.amazon.com//AmazonS3/latest/API/API_CreateBucketMetadataConfiguration.html#API_CreateBucketMetadataConfiguration_SeeAlso)」を参照してください。
## 2025 年 7 月 15 日より前に作成されたメタデータ設定でインベントリテーブルを有効にする
2025 年 7 月 15 日より前に S3 Metadata 設定を作成した場合は、ジャーナルテーブルレコードを期限切れにしてインベントリテーブルを作成できるように、設定を削除して再作成することをお勧めします。古い設定の削除と新しい設定の作成の間に発生する汎用バケットへの変更は、いずれのジャーナルテーブルにも記録されません。
古いメタデータ設定から新しい設定に移行するには、次の手順を実行します。
1. 既存のメタデータテーブル設定を削除します。手順については、「[メタデータテーブル設定の削除](metadata-tables-delete-configuration.md)」を参照してください。
1. 新しいメタデータテーブル設定を作成します。手順については、「[メタデータテーブル設定の作成](#metadata-tables-create-configuration)」を参照してください。
設定の移行に関するサポートが必要な場合は、AWS サポート にお問い合わせください。
新しいメタデータ設定を作成すると、2 つのジャーナルテーブルが作成されます。古いジャーナルテーブルが不要になった場合は、削除できます。手順については、「[メタデータテーブルの削除](metadata-tables-delete-table.md)」を参照してください。古いジャーナルテーブルを保持し、新しいジャーナルテーブルと結合する場合は、「[カスタムメタデータと S3 メタデータテーブルの結合](metadata-tables-join-custom-metadata.md)」で 2 つのテーブルを結合する方法の例を参照してください。
移行後、以下を実行できます。
1. 設定を表示するには、`GetBucketMetadataConfiguration` API オペレーションを使用できるようになりました。設定が古いか新しいかを判断するには、`GetBucketMetadataConfiguration` API レスポンスの次の属性を確認します。AWS マネージドバケットタイプ (`"aws"`) は新しい設定を示し、カスタマーマネージドバケットタイプ (`"customer"`) は古い設定を示します。
```
"MetadataTableConfigurationResult": {
"TableBucketType": ["aws" | "customer"]
```
詳細については、「[メタデータテーブル設定の表示](metadata-tables-view-configuration.md)」を参照してください。
**注記**
`GetBucketMetadataConfiguration` および `DeleteBucketMetadataConfiguration` API オペレーションは、古いメタデータテーブル設定または新しいメタデータテーブル設定で使用できます。ただし、新しい設定で `GetBucketMetadataTableConfiguration` および `DeleteBucketMetadataTableConfiguration` API オペレーションを使用しようとすると、HTTP `405 Method Not Allowed` エラーが発生します。
古い API オペレーションの代わりに新しい API オペレーション (`CreateBucketMetadataConfiguration`、`GetBucketMetadataConfiguration`、`DeleteBucketMetadataConfiguration`) を使用するようにプロセスを更新してください。
1. Amazon Athena または他の AWS クエリエンジンを使用してメタデータテーブルをクエリする場合は、AWS マネージドテーブルバケットを AWS 分析サービスと統合してください。このリージョンに既存のテーブルバケットを既に統合している場合は、AWS マネージドテーブルバケットも自動的に統合されます。詳細については、「[Amazon S3 Tables と AWS 分析サービスの統合](s3-tables-integrating-aws.md)」を参照してください。
# メタデータテーブルへのアクセスの制御
Amazon S3 メタデータテーブルへのアクセスを制御するには、テーブルバケットとメタデータテーブルにアタッチされている AWS Identity and Access Management (IAM) リソースベースのポリシーを使用できます。つまり、テーブルバケットレベルとテーブルレベルの両方でメタデータテーブルへのアクセスを制御できます。
テーブルバケットとテーブルへのアクセスの制御の詳細については、「[Access management for S3 Tables](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-setting-up.html)」を参照してください。
**重要**
テーブルバケットまたはテーブルポリシーを作成または更新するときは、Amazon S3 サービスプリンシパル `metadata.s3.amazonaws.com` および `maintenance.s3tables.amazonaws.com` がテーブルバケットまたはメタデータテーブルに書き込むことを制限しないようにしてください。
Amazon S3 がテーブルバケットまたはメタデータテーブルに書き込めない場合は、メタデータ設定を削除し、メタデータテーブルを削除してから、新しい設定を作成する必要があります。設定にインベントリテーブルがある場合は、新しいインベントリテーブルを作成する必要があります。新しいインベントリテーブルをバックフィルすると、再度課金されます。
AWS Lake Formation を使用して、メタデータテーブルの行と列へのアクセスを制御することもできます。詳細については、「*AWS Lake Formation Developer Guide*」の「[Managing Lake Formation permissions](https://docs.aws.amazon.com/lake-formation/latest/dg/managing-permissions.html)」と「[Data filtering and cell-level security in Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/data-filtering.html)」を参照してください。
# ジャーナルテーブルレコードを期限切れにする
デフォルトでは、ジャーナルテーブルのレコードは期限切れになりません。ジャーナルテーブルのストレージコストを最小限に抑えるために、ジャーナルテーブルレコードの有効期限を有効にできます。
**注記**
2025 年 7 月 15 日より前に S3 Metadata 設定を作成した場合、その設定でジャーナルテーブルレコードの有効期限を有効にすることはできません。ジャーナルテーブルレコードを期限切れにしてインベントリテーブルを作成できるように、設定を削除して再作成することをお勧めします。詳細については、「[2025 年 7 月 15 日より前に作成されたメタデータ設定でインベントリテーブルを有効にする](metadata-tables-create-configuration.md#metadata-tables-migration)」を参照してください。
ジャーナルテーブルレコードの有効期限を有効にすると、ジャーナルテーブルレコードを保持する日数を設定できます。この値を設定するには、`7`～`2147483647` の任意の整数を指定します。例えば、ジャーナルテーブルレコードを 1 年間保持するには、この値を `365` に設定します。
**重要**
ジャーナルテーブルレコードの有効期限が切れると、復元できません。
レコードは期限切れの対象になってから 24～48 時間以内に無効になります。ジャーナルレコードは最新のスナップショットから削除されます。削除されたレコードのデータとストレージは、テーブルのメンテナンスオペレーションによって削除されます。
ジャーナルテーブルレコードの有効期限を有効にしている場合は、いつでも無効にして、ジャーナルテーブルレコードの有効期限切れを停止できます。
Amazon S3 コンソール、AWS Command Line Interface (AWS CLI)、AWS SDK、または Amazon S3 REST API を使用して、ジャーナルテーブルレコードの期限切れの設定を行えます。
## ジャーナルテーブルレコードを期限切れにする方法
### S3 コンソールの使用
**ジャーナルテーブルレコードを期限切れにするには**
1. AWS マネジメントコンソール にサインインし、Amazon S3 コンソール [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) を開きます。
1. 左のナビゲーションペインで、**[汎用バケット]** を選択します。
1. レコードを期限切れにするジャーナルテーブルがあるメタデータテーブル設定を含む汎用バケットを選択します。
1. バケットの詳細ページで、**[メタデータ]** タブを選択します。
1. **[メタデータ]** タブで、**[編集]** を選択し、**[ジャーナルテーブルレコードの有効期限を編集]** を選択します。
1. **[ジャーナルテーブルレコードの有効期限を編集]** ページで、**[レコードの有効期限]** で **[有効]** を選択します。
1. ジャーナルテーブルレコードを保持する日数を設定します。**[レコードの有効期限が切れるまでの日数]** を設定するには、`7`～`2147483647` の任意の整数を指定します。例えば、ジャーナルテーブルレコードを 1 年間保持するには、この値を `365` に設定します。
**重要**
ジャーナルテーブルレコードの有効期限が切れると、復元できません。
1. **[ジャーナルテーブルレコードは指定された日数後に期限切れになる]** で、チェックボックスをオンにします。
1. **[Save changes]** (変更の保存) をクリックします。
ジャーナルテーブルレコードの有効期限を無効にする場合は、前述のステップを繰り返しますが、ステップ 6 で **[有効]** の代わりに **[無効]** を選択します。
### の使用AWS CLI
次のコマンドを実行するには、AWS CLI をインストールして設定する必要があります。AWS CLI をまだインストールしていない場合は、「*AWS Command Line Interface ユーザーガイド*」の「[AWS CLI の最新バージョンのインストールまたは更新](https://docs.aws.amazon.com//cli/latest/userguide/getting-started-install.html)」を参照してください。
AWS CloudShell を使用してコンソールから AWS CLI コマンドを実行することもできます。AWS CloudShell はブラウザベースの事前認証されたシェルであり、AWS マネジメントコンソール から直接起動できます。詳細については、「AWS CloudShell ユーザーガイド」の「[CloudShell とは](https://docs.aws.amazon.com//cloudshell/latest/userguide/welcome.html)」と「[AWS CloudShell の使用開始](https://docs.aws.amazon.com//cloudshell/latest/userguide/getting-started.html)」を参照してください。**
**AWS CLI を使用してジャーナルテーブルレコードを期限切れにするには**
次のコマンド例を使用する際は、`user input placeholders` をユーザー自身の情報に置き換えます。
1. ジャーナルテーブル設定を含む JSON ファイルを作成し、保存します (例: `journal-config.json`)。以下は、設定例です。
`Days` 値を設定するには、`7`～`2147483647` の任意の整数を指定します。例えば、ジャーナルテーブルレコードを 1 年間保持するには、この値を `365` に設定します。
```
{
"RecordExpiration": {
"Expiration": "ENABLED",
"Days": 10
}
}
```
ジャーナルテーブルレコードの有効期限を無効にするには、代わりに次のサンプル設定を作成します。`Expiration` が `DISABLED` に設定されている場合、設定で `Days` 値を指定しないでください。
```
{
"RecordExpiration": {
"Expiration": "DISABLED"
}
}
```
1. 次のコマンドを使用して、汎用バケットのジャーナルテーブルのレコードを期限切れにします (例: `amzn-s3-demo-bucket`)。
```
aws s3api update-bucket-metadata-journal-table-configuration \
--bucket amzn-s3-demo-bucket \
--journal-table-configuration file://./journal-config.json \
--region us-east-2
```
### REST API の使用
ジャーナルテーブルレコードの有効期限が切れるように REST リクエストを送信できます。詳細については、[ を参照してください。UpdateBucketMetadataJournalTableConfiguration](https://docs.aws.amazon.com/AmazonS3/latest/API/API_UpdateBucketMetadataJournalTableConfiguration.html)
### AWS SDK の使用
AWS SDK を使用して、Amazon S3 のジャーナルテーブルレコードを期限切れにすることができます。詳細については、「[サポートされる SDK のリスト](https://docs.aws.amazon.com/AmazonS3/latest/API/API_UpdateBucketMetadataJournalTableConfiguration.html#API_UpdateBucketMetadataJournalTableConfiguration_SeeAlso)」を参照してください。
# ライブインベントリテーブルを有効または無効にする
デフォルトでは、メタデータテーブル設定には、バケット内のオブジェクトに対して発生したイベントを記録する*ジャーナルテーブル*が含まれています。ジャーナルテーブルは、メタデータテーブル設定ごとに必要です。
必要に応じて、メタデータテーブル設定に*ライブインベントリテーブル*を追加できます。ライブインベントリテーブルは、バケット内のすべてのオブジェクトとそのバージョンのシンプルでクエリ可能なインベントリを提供するため、データの最新の状態を判断できます。
**注記**
2025 年 7 月 15 日より前に S3 Metadata 設定を作成した場合、その設定でインベントリテーブルを有効にすることはできません。インベントリテーブルを作成してジャーナルテーブルレコードの有効期限が切れるように、設定を削除して再作成することをお勧めします。詳細については、「[2025 年 7 月 15 日より前に作成されたメタデータ設定でインベントリテーブルを有効にする](metadata-tables-create-configuration.md#metadata-tables-migration)」を参照してください。
インベントリテーブルには、バケット内のすべてのオブジェクトの最新メタデータが含まれます。このテーブルを使用すると、さまざまなワークロードに対して処理するオブジェクトを特定することで、ビジネスワークフローとビッグデータジョブを簡素化および高速化できます。例えば、インベントリテーブルをクエリして、以下を実行できます。
+ S3 Glacier Deep Archive ストレージクラスに保存されているすべてのオブジェクトを検索します。
+ オブジェクトタグのディストリビューションを作成するか、タグなしでオブジェクトを検索します。
+ AWS Key Management Service (AWS KMS) キーによるサーバー側の暗号化 (SSE-KMS) を使用して暗号化されていないすべてのオブジェクトを検索します。
+ 2 つの異なる時点でインベントリテーブルを比較して、特定のタグを持つオブジェクトの増加を把握します。
メタデータテーブル設定のインベントリテーブルを有効にすることを選択した場合、テーブルは*バックフィル*と呼ばれるプロセスを実行し、そのプロセス中に Amazon S3 は汎用バケットをスキャンして、バケットに存在するすべてのオブジェクトの初期メタデータを取得します。バケット内のオブジェクトの数によっては、このプロセスに数分 (最小 15 分) から数時間かかる場合があります。バックフィルプロセスが完了すると、インベントリテーブルのステータスが **[バックフィル]** から **[アクティブ]** に変わります。バックフィルが完了すると、通常、オブジェクトの更新は 1 時間以内にインベントリテーブルに反映されます。
**注記**
インベントリテーブルのバックフィルの実行は課金されます。汎用バケットに 10 億個を超えるオブジェクトがある場合は、インベントリテーブルの月額料金も請求されます。詳細については、[Amazon S3 の料金](https://aws.amazon.com/s3/pricing/) を参照してください。
インベントリテーブルの更新を一時停止してから再開することはできません。ただし、インベントリテーブルの設定を無効にすることはできます。インベントリテーブルを無効にしても削除されません。インベントリテーブルは、削除するまでレコード用に保持されます。
インベントリテーブルを無効にし、後で再度有効にする場合は、まず AWS マネージドテーブルバケットから古いインベントリテーブルを削除する必要があります。インベントリテーブル設定を再度有効にすると、Amazon S3 は新しいインベントリテーブルを作成し、新しいインベントリテーブルのバックフィルに対して再度課金されます。
Amazon S3 コンソール、AWS Command Line Interface (AWS CLI)、AWS SDK、または Amazon S3 REST API を使用して、インベントリテーブルを有効または無効にできます。
**前提条件**
インベントリテーブルを無効にし、再度有効にする場合は、まず AWS マネージドテーブルバケットから古いインベントリテーブルを手動で削除する必要があります。削除しない場合、インベントリテーブルがテーブルバケットに既に存在するため、インベントリテーブルの再有効化は失敗します。インベントリテーブルを削除するには、「[メタデータテーブルを削除する](metadata-tables-delete-table.md#delete-metadata-table-procedure)」を参照してください。
インベントリテーブル設定を再度有効にすると、Amazon S3 は新しいインベントリテーブルを作成し、新しいインベントリテーブルのバックフィルに対して再度課金されます。
## インベントリテーブルを有効または無効にする
### S3 コンソールの使用
**インベントリテーブルを有効または無効にするには**
1. AWS マネジメントコンソール にサインインし、Amazon S3 コンソール [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) を開きます。
1. 左のナビゲーションペインで、**[汎用バケット]** を選択します。
1. インベントリテーブルを有効または無効にするメタデータテーブル設定を持つ汎用バケットを選択します。
1. バケットの詳細ページで、**[メタデータ]** タブを選択します。
1. **[メタデータ]** タブで、**[編集]** を選択し、**[インベントリテーブル設定を編集]** を選択します。
1. **[インベントリテーブル設定を編集]** ページで、**[インベントリテーブル]** で **[有効]** または **[無効]** を選択します。
**注記**
**[有効]** を選択する前に、[[前提条件]](#inventory-table-config-prereqs) を確認し、満たしていることを確認してください。
+ **[有効]** を選択した場合は、AWS Key Management Service (AWS KMS) キー (SSE-KMS) を使用したサーバー側の暗号化でテーブルを暗号化するかどうかを選択できます。デフォルトでは、インベントリテーブルは、Amazon S3 マネージドキーを使用してサーバー側の暗号化 (SSE-S3) を使用して暗号化されます。
SSE-KMS を使用する場合は、汎用バケットと同じリージョンにカスタマーマネージド KMS キーを指定する必要があります。
**重要**
メタデータテーブルの暗号化タイプは、テーブルの作成中にのみ設定できます。AWS マネージドテーブルの作成後は、暗号化設定を変更することはできません。
+ インベントリテーブルを SSE-S3 (デフォルト) で暗号化するには、**[暗号化タイプを指定しない]** を選択します。
+ インベントリテーブルを SSE-KMS で暗号化するには、**[暗号化タイプを指定する]** を選択します。**[暗号化タイプ]** で、**[AWS Key Management Service (AWS KMS) キー (SSE-KMS) を使用したサーバー側の暗号化]** を選択します。**[AWS KMS キー]** で、既存の KMS キーから選択するか、KMS キー ARN を入力します。KMS キーがまだない場合は、**[KMS キー ARN を入力]** を選択し、**[KMS キーを作成する]** を選択します。
+ **[無効]** を選択した場合、**[インベントリテーブルが無効になると、テーブルは更新されなくなり、更新を再開できなくなる]** チェックボックスをオンにします。
1. **[Save changes]** (変更の保存) をクリックします。
### の使用AWS CLI
次のコマンドを実行するには、AWS CLI をインストールして設定する必要があります。AWS CLI をまだインストールしていない場合は、「*AWS Command Line Interface ユーザーガイド*」の「[AWS CLI の最新バージョンのインストールまたは更新](https://docs.aws.amazon.com//cli/latest/userguide/getting-started-install.html)」を参照してください。
別の方法として、AWS CloudShell を使用してコンソールから AWS CLI コマンドを実行することもできます。AWS CloudShell は、AWS マネジメントコンソールから直接起動できる、ブラウザベースの事前認証済みシェルです。詳細については、「AWS CloudShell ユーザーガイド」の「[CloudShell とは](https://docs.aws.amazon.com//cloudshell/latest/userguide/welcome.html)」と「[AWS CloudShell の使用開始](https://docs.aws.amazon.com//cloudshell/latest/userguide/getting-started.html)」を参照してください。**
**AWS CLI を使用してインベントリテーブルを有効または無効にするには**
次のコマンド例を使用する際は、`user input placeholders` をユーザー自身の情報に置き換えます。
**注記**
インベントリ設定を有効にする前に、[[前提条件]](#inventory-table-config-prereqs) を確認し、満たしていることを確認してください。
1. インベントリテーブル設定を含む JSON ファイルを作成し、保存します (例: `inventory-config.json`)。以下は、新しいインベントリテーブルを有効にするための設定例です。
インベントリテーブルを有効にする場合は、オプションで暗号化設定を指定できます。デフォルトでは、メタデータテーブルは Amazon S3 マネージドキー (SSE-S3) を使用したサーバー側の暗号化で暗号化されます。この暗号化は、`SseAlgorithm` を `AES256` に設定することで指定できます。
AWS Key Management Service (AWS KMS) キー (SSE-KMS) を使用したサーバー側の暗号化を使用してインベントリテーブルを暗号化するには、`SseAlgorithm` を `aws:kms` に設定します。また、汎用バケットがあるリージョンと同じリージョンで、カスタマーマネージド KMS キーの ARN に `KmsKeyArn` を設定する必要があります。
```
{
"ConfigurationState": "ENABLED",
"EncryptionConfiguration": {
"SseAlgorithm": "aws:kms",
"KmsKeyArn": "arn:aws:kms:us-east-2:account-id:key/key-id"
}
}
```
既存のインベントリテーブルを無効にする場合は、次の設定を使用します。
```
{
"ConfigurationState": "DISABLED" }
}
```
1. 次のコマンドを使用して、汎用バケットのインベントリテーブル設定を更新します (例: `amzn-s3-demo-bucket`)。
```
aws s3api update-bucket-metadata-inventory-table-configuration \
--bucket amzn-s3-demo-source-bucket \
--inventory-table-configuration file://./inventory-config.json \
--region us-east-2
```
### REST API の使用
REST リクエストを送信して、インベントリテーブルを有効または無効にできます。詳細については、[ を参照してください。UpdateBucketMetadataInventoryTableConfiguration](https://docs.aws.amazon.com/AmazonS3/latest/API/API_UpdateBucketMetadataInventoryTableConfiguration.html)
### AWS SDK の使用
AWS SDK を使用して、Amazon S3 のインベントリテーブルを有効または無効にできます。詳細については、「[サポートされる SDK のリスト](https://docs.aws.amazon.com/AmazonS3/latest/API/API_UpdateBucketMetadataInventoryTableConfiguration.html#API_UpdateBucketMetadataInventoryTableConfiguration_SeeAlso)」を参照してください。
# メタデータテーブル設定の表示
汎用バケットのメタデータテーブル設定を作成した場合は、インベントリテーブルが有効になっているかどうか、ジャーナルテーブルレコードの有効期限が有効になっているかどうかなど、設定に関する情報を表示できます。ジャーナルテーブルとインベントリテーブルのステータスを表示することもできます。
汎用バケットのメタデータテーブル設定は、Amazon S3 コンソール、AWS Command Line Interface (AWS CLI)、AWS SDK、または Amazon S3 REST API を使用して表示できます。
## メタデータテーブル設定の表示
### S3 コンソールの使用
**メタデータテーブル設定を表示するには**
1. AWS マネジメントコンソール にサインインし、Amazon S3 コンソール [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) を開きます。
1. 左のナビゲーションペインで、**[汎用バケット]** を選択します。
1. 表示するメタデータテーブル設定を含む汎用バケットを選択します。
1. バケットの詳細ページで、**[メタデータ]** タブを選択します。
1. **[メタデータ]** タブで、**[メタデータ設定]** セクションまで下にスクロールします。**[ジャーナルテーブル]** と **[インベントリテーブル]** セクションでは、Amazon リソースネーム (ARN)、テーブルのステータス、ジャーナルテーブルレコードの有効期限またはインベントリテーブルを有効にしているかどうかなど、これらの設定のさまざまな情報を表示できます。
### の使用AWS CLI
次のコマンドを実行するには、AWS CLI をインストールして設定する必要があります。AWS CLI をまだインストールしていない場合は、「*AWS Command Line Interface ユーザーガイド*」の「[AWS CLI の最新バージョンのインストールまたは更新](https://docs.aws.amazon.com//cli/latest/userguide/getting-started-install.html)」を参照してください。
別の方法として、AWS CloudShell を使用してコンソールから AWS CLI コマンドを実行することもできます。AWS CloudShell は、AWS マネジメントコンソールから直接起動できる、ブラウザベースの事前認証済みシェルです。詳細については、「AWS CloudShell ユーザーガイド」の「[CloudShell とは](https://docs.aws.amazon.com//cloudshell/latest/userguide/welcome.html)」と「[AWS CloudShell の使用開始](https://docs.aws.amazon.com//cloudshell/latest/userguide/getting-started.html)」を参照してください。**
**AWS CLI を使用してメタデータテーブル設定を表示するには**
次のコマンド例を使用するには、`user input placeholders` をユーザー自身の情報に置き換えます。
1. 次のコマンドを使用して、汎用バケットのメタデータテーブル設定を表示します (例: `amzn-s3-demo-bucket`)。
```
aws s3api get-bucket-metadata-configuration \
--bucket amzn-s3-demo-bucket \
--region us-east-2
```
1. このコマンドの出力を表示して、メタデータテーブル設定のステータスを確認します。例えば、次のようになります。
```
{
"GetBucketMetadataConfigurationResult": {
"MetadataConfigurationResult": {
"DestinationResult": {
"TableBucketType": "aws",
"TableBucketArn": "arn:aws:s3tables:us-east-2:111122223333:bucket/aws-managed-s3-111122223333-us-east-2",
"TableNamespace": "b_general-purpose-bucket-name"
},
"JournalTableConfigurationResult": {
"TableStatus": "ACTIVE",
"TableName": "journal",
"TableArn": "arn:aws:s3tables:us-east-2:111122223333:bucket/aws-managed-s3-111122223333-us-east-2/table/0f01234c-fe7a-492f-a4c7-adec3864ea85",
"EncryptionConfiguration": {
"SseAlgorithm": "AES256"
},
"RecordExpiration": {
"Expiration": "ENABLED",
"Days": 10
}
},
"InventoryTableConfigurationResult": {
"ConfigurationState": "ENABLED",
"TableStatus": "BACKFILL_COMPLETE",
"TableName": "inventory",
"TableArn": "arn:aws:s3tables:us-east-2:111122223333:bucket/aws-managed-s3-111122223333-us-east-2/table/e123456-b876-4e5e-af29-bb055922ee4d",
"EncryptionConfiguration": {
"SseAlgorithm": "AES256"
}
}
}
}
}
```
### REST API の使用
REST リクエストを送信して、メタデータテーブル設定を表示できます。詳細については、[ を参照してください。GetBucketMetadataTableConfiguration](https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetBucketMetadataTableConfiguration.html)
**注記**
V1 または V2 メタデータテーブル設定で V2 `GetBucketMetadataConfiguration` API オペレーションを使用できます。ただし、V2 設定で V1 `GetBucketMetadataTableConfiguration` API オペレーションを使用しようとすると、HTTP `405 Method Not Allowed` エラーが発生します。
### AWS SDK の使用
AWS SDK を使用して、Amazon S3 でメタデータテーブル設定を表示できます。詳細については、「[サポートされる SDK のリスト](https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetBucketMetadataTableConfiguration.html#API_GetBucketMetadataTableConfiguration_SeeAlso)」を参照してください。
# メタデータテーブル設定の削除
Amazon S3 汎用バケットのメタデータテーブル設定の更新を停止する場合は、バケットにアタッチされているメタデータテーブル設定を削除できます。メタデータテーブル設定を削除すると、設定のみが削除されます。メタデータテーブル設定を削除しても、AWS マネージドテーブルバケットとメタデータテーブルは引き続き存在します。ただし、メタデータテーブルは更新されなくなります。
**注記**
メタデータテーブル設定を削除し、同じ汎用バケットの設定を再作成する場合は、まず AWS マネージドテーブルバケットから古いジャーナルテーブルとインベントリテーブルを手動で削除する必要があります。削除しない場合、新しいメタデータテーブル設定の作成は、それらのテーブルが既に存在するため失敗します。メタデータテーブルを削除するには、「[メタデータテーブルの削除](metadata-tables-delete-table.md)」を参照してください。
メタデータテーブルを削除するには、「[メタデータテーブルを削除する](metadata-tables-delete-table.md#delete-metadata-table-procedure)」を参照してください。テーブルバケットを削除するには、「*Amazon S3 API Reference*」の「[Deleting table buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-buckets-delete.html)」および「[https://docs.aws.amazon.com/AmazonS3/latest/API/API_s3TableBuckets_DeleteTableBucket.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_s3TableBuckets_DeleteTableBucket.html)」を参照してください。
メタデータテーブル設定は、Amazon S3 コンソール、AWS Command Line Interface (AWS CLI)、AWS SDK、または Amazon S3 REST API を使用して削除できます。
## メタデータテーブル設定を削除する
### S3 コンソールの使用
**メタデータテーブル設定を削除するには**
1. AWS マネジメントコンソール にサインインし、Amazon S3 コンソール [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) を開きます。
1. 左のナビゲーションペインで、**[汎用バケット]** を選択します。
1. メタデータテーブル設定を削除する汎用バケットを選択します。
1. バケットの詳細ページで、**[メタデータ]** タブを選択します。
1. **[メタデータ]** タブで、**[削除]** を選択します。
1. **[メタデータ設定を削除]** ダイアログボックスで、「**confirm**」と入力して、設定を削除することを確認します。その後、**[削除]** をクリックします。
### の使用AWS CLI
次のコマンドを実行するには、AWS CLI をインストールして設定する必要があります。AWS CLI をまだインストールしていない場合は、「*AWS Command Line Interface ユーザーガイド*」の「[AWS CLI の最新バージョンのインストールまたは更新](https://docs.aws.amazon.com//cli/latest/userguide/getting-started-install.html)」を参照してください。
別の方法として、AWS CloudShell を使用してコンソールから AWS CLI コマンドを実行することもできます。AWS CloudShell は、AWS マネジメントコンソールから直接起動できる、ブラウザベースの事前認証済みシェルです。詳細については、「AWS CloudShell ユーザーガイド」の「[CloudShell とは](https://docs.aws.amazon.com//cloudshell/latest/userguide/welcome.html)」と「[AWS CloudShell の使用開始](https://docs.aws.amazon.com//cloudshell/latest/userguide/getting-started.html)」を参照してください。**
**AWS CLI を使用してメタデータテーブル設定を削除するには**
次のコマンド例を使用する際は、`user input placeholders` をユーザー自身の情報に置き換えます。
1. 次のコマンドを使用して、メタデータテーブル設定を汎用バケット (例: `amzn-s3-demo-bucket`) から削除します。
```
aws s3api delete-bucket-metadata-configuration \
--bucket amzn-s3-demo-bucket \
--region us-east-2
```
1. 設定が削除されたことを確認するには、次のコマンドを使用します。
```
aws s3api get-bucket-metadata-configuration \
--bucket amzn-s3-demo-bucket \
--region us-east-2
```
### REST API の使用
REST リクエストを送信して、メタデータテーブル設定を削除できます。詳細については、[ を参照してください。DeleteBucketMetadataConfiguration](https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketMetadataConfiguration.html)
**注記**
V1 または V2 メタデータテーブル設定で V2 `DeleteBucketMetadataConfiguration` API オペレーションを使用できます。ただし、V2 設定で V1 `DeleteBucketMetadataTableConfiguration` API オペレーションを使用しようとすると、HTTP `405 Method Not Allowed` エラーが発生します。
### AWS SDK の使用
AWS SDK を使用して、Amazon S3 でメタデータテーブル設定を削除できます。詳細については、「[サポートされる SDK のリスト](https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketMetadataConfiguration.html#API_DeleteBucketMetadataConfiguration_SeeAlso)」を参照してください。
# メタデータテーブルの削除
Amazon S3 汎用バケット用に作成したメタデータテーブルを削除する場合は、AWS マネージドテーブルバケットからメタデータテーブルを削除できます。
**重要**
テーブルの削除は永続的であり、元に戻すことはできません。テーブルを削除する前に、重要なデータをバックアップしていることを確認してください。
メタデータテーブルを削除する前に、まず汎用バケット上の関連するメタデータテーブル設定を削除することをお勧めします。詳細については、「[メタデータテーブル設定の削除](metadata-tables-delete-configuration.md)」を参照してください。
AWS マネージドテーブルバケットを削除するには、「*Amazon S3 API Reference*」の「[Deleting table buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-buckets-delete.html)」および「[https://docs.aws.amazon.com/AmazonS3/latest/API/API_s3TableBuckets_DeleteTableBucket.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_s3TableBuckets_DeleteTableBucket.html)」を参照してください。AWS マネージドテーブルバケットを削除する前に、このバケットに関連付けられているすべてのメタデータテーブル設定を削除することをお勧めします。また、まずバケット内のすべてのメタデータテーブルを削除する必要があります。
メタデータテーブルは、AWS Command Line Interface (AWS CLI)、AWS SDK、または Amazon S3 REST API を使用して削除できます。
## メタデータテーブルを削除する
### の使用AWS CLI
次のコマンドを実行するには、AWS CLI をインストールして設定する必要があります。AWS CLI をまだインストールしていない場合は、「*AWS Command Line Interface ユーザーガイド*」の「[AWS CLI の最新バージョンのインストールまたは更新](https://docs.aws.amazon.com//cli/latest/userguide/getting-started-install.html)」を参照してください。
別の方法として、AWS CloudShell を使用してコンソールから AWS CLI コマンドを実行することもできます。AWS CloudShell は、AWS マネジメントコンソールから直接起動できる、ブラウザベースの事前認証済みシェルです。詳細については、「AWS CloudShell ユーザーガイド」の「[CloudShell とは](https://docs.aws.amazon.com//cloudshell/latest/userguide/welcome.html)」と「[AWS CloudShell の使用開始](https://docs.aws.amazon.com//cloudshell/latest/userguide/getting-started.html)」を参照してください。**
**AWS CLI を使用してメタデータテーブル設定を削除するには**
次のコマンド例を使用する際は、`user input placeholders` をユーザー自身の情報に置き換えます。
1. 次のコマンドを使用して、メタデータテーブルを AWS マネージドテーブルバケットから削除します。
```
aws s3tables delete-table \
--table-bucket-arn arn:aws:s3tables:us-east-2:111122223333:bucket/aws-s3 \
--namespace b_general-purpose-bucket-name \
--name journal \
--region us-east-2
```
1. テーブルが削除されたことを確認するには、次のコマンドを使用します。
```
aws s3tables get-table \
--table-bucket-arn arn:aws:s3tables:us-east-2:111122223333:bucket/aws-s3 \
--namespace b_general-purpose-bucket-name \
--name journal \
--region us-east-2
```
### REST API の使用
REST リクエストを送信して、メタデータテーブル設定を削除できます。詳細については、「**Amazon S3 API リファレンス」の「[https://docs.aws.amazon.com/AmazonS3/latest/API/API_s3TableBuckets_DeleteTable.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_s3TableBuckets_DeleteTable.html)」を参照してください。
### AWS SDK の使用
AWS SDK を使用して、Amazon S3 でメタデータテーブル設定を削除できます。詳細については、「*Amazon S3 API Reference*」にある「[サポートされる SDK のリスト](https://docs.aws.amazon.com/AmazonS3/latest/API/API_s3TableBuckets_DeleteTable.html#API_s3TableBuckets_DeleteTable_SeeAlso)」を参照してください。
# メタデータテーブルのクエリ
Amazon S3 Metadata テーブルは、表形式データ用に最適化されたストレージを提供する AWS マネージド S3 テーブルバケットに保存されます。メタデータをクエリするために、テーブルバケットを Amazon SageMaker Lakehouse と統合できます。AWS Glue Data Catalog および AWS Lake Formation を使用するこの統合により、AWS 分析サービスがテーブルデータを自動的に検出してアクセスできるようになります。
テーブルバケットが AWS Glue Data Catalog と統合されると、Amazon Athena、Amazon EMR、Amazon Redshift などの AWS 分析サービスを使用してメタデータテーブルを直接クエリできます。そこから、Amazon Quick を使用して、クエリデータでインタラクティブなダッシュボードを作成できます。
AWS マネージド S3 テーブルバケットと Amazon SageMaker Lakehouse の統合の詳細については、「[Amazon S3 Tables と AWS 分析サービスの統合](s3-tables-integrating-aws.md)」を参照してください。
AWS Glue Iceberg REST エンドポイント、Amazon S3 Tables Iceberg REST エンドポイント、または Apache Iceberg クライアントカタログの Amazon S3 Tables Catalog を使用して、Apache Spark、Apache Trino、および Apache Iceberg 形式をサポートする他のアプリケーションでメタデータテーブルをクエリすることもできます。メタデータテーブルへのアクセスの詳細については、「[テーブルデータへのアクセス](s3-tables-access.md)」を参照してください。
Apache Iceberg 形式をサポートする任意のクエリエンジンを使用してメタデータテーブルを分析することもできます。例えば、メタデータテーブルをクエリして、以下を実行できます。
+ ストレージの使用パターンと傾向を確認する
+ オブジェクト全体の AWS Key Management Service (AWS KMS) 暗号化キーの使用状況を監査する
+ ユーザー定義メタデータとオブジェクトタグでオブジェクトを検索する
+ オブジェクトメタデータの経時的な変化を理解する
+ リクエストを行った AWS アカウント ID や IP アドレスなど、オブジェクトがいつ更新または削除されたかを知る
S3 マネージドメタデータテーブルとカスタムメタデータテーブルを結合して、複数のデータセット間でクエリを実行することもできます。
## クエリ料金に関する考慮事項
メタデータテーブルでクエリを実行する場合は、追加料金が適用されます。詳細については、使用しているクエリエンジンの料金情報を参照してください。
クエリのコスト効率を高める方法については、「[メタデータテーブルのクエリパフォーマンスの最適化](metadata-tables-optimizing-query-performance.md)」を参照してください。
**Topics**
+ [
## クエリ料金に関する考慮事項
](#metadata-tables-querying-pricing)
+ [
# メタデータテーブルをクエリするためのアクセス許可
](metadata-tables-bucket-query-permissions.md)
+ [
# AWS 分析サービスを使用したメタデータテーブルのクエリ
](metadata-tables-bucket-integration.md)
+ [
# オープンソースのクエリエンジンを使用したメタデータテーブルのクエリ
](metadata-tables-bucket-integration-open-source.md)
+ [
# メタデータテーブルのクエリパフォーマンスの最適化
](metadata-tables-optimizing-query-performance.md)
+ [
# メタデータテーブルクエリの例
](metadata-tables-example-queries.md)
# メタデータテーブルをクエリするためのアクセス許可
S3 Metadata ジャーナルテーブルとライブインベントリテーブルをクエリする前に、特定の S3 Tables アクセス許可が必要です。メタデータテーブルが AWS Key Management Service (AWS KMS) キー (SSE-KMS) を使用したサーバー側の暗号化で暗号化されている場合は、テーブルデータを復号する `kms:Decrypt` アクセス許可も必要です。
メタデータテーブル設定を作成すると、メタデータテーブルは AWS マネージドテーブルバケットに保存されます。アカウントと同じリージョンのすべてのメタデータテーブル設定は、`aws-s3` という名前の単一の AWS マネージドテーブルバケットに保存されます。
メタデータテーブルをクエリするには、次のポリシー例を使用できます。このポリシーを使用するには、`user input placeholders` をユーザー自身の情報に置き換えます。
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"PermissionsToQueryMetadataTables",
"Effect":"Allow",
"Action":[
"s3tables:GetTable",
"s3tables:GetTableData",
"s3tables:GetTableMetadataLocation",
"kms:Decrypt"
],
"Resource":[
"arn:aws:s3tables:us-east-1:111122223333:bucket/aws-s3",
"arn:aws:s3tables:us-east-1:111122223333:bucket/aws-s3/table/*",
"arn:aws:kms:us-east-1:111122223333:key/01234567-89ab-cdef-0123-456789abcdef"
]
}
]
}
```
# AWS 分析サービスを使用したメタデータテーブルのクエリ
Amazon Athena、Amazon Redshift、Amazon EMR などの AWS 分析サービスを使用して、S3 マネージドメタデータテーブルをクエリできます。
クエリを実行する前に、まずご利用の AWS アカウントおよびリージョンの [AWS マネージド S3 テーブルバケットを AWS 分析サービスと統合する](s3-tables-integrating-aws.md)必要があります。
## Amazon Athena を使用したメタデータテーブルのクエリ
AWS 分析サービスと [AWS マネージド S3 テーブルバケットを統合](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-integrating-aws.html)したら、Athena でメタデータテーブルのクエリを開始できます。リクエストで、以下の操作を実行します。
+ カタログを `s3tablescatalog/aws-s3` に、データベースを `b_general_purpose_bucket_name` (一般的にはメタデータテーブルの名前空間) に指定します。
+ メタデータテーブル名前空間名は必ず引用符 (`"`) またはバックティック (```) で囲んでください。囲まない場合、クエリが機能しない可能性があります。
詳細については、「[Querying Amazon S3 tables with Athena](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-integrating-athena.html)」を参照してください。
Amazon S3 コンソールから Athena でクエリを実行することもできます。
### S3 コンソールと Amazon Athena の使用
以下の手順では、Amazon S3 コンソールを使用して Athena クエリエディタにアクセスし、Amazon Athena でテーブルに対してクエリを実行できるようにします。
**メタデータテーブルをクエリするには**
1. AWS マネジメントコンソール にサインインし、Amazon S3 コンソール [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) を開きます。
1. 左のナビゲーションペインで、**[汎用バケット]** を選択します。
1. **[汎用バケット]** タブで、クエリするメタデータテーブルのメタデータ設定を含むバケットを選択します。
1. バケットの詳細ページで、**[メタデータ]** タブを選択します。
1. **[Athena でテーブルのクエリを実行]** を選択し、ジャーナルテーブルまたはインベントリテーブルのサンプルクエリのいずれかを選択します。
1. Amazon Athena コンソールが開き、サンプル クエリがロードされた状態で Athena クエリエディタが表示されます。必要に応じて、このクエリをユースケースに合わせて変更します。
クエリエディタで、**[カタログ]** フィールドに **s3tablescatalog/aws-s3** を入力する必要があります。**[データベース]** フィールドには、テーブルが保存されている名前空間 (**b\$1*general-purpose-bucket-name* など**) を入力する必要があります。
**注記**
**[カタログ]** および **[データベース]** フィールドにこれらの値が表示されない場合は、このリージョンで AWS マネージドテーブルバケットを AWS 分析サービスと統合していることを確認してください。詳細については、「[Amazon S3 Tables と AWS 分析サービスの統合](s3-tables-integrating-aws.md)」を参照してください。
1. クエリを実行するには、**[Run]** (実行) を選択します。
**注記**
Athena でクエリを実行しようとしたときに、クエリを実行するためのアクセス許可が不足しており、プリンシパルは指定されたリソースに対する権限を持っていないという内容のエラーが表示される場合は、テーブルに対する必要な Lake Formation 許可が付与されている必要があります。詳細については、「[テーブルまたはデータベースに対する Lake Formation アクセス許可の付与](grant-permissions-tables.md#grant-lf-table)」を参照してください。
また、メタデータテーブルをクエリするための適切な AWS Identity and Access Management (IAM) アクセス許可があることを確認してください。詳細については、「[メタデータテーブルをクエリするためのアクセス許可](metadata-tables-bucket-query-permissions.md)」を参照してください。
クエリを実行しようとしたときに、Iceberg はリクエストされたリソースにアクセスできないという内容のエラーが表示される場合は、AWS Lake Formation コンソールに移動し、作成したテーブルバケットカタログとデータベース (名前空間) に対するアクセス許可が自分に付与されていることを確認してください。これらのアクセス許可を付与するときは、テーブルを指定しないでください。詳細については、「[テーブルまたはデータベースに対する Lake Formation アクセス許可の付与](grant-permissions-tables.md#grant-lf-table)」を参照してください。
## Amazon Redshift を使用したメタデータテーブルのクエリ
AWS 分析サービスと [AWS マネージド S3 テーブルバケットを統合](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-integrating-aws.html)した後、以下を行います。
+ メタデータテーブル名前空間 (一般的には `b_general_purpose_bucket_name`) への[リソースリンクを作成します](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-integrating-aws.html#database-link-tables)。
+ メタデータテーブル名前空間名は必ず引用符 (`"`) またはバックティック (```) で囲んでください。囲まない場合、クエリが機能しない可能性があります。
これが完了すると、Amazon Redshift コンソールでメタデータテーブルのクエリを開始できます。詳細については、「[Accessing Amazon S3 tables with Amazon Redshift](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-integrating-redshift.html)」を参照してください。
## Amazon EMR を使用したメタデータテーブルのクエリ
Amazon EMR を使用してメタデータテーブルをクエリするには、Apache Iceberg 用に設定された Amazon EMR クラスターを作成し、Apache Spark を使用してメタデータテーブルに接続します。これを設定するには、AWS マネージド S3 テーブルバケットを AWS 分析サービスと統合するか、オープンソースの Iceberg クライアントカタログ用 Amazon S3 Tables Catalog を使用します。
**注記**
Amazon EMR または他のサードパーティーエンジンで Apache Spark を使用してメタデータテーブルをクエリする場合は、Amazon S3 Tables Iceberg REST エンドポイントを使用することをお勧めします。このエンドポイントを使用しないと、クエリが正常に実行されない可能性があります。詳細については、「[Amazon S3 Tables Iceberg REST エンドポイントを使用したテーブルへのアクセス](s3-tables-integrating-open-source.md)」を参照してください。
詳細については、「[Accessing Amazon S3 tables with Amazon EMR](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-integrating-emr.html)」を参照してください。
# オープンソースのクエリエンジンを使用したメタデータテーブルのクエリ
Apache Spark などのオープンソースのクエリエンジンを使用して、S3 マネージドメタデータテーブルをクエリできます。Amazon EMR または他のサードパーティーエンジンで Apache Spark を使用してメタデータテーブルをクエリする場合は、Amazon S3 Tables Iceberg REST エンドポイントを使用することをお勧めします。このエンドポイントを使用しないと、クエリが正常に実行されない可能性があります。詳細については、「[Amazon S3 Tables Iceberg REST エンドポイントを使用したテーブルへのアクセス](s3-tables-integrating-open-source.md)」を参照してください。
# メタデータテーブルのクエリパフォーマンスの最適化
S3 Metadata は Apache Iceberg テーブル形式に基づいているため、特定の時間範囲を使用することで、ジャーナルテーブルクエリのパフォーマンスと[コスト](#metadata-tables-optimizing-query-performance)を最適化できます。
例えば、次の SQL クエリは、S3 汎用バケット内の新しいオブジェクトの機密レベルを提供します。
```
SELECT key, object_tags['SensitivityLevel']
FROM "b_general-purpose-bucket-name"."journal"
WHERE record_type = 'CREATE'
GROUP BY object_tags['SensitivityLevel']
```
このクエリはジャーナルテーブル全体をスキャンするため、実行に時間がかかる場合があります。パフォーマンスを向上させるには、特定の時間範囲に焦点を絞る `record_timestamp` 列を含めることができます。また、完全修飾テーブル名を使用することをお勧めします。これは、汎用バケットの **[メタデータ]** タブで、メタデータ設定の詳細ページの Amazon S3 コンソールにあります。以下は、過去 1 か月の新しいオブジェクトを調べる、以前のクエリが更新されたバージョンです。
```
SELECT key, object_tags['SensitivityLevel']
FROM b_general-purpose-bucket-name"."aws-s3.b_general-purpose-bucket-name.journal"
WHERE record_type = 'CREATE'
AND record_timestamp > (CURRENT_TIMESTAMP – interval '1' month)
GROUP BY object_tags['SensitivityLevel']
```
インベントリテーブルに対するクエリのパフォーマンスを向上させるには、必要な最小限の列に対してのみクエリを実行してください。
# メタデータテーブルクエリの例
次の例は、標準 SQL クエリを使用して S3 メタデータテーブルからさまざまなタイプの情報を取得する方法を示しています。
これらの例を使用する際は、次の点に注意してください。
+ 例は、Amazon Athena で動作するように記述されています。別のクエリエンジンで動作するためには、例を変更する必要がある場合があります。
+ [クエリを最適化](metadata-tables-optimizing-query-performance.md)する方法を理解していることを確認してください。
+ `b_general-purpose-bucket-name` を名前空間の名前に置き換えます。
+ サポートされている列の完全なリストについては、「[S3 Metadata ジャーナルテーブルスキーマ](metadata-tables-schema.md)」および「[S3 Metadata ライブインベントリテーブルスキーマ](metadata-tables-inventory-schema.md)」を参照してください。
**Contents**
+ [
## ジャーナルテーブルのクエリ例
](#metadata-tables-example-queries-journal-tables)
+ [
### ファイル拡張子によるオブジェクトの検索
](#metadata-tables-example-query-object-pattern)
+ [
### オブジェクトの削除の一覧表示
](#metadata-tables-example-query-delete-events)
+ [
### オブジェクトで使用される AWS KMS 暗号化キーの一覧表示
](#metadata-tables-example-query-objects-using-kms-key)
+ [
### KMS キーを使用しないオブジェクトの一覧表示
](#metadata-tables-example-query-objects-not-using-kms-key)
+ [
### 過去 7 日間の `PUT` オペレーションに使用される AWS KMS 暗号化キーの一覧表示
](#metadata-tables-example-query-objects-using-kms-key-puts)
+ [
### 過去 24 時間以内に削除されたオブジェクトを S3 ライフサイクル別に一覧表示する
](#metadata-tables-example-query-objects-deleted-lifecycle)
+ [
### Amazon Bedrock が提供するメタデータの表示
](#metadata-tables-example-query-bedrock)
+ [
### オブジェクトの現状の把握
](#metadata-tables-example-query-current-state)
+ [
## インベントリテーブルのクエリ例
](#metadata-tables-example-queries-inventory-tables)
+ [
### 特定のタグを使用するデータセットの検出
](#metadata-tables-example-query-datasets-specific-tags)
+ [
### SSE-KMS で暗号化されていないオブジェクトの一覧表示
](#metadata-tables-example-query-objects-not-kms-encrypted)
+ [
### 暗号化されていないオブジェクトの一覧表示
](#metadata-tables-example-query-objects-not-encrypted)
+ [
### Amazon Bedrock によって生成されたオブジェクトの一覧表示
](#metadata-tables-example-query-objects-generated-bedrock)
+ [
### インベントリテーブルとジャーナルテーブルの照合
](#metadata-tables-example-query-generate-latest-inventory)
+ [
### オブジェクトの最新バージョンの検索
](#metadata-tables-example-query-latest-version)
+ [
# カスタムメタデータと S3 メタデータテーブルの結合
](metadata-tables-join-custom-metadata.md)
+ [
# Amazon Quick を使用したメタデータテーブルデータの視覚化
](metadata-tables-quicksight-dashboards.md)
## ジャーナルテーブルのクエリ例
次のクエリ例を使用して、ジャーナルテーブルをクエリできます。
### ファイル拡張子によるオブジェクトの検索
次のクエリは、特定のファイル拡張子 (この場合は `.jpg`) を持つオブジェクトを返します。
```
SELECT key FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."journal"
WHERE key LIKE '%.jpg'
AND record_type = 'CREATE'
```
### オブジェクトの削除の一覧表示
次のクエリは、リクエストを行った AWS アカウント ID または AWS サービスプリンシパルを含むオブジェクト削除イベントを返します。
```
SELECT DISTINCT bucket, key, sequence_number, record_type, record_timestamp, requester, source_ip_address, version_id
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."journal"
WHERE record_type = 'DELETE';
```
### オブジェクトで使用される AWS KMS 暗号化キーの一覧表示
次のクエリは、オブジェクトを暗号化する AWS Key Management Service (AWS KMS) キーの ARN を返します。
```
SELECT DISTINCT kms_key_arn
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."journal";
```
### KMS キーを使用しないオブジェクトの一覧表示
次のクエリは、AWS KMS キーで暗号化されていないオブジェクトを返します。
```
SELECT DISTINCT kms_key_arn
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."journal"
WHERE encryption_status NOT IN ('SSE-KMS', 'DSSE-KMS')
AND record_type = 'CREATE';
```
### 過去 7 日間の `PUT` オペレーションに使用される AWS KMS 暗号化キーの一覧表示
次のクエリは、オブジェクトを暗号化する AWS Key Management Service (AWS KMS) キーの ARN を返します。
```
SELECT DISTINCT kms_key_arn
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."journal"
WHERE record_timestamp > (current_date - interval '7' day)
AND kms_key_arn is NOT NULL;
```
### 過去 24 時間以内に削除されたオブジェクトを S3 ライフサイクル別に一覧表示する
次のクエリは、S3 ライフサイクルによって最終日に期限切れになったオブジェクトを一覧表示します。
```
SELECT bucket, key, version_id, last_modified_date, record_timestamp, requester
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."journal"
WHERE requester = 's3.amazonaws.com'
AND record_type = 'DELETE'
AND record_timestamp > (current_date - interval '1' day)
```
### Amazon Bedrock が提供するメタデータの表示
一部の AWS サービス ([Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/APIReference/welcome.html) など) は、Amazon S3 にオブジェクトをアップロードします。これらのサービスによって提供されるオブジェクトメタデータをクエリできます。例えば、次のクエリには、Amazon Bedrock によって汎用バケットにアップロードされたオブジェクトがあるかどうかを判断する `user_metadata` 列が含まれています。
```
SELECT DISTINCT bucket, key, sequence_number, record_type, record_timestamp, user_metadata
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."journal"
WHERE record_type = 'CREATE'
AND user_metadata['content-source'] = 'AmazonBedrock';
```
Amazon Bedrock がバケットにオブジェクトをアップロードした場合、`user_metadata` 列には、クエリ結果のオブジェクトに関連付けられた次のメタデータが表示されます。
```
user_metadata
{content-additional-params -> requestid="CVK8FWYRW0M9JW65", signedContentSHA384="38b060a751ac96384cd9327eb1b1e36a21fdb71114be07434c0cc7bf63f6e1da274edebfe76f65fbd51ad2f14898b95b", content-model-id -> bedrock-model-arn, content-source -> AmazonBedrock}
```
### オブジェクトの現状の把握
次のクエリは、オブジェクトの現在の状態を判断するのに役立ちます。クエリは、各オブジェクトの最新バージョンを識別し、削除されたオブジェクトを除外し、シーケンス番号に基づいて各オブジェクトの最新バージョンをマークします。結果は、`bucket`、`key`、および `sequence_number` 列で順序付けられます。
```
WITH records_of_interest as (
-- Start with a query that can narrow down the records of interest.
SELECT * from "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."journal"
),
version_stacks as (
SELECT *,
-- Introduce a column called 'next_sequence_number', which is the next larger
-- sequence_number for the same key version_id in sorted order.
LEAD(sequence_number, 1) over (partition by (bucket, key, coalesce(version_id, '')) order by sequence_number ASC) as next_sequence_number
from records_of_interest
),
-- Pick the 'tip' of each version stack triple: (bucket, key, version_id).
-- The tip of the version stack is the row of that triple with the largest sequencer.
-- Selecting only the tip filters out any row duplicates.
-- This isn't typical, but some events can be delivered more than once to the table
-- and include rows that might no longer exist in the bucket (since the
-- table contains rows for both extant and extinct objects).
-- In the next subquery, eliminate the rows that contain deleted objects.
current_versions as (
SELECT * from version_stacks where next_sequence_number is NULL
),
-- Eliminate the rows that are extinct from the bucket by filtering with
-- record_type. An object version has been deleted from the bucket if its tip is
-- record_type==DELETE.
existing_current_versions as (
SELECT * from current_versions where not (record_type = 'DELETE' and is_delete_marker = FALSE)
),
-- Optionally, to determine which of several object versions is the 'latest',
-- you can compare their sequence numbers. A version_id is the latest if its
-- tip's sequencer is the largest among all other tips in the same key.
with_is_latest as (
SELECT *,
-- Determine if the sequence_number of this row is the same as the largest sequencer for the key that still exists.
sequence_number = (MAX(sequence_number) over (partition by (bucket, key))) as is_latest_version
FROM existing_current_versions
)
SELECT * from with_is_latest
ORDER BY bucket, key, sequence_number;
```
## インベントリテーブルのクエリ例
次のクエリ例を使用して、インベントリテーブルをクエリできます。
### 特定のタグを使用するデータセットの検出
次のクエリは、指定されたタグを使用するデータセットを返します。
```
SELECT *
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."inventory"
WHERE object_tags['key1'] = 'value1'
AND object_tags['key2'] = 'value2';
```
### SSE-KMS で暗号化されていないオブジェクトの一覧表示
次のクエリは、SSE-KMS キーで暗号化されていないオブジェクトを返します。
```
SELECT key, encryption_status
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."inventory"
WHERE encryption_status != 'SSE-KMS';
```
### 暗号化されていないオブジェクトの一覧表示
次のクエリは、暗号化されていないオブジェクトを返します。
```
SELECT bucket, key, version_id
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."inventory"
WHERE encryption_status IS NULL;
```
### Amazon Bedrock によって生成されたオブジェクトの一覧表示
次のクエリは、Amazon Bedrock によって生成されたオブジェクトを一覧表示します。
```
SELECT DISTINCT bucket, key, sequence_number, user_metadata
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."inventory"
WHERE user_metadata['content-source'] = 'AmazonBedrock';
```
### インベントリテーブルとジャーナルテーブルの照合
次のクエリは、バケットの現在のコンテンツを含む最新の inventory-table-like リストを生成します。より正確には、結果のリストはインベントリテーブルの最新スナップショットとジャーナルテーブルの最新イベントを組み合わせます。
このクエリで最も正確な結果を生成するには、ジャーナルテーブルとインベントリテーブルの両方がアクティブステータスである必要があります。
10 億 (10^9) 未満のオブジェクトを含む汎用バケットに、このクエリを使用することをお勧めします。
このクエリ例では、リスト結果に次の簡略化を適用します (インベントリテーブルと比較)。
+ **列の省略** – 列 `bucket`、`is_multipart`、`encryption_status`、`is_bucket_key_enabled`、`kms_key_arn`、`checksum_algorithm` は最終結果の一部ではありません。オプションの列のセットを最小限に抑えると、パフォーマンスが向上します。
+ **すべてのレコードを含める** – クエリは、null バージョン (バージョニングされていないバケットまたはバージョニングが停止されたバケット内) と削除マーカーを含むすべてのオブジェクトキーとバージョンを返します。目的のキーのみを表示するように結果をフィルタリングする方法の例については、クエリの最後にある `WHERE` 句を参照してください。
+ **高速調整** – クエリは、まれに、バケットになくなったオブジェクトを一時的にレポートすることがあります。これらの不一致は、インベントリテーブルの次のスナップショットが利用可能になるとすぐに削除されます。この動作は、パフォーマンスと精度のトレードオフです。
Amazon Athena でこのクエリを実行するには、ジャーナルテーブルとインベントリテーブルを含む汎用バケットメタデータ設定の `s3tablescatalog/aws-s3` カタログと `b_general-purpose-bucket-name` データベースを必ず選択してください。
```
WITH inventory_time_cte AS (
SELECT COALESCE(inventory_time_from_property, inventory_time_default) AS inventory_time FROM
(
SELECT * FROM
(VALUES (TIMESTAMP '2024-12-01 00:00')) AS T (inventory_time_default)
LEFT OUTER JOIN
(
SELECT from_unixtime(CAST(value AS BIGINT) / 1000.0) AS inventory_time_from_property FROM "journal$properties"
WHERE key = 'aws.s3metadata.oldest-uncoalesced-record-timestamp' LIMIT 1
)
ON TRUE
)
),
working_set AS (
SELECT
key,
sequence_number,
version_id,
is_delete_marker,
size,
COALESCE(last_modified_date, record_timestamp) AS last_modified_date,
e_tag,
storage_class,
object_tags,
user_metadata,
(record_type = 'DELETE' AND NOT COALESCE(is_delete_marker, FALSE)) AS _is_perm_delete
FROM journal j
CROSS JOIN inventory_time_cte t
WHERE j.record_timestamp > (t.inventory_time - interval '15' minute)
UNION ALL
SELECT
key,
sequence_number,
version_id,
is_delete_marker,
size,
last_modified_date,
e_tag,
storage_class,
object_tags,
user_metadata,
FALSE AS _is_perm_delete
FROM inventory i
),
updated_inventory AS (
SELECT * FROM (
SELECT *,
MAX(sequence_number) OVER (PARTITION BY key, version_id) AS _supremum_sn
FROM working_set
)
WHERE sequence_number = _supremum_sn
)
SELECT
key,
sequence_number,
version_id,
is_delete_marker,
size,
last_modified_date,
e_tag,
storage_class,
object_tags,
user_metadata
FROM updated_inventory
-- This filter omits only permanent deletes from the results. Delete markers will still be shown.
WHERE NOT _is_perm_delete
-- You can add additional filters here. Examples:
-- AND object_tags['department'] = 'billing'
-- AND starts_with(key, 'reports/')
ORDER BY key ASC, sequence_number DESC;
```
### オブジェクトの最新バージョンの検索
次のクエリでは、インベントリテーブルを使用して、どのオブジェクトバージョンが最新であるかを示す新しい出力テーブルを生成します。出力テーブルは、意図的に S3 インベントリレポートに似せています。出力テーブルには、オブジェクトが現在のバージョンであるかどうかを示す `is_latest` フィールドが含まれています。`is_latest` フィールドは、[S3 インベントリレポート](storage-inventory.md#storage-inventory-contents)の **IsLatest** フィールドと同等です。
このクエリは、バージョニングが有効またはバージョニングが停止状態の [S3 バージョニング](Versioning.md)を使用する汎用バケットで機能します。
**前提条件**
クエリは、結果を新しい S3 テーブルに出力して、さらなるクエリをサポートし、画面上に行を出力する場合よりもパフォーマンスを向上させます。したがって、このクエリを実行する前に、次の条件を満たしていることを確認してください。結果を新しいテーブルに出力しない場合は、以下の手順をスキップできます。
+ 新しいテーブルを出力する場所として、既存の名前空間を持つ既存のカスタマーマネージドのテーブルバケットが必要です。詳細については、「[テーブルバケットの作成](s3-tables-buckets-create.md)」および「[ネームスペースの作成](s3-tables-namespace-create.md)」を参照してください。
+ 新しい出力テーブルをクエリするには、そのテーブルをクエリするためのアクセス方法を設定する必要があります。詳細については、「[テーブルデータへのアクセス](s3-tables-access.md)」を参照してください。Amazon Athena などの AWS 分析サービスを使用して出力テーブルをクエリする場合は、カスタマーマネージドのテーブルバケットを AWS 分析サービスと統合する必要があります。詳細については、「[Amazon S3 Tables と AWS 分析サービスの統合の概要](s3-tables-integration-overview.md)」を参照してください。
このクエリを使用するには、`amzn-s3-demo-table-bucket` を新しい出力テーブルを作成する既存のカスタマーマネージドのテーブルバケットの名前に置き換えます。*`existing_namespace`* を、テーブルバケットに出力テーブルを作成する名前空間の名前に置き換えます。*`new_table`* は、出力テーブルに使用する名前に置き換えます。出力テーブルの名前が[テーブルの命名規則](s3-tables-buckets-naming.md#naming-rules-table)に従っていることを確認します。
Amazon Athena でこのクエリを実行するには、インベントリテーブルを含む汎用バケットメタデータ設定の `s3tablescatalog/aws-s3` カタログと `b_general-purpose-bucket-name` データベースを必ず選択してください。
```
-- If you don't want to output the results to a new table, remove the following two lines
-- (everything before the WITH clause).
CREATE TABLE "s3tablescatalog/amzn-s3-demo-table-bucket"."existing_namespace"."new_table"
as (
WITH
my_inventory AS (
SELECT
bucket,
key,
version_id,
sequence_number,
is_delete_marker,
size,
last_modified_date,
storage_class
FROM inventory
-- For prefix filtering, use a WHERE clause with % at the end.
-- WHERE key LIKE 'prefix%'
),
inventory_with_is_latest as (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY key
ORDER BY sequence_number DESC
) = 1 AS is_latest
FROM my_inventory
)
SELECT
bucket,
key,
version_id,
sequence_number,
is_delete_marker,
size,
last_modified_date,
storage_class,
is_latest
FROM inventory_with_is_latest
-- If you want only the current version of each key, uncomment the following WHERE clause.
-- WHERE is_latest = TRUE
-- If you aren't outputting the results to a new table, remove the next line:
);
```
# カスタムメタデータと S3 メタデータテーブルの結合
AWS マネージドメタデータテーブルとカスタマー (セルフマネージド) メタデータテーブル全体のデータを分析できます。標準の SQL `JOIN` 演算子を使用すると、これらの複数のソースからのデータをクエリできます。
次の SQL クエリの例は、AWS マネージドジャーナルテーブル (`"journal"`) とセルフマネージドメタデータテーブル (`my_self_managed_metadata_table`) の間で一致するレコードを検索します。また、クエリは、新しいオブジェクト (またはオブジェクトの新しいバージョン) がバケットに書き込まれたことを示す `CREATE` イベントに基づいて情報をフィルタリングします。(詳細については、[S3 Metadata ジャーナルテーブルスキーマ](metadata-tables-schema.md) を参照してください。)
```
SELECT *
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."journal" a
JOIN "my_namespace"."my_self_managed_metadata_table" b
ON a.bucket = b.bucket AND a.key = b.key AND a.version_id = b.version_id
WHERE a.record_type = 'CREATE';
```
次の SQL クエリの例は、AWS マネージドインベントリテーブル (`"inventory"`) とセルフマネージドメタデータテーブル (`my_self_managed_metadata_table`) の間で一致するレコードを検索します。
```
SELECT *
FROM "s3tablescatalog/aws-s3"."b_general-purpose-bucket-name"."inventory" a
JOIN "my_namespace"."my_self_managed_metadata_table" b
ON a.bucket = b.bucket AND a.key = b.key AND a.version_id = b.version_id;
```
# Amazon Quick を使用したメタデータテーブルデータの視覚化
Amazon Quick を使用すると、インタラクティブなダッシュボードを作成して、S3 マネージドメタデータテーブルに関する SQL クエリ結果を分析および視覚化できます。Quick ダッシュボードは、統計のモニタリング、変更の追跡、メタデータテーブルに関する運用上のインサイトの取得に役立ちます。
ジャーナルテーブルに関するダッシュボードには、以下が表示される場合があります。
+ オブジェクトのうち、削除数と比較したアップロード数の比率
+ 過去 24 時間に S3 ライフサイクルによって削除されたオブジェクトはどれか。
+ 最新の `PUT` リクエストはどの IP アドレスから送信されたか。
インベントリテーブルに関するダッシュボードには、以下が表示される場合があります。
+ 異なるストレージクラスにあるオブジェクトの数
+ ストレージデータのうち、大きいオブジェクトと比較した小さいオブジェクトの比率は?
+ バケット内に存在するオブジェクトのタイプ
AWS 分析サービスと [S3 テーブルバケットを統合](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-integrating-aws.html)すると、メタデータテーブルからデータセットを作成し、SPICE またはクエリエンジンからの直接 SQL クエリを使用して Amazon Quick で操作できるようになります。Quick は、データソースとして Amazon Athena と Amazon Redshift をサポートしています。
詳細については、「[Amazon Quick を使用したテーブルデータの視覚化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-integrating-quicksight.html)」を参照してください。
# S3 Metadata のトラブルシューティング
以下の情報を使用して、Amazon S3 Metadata の使用時に発生する可能性がある一般的な問題の診断と修正に役立てます。
## AWS マネージドテーブルバケットとメタデータテーブルを削除できない
メタデータテーブルを削除する前に、まず汎用バケット上の関連するメタデータテーブル設定を削除する必要があります。詳細については、「[メタデータテーブル設定の削除](metadata-tables-delete-configuration.md)」を参照してください。
AWS マネージドテーブルバケットを削除できるようにするには、このバケットに関連付けられているすべてのメタデータテーブル設定と、バケット内のすべてのメタデータテーブルを削除する必要があります。詳細については、「[メタデータテーブル設定の削除](metadata-tables-delete-configuration.md)」および「[メタデータテーブルの削除](metadata-tables-delete-table.md)」を参照してください。
## AWS マネージドメタデータテーブルの暗号化設定を設定または変更できない
メタデータテーブル設定を作成するときに、AWS マネージドメタデータテーブルを AWS Key Management Service (AWS KMS) キーを使用したサーバー側の暗号化 (SSE-KMS) で暗号化することを選択できます。SSE-KMS を使用する場合は、汎用バケットと同じリージョンにカスタマーマネージド KMS キーを指定する必要があります。テーブルの暗号化タイプは、テーブルの作成中にのみ設定できます。AWS マネージドテーブルの作成後は、暗号化設定を変更することはできません。メタデータテーブルに SSE-KMS を指定するには、特定のアクセス許可が必要です。詳細については、「[SSE-KMS のアクセス許可](metadata-tables-permissions.md#metadata-kms-permissions)」を参照してください。
メタデータテーブルの暗号化設定は、デフォルトのバケットレベルの暗号化設定よりも優先されます。暗号化を指定しない場合、テーブルはバケットのデフォルト暗号設定を継承します。
デフォルトでは、AWS マネージドテーブルバケットは、Amazon S3 マネージドキーによるサーバー側の暗号化 (SSE-S3) を使用して暗号化されます。最初のメタデータ設定を作成したら、AWS マネージドテーブルバケットのデフォルトの暗号化設定を設定して、AWS Key Management Service (AWS KMS) キーによるサーバー側の暗号化 (SSE-KMS) を使用できます。詳細については、「[Encryption for AWS managed table buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-aws-managed-buckets.html#aws-managed-buckets-encryption)」および「[テーブルバケットでの AWS KMS キーによるサーバー側の暗号化 (SSE-KMS) の指定](s3-tables-kms-specify.md)」を参照してください。
## メタデータテーブル設定を再作成しようとすると、エラーが発生する
メタデータテーブル設定を削除すると、設定のみが削除されます。メタデータテーブル設定を削除しても、AWS マネージドテーブルバケットとメタデータテーブルは引き続き存在します。
メタデータテーブル設定を削除し、同じ汎用バケットの設定を再作成する場合は、まず AWS マネージドテーブルバケットから古いジャーナルテーブルとインベントリテーブルを手動で削除する必要があります。削除しない場合、新しいメタデータテーブル設定の作成は、それらのテーブルが既に存在するため失敗します。
メタデータテーブルを削除するには、「[メタデータテーブルの削除](metadata-tables-delete-table.md)」を参照してください。
## 設定でインベントリテーブルを有効にできない
2025 年 7 月 15 日より前に S3 Metadata 設定を作成した場合、その設定でインベントリテーブルを有効にすることはできません。インベントリテーブルを作成してジャーナルテーブルレコードの有効期限が切れるように、設定を削除して再作成することをお勧めします。詳細については、「[2025 年 7 月 15 日より前に作成されたメタデータ設定でインベントリテーブルを有効にする](metadata-tables-create-configuration.md#metadata-tables-migration)」を参照してください。
## 設定でジャーナルテーブルレコードの有効期限を有効にできない
2025 年 7 月 15 日より前に S3 Metadata 設定を作成した場合、その設定でジャーナルテーブルレコードの有効期限を有効にすることはできません。ジャーナルテーブルレコードを期限切れにしてインベントリテーブルを作成できるように、設定を削除して再作成することをお勧めします。詳細については、「[2025 年 7 月 15 日より前に作成されたメタデータ設定でインベントリテーブルを有効にする](metadata-tables-create-configuration.md#metadata-tables-migration)」を参照してください。
## メタデータテーブルにクエリを実行できない
メタデータテーブルをクエリできない場合は、以下を確認してください。
+ Amazon Athena または Amazon Redshift を使用してメタデータテーブルをクエリする場合は、メタデータテーブルの名前空間名を引用符 (`"`) またはバックティック (```) で囲む必要があります。囲まない場合、クエリが機能しない可能性があります。
+ Amazon EMR または他のサードパーティーエンジンで Apache Spark を使用してメタデータテーブルをクエリする場合は、Amazon S3 Tables Iceberg REST エンドポイントを使用することをお勧めします。このエンドポイントを使用しないと、クエリが正常に実行されない可能性があります。詳細については、「[Amazon S3 Tables Iceberg REST エンドポイントを使用したテーブルへのアクセス](s3-tables-integrating-open-source.md)」を参照してください。
+ メタデータテーブルをクエリするための適切な AWS Identity and Access Management (IAM) アクセス許可があることを確認してください。詳細については、「[メタデータテーブルをクエリするためのアクセス許可](metadata-tables-bucket-query-permissions.md)」を参照してください。
+ Amazon Athena を使用していて、クエリを実行しようとするとエラーが表示される場合は、次の操作を行います。
+ Athena でクエリを実行しようとしたときに、クエリを実行するためのアクセス許可が不足しており、プリンシパルは指定されたリソースに対する権限を持っていないという内容のエラーが表示される場合は、テーブルに対する必要な Lake Formation 許可が付与されている必要があります。詳細については、「[テーブルまたはデータベースに対する Lake Formation アクセス許可の付与](grant-permissions-tables.md#grant-lf-table)」を参照してください。
+ クエリを実行しようとしたときに、Iceberg はリクエストされたリソースにアクセスできないという内容のエラーが表示される場合は、AWS Lake Formation コンソールに移動し、作成したテーブルバケットカタログとデータベース (名前空間) に対するアクセス許可が自分に付与されていることを確認してください。これらのアクセス許可を付与するときは、テーブルを指定しないでください。詳細については、「[テーブルまたはデータベースに対する Lake Formation アクセス許可の付与](grant-permissions-tables.md#grant-lf-table)」を参照してください。
## 特定の S3 Metadata AWS CLI コマンドと API オペレーションを使用しようとすると、405 エラーが表示される
V1 `GetBucketMetadataTableConfiguration` API オペレーションを呼び出すか、V2 メタデータテーブル設定に対して `get-bucket-metadata-table-configuration` AWS Command Line Interface (AWS CLI) コマンドを使用すると、HTTP `405 Method Not Allowed` エラーが発生します。同様に、V1 `DeleteBucketMetadataTableConfiguration` API オペレーションを呼び出すか、`delete-bucket-metadata-table-configuration` AWS CLI コマンドを使用すると、405 エラーも発生します。
V1 または V2 メタデータテーブル設定に対して、V2 `GetBucketMetadataConfiguration` API オペレーション、または `get-bucket-metadata-configuration` AWS CLI コマンドを使用できます。同様に、V1 または V2 メタデータテーブル設定に対して V2 `DeleteBucketMetadataConfiguration` API オペレーションまたは `delete-bucket-metadata-configuration` AWS CLI コマンドを使用できます。
V1 API オペレーションの代わりに新しい V2 API オペレーション (`CreateBucketMetadataConfiguration`、`GetBucketMetadataConfiguraion`、および `DeleteBucketMetadataConfiguration`) を使用するようにプロセスを更新することをお勧めします。S3 Metadata の V1 から V2 への移行の詳細については、「[2025 年 7 月 15 日より前に作成されたメタデータ設定でインベントリテーブルを有効にする](metadata-tables-create-configuration.md#metadata-tables-migration)」を参照してください。
設定が V1 か V2 かを判断するには、`GetBucketMetadataConfiguration` API レスポンスの次の属性を確認します。AWS マネージドバケットタイプ (`"aws"`) は V2 設定を示し、カスタマーマネージドバケットタイプ (`"customer"`) は V1 設定を示します。
```
"MetadataTableConfigurationResult": {
"TableBucketType": ["aws" | "customer"]
```
詳細については、「[メタデータテーブル設定の表示](metadata-tables-view-configuration.md)」を参照してください。