AWS Builder Center

Builder Center

Understanding AWS Lambda: How Serverless Computing Works in Practice

Learn how AWS Lambda executes code without managing servers, understand its event-driven architecture, and build a simple serverless application using Amazon API Gateway, AWS Lambda, and Amazon CloudWatch.

SOHOM BHADURI

Bachelors in computer science and engineering

Introduction

In traditional application development, deploying code requires managing servers, configuring operating systems, handling infrastructure scaling, and monitoring resource utilization. As applications grow, these responsibilities can increase operational complexity and cost.
AWS Lambda simplifies this process by allowing developers to run code without provisioning or managing servers. It is a serverless, event-driven compute service that automatically manages the underlying infrastructure and executes functions in response to events.
Whether you are building REST APIs, processing uploaded files, automating cloud operations, or developing event-driven applications, AWS Lambda provides a flexible way to execute code while focusing on application logic rather than server management.
In this article, we will explore how AWS Lambda works, how its components interact, and how to build a simple serverless application.

1. What Is AWS Lambda?

AWS Lambda is a compute service that runs your code in response to events. You upload your code as a Lambda function, configure its runtime and permissions, and define the events that trigger its execution.
Lambda supports several programming languages and runtimes, including Python, Java, JavaScript, and others, subject to AWS's supported runtime versions.
Unlike a traditional server-based application, you do not need to maintain a dedicated server that continuously runs your application. Lambda automatically manages execution infrastructure and scales to accommodate incoming requests.
Key features include:
  • No server management: AWS manages the underlying compute infrastructure.
  • Automatic scaling: Lambda can run multiple function instances as demand increases.
  • Event-driven execution: Functions can be triggered by HTTP requests, file uploads, database events, scheduled events, and other supported sources.
  • Pay-per-use pricing: Charges are generally based on requests and execution duration, subject to the applicable pricing model and additional service costs.
  • Integration with AWS services: Lambda works with services such as Amazon S3, Amazon DynamoDB, Amazon API Gateway, Amazon EventBridge, and Amazon SQS.

2. How Does AWS Lambda Work?

The core concept behind Lambda is simple: an event triggers a function, the function executes the application logic, and the result or side effect is returned or processed by the surrounding application.
Consider an online shopping application. When a customer uploads a product image, Amazon S3 can generate an event that invokes a Lambda function. The function can resize the image and save the processed version to another S3 location.
The developer writes the processing logic, while AWS manages the compute infrastructure required to execute it.

The execution flow

  1. An event occurs: A user sends an API request, uploads a file, or triggers another supported event.
  2. The event reaches Lambda: The configured AWS service invokes the Lambda function.
  3. The execution environment is prepared: Lambda uses an execution environment with the required runtime and function code. AWS may reuse an existing environment for subsequent invocations.
  4. The function executes: The handler processes the event and performs the required operation.
  5. The result is handled: The function returns a response to a synchronous caller or completes processing for an asynchronous invocation.
  6. Monitoring information is recorded: Logs and metrics can be collected through Amazon CloudWatch.
An important detail is that Lambda does not necessarily create a completely new execution environment for every request. AWS may reuse environments, so developers should not rely on the environment being reset between invocations.

3. Understanding AWS Lambda Architecture

A common serverless architecture uses Amazon API Gateway, AWS Lambda, and a data store such as Amazon DynamoDB.
Here is how the components interact:
Client → Amazon API Gateway → AWS Lambda → Amazon DynamoDB
  • Client: Sends an HTTP request from a browser, mobile application, or another service.
  • Amazon API Gateway: Provides an HTTP API endpoint and forwards the request to Lambda.
  • AWS Lambda: Executes the business logic, validates input, and processes the request.
  • Amazon DynamoDB: Stores or retrieves application data when required.
  • Amazon CloudWatch: Collects logs, metrics, and monitoring information.
For example, when a client requests product details, API Gateway invokes a Lambda function. The function queries DynamoDB and returns the product information through API Gateway.
This architecture separates the API entry point, application logic, and data storage, making the application easier to maintain and scale independently.

4. Building Your First AWS Lambda Function

Let's create a simple Python Lambda function that receives a name and returns a personalized greeting.

Step 1: Create a Lambda function

  1. Sign in to the AWS Management Console.
  2. Open the AWS Lambda service.
  3. Choose Create function.
  4. Select Author from scratch.
  5. Enter a function name, such as hello-builder.
  6. Choose a supported Python runtime.
  7. Create the function using the default execution role, or an appropriately configured role.

Step 2: Write the function code

Replace the default code with the following Python example:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
import json

def lambda_handler(event, context):
name = event.get("name", "AWS Builder")

response = {
"message": f"Hello, {name}!",
"service": "AWS Lambda"
}

return {
"statusCode": 200,
"headers": {
"Content-Type": "application/json"
},
"body": json.dumps(response)
}
Let's understand the code:
  • lambda_handler is the entry point configured for this function.
  • event contains the input supplied by the invocation source.
  • context provides information about the current invocation and execution environment.
  • event.get() retrieves the supplied name or uses a default value.
  • The returned dictionary contains an HTTP-style status code, headers, and a JSON-formatted response body.
The response format is suitable for a typical API Gateway Lambda proxy integration. When invoking Lambda directly, the caller receives the returned object rather than an automatically generated HTTP response.

Step 3: Test the function

In the Lambda console, create a test event using the following JSON:
1
2
3
{
"name": "Cloud Developer"
}
Run the test. The function should return a response similar to:
1
2
3
4
5
6
7
{
"statusCode": 200,
"headers": {
"Content-Type": "application/json"
},
"body": "{\"message\": \"Hello, Cloud Developer!\", \"service\": \"AWS Lambda\"}"
}
Congratulations! You have executed your first Lambda function without creating or managing a server.

