Introduction

AWS Lambda exposes configured environment variables to Java functions through the normal process environment. That means the basic API is just System.getenv(...). The real engineering concerns are naming, null handling, secrets management, and making local development behave similarly to the deployed Lambda runtime.

Read Variables with System.getenv

The direct Java call is:

1public class ConfigExample {
2    public static void main(String[] args) {
3        String bucket = System.getenv("BUCKET_NAME");
4        System.out.println(bucket);
5    }
6}

In a real Lambda handler:

1import com.amazonaws.services.lambda.runtime.Context;
2import com.amazonaws.services.lambda.runtime.RequestHandler;
3
4import java.util.Map;
5
6public class Handler implements RequestHandler<Map<String, Object>, String> {
7    @Override
8    public String handleRequest(Map<String, Object> input, Context context) {
9        String stage = System.getenv("APP_STAGE");
10        return "Running in stage: " + stage;
11    }
12}

This is all Lambda requires on the code side. If the variable exists in the function configuration, Java reads it like any other environment variable.

Configure the Variables in Lambda

The code only works if the variables are actually defined in the function configuration. In infrastructure-as-code, that might look like this in AWS SAM:

1Resources:
2  MyFunction:
3    Type: AWS::Serverless::Function
4    Properties:
5      Handler: example.Handler::handleRequest
6      Runtime: java17
7      Environment:
8        Variables:
9          APP_STAGE: prod
10          BUCKET_NAME: my-app-bucket

The same concept applies in the AWS Console, CloudFormation, Terraform, or CDK. The Java code does not care how the variable got there. It only cares whether it exists at runtime.

Fail Clearly When Required Variables Are Missing

For required configuration, wrap access in a small helper instead of scattering null checks through the code:

1public final class Env {
2    private Env() {
3    }
4
5    public static String required(String key) {
6        String value = System.getenv(key);
7        if (value == null || value.isBlank()) {
8            throw new IllegalStateException("Missing required environment variable: " + key);
9        }
10        return value;
11    }
12}

Usage:

String bucket = Env.required("BUCKET_NAME");

This makes configuration failures immediate and explicit, which is far better than letting the function fail later with a vague NullPointerException.

Keep Secrets and Configuration Separate

Lambda environment variables are convenient, but not every value belongs there in plain form. For credentials or sensitive tokens, use a proper secret-management strategy such as:

• AWS Secrets Manager
• AWS Systems Manager Parameter Store
• encrypted environment variables only when that fits the operational model

Environment variables are best for non-secret configuration such as:

• stage names
• feature flags
• endpoint URLs
• bucket names

That separation keeps the configuration model simpler and reduces accidental secret sprawl.

Mirror the Setup in Local Development

Local testing is easier if your code reads environment variables the same way everywhere. For example, you can set them before launching the JVM:

export APP_STAGE=dev
export BUCKET_NAME=my-local-bucket
./mvnw test

Or in an IDE run configuration. The key is that local and Lambda code paths should both go through System.getenv, so the handler logic itself does not need environment-specific branches.

Common Pitfalls

• Expecting Lambda-specific Java APIs when normal System.getenv is already the correct access method.
• Reading variables without validating that required ones are present.
• Putting secrets and ordinary configuration into the same casual environment-variable workflow.
• Hardcoding fallback defaults in code that hide deployment misconfiguration.
• Testing locally with one configuration path and deploying with a completely different one.

Summary

• In Java Lambda code, environment variables are accessed with System.getenv.
• The code path is simple; the real work is configuring and validating the variables correctly.
• Use helper methods for required configuration so failures are clear.
• Keep non-secret config separate from secret-management concerns.
• Make local development read environment variables the same way as the deployed Lambda function.