Standards & Governance Best Practices

This is the index for the Standards & Governance section. It condenses every page into one review sheet.

Each best practice below is a one-line rule that links to the full page behind it. Use it when writing a team's CONTRIBUTING.md, onboarding a new engineer, or reviewing a pull request that touches AWS SDK code.

How to Use This List

Read top to bottom for a fast refresher, or use it as a router: pick the category the situation touches and open its full page.
Groups run in the order a new codebase typically needs them: coding standards first, then dependency governance, then the two ongoing habits.
Every practice holds for both boto3 and AWS SDK for JavaScript v3 codebases.
If you only read two pages, read the coding-standards page and the dependency-governance page.

A - Coding Standards

Write down one naming convention. Pick snake_case clients in Python, camelCase in TypeScript, and apply it everywhere - consistency matters more than the exact pattern.
Centralize error classification. Put "is this retryable" or "is this not-found" logic in one shared helper per category, not re-derived at every call site.
Build clients once, reuse everywhere. Construct at module load or cold start, never inside a request handler or a loop.
Turn on type checking by default. Install boto3-stubs/mypy-boto3 per service in Python; rely on @aws-sdk/client-*'s native types in TypeScript.

Full detail: Coding Standards for boto3 & SDK v3 Codebases.

B - Dependency Governance

Pin exact versions, not ranges. boto3==1.43.10, "@aws-sdk/client-s3": "3.700.0" - never a floating semver range, especially for fast-moving botocore.
Commit the lockfile. poetry.lock or package-lock.json is the actual source of truth for what installs, not the manifest alone.
Write down an update cadence. Weekly review for routine patch/minor bumps, quarterly and deliberate for major versions.
Automate the PR, keep the policy manual. Dependabot/Renovate opens the update PR; your written cadence decides how fast it gets merged.

Full detail: Dependency Governance for AWS SDK Packages.

C - Deprecation & Version Tracking

Schedule a recurring review. Quarterly is a reasonable default; put it on a calendar with an owner, not a hope that someone notices.
Check AWS's real notice channels. Console deprecation banners and account/email notifications are the actual mechanism, not a third-party feed.
Read the SDK's migration guide before a major bump. Test the upgrade in a branch first, using the guide published with that release.
Turn a notice into tracked work immediately. A backlog item with an owner and a deadline, not an email to remember.

Full detail: Tracking AWS Deprecations & SDK Major Versions.

D - Staying Current

Skim AWS What's New monthly, filtered to your services. aws.amazon.com/new is the real, official feed - no invented newsletter needed.
Check the SDK's own changelog separately. botocore's CHANGELOG.rst for Python, the aws-sdk-js-v3 GitHub releases for TypeScript.
Use AWS re:Post for context, not as a primary source. It's community Q&A, useful for migration gotchas, not an official announcement channel.
Keep the habit short. Five to ten minutes a month, filtered to what you actually use, beats an unsustainable attempt to read everything.

Full detail: Staying Current: AWS What's New & SDK Release Notes.

E - Where to Start

Read the reasoning first. Why AWS SDK Code Needs Governance explains why drift, deprecations, and dependency sprawl compound if left unaddressed.
Use the starter checklist. Standards & Governance Basics gives seven day-one habits with copy-paste examples.
Apply one standard across both languages. Every practice holds for boto3 and AWS SDK v3, so a mixed Python/TypeScript codebase uses one review sheet.

FAQs

What is this page?

The cross-cutting index for the Standards & Governance section. It condenses every page into one best-practice list per category and links each to its full detail.

What are the four practice areas?

Coding standards, dependency governance, deprecation and version tracking, and staying current with AWS's own announcement sources.

Which categories matter most for a brand-new codebase?

Coding standards and dependency governance first - they prevent the most common drift. Deprecation tracking and staying current matter more as the codebase and its AWS surface area grow.

How do I use this in code review?

Pick the category the change touches - a new client, a version bump, a deprecation notice - and open its full page alongside the pull request.

If I only read two pages, which two?

Coding Standards for boto3 & SDK v3 Codebases and Dependency Governance for AWS SDK Packages. They cover the highest-frequency decisions a codebase makes.

Do these practices require new tooling?

Mostly no. A written standard, a committed lockfile, and a recurring calendar reminder cover most of this. Dependabot/Renovate and a linter are the only tools referenced, and both are already covered elsewhere in this cookbook.

Where should a new team start?

With the Why page for the reasoning, then Standards & Governance Basics for the starter checklist, then the coding-standards and dependency-governance pages for the full detail.

Does this apply to a solo developer, not just a team?

Yes, in a lighter form. Picking one naming convention and pinning versions costs almost nothing even for a single-person project, and it prevents drift the moment a second contributor joins.

How does this section relate to SDK Rules?

SDK Rules covers the mechanics of a correct call - retries, cost, cleanup, security. This section covers the process layer above it: keeping conventions and versions consistent over time.

Does this page introduce new practices?

No. It only condenses and links the practices detailed in the section's other five pages. Use it as an index, and follow the links for full detail.

Why AWS SDK Code Needs Governance - the reasoning behind every practice above.
Standards & Governance Basics - the starter checklist with copy-paste examples.
Coding Standards for boto3 & SDK v3 Codebases - the highest-frequency category in day-to-day review.
Dependency Governance for AWS SDK Packages - the versioning policy that pairs with coding standards.

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

