Case Studies Basics

This page is a short tour across the four reference builds in this section, one wiring idea at a time.

Each stop shows the smallest snippet that captures what makes that build's architecture distinctive - not the full system, which lives on its own page.

Prerequisites

Familiarity with the individual services each build wires together: Lambda, DynamoDB, Bedrock, Knowledge Bases, S3 Vectors, Step Functions, and Redshift, all covered in depth elsewhere in this cookbook.
Python: pip install boto3 (boto3 1.43.x, Python 3.10+). TypeScript: the per-service clients you use, for example npm install @aws-sdk/client-lambda @aws-sdk/client-dynamodb (Node.js 18+).
Credentials and a default region configured, as in every other section of this cookbook.

Basic Examples

1. Request-to-Record Mapping (Serverless REST API)

The core idea behind Lambda + DynamoDB + API Gateway is turning one HTTP request into one table operation.

# --- Python (boto3) ---
import boto3, json
 
table = boto3.resource("dynamodb").Table("Tasks")
 
def handler(event, context):
    body = json.loads(event["body"])
    table.put_item(Item={"taskId": body["taskId"], "title": body["title"]})
    return {"statusCode": 201, "body": json.dumps({"taskId": body["taskId"]})}

// --- TypeScript (AWS SDK v3) ---
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, PutCommand } from "@aws-sdk/lib-dynamodb";
 
const doc = DynamoDBDocumentClient.from(new DynamoDBClient({}));
 
export const handler = async (event: any) => {
  const body = JSON.parse(event.body);
  await doc.send(new PutCommand({ TableName: "Tasks", Item: { taskId: body.taskId, title: body.title } }));
  return { statusCode: 201, body: JSON.stringify({ taskId: body.taskId }) };
};

API Gateway invokes the Lambda function synchronously and hands it a proxy event with the HTTP body as a string.
The handler parses the body once, then makes exactly one DynamoDB call per request.
The Lambda response shape (statusCode, body) is what API Gateway turns back into an HTTP response.
The full build adds a GET path, validation, and error responses.

Related: Building a Serverless REST API: Lambda + DynamoDB + API Gateway.

2. Retrieve-Then-Generate (RAG Chatbot)

The core idea behind a Bedrock RAG chatbot is retrieving grounding context before asking the model to answer.

# --- Python (boto3) ---
import boto3
 
bedrock_agent = boto3.client("bedrock-agent-runtime")
 
resp = bedrock_agent.retrieve_and_generate(
    input={"text": "What is our refund window?"},
    retrieveAndGenerateConfiguration={
        "type": "KNOWLEDGE_BASE",
        "knowledgeBaseConfiguration": {
            "knowledgeBaseId": "KB123EXAMPLE",
            "modelArn": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet-20241022-v2:0",
        },
    },
)
print(resp["output"]["text"])

// --- TypeScript (AWS SDK v3) ---
import { BedrockAgentRuntimeClient, RetrieveAndGenerateCommand } from "@aws-sdk/client-bedrock-agent-runtime";
 
const client = new BedrockAgentRuntimeClient({});
const resp = await client.send(new RetrieveAndGenerateCommand({
  input: { text: "What is our refund window?" },
  retrieveAndGenerateConfiguration: {
    type: "KNOWLEDGE_BASE",
    knowledgeBaseConfiguration: {
      knowledgeBaseId: "KB123EXAMPLE",
      modelArn: "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet-20241022-v2:0",
    },
  },
}));
console.log(resp.output?.text);

RetrieveAndGenerate does the vector search and the model call in one managed step.
The knowledge base is backed by an S3 Vectors index in the full build, hedged as an evolving 2026 surface.
The model only sees passages the retriever returns, which is what keeps answers grounded.
The full build adds conversation history and citations.

Related: Building a RAG Chatbot: Bedrock + Knowledge Bases + S3 Vectors.

Intermediate Examples

3. Event-to-Orchestration Handoff (Data Pipeline)

The core idea behind the data pipeline is a small Lambda function that only starts a Step Functions execution - it does not do the work itself.

# --- Python (boto3) ---
import boto3, json
 
sfn = boto3.client("stepfunctions")
 
def handler(event, context):
    record = event["Records"][0]["s3"]
    key = record["object"]["key"]
    sfn.start_execution(
        stateMachineArn="arn:aws:states:us-east-1:123456789012:stateMachine:LoadToRedshift",
        input=json.dumps({"bucket": record["bucket"]["name"], "key": key}),
    )

// --- TypeScript (AWS SDK v3) ---
import { SFNClient, StartExecutionCommand } from "@aws-sdk/client-sfn";
 
const sfn = new SFNClient({});
 
export const handler = async (event: any) => {
  const record = event.Records[0].s3;
  await sfn.send(new StartExecutionCommand({
    stateMachineArn: "arn:aws:states:us-east-1:123456789012:stateMachine:LoadToRedshift",
    input: JSON.stringify({ bucket: record.bucket.name, key: record.object.key }),
  }));
};

The Lambda function is deliberately thin: its only job is translating an S3 event into a Step Functions input.
The state machine, not the function, owns the multi-step load-and-query workflow.
This handoff pattern keeps the event-triggered function fast and cheap to run per object.
The full build shows the state machine definition and the Redshift Data API load step.

Related: Building a Data Pipeline: S3 + Lambda + Step Functions + Redshift.

4. Batching Over Per-Item Calls (Before/After Refactor)

The core idea behind the refactor case study is replacing a per-item loop with a single batched call.

# --- Python (boto3) ---
# Before: one DynamoDB call per item in a loop.
# After: one BatchWriteItem call for up to 25 items.
table = boto3.resource("dynamodb").Table("Orders")
with table.batch_writer() as batch:
    for order in orders:
        batch.put_item(Item=order)

// --- TypeScript (AWS SDK v3) ---
// Before: one PutCommand per item in a loop.
// After: one BatchWriteCommand for up to 25 items.
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, BatchWriteCommand } from "@aws-sdk/lib-dynamodb";
 
const doc = DynamoDBDocumentClient.from(new DynamoDBClient({}));
await doc.send(new BatchWriteCommand({
  RequestItems: { Orders: orders.map((o: any) => ({ PutRequest: { Item: o } })) },
}));

The before version makes one round trip per item, so latency and throttling risk scale with item count.
The after version batches up to 25 items per call, cutting round trips by up to 25x for a full batch.
Batching does not remove the need for retry logic - a batch call can still partially fail.
The full build walks through the complete before/after narrative with a qualitative benchmark comparison.

Related: Before/After: Refactoring a Monolithic SDK Integration.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).

Each stop shows the smallest snippet that captures what makes that build's architecture distinctive - not the full system, which lives on its own page.

Prerequisites

Familiarity with the individual services each build wires together: Lambda, DynamoDB, Bedrock, Knowledge Bases, S3 Vectors, Step Functions, and Redshift, all covered in depth elsewhere in this cookbook.
Python: pip install boto3 (boto3 1.43.x, Python 3.10+). TypeScript: the per-service clients you use, for example npm install @aws-sdk/client-lambda @aws-sdk/client-dynamodb (Node.js 18+).
Credentials and a default region configured, as in every other section of this cookbook.

Basic Examples

1. Request-to-Record Mapping (Serverless REST API)

The core idea behind Lambda + DynamoDB + API Gateway is turning one HTTP request into one table operation.

# --- Python (boto3) ---
import boto3, json
 
table = boto3.resource("dynamodb").Table("Tasks")
 
def handler(event, context):
    body = json.loads(event["body"])
    table.put_item(Item={"taskId": body["taskId"], "title": body["title"]})
    return {"statusCode": 201, "body": json.dumps({"taskId": body["taskId"]})}

// --- TypeScript (AWS SDK v3) ---
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, PutCommand } from "@aws-sdk/lib-dynamodb";
 
const doc = DynamoDBDocumentClient.from(new DynamoDBClient({}));
 
export const handler = async (event: any) => {
  const body = JSON.parse(event.body);
  await doc.send(new PutCommand({ TableName: "Tasks", Item: { taskId: body.taskId, title: body.title } }));
  return { statusCode: 201, body: JSON.stringify({ taskId: body.taskId }) };
};

API Gateway invokes the Lambda function synchronously and hands it a proxy event with the HTTP body as a string.
The handler parses the body once, then makes exactly one DynamoDB call per request.
The Lambda response shape (statusCode, body) is what API Gateway turns back into an HTTP response.
The full build adds a GET path, validation, and error responses.

Related: Building a Serverless REST API: Lambda + DynamoDB + API Gateway.

2. Retrieve-Then-Generate (RAG Chatbot)

The core idea behind a Bedrock RAG chatbot is retrieving grounding context before asking the model to answer.

