AWS SDKs Overview

An SDK (Software Development Kit) is a library you add to your code so your program can talk to AWS directly. Instead of clicking buttons in the web Console or typing commands in a terminal, you write a few lines in Python, JavaScript, Java, or another language, and the SDK does the API (Application Programming Interface — the set of web requests AWS understands) calls for you. SDKs matter because real applications need to create, read, and manage AWS resources automatically, not by hand. This page explains what SDKs are, how they find your credentials, and when to reach for an SDK instead of the CLI or Console.

What an AWS SDK actually is

Every action in AWS — launch a server, upload a file, send a message — is really an HTTPS request to an AWS API endpoint, signed with your security credentials. Writing those signed requests by hand is painful and error-prone. An AWS SDK is a language-specific library that wraps the API: it builds the request, signs it correctly, sends it, retries on transient failures, and turns the response into a normal object in your language.

AWS publishes an official SDK for most popular languages. They all talk to the same APIs, so the capabilities are identical — only the syntax differs.

SDK	Language	Package name	Notes
boto3	Python	`boto3`	The most widely used; great for scripts and data work
AWS SDK for JavaScript v3	Node.js / browser	`@aws-sdk/client-*`	Modular — install only the clients you need
AWS SDK for Java 2.x	Java	`software.amazon.awssdk`	Common in enterprise back ends
AWS SDK for Go v2	Go	`aws-sdk-go-v2`	Lightweight, used in CLI-style tools
AWS SDK for .NET	C# / .NET	`AWSSDK.*`	Integrates with ASP.NET

Tip: Use the latest major version of each SDK (boto3, JS v3, Java 2.x, Go v2). Older v1/v2 lines still exist in old tutorials but get fewer updates and have clunkier APIs.

How SDKs find your credentials (the shared chain)

This is the part that confuses beginners most, so read it carefully. SDKs do not ask you for your access keys in code (and you should never paste keys into code). Instead, they use the exact same credential provider chain as the AWS CLI. The SDK checks several places in order and uses the first one that has valid credentials:

Hard-coded credentials passed directly in code (strongly discouraged).
Environment variables — AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and optionally AWS_SESSION_TOKEN.
Shared config / credentials files — ~/.aws/credentials and ~/.aws/config, selected by the AWS_PROFILE variable or a default profile.
IAM role for the compute — for example an instance role on an EC2 server (a virtual machine) or a task role in ECS/Lambda. AWS hands these out automatically; no keys are stored anywhere.

Because the SDK and CLI share this chain, if aws sts get-caller-identity works in your terminal, your SDK code usually works too — same machine, same credentials.

Gotcha: If your code is acting as the wrong account or user, the cause is almost always an environment variable you forgot was set. Environment variables (step 2) win over your ~/.aws profile (step 3). A leftover AWS_ACCESS_KEY_ID in your shell or a CI/CD system silently overrides everything. Always check it first.

To see exactly which identity the chain resolved to, use the CLI — the SDK resolves to the same one:

aws sts get-caller-identity --profile dev

Output:

{
    "UserId": "AIDA1EXAMPLE2EXAMPLE3",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/devcraftly-dev"
}

A first SDK example: list your S3 buckets

The idea is the same in every language: create a client for a service, call a method, read the result. Here it is in Python with boto3. Notice there are no keys in the code — boto3 resolves them through the chain above.

import boto3

# Create a client for Amazon S3 (object storage)
s3 = boto3.client("s3")

response = s3.list_buckets()
for bucket in response["Buckets"]:
    print(bucket["Name"])

Output:

devcraftly-app-uploads
devcraftly-logs-archive
devcraftly-terraform-state

The same operation in the AWS SDK for JavaScript v3 (Node.js):

import { S3Client, ListBucketsCommand } from "@aws-sdk/client-s3";

const client = new S3Client({ region: "us-east-1" });
const response = await client.send(new ListBucketsCommand({}));
response.Buckets.forEach((b) => console.log(b.Name));

And the equivalent AWS CLI command, which does the very same API call under the hood:

aws s3api list-buckets --query "Buckets[].Name" --output text

Output:

devcraftly-app-uploads  devcraftly-logs-archive devcraftly-terraform-state

SDK vs CLI vs Console — when to use which

All three call the same APIs. The difference is who is driving and how often.

	Console	CLI	SDK
What it is	Web UI in the browser	Command-line tool	Library inside your app
Best for	Learning, exploring, one-off changes	Scripts, automation, quick checks	Application code that runs repeatedly
Repeatable?	No (manual clicks)	Yes (shell scripts)	Yes (compiled into your app)
Audience	Humans	Humans + simple automation	Running programs
Credentials	Console login (user/SSO)	Provider chain	Same provider chain as CLI

Practical guidance:

Use the Console when you are first learning a service, debugging visually, or making a rare manual change. Do not use it for anything you will repeat — clicking is not reproducible.
Use the CLI for shell scripts, CI/CD pipelines, and quick interactive checks. It is perfect when the logic is “run these commands in order.”
Use an SDK when AWS calls are part of an application — for example, your web app uploads a user’s photo to S3, or a Lambda function reads from DynamoDB. SDKs give you error handling, types, pagination, and retries inside your normal code.

Cost note: SDKs, the CLI, and the Console are all free to download and use. You pay only for the AWS resources you create with them. A typo in a loop that launches 50 EC2 servers costs real money — always test automation against small, tagged, throwaway resources first.

Configuring the SDK without touching code

Because the SDK reads the same files as the CLI, you configure it the same way. Set up a named profile once and every SDK on the machine can use it.

aws configure --profile dev

Output:

AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key [None]: ****************EXAMPLE
Default region name [None]: us-east-1
Default output format [None]: json

Then point your code at that profile with an environment variable (no code change needed):

export AWS_PROFILE=dev

On AWS compute (EC2, ECS, Lambda), skip credentials entirely and attach an IAM role instead. The SDK picks up temporary credentials from the role automatically — nothing to store, nothing to rotate.

Best Practices

Never hard-code access keys in source code or commit them to Git. Use the provider chain — profiles locally, IAM roles in the cloud.
Prefer IAM roles for any code running on AWS compute. Roles give short-lived, auto-rotated credentials with no secrets to leak.
Check environment variables first when credentials look wrong — they override your profile and are the usual culprit.
Use the latest major SDK version (boto3, JS v3, Java 2.x, Go v2) for better APIs, security fixes, and built-in retries.
Set an explicit region in the client or profile so your code does not accidentally act in the wrong AWS Region.
Test destructive automation against small, clearly named, throwaway resources before running it widely.
Reuse one client object across many calls instead of creating a new client per request — it is faster and avoids re-resolving credentials each time.

AWS SDKs Overview

What an AWS SDK actually is

How SDKs find your credentials (the shared chain)

A first SDK example: list your S3 buckets

SDK vs CLI vs Console — when to use which

Configuring the SDK without touching code

Best Practices

Related Topics