Set Up Amazon S3 Vectors and S3 Metadata for RAG Through the AWS Console

Series: Financial Service (19 articles)

1
AWS Lambda MicroVMs and the End of Repeated Application Cold Initialization
…
12
Set Up Amazon S3 Vectors and S3 Metadata for RAG Through the AWS Console This article
13
The Human Risk Conversation Layer: Building Real-Time Voice Agents on Amazon Bedrock AgentCore Without Turning the Trading Desk into a Surveillance System [ part 1 ]

Martin

Dev @ Vertex Macro

Published Oct 2, 2026

Last modified Oct 2, 2026

Set Up Amazon S3 Vectors and S3 Metadata for RAG Through the AWS Console

The cleanest console-based implementation uses four connected components:

A general-purpose Amazon S3 bucket for source documents
Amazon S3 Metadata for inventory, lineage, annotations, and governance
An S3 vector bucket and vector index for embeddings
Amazon Bedrock Knowledge Bases for document ingestion, chunking, embedding, retrieval, and answer generation

Amazon Bedrock can automatically read documents from the general-purpose S3 bucket, split them into chunks, generate embeddings, and write those embeddings into S3 Vectors. S3 Metadata remains the governance and discovery layer around the original source documents.

Console labels may vary slightly by AWS Region and account rollout. Keep the S3 bucket, S3 vector bucket, Amazon Bedrock Knowledge Base, embedding model, and generation model in the same supported AWS Region.

Target Architecture

Users and internal applications submit requests to an Amazon Bedrock Knowledge Base. The Knowledge Base uses an approved embedding model to convert each request into a query vector and sends that vector to Amazon S3 Vectors. S3 Vectors stores the vector bucket, vector index, document-chunk embeddings, and compact retrieval metadata used for semantic similarity search and metadata filtering.

The Knowledge Base also connects to a general-purpose Amazon S3 bucket containing the original source documents. This bucket holds the authoritative documents, user-defined object metadata, object tags, document metadata sidecar files, and optional S3 annotations. Amazon S3 Metadata continuously captures information about these source objects and represents it through managed Apache Iceberg tables.

The S3 Metadata configuration can include a required journal table, an optional live inventory table, and an optional annotation table. Amazon Athena can query these tables for discovery, reconciliation, audit, lineage, and governance controls. The online RAG path uses Amazon Bedrock Knowledge Bases and S3 Vectors for retrieval, while the S3 Metadata tables provide the analytical control plane around the source corpus.

The end-to-end flow is therefore: users or internal applications send a request to an Amazon Bedrock Knowledge Base; the Knowledge Base generates the query embedding; S3 Vectors finds semantically similar, policy-filtered chunks; the Knowledge Base retrieves the corresponding approved content from the source corpus; a Bedrock generation model produces a grounded answer with citations; and S3 Metadata plus Athena provide ongoing inventory, lineage, change tracking, annotation discovery, and audit visibility.

Amazon S3 Vectors is purpose-built for vector storage and similarity queries. It supports vector buckets, vector indexes, vector-level metadata, IAM policies, and strongly consistent writes. Amazon S3 Metadata creates read-only, fully managed Apache Iceberg tables covering object state and changes in a general-purpose S3 bucket.

Step 1: Select the AWS Region

Open the AWS Management Console and select a Region that supports all required services:

Amazon S3 Vectors
Amazon S3 Metadata
Amazon Bedrock Knowledge Bases
The selected Amazon Bedrock embedding model
The selected Amazon Bedrock generation model
Amazon Athena
AWS KMS, if customer-managed encryption keys are required

The general-purpose S3 data-source bucket must be in the same Region as the Amazon Bedrock Knowledge Base.

For an enterprise deployment, use separate AWS accounts for development, validation, production, and customer-facing content. Do not combine internal trading history and customer-publishable content in the same Knowledge Base or vector index.

Step 2: Enable Amazon Bedrock Model Access

Open the Amazon Bedrock console.

Navigate to the area for model access, model catalog, or foundation models, depending on the current console interface.

Enable access to:

An embedding model supported by Amazon Bedrock Knowledge Bases and S3 Vectors
A text-generation model for testing retrieval-augmented answers

The embedding model defines the vector dimension. Every vector in an S3 vector index must have exactly the dimension configured when the index is created. The embedding model used at query time must also be compatible with the one used during ingestion.

