Choosing an AWS SDK Basics

Choosing an AWS SDK is mostly a language decision, not a capability one.

Because every SDK is generated from the same service model, the operations you need almost certainly exist in whichever language you pick. The real questions are which language your workload runs in, what runtime you deploy to, and how you install the client.

These seven examples walk that decision, five basic and two intermediate, in both Python (boto3) and TypeScript (AWS SDK v3).

Prerequisites

• Python: pip install boto3 (boto3 1.43.x, Python 3.10+). TypeScript: npm install @aws-sdk/client-s3 and add each service client you need (Node.js 18+).
• Credentials configured once via aws configure, environment variables, or an IAM role. The SDK resolves them automatically.
• A default region set with AWS_REGION or passed per client.
• A rough idea of your runtime: a long-running server, a short-lived Lambda, a browser app, or a local script.

Basic Examples

1. Start From the Language You Already Run

Pick the SDK for the language the workload lives in, not the other way around.

# --- Python (boto3) ---
import boto3
 
# A Python data job or Django backend? boto3 is the natural fit.
s3 = boto3.client("s3", region_name="us-east-1")
print("using boto3")

// --- TypeScript (AWS SDK v3) ---
import { S3Client } from "@aws-sdk/client-s3";
 
// A Node/TypeScript API or Lambda? AWS SDK v3 is the natural fit.
const s3 = new S3Client({ region: "us-east-1" });
console.log("using AWS SDK v3");

• Capability parity is high, so the language rarely limits which AWS operations you can call.
• Matching the SDK to your existing stack avoids adding a second language runtime.
• A Python-heavy team gains little by rewriting a working script in TypeScript, and vice versa.
• Deployment target matters too, covered in example 5.

Related: The AWS SDK Family: One Team, Many Languages - why parity is so high.

2. Install the Right Package

boto3 is one package for everything; SDK v3 is one package per service.

# --- Python (boto3) ---
# pip install boto3
# One install covers S3, DynamoDB, SQS, and every other service.
import boto3
 
ddb = boto3.client("dynamodb")

// --- TypeScript (AWS SDK v3) ---
// npm install @aws-sdk/client-dynamodb
// Install only the service clients you actually use.
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
 
const ddb = new DynamoDBClient({});

• boto3 bundles every service, so you never add per-service dependencies.
• SDK v3 is modular, so you install @aws-sdk/client-<service> for each service you touch.
• The modular approach keeps JavaScript bundles and Lambda cold starts small.
• Do not reach for the old aws-sdk v2 monolith on npm; v3 is the current line.

Related: Bundle Size & Cold Start: Why SDK v3's Modularity Matters - the packaging payoff.

3. Confirm the Operation Exists

Check the AWS API reference for the operation, then call it in your SDK.

# --- Python (boto3) ---
import boto3
 
# SQS SendMessage exists in every SDK; here it is in boto3.
sqs = boto3.client("sqs", region_name="us-east-1")
sqs.send_message(QueueUrl="https://sqs.us-east-1.amazonaws.com/123456789012/jobs",
                 MessageBody="hello")

// --- TypeScript (AWS SDK v3) ---
import { SQSClient, SendMessageCommand } from "@aws-sdk/client-sqs";
 
const sqs = new SQSClient({ region: "us-east-1" });
await sqs.send(new SendMessageCommand({
  QueueUrl: "https://sqs.us-east-1.amazonaws.com/123456789012/jobs",
  MessageBody: "hello",
}));

• The operation name (SendMessage) and inputs come from the shared service model, so both SDKs match the reference.
• boto3 exposes it as send_message; SDK v3 exposes it as SendMessageCommand.
• If the API reference lists an operation, your language's SDK almost always has it.
• Verify against the reference rather than assuming one SDK lacks a feature.

Related: The AWS SDK Family: One Team, Many Languages - the shared model.

4. Write the Same Call Both Ways

Seeing one operation in both SDKs makes the choice feel low-stakes.

# --- Python (boto3) ---
import boto3
 
s3 = boto3.client("s3")
s3.put_object(Bucket="my-bucket", Key="hello.txt", Body=b"hi")

// --- TypeScript (AWS SDK v3) ---
import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";
 
const s3 = new S3Client({});
await s3.send(new PutObjectCommand({ Bucket: "my-bucket", Key: "hello.txt", Body: "hi" }));

• The Bucket, Key, and Body inputs are identical because they come from one contract.
• boto3 calls a method; SDK v3 sends a command - the difference is syntax, not power.
• Porting a call between SDKs is usually mechanical once you know both surfaces.
• This is why "which SDK" rarely blocks a feature.

5. Let the Runtime Break Ties

When two languages are both viable, the deployment target decides.

# --- Python (boto3) ---
import boto3
 
# Long-running server or data job: startup cost is amortized, boto3 is fine.
s3 = boto3.client("s3", region_name="us-east-1")

// --- TypeScript (AWS SDK v3) ---
import { S3Client } from "@aws-sdk/client-s3";
 
// Lambda: modular v3 keeps the bundle small, so cold starts stay fast.
const s3 = new S3Client({ region: "us-east-1" });

• For servers and batch jobs, startup time is amortized, so either SDK works well.
• For Lambda, cold-start latency is per invocation, and SDK v3's small bundles help.
• Browser apps must use SDK v3 in TypeScript; boto3 is server-side Python only.
• Match the SDK to where the code runs, not just to personal preference.

Related: Bundle Size & Cold Start: Why SDK v3's Modularity Matters - the Lambda angle.

Intermediate Examples

6. Reuse a Client Across Calls

Whichever SDK you choose, build the client once and reuse it.

# --- Python (boto3) ---
import boto3
 
# Module scope: one client reused across many operations.
s3 = boto3.client("s3", region_name="us-east-1")
 
def upload(key, body):
    s3.put_object(Bucket="my-bucket", Key=key, Body=body)

// --- TypeScript (AWS SDK v3) ---
import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";
 
// Module scope: reused across invocations, including warm Lambdas.
const s3 = new S3Client({ region: "us-east-1" });
 
export async function upload(key: string, body: string) {
  await s3.send(new PutObjectCommand({ Bucket: "my-bucket", Key: key, Body: body }));
}

• Client construction sets up connection pools, so reuse is cheaper than rebuilding.
• In Lambda, define the client outside the handler so warm invocations reuse it.
• This habit is identical across SDKs, so it is not a differentiator when choosing.
• Reuse also keeps credential and endpoint resolution from repeating needlessly.

Related: Choosing an AWS SDK Best Practices - the habits behind a good default.

7. Mix SDKs When It Is Justified

A polyglot org can run more than one SDK, as long as the split is intentional.

# --- Python (boto3) ---
import boto3
 
# Data/ML pipeline in Python writes results to S3.
s3 = boto3.client("s3", region_name="us-east-1")
s3.put_object(Bucket="results", Key="run-1.json", Body=b"{}")

// --- TypeScript (AWS SDK v3) ---
import { S3Client, GetObjectCommand } from "@aws-sdk/client-s3";
 
// TypeScript API/Lambda reads the same object the Python job wrote.
const s3 = new S3Client({ region: "us-east-1" });
await s3.send(new GetObjectCommand({ Bucket: "results", Key: "run-1.json" }));

• Because the model is shared, the Python and TypeScript sides agree on bucket, key, and shape.
• A common split is a Python data layer with a TypeScript web and Lambda layer.
• Two SDKs means two dependency sets and two idioms, so keep the boundary clear.
• Mix by workload type, not per developer preference within one service.

Related: Mixing SDKs in One Organization - the trade-offs in depth.

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