Technical Leadership Basics

Seven checks to run on a teammate's first AWS integration pull request - five basic and two intermediate.

Each check is something you can verify by reading the diff and the linked IAM policy, without running the code.

Prerequisites

• Access to the IAM policy or role the new code will run under, not just the application code.
• A shared understanding of which AWS services the team already uses, so you can spot an unnecessary new one.
• Fifteen to thirty minutes - a first-PR review is worth doing unhurried, since it sets a pattern the author will repeat.

Basic Examples

1. Check the IAM Scope First

Before reading a single line of SDK code, read the permissions it will run under.

• Look for Action: "*" or a wildcard resource ARN - both are red flags on a first PR.
• Confirm the policy lists only the operations the code actually calls (for example s3:GetObject, not s3:*).
• Ask the author to name every AWS action their code calls, then diff that list against the policy.
• A policy that is broader than the code needs is the single most common first-PR mistake.

Related: Design Reviews for New AWS Integrations - the fuller checklist this basic check comes from.

2. Confirm No Hardcoded Credentials

Look for anything that bypasses the SDK's default credential chain.

• Search the diff for aws_access_key_id, secret, or a raw key string - none of these belong in application code.
• Confirm the client is constructed with no explicit keys, relying on environment, role, or shared config.
• If a .env.example or config template was touched, confirm it holds no real values.
• This check takes seconds and catches the most expensive class of mistake.

3. Read the Error Handling

A first AWS integration PR often either swallows errors or does not handle them at all.

# --- Python (boto3) ---
# Flag this in review: the error is caught and discarded.
try:
    s3.put_object(Bucket=bucket, Key=key, Body=data)
except Exception:
    pass  # <- ask: why is this safe to ignore?

// --- TypeScript (AWS SDK v3) ---
// Flag this in review: the error is caught and discarded.
try {
  await s3.send(new PutObjectCommand({ Bucket: bucket, Key: key, Body: data }));
} catch {
  // <- ask: why is this safe to ignore?
}

• Confirm errors are logged with enough context (operation, key parameters) to debug later.
• Confirm the code branches on error code where it matters, rather than treating every failure the same.
• A bare except: pass or empty catch {} on an AWS call is almost never correct.

4. Check for Retry and Idempotency Assumptions

Ask what happens if this exact call runs twice.

• For mutating calls (write, delete), confirm the operation is either naturally idempotent or explicitly guarded (a conditional write, an idempotency key).
• Confirm the author is relying on the SDK's built-in retry behavior rather than hand-rolling a retry loop, unless there is a specific reason not to.
• Ask: if this call times out after the server actually applied it, what happens on retry?

5. Confirm Logging Does Not Leak Sensitive Data

• Check that logged request/response objects do not include credentials, tokens, or full customer records.
• Confirm log statements include a request id or similar, so a production issue is traceable back to a specific call.
• Watch for print(response) or console.log(response) left in from local debugging - full responses often carry more than the author intended to log.

Intermediate Examples

6. Sanity-Check the Cost Shape

Read the code for anything that runs in a loop or on a schedule.

• A call inside a loop over user records, or on every request, has a very different cost profile than the same call run once.
• Ask whether the call could be batched (many services offer a batch operation) instead of looped.
• For anything talking to Bedrock or another usage-priced service, confirm the author has looked at the pricing page, not guessed.

Related: Working with Product on AWS-Cost-Sensitive Features - framing that cost trade-off for non-engineers.

7. Confirm There Is a Rollback Path

• Ask what the team does if this integration needs to be turned off in production within the hour.
• Confirm the change ships behind a feature flag if it is user-facing and new, rather than as an unconditional code path.
• Confirm the author knows who to page and what dashboard to check if this specific integration starts failing.

Related: Release Strategy & Feature Flags for AWS-Backed Features - the fuller rollout pattern.

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