The term “Serverless”
Lambda is a serverless compute service that lets you run code without provisioning or managing servers.
Key points:
Serverless Paradigm: Emphasizes the shift from traditional server management to deploying code in the form of functions.
Deployment Simplicity: Developers focus solely on writing code, leaving infrastructure concerns to AWS.
Event-Driven: Lambda functions are triggered by events, making them ideal for real-time data processing.
Key Features of AWS Lambda
Lambda's robust feature set includes:
Multi-Language Support: Supports Node.js, Python, Java, C#, and more.
Execution Time: Functions can run up to 15 minutes.
Environment Variables: Manage configuration settings and secrets easily.
Monitoring: Integrated with AWS CloudWatch for logging and performance monitoring.
Lambda Pricing
Pay Per Calls:
First 1,000,000 requests are free
$0.20 per 1 million requests thereafter ($0.0000002 per request)
Pay per duration:
400,000 GB -seconds of compute time per month for FREE
== 400,000 seconds if function is 1GB RAM
After that $1.00 for 600,000 GB-seconds
You can find overall pricing information here:
Creating a Lambda Function
Lambda Execution Role
Execution Role grants the Lambda function permissions to AWS services / resources
Sample managed policies for Lambda:
AWSLambdaBasicExecutionRole – Upload logs to CloudWatch.
AWSLambdaDynamoDBExecutionRole – Read from DynamoDB Streams.
AWSLambdaSQSQueueExecutionRole – Read from SQS.
AWSLambdaVPCAccessExecutionRole – Deploy Lambda function in VPC.
AWSLambdaInvocation-DynamoDB – Allow a Lambda function to be invoked by DynamoDB streams.
AWSLambdaInvocation-SQS – Allow a Lambda function to be invoked by SQS messages.
AWSLambdaInvocation-SNS – Allow a Lambda function to be invoked by SNS messages.
When you use an event source mapping to invoke your function, Lambda uses the execution role to read event data.
Lambda Resource Based Policies
Purpose:
Use resource-based policies to give other accounts and AWS services permission to use your Lambda resources.
Access Control:
An IAM principal can access a Lambda function if:
The IAM policy attached to the principal authorizes it (e.g., user access).
The resource-based policy authorizes it (e.g., service access).
Service Invocation:
When an AWS service like Amazon S3 calls your Lambda function, the resource-based policy grants it the necessary access.
Example Policy:
Lambda Environment Variables
Purpose:
Environment variables allow you to configure various aspects of your Lambda function's behavior without modifying its code.
They are useful for storing configuration settings, sensitive information like API keys or database credentials, and any other dynamic data needed by your function.
Accessing Environment Variables:
In your Lambda function code, you can access environment variables using standard methods provided by your programming language's runtime environment.
For example, in Node.js, you can access environment variables using process.env.MY_VARIABLE.
Security Considerations:
AWS provides integration with Key Management Service (KMS) to encrypt environment variables, ensuring that sensitive data remains protected.
Lambda Event Source Mapping
Event source mapping is a mechanism that allows AWS Lambda to automatically process events from various AWS services without the need for manual invocation.
How Event Source Mapping Works
Configuration: You configure an event source mapping to specify the event source and the target Lambda function.
Polling or Event Trigger: Depending on the event source, AWS Lambda either polls the event source (e.g., SQS, DynamoDB) or receives events directly (e.g., S3, SNS).
Invocation: When an event occurs, AWS Lambda invokes the specified function and passes the event data as input
Lambda Limits to Know per region
Execution:
Memory allocation: 128 MB – 10GB (1 MB increments)
Maximum execution time: 900 seconds (15 minutes)
Environment variables (4 KB)
Disk capacity in the “function container” (in /tmp): 512 MB to 10GB
Concurrency executions: 1000 (can be increased)
Deployment:
Lambda function deployment size (compressed .zip): 50 MB
Size of uncompressed deployment (code + dependencies): 250 MB
Can use the /tmp directory to load other files at startup
Lambda Layers
Lambda Layers are a feature that allows you to package libraries, custom runtimes, and other dependencies that you can use with your Lambda functions. Layers help you to manage your code better and keep your deployment package size small.
Key Concepts
Layer Creation:
Layers are created separately from Lambda functions.
Each layer can contain libraries, a custom runtime, or other dependencies.
You can create a layer from the AWS Management Console, AWS CLI, or AWS SDKs.
Layer Versions:
Layers are versioned. Each update to a layer creates a new version.
You can specify which version of the layer to use with your Lambda function.
Layer Usage:
You can use up to five layers in a single Lambda function.
Layers can be shared across accounts and with the public.
Layer Content:
Layers can include libraries, binaries, custom runtimes, and other files.
The content must be in a ZIP file when uploading.
Lambda Layers Best Practices
Use Layers for Dependencies:
Include common libraries and dependencies in layers to keep the function deployment package small.
Version Control:
Maintain version control for layers. Test new versions before updating functions to ensure compatibility.
Optimize Layer Size:
Keep the layer size minimal. Remove unnecessary files and dependencies to stay within the 50 MB limit (250 MB unzipped).
Security:
Secure sensitive data within layers using encryption and IAM policies.
Use AWS KMS to encrypt sensitive information stored in layers.
This Much for this week, Next week I’ll cover the Advanced Lambda Topics.
Don’t forget to Follow me at @masterawscloud