Amazon S3 に関するよくある質問

ベクトルバケットは、ベクトルの保存とクエリのために特別に構築されています。ベクトルバケット内では、S3 オブジェクト API ではなく、専用のベクトル API を使用してベクトルデータを書き込み、意味論的意味と類似性に基づいてクエリします。バケットや IAM ポリシーなど、Amazon S3 の既存のアクセスコントロールメカニズムを使用して、ベクトルデータへのアクセスを制御できます。ベクトルバケットへのすべての書き込みは強力な一貫性を備えているため、最後に追加されたベクトルにすぐにアクセスできます。時間が経過する中で、ベクトルの書き込み、更新、削除が行われると、S3 ベクトルバケットは、データセットがスケールおよび進化しても、保存されているベクトルデータを自動的に最適化し、最適な料金パフォーマンスを実現します。

バケットは Amazon S3 に保存されているオブジェクト、テーブルのコンテナであり、バケットにはオブジェクトをいくつでも保存できます。汎用バケットは元の S3 バケットタイプであり、1 つの汎用バケットには、S3 Express One Zone を除くすべてのストレージクラスに保存されたオブジェクトを含めることができます。ほとんどのユースケースとアクセスパターンに推奨されます。S3 ディレクトリバケットでは、S3 Express One Zone ストレージクラスに保存されたオブジェクトのみを許可します。これにより、1 つのアベイラビリティーゾーン内でのデータ処理が高速になります。低レイテンシーのユースケースで推奨されます。 各 S3 ディレクトリバケットは、バケット内のディレクトリ数にかかわらず、1 秒あたり最大 200 万トランザクション (TPS) をサポートできます。 S3 テーブルバケットは、日々の購入取引、ストリーミングセンサーデータ、広告インプレッションなどの表形式のデータを S3 に保存するために設計されています。テーブルバケットを使用する場合、データはアイスバーグテーブルとして S3 に保存され、行レベルのトランザクション、クエリ可能なテーブルスナップショットなどの分析機能を使用してそのデータを操作できます。これらはすべて S3 によって管理されます。さらに、テーブルバケットは継続的にテーブルメンテナンスを実行し、データレイクがスケールしたり、進化したりしても、クエリの効率を継続的かつ自動的に最適化します。 S3 ベクトルバケットは、ベクトルの保存とクエリのために特別に構築されています。ベクトルバケット内では、専用のベクトル API を使用してベクトルデータを書き込み、意味論的意味と類似性に基づいてクエリします。バケットや IAM ポリシーなど、Amazon S3 の既存のアクセスコントロールメカニズムを使用して、ベクトルデータへのアクセスを制御できます。時間が経過する中で、ベクトルの書き込み、更新、削除が行われると、S3 ベクトルバケットは、データセットがスケールおよび進化しても、保存されているベクトルデータを自動的に最適化し、最適な料金パフォーマンスを実現します。

S3 Tables は、構造化データを Apache Parquet、Avro、または ORC 形式で保存するための専用の S3 ストレージを提供します。テーブルバケット内では、テーブルをファーストクラスのリソースとして直接 S3 に作成できます。これらのテーブルは、ID ベースまたはリソースベースのポリシーで定義されたテーブルレベルの許可で保護でき、Apache Iceberg 標準をサポートするアプリケーションまたはツールによってアクセスできます。テーブルバケットにテーブルを作成すると、S3 内の基盤となるデータは Parquet、Avro、または ORC ファイルとして保存されます。次に、S3 は Apache Iceberg 標準を使用して、そのデータをアプリケーションでクエリできるようにするために必要なメタデータを保存します。S3 Tables には、テーブルバケット内のテーブルの Iceberg メタデータを操作および更新するためにクエリエンジンによって使用されるクライアントライブラリが含まれています。このライブラリは、テーブルオペレーション用の更新された S3 API と連携して、複数のクライアントが安全に、データをテーブルに読み書きできるようにします。時間が経過する中で、S3 は、オブジェクトを書き換える (あるいは「圧縮」する) ことによって、基盤となる 、Parquet、Avro、または ORC データを自動的に最適化します。圧縮により、S3 上のデータが最適化され、クエリのパフォーマンスが改善することができます。

