AWS Builder Center

Builder Center

Building a Scalable Serverless API with Amazon API Gateway and AWS Lambda

Serverless architectures make it possible to build and deploy APIs without managing servers, operating systems, or traditional application infrastructure. In this article, we’ll explore how Amazon API Gateway and AWS Lambda can be combined to create a simple, scalable HTTP API.

Why serverless?

In a traditional application, you typically need to provision compute resources, configure networking, manage operating systems, and plan capacity. Serverless services shift much of that operational responsibility to AWS.
With a serverless API:
  • Amazon API Gateway handles HTTP requests and API routing.
  • AWS Lambda runs application code in response to requests.
  • Infrastructure can scale automatically with demand.
  • You pay based largely on usage rather than continuously running servers.
This makes the architecture particularly useful for APIs with variable or unpredictable traffic.

Architecture

A basic request flow looks like this:
1
2
3
4
5
6
7
8
9
10
Client
|
v
Amazon API Gateway
|
v
AWS Lambda
|
v
Application logic
For a production application, Lambda can also interact with services such as Amazon DynamoDB, Amazon S3, Amazon SQS, or Amazon EventBridge.

Step 1: Create the Lambda function

Start by creating a Lambda function using your preferred runtime.
For example, a Python Lambda handler can return a simple JSON response:
1
2
3
4
5
6
7
8
9
10
11
12
import json

def lambda_handler(event, context):
return {
"statusCode": 200,
"headers": {
"Content-Type": "application/json"
},
"body": json.dumps({
"message": "Hello from AWS Lambda!"
})
}
The function receives an event from the API layer and returns an HTTP-compatible response.

Step 2: Create the API

Next, create an API in Amazon API Gateway and configure a route such as:
1
GET /hello
Connect this route to the Lambda function.
When a client sends:
1
GET /hello
API Gateway invokes Lambda, which executes the application logic and returns the response.

Step 3: Test the API

After deploying the API, you can test the endpoint with a browser, curl, or an API client.
For example:
1
curl https://your-api-endpoint.example.com/hello
A successful request should return JSON similar to:
1
2
3
{
"message": "Hello from AWS Lambda!"
}

Handling application data

A real API usually needs persistent storage. Instead of maintaining a database server yourself, you can use managed AWS services.
For example, a serverless application could use:
1
2
3
4
5
6
7
8
9
10
11
12
13
Client
|
v
API Gateway
|
v
Lambda
|
+----> Amazon DynamoDB
|
+----> Amazon S3
|
+----> Amazon SQS
Lambda can read or write data in DynamoDB, store files in S3, or send asynchronous messages through SQS.
This allows each component to scale independently and keeps the application loosely coupled.

Security considerations

A publicly accessible API should not rely only on application code for security.
Depending on the use case, consider:
  • Authentication and authorization
  • AWS Identity and Access Management (IAM)
  • Amazon Cognito for user authentication
  • API throttling
  • Input validation
  • Least-privilege IAM policies
  • Encryption in transit and at rest
  • Logging and monitoring with Amazon CloudWatch
Avoid granting a Lambda function more AWS permissions than it actually needs.
For example, if a function only needs to read from one DynamoDB table, its IAM policy should not grant unrestricted access to every DynamoDB resource.

Observability

Serverless does not eliminate the need for monitoring.
Amazon CloudWatch can help you monitor Lambda invocations, errors, duration, and logs. API Gateway also provides metrics that can help identify failed requests and traffic patterns.
A useful production setup should make it easy to answer questions such as:
  • How many requests are failing?
  • Which endpoints are slow?
  • Is Lambda experiencing errors?
  • How much traffic is the API receiving?
  • Are downstream services becoming bottlenecks?
Good observability makes troubleshooting significantly easier.

When should you use this architecture?

API Gateway and Lambda are a strong choice for applications such as:
  • REST and HTTP APIs
  • Webhooks
  • Lightweight backend services
  • Event-driven applications
  • Mobile and web application backends
  • Automation endpoints
  • APIs with unpredictable traffic
However, serverless is not automatically the best choice for every workload. Long-running processes, highly specialized networking requirements, or workloads that require persistent connections may be better suited to other AWS compute options.

Final thoughts

Amazon API Gateway and AWS Lambda provide a powerful foundation for building APIs without managing traditional servers. By combining them with managed services such as DynamoDB, S3, SQS, and CloudWatch, you can create applications that are scalable, modular, and easier to operate.
The most important step is not simply moving an existing application to Lambda. Instead, think about how the application can take advantage of event-driven execution, managed services, automatic scaling, and loosely coupled components.
That shift in architecture is where serverless becomes particularly powerful.
# aws-lambda# api-gateway# api
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