Question: Should you make a new DynamoDB client for each request?

Answer

No. Reuse a DynamoDB SDK client for requests that share the same Region, endpoint and credential configuration. Creating a fresh client for every call can discard reusable HTTP connections and add setup latency.

In Node.js, create the v3 client once at module scope and wrap it in a reusable DynamoDBDocumentClient. In Lambda, initialize it outside the handler so later invocations in the same execution environment can reuse it. Put request-specific keys and values in command objects, not in mutable shared application state.

AWS SDK for JavaScript v3 reuses TCP connections by default in Node.js. You generally do not need a pool of separate DynamoDB client objects. Configure request timeouts, retries and HTTP concurrency on the shared client when the workload needs them.

Create separate clients when configurations genuinely differ, such as different Regions, local testing endpoints or distinct credential providers. Prefer refreshable credential providers over copying expiring credentials into a static object.

Client thread-safety differs by SDK and abstraction. For example, do not assume boto3 resource objects have the same sharing guarantees as clients. Check your language's documentation before sharing across threads or processes, and close resources at application shutdown where required.

See connection pooling and Node.js examples.

Source: AWS connection reuse.