# --- Python (boto3) ---
import boto3
 
bedrock_agent = boto3.client("bedrock-agent-runtime")
 
resp = bedrock_agent.retrieve_and_generate(
    input={"text": "What is our refund window?"},
    retrieveAndGenerateConfiguration={
        "type": "KNOWLEDGE_BASE",
        "knowledgeBaseConfiguration": {
            "knowledgeBaseId": "KB123EXAMPLE",
            "modelArn": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet-20241022-v2:0",
        },
    },
)
print(resp["output"]["text"])

// --- TypeScript (AWS SDK v3) ---
import { BedrockAgentRuntimeClient, RetrieveAndGenerateCommand } from "@aws-sdk/client-bedrock-agent-runtime";
 
const client = new BedrockAgentRuntimeClient({});
const resp = await client.send(new RetrieveAndGenerateCommand({
  input: { text: "What is our refund window?" },
  retrieveAndGenerateConfiguration: {
    type: "KNOWLEDGE_BASE",
    knowledgeBaseConfiguration: {
      knowledgeBaseId: "KB123EXAMPLE",
      modelArn: "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet-20241022-v2:0",
    },
  },
}));
console.log(resp.output?.text);

RetrieveAndGenerate does the vector search and the model call in one managed step.
The knowledge base is backed by an S3 Vectors index in the full build, hedged as an evolving 2026 surface.
The model only sees passages the retriever returns, which is what keeps answers grounded.
The full build adds conversation history and citations.

Related: Building a RAG Chatbot: Bedrock + Knowledge Bases + S3 Vectors.

Intermediate Examples

3. Event-to-Orchestration Handoff (Data Pipeline)

The core idea behind the data pipeline is a small Lambda function that only starts a Step Functions execution - it does not do the work itself.

# --- Python (boto3) ---
import boto3, json
 
sfn = boto3.client("stepfunctions")
 
def handler(event, context):
    record = event["Records"][0]["s3"]
    key = record["object"]["key"]
    sfn.start_execution(
        stateMachineArn="arn:aws:states:us-east-1:123456789012:stateMachine:LoadToRedshift",
        input=json.dumps({"bucket": record["bucket"]["name"], "key": key}),
    )

// --- TypeScript (AWS SDK v3) ---
import { SFNClient, StartExecutionCommand } from "@aws-sdk/client-sfn";
 
const sfn = new SFNClient({});
 
export const handler = async (event: any) => {
  const record = event.Records[0].s3;
  await sfn.send(new StartExecutionCommand({
    stateMachineArn: "arn:aws:states:us-east-1:123456789012:stateMachine:LoadToRedshift",
    input: JSON.stringify({ bucket: record.bucket.name, key: record.object.key }),
  }));
};

The Lambda function is deliberately thin: its only job is translating an S3 event into a Step Functions input.
The state machine, not the function, owns the multi-step load-and-query workflow.
This handoff pattern keeps the event-triggered function fast and cheap to run per object.
The full build shows the state machine definition and the Redshift Data API load step.

Related: Building a Data Pipeline: S3 + Lambda + Step Functions + Redshift.

4. Batching Over Per-Item Calls (Before/After Refactor)

The core idea behind the refactor case study is replacing a per-item loop with a single batched call.

# --- Python (boto3) ---
# Before: one DynamoDB call per item in a loop.
# After: one BatchWriteItem call for up to 25 items.
table = boto3.resource("dynamodb").Table("Orders")
with table.batch_writer() as batch:
    for order in orders:
        batch.put_item(Item=order)

// --- TypeScript (AWS SDK v3) ---
// Before: one PutCommand per item in a loop.
// After: one BatchWriteCommand for up to 25 items.
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, BatchWriteCommand } from "@aws-sdk/lib-dynamodb";
 
const doc = DynamoDBDocumentClient.from(new DynamoDBClient({}));
await doc.send(new BatchWriteCommand({
  RequestItems: { Orders: orders.map((o: any) => ({ PutRequest: { Item: o } })) },
}));

The before version makes one round trip per item, so latency and throttling risk scale with item count.
The after version batches up to 25 items per call, cutting round trips by up to 25x for a full batch.
Batching does not remove the need for retry logic - a batch call can still partially fail.
The full build walks through the complete before/after narrative with a qualitative benchmark comparison.

Related: Before/After: Refactoring a Monolithic SDK Integration.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).

Case Studies Basics

Buscar en la documentación

Case Studies Basics