DEV Community: Sujitha Rasamsetty

Amazon S3 Vectors: When Your Data Lake Becomes Your Vector Store

Sujitha Rasamsetty — Sun, 11 Jan 2026 09:06:14 +0000

For years, Amazon S3 has been depicted as "just storage" in most architectural diagrams.

We put everything there:

Raw events
PDFs and contracts
Images and videos
Data lake zones

Then we built more systems around it:

Vector databases for semantic search
Indexing services
ETL pipelines to sync embeddings

Every new AI workload meant one more moving piece.

With Amazon S3 Vectors, AWS is quietly asking us:

💡 What if your object store could also be your vector store?

And that's a big shift for anyone building AI, RAG, agents, or semantic search on AWS.

Why S3 Vectors Matter (In One Sentence)

Amazon S3 Vectors lets you store and query vector embeddings directly in S3, with native similarity search no separate vector database needed.

If you're an AWS builder, architect, or data practitioner, this changes how you think about:

Where do you keep embeddings?
How many systems do you operate?
How do you design RAG and AI search workloads?

This is not "just another feature".

This is S3 stepping into the AI runtime 🚀.

First, What Are "Vectors" in This Story?

Short version:

Take text, image, audio, or a document
Run it through an embedding model (Bedrock, SageMaker, open-source, etc.)
You get a list of numbers like: [0.12, -0.83, 0.07, …]

That list of numbers is a vector embedding, a mathematical representation of meaning.

Two items with similar meaning → similar vectors.

This unlocks:

Semantic search ("find things like this")
Recommendations ("suggest similar items")
RAG ("retrieve the right context for my LLM query")

And now, S3 understands this type of data natively ✨

What Did AWS Actually Add?

Amazon S3 Vectors introduces three core building blocks:

1. Vector bucket

A special type of S3 bucket designed for storing and querying vectors
Same durability and elasticity guarantees as S3

2. Vector index

Lives inside a vector bucket
Groups vectors logically (for example: docs, products, support tickets)
This is where similarity search happens

3. Vectors

The embeddings you write into a vector index
Can include metadata (doc_id, type, tenant, created_at, etc.)

You interact with this using dedicated APIs and console support, not just PutObject / GetObject.

Why This Is a Big Deal for AI Builders

Let's be honest: vector databases solved real problems.

But at scale, many teams ended up with:

S3 for raw objects
A vector DB for embeddings
Glue/Spark/ETL to sync between them
Extra monitoring, security, and cost overhead

With S3 Vectors:

Storage and vectors live together
No extra vector infrastructure to deploy and babysit
You pay based on S3 style storage + query usage, not "always-on" clusters

This is especially attractive if you:

Already treat S3 as your "source of truth."
Are cost-sensitive with AI workloads
Want fewer systems in your architecture diagram

How S3 Vectors Fit Into a RAG / AI Architecture

Here's a simple mental flow for a RAG-style app on AWS:

Content lands in S3
- PDFs, docs, wiki exports, tickets, transcripts, etc.
Embedding generation
- Use Amazon Bedrock (for example, a Titan embedding model) or another model to generate embeddings for these items.
Store embeddings in S3 Vectors
- One vector bucket, one or more vector indexes (for example: kb-docs, faqs, tickets)
Query at runtime
- Given a user query → generate a query embedding → run similarity search on S3 Vectors → get the top-K closest vectors
Feed top-K results into your LLM
- Use Bedrock, SageMaker, or any LLM endpoint
Return final answer to user
- Combine retrieved context + LLM response

No external vector DB.

No "sync job" to keep storage and vectors aligned.

If your data lake is in S3, your AI retrieval layer can now live there too.

Where S3 Vectors Shine (Concrete Use Cases)

1️⃣ Semantic Search Over Documents

Perfect for:

Internal knowledge bases
Policy/compliance documents
Customer contracts
Product manuals

Store both the original files in S3 and the embeddings in S3 Vectors.

Search by meaning, not just exact keyword match.

2️⃣ RAG for Enterprise Assistants

LLM-powered assistants need:

Relevant context
Low latency retrieval
Cost-effective storage

S3 Vectors can power the retrieval layer for:

Support chatbots 💬
Internal Q&A over Confluence / SharePoint exports
Developer assistants over code snippets & docs

With Bedrock Knowledge Bases and other integrations, you can plug S3 Vectors into a managed RAG pipeline.

3️⃣ Recommendations & Similarity

