AWS Lambda Tutorial: A Guide to Creating Your First Function

Summary:

• Learn how to create your first AWS Lambda function using the latest runtimes including Python 3.13, Node.js 22, Java 25, and .NET 10 with step-by-step guidance for both console and Infrastructure as Code deployments.
• Understand cold start optimization techniques including SnapStart, Arm64 architecture selection, and runtime-specific performance tuning that can reduce latency by up to 90% in production workloads.
• Compare managed versus custom runtimes with concrete benchmarks, cost analysis, and decision frameworks to help you select the right approach for your serverless architecture.
• Master deployment workflows using AWS SAM and CDK alongside monitoring strategies with CloudWatch and X-Ray to build production-ready Lambda functions from day one.

Serverless computing has fundamentally shifted how engineering teams approach application architecture, and AWS Lambda sits at the center of this transformation. Whether you are building a lightweight API endpoint, processing event streams from S3, or orchestrating complex workflows, Lambda eliminates the operational burden of managing servers while providing automatic scaling that responds to demand in milliseconds. This AWS Lambda tutorial walks you through creating your first function using the latest 2026 runtimes, optimizing for performance, and deploying with modern Infrastructure as Code practices that will serve you well in both production systems and technical interviews.

Understanding AWS Lambda and its role in modern cloud architecture

AWS Lambda is a serverless compute service that executes your code in response to events without requiring you to provision or manage servers. When an event triggers your function, Lambda automatically allocates compute resources, runs your code, and scales horizontally to handle concurrent requests. You pay only for the compute time consumed, measured in milliseconds. This makes Lambda particularly cost-effective for workloads with variable or unpredictable traffic patterns.

The service handles all infrastructure concerns including operating system maintenance, capacity provisioning, automatic scaling, and high availability across multiple Availability Zones.

The execution model follows a straightforward pattern that every engineer should internalize. Your function receives an event object containing the trigger payload and a context object with runtime information such as remaining execution time and request identifiers. Lambda creates an execution environment that includes your code, runtime, and any configured layers, then invokes your handler function.

This environment may be reused for subsequent invocations, a behavior that directly impacts cold start performance and connection pooling strategies. Understanding this lifecycle becomes critical when optimizing for latency-sensitive applications.

Lambda integrates natively with over 200 AWS services, creating a powerful ecosystem for event-driven architectures. Common trigger sources include API Gateway for HTTP endpoints, S3 for object storage events, DynamoDB Streams for database changes, SQS for message queue processing, and EventBridge for custom application events.

This integration depth means you can build sophisticated distributed systems by composing Lambda functions with other managed services. This approach reduces the operational complexity that traditionally accompanied such architectures. Consider the following section to understand which runtime best fits your use case before writing your first function.

Selecting the right runtime for your Lambda function

AWS Lambda supports multiple managed runtimes as of 2026, each optimized for different use cases and team expertise. The current lineup includes Python 3.13, Node.js 22, Java 25, .NET 10, Ruby 3.4, and custom runtimes built on the Lambda Runtime API. Your runtime choice impacts cold start latency, memory efficiency, ecosystem compatibility, and long-term maintenance burden. Making an informed decision here prevents costly refactoring later when performance requirements tighten or team composition changes.

Managed runtime options and their characteristics

Python 3.13 remains the most popular choice for Lambda functions due to its readable syntax, extensive library ecosystem, and relatively fast cold starts averaging 200-400ms for typical functions. The runtime includes optimizations for AWS SDK operations and supports the latest language features including improved error messages and performance enhancements in the interpreter.

Node.js 22 offers excellent cold start performance, often under 200ms, making it ideal for latency-sensitive API endpoints. The event-driven nature of JavaScript aligns naturally with Lambda’s execution model, and the npm ecosystem provides packages for virtually any integration requirement.

Java 25 introduces significant improvements for serverless workloads, particularly through enhanced ahead-of-time compilation and the mature SnapStart feature that can reduce cold starts from several seconds to under 200ms. The runtime now supports virtual threads (Project Loom), enabling efficient handling of concurrent I/O operations without the complexity of traditional thread management.

.NET 10 brings native AOT compilation to Lambda, producing smaller deployment packages and faster startup times compared to previous versions. For teams with existing .NET expertise, this runtime provides a smooth path to serverless without sacrificing language familiarity.

Custom runtimes and when to use them

