AWS Notes

Lambda Functions

Last updated
Reading time
4 min read

Overview

Lambda functions allow for code to be run in a serverless environment. The run on a server, but deploying an EC2 instance isn't required so there aren't any direct interactions or server configurations to deal with. Many different programming languages and run-times are supported, and every type of function is associated with a trigger that causes the function to run.

Types of triggers

There are a lot of different services that can trigger a function, but here are a few high-level categories:

  1. API Gateway for HTTP Triggers

    • by HTTP request where functions are serverless APIs or webhooks
    • Can be used to receive requests and securely interface with another service or database rather than providing direct access

  2. Database / Storage Triggers

    • by changes to an S3 bucket
    • by updates to tables in DynamoDB or by RDS database events
    • Can be used for data synchronization or image processing

  3. Messaging and Event Triggers

    • by CloudWatch events or by SQS or SNS messages
    • Can analyze a CloudWatch log or handle notifications

  4. Authentication Triggers

    • by Cognito events like a user sign up
    • Can be used to customize sign ups

Configurations

  1. Memory

    • Dictates the amount of memory a function has at runtime
    • Proportionally increases CPU power
    • Allows from 128 MB up to 10,240 MB

  2. Ephemeral Storage

    • Temporary storage that is encrypted and unique to each function execution
    • Allows from 512 MB up to 10,240 MB

  3. Timeout

    • Longest time a function can run in seconds
    • Allows up to 900 seconds (15 minutes)

  4. Environment Variables

    • Define variables to use in the function's code
    • Secure at rest using KMS to encrypt
    • Can increase security in transit by enabling client-side helpers to encrypt variables on a per-variable basis
    • Not recommended for storing database credentials (use Secrets Manager instead)

Edge Functions

There are two primary ways of integrating Lambda functions to work with the edge (view the next post for more about CloudFront & The Edge). Using CloudFront, Lambda@Edge can run code on the edge. Alternatively, API enabled Lambda Functions can cache responses on the edge to reduce latency when the data and request do not yet need to be revalidated. Here are details for each option:

  1. Lambda@Edge (not an origin)

    • Code runs at the edge location
    • Function deployed to a CloudFront distribution
    • Designed to be used like middleware in that it is an intermediary between an end-user and an origin during the request/response processing that can updates the requests and responses dynamically
    • Triggered by a CloudFront event:
      Viewer Request
      When CloudFront receives a request from and end-user
      Viewer Response
      When CloudFronts ready to reply to the end-user
      Origin Request

      When CloudFront forwards request to an origin, if content is not already cached on the edge

      Origin Response
      When CloudFront receives reply from an origin

  2. API Gateway (Lambda Function as an origin)

    • Code does not actually run on the edge, only the responses are cached based on a configurable caching policy like what gets cached and for how long
    • Setup Lambda Function triggered by REST API gateway - (REST recommended over HTTP API for Edge)
    • CloudFont returns cached response if they are still valid subject to cache control headers like max-age or must-revalidate
    • Invalidation of a cached response can be handled manually by updating a versioned URL path or with the cache invalidation API
    • Programmatic invalidation example - Origin server can trigger cache invalidation manually where a lambda function with a database trigger issues an invalidation request using the AWS SDK