Can reusing a DynamoDB client across AWS Lambda warm invocations cause intermittent SignatureExpired errors?

Question

We recently encountered a very rare SignatureExpired exception when calling DynamoDB from an AWS Lambda function.

The error was similar to:
```
Signature expired:
 is not earlier than 
```
The issue has occurred only a couple of times despite processing thousands of Lambda invocations.

**Current implementation**
We initialize the DynamoDB client once and reuse it across warm Lambda invocations.
```
new aws.ddb.DynamoDB({
                region: AWS_REGION
            });
```

**Proposed change**
Instead of reusing the existing client, we are considering creating a new DynamoDB client for every Lambda invocation:
```
const ddb = new DynamoDB({
    region: AWS_REGION,
});

aws.ddb.set(ddb);
```

**Our hypothesis**

Our assumption is that a Lambda execution environment may remain idle for some time, and when it is reused, the existing DynamoDB client (or its underlying HTTP/signing state) could contribute to an occasional SignatureExpired error.
However, we have not found AWS documentation confirming whether client reuse can cause this.

**Questions**

Can reusing a DynamoDB client across warm Lambda invocations contribute to intermittent SignatureExpired errors?

Does the AWS SDK cache any signing timestamp or other state inside the DynamoDB client that could become stale after a Lambda execution environment has been idle?

Is creating a new DynamoDB client per invocation considered a recommended mitigation, or is it unnecessary?

Are there any scalability or performance drawbacks to creating a new DynamoDB client on every Lambda invocation instead of reusing it?
Has anyone observed similar behavior in production?

The error is extremely rare, so we're trying to determine whether changing the client lifecycle is the correct solution or whether we should continue investigating another root cause.

Leeroy Hannigan · Answer

#### Can client reuse cause SignatureExpired?
No. The DynamoDB client does not cache signing timestamps. Each request generates a fresh timestamp at signing time. The SignatureExpired error occurs when the signed timestamp deviates >15 minutes from the server clock, this is a clock skew issue, not a client state issue.

#### Does the SDK cache signing state that goes stale?
No signing timestamp is cached. The SDK does cache credentials (STS tokens), but credential staleness produces `ExpiredTokenException`, not `SignatureExpired`. These are distinct errors.

#### Root cause of your intermittent SignatureExpired
The most likely culprit: the Lambda execution environment's system clock drifted significantly while the environment was frozen/idle, then resumed with a skewed clock. AWS Lambda freezes the execution environment between invocations, in rare cases, after a very long idle period, the resumed environment can briefly have a stale clock before the hypervisor syncs it. This is an infrastructure-level edge case, not SDK behavior.

#### Should you create a new client per invocation?
No, this is the wrong mitigation and introduces real costs:
- TLS handshake overhead on every invocation (~50-100ms)
- Connection pool churn
- Higher memory pressure from repeated client instantiation

#### Recommended approach
Add retry logic specifically for `SignatureExpired` with a short delay, the clock corrects itself within seconds:

```javascript
// Retry config handles the rare clock skew case
const client = new DynamoDBClient({
  region: AWS_REGION,
  maxAttempts: 3,
});
```
Initialize once outside the handler. The SDK's built-in retry behavior does not retry `SignatureExpired` by default (it's treated as a client error), so you may want to implement a custom retry for this specific error code if frequency warrants it.

Bottom line: The error is caused by Lambda environment clock skew, not client reuse. Creating a new client per invocation will not fix it and degrades performance.

Can reusing a DynamoDB client across AWS Lambda warm invocations cause intermittent SignatureExpired errors?

Can client reuse cause SignatureExpired?

Does the SDK cache signing state that goes stale?

Root cause of your intermittent SignatureExpired

Should you create a new client per invocation?

Recommended approach

Add your answer

Relevant content