DynamoDB Connection Pool Exhaustion: Raise maxConnections or Tighten Retry/Backoff?

In AWS SDK for Java v2, DynamoDB clients can intermittently exhaust the HTTP connection pool when request bursts outpace socket release. Two documented adjustments are often considered: increasing the maximum pool size via ApacheHttpClientBuilder.maxConnections, or tightening the retry policy with exponential backoff and jitter. Each has trade-offs.

Raising maxConnections permits more concurrent sockets, reducing lease contention, but increases client memory use and can amplify throttling if DynamoDB provisioned throughput is already saturated. Tightening retry/backoff lowers the rate of new requests during throttling, giving the pool time to recover, yet may add latency and starve requests under sustained load. The optimal balance depends on traffic burst patterns and table capacity.

An unresolved behavior is whether the async client reliably closes idle connections after connectionTimeToLive during network interruptions; if leaked sockets persist, pool exhaustion may continue despite either adjustment. This point may require verification against current SDK behavior.

Which adjustment should be prioritized for intermittent pool exhaustion: raising maxConnections or tightening retry/backoff? How should the two be combined when the workload is bursty but provisioned throughput is fixed? And does the async client’s idle-connection handling change the answer?