S3 Tables は、S3 外部のインフラストラクチャを立ち上げなくても、ほんの数ステップで使い始めることができます。まず、S3 コンソールでテーブルバケットを作成します。コンソールを通じて最初のテーブルバケットを作成すると、AWS 分析サービスとの統合が自動的に行われ、S3 はアカウントとリージョン内のすべてのテーブルバケットとテーブルを AWS Glue データカタログに自動的に入力できるようになります。この後、Amazon Athena、EMR、Redshift などの AWS クエリエンジンから S3 Tables にアクセスできるようになります。次に、S3 コンソールから Amazon Athena を使用してテーブルを作成するためにクリックできます。Athena にアクセスすると、新しいテーブルへの入力とクエリをすぐに開始できます。

あるいは、AWS Glue データカタログを通じて Iceberg REST カタログエンドポイントを使用して S3 Tables にアクセスすることもできます。これにより、すべてのテーブルリソースを含むデータ資産全体を検出できます。また、個々のテーブルバケットエンドポイントに直接接続して、そのバケット内のすべての S3 Tables リソースを検出することもできます。これにより、Apache Iceberg REST カタログ仕様をサポートする任意のアプリケーションまたはクエリエンジンで S3 Tables を使用できるようになります。

Iceberg テーブルを汎用 Amazon S3 バケットに保存する場合と比較して、クエリパフォーマンスは最大 3 倍速く、1 秒あたりのトランザクション数 (TPS) は最大 10 倍高くなることが期待できます。これは、テーブルバケットがテーブルの基になる Parquet、Avro、または ORC データを自動的に圧縮してクエリのパフォーマンスを最適化し、専用ストレージがデフォルトで最大 10 倍の TPS をサポートするためです。

テーブルバケットでは、リソースポリシーをバケット全体または個々のテーブルに適用できます。テーブルバケットポリシーは、PutTablePolicy と PutTableBucketPolicy API を使用して適用できます。テーブルレベルのポリシーを使用すると、個々の Parquet、Avro、または ORC ファイルの物理的な場所を理解しなくても、関連する論理テーブルに基づいてテーブルバケット内のテーブルに対する許可を管理できます。さらに、S3 ブロックパブリックアクセスは常にテーブルバケットに適用されます。

テーブルバケットは、Parquet、Avro、または ORC データを含む Apache Iceberg テーブル形式をサポートしています。

Amazon S3 の外部にインフラストラクチャをセットアップすることなく、4 つのシンプルなステップで S3 Vectors の使用を開始できます。まず、CreateVectorBucket API または S3 コンソールを通じて、特定の AWS リージョンにベクトルバケットを作成します。次に、ベクトルデータをベクトルバケットに整理するために、CreateIndex API または S3 コンソールを使用してベクトルインデックスを作成します。ベクトルインデックスを作成するときは、距離メトリクス (コサインまたはユークリッド) とベクトルの次元数 (最大 4092) を指定します。最も正確な結果を得るには、埋め込みモデルによって推奨される距離メトリクスを選択してください。3 番目に、PutVectors API を使用してベクトルインデックスにベクトルデータを追加します。オプションで、各ベクトルに key-value ペアとしてメタデータをアタッチし、クエリをフィルタリングできます。4 番目に、QueryVectors API を使用して類似性クエリを実行し、検索するベクトルと、最も類似する結果のうち、返される数を指定します。

ベクトルインデックスは、S3 コンソールまたは CreateIndex API を使用して作成できます。インデックス作成時に、ベクトルバケット、インデックス、距離メトリクス、ディメンションを指定し、さらに、類似性クエリ中にフィルタリングから除外するメタデータフィールドのリストをオプションで指定します。例えば、ベクトルに関連付けられたデータを純粋に参照用に保存する場合は、これらをフィルタリング不可のメタデータフィールドとして指定できます。作成時に、各インデックスには、一意の Amazon リソースネーム (ARN) が割り当てられます。その後、書き込みまたはクエリリクエストを実行する際、ベクトルバケット内のベクトルインデックスにそのリクエストを送信します。

