AWS Builder Center

Builder Center

Building a Serverless API with Amazon API Gateway and AWS Lambda

A practical beginner-friendly walkthrough of building a serverless API using Amazon API Gateway and AWS Lambda, including request handling, deployment, testing, and understanding how the services work together.

When I started exploring AWS serverless services, two services that stood out were AWS Lambda and Amazon API Gateway.
Individually, they are useful services, but combining them makes it possible to build an API without managing servers.
In this article, I’ll walk through the basic concepts I explored and how Lambda and API Gateway work together to create a simple serverless application.

Why Serverless?

In a traditional application, we might need to manage:
  • Virtual machines
  • Operating systems
  • Application servers
  • Scaling
  • Infrastructure configuration
  • Server availability
With a serverless architecture, much of this infrastructure management is handled by AWS.
For a simple API, the architecture can look like this:
1
2
3
4
5
6
7
8
9
10
Client
|
v
API Gateway
|
v
AWS Lambda
|
v
Application Logic
The client sends a request to API Gateway, which invokes the Lambda function containing our application logic.

1. Creating an AWS Lambda Function

The first service I explored was AWS Lambda.
Lambda allows us to run code without managing the underlying servers.
For example, a simple Python Lambda function can look like:
1
def lambda_handler(event, context): return { "statusCode": 200, "body": "Hello from AWS Lambda!" }
The function receives an event containing information about the request and a context object containing information about the Lambda execution environment.
I found this model useful because I could focus on the application logic rather than configuring a server.

2. Understanding the Lambda Execution Model

A Lambda function is invoked when something triggers it.
For an API-based application, the flow is:
1
2
3
4
5
6
7
8
9
10
11
12
13
HTTP Request
|
v
API Gateway
|
v
Lambda Invocation
|
v
Python Function
|
v
HTTP Response
Lambda executes the function and returns the result to the service that invoked it.

3. Adding Amazon API Gateway

Lambda by itself doesn't provide the complete API experience that a web application usually needs.
This is where Amazon API Gateway comes in.
API Gateway can receive HTTP requests and route them to backend services such as Lambda.
For example:
1
2
3
4
5
6
7
8
9
10
GET /hello
|
v
API Gateway
|
v
Lambda
|
v
"Hello from AWS Lambda!"
This allows the Lambda function to act as the backend for an HTTP API.

4. Creating an API Route

I created a simple route:
1
GET /hello
The route is connected to the Lambda function.
When a client sends:
1
GET /hello
API Gateway receives the request and invokes the corresponding Lambda function.
The response can then be returned to the client as an HTTP response.

5. Understanding the Event

One useful part of working with Lambda behind API Gateway is understanding the event object.
The Lambda function can receive information such as:
1
def lambda_handler(event, context): print(event) return { "statusCode": 200, "body": "Request received" }
Inspecting the event helped me understand how information moves from the HTTP request into the application code.

6. Testing the API

Once the API route was configured, I could test it by sending an HTTP request.
The overall flow becomes:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Client
|
| HTTP Request
v
API Gateway
|
| Invoke
v
Lambda
|
| Execute
v
Application Logic
|
| Response
v
API Gateway
|
v
Client
This was the point where the individual AWS services started making sense as part of an actual application architecture.

7. Why Lambda + API Gateway Is Useful

This combination can be useful for applications such as:
  • REST APIs
  • Backend endpoints
  • Webhooks
  • Lightweight microservices
  • Event-driven applications
  • Serverless applications
For small APIs, it can provide a relatively simple way to build and expose backend functionality without maintaining traditional application servers.

8. What I Learned

The biggest takeaway for me was understanding the separation of responsibilities.
API Gateway handles the API layer.
Lambda handles the application logic.
Together:
1
2
3
4
5
6
7
8
9
10
11
12
Serverless API

Client
|
v
 Amazon API Gateway
|
v
 AWS Lambda
|
v
 Application Logic
Understanding this basic architecture makes it easier to explore more AWS services and more complex serverless applications.

What's Next?

After understanding the basic API, the next areas I would explore are:
  • Connecting Lambda to Amazon DynamoDB
  • Environment variables
  • IAM permissions
  • API authentication
  • Lambda layers
  • CloudWatch logging
  • Error handling
  • API monitoring
  • Infrastructure as Code
Starting with a simple API helped me understand how individual AWS services can be combined to build a complete application without managing traditional servers.
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