Lambda #

AWS Lambda is the pioneering Function-as-a-Service (FaaS) service launched by Amazon Web Services in 2014. Its arrival sparked a global wave of serverless architecture adoption. Before Lambda, deploying an application always meant renting a virtual server (VM), configuring the operating system, and leaving it running continuously. AWS Lambda radically changed the rules of the game: we simply upload our application code, and AWS handles the entire execution, scalability, security, and availability process automatically.

In modern AWS cloud architecture practice, Lambda acts as the “glue service” that connects various AWS services responsively and event-driven. This article will thoroughly unpack AWS Lambda — from its internal architecture, how execution works, trigger integration, performance configuration, to real implementation code examples and best practices for production environments.

AWS Lambda Internal Architecture #

To write efficient, high-performance Lambda functions, we need to understand what happens behind the scenes when AWS receives a request to execute our function.

Isolation Technology: AWS Firecracker #

At launch, Lambda used standard EC2 containers to run user functions. However, to safely and isolatedly handle millions of invocations per second from thousands of customers, AWS developed an internal virtualization technology called AWS Firecracker.

Firecracker is an open-source technology written in Rust for creating MicroVMs (Micro Virtual Machines) that are extremely lightweight and secure, running on top of the Linux KVM (Kernel-based Virtual Machine) hypervisor. MicroVMs combine the hardware isolation security of traditional VMs with the boot speed and resource efficiency of contemporary containers. A Firecracker MicroVM can boot from a completely dead state in under 5 milliseconds and consume less than 5 MB of memory.

Execution Lifecycle (Cold Start vs. Warm Start) #

The AWS Lambda execution environment lifecycle is divided into three main phases:

flowchart TD
    Start["Incoming Invocation Request"] --> Check{"Is there an idle\nruntime available?"}
    Check -- "No (Cold Start)" --> Phase1["Phase 1: Init\n- Download function code\n- Create Firecracker MicroVM\n- Start language runtime\n- Initialize code outside handler"]
    Check -- "Yes (Warm Start)" --> Phase2["Phase 2: Invoke\n- Run the code handler\n- Send event parameters\n- Wait for response"]
    Phase1 --> Phase2
    Phase2 --> Phase3["Phase 3: Shutdown\n- Runtime frozen temporarily\n- If idle too long, destroyed"]

1. Initialization Phase (Init Phase) #

In this phase, AWS Lambda downloads the function code from an internal S3 bucket, creates a new Firecracker MicroVM with resource allocation matching the configuration, initializes the programming language runtime (e.g., Node.js or Python), and executes the code outside the main function (handler). This process is what’s known as Cold Start.

2. Invocation Phase (Invoke Phase) #

Once the execution environment is ready, AWS Lambda calls the actual handler function and injects the event parameter data. After execution completes and returns a response, this execution environment is frozen temporarily to save CPU.

3. Shutdown Phase #

If no new request arrives after a few minutes, AWS Lambda thaws the execution environment to clean up resources and permanently destroys the MicroVM.

If a new request arrives while the execution environment is in a frozen state, AWS Lambda immediately thaws it and enters the Invocation Phase without repeating the Initialization Phase. This instant process is called Warm Start.

Billing Model and Scalability #

AWS Lambda applies a very fair and efficient cloud economic model: we only pay for exactly what we use.

Billing Calculation #

The AWS Lambda bill is calculated based on two main metrics:

  1. Number of Requests (Invocations): The total number of function calls. The cost is very cheap, around $0.20 per 1 million requests.
  2. Compute Duration (GB-Seconds): Calculated from how long the code runs (rounded to millisecond precision) multiplied by the memory (RAM) capacity we allocate.

Cost Calculation Simulation Example: #