PutVectors API を使用して、ベクトルインデックスにベクトルを追加できます。各ベクトルはキーで構成され、このキーによってベクトルインデックス内の各ベクトルが一意に識別されます (例: プログラムを使用して UUID を生成できます)。書き込みスループットを最大化するには、大きなバッチ (最大リクエストサイズまで) でベクトルを挿入することをお勧めします。さらに、メタデータ (例: 年、著者、ジャンル、場所) を key-value ペアとして各ベクトルにアタッチできます。メタデータを含めると、ベクトルインデックスの作成時にフィルタリング不可のメタデータとして指定しない限り、デフォルトではすべてのフィールドを類似性クエリにおけるフィルターとして使用できます。非構造化データの新しいベクトル埋め込みを生成するために、Amazon Bedrock の InvokeModel API を使用し、使用する埋め込みモデルのモデル ID を指定できます。

GetVectors API でベクトルキーを使用して、ベクトルとそれに関連付けられたメタデータを検索して返すことができます。

QueryVectors API を使用して類似性クエリを実行し、クエリベクトル、返される関連結果の数 (上位 k 個の近傍)、インデックス ARN を指定します。クエリベクトルを生成する際は、ベクトルインデックスに保存される初期ベクトルの生成に使用したのと同じ埋め込みモデルを使用すべきです。例えば、Amazon Bedrock で Amazon Titan Text Embeddings v2 を使用してドキュメントの埋め込みを生成する場合は、同じモデルを使用して質問をベクトルに変換することをお勧めします。さらに、クエリでメタデータフィルターを使用して、フィルターに一致するベクトルを検索できます。類似性クエリを実行すると、デフォルトではベクトルキーが返されます。オプションで、距離とメタデータをレスポンスに含めることができます。

S3 Vectors は、耐久性と可用性に優れたベクトルストレージを提供します。S3 Vectors に書き込まれたデータは、イレブンナインのデータ耐久性を実現するよう設計された S3 に保存されます。S3 Vectorsは 99.99% の可用性と 99.9% の可用性SLAを実現するように設計されています。

S3 Vectors は、1 秒未満のクエリレイテンシー時間を実現します。Amazon S3 の伸縮自在なスループットを使用して、数百万のベクトルの検索を処理し、頻度の低いクエリワークロードに最適です。

ベクトル埋め込みについて類似性クエリを実行する場合、埋め込みモデル、ベクトルデータセットのサイズ (ベクトルの数と次元)、クエリの分布など、いくつかの要因が平均リコールに影響を及ぼす可能性があります。S3 Vectors は、ほとんどのデータセットで 90% を超える平均リコールを実現します。平均リコールはクエリ結果の質を測定します。90% は、インデックスに保存されている、クエリベクトルに最も近いグラウンドトゥルースベクトルの 90% がレスポンスに含まれていることを意味します。ただし、実際のパフォーマンスは具体的なユースケースによって異なる場合があるため、代表的なデータとクエリを使用して独自のテストを実施し、S3 ベクトルインデックスがリコール要件を満たしていることを検証することをお勧めします。

ListVectors API を使用すると、ベクトルインデックス内のベクトルのリストを確認できます。この API は、一度に最大 1,000 個のベクトルを返します。レスポンスが切り詰められている場合は、そのインジケーターも表示されます。レスポンスには、最終変更日、ベクトルキー、ベクトルデータ、メタデータが含まれます。また、ListVectors API を使用すると、指定したベクトルインデックスからベクトルデータを簡単にエクスポートできます。ListVectors オペレーションは強力な一貫性を備えています。そのため、書き込み後、変更が反映されたベクトルをすぐにリスト表示できます。

S3 Vectors では、ストレージと、該当する書き込みおよび読み取りリクエスト (例: ベクトルの挿入、ベクトルインデックス内のベクトルに対するクエリオペレーションの実行) についての料金をお支払いいただきます。料金の詳細については、S3 の料金ページをご覧ください。

はい。Bedrock コンソールまたは API を通じて Bedrock ナレッジベースを作成する際に、既存の S3 Vectors インデックスをベクトルストアとして設定することで、RAG ユースケースのベクトルストレージコストを削減できます。Bedrock にベクトルインデックスの作成と管理を任せたい場合は、Bedrock コンソールのクイック作成ワークフローを使用してください。さらに、Amazon SageMaker Unified Studio で、新しい S3 ベクトルインデックスを RAG ワークフローのベクトルストアとして設定することもできます。