Record the following:

1
2
3
4
5
6
AWS Region

Embedding model name

Embedding model ID

Embedding dimension

Recommended distance metric

Generation model name

Do not guess the embedding dimension. Read it from the selected model's current Amazon Bedrock documentation or allow the Bedrock Knowledge Base workflow to create the S3 Vectors resources when that option is available.

Step 3: Create the Source Document Bucket

Open the Amazon S3 console.

Select General purpose buckets, then select Create bucket.

Use a name similar to:

1
fsi-rag-source-prod-<account-id>

Configure the bucket as follows:

1
2
3
4
5
6
AWS Region: Same Region as Amazon Bedrock

Object Ownership: Bucket owner enforced

Block Public Access: Enabled for every option

Bucket Versioning: Enabled

Default encryption: SSE-KMS for regulated data

Object Lock: Enable only if required by records-retention policy

Create prefixes that represent governance boundaries:

1
2
3
4
5
internal-approved/

internal-quarantine/

customer-approved/

superseded/

evaluation/

For a real financial-services environment, internal and customer-facing content should preferably use different buckets, Knowledge Bases, S3 vector buckets, encryption keys, and AWS accounts.

Amazon Bedrock Knowledge Bases currently uses general-purpose S3 buckets as S3 data sources. The console can create a service role with access to the selected bucket, but that role should be reviewed before production use.

Step 4: Upload a Small Controlled Corpus

In the source bucket, open the appropriate approved prefix, such as:

1
internal-approved/

Select Upload and add a small, controlled test collection such as:

1
2
3
4
5
trading_policy_2026.pdf

liquidity_risk_review_2025.pdf

settlement_exception_procedure.docx

historical_trade_review_1998.txt

market_structure_training.md

Start with 20 to 100 representative documents rather than the complete enterprise archive.

The initial corpus should include:

Current procedures
Superseded procedures
Historical trading studies
Approved post-trade reviews
Operational exception records
Documents from more than one period
Documents that appear similar but carry different access restrictions
At least one document the system must not retrieve

This makes the first test a governance and retrieval-quality exercise rather than a demonstration using only easy documents.

Step 5: Add Document Metadata for Bedrock Filtering

Amazon Bedrock supports document metadata for S3 data sources. A common approach is to place a metadata sidecar file beside each source document.

For example:

1
2
internal-approved/liquidity_risk_review_2025.pdf

internal-approved/liquidity_risk_review_2025.pdf.metadata.json

A representative metadata file could contain:

1
2
3
4
5
6
7
8
9
10
11
12
13
{

  "metadataAttributes": {

    "legal_entity": "LE-HK-001",

    "desk": "macro",

    "jurisdiction": "HK",

    "classification": "confidential",

    "publication_state": "approved_internal",

    "document_type": "risk_review",

    "effective_from": "2025-01-01",

    "effective_to": "9999-12-31",

    "language": "en"

  }

}

Use controlled values rather than descriptive free text. Fields such as classification, legal_entity, publication_state, and jurisdiction may later become retrieval filters.

Do not use model-generated metadata as the authoritative entitlement source. Security-critical values should be produced or validated by deterministic enterprise controls.

Step 6: Enable S3 Metadata

Open the source bucket in the Amazon S3 console.

Locate the Metadata, S3 Metadata, or Metadata tables section.

Select Create metadata table configuration.

For each general-purpose bucket, S3 Metadata can maintain up to three complementary managed tables:

Journal table, which is required and records object and metadata change events occurring after configuration
Live inventory table, which provides the latest inventory of objects and versions
Annotation table, which makes object annotations discoverable

The journal table records changes in near real time. Enabling the live inventory table triggers a backfill of the objects already present in the bucket.

Configure the metadata tables as follows:

1
2
3
4
5
6
Journal table: Enabled

Journal expiration: Based on audit-retention requirements

Live inventory table: Enabled

Annotation table: Enabled if visible and supported in the selected Region

Encryption: SSE-KMS for regulated workloads

Analytics integration: Enabled

The S3 console may create or select an S3 table bucket, namespace, managed Apache Iceberg tables, and supporting IAM role. Review the generated names and permissions.