Suppose we allocate 1024 MB (1 GB) of memory to our function, and the function is invoked 3 million times in a month with an average execution duration of 200 ms per request.

  • Invocation Cost: 3,000,000 requests × $0.0000002 = $0.60
  • Total Duration: 3,000,000 requests × 0.2 seconds = 600,000 seconds
  • Total GB-Seconds: 600,000 seconds × 1 GB = 600,000 GB-seconds
  • Duration Cost (AWS standard price around $0.0000166667 per GB-second): 600,000 GB-seconds × $0.0000166667 = $10.00
  • Total Monthly Cost: $0.60 + $10.00 = $10.60 (Very cheap compared to renting a 24/7 VM).

Built-in Horizontal Scalability #

When application traffic load spikes, AWS Lambda scales horizontally by creating additional execution environment instances (MicroVMs) in parallel.

By default, the simultaneous parallel execution capacity quota (concurrency limit) is 1,000 parallel functions per region per AWS account (this limit can be increased by submitting a request to AWS Support). If new invocations exceed that limit, AWS rejects the request with a 429 status error (throttling).

Event Sources (Triggers) & Invocation Patterns #

AWS Lambda acts as an event consumer. There are three main patterns for how Lambda functions are triggered by other AWS services:

1. Synchronous Invocation #

In this model, the request sender waits for a direct response from the Lambda function before continuing its process.

  • Event Sources: Amazon API Gateway, Application Load Balancer (ALB), Cognito.
  • Error Handling: If the Lambda function fails or times out, the request sender immediately receives an HTTP 500 error. Retry logic must be handled on the sender’s side.

2. Asynchronous Invocation #

The request sender only sends event data to Lambda’s internal queue, receives instant confirmation (HTTP 202), and immediately continues its task without waiting for the Lambda function to finish running.

  • Event Sources: Amazon S3 (file uploads), Amazon SNS, EventBridge.
  • Error Handling: AWS Lambda automatically manages the internal queue and will attempt to re-execute failed functions 2 additional times by default before discarding them to a Dead Letter Queue (DLQ) or sending them to Lambda Destinations.

3. Event Source Mapping (Polling) #

AWS Lambda actively polls data from queue- or stream-based services, reads a certain number of messages (batch), then sends them to the Lambda function.

  • Event Sources: Amazon SQS, Amazon Kinesis, DynamoDB Streams.
  • Error Handling: If execution fails, Lambda keeps retrying the problematic batch until the data expiration period ends (retry-until-expire) to maintain precise data ordering.

Essential Configuration and Performance Tuning #

Configuring the right parameters on AWS Lambda determines our application’s execution performance and cost efficiency.

Memory Allocation and Its Relationship with CPU #

On AWS Lambda, we can’t choose the number of vCPUs independently. We only configure memory (RAM) capacity from 128 MB to 10,240 MB (10 GB).

AWS allocates CPU power proportionally. For example, if we double the RAM from 256 MB to 512 MB, our function also gets twice the CPU power.

AWS Lambda Power Tuning: Increasing memory often lowers total cost. Why? Because a larger CPU allocation makes the function run much faster, significantly reducing execution milliseconds. We should run performance benchmarks using the open-source AWS Lambda Power Tuning tool to find the optimal sweet spot between execution speed and cost.

VPC Configuration (Virtual Private Cloud) #

By default, Lambda functions run in AWS’s secure, isolated internal network with outbound access to the public internet. However, if our function needs to access private databases inside our VPC (like Amazon RDS PostgreSQL), we must configure the function to connect to our VPC.

In the past, connecting Lambda to a VPC triggered a very slow cold start increase because Elastic Network Interfaces (ENIs) had to be created. Now, AWS has implemented a new network architecture called AWS Hyperplane that shares ENIs, making cold starts inside a VPC as fast as outside one.

Practical Implementation Code Example #

Here’s an AWS Lambda function implementation example using Node.js (JavaScript ES Modules) that demonstrates writing a handler, reading event parameters, calling a database (simulated), and writing structured JSON-format logs.