はい。S3 Vectors を Amazon OpenSearch Service で使用するには 2 つの方法があります。1 つ目の方法として、S3 をご利用のお客様は、S3 または OpenSearch コンソールのいずれかを使用して、新しいサーバーレスコレクションとして、すべてのベクトルを S3 ベクトルインデックスから OpenSearch Serverless にエクスポートできます。S3 Vectors を使用してネイティブに構築する場合、リアルタイムクエリが必要なワークロードのために OpenSearch Serverless を選択的に使用できるという恩恵を享受できます。2 つ目の方法として、マネージド OpenSearch をご利用のお客様は、1 秒未満のレイテンシーでクエリ可能なベクトルデータのエンジンとして S3 Vectors を選択できるようになりました。その後、OpenSearch は自動的に S3 Vectors をベクトルの基盤エンジンとして使用し、OpenSearch API を使用してベクトルデータを更新および検索できます。アプリケーションに変更を加えることなく、S3 Vectors のコストメリットを享受できます。

Amazon S3 Access Points は、S3 と連動するアプリケーションまたは AWS サービスのデータアクセス管理を簡素化するエンドポイントです。S3 Access Points は、S3 バケットおよび Amazon FSx for OpenZFS ファイルシステムで動作します。各アプリケーションまたはユーザーに合わせてカスタマイズされた名前と許可を持つアクセスポイントを作成することで、さまざまなアプリケーションまたはユーザーがデータにアクセスする方法を制御および簡素化できます。

S3 バケットで S3 Access Points を使用すると、作成、読み取り、追跡、監査が必要な何百もの異なる許可ルールを含む単一の複雑なバケットポリシーを管理する必要がなくなります。代わりに、バケットごとに数百のアクセスポイントを作成し、それぞれがバケットへのカスタマイズされたパスを提供し、アクセスポイントを介して行われるすべてのリクエストに対して特定の許可とネットワーク制御を適用する独自のホスト名とアクセスポリシーを設定できます。

FSx for OpenZFS で S3 Access Points を使用すると、データが S3 に存在しているかのように、S3 API を使用して FSx データにアクセスできます。この機能により、FSx for OpenZFS 内のファイルデータは、FSx for OpenZFS ファイルシステムに保存したまま、S3 と連携するさまざまな人工知能、機械学習、分析のサービスおよびアプリケーションで使用できるようになります。

S3 Access Points を使用すると、データを S3 に移動することなく、S3 API を使用して Amazon FSx for OpenZFS のファイルデータにアクセスできます。FSx for OpenZFS ファイルシステムにアタッチされた S3 Access Points は、S3 バケットにアタッチされた S3 Access Points と同様に機能し、アクセスポリシーによってアクセスが制御された S3 経由のデータアクセスを提供します。データは引き続き FSx for OpenZFS ファイルシステムまたは S3 バケットのいずれかに保存されます。例えば、S3 Access Points を FSx for OpenZFS ファイルシステムにアタッチすると、お客様は、S3 と連携する生成 AI、機械学習、分析サービス、およびアプリケーションでそのアクセスポイントを使用して、FSx for OpenZFS データにアクセスできます。

ディレクトリバケットを作成した後、インポートオプションを使用して S3 コンソール経由で同じ AWS リージョン内のデータを S3 Express One Zone ストレージクラスにインポートできます。インポートでは、コピーするオブジェクトをすべて個別に指定しなくても、データをインポートするプレフィックスまたはバケットを選択できるため、S3 ディレクトリバケットへのデータのコピーが簡単になります。S3 バッチオペレーションは、選択したプレフィックスバケットまたは汎用バケットにオブジェクトをコピーします。S3 バッチオペレーションジョブの詳細ページからインポートコピージョブの進行状況を監視できます。

3 か月以上リクエストアクティビティがない S3 ディレクトリバケットは、非アクティブ状態に移行します。非アクティブな状態では、ディレクトリバケットは一時的に読み取りや書き込みができなくなります。非アクティブなバケットには、すべてのストレージ、オブジェクトメタデータ、バケットメタデータが保持されます。非アクティブなバケットには既存のストレージ料金が適用されます。非アクティブなバケットへのアクセスリクエストにより、バケットは通常数分以内にアクティブな状態に移行します。この移行期間中、読み取りと書き込みを行うと 503 SlowDown エラーコードが返されます。

