Lambda Function Limitations

Here are the key limitations of AWS Lambda functions

1. Timeout: Maximum execution time is 15 minutes per invocation.
2. Memory: Memory can be allocated between 128 MB to 10 GB.
3. Ephemeral Storage: Temporary /tmp storage is limited to 512 MB, but can be increased up to 10 GB (requires configuration).
4. Payload size: Lambda can handle a maximum payload size of 6 MB for synchronous invocations and and 256 KB for asynchronous events.
5. Cold Starts: First-time invocations might experience a slight delay due to environment initialization.
6. Retries: Asynchronous invocations retry twice upon failure.
7. Sockets: Limited to 10 connections per instance.
8. Function Environment Variables: Combined size limit is 4 KB.
9. Function Name Length: Maximum 64 characters.
10. Supported Runtimes: Limited to AWS-supported languages (e.g., Python, Node.js, Java, Go, etc.)
11. Deployment Package Size:
    1. Direct upload - 50 MB (zipped).
    2. When using layers-  250 MB (unzipped, including all layers).
12. Concurrency:
    1. Default concurrent executions per account per region: 1,000 (can be increased with AWS support). This means that at any given time, no more than 1,000 Lambda function invocations can run simultaneously in that region.
    2. Burst concurrency: Limited based on region (e.g., 500-3,000 bursts in some regions).

Lambda Best Practices

1. When to VPC-Enable a Lambda Function
   1. By Default, Lambda functions operate from an AWS-managed VPC, with full access to public internet and AWS APIs.
   2. VPC Enablement Needed: Only when interacting with private resources in a private subnet (e.g., RDS instances).
   3. Once function is VPC-enabled, all network traffic from function follows the routing rules of your VPC/subnet.
   4. To interact with public resources, configure a route through a NAT gateway in a public subnet.
2. Use Lambda Layers for reusable Code
   1. Reuse common code across multiple functions.
   2. Examples:
      1. Logging packages for standardization.
      2. Custom version of the AWS SDK pinned to a tested version (e.g., Node.js, Python).
      3. Reduces duplication and simplifies function updates.
3. Optimize Package Size and Dependencies
   1. Smaller Deployment Packages → Faster cold-start times.
   2. Remove unused libraries, documentation, and unnecessary files.
   3. For Java: Include only required AWS SDK modules.
      1. Good: Add only relevant dependencies (e.g., dynamodb module).
      2. Bad: Avoid bundling the entire SDK.
4. Monitor Concurrency and Set CloudWatch Alarms
   1. Concurrency Control: Prevent overwhelming downstream systems.
   2. Use CloudWatch Alarms for metrics like:
      1. ConcurrentExecutions.
      2. Invocations.
   3. Set up AWS Budgets for cost control to monitor daily expenses.
   4. Address unexpected spikes in traffic proactively.
5. Optimize Memory and Timeout Settings
   1. Memory Allocation:
      1. Lambda scales compute power with memory.
      2. Over-provision memory improves execution speed and reduces costs.
      3. Benchmark to find the optimal memory-to-cost ratio for your use case.
   2. Timeout Settings:
      1. Do not over-provision timeouts.
      2. Set timeouts based on actual function performance to avoid unexpected costs.

3. Lambda@Edge vs AWS Lambda

Lambda@Edge and AWS Lambda (regular Lambda) are different services. Let me clarify this in detail:

1. AWS Lambda: A serverless compute service where you can run functions in response to various events. You can trigger AWS Lambda functions from services like S3, DynamoDB, API Gateway, etc.
2. Lambda@Edge: A variant of AWS Lambda that Runs closer to the end users at CloudFront edge locations. It allows you to perform lightweight processing at the edge, reducing latency and minimizing backend load.

Question - AWS Lambda concurrency limits

The engineering team at a football club built a notification system using Amazon SNS and AWS Lambda. During the off-season, the system handles 100 requests per second, but during peak season, it struggles with 5000 requests per second, causing missed notifications.

What is the best solution to address this issue?

Explanation: SNS to Lambda integrations are subject to AWS Lambda concurrency limits. If the rate of SNS messages increases (as in peak season), and the number of concurrent Lambda executions exceeds the account's concurrency quota, SNS may throttle or drop messages, resulting in missed notifications.

So, contacting AWS Support to increase the concurrency quota is a valid and often necessary step. Besides raising the limit, additional or alternative solutions may improve reliability and scalability:

Use SQS as a Buffer (Recommended Pattern)

Instead of invoking Lambda directly from SNS, you can:

1. SNS → SQS → Lambda
2. This decouples the system and lets SQS buffer bursts of messages during peak traffic, reducing pressure on Lambda concurrency.
3. This is an AWS best practice for high-throughput systems.

Question - Dynamic image resizing using Lambda®Edge function

A social media company runs its application on Amazon EC2 instances behind an Application Load Balancer (ALB). The ALB is the origin for an Amazon CloudFront in the request distribution. The application has more than a billion images stored in an Amazon S3 bucket and processes thousands of images each second. The company wants to resize the images dynamically and serve appropriate formats to clients. Which solution will meet these requirements with the LEAST operational overhead?

1. Use a Lambda®Edge function with an external image management library. Associate the Lambda®Edge function with the CloudFront behaviors that serve the images. (Correct Ans)
2. Install an external image management library on an EC2 instance. Use the image management library to process the images.
3. Create a CloudFront response headers policy. Use the policy to automatically resize images and to serve the appropriate format based on the User-Agent HTTP header in the request.
4. Create a CloudFront origin request policy. Use the policy to automatically resize images and to serve the appropriate format based on the User-Agent HTTP header

Explanation

1. Dynamic image resizing and format selection (e.g., WebP vs JPEG) requires on-the-fly processing based on headers like User-Agent, which standard CloudFront configurations can't do alone.
2. Lambda@Edge runs at CloudFront edge locations, allowing:
   • Dynamic image transformation (resize, format change)
   • Low latency (processing happens close to the user)
   • Minimal operational overhead (no EC2 to manage)
3. External image libraries (e.g., Sharp or ImageMagick) can be bundled with the Lambda function to perform image processing.

Why the other options are incorrect?

1. Install an external image management library on an EC2 instance:
   • High operational overhead (you have to manage EC2, scaling, updates).
   • Not cost-effective or scalable for image processing at large scale.
2. Create a CloudFront response headers policy:
   • Response header policies control HTTP headers, not image resizing or format conversion.
   • Cannot modify image content.
3. Create a CloudFront origin request policy:
   • Origin request policies let CloudFront forward specific headers, cookies, and query strings to the origin.
   • They do not handle image transformation.