InvalidParameterValueException: Lambda was unable to configure your environment variables because the environment variables you have provided exceeded the 4KB limit.

What it means

Lambda allows 4 KB for a function's entire environment — every key and every value, added together. There is no cap on how many variables you may have, and no cap on any individual one; the only thing measured is the total, and 4,096 bytes is less room than it sounds once real values are in it.

The limit is reached in two characteristically different ways. The first is a single large value: a PEM certificate, a private key, a service-account JSON document. Any one of those can take a quarter of the budget or more, and they end up in environment variables because it is the path of least resistance for getting a secret into a function. The second is accumulation. No individual variable is unreasonable, but a service that has collected endpoints, feature flags, table names, queue URLs and tuning parameters over a couple of years crosses the line on a change that adds almost nothing — which is why this so often appears alongside a trivial diff.

ARNs deserve a specific mention because they are so easy to overlook. A full ARN runs well past a hundred characters, and a function wired to a dozen resources is spending over a kilobyte on identifiers before any actual configuration. Passing resource names and constructing the ARNs in code, using the region and account already present in the runtime environment, recovers a surprising amount of room.

There is a security argument that points the same way as the size one. Environment variables are readable by anyone who can call GetFunctionConfiguration, and they appear in the console. If a certificate or an API key is what pushed you over 4 KB, the limit has surfaced a problem worth fixing rather than working around — Secrets Manager or Parameter Store solves both at once, and fetching at module scope means one call per execution environment rather than one per invocation.

None of this reaches CloudWatch Logs. The configuration is rejected, the function keeps its previous environment, and it carries on running exactly as before — so the only evidence is in the deployment's own output.

Where you'll see it

This failure happens before the function runs, so nothing about it reaches CloudWatch Logs — there is no invocation, and no log group entry to find. Once the deployment succeeds and the function starts running, the rest of this index covers what you will see there.

Causes, most likely first

Fixes

bashaws lambda get-function-configuration --function-name orders-fn \
  --query 'Environment.Variables' --output json |
python3 -c "
import json,sys
env = json.load(sys.stdin)
rows = sorted(((len(k) + len(v), k) for k, v in env.items()), reverse=True)
print(f'total {sum(n for n, _ in rows)} bytes across {len(rows)} variables\n')
for n, k in rows[:15]:
    print(f'{n:>6}  {k}')
"

jsimport { SecretsManagerClient, GetSecretValueCommand }
  from "@aws-sdk/client-secrets-manager";

const client = new SecretsManagerClient({});

// Module scope: one fetch per execution environment, not per invocation.
let cached;
async function signingKey() {
  cached ??= (await client.send(
    new GetSecretValueCommand({ SecretId: process.env.SIGNING_KEY_ID })
  )).SecretString;
  return cached;
}

yamlEnvironment:
  Variables:
    # Instead of forty individual settings:
    CONFIG_PARAM: /orders/prod/config
    AWS_REGION_OVERRIDE: !Ref AWS::Region

Also seen as

The same underlying failure, worded differently by a different runtime, SDK version, or logging layer. All of these land here — there is no separate page for each phrasing.

Related errors

Errors that show up alongside this one, or that people mistake for it.

References

• AWS Lambda Developer Guide — Using Lambda environment variables
• AWS Lambda Developer Guide — Lambda quotas