Amazon S3 のよくある質問

ベクターバケットは、ベクターの保存とクエリを目的として構築されています。ベクターバケット内では、S3 オブジェクト API ではなく、専用のベクター API を使用してベクターデータを書き込み、セマンティックな意味と類似性に基づいてクエリを行います。Amazon S3 の既存のアクセス制御メカニズム (バケットや IAM ポリシーを含む) を使用して、ベクターデータへのアクセスを制御できます。ベクターバケットへの書き込みはすべて一貫性が高いため、最近追加されたベクターにすぐにアクセスできます。時間の経過とともにベクターの書き込み、更新、削除を行うと、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 ベクターバケットは格納されているベクターデータを自動的に最適化して、データセットの規模が拡大したり進化したりしても、最適なコストパフォーマンスを実現します。

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

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

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

GetVectors API を使用すると、ベクターキーでベクターと関連メタデータを検索して返すことができます。

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

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

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

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

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

S3 Vectorsでは、ストレージと該当する書き込み/読み取りリクエスト（たとえば、ベクターの挿入やベクターインデックスのベクターへのクエリ操作の実行など）に対して料金が発生します。料金の詳細については、 S3 の料金表ページをご覧ください。

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

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

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

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

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

S3 アクセスポイントを使用すると、S3 API を使用して Amazon FSx for OpenZFS のファイルデータにアクセスできます。データを S3 に移動する必要はありません。OpenZFSファイルシステム用のFSxに接続されたS3アクセスポイントは、S3バケットに接続されたS3アクセスポイントの仕組みと同様に機能します。データは引き続きFSx for OpenZFSファイルシステムまたはS3バケットのいずれかに保存されますが、S3経由のデータアクセスはアクセスポリシーによって制御されます。たとえば、S3アクセスポイントをFSx for OpenZFSファイルシステムに接続すると、顧客はそのアクセスポイントを、S3と連携するジェネレーティブAI、機械学習、分析サービスおよびアプリケーションで使用して、FSx for OpenZFSデータにアクセスできます。

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

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

SQL を使用して S3 オブジェクトに関する情報をクエリし、ジェネレーティブ AI、分析、その他のユースケースで特定のデータセットをすばやく特定したい場合は、Amazon S3 メタデータを使用する必要があります。S3 メタデータはほぼリアルタイムでメタデータを最新の状態に保つため、任意の ICEBERG 互換クライアントを使用して SQL クエリを実行し、オブジェクトメタデータでオブジェクトを検索できます。たとえば、SQL クエリを使用して、特定のフィルターに一致するオブジェクトのリストを返すことができます。たとえば、過去 30 日間に任意のバケットに追加されたオブジェクトなどです。

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

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

S3 メタデータテーブルは、 aws-s3 と呼ばれる AWS アカウントの AWS 管理テーブルバケットに保存されます。テーブルは読み取り専用になり、メタデータの書き込み、更新、削除の権限を持つのは S3 だけです。 

S3 メタデータは、アカウントの 2 つの管理テーブル、ジャーナルテーブルとライブインベントリテーブルにメタデータを格納します。 

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

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

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

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

S3 テーブルは、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 上のデータが最適化され、クエリのパフォーマンスが改善することができます。

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

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

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