Table of Contents hide

AWS Lambda Functions

Each function has associated configuration information, such as its name, description, runtime, entry point, and resource requirements

Lambda functions should be designed as stateless
- to allow launching of as many copies of the function as needed as per the demand.
- Local file system access, child processes, and similar artifacts may not extend beyond the lifetime of the request
- The state can be maintained externally in DynamoDB or S3
Lambda Execution role can be assigned to the function to grant permission to access other resources.

Functions have the following restrictions
- Inbound network connections are blocked
- Outbound connections only TCP/IP sockets are supported
- ptrace (debugging) system calls are blocked
- TCP port 25 traffic is also blocked as an anti-spam measure.
Lambda may choose to retain an instance of the function and reuse it to serve a subsequent request, rather than creating a new copy.

Lambda Layers provide a convenient way to package libraries and other dependencies that you can use with your Lambda functions.
Function versions can be used to manage the deployment of the functions.
Function Alias supports creating aliases, which are mutable, for each function version.

Functions have the following limits
- RAM – 128 MB to 10,240 MB (10 GB)
- CPU is linked to RAM and cannot be set manually.
  - 2 vCPUs = 1769 MB RAM
  - 6 vCPUs = 10240 MB RAM
- Timeout – 900 Secs or 15 mins
- /tmp storage between 512 MB and 10,240 MB
- Deployment Package – 50 MB (zipped), 250 MB (unzipped) including layers
- Concurrent Executions – 1000 (soft limit)
- Container Image Size – 10 GB
- Invocation Payload (request/response) – 6 MB (sync), 256 KB (async)
Functions are automatically monitored, and real-time metrics are reported through CloudWatch, including total requests, latency, error rates, and throttled requests.

Lambda automatically integrates with CloudWatch logs, creating a log group for each function and providing basic application lifecycle event log entries, including logging the resources consumed for each use of that function.
Functions support code written in
- Node.js (JavaScript)
- Python
- Ruby
- Java (Java 8 compatible)
- C# (.NET Core)
- Go
- Custom runtime

Container images are also supported.
Failure Handling
- For S3 bucket notifications and custom events, Lambda will attempt execution of the function three times in the event of an error condition in the code or if a service or resource limit is exceeded.
- For ordered event sources that Lambda polls, e.g. DynamoDB Streams and Kinesis streams, it will continue attempting execution in the event of a developer code error until the data expires.
- Kinesis and DynamoDB Streams retain data for a minimum of 24 hours
- Dead Letter Queues (SNS or SQS) can be configured for events to be placed, once the retry policy for asynchronous invocations is exceeded

Lambda Layers

Lambda Layers provide a convenient way to package libraries and other dependencies that you can use with your Lambda functions.
Layers help reduce the size of uploaded deployment archives and make it faster to deploy your code.
A layer is a .zip file archive that can contain additional code or data.

A layer can contain libraries, a custom runtime, data, or configuration files.
Layers promote reusability, code sharing, and separation of responsibilities so that you can iterate faster on writing business logic.
Layers can be used only with Lambda functions deployed as a .zip file archive.

For functions defined as a container image, the preferred runtime and all code dependencies can be packaged when the container image is created.
A Layer can be created by bundling the content into a .zip file archive and uploading the .zip file archive to the layer from S3 or the local machine.
Lambda extracts the layer contents into the /opt directory when setting up the execution environment for the function.

Environment variables can be used to adjust the function’s behavior without updating the code.
An environment variable is a pair of strings that are stored in a function’s version-specific configuration.
The Lambda runtime makes environment variables available to the code and sets additional environment variables that contain information about the function and invocation request.

Environment variables are not evaluated prior to the function invocation.
Lambda stores environment variables securely by encrypting them at rest.
AWS recommends using Secrets Manager instead of storing secrets in the environment variables.

RAM – 128 MB to 10,240 MB (10 GB)
CPU is linked to RAM and cannot be set manually.
- 2 vCPUs = 1769 MB RAM
- 6 vCPUs = 10240 MB RAM
Timeout – 900 Secs or 15 mins
/tmp storage between 512 MB and 10,240 MB

Lambda creates a new version of the function each time it’s published.
A function version includes the following information:
- The function code and all associated dependencies.
- The Lambda runtime that invokes the function.
- All the function settings, including the environment variables.
- A unique Amazon Resource Name (ARN) to identify the specific version of the function.

Alias supports routing configuration to point to a maximum of two Lambda function versions. It can be used for canary testing to send a portion of traffic to a second function version.