Lambda

AWS Lambda

Lambda

  • It is a serverless Function as a Service (Faas)

  • Pay per request (number of invocations) and compute time

  • Integrated with CloudWatch for monitoring

  • Not good for running containerized applications

  • Can package and deploy Lambda functions as container images

Difference between EC2 and Lambda

EC2

  • Virtual Servers in the Cloud

  • Limited by RAM and CPU

  • Continuously running

  • Scaling means intervention to add / remove servers

Lambda

  • Virtual functions – no servers to manage

  • Limited by time - short executions

  • Run on-demand

  • Scaling is automated

Lambda: Performance

  • Increasing RAM will improve CPU and network

  • Memory allocation (RAM): 128 MB -10GB (1 MB increments)

  • Max execution time: 900 seconds (15 minutes)

  • Disk capacity in function container (/tmp): 512 MB to 10GB

  • Size of environment variables: 4 KB

  • Concurrency executions: 1000 (can be increased)

Lambda: Deployment

    • Deployment size

      • Compressed: 50MB

      • Uncompressed (code + dependencies): 250 MB

  • Can use the /tmp directory to load other files at startup

  • Size of environment variables: 4 KB

  • If you intend to reuse code in more than one Lambda function, consider creating a Lambda Layer (a ZIP archive that contains libraries) for the reusable code. With layers, you can use libraries in your function without including them in the deployment package. Layers let you keep your deployment package small, which makes development easier. A function can use up to 5 layers at a time.

Lambda: Supported Languages

  • Node.js (JavaScript)

  • Python

  • Java

  • C# (.NET Core) / Powershell

  • Ruby

  • Any other language using Custom Runtime API (community supported, example Rust, GoLang)

  • Lambda Container Image

    • The container image must implement the Lambda Runtime API

    • ECS / Fargate is preferred for running arbitrary Docker images

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: (in increment of 1 ms )

    • 400,000 GB -seconds of compute time per month for FREE

    • \== 400,000 seconds if function is 1GB RAM

    • \== 3,200,000 seconds if function is 128 MB RAM

    • After that $1.00 for 600,000 GB-seconds

  • It is usually very cheap to run AWS Lambda so it’s very popular

Use cases

  • Serverless thumbnail creation using S3 & Lambda

  • Serverless CRON job using EventBridge & Lambda

Lambda: SnapStart

  • Improves your Lambda functions performance up to 10x at no extra cost for Java 11 and above

  • When enabled, function is invoked from a preinitialized state (no function initialization from scratch)

  • When you publish a new version:

    • Lambda initializes your function

    • Takes a snapshot of memory and disk state of the initialized function

    • Snapshot is cached for low-latency access

Customization At The Edge

  • Many modern applications execute some form of the logic at the edge

  • Edge Function:

    • A code that you write and attach to CloudFront distributions

    • Runs close to your users to minimize latency

  • CloudFront provides two types: CloudFront Functions & Lambda@Edge

  • You don’t have to manage any servers, deployed globally

  • Use case: customize the CDN content

  • Pay only for what you use

  • Fully serverless

CloudFront Functions & Lambda@Edge Use Cases

  • Website Security and Privacy

  • Dynamic Web Application at the Edge

  • Search Engine Optimization (SEO)

  • Intelligently Route Across Origins and Data Centers

  • Bot Mitigation at the Edge

  • Real-time Image Transformation

  • A/B Testing

  • User Authentication and Authorization

  • User Prioritization

  • User Tracking and Analytics

CloudFront Functions

  • Lightweight functions written in JavaScript

  • For high-scale, latency-sensitive CDN customizations

  • Sub-ms startup times, millions of requests/second

  • Used to change Viewer requests and responses:

    • Viewer Request: after CloudFront receives a request from a viewer

    • Viewer Response: before CloudFront forwards the response to the viewer

  • Native feature of CloudFront (manage code entirely within CloudFront)

Lambda@Edge

  • Lambda functions written in NodeJS or Python

  • Deploy Lambda functions alongside your CloudFront CDN for computing at edge locations

  • Scales to 1000s of requests/second

  • Used to change CloudFront requests and responses:

    • Viewer Request – after CloudFront receives a request from a viewer

    • Origin Request – before CloudFront forwards the request to the origin

    • Origin Response – after CloudFront receives the response from the origin

    • Viewer Response – before CloudFront forwards the response to the viewer

  • Author your functions in one AWS Region (us-east-1), then CloudFront replicates to its locations

CloudFront Functions vs. LambdaEDGE

CloudFront Functions vs. Lambda@Edge - Use Cases

Lambda by default

  • By default, your Lambda function is launched outside your own VPC (in an AWS -owned VPC)

  • Therefore, it cannot access resources in your VPC (RDS, ElastiCache, internal ELB…)

Lambda in VPC

  • You must define the VPC ID, the Subnets and the Security Groups

  • Lambda will create an ENI (Elastic Network Interface) in your subnets

Lambda with RDS Proxy

  • If Lambda functions directly access your database, they may open too many connections under high load

  • RDS Proxy

    • Improve scalability by pooling and sharing DB connections

    • Improve availability by reducing by 66% the failover time and preserving connections

    • Improve security by enforcing IAM authentication and storing credentials in Secrets Manager

  • The Lambda function must be deployed in your VPC, because RDS Proxy is never publicly accessible

Invoking Lambda from RDS & Aurora

  • Invoke Lambda functions from within your DB instance

  • Allows you to process data events from within a database

  • Supported for RDS for PostgreSQL and Aurora MySQL

  • Must allow outbound traffic to your Lambda function from within your DB instance (Public, NAT GW, VPC Endpoints)

  • DB instance must have the required permissions to invoke the Lambda function (Lambda Resource-based Policy & IAM Policy)

RDS Event Notifications

  • Notifications that tells information about the DB instance itself (created, stopped, start, …)

  • You don’t have any information about the data itself

  • Subscribe to the following event categories: DB instance, DB snapshot, DB Parameter Group, DB Security Group, RDS Proxy, Custom Engine Version

  • Near real-time events (up to 5 minutes)

  • Send notifications to SNS or subscribe to events using EventBridge