SQL を使用して S3 オブジェクトに関する情報をクエリし、生成 AI、分析、その他のユースケースで特定のデータセットを迅速に特定したい場合は、Amazon S3 Metadata を使用すべきです。S3 Metadata はメタデータをほぼリアルタイムで最新の状態に維持するため、Iceberg 互換クライアントを使用して SQL クエリを実行し、オブジェクトのメタデータでオブジェクトを検索できます。例えば、SQL クエリを使用して、バケット全体で過去 30 日間に追加されたオブジェクトなど、特定のフィルターに一致するオブジェクトのリストを返すことができます。

S3 Metadata は、バケットにアップロードされたオブジェクトに関する追加情報を提供するメタデータを自動生成し、そのメタデータを読み取り専用テーブルでクエリ可能にするように設計されています。これらのメタデータテーブルは、Apache Iceberg 上に構築された Amazon S3 Tables に保存され、S3 内で表形式データを保存およびクエリするための管理された方法を提供します。S3 Metadata は、オブジェクトサイズなどのシステムレベルのメタデータ、オブジェクトのアップロード中のタグやユーザー定義メタデータなどのカスタムメタデータ、リクエストを送信した IP アドレスなどのイベントメタデータを作成および維持します。バケット内のデータが変更されると、S3 Metadata は、ほぼリアルタイムで更新され、最新の変更が反映されます。その後、Amazon Athena、Amazon QuickSight、Apache Spark などのさまざまな AWS 分析サービスやオープンソースツール (Iceberg 互換) を使用してメタデータテーブルをクエリできます。

S3 コンソールで数回クリックするだけで S3 Metadata を使い始めることができます。S3 Metadata を有効にする汎用 S3 バケットを選択するだけで、S3 はバケット内のデータを分析し、すべてのオブジェクトのメタデータを含むフルマネージド Apache Iceberg テーブルを構築します。Apache Iceberg をサポートする任意のクエリエンジンまたはツールを使用して、数分以内にメタデータのクエリを開始できます。

S3 Metadata テーブルは、AWS アカウントの AWS マネージドテーブルバケット (aws-s3) に保存されます。テーブルは読み取り専用であり、メタデータの書き込み、更新、削除の許可は S3 にのみ付与されます。 

S3 Metadata は、アカウント内の 2 つのマネージドテーブル (ジャーナルテーブルとライブインベントリテーブル) にメタデータを保存します。 

S3 Metadata ジャーナルテーブルは、バケット内で行われた変更のビューを提供します。汎用 S3 バケットにオブジェクトが追加、更新、削除されると、対応する変更がジャーナルテーブルにほぼリアルタイムで反映されます。ジャーナルテーブルは、アプリケーションの動作を理解し、データセットに加えられた変更を特定するのに役立ちます。例えば、ジャーナルテーブルについて SQL クエリを記述して、過去 30 日間に追加されたオブジェクト、アクティブなリクエスタによって追加されたオブジェクト、過去 1 週間にメタデータが変更されたオブジェクトなど、フィルターに一致する S3 オブジェクトを見つけることができます。

S3 Metadata ライブインベントリテーブルには、バケット内のすべてのオブジェクトの完全なリストが含まれます。ライブインベントリテーブルは 1 時間ごとに更新され、S3 がオブジェクトについて認識しているすべての情報が含まれます。ライブインベントリテーブルは、オブジェクトメタデータで生成された特性に基づいて、バケット内のデータセットを検出または識別するのに役立ちます。例えば、ライブインベントリテーブルを使用して、機械学習用のトレーニングデータセットを特定したり、ストレージコストの最適化演習で使用したり、ガバナンスコントロールを強制適用するのに役立てたりできます。

バケットに新しいオブジェクトを追加すると、数分以内にジャーナルテーブルにエントリが表示され、次の 1 時間ごとの更新時にライブインベントリテーブルにエントリが表示されます。既存のバケットで S3 Metadata を有効にすると、S3 は自動的にバックフィルオペレーションを開始し、既存のすべてのオブジェクトについてのメタデータを生成します。このバックフィルは通常数分で完了しますが、既存のデータセットに数百万または数十億の S3 オブジェクトが含まれている場合は、数時間かかることがあります。

