From API to AI: Building a Serverless AI Assistant with Amazon Bedrock and AWS Lambda
Learn how to build a serverless AI assistant by integrating Amazon Bedrock, AWS Lambda, and Amazon API Gateway. This hands-on guide covers architecture, implementation, security, error handling, and cost optimization.
From API to AI: Building a Serverless AI Assistant with Amazon Bedrock and AWS Lambda
Introduction
Artificial intelligence is becoming an important part of modern applications, from intelligent chatbots to document assistants and automated support systems. However, building an AI-powered application involves more than connecting to a language model. Developers also need to handle API requests, security, scalability, error handling, and infrastructure costs.
In this article, we will explore how to design a serverless AI assistant using Amazon Bedrock, AWS Lambda, and Amazon API Gateway.
The goal is to understand how these AWS services work together to create an application that accepts a user's question, sends it to an AI model, and returns a useful response without requiring us to manage application servers.
1. Understanding the Architecture
Our application will use the following request flow:
User → Amazon API Gateway → AWS Lambda → Amazon Bedrock → AWS Lambda → API Gateway → User
Each component has a specific responsibility.
Amazon API Gateway
Amazon API Gateway provides an HTTP endpoint through which the frontend or another application can communicate with our backend.
It receives the user's request and forwards it to the appropriate Lambda function.
AWS Lambda
AWS Lambda runs our Python code without requiring us to provision or manage servers.
The Lambda function validates the incoming request, prepares the prompt, invokes Amazon Bedrock, and returns the result.
Amazon Bedrock
Amazon Bedrock provides access to supported foundation models through AWS APIs. We can use it to generate responses, summarize content, answer questions, and build other generative AI experiences.
The exact model available depends on the AWS Region, model access, and account configuration.
IAM
AWS Identity and Access Management (IAM) controls which AWS resources our application can access. We will use an execution role that grants the Lambda function permission to invoke only the required Bedrock model.
2. How the Request Flows
Suppose a user asks:
"What is serverless computing, and why is it useful?"
The application follows these steps:
- The frontend sends a JSON request to the API endpoint.
- API Gateway forwards the request to Lambda.
- Lambda validates the input and constructs a prompt.
- Lambda invokes the configured foundation model through Amazon Bedrock.
- The model generates a response.
- Lambda formats the result as JSON.
- API Gateway returns the response to the caller.
This separation makes the architecture easier to understand, test, and extend.
3. Implementing the Lambda Function
We can implement the backend using Python and the AWS SDK for Python, also known as Boto3.
The following example demonstrates the core request flow. Before using it, configure a supported Amazon Bedrock model ID, grant the Lambda execution role the necessary permissions, and ensure the model is available in the selected Region.
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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
import json
import os
import boto3
bedrock = boto3.client(
"bedrock-runtime",
region_name=os.environ.get("AWS_REGION", "us-east-1")
)
MODEL_ID = os.environ["BEDROCK_MODEL_ID"]
def lambda_handler(event, context):
try:
body = event.get("body", {})
if isinstance(body, str):
body = json.loads(body)
question = body.get("question", "").strip()
if not question:
return response(
400,
{"error": "Please provide a question."}
)
if len(question) > 4000:
return response(
400,
{"error": "Question is too long."}
)
result = bedrock.converse(
modelId=MODEL_ID,
messages=[
{
"role": "user",
"content": [
{"text": question}
]
}
],
inferenceConfig={
"maxTokens": 500,
"temperature": 0.3
}
)
answer = "".join(
item.get("text", "")
for item in result["output"]["message"]["content"]
if "text" in item
)
return response(200, {"answer": answer})
except Exception:
print("Request failed while processing the AI response.")
return response(
500,
{"error": "Unable to process your request right now."}
)
def response(status_code, payload):
return {
"statusCode": status_code,
"headers": {
"Content-Type": "application/json"
},
"body": json.dumps(payload)
}Understanding the Code
1. Creating the Bedrock client
Boto3 allows our Python function to communicate with AWS services. The client uses the configured AWS Region.
2. Reading the request
The function extracts the
question field from the incoming JSON body and checks whether it is empty or exceeds the configured length limit.3. Calling the model
The Bedrock Converse API provides a consistent interface for supported conversational models. The model ID is supplied through an environment variable instead of being hardcoded.
4. Returning the response
The function returns a JSON response containing the generated answer. The response format shown is suitable for a Lambda proxy integration with API Gateway.
5. Handling errors
The example returns a generic error message to the caller instead of exposing internal exception details. In production, errors should also be logged with appropriate context, while avoiding sensitive information.
This is a minimal demonstration. Production implementations should distinguish validation errors, throttling, timeouts, model-access failures, and other service errors. They should also use appropriate retry and timeout policies.
4. Configuring the AWS Resources
To run the example, configure the following resources:
Step 1: Configure Amazon Bedrock
Choose a supported foundation model in your AWS Region. Verify that the model is available to your account and that your intended API operation is supported.
Set the
BEDROCK_MODEL_ID Lambda environment variable to the selected model ID.Step 2: Create the Lambda Function
Create a Python Lambda function and add the handler code.
Use a runtime supported by your AWS environment. Boto3 is available in Lambda runtimes, but production deployments should package and test dependencies appropriately when specific versions are required.
Step 3: Configure IAM Permissions
Attach an execution role to the Lambda function.
Grant the role the required
bedrock:InvokeModel permission for the selected model resource. Review the model's authorization requirements and use least-privilege access rather than granting broad permissions.Never place AWS access keys directly in the source code.
Step 4: Create the API Gateway Endpoint
Create an HTTP API in Amazon API Gateway and configure a Lambda integration.
Configure a route such as
POST /ask and connect it to the Lambda function.Test the integration with a JSON request:
1
2
3
{
"question": "Explain serverless computing in simple terms."
}The expected response has this general structure:
1
2
3
{
"answer": "Serverless computing lets developers run application code without managing the underlying servers..."
}The exact answer will depend on the selected model.
5. Security Considerations
AI applications need the same security discipline as other backend services, along with additional controls for model usage.
Important practices include:
- Use IAM roles instead of long-lived access keys.
- Validate and limit incoming request sizes.
- Apply authentication and authorization where required.
- Configure throttling and request quotas.
- Avoid logging sensitive prompts or personal information unnecessarily.
- Restrict model permissions to the resources the application actually needs.
- Monitor unexpected request volume and model usage.
- Treat user-provided text as untrusted input.
Prompt injection is another consideration. A user may attempt to manipulate a model into ignoring application instructions or revealing sensitive information. Input validation helps protect the API, but it is not a complete solution to prompt injection. Applications should enforce authorization and access controls outside the model and avoid giving the model unrestricted access to sensitive systems.
6. Error Handling and Reliability
A successful AI application must handle failures gracefully.
Potential failure scenarios include:
- Invalid user input.
- Missing or incorrect model configuration.
- Insufficient IAM permissions.
- Bedrock throttling.
- Model response delays.
- Temporary service errors.
The application should return appropriate HTTP status codes, set reasonable timeouts, and retry only when suitable. Retries should be bounded and designed carefully to avoid multiplying costs or duplicating operations.
For production systems, structured logs and CloudWatch metrics can help identify failures and track application behavior.
7. Cost Optimization
Serverless architecture can reduce the need to operate continuously running application servers, but it does not make an application free.
Costs may include Lambda invocations and execution duration, API Gateway requests, and Amazon Bedrock model usage. Exact pricing depends on the chosen services, model, Region, and request volume.
A few practical cost-control measures are:
- Set a reasonable maximum token output.
- Limit request size.
- Select a model appropriate for the task.
- Monitor invocation counts and model usage.
- Configure AWS Budgets and relevant alerts.
- Apply throttling to prevent accidental or abusive traffic.
- Cache responses only when doing so is appropriate for the data and use case.
A smaller model may be sufficient for simple summarization or FAQ tasks, while complex reasoning may require a more capable model. Model selection should balance quality, latency, and cost.
8. Possible Improvements
Once the basic assistant works, we can extend it with additional AWS capabilities.
Frontend integration: Build a React interface that sends questions to the API and displays the generated answers.
Amazon CloudWatch: Monitor Lambda errors, execution duration, and request volume.
Authentication: Add an appropriate identity and authorization layer before exposing the endpoint publicly.
Knowledge retrieval: Extend the application with a retrieval-augmented generation (RAG) workflow so the assistant can answer questions using an authorized document collection.
Infrastructure as Code: Use AWS SAM, AWS CDK, or AWS CloudFormation to make the deployment repeatable.
Automated testing: Test request validation, error paths, IAM permissions, and model response handling before deployment.
Each improvement should be introduced according to the application's actual requirements rather than adding services unnecessarily.
Conclusion
Combining Amazon API Gateway, AWS Lambda, and Amazon Bedrock provides a practical foundation for building serverless generative AI applications.
API Gateway manages the HTTP entry point, Lambda handles application logic, and Bedrock provides access to foundation models. IAM, validation, monitoring, and cost controls help make the application more reliable and secure.
The key lesson is that building an AI application is not just about generating a response from a model. It is about designing a complete system around that model—one that is secure, maintainable, observable, and appropriate for its intended use case.
Start with a small working implementation, test it carefully, and add complexity only when the application needs it.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article