The AWS SDK Family: One Team, Many Languages
AWS ships a different SDK for every major language, yet they all feel like siblings.
//
Busque em todas as páginas da documentação
AWS ships a different SDK for every major language, yet they all feel like siblings.
boto3 in Python, the AWS SDK for JavaScript v3 in TypeScript, plus SDKs for Go, Java, .NET, Rust, and more - each is its own package, but none of them invents its own set of AWS operations.
This page explains why the whole family stays in sync, so the rest of this section reads as a comparison of ergonomics rather than capability.
An AWS service like S3 or DynamoDB is defined once, as a machine-readable contract.
That contract lists every operation the service supports (ListBuckets, GetItem, SendMessage), the exact inputs each takes, and the shape of each response. AWS maintains this model internally, today largely expressed in Smithy, its interface definition language.
Each SDK is then code-generated from those models. The team does not hand-write a list_buckets method in Python and a separate ListBuckets command in TypeScript from scratch; both are produced from the same S3 definition.
That is why the family stays consistent. A new operation added to a service flows into every SDK through the same generation pipeline.
Here is the same S3 operation in the two SDKs this site focuses on.
# --- Python (boto3) ---
import boto3
s3 = boto3.client("s3")
response = s3.list_buckets()
for bucket in response["Buckets"]:
print(bucket["Name"])// --- TypeScript (AWS SDK v3) ---
import { S3Client, ListBucketsCommand } from "@aws-sdk/client-s3";
const s3 = new S3Client({});
const response = await s3.send(new ListBucketsCommand({}));
for (const bucket of response.Buckets ?? []) {
console.log(bucket.Name);
}The operation is ListBuckets in both. The response key is Buckets in both. Only the language wrapping differs.
The shared model shows up most clearly in the input and output shapes.
Because both SDKs read the same DynamoDB definition, a GetItem call takes the same parameters and returns the same fields, in the same PascalCase the API reference uses.
# --- Python (boto3) ---
import boto3
ddb = boto3.client("dynamodb", region_name="us-east-1")
result = ddb.get_item(
TableName="Orders",
Key={"id": {"S": "order-42"}},
)
print(result.get("Item"))// --- TypeScript (AWS SDK v3) ---
import { DynamoDBClient, GetItemCommand } from "@aws-sdk/client-dynamodb";
const ddb = new DynamoDBClient({ region: "us-east-1" });
const result = await ddb.send(new GetItemCommand({
TableName: "Orders",
Key: { id: { S: "order-42" } },
}));
console.log(result.Item);Notice the TableName, Key, and the typed attribute value {"S": ...} are identical. That is the service model showing through both surfaces.
What differs is everything around the operation. boto3 hangs operations directly off the client as methods and ships as one large package covering every service. SDK v3 wraps each operation in a Command object passed to client.send(), and splits every service into its own @aws-sdk/client-* package.
The family also shares infrastructure below the surface: credential resolution chains, SigV4 signing, retry logic, and pagination all follow the same conventions, just implemented per language.
So when you learn the mental model in one SDK, it transfers. A Python developer reading TypeScript AWS code can usually follow it, because the operation names and inputs are the shared vocabulary.
Parity is high, but "the same model" does not mean "byte-for-byte identical developer experience."
A few real differences separate the siblings.
| Dimension | boto3 (Python) | AWS SDK for JavaScript v3 | Why it differs |
|---|---|---|---|
| Packaging | One package, all services | One package per service | Different runtime and bundling goals |
| Operation surface | Methods on the client | Command objects via send() | Middleware and tree-shaking design |
| Naming | snake_case methods | PascalCase commands | Language conventions |
| Higher-level helpers | Resources, upload_file transfer manager | lib-* helpers, lib-storage upload | Ecosystem-specific ergonomics |
| New-service lead time | Usually near day-one | Usually near day-one | Both are code-generated, so both track closely |
The naming shift is the most visible. boto3 converts the model's PascalCase operation names into Pythonic snake_case methods (list_buckets), while SDK v3 keeps PascalCase in its command classes (ListBucketsCommand). The underlying API name is ListBuckets in both.
Higher-level convenience differs too. boto3 offers the resource interface and helpers like upload_file; SDK v3 offers separate lib-* packages such as @aws-sdk/lib-storage for multipart uploads. These are conveniences layered on top of the shared operations, not new AWS capabilities.
The practical takeaway: capability is rarely the deciding factor. If a service supports an operation, your language's SDK almost certainly exposes it. Choose based on the language your workload already lives in, the runtime you deploy to, and the packaging and cold-start characteristics covered later in this section.
Many - one per language (Python's boto3, JavaScript/TypeScript's v3, Go, Java, .NET, Rust, and others) - but all are generated from the same shared service API model.
Because they are code-generated from the same AWS service definitions. The operation names, inputs, and response shapes come from one contract, so only the language wrapping differs.
A machine-readable definition of a service's operations, inputs, and outputs. AWS maintains these (largely in Smithy today) and generates each SDK from them.
Effectively yes. Since both are generated from the same models, their operation coverage is near-identical; differences are in surface, packaging, and helpers.
Each SDK follows its language's conventions. boto3 turns ListBuckets into a snake_case method list_buckets; SDK v3 keeps a PascalCase ListBucketsCommand. The API name is the same underneath.
Choose by language and runtime. Pick the SDK for the language your workload already uses, then weigh packaging and cold-start traits, which the rest of this section covers.
No. The operation names and inputs are shared vocabulary, so the calls are recognizable even across languages; only the client and command syntax change.
No. Things like boto3 resources or SDK v3's lib-storage are language-specific conveniences layered on top of the shared operations, not extra AWS capabilities.
Usually very close together, because the code-generation pipeline feeds all SDKs from the same definitions. Small lead-time differences can happen but are the exception.
No. Smithy is how AWS defines services internally and generates the SDKs. As an SDK user you consume the result; you never write Smithy yourself.
Yes, and many teams do - for example a Python backend and TypeScript Lambdas. Because the model is shared, the operations line up cleanly across the split.
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 atualização: 23 de jul. de 2026