Lambda

Introduction

• A serverless compute service to run your code

Feature

• Support language: C#, Java, Node, Python, Javascript, etc.

• Lamda is charged with request times, duration, used memory.

• Limits:

  • RAM: 128 ~ 3G

    • RAM is linked to CPU allocation (cannot be set accrodingly)

    • 2 vCPU are allocated after 1.5G of RAM

  • Timeout: 15 minutes (Can break into sub executions but be careful with the latency.)

  • /tmp storage: 512 MB (can't process big files)

  • Councurrency execution: 1000 (differs by region, can be requested to increase).

  • If your code is too large to upload and can not break the code down

    • Consider deploying with Elastic BeanStalk.

• Security

  • IAM Roles policy: for Lambda execution.

  • Resource-based policy: allow other accounts, services to invoke / manage the Lambda.

  • Networking

    • Sits in the AWS VPC (by default)

      • Can access publicly

      • Cannot link to resources in a private Subnet.

    • Can create within your VPC

      • To access a resource in a private Subnet, the Lambda must be created within the private Subnet and do:

        • Assign Security Group with outbound rule to the Lambda

        • Use a NAT if needs to have a public access.

        • Can attach VPC Endpoint to asscess S3 / DynamoDB without requiring an IGW to save cost.

      • Reasons of EC2ThrottledException:

        • ​Does not have sufficient subnet IPs / subnet ENIs.

• Logging, monitoring and tracing

  • CloudWatch: trace logs, metrics. (Make sure the Lambda has execution role with CloudWatch privilege).

  • X-Ray:

    • Can help debug / trace the end-to-end latency.

    • Enable in Lambda configuration (runs the X-Ray daemon for you)

    • Use AWS SDK in Code

    • Ensure Lambda has correct IAM execution role.

• Invocation

  • Synchronous: by CLI, SDK, API Gateway

    • Clients waiting for the response.

    • Handling exception by client side.

  • Asynchronous: like S3, SNS, CloudWatch events

    • When error, Lambda woud attempt for 3 retries. (so make sure the process is idempotent).

    • Can define a destination or DLQ (dead-letter queue, supports SNS, SQS, Lambda for failed processing).

  • Event Source Mapping (Poll model, by another Lambda to trigger your Lambda)

    • In-ordered services: Kinesis data streams, SQS FIFO, DynamoDB streams and SQS (not guarenteed in-ordered) are supported.

    • Lambda Event Source Mapping would do poll from the source and send to Lambda function in a batch way.

    • If Lambda returns an error, the entire batch is reprocessed until success.

      • Kinesis, DynamoDB streams: would stop processing later shards.

      • SQS FIFO: stop, unless a SQS DLQ has been defined.

• Destinations (AWS suggests to replace DLQ)

  • Can configure to send result to a destination.

  • Asynchronous: can define destinations for successful and failed events to:

    • SQS

    • SNS

    • Lambda

    • EventBridge Bus

  • Event Source Mapping: for discarded event batches (only for failures).

    • SQS

    • SNS

• Versions

  • When you work on a Lambda function, we work on $LATEST. When publish a Lambda, a version is created.

  • Versions

    • are immutable.

    • have increasing version numbers.

    • get their own ARN.

    • include their code and configurarion.

    • can be accessed.

  • Aliases are pointers to Lambda versions.

    • Aliases are mutable and have ARNs.

    • Aliases enable stable configuration of event triggers / destinations.

    • Deployment to shift alias can be supported with CodeDeploy strategies:

      • Linear: grow traffic every N minutes until 100%.

      • Canary: try X percent then 100%.

      • AllAtOnce: immediate.

    • Can create pre & post traffic hooks to check the health of Lambda.

    • Scenarios:

      • can define a dev, test etc to point to a Lambda version.

      • can enable blue / green deployment by assigning weights to point to different Lambda versions.