AWS SDK Rules Quickstart

This is the orientation page for the enumerated rule references in this section.

If you only have a few minutes, this page gives you the five highest-impact habits and points you at the checklist that goes deep on each one.

Read the Why AWS SDK Rules Exist explainer first for the reasoning; read this page for the map.

Summary

This page is a map, not a rulebook: it routes you to the checklists where each rule category is enumerated in full.
Insight: you do not need to memorize dozens of rules to be safe today - five habits cover the most common and most expensive mistakes.
Key Concepts: credential hygiene, typed error handling, bounded retries, batching, client reuse.
When to Use: as the first stop before writing an AWS integration, and as the index you return to when reviewing code.
Limitations/Trade-offs: the five starter rules are a floor, not a ceiling; each checklist adds the nuance this page skips.
Related Topics: every other page in the SDK Rules section.

Foundations

The five starter rules map one-to-one onto the failure modes from the previous page.

Never hardcode credentials. Let the SDK resolve them from environment, config, or an IAM role. This is the single highest-impact security rule.
Catch typed errors, not bare exceptions. Branch on the specific error so you handle the known cases and surface the rest.
Bound your retries. Rely on built-in retry with backoff and cap the attempts; never loop forever on failure.
Batch and paginate instead of looping. One batched call beats a thousand single calls for both cost and latency.
Reuse and close clients. Create a client once, share it, and clean up long-lived resources.

Here is the safe baseline: no keys in code, region pinned, client reused.

# --- Python (boto3) ---
import boto3
 
# Rule 1 + 5: no keys in code, one client created once and reused.
s3 = boto3.client("s3", region_name="us-east-1")

// --- TypeScript (AWS SDK v3) ---
import { S3Client } from "@aws-sdk/client-s3";
 
// Rule 1 + 5: no keys in code, one client created once and reused.
const s3 = new S3Client({ region: "us-east-1" });

If your code already does these five things, you have avoided the majority of real-world SDK incidents.

Mechanics & Interactions

The rest of the section expands each starter rule into a full checklist. Read them in this order.

Start with the Authentication & Credential Rules Checklist. Leaked credentials are the fastest way to a security incident and a large bill, so this comes first.
Then the Error Handling & Retry Rules Checklist. It covers which errors to catch, which operations are safe to retry, and how to configure backoff.
Then the Cost-Aware SDK Usage Rules. It turns "batch and paginate" into concrete rules about loops, polling, and data transfer.
Then the Resource Cleanup & Teardown Rules. It covers closing clients, releasing connections, and avoiding orphaned resources.
Then the Security Rules for SDK-Calling Services. It goes beyond credentials into least privilege, secret handling, and dependency scanning.

When you know the categories, the AWS SDK Rules & Best Practices Summary is the cross-cutting index you keep open during code review.

Advanced Considerations & Applications

The checklists are written to be audited, not just read. Each rule is a checkbox you can hold your own code against.

A useful workflow is to open the relevant checklist next to a pull request and walk the boxes. Most reviews only need two or three categories - credentials and errors for a small feature, plus cost and cleanup for anything long-running or high-volume.

The rules are also portable across languages. Every checklist shows boto3 and AWS SDK for JavaScript v3 together, so a team that runs Python services and TypeScript Lambdas can apply one standard to both.

Do not treat the starter five as the finish line. They stop the common disasters, but the checklists carry the nuance: idempotency tokens for safe retries, adaptive retry mode for bursty load, partition-aware ARNs, and dependency scanning. Adopt the five today, then layer in the rest as your integration grows.

Common Misconceptions

"Quickstart means I can skip the checklists." - No. This page is the map; the checklists are the territory. The five rules are a floor, not full coverage.
"I should read the security page first because it sounds most important." - Start with authentication. Most security incidents begin with a leaked credential, which the authentication checklist covers directly.
"The starter rules are enough for production." - They prevent the common disasters. Production code also needs the cost, cleanup, and least-privilege rules the checklists add.
"These are Python rules that I have to translate to TypeScript." - Every rule is shown in both boto3 and SDK v3; the standard is the same for both.
"Batching is a performance optimization I can defer." - Batching is a cost rule. Deferring it can multiply your bill, not just your latency.

FAQs

What is this page for?

It is the orientation map for the SDK Rules section. It gives you five starter habits and points you to the checklist that covers each one in depth.

What are the five rules to adopt first?

No hardcoded credentials, catch typed errors, bound your retries, batch and paginate instead of looping, and reuse and close clients.

Which checklist should I read first?

The authentication and credential checklist. Leaked credentials are the highest-impact failure mode, so credential hygiene comes before everything else.

Are the five rules enough on their own?

They prevent most real incidents, but they are a floor. The checklists add cost control, cleanup, least privilege, and safe-retry nuance you will want as code grows.

Do the rules apply to both boto3 and SDK v3?

Yes. Every checklist shows Python and TypeScript side by side, so one standard covers services in both languages.

How do I use the checklists in review?

Open the relevant checklist next to the pull request and walk the boxes. Most changes only need two or three categories.

Where is the full index of rules?

The Best Practices Summary at the end of the section links every checklist and condenses the categories into one review sheet.

Is batching really a starter rule?

Yes, because it is a cost rule. A loop of single calls can cost far more than one batched call, so batching belongs in the first five.

What if I only write short scripts?

The credential and error rules still apply. A leaked key or an uncaught error in a script is just as costly as one in a service.

Why bound retries if the SDK already retries?

The SDK retries with backoff, but you still cap the attempts and only retry idempotent operations. Unbounded retries turn a transient error into a bill.