// CORRECT: Initialize the database client outside the handler (Global Scope)
// Benefit: The DB connection can be reused on subsequent Warm Start invocations
import { Client } from 'pg';

const dbClient = new Client({
    connectionString: process.env.DATABASE_URL
});

// Flag to track the database connection status
let isDbConnected = false;

async function connectDatabase() {
    if (!isDbConnected) {
        console.log(JSON.stringify({ message: "Creating a new database connection..." }));
        await dbClient.connect();
        isDbConnected = true;
    }
}

// Main AWS Lambda handler
export const handler = async (event, context) => {
    // ✓ Structured logging using JSON format for easy reading in CloudWatch
    console.log(JSON.stringify({ 
        message: "Lambda invocation request received", 
        requestId: context.awsRequestId,
        eventData: event 
    }));

    try {
        // Safely initialize the database connection
        await connectDatabase();

        // 1. Extract data from the event parameters (Assumed trigger from API Gateway)
        const body = event.body ? JSON.parse(event.body) : {};
        const userId = body.userId;

        if (!userId) {
            // ✓ Return a structured response with the appropriate status code
            return {
                statusCode: 400,
                headers: { 'Content-Type': 'application/json' },
                body: JSON.stringify({ error: "userId is required in the request body" })
            };
        }

        // 2. Simulated database query
        const res = await dbClient.query('SELECT name, email FROM users WHERE id = $1', [userId]);
        
        if (res.rows.length === 0) {
            return {
                statusCode: 404,
                headers: { 'Content-Type': 'application/json' },
                body: JSON.stringify({ error: "User not found" })
            };
        }

        const userData = res.rows[0];

        // 3. Return the success response data
        return {
            statusCode: 200,
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({
                success: true,
                user: userData
            })
        };

    } catch (error) {
        // ✗ Don't ignore error logging! Write the error details to stderr
        console.error(JSON.stringify({
            message: "An internal error occurred in the Lambda function",
            error: error.message,
            stack: error.stack
        }));

        return {
            statusCode: 500,
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({ error: "Internal server error" })
        };
    }
};

Best Practices in Production Environments #

To ensure AWS Lambda functions run stably, securely, and efficiently at production scale, we must follow these best practice guidelines:

1. Apply the Least Privilege Security Principle #

Every Lambda function should have its own strictly configured IAM Execution Role. If Lambda function A only retrieves files from one specific S3 bucket, give it s3:GetObject permission scoped to that bucket’s ARN. Avoid wildcards like "Action": "s3:*" or "Resource": "*".

2. Manage Environment Variables Securely (Secrets Management) #

Never write API keys, tokens, or database credentials in plain text (hardcoded) in source code or as standard environment variables. Use managed services like AWS Secrets Manager or Systems Manager (SSM) Parameter Store to securely retrieve those secrets at runtime.

3. Write Idempotent Code #

Because Lambda’s async invocation model has automatic retry on failure, a Lambda function may receive the same event more than once (at-least-once delivery). Make sure our function code is safe to run repeatedly with identical input without producing duplicate side effects (e.g., double payments).

4. Implement Observability from the Start #

Enable AWS X-Ray tracing to monitor the time Lambda functions spend calling external services (like RDS databases or external APIs). Use structured JSON logging to make monitoring and log visualization with CloudWatch Insights easier.

Summary #

  • AWS Lambda is a FaaS service that executes code dynamically based on events, abstracting all server management away from developers.
  • Firecracker MicroVMs are the virtualization technology behind Lambda, providing secure hardware isolation with sub-5ms boot speed.
  • The billing model is calculated granularly based on the number of requests and compute duration (milliseconds multiplied by allocated RAM capacity).
  • CPU allocation is directly proportional to RAM — increasing memory capacity often lowers cost because execution duration becomes much faster.
  • Function design must be stateless, idempotent, follow least privilege access, and leverage variable initialization outside the handler for warm start invocations.
← Previous: Pros & Cons   Next: Fargate →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact