AWS Builder Center

Builder Center

Building an AI-Powered Application on AWS

Building an AI-Powered Application on AWS

Explore how to build an AI-powered question-answering application on AWS using Amazon Bedrock, Retrieval-Augmented Generation (RAG), and Amazon S3. This article covers system architecture, document retrieval, foundation models, performance evaluation, cost optimization, and security best practices. Discover how to measure response latency, retrieval relevance, and application efficiency through illustrative graphs and architecture diagrams while learning to design scalable, reliable.

MADHAV SINGHAL

B.Tech CSE student specializing in Cloud Computing, AWS, Python, and automation.

Beyond Servers: Build a Scalable Serverless API with AWS Lambda and Python

Abstract

Serverless computing is changing how developers design and deploy applications by reducing the need to provision and manage servers. AWS Lambda allows developers to execute code in response to events, while services such as Amazon API Gateway provide HTTP endpoints for application clients.
This hands-on tutorial demonstrates how to build a lightweight text-analysis API using Python and AWS Lambda. It explains the serverless execution model, presents the application architecture, walks through implementation and deployment, and discusses scalability, performance measurement, reliability, and cost considerations. Illustrative graphs help explain the concepts, while a practical test demonstrates how to invoke the deployed application.

1. Introduction

Traditional application deployment often requires developers to configure servers, install runtime dependencies, manage operating systems, monitor resource utilization, and plan capacity for changing traffic.
Serverless computing shifts much of this infrastructure management to the cloud provider. Developers focus primarily on application logic and connect managed services to create a complete application.
AWS Lambda is a serverless compute service that executes code in response to events. It supports event-driven architectures in which functions can be triggered by HTTP requests, file uploads, queue messages, scheduled events, and other supported sources.
Despite the name, serverless does not mean that servers do not exist. It means that developers do not directly manage the underlying server infrastructure for the function.
This tutorial builds a simple text-analysis API that accepts text and returns the number of words, characters, and uppercase characters. Although the example is intentionally small, the same architecture can support data validation, lightweight transformations, webhook processing, and other request-driven tasks.

2. Understanding the Serverless Architecture

A typical request-driven serverless application contains three main components:
Amazon API Gateway: Receives HTTP requests and forwards them to the configured backend.
AWS Lambda: Executes the Python function that processes the request.
Client application: Sends JSON input and receives the JSON response.
For this tutorial, the application does not require a database. This keeps the implementation focused on the request-response workflow.

Figure 1. Architecture of the text-analysis API

The request travels from the client through API Gateway to Lambda. The function validates the input, performs the text analysis, and returns a response through the API.
The separation between the API layer and the compute layer makes it easier to modify the application logic without managing a persistent web server.

3. Building the Python Lambda Function

Step 1: Create the function

Sign in to the AWS Management Console and open AWS Lambda.
  1. Select Create function.
  2. Choose Author from scratch.
  3. Enter TextAnalyzerAPI as the function name.
  4. Select a currently supported Python runtime.
  5. Create or select an execution role with the basic permissions required to write logs to Amazon CloudWatch Logs.
  6. Create the function.
The execution role allows Lambda to access the AWS resources required by the function. For this initial example, the function does not need access to S3, DynamoDB, or other application data services.

Step 2: Add the Python code

Open the function's code editor and replace the sample code with the following implementation. Keep the handler name as lambda_function.lambda_handler if the file is named lambda_function.py.
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
import json

def lambda_handler(event, context):
try:
body = event.get("body")

# Support direct Lambda test events and API requests.
if isinstance(body, str):
body = json.loads(body)
elif body is None:
body = event

if not isinstance(body, dict):
raise ValueError("Request body must be a JSON object")

text = body.get("text")

if not isinstance(text, str) or not text.strip():
return {
"statusCode": 400,
"headers": {
"Content-Type": "application/json"
},
"body": json.dumps({
"error": "Please provide non-empty text."
})
}

result = {
"word_count": len(text.split()),
"character_count": len(text),
"uppercase_count": sum(
1 for character in text
if character.isupper()
)
}