Standards & Governance Best Practices

This is the index for the Standards & Governance section. It condenses every page into one review sheet.

How to Use This List

Read top to bottom for a fast refresher, or use it as a router: pick the category the situation touches and open its full page.
Groups run in the order a new codebase typically needs them: coding standards first, then dependency governance, then the two ongoing habits.
Every practice holds for both boto3 and AWS SDK for JavaScript v3 codebases.
If you only read two pages, read the coding-standards page and the dependency-governance page.

A - Coding Standards

Write down one naming convention. Pick snake_case clients in Python, camelCase in TypeScript, and apply it everywhere - consistency matters more than the exact pattern.
Centralize error classification. Put "is this retryable" or "is this not-found" logic in one shared helper per category, not re-derived at every call site.
Build clients once, reuse everywhere. Construct at module load or cold start, never inside a request handler or a loop.
Turn on type checking by default. Install boto3-stubs/mypy-boto3 per service in Python; rely on @aws-sdk/client-*'s native types in TypeScript.

Full detail: Coding Standards for boto3 & SDK v3 Codebases.

B - Dependency Governance

Pin exact versions, not ranges. boto3==1.43.10, "@aws-sdk/client-s3": "3.700.0" - never a floating semver range, especially for fast-moving botocore.
Commit the lockfile. poetry.lock or package-lock.json is the actual source of truth for what installs, not the manifest alone.
Write down an update cadence. Weekly review for routine patch/minor bumps, quarterly and deliberate for major versions.
Automate the PR, keep the policy manual. Dependabot/Renovate opens the update PR; your written cadence decides how fast it gets merged.

Full detail: Dependency Governance for AWS SDK Packages.

C - Deprecation & Version Tracking

Schedule a recurring review. Quarterly is a reasonable default; put it on a calendar with an owner, not a hope that someone notices.
Check AWS's real notice channels. Console deprecation banners and account/email notifications are the actual mechanism, not a third-party feed.
Read the SDK's migration guide before a major bump. Test the upgrade in a branch first, using the guide published with that release.
Turn a notice into tracked work immediately. A backlog item with an owner and a deadline, not an email to remember.

Full detail: Tracking AWS Deprecations & SDK Major Versions.

D - Staying Current

Skim AWS What's New monthly, filtered to your services. aws.amazon.com/new is the real, official feed - no invented newsletter needed.
Check the SDK's own changelog separately. botocore's CHANGELOG.rst for Python, the aws-sdk-js-v3 GitHub releases for TypeScript.
Use AWS re:Post for context, not as a primary source. It's community Q&A, useful for migration gotchas, not an official announcement channel.
Keep the habit short. Five to ten minutes a month, filtered to what you actually use, beats an unsustainable attempt to read everything.

Full detail: Staying Current: AWS What's New & SDK Release Notes.

E - Where to Start

Read the reasoning first. Why AWS SDK Code Needs Governance explains why drift, deprecations, and dependency sprawl compound if left unaddressed.
Use the starter checklist. Standards & Governance Basics gives seven day-one habits with copy-paste examples.
Apply one standard across both languages. Every practice holds for boto3 and AWS SDK v3, so a mixed Python/TypeScript codebase uses one review sheet.

FAQs

What is this page?

The cross-cutting index for the Standards & Governance section. It condenses every page into one best-practice list per category and links each to its full detail.

What are the four practice areas?

Coding standards, dependency governance, deprecation and version tracking, and staying current with AWS's own announcement sources.

Which categories matter most for a brand-new codebase?

Coding standards and dependency governance first - they prevent the most common drift. Deprecation tracking and staying current matter more as the codebase and its AWS surface area grow.

How do I use this in code review?

Pick the category the change touches - a new client, a version bump, a deprecation notice - and open its full page alongside the pull request.

If I only read two pages, which two?

Coding Standards for boto3 & SDK v3 Codebases and Dependency Governance for AWS SDK Packages. They cover the highest-frequency decisions a codebase makes.

Do these practices require new tooling?

Where should a new team start?

With the Why page for the reasoning, then Standards & Governance Basics for the starter checklist, then the coding-standards and dependency-governance pages for the full detail.

Does this apply to a solo developer, not just a team?

Yes, in a lighter form. Picking one naming convention and pinning versions costs almost nothing even for a single-person project, and it prevents drift the moment a second contributor joins.

How does this section relate to SDK Rules?

SDK Rules covers the mechanics of a correct call - retries, cost, cleanup, security. This section covers the process layer above it: keeping conventions and versions consistent over time.

Does this page introduce new practices?

No. It only condenses and links the practices detailed in the section's other five pages. Use it as an index, and follow the links for full detail.

Why AWS SDK Code Needs Governance - the reasoning behind every practice above.
Standards & Governance Basics - the starter checklist with copy-paste examples.
Coding Standards for boto3 & SDK v3 Codebases - the highest-frequency category in day-to-day review.
Dependency Governance for AWS SDK Packages - the versioning policy that pairs with coding standards.

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

Standards & Governance Best Practices

Search Documentation

Standards & Governance Best Practices