Custom runtimes extend Lambda to languages not natively supported, such as Rust, Go (beyond the deprecated managed runtime), or specialized language versions. You implement the Lambda Runtime API, which defines how your runtime receives invocation events and returns responses. This approach requires more operational investment but unlocks performance characteristics impossible with managed runtimes. Rust-based custom runtimes, for example, consistently achieve cold starts under 50ms with minimal memory footprint.

The decision between managed and custom runtimes involves weighing several factors:

• Team expertise: Custom runtimes require deeper understanding of Lambda internals and add maintenance burden for runtime updates and security patches.
• Performance requirements: If your application demands sub-100ms cold starts or minimal memory usage, custom runtimes built with compiled languages offer advantages.
• Ecosystem needs: Managed runtimes provide seamless integration with AWS SDKs and extensive community packages that accelerate development.

With runtime selection clarified, the next step involves actually creating your first Lambda function through the AWS Console. The console provides an interactive environment for learning the service fundamentals.

Creating your first Lambda function via the AWS Console

The AWS Console offers the fastest path to deploying your first Lambda function, providing an integrated development environment that includes code editing, testing, and monitoring capabilities. Recent updates have introduced the Code-OSS editor, bringing VS Code-like functionality directly into the browser with features including IntelliSense, syntax highlighting, and integrated terminal access. This approach works well for learning and prototyping before transitioning to Infrastructure as Code for production deployments.

Step-by-step function creation process

Navigate to the Lambda service in the AWS Console and select Create function. Choose Author from scratch to build a new function without a blueprint template. Enter a descriptive function name following your organization’s naming conventions, typically including the service name, purpose, and environment identifier. Select your runtime from the dropdown, with Python 3.13 being an excellent choice for this tutorial due to its accessibility and fast iteration cycle.

The architecture selection between x86_64 and arm64 (Graviton2) impacts both performance and cost. Arm64 functions typically cost 20% less and often execute faster for compute-bound workloads due to the Graviton2 processor’s efficiency. However, verify that your dependencies support arm64 before selecting this option, as some native libraries may only provide x86 binaries. For permissions, the default execution role option creates a new IAM role with basic Lambda execution permissions including CloudWatch Logs access.

After creation, the console displays your function’s code editor with a default handler. Replace the template code with a simple function that demonstrates the event and context parameters:

import json

def lambda_handler(event, context):
    # Extract information from the incoming event
    name = event.get('name', 'World')
    
    # Access runtime context information
    remaining_time = context.get_remaining_time_in_millis()
    request_id = context.aws_request_id
    
    response = {
        'statusCode': 200,
        'body': json.dumps({
            'message': f'Hello, {name}!',
            'requestId': request_id,
            'remainingTime': remaining_time
        })
    }
    
    return response

 

Watch out: The console editor works well for functions under 3MB, but larger deployment packages require uploading a ZIP file or using container images. Plan your deployment strategy early to avoid workflow disruptions as your function grows.

Testing and validating your function

The Test tab allows you to create test events that simulate real invocations. Create a new test event with a JSON payload matching your expected input format. For the example function above, use a simple object like {"name": "Lambda Developer"}. Execute the test and examine the response, which includes the function output, execution duration, billed duration, and memory used. These metrics provide immediate feedback on function behavior and resource consumption.

The Execution results panel displays both the response payload and the function logs. Pay attention to the Init Duration metric on cold starts, which represents the time Lambda spent initializing your execution environment before running the handler. This metric disappears on warm invocations when Lambda reuses an existing environment.

Understanding this distinction helps you interpret performance data accurately and identify optimization opportunities. With console-based development understood, transitioning to Infrastructure as Code enables reproducible deployments across environments.

Deploying Lambda functions with Infrastructure as Code

Production Lambda deployments require Infrastructure as Code to ensure consistency, enable version control, and support automated CI/CD pipelines. AWS provides two primary tools for this purpose. These are the Serverless Application Model (SAM) and the Cloud Development Kit (CDK). Both integrate with CloudFormation for resource provisioning but offer different abstractions suited to different team preferences and project requirements.

AWS SAM for serverless-focused deployments

SAM extends CloudFormation with simplified syntax specifically designed for serverless applications. A SAM template defines your Lambda function, its triggers, and associated resources in a declarative YAML format that reduces boilerplate compared to raw CloudFormation. The SAM CLI provides local testing capabilities, allowing you to invoke functions on your development machine before deploying to AWS. This local execution uses Docker containers that mirror the Lambda runtime environment.