Why AWS SDK Rules Exist - the reasoning behind every rule in this section.
Authentication & Credential Rules Checklist - read this first.
Error Handling & Retry Rules Checklist - the reliability rules in full.
AWS SDK Rules & Best Practices Summary - the cross-cutting index for all checklists.

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

If you only have a few minutes, this page gives you the five highest-impact habits and points you at the checklist that goes deep on each one.

Read the Why AWS SDK Rules Exist explainer first for the reasoning; read this page for the map.

Summary

This page is a map, not a rulebook: it routes you to the checklists where each rule category is enumerated in full.
Insight: you do not need to memorize dozens of rules to be safe today - five habits cover the most common and most expensive mistakes.
Key Concepts: credential hygiene, typed error handling, bounded retries, batching, client reuse.
When to Use: as the first stop before writing an AWS integration, and as the index you return to when reviewing code.
Limitations/Trade-offs: the five starter rules are a floor, not a ceiling; each checklist adds the nuance this page skips.
Related Topics: every other page in the SDK Rules section.

Foundations

The five starter rules map one-to-one onto the failure modes from the previous page.

Never hardcode credentials. Let the SDK resolve them from environment, config, or an IAM role. This is the single highest-impact security rule.
Catch typed errors, not bare exceptions. Branch on the specific error so you handle the known cases and surface the rest.
Bound your retries. Rely on built-in retry with backoff and cap the attempts; never loop forever on failure.
Batch and paginate instead of looping. One batched call beats a thousand single calls for both cost and latency.
Reuse and close clients. Create a client once, share it, and clean up long-lived resources.

Here is the safe baseline: no keys in code, region pinned, client reused.

# --- Python (boto3) ---
import boto3
 
# Rule 1 + 5: no keys in code, one client created once and reused.
s3 = boto3.client("s3", region_name="us-east-1")

// --- TypeScript (AWS SDK v3) ---
import { S3Client } from "@aws-sdk/client-s3";
 
// Rule 1 + 5: no keys in code, one client created once and reused.
const s3 = new S3Client({ region: "us-east-1" });

If your code already does these five things, you have avoided the majority of real-world SDK incidents.

Mechanics & Interactions

The rest of the section expands each starter rule into a full checklist. Read them in this order.

Start with the Authentication & Credential Rules Checklist. Leaked credentials are the fastest way to a security incident and a large bill, so this comes first.
Then the Error Handling & Retry Rules Checklist. It covers which errors to catch, which operations are safe to retry, and how to configure backoff.
Then the Cost-Aware SDK Usage Rules. It turns "batch and paginate" into concrete rules about loops, polling, and data transfer.
Then the Resource Cleanup & Teardown Rules. It covers closing clients, releasing connections, and avoiding orphaned resources.
Then the Security Rules for SDK-Calling Services. It goes beyond credentials into least privilege, secret handling, and dependency scanning.

When you know the categories, the AWS SDK Rules & Best Practices Summary is the cross-cutting index you keep open during code review.

Advanced Considerations & Applications

The checklists are written to be audited, not just read. Each rule is a checkbox you can hold your own code against.

Common Misconceptions

"Quickstart means I can skip the checklists." - No. This page is the map; the checklists are the territory. The five rules are a floor, not full coverage.
"I should read the security page first because it sounds most important." - Start with authentication. Most security incidents begin with a leaked credential, which the authentication checklist covers directly.
"The starter rules are enough for production." - They prevent the common disasters. Production code also needs the cost, cleanup, and least-privilege rules the checklists add.
"These are Python rules that I have to translate to TypeScript." - Every rule is shown in both boto3 and SDK v3; the standard is the same for both.
"Batching is a performance optimization I can defer." - Batching is a cost rule. Deferring it can multiply your bill, not just your latency.

FAQs

What is this page for?

It is the orientation map for the SDK Rules section. It gives you five starter habits and points you to the checklist that covers each one in depth.

What are the five rules to adopt first?

No hardcoded credentials, catch typed errors, bound your retries, batch and paginate instead of looping, and reuse and close clients.

Which checklist should I read first?

The authentication and credential checklist. Leaked credentials are the highest-impact failure mode, so credential hygiene comes before everything else.

Are the five rules enough on their own?

They prevent most real incidents, but they are a floor. The checklists add cost control, cleanup, least privilege, and safe-retry nuance you will want as code grows.

Do the rules apply to both boto3 and SDK v3?

Yes. Every checklist shows Python and TypeScript side by side, so one standard covers services in both languages.

How do I use the checklists in review?

Open the relevant checklist next to the pull request and walk the boxes. Most changes only need two or three categories.

Where is the full index of rules?

The Best Practices Summary at the end of the section links every checklist and condenses the categories into one review sheet.

Is batching really a starter rule?

Yes, because it is a cost rule. A loop of single calls can cost far more than one batched call, so batching belongs in the first five.

What if I only write short scripts?

The credential and error rules still apply. A leaked key or an uncaught error in a script is just as costly as one in a service.

Why bound retries if the SDK already retries?

The SDK retries with backoff, but you still cap the attempts and only retry idempotent operations. Unbounded retries turn a transient error into a bill.

Why AWS SDK Rules Exist - the reasoning behind every rule in this section.
Authentication & Credential Rules Checklist - read this first.
Error Handling & Retry Rules Checklist - the reliability rules in full.
AWS SDK Rules & Best Practices Summary - the cross-cutting index for all checklists.

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

AWS SDK Rules Quickstart

Buscar en la documentación

AWS SDK Rules Quickstart