Choosing an AWS SDK Best Practices
Choosing an SDK well is less about the perfect pick and more about a consistent default.
//
Busca en todas las páginas de la documentación
Choosing an SDK well is less about the perfect pick and more about a consistent default.
Because every AWS SDK shares the same service model, capability rarely decides. What matters is matching the SDK to the workload, using current versions, and keeping any multi-SDK split intentional.
Walk this list once, then use it as a review checklist whenever you start a new service or add a language to the stack.
Match the SDK to where the code already lives.
# --- Python (boto3) ---
import boto3
# Default for Python data/backend workloads.
s3 = boto3.client("s3", region_name="us-east-1")// --- TypeScript (AWS SDK v3) ---
import { S3Client } from "@aws-sdk/client-s3";
// Default for TypeScript web/Lambda workloads.
const s3 = new S3Client({ region: "us-east-1" });@aws-sdk/client-* v3 line is modular and current; the aws-sdk v2 monolith is retired.boto library is long obsolete.@aws-sdk/client-<service> per service and bundle with tree-shaking.Keep JavaScript imports narrow so bundles stay lean.
# --- Python (boto3) ---
import boto3
# One monolith install; reuse the client, no per-service package needed.
ddb = boto3.client("dynamodb", region_name="us-east-1")// --- TypeScript (AWS SDK v3) ---
// Narrow import → smaller bundle → faster Lambda cold start.
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
const ddb = new DynamoDBClient({ region: "us-east-1" });Pick a default SDK per language and workload type, and stick to it. Consistency across the org matters more than the exact choice, since capability parity is high.
No, for new work. v3 (@aws-sdk/client-*) is the current, modular, actively developed line. The v2 aws-sdk monolith is retired and bloats bundles and cold starts.
Almost never. All SDKs are generated from the same models, so operation coverage is near-identical. Choose on language, runtime, and ergonomics instead.
Mainly on Lambda in JavaScript, where SDK v3's modular packages shrink bundles and cut cold-start latency. On servers, the difference is negligible because startup is amortized.
Match the team and runtime. Use Python/boto3 for data and existing Python backends; use TypeScript/SDK v3 for web APIs, Lambda, and anything browser-facing.
No, if the split follows workload boundaries. Both call the same services, so they interoperate cleanly. The cost is maintaining two dependency sets and two idioms.
Document the default per workload type and per language. A written default lets new services inherit the decision instead of debating it each time.
Yes. Lock the version in your dependency file so upgrades are deliberate. This is especially important for JavaScript, where you should also bundle your own pinned v3 clients.
Use their current lines - Go v2, Java 2.x, and the current .NET and Rust SDKs. Choose them when a team already lives in that language, not for extra AWS capability.
Emit them from IaC outputs or shared config that every language consumes. Hardcoding names separately in each SDK invites drift and mismatched calls.
Yes. In a mixed org, a permission or handling gap on either SDK exposes the shared resource, so audit every SDK path rather than just the dominant one.
Whenever a new workload class appears - edge functions, streaming, browser code - or when an SDK ships a major version. Reconfirm the default still fits the new constraints.
Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).
Revisado por Chris St. John·Última actualización: 23 jul 2026