The required permissions can include S3 Metadata actions, S3 Tables actions, AWS KMS permissions, and iam:PassRole when an annotation table configuration uses an IAM role.

Step 7: Verify the Metadata Tables

Return to the source S3 bucket and open its metadata-table configuration.

Confirm that the status of the following resources becomes active:

1
2
3
4
5
6
Journal table

Live inventory table

Annotation table, if enabled

Table bucket

Namespace

Analytics integration

Do not expect every table to be populated immediately.

The journal table primarily records events after the metadata configuration is created. The live inventory table scans existing objects during backfill. S3 continuously refreshes and optimizes the managed Iceberg tables while the configuration remains active.

Step 8: Query S3 Metadata with Amazon Athena

From the S3 Metadata configuration, select the option to open or query the table with Amazon Athena.

Alternatively:

Open the Amazon Athena console.
Select the same AWS Region.
Open the Query editor.
Select the catalog representing the S3 table bucket.
Select the namespace and metadata table.
Configure an Athena query-results location if the console requests one.

Start with a discovery query:

1
2
3
SELECT *

FROM "<catalog>"."<namespace>"."<live_inventory_table>"

LIMIT 20;

Find PDF documents:

1
2
3
4
5
6
7
8
9
SELECT

    key,

    size,

    last_modified_date,

    storage_class

FROM "<catalog>"."<namespace>"."<live_inventory_table>"

WHERE lower(key) LIKE '%.pdf'

ORDER BY last_modified_date DESC

LIMIT 100;

Inspect recent object activity:

1
2
3
4
SELECT *

FROM "<catalog>"."<namespace>"."<journal_table>"

ORDER BY event_time DESC

LIMIT 100;

Use the actual column names shown in Athena because the precise schemas can differ among journal, live inventory, and annotation tables.

S3 metadata tables are read-only managed Apache Iceberg tables. They are suited to discovery, audit, reconciliation, and batch controls. They should not be treated as the real-time authorization database for an online RAG request.

Step 9: Create the S3 Vector Bucket

You can allow Amazon Bedrock to create the vector resources during Knowledge Base setup, or create them first in Amazon S3. Creating them first provides tighter control over naming, encryption, tags, dimensions, and metadata behavior.

Open the Amazon S3 console.

In the left navigation pane, select Vector buckets.

Select Create vector bucket.

Use a name similar to:

1
fsi-rag-vectors-prod

Configure:

1
2
3
4
5
6
Encryption: SSE-KMS for production

Tags:

  environment = prod

  application = institutional-memory-rag

  data_classification = confidential

  owner = knowledge-platform

A vector bucket name must be unique within the AWS Region, contain 3 to 63 characters, and use lowercase letters, numbers, and hyphens. Its name and encryption type cannot be changed after creation. All data in vector buckets is encrypted at rest.

Step 10: Create the Vector Index

Open the newly created vector bucket and select Create vector index.

Use a name such as:

1
institutional-memory-embeddings-v1

Configure the following:

1
2
3
4
Data type: float32

Dimension: Exact dimension of the selected embedding model

Distance metric: Cosine, unless the model documentation recommends Euclidean

Encryption: Customer-managed KMS key where required

For metadata settings, designate large fields that will never be used in filters as non-filterable. Keep fields such as classification, jurisdiction, legal entity, publication state, effective date, desk, and document type filterable.

By default, vector metadata fields are filterable unless they are explicitly designated as non-filterable during index creation. Filterable metadata supports string, number, Boolean, and list values.

Choose these settings carefully. After an index is created, its name, dimension, distance metric, and non-filterable metadata keys cannot be changed. A configuration change normally requires a new vector index and re-ingestion.

If the console offers an index mode, choose the mode that performs metadata pre-filtering before similarity evaluation for permission-sensitive and highly selective filtered searches.

Step 11: Create the Amazon Bedrock Knowledge Base

Open the Amazon Bedrock console.

Navigate to Knowledge Bases.

Select Create knowledge base and choose the workflow that connects an unstructured data source to a vector store.

Enter:

1
2
3
4
5
6
Knowledge base name:

fsi-institutional-memory-rag



Description:

Authorized semantic retrieval across approved trading,

risk, operations, and institutional-history documents.

For the service role, select Create and use a new service role for an initial test. For production, review or replace the generated role with a tightly scoped IAM role.

