IAM Basics for SDK Auth Best Practices

A working checklist of IAM habits that keep AWS SDK authentication secure without slowing you down.

Each rule is stated positively, with a one-line reason and how to enforce it.

How to Use This List

Walk it top to bottom when standing up a new SDK integration or reviewing an old one.
Treat each unchecked box as a finding to fix or consciously accept.
Categories are ordered by leverage - identity choice first, then scope, then hygiene.
Re-run the audit categories on a recurring cadence, not just once.
Wire the checkable rules into CI or an ADR so they do not regress.

A - Identity & Credentials

Default to roles, not users with access keys. Roles issue temporary credentials that rotate automatically, shrinking the blast radius of any leak.
Use the compute's attached role on AWS. Instance profiles, ECS task roles, and Lambda execution roles let the SDK authenticate with zero secrets in code.
Let the default provider chain resolve credentials. Create clients with no keys so the SDK reads env, profile, or metadata credentials - never hardcode.
Assume roles via STS for cross-account or off-compute access. sts:AssumeRole gives scoped, expiring credentials instead of shared static keys.
Use IAM Identity Center (SSO) for human access. Federated sign-in beats handing developers long-lived keys.

# --- Python (boto3) ---
# Good: no keys in code, SDK resolves the attached role.
import boto3
s3 = boto3.client("s3")

// --- TypeScript (AWS SDK v3) ---
// Good: empty config triggers the default credential provider chain.
import { S3Client } from "@aws-sdk/client-s3";
const s3 = new S3Client({});

B - Least Privilege

Grant only the actions your code calls. List explicit service:Operation actions instead of s3:* or Action: "*".
Scope resources to specific ARNs. Replace Resource: "*" with the exact bucket, prefix, table, or queue where possible.
Add condition guards. Use keys like aws:SourceIp, resource tags, or required encryption to constrain permitted actions further.
Give each workload its own role. Separate roles keep a single compromise from spreading across services.
Right-size from real usage. Use IAM Access Analyzer policy generation on CloudTrail history to base the policy on observed calls.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ScopedReadWrite",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::acme-uploads/tenant-*/*"
    }
  ]
}

C - Key Hygiene & Rotation

Never commit credentials to source control. A secret in Git history is compromised even after deletion; run a secret scanner in CI.
Store any unavoidable secret in a secrets manager. Keep it out of code, images, and environment files checked into the repo.
Rotate access keys on a schedule with overlap. Create the new key, deploy, deactivate the old, then delete - never delete first.
Deactivate before deleting a key. Status="Inactive" gives a safe rollback window before permanent removal.
Alert on key age. Read list_access_keys metadata and flag any key older than your rotation policy.

# --- Python (boto3) ---
import boto3
iam = boto3.client("iam")
for k in iam.list_access_keys(UserName="ci-deployer")["AccessKeyMetadata"]:
    print(k["AccessKeyId"], k["Status"], k["CreateDate"])

// --- TypeScript (AWS SDK v3) ---
import { IAMClient, ListAccessKeysCommand } from "@aws-sdk/client-iam";
const iam = new IAMClient({});
const { AccessKeyMetadata } = await iam.send(
  new ListAccessKeysCommand({ UserName: "ci-deployer" }));
AccessKeyMetadata?.forEach((k) => console.log(k.AccessKeyId, k.Status, k.CreateDate));

D - Auditing & Debugging

Verify policies before deploying. Run SimulatePrincipalPolicy to confirm each intended action is allowed and each forbidden one is denied.
Diagnose AccessDenied with CloudTrail. The event shows the exact action and resource, so you stop guessing at the missing permission.
Treat AccessDenied as a policy fix, not a retry. It is an authorization verdict; retrying the same call will not change it.
Scan for external access with Access Analyzer. Catch policies that grant access outside your account or broader than intended.
Enable CloudTrail everywhere. It is the authoritative record of who called what and whether it was allowed.

E - Operational Guardrails

Enforce MFA for privileged human actions. Require MFA on sensitive operations via a condition on the policy.
Use permission boundaries when delegating role creation. They cap what a delegated role can ever grant.
Prefer managed policies for reuse, inline for one-off scope. Reuse shared intent; keep a role's unique permissions local and obvious.
Review and prune permissions periodically. Remove actions for retired features so stale grants do not linger.
Document required wildcards. When an action genuinely needs Resource: "*", note why so reviewers do not mistake it for laziness.

FAQs

Why is "roles over users" the first rule?

Because it has the highest leverage. A role delivers temporary, auto-rotating credentials with no stored secret, which removes an entire class of leak-and-linger risk before you even think about policy scope.