Examples:

"Show me products similar to this one."
"Find images visually similar to this photo."
"Recommend articles similar to what I just read."

Store behavior or content embeddings in S3 Vectors and query for nearest neighbors based on vector distance.

4️⃣ Multi-Tenant AI Platforms

If you're building:

A SaaS AI product on AWS
A multi-tenant knowledge platform

You can:

Use metadata like tenant_id, project, visibility.
Filter queries per customer/user
Keep it all in one storage + vector layer

S3 Vectors vs Dedicated Vector Databases

So does this kill vector databases?

Not necessarily.

It changes the question from:

"Which vector DB should I use?"

to:

"Do I actually need a separate vector DB for this workload?"

✅ When S3 Vectors Are a Great Fit

Your primary data is already in S3
You need durable, cost-optimized, large-scale vector storage
You don't want to operate another distributed system
You're building RAG, semantic search, and recommendations on top of existing S3 data

When a Separate Vector DB Might Still Make Sense

Ultra-low-latency, very high-QPS workloads with complex query patterns
Tight coupling with existing non-AWS ecosystems
Highly customized index tuning or retrieval logic

For a huge percentage of GenAI and AI-search workloads on AWS, S3 Vectors will be the default starting point.

🛠️ Getting Started (Builder Mindset)

If I were starting a PoC this week, here's how I'd approach it:

1. Pick one narrow use case
Example:

"Semantic search over our User Group session notes and slide decks."

2. Create a vector bucket + index

Follow the "Getting started with S3 Vectors" section in the AWS docs.

3. Generate embeddings with Bedrock or another model

Start with a Bedrock embedding model (for example, Amazon Titan)
One embedding per document, page, or chunk

4. Write embeddings to S3 Vectors

Include metadata like title, speaker, date, tags, url.

5. Build a tiny API or CLI

Input: natural language query
Output: top-K sessions/docs that match
Return relevant links/summaries

📌 In my next post, I’ll walk you through a hands-on PoC using Amazon S3 Vector Engine — so you can see this in action.

🧭 Architect's Lens: Designing for the Next 12–18 Months

As AI workloads mature, we'll care more about:

Unified data governance (one place to manage access)
Cost curves, not just PoCs
Operational simplicity – fewer systems, fewer outages

S3 Vectors aligns nicely with all three:

Uses IAM + S3 policies for control 🔐
Priced like storage + queries, not another cluster
Integrates with Bedrock, OpenSearch, analytics tools, and more

As builders, our job is not to collect more tools.

It's to design systems that are boring to operate and exciting to use.

S3 Vectors is one of those quiet features that moves us in that direction.

🧠 TL;DR – In Simple Words

Amazon S3 Vectors lets you store AI embeddings in S3 and search them by meaning, without needing a separate vector database. It makes semantic search easier, scalable, and integrated with the AWS ecosystem you already use.

🔗 References

What are you planning to build with S3 Vectors? Drop your thoughts in the comments!

Happy Building! 🚀

About the Author

Sujitha Rasamsetty is an AWS Community Builder in AI Engineering and a Data Scientist at Relanto, with a strong passion for emerging technologies in cloud computing and artificial intelligence.

In her role, she works hands-on with data, cloud architectures, and AI-driven solutions, focusing on building scalable, secure, and production-ready systems. Her interests span across machine learning, generative AI, cloud-native architectures, and data platforms, where she enjoys bridging the gap between advanced analytics and real-world cloud implementations.

Sujitha actively shares her learning and experiences with the community through blogs, discussions, and technical knowledge sharing, with a strong belief in learning in public and growing together as a community.

📌 Let’s Connect:

For updates, discussions, and questions, feel free to connect with her on LinkedIn:

👉 https://www.linkedin.com/in/sujitharasamsetty/

🗣️ Hey Dev. to fam! This is a hands-on guide for building a serverless logging pipeline for Amazon Bedrock — covering everything from invocation to insights using Lambda, S3, CloudWatch, and Athena. If you’ve been wondering how to monitor, store, and an

Sujitha Rasamsetty — Fri, 09 Jan 2026 15:56:42 +0000

Serverless Logging for Amazon Bedrock: From Invocation to Insight

Sujitha Rasamsetty ・ Jan 2

#aws #awscommunity #awsbedrock #ai

Serverless Logging for Amazon Bedrock: From Invocation to Insight

Sujitha Rasamsetty — Fri, 02 Jan 2026 14:53:00 +0000