A Knowledge Base cannot be created using the AWS account root user. Use an IAM principal or federated enterprise identity with the required permissions.

Step 12: Connect the S3 Data Source

Select Amazon S3 as the data source.

Enter or browse to the general-purpose source bucket.

Restrict the inclusion prefix to approved content:

1
internal-approved/

Do not point the Knowledge Base at the bucket root if the bucket also contains quarantined, raw, restricted, or customer-specific documents.

Configure the deletion policy deliberately:

1
2
3
4
5
DELETE:

Remove associated vector embeddings when source content is removed.



RETAIN:

Retain the embeddings when the data source is detached or deleted.

For most governed RAG systems, DELETE is safer unless record-retention requirements explicitly demand otherwise.

The source S3 bucket and Knowledge Base must be in the same Region, and the Knowledge Base service role must be able to read the selected source objects.

Step 13: Configure Chunking

Select a chunking strategy appropriate to the documents.

A conservative first configuration is:

1
2
3
Chunking strategy: Fixed-size

Maximum tokens: 500 to 800

Overlap: 10% to 20%

For long research reports or trading histories, semantic or hierarchical chunking may give better results if available in the selected workflow.

Avoid very large chunks because they reduce retrieval precision. Avoid very small chunks because they separate evidence from its qualifications and historical context.

For financial-service documents, the ideal chunk boundary often follows:

1
2
3
4
5
6
Thesis

Evidence

Challenge

Decision

Outcome

Control implication

Changing the chunking method later may require resynchronization and should be treated as a controlled retrieval-model change.

Step 14: Select the Embedding Model

Choose the same embedding model whose dimension was used to create the vector index.

If Amazon Bedrock created the vector store automatically, it should align the index configuration with the selected embedding model. If you supplied an existing vector index, confirm that:

1
2
3
4
Embedding dimension = Vector index dimension

Distance metric = Appropriate for the model

AWS Region = Same Region

Knowledge Base role = Authorized to access the vector bucket and index

Amazon Bedrock Knowledge Bases automates extraction, chunking, embedding generation, and insertion into the S3 vector index. It also manages vectors during subsequent source synchronization.

Step 15: Select S3 Vectors as the Vector Store

In the vector-database section, select:

1
Amazon S3 Vectors

Then choose either:

1
Create a new vector store

or:

1
Use an existing vector store

For an existing vector store, select:

1
2
Vector bucket: fsi-rag-vectors-prod

Vector index: institutional-memory-embeddings-v1

Complete the Knowledge Base creation.

Amazon S3 Vectors is appropriate when the application needs cost-efficient storage for a large, durable corpus and subsecond retrieval is acceptable. Amazon Bedrock handles vector operations through the Knowledge Base interface, so the application does not need to call the S3 Vectors APIs directly for normal managed RAG ingestion and retrieval.

Step 16: Synchronize the Data Source

Open the Knowledge Base.

Under Data sources, select the S3 data source and choose Sync.

Monitor the synchronization job until it reports completion.

Review:

1
2
3
4
5
6
7
Documents scanned

Documents added

Documents modified

Documents deleted

Documents failed

Warnings

Start and completion time

When the source data changes, the Knowledge Base must be synchronized again unless the application has implemented another supported ingestion mechanism.

Typical synchronization failures include:

Unsupported or encrypted document formats
Missing S3 permissions
Missing KMS permissions
Vector-index dimension mismatch
Invalid metadata sidecar files
Source bucket in a different Region
Bedrock service role unable to access the vector bucket
Documents exceeding current service quotas

Step 17: Test Retrieval Without Generation

Open the Knowledge Base test interface.

Start with retrieval-only testing where available. Use a prompt such as:

1
2
3
Find historical reviews discussing a situation in which market

liquidity disappeared faster than the desk could reduce exposure.

Return the relevant source documents and explain the matching context.

Inspect the retrieved chunks before evaluating the generated prose.

Validate:

1
2
3
4
5
6
Are the correct documents present?

Are current and superseded policies clearly distinguished?

Are citations linked to the correct source?

Are restricted documents absent?

Is the retrieved context complete enough to preserve qualifications?

Are several chunks coming from the same document unnecessarily?

Retrieval quality should be validated independently from the generation model. A fluent answer cannot compensate for retrieving the wrong evidence.