S3 インベントリレポートは、Amazon S3 同期リスト API の定期的な代替を提供します。S3 インベントリを設定することで、S3 バケットまたはプレフィックスについて、オブジェクトとそれに対応するメタデータの CSV ファイルまたは ORC ファイルを、日単位または週単位で出力できます。S3 インベントリを使用すれば、ビジネスのワークフローやビッグデータのジョブを簡素化してスピードアップできます。S3 インベントリを使用してオブジェクトの暗号化やレプリケーションのステータスを検証することで、ビジネス、コンプライアンス、規制のニーズに応えることもできます。 詳細については、Amazon S3 インベントリのユーザーガイドをご覧ください。

S3 Tables は、構造化データを Apache Parquet、Avro、または ORC 形式で保存するための専用の S3 ストレージを提供します。テーブルバケット内では、テーブルをファーストクラスのリソースとして直接 S3 に作成できます。これらのテーブルは、ID ベースまたはリソースベースのポリシーで定義されたテーブルレベルの許可で保護でき、Apache Iceberg 標準をサポートするアプリケーションまたはツールによってアクセスできます。テーブルバケットにテーブルを作成すると、S3 内の基盤となるデータは Parquet、Avro、または ORC ファイルとして保存されます。次に、S3 は Apache Iceberg 標準を使用して、そのデータをアプリケーションでクエリできるようにするために必要なメタデータを保存します。S3 Tables には、テーブルバケット内のテーブルの Iceberg メタデータを操作および更新するためにクエリエンジンによって使用されるクライアントライブラリが含まれています。このライブラリは、テーブルオペレーション用の更新された S3 API と連携して、複数のクライアントが安全に、データをテーブルに読み書きできるようにします。時間が経過する中で、S3 は、オブジェクトを書き換える (あるいは「圧縮」する) ことによって、基盤となる 、Parquet、Avro、または ORC データを自動的に最適化します。圧縮により、S3 上のデータが最適化され、クエリのパフォーマンスが改善することができます。

S3 Tables は、S3 外部のインフラストラクチャを立ち上げなくても、ほんの数ステップで使い始めることができます。まず、S3 コンソールでテーブルバケットを作成します。コンソールを通じて最初のテーブルバケットを作成すると、AWS 分析サービスとの統合が自動的に行われ、S3 はアカウントとリージョン内のすべてのテーブルバケットとテーブルを AWS Glue データカタログに自動的に入力できるようになります。この後、Amazon Athena、EMR、Redshift などの AWS クエリエンジンから S3 Tables にアクセスできるようになります。次に、S3 コンソールから Amazon Athena を使用してテーブルを作成するためにクリックできます。Athena にアクセスすると、新しいテーブルへの入力とクエリをすぐに開始できます。

あるいは、AWS Glue データカタログを通じて Iceberg REST カタログエンドポイントを使用して S3 Tables にアクセスすることもできます。これにより、すべてのテーブルリソースを含むデータ資産全体を検出できます。また、個々のテーブルバケットエンドポイントに直接接続して、そのバケット内のすべての S3 Tables リソースを検出することもできます。これにより、Apache Iceberg REST カタログ仕様をサポートする任意のアプリケーションまたはクエリエンジンで S3 Tables を使用できるようになります。

Iceberg テーブルを汎用 Amazon S3 バケットに保存する場合と比較して、クエリパフォーマンスは最大 3 倍速く、1 秒あたりのトランザクション数 (TPS) は最大 10 倍高くなることが期待できます。これは、テーブルバケットがテーブルの基になる Parquet、Avro、または ORC データを自動的に圧縮してクエリのパフォーマンスを最適化し、専用ストレージがデフォルトで最大 10 倍の TPS をサポートするためです。

テーブルバケットでは、リソースポリシーをバケット全体または個々のテーブルに適用できます。テーブルバケットポリシーは、PutTablePolicy と PutTableBucketPolicy API を使用して適用できます。テーブルレベルのポリシーを使用すると、個々の Parquet、Avro、または ORC ファイルの物理的な場所を理解しなくても、関連する論理テーブルに基づいてテーブルバケット内のテーブルに対する許可を管理できます。さらに、S3 ブロックパブリックアクセスは常にテーブルバケットに適用されます。

テーブルバケットは、Parquet、Avro、または ORC データを含む Apache Iceberg テーブル形式をサポートしています。