Introduction

Code that runs both locally and inside AWS Lambda often needs small environment-specific decisions, such as where to write temporary files, how aggressively to log, or whether credentials come from the Lambda execution role. The most practical way to detect Lambda is to check for environment variables that AWS injects into the runtime.

Use Lambda-Specific Environment Variables

AWS Lambda sets several variables only when the function is running in the Lambda environment. The most commonly checked ones are:

• 'AWS_LAMBDA_FUNCTION_NAME'
• 'AWS_LAMBDA_FUNCTION_VERSION'
• 'AWS_EXECUTION_ENV'
• 'LAMBDA_TASK_ROOT'

Checking one well-known variable is usually enough. Checking two can make the logic a little more defensive.

1import os
2
3
4def is_running_in_lambda() -> bool:
5    return (
6        "AWS_LAMBDA_FUNCTION_NAME" in os.environ
7        and "LAMBDA_TASK_ROOT" in os.environ
8    )
9
10
11if __name__ == "__main__":
12    if is_running_in_lambda():
13        print("Running inside AWS Lambda")
14    else:
15        print("Running outside AWS Lambda")

This approach is fast, readable, and works in every language runtime because it depends on process environment, not on SDK features.

Keep the Detection Logic in One Place

Instead of scattering checks across the codebase, wrap the logic in a helper. That keeps tests simple and makes future changes easy if you later add support for another serverless platform.

1import os
2from dataclasses import dataclass
3
4
5@dataclass(frozen=True)
6class RuntimeInfo:
7    in_lambda: bool
8    function_name: str | None
9
10
11def get_runtime_info() -> RuntimeInfo:
12    function_name = os.getenv("AWS_LAMBDA_FUNCTION_NAME")
13    return RuntimeInfo(
14        in_lambda=function_name is not None,
15        function_name=function_name,
16    )

A small abstraction like this is usually better than repeated raw environment lookups in unrelated modules.

Node.js Example

The same idea applies in Node.js.

1function isRunningInLambda() {
2  return Boolean(
3    process.env.AWS_LAMBDA_FUNCTION_NAME && process.env.LAMBDA_TASK_ROOT
4  );
5}
6
7if (isRunningInLambda()) {
8  console.log("Lambda runtime detected");
9} else {
10  console.log("Not running in Lambda");
11}

The exact variable names are the important part, not the language.

What This Check Is Good For

Environment detection is useful for configuration choices that should vary by runtime, such as:

• using /tmp only in Lambda
• enabling structured cloud logs
• selecting local mocks outside Lambda
• skipping startup behavior that only makes sense on a developer machine

The key is to keep the branching narrow. Your business logic should not care where it runs unless the platform genuinely changes behavior.

What Not To Use as the Primary Signal

Do not make SDK calls to AWS just to decide whether you are in Lambda. That adds latency, depends on credentials, and fails in exactly the situations where startup needs to stay robust.

Filesystem checks are also weaker as a primary signal. For example, some local test harnesses can mimic Lambda paths or variables. If you want stronger confirmation, combine a couple of environment variables instead of probing the platform indirectly.

Local Testing and Emulators

Local tools such as AWS SAM or serverless offline frameworks may set the same environment variables intentionally. That is not a bug. It usually means your code is running in a Lambda-like environment, which is exactly what the local tool is trying to simulate.

If you need to distinguish real AWS infrastructure from local emulation, add your own explicit flag such as APP_ENV=local rather than trying to infer too much from Lambda variables alone.

Avoid Over-Coupling to the Platform

Detection should inform configuration, not infect the whole architecture. A good pattern is:

• detect runtime once
• convert the result into a small config object
• pass that config to the parts of the app that need it

That way, moving code into containers, EC2, or another function platform later does not require a full rewrite.

Common Pitfalls

A common mistake is checking only one very generic variable and assuming it proves too much. For example, AWS_REGION may appear in environments other than Lambda.

Another mistake is repeating os.getenv or process.env checks throughout the codebase. That makes behavior inconsistent and harder to test.

Some teams also use detection to branch business logic heavily. If the code path changes too much between local and Lambda runs, defects become environment-specific and harder to reproduce.

Finally, remember that local emulators may intentionally define Lambda variables. If you need “real AWS” detection, model that separately.

Summary

• Detect Lambda by checking Lambda-specific environment variables.
• Put the check in one helper instead of spreading it throughout the codebase.
• Use the result for configuration, logging, and runtime-specific setup.
• Do not make network calls just to identify the platform.
• Separate “Lambda-like local emulation” from “real AWS” only when the application truly needs that distinction.