Step 18: Test Retrieval with Response Generation

Select an approved Bedrock generation model in the test interface.

Use a system instruction similar to:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Answer only from the retrieved evidence.



Cite every material statement.



Separate historical facts from current policy.



State when the available evidence is insufficient.



Do not provide executable buy, sell, timing, or position-sizing advice.



Identify both the similarities and the differences between a historical

event and the user's current situation.



Never expose content outside the user's approved legal entity,

jurisdiction, classification, publication state, and purpose.

Test at least four response classes:

1
2
3
4
A valid question with strong evidence

A valid question with conflicting evidence

A question for which the corpus has no answer

A request that should be blocked by access policy

Step 19: Apply Retrieval Filters

Use Knowledge Base retrieval filters to narrow results by document metadata.

A conceptual filter might require:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
{

  "andAll": [

    {

      "equals": {

        "key": "legal_entity",

        "value": "LE-HK-001"

      }

    },

    {

      "equals": {

        "key": "publication_state",

        "value": "approved_internal"

      }

    },

    {

      "equals": {

        "key": "classification",

        "value": "confidential"

      }

    }

  ]

}

The exact filter structure depends on the Bedrock console or API integration.

The server must construct security-sensitive filters from authenticated identity and enterprise policy. Do not trust a legal-entity, customer, tenant, or classification value supplied only by a user interface.

S3 Vectors supports metadata filtering alongside similarity retrieval. Filterable metadata is intended for categories, timestamps, status values, and other conditions used to restrict query results.

Step 20: Use S3 Metadata as the Governance Control Plane

Amazon Bedrock Knowledge Bases does not automatically turn S3 Metadata tables into its authorization engine. Treat them as complementary layers:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
S3 Vectors:

Fast semantic retrieval of document chunks.



Bedrock document metadata:

Retrieval-time filters associated with indexed content.



S3 Metadata live inventory:

Current analytical inventory of source objects and versions.



S3 Metadata journal:

Near-real-time history of object and metadata changes.



S3 Metadata annotation table:

Discovery of richer business, lineage, and governance context.



Enterprise policy service:

Authoritative online access decision.

S3 Metadata automatically captures object metadata and maintains the managed Iceberg tables, but these tables are analytical and read-only. They are useful for finding missing embeddings, superseded documents, unapproved publication states, encryption exceptions, and unexpected deletions.

Useful governance checks include:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
-- Approved documents that have not entered the expected workflow

SELECT key, last_modified_date

FROM "<catalog>"."<namespace>"."<live_inventory_table>"

WHERE key LIKE 'internal-approved/%'

  AND lower(key) NOT LIKE '%.metadata.json';



-- Recently deleted or modified source objects

SELECT *

FROM "<catalog>"."<namespace>"."<journal_table>"

WHERE event_time >= current_timestamp - INTERVAL '1' DAY

ORDER BY event_time DESC;



-- Documents in an unexpected storage or encryption state

SELECT key, storage_class, encryption_status

FROM "<catalog>"."<namespace>"."<live_inventory_table>"

WHERE key LIKE 'internal-approved/%';

Adjust these statements to the actual table schemas shown in Athena.

Step 21: Production Security Checklist

Before production release, implement the following:

Keep S3 Block Public Access enabled.
Use separate buckets and vector indexes for internal and external content.
Use SSE-KMS with separate keys for source documents and vector stores.
Restrict IAM policies to exact bucket, prefix, vector bucket, and index ARNs.
Require access through approved VPC endpoints where supported.
Enable CloudTrail management events and required data events.
Enable S3 Versioning.
Use Object Lock only where records policy requires immutable retention.
Use Macie or another approved control to detect sensitive content before indexing.
Prevent quarantined documents from entering the approved prefix.
Record the embedding model, model version, chunking strategy, source version, and synchronization job.
Test deletion, supersession, re-ingestion, and access revocation.
Record retrieved source identifiers and response citations in the application audit trail.
Red-team cross-tenant, cross-entity, restricted-research, prompt-injection, and stale-policy scenarios.

S3 Vectors access can be governed through IAM and bucket policies, while S3 Metadata configuration and query access require separate S3, S3 Tables, analytics, and potentially KMS permissions.

Recommended First Production Configuration

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
Source bucket:

