AWS Lambda

Virtual functions - no servers to manage
Limited by time - short executions
Run on-demand
Scaling is automated
Lambda Container Image
- The container image must implement the Lambda Runtime API
- ECS/Fargate is preferred for running arbitrary Docker images

Execution
- Memory allocation: 128MB to 10GB (1MB increments)
- Maximum execution time: 900 seconds (15 minutes)
- Environment variables (4KB)
- Disk capacity in the “Function Container” (in /tmp): 512MB to 10GB
- Concurrency executions: 1000 (can be increased)
Deployment
- Lambda function deployment size (compressed .zip): 50MB
- Size of uncompressed deployment (code + dependencies): 250MB
- Can use the /tmp directory to load other files at startup
- Size of environment variables: 4KB

Improves Lambda function performance up to 10x at no extra cost for Java 11 and above
When enabled, function is invoked from a pre-initialized state (no function initialization from scratch)
When you publish a new version
- Lambda initialize function
- Takes a snapshot of memory and disk state of the initialized function
- Snapshot is cached for low-latency access

Lambda function is launched outside VPC by default, meaning it cannot access resources in VPC such as RDS, ElastiCache, ELB, …
Define the VPC ID, Subnets, and SGs to launch Lambda in VPC
- Lambda will create an ENI in Subnets
Use Lambda with RDS Proxy to:
- Avoid opening too many connections to RDS
Lambda must be deployed in VPC because RDS Proxy is never publicly accessible

Allows to process data events from within a DB
Supported for RDS Postgres & Aurora MySQL
Must allow outbound traffic to Lambda from within 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)

Lambda 엔 boto3 와 같은 유용한 패키지들을 미리 제공되어 Docker Image 를 빌드할 때 패키지를 다운로드하는 번거로움을 줄일 수 있음
해당 Gist 를 통해 어떤 패키지들이 pre-installed 되어있는지 확인 가능

References