return {
"statusCode": 200,
"headers": {
"Content-Type": "application/json"
},
"body": json.dumps(result)
}

except (ValueError, json.JSONDecodeError):
return {
"statusCode": 400,
"headers": {
"Content-Type": "application/json"
},
"body": json.dumps({
"error": "Invalid JSON request."
})
}

Step 3: Understand the handler

The lambda_handler function is the entry point invoked by the Lambda runtime.
  • event contains the input supplied by the invoking service.
  • context provides invocation and execution-environment information.
  • The function validates the request before processing it.
  • The result is converted into JSON for the caller.
The implementation also handles an empty text field and malformed JSON. Input validation is important because an API should return a controlled error instead of failing unexpectedly when a client sends invalid data.
The handler is deliberately stateless: it does not rely on a previous invocation having stored information in memory. This makes the example easier to scale and test.

4. Testing the Function

Step 1: Create a test event

In the Lambda console, create a test event using this JSON:
1
2
3
{
"body": "{\"text\":\"AWS Lambda makes cloud development easier\"}"
}
Save the event and select Test.
For this input, the expected response body is:
1
2
3
4
5
{
"word_count": 7,
"character_count": 44,
"uppercase_count": 5
}
The word count, character count, and uppercase count are deterministic for the supplied input. The example does not require an external dataset or machine-learning model.

Step 2: Interpret the response

A successful invocation should return HTTP status code 200 in the Lambda response object, along with the calculated statistics. An empty or invalid text request should produce a 400 response.
Testing in the Lambda console verifies the function's basic logic. The next step exposes the function through an HTTP endpoint.

5. Exposing the Function Through Amazon API Gateway

Step 1: Create an HTTP API

Open Amazon API Gateway and create an HTTP API.
  1. Add an integration with the TextAnalyzerAPI Lambda function.
  2. Configure a POST route at /analyze.
  3. Ensure the integration is associated with the intended AWS Region and function.
  4. Configure a deployment stage.
  5. Deploy the API and copy its invoke URL.
Follow the console's current integration and permission workflow so that API Gateway is authorized to invoke the function.

Step 2: Send a request

Use a terminal with curl, replacing the placeholder with your deployed API's URL:
1
2
3
4
curl -X POST \
"https://YOUR_API_ID.execute-api.YOUR_REGION.amazonaws.com/analyze" \
-H "Content-Type: application/json" \
-d '{"text":"AWS Lambda makes cloud development easier"}'
A successful response should resemble:
1
2
3
4
5
{
"word_count": 7,
"character_count": 44,
"uppercase_count": 5
}
The exact endpoint depends on the API and stage configuration. If the API uses a named stage in its invoke URL, include that stage before /analyze.

Step 3: Verify errors and logs

Send an empty text value and confirm that the application returns a controlled client error.
Then open the function's monitoring section and inspect the associated CloudWatch Logs to review invocation details and any runtime errors. Avoid logging sensitive request bodies in production applications.

6. Understanding Event-Driven Serverless Computing

HTTP requests are only one way to invoke Lambda. AWS also supports event-driven patterns that connect services without requiring a continuously running application server.
For example, an S3-triggered workflow can process a file immediately after it is uploaded. An SQS-based workflow can process queued messages, while EventBridge can route supported application events to functions.

Figure 2. Event-driven file-processing workflow

  1. A user uploads a file to an input S3 bucket.
  2. The S3 event invokes a Lambda function.
  3. The function validates or transforms the file.
  4. The processed result is stored in a separate output location.
  5. CloudWatch metrics and logs help operators monitor the workflow.
Using separate input and output buckets can help prevent recursive invocation loops. If the same bucket is used for both input and output, configure event notifications carefully so that writing the output does not trigger the function indefinitely.
For workflows involving retries, queues, or multiple dependent tasks, design explicit error handling and consider services such as Amazon SQS or AWS Step Functions.

7. Scalability and Performance

