Lambda functions should use latest runtimes

Lambda runtimes that reach end-of-life stop receiving security patches from AWS and the upstream language maintainer. A function running python3.7 or nodejs14.x won't get fixes for newly discovered CVEs in the interpreter itself, leaving your workload exposed to known vulnerabilities no matter how clean your application code is.

Runtime migrations also compound in difficulty the longer you wait. A function two major versions behind may depend on deprecated standard library modules, changed default behaviors, or removed APIs. Migrating in smaller increments reduces the scope of each change and keeps your Lambda fleet within AWS's shared responsibility coverage for the managed runtime layer.

Retrofit consideration

Changing the runtime attribute on an existing aws_lambda_function triggers an in-place update, not a replacement, so the function stays live during the change. Language-level breaking changes, deprecated standard library modules, and SDK version incompatibilities can all cause handler failures after the update. Test in a non-production environment and validate your handler against the new runtime before rolling changes out across your fleet.

Implementation

Choose the approach that matches how you manage Terraform.

Compliance.tfOpen source moduleTerraform resources

Use the compliance.tf module to enforce this control by default. See get started with compliance.tf.

PCI DSS v4.0ACSC Essential EightNIST Cybersecurity Framework v1.1

module "lambda" {
  source  = "pcidss.compliance.tf/terraform-aws-modules/lambda/aws"
  version = ">=8.0.0"

  create_package         = false
  function_name          = "abc123"
  handler                = "index.lambda_handler"
  local_existing_package = "lambda_function.zip"

  runtime = "python3.14"
}

module "lambda" {
  source  = "acscessentialeight.compliance.tf/terraform-aws-modules/lambda/aws"
  version = ">=8.0.0"

  create_package         = false
  function_name          = "abc123"
  handler                = "index.lambda_handler"
  local_existing_package = "lambda_function.zip"

  runtime = "python3.14"
}

module "lambda" {
  source  = "nistcsfv11.compliance.tf/terraform-aws-modules/lambda/aws"
  version = ">=8.0.0"

  create_package         = false
  function_name          = "abc123"
  handler                = "index.lambda_handler"
  local_existing_package = "lambda_function.zip"

  runtime = "python3.14"
}

If you use terraform-aws-modules/lambda/aws, set the right module inputs for this control. You can later migrate to the compliance.tf module with minimal changes because it is compatible by design.

module "lambda" {
  source  = "terraform-aws-modules/lambda/aws"
  version = ">=8.0.0"

  create_package         = false
  function_name          = "abc123"
  handler                = "index.lambda_handler"
  local_existing_package = "lambda_function.zip"

  runtime = "python3.14"
}

Use AWS provider resources directly. See docs for the resources involved: aws_lambda_function.

resource "aws_lambda_function" "this" {
  filename                       = "lambda_function.zip"
  function_name                  = "pofix-abc123"
  handler                        = "index.handler"
  reserved_concurrent_executions = 100
  role                           = "arn:aws:iam::123456789012:role/example-role"
  source_code_hash               = "base64encodedhashabcdef1234567890=="

  runtime = "python3.14"
}

What this control checks

The control checks the runtime argument on aws_lambda_function resources. The value must be one of the approved runtime identifiers: nodejs20.x, nodejs18.x, nodejs16.x, python3.12, python3.11, python3.10, python3.9, python3.8, ruby3.3, ruby3.2, java21, java17, java11, java8.al2, dotnet8, or dotnet6. Functions set to anything outside this list, such as python3.7, nodejs14.x, dotnet5.0, or ruby2.7, fail. Container image functions (package_type = "Image") don't set runtime in the resource config because the runtime is embedded in the image; these may be excluded or evaluated separately depending on the evaluator. provided and provided.al2023 custom runtimes are not in the approved list, so functions using custom runtimes will also fail unless the evaluator explicitly excludes them.

Common pitfalls

Approved list drifts over time
AWS regularly deprecates runtimes and releases new ones. The approved list in your policy check can go stale in both directions: it may still include a runtime AWS has since deprecated, or it may not yet cover a newly released one like python3.13. Subscribe to AWS Lambda runtime deprecation announcements and treat the approved list as a living artifact that needs updating as AWS publishes new releases.
Container image functions bypass the runtime argument
Container image functions slip through this check entirely. When package_type is Image, the runtime argument isn't set on the Terraform resource because the runtime is baked into the container image. This control won't detect an outdated runtime inside the image. You need a separate image scanning strategy, such as ECR image scanning or a pipeline-level check, to cover those functions.
Terraform variable indirection hides runtime values
If runtime is set via a variable like var.lambda_runtime, static analysis tools and plan-time policy checks may not resolve the actual value, so violations slip through. Pin runtimes explicitly in your resource config, or add a validation block to the variable (e.g., validation { condition = contains(["python3.12","nodejs20.x"], var.lambda_runtime) }) to catch mismatches before plan.
Lambda@Edge runtime restrictions
Lambda@Edge only supports Node.js and Python, and the supported versions often lag behind standard Lambda. A CloudFront-associated function may have been deployed on the newest Edge-supported runtime at the time, yet still fail this control if that version has since been deprecated. Check the Lambda@Edge supported runtimes list separately from the standard Lambda list when validating edge functions.

Audit evidence

Auditors will want Config rule evaluation results showing all in-scope Lambda functions as compliant, typically from the lambda-function-settings-check managed Config rule with the runtime parameter set to the approved list. A direct inventory export from the Lambda ListFunctions API, filtered to the Runtime field across all regions, works as primary evidence. Output from open-source scanning tools like Prowler or Steampipe enumerating non-compliant runtimes and showing zero findings strengthens the package.

Framework-specific interpretation

PCI DSS v4.0: Requirement 6.3.3 calls for patching known vulnerabilities based on risk ranking. Running a supported Lambda runtime keeps functions within the vendor patch cycle; EOL runtimes sit outside it, meaning newly published CVEs in the interpreter won't be addressed. Using supported runtimes is one approach to meeting the patch-coverage intent of the broader Requirement 6.3 patch-management controls.

ECS fargate services should run on the latest fargate platform version

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

Compliance.tf Control: lambda_function_use_latest_runtime
AWS Config Managed Rule: LAMBDA_FUNCTION_SETTINGS_CHECK
Checkov Check: CKV_AWS_363
Powerpipe Control: aws_compliance.control.lambda_function_use_latest_runtime
Prowler Check: awslambda_function_using_supported_runtimes
AWS Security Hub Control: Lambda.2

Last reviewed: 2026-03-09