A minimal SAM template for deploying a Python function with an API Gateway trigger demonstrates the framework’s conciseness:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Sample SAM template for Lambda tutorial

Globals:
  Function:
    Timeout: 30
    MemorySize: 256
    Runtime: python3.13
    Architectures:
      - arm64

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: src/
      Handler: app.lambda_handler
      Events:
        ApiEvent:
          Type: Api
          Properties:
            Path: /hello
            Method: get

Outputs:
  ApiEndpoint:
    Description: API Gateway endpoint URL
    Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/hello"

Deploy this template using sam build followed by sam deploy --guided, which walks you through configuration options including stack name, region, and IAM capability acknowledgment. SAM handles packaging your code, uploading to S3, and orchestrating the CloudFormation deployment.

AWS CDK for programmatic infrastructure

The Cloud Development Kit takes a different approach, allowing you to define infrastructure using familiar programming languages including TypeScript, Python, Java, and C#. This programmatic model enables loops, conditionals, and abstractions impossible in declarative templates. CDK constructs encapsulate AWS best practices, automatically configuring IAM permissions and resource relationships that would require explicit definition in SAM or CloudFormation.

The equivalent CDK code in TypeScript illustrates the programming model:

import * as cdk from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as apigateway from 'aws-cdk-lib/aws-apigateway';

export class LambdaTutorialStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const helloFunction = new lambda.Function(this, 'HelloFunction', {
      runtime: lambda.Runtime.PYTHON_3_13,
      architecture: lambda.Architecture.ARM_64,
      handler: 'app.lambda_handler',
      code: lambda.Code.fromAsset('src'),
      timeout: cdk.Duration.seconds(30),
      memorySize: 256,
    });

    const api = new apigateway.RestApi(this, 'HelloApi');
    api.root.addResource('hello').addMethod('GET', 
      new apigateway.LambdaIntegration(helloFunction));
  }
}

Both tools support the full Lambda feature set including layers, provisioned concurrency, and SnapStart configuration. Your choice between them often depends on team familiarity and project complexity rather than technical capability. With deployment infrastructure established, optimizing function performance becomes the next priority for production readiness.

Optimizing Lambda performance and reducing cold starts

Cold start latency represents the most significant performance challenge in Lambda architectures, particularly for synchronous workloads where users wait for responses. A cold start occurs when Lambda must create a new execution environment. This involves downloading your deployment package, initializing the runtime, and executing any code outside your handler function. Optimization strategies target each phase of this initialization process to minimize user-perceived latency.

SnapStart for Java and .NET workloads

SnapStart addresses cold start latency for Java and .NET functions by creating a snapshot of the initialized execution environment. When you publish a new function version with SnapStart enabled, Lambda initializes your function, takes a memory snapshot, and caches it for reuse. Subsequent cold starts restore from this snapshot rather than performing full initialization, reducing startup time from seconds to typically under 200ms. This feature transforms Java from one of the slowest cold start runtimes to competitive with interpreted languages.

Enabling SnapStart requires publishing a function version, as the feature operates on immutable versions rather than the $LATEST alias. In SAM, add the SnapStart configuration to your function definition:

Resources:
  JavaFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: java25
      SnapStart:
        ApplyOn: PublishedVersions
      AutoPublishAlias: live

Consider these factors when implementing SnapStart:

1. Uniqueness requirements: Any unique identifiers generated during initialization will be shared across restored instances. Use runtime hooks to regenerate unique values after restoration.
2. Network connections: Connections established during init may become stale. Implement connection validation or lazy initialization patterns.
3. Cached credentials: Security tokens cached during snapshot creation may expire. Use the AWS SDK’s automatic credential refresh rather than manual caching.

Architecture selection and memory optimization

Selecting arm64 architecture provides both cost savings and performance improvements for many workloads. Graviton2 processors offer better price-performance than x86 equivalents, with Lambda pricing 20% lower for arm64 functions. Benchmark testing consistently shows arm64 matching or exceeding x86 performance for compute-bound operations, though results vary by workload characteristics. Ensure your dependencies provide arm64-compatible binaries before migrating existing functions.

Memory allocation directly impacts CPU allocation in Lambda, with CPU power scaling linearly from 128MB to 1,769MB and proportionally beyond. Increasing memory often reduces execution duration enough to offset the higher per-millisecond cost, resulting in lower total cost. Use the AWS Lambda Power Tuning tool to identify the optimal memory configuration for your specific function by running automated benchmarks across memory settings.