One major advantage of Lambda is that AWS manages the execution infrastructure and scales function execution according to demand, subject to applicable concurrency quotas and configuration limits.
However, automatic scaling does not mean every request has identical latency. Execution time can vary with the function's memory allocation, initialization work, dependencies, downstream service latency, request size, and concurrency.
Cold starts may add initialization latency when an execution environment needs to be prepared. Provisioned concurrency can help reduce startup latency for supported workloads, but it adds cost and should be evaluated against actual requirements.

Figure 3. Illustrative relationship between request load and active executions

The graph below uses hypothetical values to demonstrate how a serverless workload might scale. It is not a benchmark or a prediction of AWS performance.

8. Measuring Application Performance

For a meaningful experiment, generate a controlled set of requests and record:
  • Request count and successful responses.
  • End-to-end latency, including median and tail percentiles.
  • Lambda duration and errors.
  • Throttles and concurrent executions.
  • Memory configuration and any initialization overhead.
  • Cost under the tested workload.
Use the same request payloads and test conditions when comparing different configurations. Record the AWS Region, runtime, memory allocation, test duration, and concurrency settings so that another developer can reproduce the experiment.

Figure 4. Example performance comparison

A second graph can compare the median and 95th-percentile latency measured under two or more test configurations. Populate the graph with actual results from your deployed function. If no experiment has been run, label all values as illustrative rather than presenting them as measured findings.

9. Cost Considerations

AWS Lambda function pricing generally depends on the number of requests and execution duration, with duration charges influenced by allocated memory. Additional services, such as API Gateway, CloudWatch Logs, S3, and data transfer, may incur separate charges.
The most suitable design depends on the workload. Lambda can be attractive for event-driven tasks and variable traffic, but it is not automatically the cheapest option for every continuously running or compute-intensive application.
To understand the cost of this tutorial:
  1. Measure average execution duration.
  2. Record the configured memory allocation.
  3. Estimate monthly request volume.
  4. Include the cost of API Gateway and supporting services.
  5. Check current regional pricing and applicable free-tier allowances.
  6. Review actual usage in AWS billing tools.
Avoid estimating total application cost using Lambda charges alone when other AWS services are part of the request path.

10. Reliability and Production Readiness

A small demonstration can be useful without being production-ready. Before deploying a serverless API for real users, consider:
  • Request validation and reasonable payload-size limits.
  • Authentication and authorization requirements.
  • Least-privilege execution roles.
  • Structured logging and meaningful metrics.
  • Throttling and concurrency limits.
  • Appropriate timeout settings.
  • Retry behavior and duplicate-event handling.
  • Safe handling of sensitive information.
  • Automated tests and deployment versioning.
For asynchronous event processing, make functions idempotent where possible so that duplicate deliveries do not create duplicate side effects. For more complex workflows, use a suitable queue or orchestration service rather than placing every operation in a single function.

11. Conclusion

AWS Lambda enables developers to build event-driven applications without managing the underlying compute servers. When combined with Amazon API Gateway, it provides a practical foundation for HTTP APIs, while integrations with S3, SQS, and other AWS services enable additional event-driven workflows.
In this tutorial, we built a Python text-analysis function, tested its input and output, and described how to expose it through an HTTP endpoint. We also explored performance evaluation, scaling behavior, cost considerations, and production-readiness requirements.
The most important lesson is that serverless computing is an architectural approach, not simply a way to run code. Successful implementations combine small, well-defined functions with thoughtful event handling, observability, testing, and cost management.

References

  1. AWS Lambda Developer Guide: https://docs.aws.amazon.com/lambda/latest/dg/welcome.html 
  2. Define a Lambda function handler in Python: https://docs.aws.amazon.com/lambda/latest/dg/python-handler.html 
  3. Creating event-driven architectures with Lambda: https://docs.aws.amazon.com/lambda/latest/dg/concepts-event-driven-architectures.html 
  4. Designing Lambda applications: https://docs.aws.amazon.com/lambda/latest/dg/concepts-application-design.html 
  5. Amazon API Gateway documentation: https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html 
  6. AWS Lambda pricing: https://aws.amazon.com/lambda/pricing/ 
# serverless
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article