fsi-rag-source-prod-<account-id>



Approved prefix:

internal-approved/



Vector bucket:

fsi-rag-vectors-prod



Vector index:

institutional-memory-embeddings-v1



Knowledge Base:

fsi-institutional-memory-rag



S3 Metadata:

Journal enabled

Live inventory enabled

Annotation table enabled

SSE-KMS enabled



Retrieval filters:

legal_entity

jurisdiction

classification

publication_state

document_type

effective_from

effective_to

policy_epoch



Initial corpus:

50 to 100 approved documents



Initial audience:

One trading desk

One operations team

Risk and compliance reviewers



External customer access:

Not connected to the internal Knowledge Base

This setup produces a managed RAG pipeline in which Amazon Bedrock performs ingestion and retrieval, S3 Vectors stores semantic embeddings, the general-purpose S3 bucket remains the system of record, and S3 Metadata supplies the audit and discovery layer needed to manage the corpus over time.

References

Amazon Web Services, "Working with S3 Vectors and vector buckets." https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-vectors.html
Amazon Web Services, "Tutorial: Getting started with S3 Vectors." https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-vectors-getting-started.html
Amazon Web Services, "Creating a vector bucket." https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-vectors-buckets-create.html
Amazon Web Services, "Creating a vector index in a vector bucket." https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-vectors-create-index.html
Amazon Web Services, "Vector indexes." https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-vectors-indexes.html
Amazon Web Services, "Metadata filtering." https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-vectors-metadata-filtering.html
Amazon Web Services, "Discovering your data with S3 Metadata tables." https://docs.aws.amazon.com/AmazonS3/latest/userguide/metadata-tables-overview.html
Amazon Web Services, "Configuring metadata tables." https://docs.aws.amazon.com/AmazonS3/latest/userguide/metadata-tables-configuring.html
Amazon Web Services, "Creating metadata table configurations." https://docs.aws.amazon.com/AmazonS3/latest/userguide/metadata-tables-create-configuration.html
Amazon Web Services, "Querying Amazon S3 tables with Athena." https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-tables-integrating-athena.html
Amazon Web Services, "Using S3 Vectors with Amazon Bedrock Knowledge Bases." https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-vectors-bedrock-kb.html
Amazon Web Services, "Connect to Amazon S3 for your knowledge base." https://docs.aws.amazon.com/bedrock/latest/userguide/s3-data-source-connector.html
Amazon Web Services, "Create a knowledge base by connecting to a data source." https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-create.html
Amazon Web Services, "Build a knowledge base with vector stores." https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-build.html

Series: Financial Service (19 articles)

1
AWS Lambda MicroVMs and the End of Repeated Application Cold Initialization
…
12
Set Up Amazon S3 Vectors and S3 Metadata for RAG Through the AWS Console This article
13
The Human Risk Conversation Layer: Building Real-Time Voice Agents on Amazon Bedrock AgentCore Without Turning the Trading Desk into a Surveillance System [ part 1 ]

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

Set Up Amazon S3 Vectors and S3 Metadata for RAG Through the AWS Console

Series: Financial Service (19 articles)

Martin

Set Up Amazon S3 Vectors and S3 Metadata for RAG Through the AWS Console

Target Architecture

Step 1: Select the AWS Region

Step 2: Enable Amazon Bedrock Model Access

Step 3: Create the Source Document Bucket

Step 4: Upload a Small Controlled Corpus

Step 5: Add Document Metadata for Bedrock Filtering

Step 6: Enable S3 Metadata

Step 7: Verify the Metadata Tables

Step 8: Query S3 Metadata with Amazon Athena

Step 9: Create the S3 Vector Bucket

Step 10: Create the Vector Index

Step 11: Create the Amazon Bedrock Knowledge Base

Step 12: Connect the S3 Data Source

Step 13: Configure Chunking

Step 14: Select the Embedding Model

Step 15: Select S3 Vectors as the Vector Store

Step 16: Synchronize the Data Source

Step 17: Test Retrieval Without Generation

Step 18: Test Retrieval with Response Generation

Step 19: Apply Retrieval Filters

Step 20: Use S3 Metadata as the Governance Control Plane

Step 21: Production Security Checklist

Recommended First Production Configuration

References

Series: Financial Service (19 articles)