AWS Certified Developer Exam Notes – Lambda

Posted on by antonogeo

Lambda

  • Serverless.
  • Limited by time – short executions
  • Does not run continuously. Runs on-demand.
  • Pay for the number of requests and compute time.
  • Free tier of 1m Lambda requests
  • Limits
    • Memory: 128MB – 10GB
    • Max execution time: 15 minutes
    • Env variables 4KB
    • Concurrency 1000 executions for all (can be increased with AWS request)
    • Deployment
      • 50MB compressed
      • 250MB uncompressed (+dependencies)
  • Languages: Node, Python, Java, C#, Golang, Ruby, Custom Runtime API (Rust)
  • Best Practices
    • Keep heavy-duty work outside function handler
    • Avoid recursive functions.
    • Use environment variables for DB connection strings, s3 buckets, and passwords (encrypted with KMS)
    • Minimize deployment package. Use layers if necessary
    • You can use a /tmp folder to store temporary files that can be used by subsequent invocations of the function
  • Lambda container image. Must implement Lambda Runtime API. Can be run on ECS / Fargate.

  • CLI : aws lambda invoke –function-name XXX –payload ‘[XXX]’ response.json

  • Destinations
    • Send the results of asynchronous invocations to a destination in order to find out what goes wrong with asynchronous invocations. 
    • Use them instead of DLQ
    • Add destination -> On failure or On success -> Select Destination
    • Destinations: SQS, SNS, Lambda, Eventbridge bus
  • IAM Role
    • All Lambda functions have an IAM role. 
    • When the Lambda is invoked, we need resource-based policies. This is automatically created.
    • When Lambda polls, we don’t need a resource-based policy. We need to modify the Lambda role, with the correct permissions for the caller.
  • Environment variables
    • We can encrypt them to store sensitive data
    • Code changes: import os
  • Monitoring and Tracing
    • Lambda execution logs are stored in Cloudwatch Logs (we need to assign permissions to the lambda role)
    • Tracing with Xray
      • This is enabled in Lambda configuration: Active Tracing
  • External Dependencies
    • We need to zip all together (lambda function,  jars, node_modules, etc) and upload them to Lambda
  • CloudFormation
    • We can write the Lambda functions inline the CloudFormation templates (but without dependencies, used for simple functions)
    • Also, we can upload the Lambda zip in S3, and refer it to the CloudFormation code
    • We set on the CloudFormation the following
      • S3BucketParam
      • S3KeyParam (the zip)
      • S3ObjectVersionParams
  • Layers
    • Externalize dependencies to reuse them
    • Save a layer of code and reuse it on many functions

 

Function Configuration

  • From 128MB to 10GB. The more, the more expensive.
  • 1792 = 1vCPU
  • What to do if the application is computation-heavy (CPU-bound)? : Increase Memory (RAM). We cannot change the CPU directly.
  • The maximum amount of memory available to the Lambda function at runtime is 10,240 MB
  • Timeout: 3 seconds to 900 seconds (15 minutes). Anything more than 15 minutes is not a use case for lambda. 
    • We don’t want to update all Lambda to 15 minutes since we want to fail faster in case of an error.
  • You can store something (a big file) to /tmp (up to 512MB) in order to use it later, during the function call.

 

Lambda@Edge

  • Deploy Lambda function to Edge locations. Works with Cloudfront. Create a global application.
  • We can modify the viewer request/response (user-cloudfront), and the origin request/response(cloudfront-origin)

Lambda and ALB

  • Connect it with Lambda, by registering lambda to a target group
  • ALB to Lambda: HTTP to JSON (headers and body are converted to JSON key-value pairs)
  • Multi-Header values for query string parameters. It is a setting on ALB. Headers and parameters are passed as arrays

Lambda and VPC

  • By default the functions are launched outside VPC, so they cannot access VPC resources (RDS, internal ELB, ElastiCache)
  • You can deploy Lambda in VPC. Lambda will create an ENI
  • Internet access
    • By default, a VPC Lambda function does not have internet access, even if we deploy it on a public subnet
    • We need to deploy it on the private subnet and use a NAT Gateway

Lambda and Images

  • Up to 10GB from ECR
  • The base image must implement Lambda Runtime API
  • The Dockerfile need to be updated
  •  Lambda function needs to be on the same account as the container registry in Amazon ECR.

Versions

  • We work on $LATEST
  • Aliases point to different versions
  • We can create dev, prod, test, etc Aliases that point to different versions.
  • Aliases cannot reference Aliases, only versions!
  • With aliases we can assign weights, to implement Blue/Green deployment
  • We can use CodeDeploy to shift the traffic (manage the weights)
    • Linear: Shift traffic every N minutes
    • Canary: Try X percent then 100%
    • AllAtOnce: immediate

Concurrency

  • Up to 1000 concurrent executions for all Lambda functions. If we have more than one lambda function, and we don’t set a limit, then if for any reason one of them reaches 1000 executions, the other functions will be throttled.
  • Reserver concurrency (limit the concurrency) ThrottleError – 429
    • Error for throttling: Rate Exceeded
  • Cold start: During the first request load the code, and can take more time than the next. Solved with Provisioned Concurrency. Concurrency is allocated before the function is invoked, so we never experience a cold start.

Events Types

  1. Synchronous invocations (behind an API GW, ALB, or trigger manually)
  2. Asynchronous Invocations
  3. Event Source Mapping

Asynchronous Invocations

  • S3(event notifications), SNS, Cloudwatch events / Eventbridge
  • Set the invocation type parameter to Event.
  • 3 Retries on errors. 1 immediately, 1 after one min, 1 after two min
  • We can define a dead letter queue. Send errors to SQS queue or SNS topic
  • Cloudwatch Events / EventBridge. Create an EventBridge to trigger the lambda function
    • We can set up cron to run periodically
  • S3 Events Notifications
    • On an S3 bucket, set up event notification properties.
      • On destination choose Lambda (other choices are SNS and SQS)
    • On lambda, we can process the events (for example the object creation)

Event Source Mapping

  • Lambda polls from services. Invoked synchronously
  • Create lambda -> Add Trigger -> Setup batch size
  • Streams
    • Services
      • Kinesis Data Streams
      • Dynamodb Streams
    • Works with batches. Multiple batches in parallel
      • If there is an error the entire batch is reprocessed
      • Up to 10 baches per shard
      • Processing is stopped in error, in order to maintain order.
  • Queues
    • Services
      • SQS & SQS FIFO
    • Long polling to SQS
    • DLQ should be set up to SQS queue, not lambda (cause lambda is synchronous, and DLQ is not supported)