Performance & Cost Best Practices

These are the defaults every SDK-heavy service should set before scaling, not discover from a slow endpoint or a surprise invoice.

Walk the list once now, then use it as a review checklist before shipping any code that constructs clients, loops over items, or runs calls in parallel.

How to Use This List

• Each item is a rule stated positively, with a one-line rationale.
• Groups run roughly in order of impact: client reuse first, then batching, concurrency, cost habits, and load testing.
• Check the boxes against your own code as a quick audit.
• Revisit whenever you add a new service client, move code into a higher-throughput path, or change a Lambda handler.

A - Client Reuse & Connection Pooling

• Construct each client once, at module scope. Build it outside any handler or loop, in both boto3 and SDK v3, so its connection pool is reused across calls.
• In Lambda, keep client construction above the handler function. A client built inside the handler pays connection setup on every invocation, warm or cold.
• Size the pool to expected concurrency. Set max_pool_connections (boto3) or an Agent({ maxSockets }) on NodeHttpHandler (SDK v3) to roughly the number of concurrent in-flight calls on that client.
• Trust that clients are safe to share. boto3 clients are thread-safe and SDK v3 clients are safe across concurrent async calls; don't build one client per worker out of caution.
• Never rebuild a client per item in a loop. That recreates the cold-pool cost the loop is trying to avoid.

Build the client once; call it many times.

# --- Python (boto3) ---
import boto3
from botocore.config import Config
 
cfg = Config(max_pool_connections=25)
s3 = boto3.client("s3", config=cfg)   # module scope, reused everywhere

// --- TypeScript (AWS SDK v3) ---
import { S3Client } from "@aws-sdk/client-s3";
import { NodeHttpHandler } from "@smithy/node-http-handler";
import { Agent } from "node:https";
 
const s3 = new S3Client({
  requestHandler: new NodeHttpHandler({ httpsAgent: new Agent({ maxSockets: 25 }) }),
});   // module scope, reused everywhere

B - Batching

• Use batch APIs for bulk writes and deletes. SendMessageBatch (SQS), BatchWriteItem (DynamoDB), and DeleteObjects (S3) each replace many single-item calls with one.
• Chunk to each API's own limit. 10 for SQS batch operations, 25 for BatchWriteItem, 1,000 for DeleteObjects - exceeding the limit is a validation error, not a partial batch.
• Always check the failure/unprocessed list. Failed, UnprocessedItems, and Errors fields can carry partial failures even when the call itself succeeds.
• Retry unprocessed entries with backoff, not a tight loop. UnprocessedItems often means the partition was momentarily throttled.
• Don't treat a batch API as a transaction. Use TransactWriteItems instead when items must all succeed or all fail together.

Batch the writes; check the partial-failure list every time.

# --- Python (boto3) ---
resp = ddb.batch_write_item(RequestItems=request_items)
unprocessed = resp.get("UnprocessedItems", {})   # always check this

// --- TypeScript (AWS SDK v3) ---
const resp = await ddb.send(new BatchWriteItemCommand({ RequestItems: requestItems }));
const unprocessed = resp.UnprocessedItems ?? {};   // always check this

C - Concurrency & Backpressure

• Bound parallel SDK calls explicitly. Use asyncio.Semaphore with aioboto3, or a worker-pool pattern, in Python; use p-limit or a small helper in TypeScript.
• Size the concurrency limit against the connection pool. A limit above the pool size just moves queuing from your limiter to the pool.
• Pair concurrency limits with retry/backoff, not instead of it. A limit reduces throttling; retries absorb the throttling that still happens.
• Watch the throttling error rate, not just latency, when tuning the limit. A rising throttling rate under load is the signal to lower it.
• Consider aggregate concurrency across processes. A per-process limit doesn't protect a shared table or endpoint from many processes at once; use a shared queue if it does.

Cap in-flight calls; let retries handle the rest.

# --- Python (boto3) ---
sem = asyncio.Semaphore(10)   # at most 10 concurrent calls

// --- TypeScript (AWS SDK v3) ---
const limit = pLimit(10);   // at most 10 concurrent calls

D - Cost-Aware Usage

• Prefer long polling over short-interval polling. Set WaitTimeSeconds on SQS ReceiveMessage, or use waiters, instead of a tight poll loop.
• Prefer events over polling where possible. EventBridge, SNS, and SQS triggers remove polling cost entirely.
• Filter S3 listings server-side and avoid re-listing broad prefixes repeatedly. Every LIST call is a billed operation.
• Right-size DynamoDB capacity mode and Lambda memory to the actual workload. Neither the on-demand default nor a generous memory setting is automatically the cheapest choice.
• Keep CloudWatch custom metric dimensions low-cardinality. A raw user ID or request ID in a dimension multiplies billed unique metrics; push identifiers into logs instead.

Wait for data instead of asking for it repeatedly.

# --- Python (boto3) ---
resp = sqs.receive_message(QueueUrl=queue_url, WaitTimeSeconds=20)

// --- TypeScript (AWS SDK v3) ---
const resp = await sqs.send(new ReceiveMessageCommand({ QueueUrl: queueUrl, WaitTimeSeconds: 20 }));

E - Load Testing

• Load test before scaling, not after an incident. Validate concurrency limits, pool sizing, and capacity settings against realistic traffic first.
• Model a realistic ramp/hold/ramp-down shape, not a flat maximum blast. Bursty production traffic fails differently than a steady maximum-throughput test.
• Drive load through the real entry point, not directly against the AWS SDK. The test must exercise the same client reuse and concurrency limits production uses.
• Watch throttling rate and tail latency, not just average latency. Connection pool queuing and early throttling usually show up there first.
• Feed results back into concurrency limits, pool sizes, and capacity mode. A pass/fail result alone doesn't tell you what to tune.

Ramp traffic up and down; watch tail latency and throttling, not just the average.

# --- Python (boto3) ---
# locustfile.py: wait_time models think time, not max throughput
from locust import HttpUser, task, between
 
class ServiceUser(HttpUser):
    wait_time = between(1, 3)
 
    @task
    def call_endpoint(self):
        self.client.get("/sessions/user-123")

// k6 script targeting a Node/SDK v3-backed endpoint
export const options = {
  stages: [
    { duration: "2m", target: 50 },
    { duration: "5m", target: 50 },
    { duration: "2m", target: 0 },
  ],
};

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).