Ref: https://learn.cantrill.io/courses/1820301/lectures/41301393

• Summary:
• Contents:

AWS Lambda - Cold vs Warm Starts

Diagram: https://github.com/acantril/aws-sa-associate-saac03/blob/main/1600-SERVERLESS_and_APPLICATION_SERVICES/00_LEARNINGAIDS/Lambda-8.png

• 🔧 Lambda code runs inside a RTE, i.e. an execution context
  • 💡 Think of it as small container with resources that run the Lambda code
  • ‼️ Even if functions can potentially reuse execution contexts from previous invocations, they must be generally configured to be STATELESS!
    • Assume they need to provision a brand new execution context upon invocation!
• Cold start = Lambda creates a brand new execution context upon invocation:
  1. Environment itself gets created (needs physical HW)
  2. Required runtimes (core libraries, packages, interpreters…) downloaded & installed
  3. Deployment package (your code, 3rd-party libraries…) is downloaded & installed
  • ❗ All of the above take time!
    • Cold starts can take hundreds of milliseconds or more
    • Significant in synchronous invocations where a human is awaiting a response
• Warm start = Lambda reuses part or whole execution context from a previous invocation
  • First time a function is called, it must be a cold start
    • 💡 …unless using provisioned concurrencies, check next section
  • If first function completes, and the same function is invoked again after not so much time, Lambda will probably use the same execution context → warm start
  • 👍 No need to set up environment nor download packages, since execution context is already there → faster starts
    • Function can begin processing immediately
    • Code can be running within a few milliseconds
• ‼️ A Lambda function must assume it can NOT reuse execution context!! → stateless
  • Execution context gets removed if idle
    • If function invoked infrequently, it will normally require cold starts
  • ❗ Concurrent executions will use multiple (potentially new) contexts!!
    • 💡 20 parallel executions will result in 20 cold starts because one function uses one whole execution context

AWS Lambda - Options to Improve Latency

• Purchase provisioned concurrency → tell AWS to create and keep X amount of execution contexts warm & ready to use → improves start speeds
  • Example use cases:
    • Expected higher load periods at a given time
    • Pre-create all execution environments before a PROD release, make sure customer experience is not degraded
• Use the /tmp allocated space
  • Example: pre-download heavy media images used as part of processing → function that uses that execution context will not need to redownload the images
  • ❗ Be careful! Functions need to be able to cope if environment is brand new & clean! They can never assume the presence of anything!
    • In previous example, have the function be able to download the media images if it can't find them in /tmp
• Define commonly reused components OUTSIDE the Lambda function handler code
  • Most of function code goes inside Lambda function handler…
    • …but anything defined outside is made available for any future invocations in the same context!
  • Example: DB connections → they are costly to establish, but a long-lasting connection can be reused by many successive Lambda invocations → saves time & costs
  • ❗ Again, be careful! Make sure the function can fetch required information if needed, don't make it depend on external configuration
    • In previous example, if a new DB connection needs to be established, the Lambda function should be able to do it itself
• 🔧 CONCLUSION: configure common components to persist through different invocations to improve efficiency… BUT! Every time a function is executed, it should be able to recreate everything if needed!