Standards & Governance Basics

Seven starter habits for a new AWS SDK codebase - five basic and two intermediate.

None of these require tooling you don't already have. They are decisions to make once, in writing, before drift sets in.

Prerequisites

• An existing boto3 (Python 3.10+) and/or AWS SDK for JavaScript v3 (Node.js 18+) codebase, even a small one.
• A place to write things down - a CONTRIBUTING.md, a wiki page, or a pinned team doc. The format matters less than that it exists.
• No new tools required for the basic examples; the intermediate examples reference tools already covered elsewhere in this cookbook.

Basic Examples

1. Write Down One Naming Convention

Pick a single pattern for client variable names and stick to it everywhere.

# --- Python (boto3) ---
# Convention: <service>_client, lowercase, no abbreviation guessing
s3_client = boto3.client("s3")
dynamodb_client = boto3.client("dynamodb")

// --- TypeScript (AWS SDK v3) ---
// Convention: <service>Client, camelCase, matches the imported class
const s3Client = new S3Client({});
const dynamoDbClient = new DynamoDBClient({});

• The exact convention matters less than that everyone uses the same one.
• Consistent naming makes a call site instantly readable without opening its imports.
• Write the convention down once, in one file, rather than relying on a reviewer to catch drift.
• Apply it to new code first; retrofitting old code can wait for a natural touch point.

2. Pin SDK Versions in the Lockfile

Never let boto3 or @aws-sdk/client-* float on an unpinned range.

# --- requirements.txt (Python) ---
boto3==1.43.10
botocore==1.43.10

// --- package.json (TypeScript) ---
{
  "dependencies": {
    "@aws-sdk/client-s3": "3.700.0",
    "@aws-sdk/client-dynamodb": "3.700.0"
  }
}

• Exact pins plus a committed lockfile (poetry.lock or package-lock.json) mean every install is reproducible.
• Unpinned ranges (boto3>=1.40) can pull in a new minor version mid-deploy with no warning.
• This is the day-one habit; the full update-cadence policy is covered later in this section.
• The same discipline applies whether you use pip, Poetry, or npm.

Related: Dependency Governance for AWS SDK Packages - the full pinning and update-cadence policy.

3. Centralize Error Handling in One Helper

Wrap the common "catch and classify" pattern once instead of repeating it at every call site.

# --- Python (boto3) ---
from botocore.exceptions import ClientError
 
def is_not_found(err: ClientError) -> bool:
    return err.response["Error"]["Code"] in ("NoSuchKey", "404")

// --- TypeScript (AWS SDK v3) ---
export function isNotFound(err: unknown): boolean {
  return err instanceof Error && err.name === "NotFound";
}

• A shared helper means the classification logic (what counts as "not found") lives in one place.
• New call sites import the helper instead of re-deriving error codes from memory.
• This does not replace the retry and error-handling mechanics already covered in the pagination-and-retries section; it is the standard for applying them consistently.
• Naming the helper clearly (isNotFound, not checkErr) keeps intent obvious at the call site.

4. Turn On Type Checking Early

Both languages have a real typing story for the SDK; use it from the start rather than retrofitting it.

# --- Python (boto3) ---
# pip install boto3-stubs[s3,dynamodb]
# mypy picks up the stubs automatically once installed
from mypy_boto3_s3 import S3Client

// --- TypeScript (AWS SDK v3) ---
// No extra install: @aws-sdk/client-* ships its own types
import type { S3Client } from "@aws-sdk/client-s3";

• Python needs boto3-stubs/mypy-boto3 installed per-service to get typed clients; TypeScript gets this for free from @aws-sdk/client-*.
• Typing catches a wrong parameter name or response field at review time instead of at runtime.
• This is covered in depth in boto3-fundamentals; the standard here is simply to require it by default on new code.
• Adding types to an existing untyped codebase can be incremental - start with the services you touch most.

Related: Coding Standards for boto3 & SDK v3 Codebases - where type checking fits among the other conventions.

5. Write Down an Update Cadence

Decide, once, how often SDK dependencies get reviewed and bumped.

Example team policy (put this in CONTRIBUTING.md):
 
- Review boto3/botocore and @aws-sdk/client-* versions quarterly.
- Dependabot/Renovate PRs for patch/minor bumps: merge within one sprint.
- Major version bumps: read the changelog, test in a branch, schedule deliberately.

• A written cadence turns "we should update sometime" into a concrete, checkable habit.
• It does not need to be frequent - quarterly is a reasonable default for most teams.
• Automated tools (Dependabot, Renovate) handle the mechanical PR-opening part; the cadence covers who reviews and merges them.
• Skipping this is how a codebase ends up years behind without anyone deciding that on purpose.

Intermediate Examples

6. Keep a Living Deprecation-Tracking Note

A single short doc that lists services and SDK versions in use, reviewed on the same cadence as dependency updates.

Example tracking note (updated quarterly):
 
- S3, DynamoDB, Lambda - boto3 1.43.x, @aws-sdk/client-* 3.700.x
- Last deprecation review: 2026-07-01
- Open items: none currently flagged by AWS's console banners

• This does not need a dedicated tool; a shared doc reviewed on schedule is enough for most teams.
• The point is to have one place to check, not to re-derive "are we affected?" from scratch every time.
• Pair this with the full process in Tracking AWS Deprecations & SDK Major Versions later in this section.
• Include the last review date so anyone can see at a glance whether the note is stale.

Related: Tracking AWS Deprecations & SDK Major Versions - the full process this note supports.

7. Subscribe to Real Release-Notes Sources

Point the team at AWS's actual sources instead of relying on word of mouth.

Sources worth bookmarking:
 
- AWS What's New (aws.amazon.com/new) - service-level announcements
- boto3/botocore changelog on GitHub - Python SDK release notes
- AWS SDK for JavaScript v3 GitHub releases - Node/TypeScript SDK release notes
- AWS re:Post - community Q&A, useful for migration gotchas

• These are the same real sources covered in depth later in this section - no invented newsletter or tool needed.
• Even skimming AWS What's New monthly catches most service-level changes relevant to your stack.
• SDK-specific changelogs matter more when planning a major version upgrade.
• This is a habit, not a tool purchase; the cost is a recurring few minutes.

Related: Staying Current: AWS What's New & SDK Release Notes - the full habit loop.

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