AWS Lambda (Serverless)

AWS Lambda is a compute service that lets you run code without provisioning or managing servers. It is a key component of the serverless architecture on AWS. The problem it solves is the operational overhead of managing servers: you no longer need to worry about OS patching, capacity planning, scaling, or high availability. You simply upload your code (known as a Lambda function) and define triggers (events) that cause the code to run. AWS handles everything else, including automatic scaling from zero to thousands of concurrent executions.

When you create a Lambda function, you specify the runtime (e.g., Python 3.9, Node.js 18, Java 11, .NET Core 6, Go, Ruby, or custom runtime via provided.al2), the code itself (either uploaded directly or from Amazon S3), and a role (IAM role) that grants the function permission to access other AWS services. The function is packaged into a deployment package (a .zip file or container image up to 250 MB unzipped).

Behind the scenes, AWS Lambda maintains a pool of warm containers ready to execute. When an event triggers the function, the Lambda service assigns an available container to run the code. The first invocation after a period of inactivity may experience a cold start (delay of a few hundred milliseconds to a few seconds) because a new container must be initialized. Subsequent invocations reuse the same container (warm start) for faster response. The container is frozen after the function completes, and if another invocation arrives quickly, it is reused. After a period of inactivity (typically 5-15 minutes), the container is recycled.

Lambda functions can be triggered by many AWS services: S3 (on object create/delete), DynamoDB Streams, Kinesis Streams, SQS, SNS, API Gateway, CloudWatch Events/EventBridge, and more. You can also invoke Lambda directly via the AWS SDK, CLI, or console.

Lambda pricing is based on three components: 1. Requests: $0.20 per 1 million requests (first 1 million free per month). 2. Duration: $0.0000166667 per GB-second (first 400,000 GB-seconds free per month). Duration is calculated from the time your code starts executing to when it returns or terminates, rounded up to the nearest 1 ms (previously 100 ms). 3. Provisioned Concurrency: Additional cost for keeping a number of containers warm to avoid cold starts. You pay for the amount of concurrency configured and the duration it is enabled.

On-premises, you would need to provision physical or virtual servers, install the OS and runtime, deploy your code, set up load balancers, and monitor health. With Lambda, none of that exists. Compared to Amazon EC2, Lambda is event-driven and scales automatically but has limitations: maximum 15-minute execution time, limited local storage (10 GB), and no persistent connections (state must be stored externally in DynamoDB or S3). EC2 gives you full control over the OS and environment and can run long-running processes. Lambda is ideal for short-lived, stateless functions.

Use Lambda when:

Do not use Lambda when:

Lambda@Edge is a feature that lets you run Lambda functions at AWS edge locations (CloudFront points of presence) to customize content delivered via CloudFront. You can trigger functions on viewer request, origin request, viewer response, and origin response. This is useful for A/B testing, URL rewrites, and authentication.

Lambda supports versioning of functions. Each version has a unique ARN and is immutable. You can create an alias (e.g., "prod", "dev") that points to a specific version, and you can update the alias to point to a different version without changing the code that invokes the alias. This enables blue/green deployments and canary releases.

Lambda allows you to set environment variables (up to 4 KB) that are available to your code at runtime. These are encrypted at rest by default using AWS KMS (you can provide a custom KMS key). Environment variables are useful for storing configuration settings like database connection strings (but not secrets — use AWS Secrets Manager or Parameter Store for sensitive data).

A Lambda layer is a .zip file archive that can contain libraries, a custom runtime, or other dependencies. You can use layers to manage common dependencies separately from your function code, reducing the size of deployment packages and promoting code reuse. You can include up to five layers per function.

For stream-based services (DynamoDB Streams, Kinesis Data Streams, SQS), Lambda uses event source mappings to poll the stream and invoke your function. You can configure batch size, starting position, and error handling (e.g., DLQ). The mapping handles scaling and retries.

Lambda can send invocation results to a destination (SQS, SNS, Lambda, EventBridge) for successful or failed asynchronous invocations. This is useful for chaining functions or handling errors.

Here is a simple Lambda function in Python that processes an S3 event:

import json
import boto3

def lambda_handler(event, context):
    # Log the event
    print("Received event: " + json.dumps(event, indent=2))
    
    # Get the S3 bucket and object key from the event
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']
    
    # Process the object (e.g., resize image)
    s3 = boto3.client('s3')
    response = s3.get_object(Bucket=bucket, Key=key)
    # ... do something with the file
    
    return {
        'statusCode': 200,
        'body': json.dumps('Success')
    }

To invoke a Lambda function via the AWS CLI:

aws lambda invoke --function-name my-function --payload '{"key1": "value1"}' response.json

A social media app allows users to upload profile pictures. When a user uploads an image to an S3 bucket, an S3 event triggers a Lambda function that resizes the image into multiple thumbnail sizes (e.g., 50x50, 150x150) and stores them back in S3. The function also updates a DynamoDB table with the image metadata. This serverless architecture eliminates the need for a dedicated image processing server. Cost: For 1 million uploads per month, assuming 1-second execution time and 128 MB memory, the cost is about $0.20 for requests + $0.0000166667 * 128/1024 * 1,000,000 seconds = ~$2.08, total ~$2.28 per month. Misconfiguration: If the Lambda timeout is set too low (e.g., 3 seconds) and large images take longer, the function will timeout and fail. Also, if the function does not handle errors gracefully (e.g., corrupt image), it may retry and cause duplicate processing. A DLQ should be configured to capture failed events.

A financial services company processes stock trade data from a Kinesis Data Stream. A Lambda function is triggered by the stream with a batch of records. It validates each trade, enriches it with reference data from DynamoDB, and writes the result to a Redshift cluster for analytics. This replaces a legacy on-premises stream processing system that required constant maintenance. The Lambda function scales automatically with the stream throughput. Cost considerations: The function must be idempotent because Kinesis may deliver records more than once. Also, if the function fails processing a batch, Lambda retries the entire batch until it succeeds or expires (up to 6 retries by default). A common mistake: Setting the batch size too large, causing the function to exceed the 15-minute timeout. The recommended batch size is 100 records for Kinesis.

An e-commerce platform needs to delete expired user sessions from a DynamoDB table every hour. Instead of running a cron job on an EC2 instance, they use Amazon EventBridge (CloudWatch Events) to trigger a Lambda function on a schedule (rate(1 hour)). The function scans the table for expired items and deletes them. This is cost-effective because the function runs only for a few seconds each hour. If the function is misconfigured to run too frequently or scans too many items, it could exceed the DynamoDB read capacity and cause throttling. Also, if the function fails, there is no automatic retry for scheduled events (the event is lost). Best practice: Use a DLQ for asynchronous invocations and set up a CloudWatch alarm for function errors.