> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Exposing Your Bedrock App Using API Gateway Part 1
> Shows how to build a serverless event driven pipeline using S3, Lambda, and Amazon Bedrock to automatically process incoming data with generative AI and store results
In this lesson you’ll learn how to integrate Amazon Bedrock with AWS Lambda so generative AI tasks run automatically whenever new data arrives. This serverless, event-driven approach makes real-time processing scalable, resilient, and cost-effective.
Lesson outline:
* Define the real-world problem: inefficient handling of real-time data.
* Present a serverless, event-driven solution using Lambda and Bedrock.
* Walk through the implementation workflow and sample code.
* Explain expected results, benefits, and operational considerations.
* Provide next steps for a hands-on implementation.
Let’s start with the real-world problem.
When new data assets arrive in a storage service, you often want to react automatically. New data can come from IoT devices, batch processes, customer uploads, reviews, or surveys, and it frequently arrives in unpredictable bursts. A manual flow—notify a person (email), have them trigger an AI workflow, then wait for results—is slow, inconsistent, and hard to scale because it depends on human intervention.
Event-driven serverless processing
An event-driven pattern removes manual steps by automatically running compute when an event occurs. In this lesson we use AWS Lambda together with Amazon Bedrock to process new objects as they arrive.
AWS Lambda is a managed, ephemeral compute environment that runs your code in response to events. Typical invocations are short (seconds), and Lambda scales automatically to match load, making it ideal for per-event processing. From inside Lambda you can use the AWS SDKs to call other AWS services—Amazon Bedrock included—without embedding static credentials.
Typical workflow (S3 → Lambda → Bedrock → S3)
1. A file or object is uploaded to Amazon S3.
2. S3 emits an "Object Created" event.
3. The event triggers a Lambda function via S3 Event Notification.
4. The Lambda handler parses the event, reads the object, and constructs a Bedrock input (prompt).
5. Lambda invokes the Bedrock runtime to run a model (summarization, Q\&A, sentiment, etc.).
6. The model response is saved back to S3 for downstream use.
Visual summary of the flow:
How S3 event notifications work
Amazon S3 supports Event Notifications for buckets. You can configure notifications on events such as "ObjectCreated" and optionally filter by prefix or suffix to limit which objects trigger the event. S3 then delivers an event record to a destination such as Lambda, SNS, or SQS.
In this lesson we configure S3 to send all "Object Created" events to a Lambda function (no prefix/suffix filters), so any object creation in the bucket will trigger the function.
Selecting the destination: Lambda
When creating the S3 event subscription you must choose a destination. Select the intended Lambda function (for example, `bedrock-summarize`). Every new object that matches the notification pattern will be delivered to that Lambda function for processing.
Inside the Lambda function
A Lambda function has an entry point called the handler. When S3 invokes Lambda, the handler receives an `event` parameter: a JSON payload describing what caused the invocation (including the S3 bucket and object key). Typical handler logic:
* Parse the event to extract S3 bucket and object key.
* Read the object from S3 and build the Bedrock prompt or input.
* Call the Bedrock runtime to run a model.
* Persist the model output back to S3 (or another storage destination).
Example Python Lambda handler that implements those steps:
```python theme={null}
# lambda_function.py
import json
import boto3
s3 = boto3.client("s3")
bedrock = boto3.client("bedrock-runtime") # Bedrock runtime client
MODEL_ID = "your-model-id-or-name" # Replace with your model identifier
def lambda_handler(event, context):
# S3 event can contain multiple Records
for record in event.get("Records", []):
bucket = record["s3"]["bucket"]["name"]
key = record["s3"]["object"]["key"]
# Read the uploaded object
obj = s3.get_object(Bucket=bucket, Key=key)
body_bytes = obj["Body"].read()
text_input = body_bytes.decode("utf-8")
# Prepare and call Bedrock to process the text
response = bedrock.invoke_model(
modelId=MODEL_ID,
contentType="text/plain",
accept="application/json",
body=text_input.encode("utf-8")
)
# Read model output from the streaming body
model_output = response["body"].read().decode("utf-8")
# Save the generated response back to S3 (e.g., in an outputs/ folder)
output_key = f"outputs/{key}.json"
s3.put_object(Bucket=bucket, Key=output_key, Body=model_output.encode("utf-8"))
return {"status": "processed", "records": len(event.get("Records", []))}
```
Example S3 event payload (sent to Lambda):
```json theme={null}
{
"Records": [
{
"eventName": "ObjectCreated:Put",
"s3": {
"bucket": { "name": "example-bucket" },
"object": { "key": "uploads/document1.txt" }
}
}
]
}
```
Permissions and IAM roles
Lambda functions assume an IAM execution role that grants the permissions they need. Instead of embedding credentials in your code, attach a role with minimal privileges for the function to operate.
Common permissions to grant the Lambda execution role:
| Action | Purpose | Example IAM permission |
| - | - | - |
| Read source objects | Download newly uploaded objects from the source bucket | `s3:GetObject` |
| Write outputs | Save generated responses to a destination bucket or prefix | `s3:PutObject` |
| Call Bedrock | Allow the function to invoke the Bedrock runtime API | `bedrock:InvokeModel` |
| (optional) CloudWatch Logs | Enable logging for debugging and observability | `logs:CreateLogGroup`, `logs:CreateLogStream`, `logs:PutLogEvents` |
Use least-privilege policies and restrict the role to specific buckets and prefixes where possible.
Use the Lambda execution role for all service access. Avoid embedding AWS credentials in your function code. For configuration values (model ID, output prefix, etc.), prefer Lambda environment variables or AWS Systems Manager Parameter Store / Secrets Manager.
Lambda console and function configuration
In the Lambda console you choose:
* Runtime (Python, Node.js, etc.).
* Handler name (the entry point function).
* Memory and timeout settings (default timeout is 3 seconds; configure up to 15 minutes if required).
* Execution role (attach the IAM role discussed above).
* Optionally, environment variables and layers.
When an S3 event triggers the function, Lambda injects the event JSON into your handler so your code can process it immediately.
Expected results and business benefits
This serverless pattern yields clear operational and business advantages:
| Benefit | Description |
| - | - |
| Real-time processing | Trigger AI workflows immediately on data arrival instead of batch windows. |
| Scalability | Lambda auto-scales to handle spikes; no need to provision servers. |
| Cost efficiency | Pay only for execution time when events occur. |
| Modularity | Small Lambda functions can focus on single responsibilities (summarize, sentiment, index). |
| Integration | Same pattern works with other AWS event sources (API Gateway, SQS, SNS, DynamoDB Streams, etc.). |
This pattern is flexible: substitute S3 with other event sources (SNS, SQS messages, DynamoDB streams), and adapt model calls to use classification, summarization, or generation as required.
Security and operational considerations
* Monitor execution times and error counts in CloudWatch. Configure retries and dead-letter queues (DLQ) for failed events.
* Use IAM policies scoped to required resources and restrict Bedrock access to necessary models.
* If model responses contain PII, ensure proper encryption at rest and access controls for output storage.
* For heavy workloads or long-running tasks, consider asynchronous patterns (queueing with SQS + FIFO) to smooth spikes.
Make sure your Lambda role has explicit permissions for Bedrock and S3 operations. Missing permissions cause invocation errors and retries. Also be mindful of regional endpoints for Bedrock—deploy and call Bedrock in the supported AWS regions for your account.
Key takeaway
Using Lambda with Amazon Bedrock enables automated, event-driven AI processing for incoming data. The S3 "object created" pattern is a common example, but the same architecture applies across many AWS event sources to deliver scalable, near-real-time generative AI workflows.
Next steps (hands-on lab)
1. Create an S3 bucket and enable "Object Created" event notifications.
2. Implement the Lambda handler (sample shown above) and set `MODEL_ID`.
3. Create an IAM execution role scoped to required S3 and Bedrock permissions.
4. Attach the role to the Lambda function and configure environment variables for model and output prefix.
5. Upload files to S3 and validate outputs appear in your `outputs/` prefix.
6. Monitor CloudWatch logs and refine error handling, concurrency limits, and retries.
Links and references
* [Amazon Bedrock Documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html)
* [AWS Lambda Developer Guide](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
* [S3 Event Notifications](https://docs.aws.amazon.com/AmazonS3/latest/userguide/NotificationHowTo.html)
* [IAM Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
Good luck implementing your event-driven Bedrock workflows!
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.