Build an AI Document Summarizer with AWS Serverless

Build an AI Document Summarizer with AWS Serverless
Organizations process thousands of documents every day, including reports, invoices, meeting notes, and technical documents. Manually reading and summarizing these documents can be time-consuming.
In this article, we’ll build a simple serverless AI document summarization workflow using AWS services. The solution automatically processes a document uploaded to Amazon S3, invokes Amazon Bedrock to generate a summary, and stores the result in Amazon DynamoDB.
The architecture requires no servers to manage and can be extended for many AI-powered document-processing use cases.
Solution architecture
The workflow consists of four main AWS services:
User
|
v
Amazon S3
|
| Object Created Event
v
AWS Lambda
|
| Invoke model
v
Amazon Bedrock
|
v
Amazon DynamoDB

The workflow is:
A user uploads a document to Amazon S3.
Amazon S3 generates an object-created event.
AWS Lambda receives the event.
Lambda retrieves the document.
Lambda sends the document content to Amazon Bedrock.
Amazon Bedrock generates a summary.
Lambda stores the summary in DynamoDB.
This event-driven architecture allows the application to process documents without maintaining an always-running server.
Prerequisites
Before starting, you should have:
An AWS account
Basic knowledge of AWS IAM
Basic Python knowledge
Access to Amazon S3
Access to AWS Lambda
Access to Amazon Bedrock
Access to Amazon DynamoDB
Make sure the foundation model you plan to use is available and enabled for your AWS Region.
Step 1: Create an Amazon S3 bucket
Amazon S3 will be used as the document upload location.
You can create a bucket using the AWS CLI:
aws s3 mb s3://my-ai-document-input

For a production workload, enable security controls such as:
Block Public Access
Server-side encryption
Versioning
Lifecycle policies
Least-privilege IAM permissions
A simple object structure could look like this:
documents/
report.txt
meeting-notes.txt
project-summary.txt

When a new document is uploaded, S3 can trigger the Lambda function.
Step 2: Create the Lambda function
AWS Lambda provides the compute layer for our application.
The function receives the S3 event, downloads the document, prepares a prompt, and invokes Amazon Bedrock.
A simplified Python implementation looks like this:
import json
import boto3

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

def lambda_handler(event, context):

record = event["Records"][0]

bucket = record["s3"]["bucket"]["name"]
key = record["s3"]["object"]["key"]

response = s3.get_object(
Bucket=bucket,
Key=key
)

document = response["Body"].read().decode("utf-8")

prompt = f"""
Summarize the following document.

Provide:
1. A short summary
2. The key points
3. Important action items

Document:
{document}
"""

# Invoke your selected Amazon Bedrock model here.
# The request format depends on the selected model.

return {
"statusCode": 200,
"document": key
}

The exact Bedrock request format depends on the foundation model selected for the application.
Step 3: Configure the S3 event
Next, configure Amazon S3 to invoke the Lambda function when a new object is created.
The resulting workflow is:
S3 ObjectCreated
|
v
AWS Lambda
|
v
Amazon Bedrock

This removes the need for the application to continuously check S3 for new files.
Event-driven processing is especially useful when documents arrive at unpredictable times.
Step 4: Invoke Amazon Bedrock
Amazon Bedrock provides API access to foundation models without requiring you to manage the underlying model infrastructure.
The Lambda function can send a prompt containing the document text.
For example:
Analyze the document below.

Return:
- A concise summary
- Five key points
- Important action items

Document:
<document content>

The application can request a structured response so that it is easier to store and consume.
For example:
{
"summary": "The report describes the project's progress.",
"key_points": [
"Project milestones are on schedule",
"Operating costs decreased",
"The next phase starts next month"
],
"action_items": [
"Review the project schedule",
"Prepare the next phase plan"
]
}

Step 5: Store the result in DynamoDB
Amazon DynamoDB can store the generated summaries.
Create a table such as:
Table name: DocumentSummaries
Partition key: document_id

Lambda can then store the result:
dynamodb = boto3.resource("dynamodb")

table = dynamodb.Table("DocumentSummaries")

table.put_item(
Item={
"document_id": key,
"summary": summary,
"status": "COMPLETED"
}
)

The application can now retrieve a document's summary without processing the original document again.
Processing large documents
Large documents require additional consideration.
Sending an entire document in a single model request may not be appropriate. Instead, the application can extract the text and divide it into smaller chunks.
The workflow becomes:
Large Document
|
v
Text Extraction
|
v
Document Chunking
|
+---- Chunk 1 → Bedrock
+---- Chunk 2 → Bedrock
+---- Chunk 3 → Bedrock
|
v
Combine Results
|
v
Final Summary

This approach can also be used to build more advanced document-analysis applications.
For PDF documents or scanned images, additional AWS services may be introduced to extract text before sending the content to the foundation model.
Making the application reliable
A production application should account for failures and duplicate events.
Handle retries
Transient failures can occur when calling external services. Configure appropriate retry behavior and avoid creating duplicate records during retries.
Use idempotency
S3 events can potentially be delivered more than once. The application should therefore be designed so that processing the same document multiple times does not create inconsistent results.
A deterministic document ID stored in DynamoDB can help with this.
Monitor the application
Amazon CloudWatch can be used to monitor:
Lambda invocations
Lambda errors
Execution duration
Throttling
Application logs
Monitoring helps identify problems quickly and provides visibility into the processing pipeline.
Security best practices
Security should be part of the design from the beginning.
The Lambda execution role should use least-privilege permissions. For example, the function may require permissions to:
s3:GetObject
bedrock:InvokeModel
dynamodb:PutItem

Avoid giving the Lambda function broad permissions that it does not require.
Additional recommendations include:
Keep S3 buckets private.
Enable encryption for stored data.
Use IAM roles instead of hard-coded credentials.
Avoid logging sensitive document contents.
Restrict access to DynamoDB data.
Separate development and production resources.
Cost optimization
Serverless architectures can help reduce infrastructure management overhead because you don't need to maintain continuously running application servers.
However, AI workloads introduce additional costs based on model usage and the amount of data processed.
You can improve cost efficiency by:
Processing only the required document content.
Avoiding unnecessary repeated model calls.
Selecting an appropriate foundation model.
Controlling document chunk sizes.
Configuring S3 lifecycle policies.
Monitoring Lambda and Bedrock usage.
CloudWatch metrics and AWS billing tools can help identify unexpected increases in usage.
Extending the solution
The basic architecture can be extended into a more complete AI document-processing platform.
For example, you could add:
Automatic document classification
Invoice information extraction
Contract analysis
Meeting summarization
Document tagging
Question answering
Retrieval-augmented generation (RAG)
Semantic search
Human approval workflows
AWS Step Functions can also be introduced when the workflow contains multiple processing stages.
A more advanced architecture could look like this:
┌── Amazon Bedrock
│
Amazon S3 → Lambda ─┼── DynamoDB
│
├── CloudWatch
│
└── Step Functions

Each service has a focused responsibility, making the system easier to maintain and evolve.
Conclusion
By combining Amazon S3, AWS Lambda, Amazon Bedrock, and Amazon DynamoDB, you can build an AI-powered document summarization application using a fully managed, event-driven architecture.
The solution automatically reacts to document uploads, processes content using a foundation model, and stores the generated results for later use.
More importantly, the same architecture can serve as a foundation for many real-world AI applications, including document classification, information extraction, knowledge management, and intelligent search.
Starting with a simple serverless workflow makes it possible to experiment quickly while keeping the architecture flexible enough to grow into a production application.