When is it acceptable to use long-lived access keys?

Only when nothing can assume a role - typically a system outside AWS or legacy tooling during migration. Even then, scope the permissions tightly and rotate on a schedule.

What does least privilege cost at runtime?

Nothing. IAM evaluates policies on every request regardless of breadth, so a narrow policy is exactly as fast as a broad one while being far safer.

Why grant a separate role per workload?

To contain damage. If one workload is compromised, a dedicated least-privilege role limits the attacker to that workload's permissions instead of everything the shared role could do.

What is the correct key rotation order?

Create the new key, deploy and verify it, deactivate the old key, then delete it. Deleting first would break the running credential and cause an outage.

Why deactivate a key before deleting it?

Deactivation is reversible and deletion is not. Setting the key to Inactive first gives you a rollback window to confirm nothing depended on it.

How do I stop credentials from ending up in Git?

Do not put them in code at all - use roles and the default provider chain. As a backstop, run a secret scanner in CI and store any unavoidable secret in a secrets manager.

What should I do first when I hit AccessDenied?

Look up the CloudTrail event to see the exact action and resource, then simulate that same action against the principal. That tells you precisely which permission to add - retrying does nothing.

When must a policy use Resource: "*" ?

For account-wide actions with no specific resource, such as s3:ListAllMyBuckets. Document these so a reviewer knows the wildcard is required rather than careless.

What is a permission boundary for?

It caps the maximum permissions a role can have, which is valuable when you let another team or automation create roles. The boundary limits what those delegated roles can ever grant.

Managed or inline policies - which should I use?

Use managed policies for permissions shared across many principals, and inline policies to keep a single role's unique, one-off permissions local and easy to reason about.

How often should I audit IAM for SDK auth?

On a recurring cadence, not once. Re-run Access Analyzer, review CloudTrail, prune unused actions, and confirm key ages against your rotation policy regularly.

IAM's Role in Every SDK Call - the model these rules protect.
IAM Users, Access Keys & When to Avoid Them - why roles beat static keys.
IAM Roles for Applications & Services - the role-based defaults in practice.
Writing a Least-Privilege Policy for a New SDK Integration - scope actions and resources.
IAM Policy Simulator & Access Analyzer for SDK Debugging - verify and audit policies.

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

IAM Basics for SDK Auth Best Practices

A working checklist of IAM habits that keep AWS SDK authentication secure without slowing you down.

Each rule is stated positively, with a one-line reason and how to enforce it.

How to Use This List

Walk it top to bottom when standing up a new SDK integration or reviewing an old one.
Treat each unchecked box as a finding to fix or consciously accept.
Categories are ordered by leverage - identity choice first, then scope, then hygiene.
Re-run the audit categories on a recurring cadence, not just once.
Wire the checkable rules into CI or an ADR so they do not regress.

A - Identity & Credentials

Default to roles, not users with access keys. Roles issue temporary credentials that rotate automatically, shrinking the blast radius of any leak.
Use the compute's attached role on AWS. Instance profiles, ECS task roles, and Lambda execution roles let the SDK authenticate with zero secrets in code.
Let the default provider chain resolve credentials. Create clients with no keys so the SDK reads env, profile, or metadata credentials - never hardcode.
Assume roles via STS for cross-account or off-compute access. sts:AssumeRole gives scoped, expiring credentials instead of shared static keys.
Use IAM Identity Center (SSO) for human access. Federated sign-in beats handing developers long-lived keys.

# --- Python (boto3) ---
# Good: no keys in code, SDK resolves the attached role.
import boto3
s3 = boto3.client("s3")

// --- TypeScript (AWS SDK v3) ---
// Good: empty config triggers the default credential provider chain.
import { S3Client } from "@aws-sdk/client-s3";
const s3 = new S3Client({});

B - Least Privilege

Grant only the actions your code calls. List explicit service:Operation actions instead of s3:* or Action: "*".
Scope resources to specific ARNs. Replace Resource: "*" with the exact bucket, prefix, table, or queue where possible.
Add condition guards. Use keys like aws:SourceIp, resource tags, or required encryption to constrain permitted actions further.
Give each workload its own role. Separate roles keep a single compromise from spreading across services.
Right-size from real usage. Use IAM Access Analyzer policy generation on CloudTrail history to base the policy on observed calls.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ScopedReadWrite",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::acme-uploads/tenant-*/*"
    }
  ]
}

C - Key Hygiene & Rotation