Step 4: Expose the function through an HTTP API

To make the function accessible through an HTTP endpoint:
  1. Open Amazon API Gateway.
  2. Create an HTTP API.
  3. Configure an AWS Lambda integration and select hello-builder.
  4. Add a route such as GET /hello.
  5. Deploy the API to a stage.
  6. Send a request to the generated endpoint and verify the response.
For a real application, ensure that the function correctly handles API Gateway's request format. You may need to extract query parameters or parse a request body instead of reading event["name"] directly.
Also, configure authentication, authorization, validation, and appropriate resource permissions before exposing an API publicly.

5. What Happens Behind the Scenes?

Several mechanisms make Lambda execution possible.

Execution environments

Lambda runs functions inside managed execution environments that provide the language runtime and function code. These environments can be reused, which can reduce initialization overhead on subsequent invocations.
This is why developers often initialize reusable clients outside the handler:
1
2
3
4
5
6
7
import boto3

s3 = boto3.client("s3")

def lambda_handler(event, context):
# Reuse the S3 client when the environment is reused.
return {"statusCode": 200}
Reusable initialization can improve performance, but your application must still handle retries and transient failures correctly.

Concurrency and scaling

Concurrency represents the number of function invocations being processed at the same time.
For example, if 100 requests arrive while earlier requests are still executing, Lambda can scale out to process multiple invocations concurrently, subject to account quotas, configured concurrency limits, and downstream service capacity.
For latency-sensitive applications, provisioned concurrency can help reduce cold-start latency by keeping execution environments initialized. It is an additional configuration with its own cost.

Cold starts

A cold start occurs when Lambda needs to initialize a new execution environment before running a function. Initialization may include starting the runtime, loading code, and executing initialization logic.
Cold starts can affect latency, particularly for functions with large dependencies or expensive initialization steps.
To reduce their impact:
  • Keep deployment packages and dependencies reasonably small.
  • Avoid unnecessary work during initialization.
  • Reuse SDK clients and database connections when appropriate.
  • Consider provisioned concurrency when predictable low latency is important.

6. Common AWS Lambda Use Cases

AWS Lambda supports a wide range of application patterns.
1. REST APIs and backend services
Use API Gateway and Lambda to create serverless API endpoints for web applications, mobile apps, and microservices.
2. File processing
Trigger a function when a file is uploaded to Amazon S3. The function can generate thumbnails, extract metadata, or validate file contents.
3. Event-driven automation
Use Amazon EventBridge to trigger scheduled tasks or respond to events, such as periodically cleaning up temporary resources.
4. Database-driven applications
Process DynamoDB Streams events to react to data changes and maintain related application state.
5. Asynchronous workloads
Integrate Lambda with Amazon SQS to process queued messages independently of the systems that generate them.
6. Data processing and AI workflows
Use Lambda to validate incoming data, coordinate processing steps, call supported AI services, or trigger longer-running workloads in other compute services. Lambda is generally best suited to bounded tasks rather than long-running GPU-intensive workloads.

7. AWS Lambda Pricing: What Should Beginners Know?

AWS Lambda follows a usage-based pricing model. Depending on the applicable pricing plan, charges can include the number of requests and the compute duration, which is influenced by the configured memory and execution time.
The AWS Free Tier or other available free-use allowances may cover eligible usage, subject to current terms and quotas.
However, Lambda is not the only possible source of cost. An application may also incur charges for:
  • Amazon API Gateway requests.
  • Amazon CloudWatch logs and monitoring.
  • Data transfer.
  • Database operations and storage.
  • NAT gateways or other networking resources, when used.
  • Provisioned concurrency, if enabled.
Before deploying an application, review the current AWS pricing pages and configure AWS Budgets or billing alerts to help monitor spending. Free-tier eligibility and allowances can change, so verify the terms that apply to your account.

8. Best Practices for Production Applications

A working Lambda function is only the beginning. Production workloads need security, reliability, observability, and efficient resource usage.
  • Follow least-privilege access: Grant the execution role only the permissions required by the function.
  • Protect sensitive information: Store secrets in an appropriate secrets-management service rather than hardcoding credentials.
  • Design for retries: Asynchronous events and event-source integrations can be retried, so make operations idempotent wherever possible.
  • Handle failures: Configure suitable error handling, timeouts, retry behavior, and dead-letter or failure destinations where supported.
  • Monitor execution: Use CloudWatch logs, metrics, and alarms to detect errors, timeouts, and performance issues.
  • Choose resources carefully: Set memory and timeout values based on measured workload requirements.
  • Test before deployment: Test normal inputs, invalid inputs, service failures, and concurrent execution scenarios.
  • Avoid unnecessary complexity: For workloads that require continuous processing, specialized hardware, or execution beyond Lambda's limits, consider other AWS compute services.
These practices help ensure that a serverless application remains secure, maintainable, and reliable as usage grows.

Conclusion

AWS Lambda changes how developers build and operate applications by allowing them to focus on code rather than managing servers. Its event-driven execution model, automatic scaling, and integration with other AWS services make it a useful building block for modern cloud applications.
By combining Lambda with Amazon API Gateway, Amazon S3, Amazon DynamoDB, and Amazon CloudWatch, developers can create flexible serverless systems for APIs, automation, and event processing.
For beginners, the best way to understand Lambda is to build a small function, test it with different events, connect it to an API endpoint, and observe its execution through CloudWatch.
As you explore serverless computing, remember that AWS Lambda is not simply a replacement for every server. It is a powerful compute option when your workload benefits from event-driven execution, managed infrastructure, and usage-based scaling.
Start small, monitor your usage, apply security best practices, and gradually build more sophisticated serverless applications.
Happy building!
# aws-api# aws-builders# student-builders# students# aws-student-builders-groups
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