Feature request: Support correct cold start detection for non-on-demand invocation types

[phipag]

Use case

When using provisioned concurrency or other non-on-demand invocation types in Lambda functions, the first invocation is not necessarily a cold start. For instance, SnapStart doesn't have cold starts at all (only restores).

Currently, Powertools incorrectly identifies these scenarios as cold starts, leading to:

• Cold start metrics being emitted when they shouldn't be
• JSON logs showing cold_start: true field incorrectly
• Traces having ColdStart: true annotation when inappropriate

This creates inaccurate observability data for Lambda functions using provisioned concurrency or SnapStart.

Solution/User Experience

All function executions which do not have AWS_LAMBDA_INITIALIZATION_TYPE="on-demand" should:

• NOT emit a cold start metric
• NOT set cold_start: true in the structured JSON logs
• NOT set the ColdStart annotation in traces

Implementation approach:
Use the AWS_LAMBDA_INITIALIZATION_TYPE environment variable within the utilities to suppress cold start behavior if the init type is not on-demand. Consider all init types from the AWS docs: https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html#configuration-envvars-runtime

Update the global LambdaHandlerProcessor to have more nuanced cold start detection logic:

powertools-lambda-java/powertools-common/src/main/java/software/amazon/lambda/powertools/common/internal/LambdaHandlerProcessor.java

Line 35 in 22ea06a

private static Boolean IS_COLD_START = null;

Code example:

@Logging(logEvent = true)
@Tracing
@FlushMetrics(namespace = "TriagingTemplate", service = "triage", captureColdStart = true)
public APIGatewayProxyResponseEvent handleRequest(APIGatewayProxyRequestEvent input, Context context) {
    // With provisioned concurrency, this should NOT be marked as cold start
    logger.info("Processing triage request");
    metrics.addMetric("TriageRequests", 1, MetricUnit.COUNT);
    // ... rest of handler
}

Reproduction steps:
Deploy a Lambda function with provisioned concurrency using this SAM template. You can use the Powertools triaging template for this: https://github.com/phipag/powertools-triaging-template-java

TriageFunction:
  Type: AWS::Serverless::Function
  Properties:
    CodeUri: .
    Handler: triage.TriageHandler::handleRequest
    AutoPublishAlias: live
    ProvisionedConcurrencyConfig:
      ProvisionedConcurrentExecutions: 1

Alternative solutions

Using AWS_LAMBDA_INITIALIZATION_TYPE is the most reliable and AWS-native approach.

Acknowledgment

• This feature request meets Powertools for AWS Lambda (Java) Tenets
• Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, TypeScript, and .NET

---

Future readers: Please react with 👍 and your use case to help us understand customer demand.

[dreamorosi]

I don't think this is a bug, just a capability we don't support yet.

Also, the same logic should apply to the cold_start field in the Logger logs, and the ColdStart annotation on Tracer segments.

Unsure what's the best way to centralize this logic so that all three utilities get it, but perhaps the issue could use some additional details to help contributors understand the steps to take.

[phipag]

I mainly framed it as a bug given that it reported a cold start under a condition where a cold start is not possible. But, I am also happy to re-phrase it into a feature request issue.

You are right, I should add more details for contributors. Will do that.

In fact, we already have a centralized logic for cold start calculations which only needs a small update reacting to the environment variable. Then, Metrics, Logger, Tracing should pick that up. Good call-out with the Tracing utility which I neglected.

powertools-lambda-java/powertools-common/src/main/java/software/amazon/lambda/powertools/common/internal/LambdaHandlerProcessor.java

Line 35 in 22ea06a

private static Boolean IS_COLD_START = null;

[dcabib]

Need help?

[dreamorosi]

I see you have several PRs open across projects, all of which need refactoring or adjustments of varying degrees.

You're free to take this, but we'd rather prioritize quality over quantity.