Never commit credentials to source control. A secret in Git history is compromised even after deletion; run a secret scanner in CI.
Store any unavoidable secret in a secrets manager. Keep it out of code, images, and environment files checked into the repo.
Rotate access keys on a schedule with overlap. Create the new key, deploy, deactivate the old, then delete - never delete first.
Deactivate before deleting a key. Status="Inactive" gives a safe rollback window before permanent removal.
Alert on key age. Read list_access_keys metadata and flag any key older than your rotation policy.

# --- Python (boto3) ---
import boto3
iam = boto3.client("iam")
for k in iam.list_access_keys(UserName="ci-deployer")["AccessKeyMetadata"]:
    print(k["AccessKeyId"], k["Status"], k["CreateDate"])

// --- TypeScript (AWS SDK v3) ---
import { IAMClient, ListAccessKeysCommand } from "@aws-sdk/client-iam";
const iam = new IAMClient({});
const { AccessKeyMetadata } = await iam.send(
  new ListAccessKeysCommand({ UserName: "ci-deployer" }));
AccessKeyMetadata?.forEach((k) => console.log(k.AccessKeyId, k.Status, k.CreateDate));

D - Auditing & Debugging

Verify policies before deploying. Run SimulatePrincipalPolicy to confirm each intended action is allowed and each forbidden one is denied.
Diagnose AccessDenied with CloudTrail. The event shows the exact action and resource, so you stop guessing at the missing permission.
Treat AccessDenied as a policy fix, not a retry. It is an authorization verdict; retrying the same call will not change it.
Scan for external access with Access Analyzer. Catch policies that grant access outside your account or broader than intended.
Enable CloudTrail everywhere. It is the authoritative record of who called what and whether it was allowed.

E - Operational Guardrails

Enforce MFA for privileged human actions. Require MFA on sensitive operations via a condition on the policy.
Use permission boundaries when delegating role creation. They cap what a delegated role can ever grant.
Prefer managed policies for reuse, inline for one-off scope. Reuse shared intent; keep a role's unique permissions local and obvious.
Review and prune permissions periodically. Remove actions for retired features so stale grants do not linger.
Document required wildcards. When an action genuinely needs Resource: "*", note why so reviewers do not mistake it for laziness.

FAQs

Why is "roles over users" the first rule?

When is it acceptable to use long-lived access keys?

Only when nothing can assume a role - typically a system outside AWS or legacy tooling during migration. Even then, scope the permissions tightly and rotate on a schedule.

What does least privilege cost at runtime?

Nothing. IAM evaluates policies on every request regardless of breadth, so a narrow policy is exactly as fast as a broad one while being far safer.

Why grant a separate role per workload?

To contain damage. If one workload is compromised, a dedicated least-privilege role limits the attacker to that workload's permissions instead of everything the shared role could do.

What is the correct key rotation order?

Create the new key, deploy and verify it, deactivate the old key, then delete it. Deleting first would break the running credential and cause an outage.

Why deactivate a key before deleting it?

Deactivation is reversible and deletion is not. Setting the key to Inactive first gives you a rollback window to confirm nothing depended on it.

How do I stop credentials from ending up in Git?

Do not put them in code at all - use roles and the default provider chain. As a backstop, run a secret scanner in CI and store any unavoidable secret in a secrets manager.

What should I do first when I hit AccessDenied?

Look up the CloudTrail event to see the exact action and resource, then simulate that same action against the principal. That tells you precisely which permission to add - retrying does nothing.

When must a policy use Resource: "*" ?

For account-wide actions with no specific resource, such as s3:ListAllMyBuckets. Document these so a reviewer knows the wildcard is required rather than careless.

What is a permission boundary for?

It caps the maximum permissions a role can have, which is valuable when you let another team or automation create roles. The boundary limits what those delegated roles can ever grant.

Managed or inline policies - which should I use?

Use managed policies for permissions shared across many principals, and inline policies to keep a single role's unique, one-off permissions local and easy to reason about.

How often should I audit IAM for SDK auth?

On a recurring cadence, not once. Re-run Access Analyzer, review CloudTrail, prune unused actions, and confirm key ages against your rotation policy regularly.

IAM's Role in Every SDK Call - the model these rules protect.
IAM Users, Access Keys & When to Avoid Them - why roles beat static keys.
IAM Roles for Applications & Services - the role-based defaults in practice.
Writing a Least-Privilege Policy for a New SDK Integration - scope actions and resources.
IAM Policy Simulator & Access Analyzer for SDK Debugging - verify and audit policies.

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

IAM Basics for SDK Auth Best Practices

Search Documentation

IAM Basics for SDK Auth Best Practices