A hands-on, step-by-step guide to setting up model response logging, error alerts, and actionable insights using AWS Lambda, Amazon Bedrock, S3, CloudWatch, and Athena.

🧠 Why This Matters

As Generative AI adoption grows within enterprises, using services like Amazon Bedrock becomes a preferred approach for building scalable LLM-powered applications. However, as models get integrated into business-critical flows, tracking what is invoked, how it's performing, and where it fails becomes vital.

This PoC demonstrates a serverless, zero-infrastructure approach to:

Log model prompts and responses
Catch and alert on errors in real-time
Store and analyze logs with Athena

For stakeholders, it offers:

Engineering: Track model behavior over time.
Product: See usage patterns or prompt gaps.
Compliance: Maintain traceability of model interactions.

Why We Built This PoC

As enterprises integrate generative AI into realworld applications from chatbots to knowledge assistants ensuring operational visibility becomes critical.

However, when using Amazon Bedrock, developers typically focus only on model integration. What’s often missed is observability — knowing:

What prompts are being sent?
What responses are returned?
What errors occur and when?

This PoC answers that gap.

Purpose

We built this PoC to:

Track model usage (prompts, responses)
Monitor for failures (e.g., access issues, quota breaches)
Alert stakeholders in real-time
Store structured logs for audit/compliance
Enable analytics using SQL (Athena),without extra infrastructure

How This Helps the IT Industry

Cloud Architects / DevOps: Build fault-tolerant LLM apps with integrated monitoring and logging pipelines.
Product Teams: Analyze prompts, user behavior, or failure trends to improve UX.
Security & Compliance: Ensure that model usage is tracked and auditable,a growing requirement in regulated industries.
Startups: Use this serverless pattern to scale quickly without managing infrastructure.

Architecture Overview

Here’s what we’re building:

Architecture Overview: Serverless Logging for Amazon Bedrock

This architecture illustrates a serverless logging and monitoring pipeline for Amazon Bedrock model invocations. It is designed to capture model responses, log interactions, and notify stakeholders of any issues, all without maintaining any infrastructure.

Here's what happens step-by-step:

End User

Initiates a request (e.g., a prompt) that is handled by a serverless backend.
AWS Lambda

A Lambda function acts as the compute layer, invoking the Amazon Bedrock model (e.g., Claude, Titan, or any supported foundation model) and capturing the response.
Amazon Bedrock

Processes the request and returns the generated response back to Lambda.
S3 (Audit Logs)

The prompt and response pair (along with a timestamp) is stored in Amazon S3 in structured JSON format, organized into success and error folders for easy retrieval and analysis.
Athena

Athena queries the audit logs directly from S3 to extract insights, track usage, or debug issues using SQL, without needing to move data.
CloudWatch

Monitors the Lambda function’s execution and captures any error logs or anomalies.
SNS (Simple Notification Service)

When an error is detected (e.g., failed Bedrock call or S3 write), CloudWatch triggers an alarm that notifies stakeholders via an SNS topic (email/SMS/Slack).

Step 1: Set Up IAM Roles and Policies

Lambda Execution Role

Create a role with the following:

AmazonBedrockFullAccess (or scoped-down invoke permissions)
AmazonS3FullAccess (or fine-grained access to specific bucket/prefix)
CloudWatchLogsFullAccess

Attach the role to the Lambda function.

S3 Bucket Policy

Allow the Lambda role to PutObject to the audit log bucket:

{
  "Effect": "Allow",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::bedrock-model-audit-logs-sujitha/bedrock-backups/*"
}

Step 2: Create Lambda Function

Use Python for the function.

Key features:

Receives prompt via event
Invokes Bedrock model (Titan / Claude / others)
Stores response in S3 (success or error folder)
Logs to CloudWatch
Sends SNS alert on failure

import json
import boto3
import uuid
import datetime

bedrock = boto3.client("bedrock-runtime")
s3 = boto3.client("s3")

S3_BUCKET = "bedrock-model-audit-logs-sujitha"
S3_PREFIX = "bedrock-backups"

def lambda_handler(event, context):
    prompt = event.get("prompt", "Default prompt")
    timestamp = datetime.datetime.now().isoformat()
    interaction_id = str(uuid.uuid4())

    try:
        # Bedrock inference
        response = bedrock.invoke_model(
            modelId="amazon.titan-text-express-v1",
            body=json.dumps({
                "inputText": prompt,
                "textGenerationConfig": {
                    "maxTokenCount": 500,
                    "temperature": 0.7,
                    "topP": 0.9
                }
            }),
            contentType="application/json",
            accept="application/json"
        )

        result = json.loads(response["body"].read().decode("utf-8"))
        output = result.get("results", [{}])[0].get("outputText", "")

        # Save success log
        s3.put_object(
            Bucket=S3_BUCKET,
            Key=f"{S3_PREFIX}/success/interaction-{interaction_id}.json",
            Body=json.dumps({
                "timestamp": timestamp,
                "prompt": prompt,
                "response": output
            })
        )

        return {
            "statusCode": 200,
            "body": json.dumps({
                "prompt": prompt,
                "response": output
            })
        }

    except Exception as e:
        error_message = str(e)

        # Save error log
        s3.put_object(
            Bucket=S3_BUCKET,
            Key=f"{S3_PREFIX}/error/interaction-{interaction_id}.json",
            Body=json.dumps({
                "timestamp": timestamp,
                "prompt": prompt,
                "error": error_message
            })
        )

        return {
            "statusCode": 500,
            "body": json.dumps({"error": error_message})
        }

Step 3: Create S3 Folder Structure

CloudWatch Metrics & Error Alerts

To ensure production-grade reliability, we monitor our Lambda function using Amazon CloudWatch.

Custom Metric: `Errors`

We use the built-in Lambda metric:

Namespace: AWS/Lambda
Metric name: Errors
Dimension: FunctionName = bedrock-model-backup
Period: 10 seconds
Statistic: Average

This metric tracks how often the Lambda function fails — for example, when the Bedrock invocation fails or when S3 writes are denied.

🚨 Alarm Setup

A CloudWatch alarm is created with:

Threshold: ≥ 1 error
Evaluation Period: 1 datapoint (10 seconds)
TreatMissingData: missing
Alarm Action: Triggers an SNS Topic to notify stakeholders

This ensures real-time notifications when even a single error occurs helpful during early testing or production monitoring.

You’ll receive emails like this from Amazon SNS, alerting you to issues immediately:

ALARM: "bedrock-error-alarm"

Threshold Crossed: 1 out of the last 1 datapoints was ≥ 1.0

FunctionName = bedrock-model-backup

Why This Helps

Engineering teams get real-time visibility into model failures.
Product managers can track stability over time.
Stakeholders are kept in the loop via email/SMS.

Step 4: Set Up SNS Alert

Create an SNS topic: bedrock-model-errors.
Subscribe to your email to the topic.
Use the topic ARN in Lambda.

Step 5: Set Up Athena for Log Querying

Create Database

CREATE DATABASE IF NOT EXISTS bedrock_audit_logs;

Create Table (Success Logs)

CREATE EXTERNAL TABLE IF NOT EXISTS bedrock_audit_logs.success_logs (
  `timestamp` string,
  `prompt` string,
  `response` string
)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
  'ignore.malformed.json' = 'true'
)
LOCATION 's3://bedrock-model-audit-logs-sujitha/bedrock-backups/success/.'
TBLPROPERTIES ('has_encrypted_data'='false');

Repeat similarly for error_logs table with an error column.

Run Queries

SELECT prompt, response, timestamp
FROM bedrock_audit_logs.success_logs
ORDER BY timestamp DESC;

Conclusion: Wrapping It All Together

In a world rapidly adopting Generative AI, observability is not optional especially when models power customer-facing or compliance-sensitive applications.

This Proof of Concept (PoC) offers a fully serverless, production-grade pattern to:

Log every Amazon Bedrock prompt and response
Detect and alert on errors in real-time
Store structured audit logs for compliance and monitoring
Run post-hoc analysis using SQL, without managing infrastructure

By combining Lambda, Amazon Bedrock, S3, CloudWatch, SNS, and Athena, we’ve created a scalable blueprint that any team can adopt and extend.

Whether you're building internal tools or external-facing AI apps, this architecture ensures visibility, accountability, and agility.

If you found this helpful, don’t forget to ❤️ and follow for more serverless + GenAI guides!

Questions or suggestions? Drop them in the comments 👇

About the Author

In her role, she works hands on with data, cloud architectures, and AI-driven solutions, focusing on building scalable, secure, and production-ready systems. Her interests span across machine learning, generative AI, cloud-native architectures, and data platforms, where she enjoys bridging the gap between advanced analytics and real-world cloud implementations.

📌 Let’s Connect:

For updates, discussions, and questions, feel free to connect with her on LinkedIn:

👉 https://www.linkedin.com/in/sujitharasamsetty/

How to Become an AWS Community Builder (What Nobody Tells You)

Sujitha Rasamsetty — Fri, 02 Jan 2026 06:30:18 +0000

👋 Hey there, tech enthusiasts!

I’m writing this not as a recruiter, not as an AWS employee, and not as someone who “figured it all out” early — but as someone who learned the hard way what community actually means in tech.

This article is for people who:

Are curious about the AWS Community Builders Program
Feel they might be “too early” or “not ready.”
Are tired of shallow posts that only talk about benefits and swag

This is not a hype piece.

This is a reality-based guide built from observation, participation, mistakes, and mentoring others.

First, Let’s Reset Expectations

Most content about the AWS Community Builder program follows the same template:

What the program is
What benefits you get
How to apply
What swag looks like

That information is easy to find.

What’s harder to find — and more important — is this truth:

You don’t become an AWS Community Builder by applying.

You apply because you already behave like one.

The program doesn’t create community builders.

It recognizes patterns that already exist.

A Quick Note on Applications

The AWS Community Builder applications usually:

Open once a year
Typically around early January
Stay open for ~2 weeks

But timing matters far less than what you’ve been doing in the months before.

⏳ Join the Official Waitlist

If applications are not yet open, AWS provides an official waitlist so you don’t miss the next cycle.

👉 AWS Community Builders – Waitlist & Program Page:

https://builder.aws.com/community/community-builders

If you’re serious about applying, joining the waitlist is the first practical step.

The Biggest Myth About AWS Community Builders

Let’s kill this myth immediately:

“AWS Community Builders are experts with tons of certifications and followers.”

That is not what AWS is selecting.

AWS is selecting signals.

The signals that matter:

Are you learning continuously?
Are you sharing consistently?
Are you helping others without being asked?
Do you show up even when no one is watching?

Skill level helps.

Visibility helps.

But neither is the deciding factor.

What AWS Is Actually Looking For (Without Saying It)

After observing multiple cycles — people getting selected, rejected, reapplying, and eventually succeeding — a few patterns become very clear.

1. Learning in Public Beats Private Excellence

AWS strongly favors people who document their learning openly.

This does not mean:

Writing perfect tutorials
Explaining everything, like documentation
Acting like an expert

It does mean:

Writing about what confused you
Sharing what failed before it worked
Explaining concepts in your own words
Turning notes into blogs, posts, or videos

Learning in public shows:

Curiosity
Humility
Long-term intent

That alignment matters far more than polish.

2. Consistency Is Louder Than Talent

One excellent article written a year ago is weaker than:

Two or three honest contributions spread across months

The program intentionally looks at recent activity.

Why?

Because they are not evaluating your past achievements —

they’re evaluating your current behavior.

AWS is not looking for a burst of effort.

They’re looking for momentum.

3. Your Voice Matters More Than Your Topic

If your content:

Sounds like copied documentation
Feels like marketing material
Reads like an LLM-generated summary

…it silently weakens your application.

AWS wants your thinking, not recycled explanations.

If it doesn’t sound like you — rewrite it.

Clarity > complexity

Honesty > perfection

Voice > volume

“What Should I Even Contribute?”

Here’s the simplest answer:

Contribute what you are already learning, building, fixing, or explaining.

Strong contribution examples:

What went wrong when setting up your first VPC
IAM mistakes you didn’t expect
Cost surprises from your first AWS bill
Explaining a service the way you wish someone had explained it to you

Content rooted in real experience always wins.

Formats That Work Well

Blog posts (dev.to, Medium, personal site)
GitHub repos (PoCs, IaC, demos)
Short videos or walkthroughs
Community answers with explanations (not just fixes)

Language is not a barrier.

Local-language content is welcome and encouraged.

The Hidden Lifecycle of a Community Builder

Most successful Community Builders move through these stages:

Learning – courses, docs, labs
Narrating – blogs, notes, walkthroughs
Contributing – helping others consistently
Connecting – mentoring, speaking, enabling

The program does not force this journey.

It recognizes people who are already on it.

The Application Is Not a Test — It’s a Story

The application is not asking:

How impressive are you?
How many followers do you have?

It’s asking:

Can you explain your journey clearly?
Do your contributions back your words?
Will you continue contributing after selection?

Exaggeration hurts more than honesty.

Rejection is not failure.

It’s timing and alignment.

About Benefits (Let’s Be Real)

Yes, there are credits, learning resources, and swag.

But the real impact is:

Confidence to share publicly
Access to global peers
A sense of belonging
A platform that amplifies learning, not ego

If I Were Starting Today

Here’s what I would do differently if I started today:

Pick one AWS area
Publish consistently, not perfectly
Choose one platform and commit
Help beginners openly
Treat rejection as part of the process

Stop asking:

“How do I get selected?”

Start asking:

“How do I become useful?”

Selection always follows usefulness.

Closing Thoughts

You don’t become an AWS Community Builder in January when applications open.

You become one quietly:

Month by month
Post by post
Help by help

The application simply confirms what you’ve already built.

📌 Wrapping Up

If this helped:

❤️ Like it
🔁 Share it with someone applying
💬 Drop your thoughts or questions in the comments

Community growth always starts with conversation.

Happy learning 🚀

About the Author

📌 Let’s Connect:

For updates, discussions, and questions, feel free to connect with her on LinkedIn:

👉 https://www.linkedin.com/in/sujitharasamsetty/

AWS Clean Rooms: End-to-End Analytics Collaboration Across Two AWS Accounts

Sujitha Rasamsetty — Mon, 22 Dec 2025 09:10:14 +0000

Why AWS Clean Rooms, and why this PoC?

Most cross-company data collaborations fail at the same point: data sharing.

Even when both sides want the same outcome (insights), sharing raw data introduces compliance, security, and trust barriers. AWS Clean Rooms addresses that gap by letting multiple parties run approved analytics across their datasets while preventing raw data exposure.

In this post, I’ll show a simple, reproducible PoC where:

Two AWS accounts participate in a Clean Rooms collaboration
Each account contributes a small S3 dataset
Query access is governed by analysis rules
The analyst gets aggregated results only

This is intentionally a small PoC, designed to be easy to understand and easy to reproduce exactly the kind of “teachable build” that works well for community learning.

What we are building

The simplest useful story is: count customers by region, without letting anyone download or view raw rows.

The roles in this PoC:

Account A: “Data owner” — hosts a dataset in S3 and allows limited analysis through rules.
Account B: “Second participant” — joins the collaboration and contributes its dataset (or can be an analyst member depending on your setup).
AWS Clean Rooms: enforces collaboration boundaries and query-level privacy controls.

Even if the real world is more complex, this PoC covers the core fundamentals.

Prerequisites

Two AWS accounts (Account A and Account B)
Same region in both accounts (I used us-east-1 for simplicity)
S3 access in both accounts
AWS Clean Rooms access in both accounts
Athena will be used as the query engine (Clean Rooms integrates with Athena)

IAM quick checklist (minimum for a PoC)

In both accounts, ensure the user you’re logged in with has:

AWSCleanRoomsFullAccess
S3 permissions (at least to your PoC buckets)
Athena + Glue permissions (for catalog + querying)

For a PoC, using AWS managed policies is acceptable and helps you move quickly.

Step 1: Create the datasets (one per account)

Create two small CSV files.

Account A dataset (example: `company_a_customers.csv`)

customer_id,region
A001,India
A002,India
A003,USA
A004,UK
A005,USA

Account B dataset (example: company_b_customers.csv)

customer_id,region
B101,India
B102,USA
B103,USA
B104,Canada
B105,UK

Upload them to S3:

Account A bucket example: aws-clean-rooms-poc-org-a
Account B bucket example: aws-clean-rooms-poc-org-b

Step 2: Create the AWS Clean Rooms collaboration (Account A)

Sign in to Account A.
Navigate to:

AWS Console → AWS Clean Rooms → Collaborations → Create collaboration
Enter collaboration details:
- Collaboration name: aws-clean-rooms-collaboration-poc
- Description: Short, goal-oriented description

4.Add members:

Member 1: Account A (automatically added as the creator)
Member 2: Account B (must be a different AWS Account ID)

Each collaboration member must be a unique AWS account.

Duplicate account IDs are not allowed.

5.Configure collaboration abilities:

Enable Queries (SQL)
Do not enable Jobs or ML workflows for this PoC

6.Configure query cost responsibility:

Pay for queries: Account A

7.Create the collaboration.
8.Review and create:

Click Create Collaboration

Then, create the collaboration and join it by creating a membership immediately.

Why the “two accounts” requirement matters

Clean Rooms enforces collaboration boundaries at the account level, so each member must be in a unique AWS account. This is not optional; it’s the security boundary.

Step 3: Accept invitation and create membership (Account B)

In Account B:

Open AWS Clean Rooms in the same region
You should see a pending invitation under Collaborations
Click Create membership to join

If you see "Access denied" or "needs subscription."

This usually means one of two things:

AWS Clean Rooms is not enabled/initialized in the account (first-time access)

Your IAM user does not have AWSCleanRoomsFullAccess

Fix: attach the policy to the IAM user you are logged in with (creating a role alone won’t help unless you assume it).

Step 4: Catalog S3 data (Glue) so Clean Rooms/Athena can query it

This step confuses many people at first, so I’ll explain clearly:

Do I need AWS Glue?

Yes, if your data source is S3 and you plan to query with Athena

Clean Rooms uses query engines like Athena. Athena queries tables defined in the Glue Data Catalog. So the S3 files must be represented as tables in Glue (schema matters).

You can create the Glue table either by:

creating a Glue table manually (fast for PoC), or
using a crawler (overkill for this PoC)

Create Glue table in Account A:

In Account A → AWS Glue → Databases / Tables:

Create database: cleanrooms_poc_db

Create table: company_a_customers
Location: s3://aws-clean-rooms-poc-org-a/
Format: CSV
Schema (must match your CSV):
customer_id (string)
region (string)

Repeat the same in Account B:

Database: cleanrooms_poc_db
Table: company_b_customers
Location: s3://aws-clean-rooms-poc-org-b-/
Schema:
customer_id (string)
region (string)

Important lesson: If a column is missing in Glue schema, you will get errors like:

Column 'customer_id' not found in any table

This is not a Clean Rooms bug; it's a catalog/schema mismatch.

Step 5: Create configured tables (Account A and Account B)

Configured tables are how Clean Rooms expose a dataset to the collaboration.

In Account A

1.AWS Clean Rooms → Tables → Configure new table
2.Data source: Amazon S3
3.Choose the Glue database/table you created:

cleanrooms_poc_db.company_a_customers

4.Columns available to collaboration:

For this PoC, allow both:
customer_id
region

5.Allowed analysis methods:

Direct query only
Do not enable jobs

6.Create configured table.

In Account B :
Repeat the same steps for:
- cleanrooms_poc_db.company_b_customers

Step 6: Associate configured tables with the collaboration

Still in each account:

Go to the configured table
Choose Associate to collaboration
Skip data access budget for now (optional feature; not needed for a basic PoC)
When you return to the collaboration view, you should see tables associated with both members.

If you only see Account A’s table, it means Account B hasn’t associated its table yet.

Step 7: Configure the analysis rule (this is the core of Clean Rooms)

Analysis rules define what is allowed.
For a community-friendly PoC, use Aggregation rules.
Recommended aggregation rule design

Goal: allow results like “count customers by region” while blocking raw output.

In the analysis rule UI:

1.Choose Aggregation
2.Query controls:

Allow COUNT (or COUNT_DISTINCT) on customer_id 3.Dimension controls:
Allow region as a dimension column
This is what makes region appear in SELECT/GROUP BY 4.Join controls:
- If you want standalone aggregation, allow “queried by itself = Yes”
- If you want overlap-only analytics, choose overlap-only (stricter) 5.Output constraints (aggregation thresholds):
- Set minimum threshold (e.g., 2) This prevents returning results for very small groups (privacy guardrail)

Common error and the fix:
If you see an error like:

columns prohibited by aggregation analysis rule

It means your analysis rule doesn’t allow that column in the SELECT/PROJECT clause.

Fix it by ensuring:

region is included as a dimension column
aggregate function is defined on customer_id

This is exactly how Clean Rooms enforces safe query structure.

Step 8: Where to run queries

You can run queries from the AWS Clean Rooms analysis experience, not directly from Athena.

In the collaboration:

AWS Clean Rooms → Collaborations → select your collaboration
Go to Analysis (or “Run analysis / Queries”, depending on console)
Choose the tables and run SQL there

This ensures the query is evaluated against Clean Rooms analysis rules and constraints.

Step 9: Example query

Once both tables are associated and analysis rules allow it, run:

SELECT
  region,
  COUNT(DISTINCT customer_id) AS customer_count
FROM company_a_customers_v2
GROUP BY region;

Or, if you designed the collaboration to require overlap joins, your query will need to join Account A and Account B tables using approved join columns.

Either way, the result should be aggregated and controlled by thresholds.

What this PoC demonstrates:

This simple PoC proves several important points:
Collaboration is enforced at the AWS account boundary
Data stays in each owner’s S3 bucket; what changes is what can be computed
Glue/Athena catalog integration matters (schema correctness is critical)
Analysis rules are the real power:
- They control columns
- They control query structure
- They control privacy thresholds

This is not “sharing data safely.”
It is “designing a system where raw data sharing is not required.”

Closing

If you’re learning or teaching privacy-first data collaboration patterns on AWS, Clean Rooms is worth investing time into. The service is less about analytics features and more about architectural trust boundaries.

If you build this PoC, feel free to adapt the dataset and analysis rules to your domain (ad measurement, fraud, healthcare research). The core idea remains the same.

DEV Community: Sujitha Rasamsetty

Amazon S3 Vectors: When Your Data Lake Becomes Your Vector Store

Why S3 Vectors Matter (In One Sentence)

First, What Are "Vectors" in This Story?

What Did AWS Actually Add?

Why This Is a Big Deal for AI Builders

How S3 Vectors Fit Into a RAG / AI Architecture

Where S3 Vectors Shine (Concrete Use Cases)

1️⃣ Semantic Search Over Documents

2️⃣ RAG for Enterprise Assistants

3️⃣ Recommendations & Similarity

4️⃣ Multi-Tenant AI Platforms

S3 Vectors vs Dedicated Vector Databases

✅ When S3 Vectors Are a Great Fit

When a Separate Vector DB Might Still Make Sense

🛠️ Getting Started (Builder Mindset)

🧭 Architect's Lens: Designing for the Next 12–18 Months

🧠 TL;DR – In Simple Words

🔗 References

About the Author

🗣️ Hey Dev. to fam! This is a hands-on guide for building a serverless logging pipeline for Amazon Bedrock — covering everything from invocation to insights using Lambda, S3, CloudWatch, and Athena. If you’ve been wondering how to monitor, store, and an

Serverless Logging for Amazon Bedrock: From Invocation to Insight

Sujitha Rasamsetty ・ Jan 2

Serverless Logging for Amazon Bedrock: From Invocation to Insight

🧠 Why This Matters

Why We Built This PoC

Purpose

How This Helps the IT Industry

Architecture Overview

Architecture Overview: Serverless Logging for Amazon Bedrock

Here's what happens step-by-step:

Step 1: Set Up IAM Roles and Policies

Lambda Execution Role

S3 Bucket Policy

Step 2: Create Lambda Function

Key features:

Step 3: Create S3 Folder Structure

CloudWatch Metrics & Error Alerts

Custom Metric: Errors

🚨 Alarm Setup

Why This Helps

Step 4: Set Up SNS Alert

Step 5: Set Up Athena for Log Querying

Create Database

Create Table (Success Logs)

Run Queries

Conclusion: Wrapping It All Together

About the Author

How to Become an AWS Community Builder (What Nobody Tells You)

First, Let’s Reset Expectations

A Quick Note on Applications

⏳ Join the Official Waitlist

The Biggest Myth About AWS Community Builders

The signals that matter:

What AWS Is Actually Looking For (Without Saying It)

1. Learning in Public Beats Private Excellence

2. Consistency Is Louder Than Talent

3. Your Voice Matters More Than Your Topic

“What Should I Even Contribute?”

Formats That Work Well

The Hidden Lifecycle of a Community Builder

The Application Is Not a Test — It’s a Story

About Benefits (Let’s Be Real)

If I Were Starting Today

Closing Thoughts

📌 Wrapping Up

About the Author

AWS Clean Rooms: End-to-End Analytics Collaboration Across Two AWS Accounts

Why AWS Clean Rooms, and why this PoC?

What we are building

The roles in this PoC:

Prerequisites

IAM quick checklist (minimum for a PoC)

Step 1: Create the datasets (one per account)

Account A dataset (example: company_a_customers.csv)

Account B dataset (example: company_b_customers.csv)

Step 2: Create the AWS Clean Rooms collaboration (Account A)

Step 3: Accept invitation and create membership (Account B)

Step 4: Catalog S3 data (Glue) so Clean Rooms/Athena can query it

Step 5: Create configured tables (Account A and Account B)

Custom Metric: `Errors`

Account A dataset (example: `company_a_customers.csv`)