Provisioned concurrency for consistent latency

When cold start elimination is critical, provisioned concurrency pre-initializes a specified number of execution environments that remain ready to handle requests immediately. This feature guarantees warm start performance for the configured concurrency level. Lambda automatically scales beyond provisioned capacity using on-demand instances when traffic exceeds the provisioned amount.

The trade-off involves paying for provisioned environments regardless of actual utilization. This makes the feature cost-effective only for functions with predictable, sustained traffic.

Performance optimization establishes the foundation for production workloads. Comprehensive monitoring ensures you can identify issues and validate improvements in real deployments.

Monitoring, logging, and security best practices

Effective Lambda operations require visibility into function behavior, performance trends, and error patterns. AWS provides integrated monitoring through CloudWatch Logs, CloudWatch Metrics, and X-Ray distributed tracing. Combining these services creates a comprehensive observability stack that supports both real-time alerting and historical analysis for capacity planning and optimization.

CloudWatch integration for logs and metrics

Lambda automatically streams function logs to CloudWatch Logs, capturing both your application output and platform events including cold start notifications and timeout warnings. Structure your log output as JSON to enable CloudWatch Logs Insights queries that filter and aggregate across thousands of invocations. Include correlation identifiers in your logs to trace requests across multiple functions in distributed workflows.

CloudWatch Metrics provides pre-built dashboards showing invocation counts, error rates, duration percentiles, and concurrent executions. Create alarms on these metrics to receive notifications when error rates spike or duration exceeds acceptable thresholds. The Iterator Age metric proves particularly valuable for stream-based triggers, indicating how far behind your function has fallen in processing events from Kinesis or DynamoDB Streams.

Distributed tracing with X-Ray

AWS X-Ray provides end-to-end request tracing across Lambda functions and integrated AWS services. Enable active tracing on your function to capture detailed timing information for each invocation, including initialization time, handler execution, and calls to downstream services. X-Ray automatically instruments AWS SDK calls, showing latency breakdown for DynamoDB queries, S3 operations, and other service interactions without code changes.

For custom instrumentation, the X-Ray SDK allows you to create subsegments that capture timing for specific code blocks or external API calls. This granular visibility helps identify performance bottlenecks that aggregate metrics would obscure. The service map visualization shows request flow through your architecture, highlighting services with elevated error rates or latency.

IAM security and least privilege

Lambda execution roles define what AWS resources your function can access. Apply the principle of least privilege by granting only the specific permissions required for your function’s operation. Avoid using managed policies like AmazonDynamoDBFullAccess when your function only needs read access to a single table. Instead, create custom policies that specify exact actions and resource ARNs.

Resource-based policies control which principals can invoke your function. When configuring triggers, Lambda automatically adds necessary permissions, but review these policies periodically to remove stale entries from decommissioned integrations. For functions exposed via Function URLs, configure authentication requirements and CORS settings appropriate for your security posture. The IAM policy documentation provides detailed guidance on constructing secure, minimal policies.

Conclusion

This AWS Lambda tutorial has equipped you with the knowledge to create, deploy, and optimize serverless functions using current best practices and the latest 2026 runtimes. You now understand how to select appropriate runtimes based on performance characteristics and team expertise. Python 3.13 and Node.js 22 offer excellent starting points, and Java 25 with SnapStart provides enterprise-grade performance for JVM workloads. The deployment patterns using SAM and CDK establish reproducible infrastructure that scales from prototype to production without workflow changes.

Cold start optimization through architecture selection, memory tuning, and SnapStart configuration addresses the primary performance challenge in serverless architectures. Combined with comprehensive monitoring via CloudWatch and X-Ray, these techniques enable you to build Lambda functions that meet demanding latency requirements while maintaining operational visibility. As serverless adoption continues accelerating, these foundational skills position you to architect event-driven systems that leverage managed infrastructure for both cost efficiency and operational simplicity.

The path forward involves applying these concepts to increasingly complex scenarios. These include multi-function workflows orchestrated by Step Functions, event sourcing patterns with DynamoDB Streams, and real-time data processing with Kinesis. Each extension builds on the fundamentals covered here, making your investment in understanding Lambda’s execution model and optimization levers valuable across the breadth of serverless architecture patterns.