IAM's Role in Every SDK Call
Every AWS SDK call - s3.get_object, dynamodb.put_item, sqs.send_message - is an HTTPS request to a regional AWS endpoint.
//
Busque em todas as páginas da documentação
Every AWS SDK call - s3.get_object, dynamodb.put_item, sqs.send_message - is an HTTPS request to a regional AWS endpoint.
Before AWS runs that request, two questions must be answered: who is asking, and are they allowed?
IAM (Identity and Access Management) is the service that answers both. It sits in front of nearly every AWS API, and understanding it is the difference between "my code works" and "my code is safe."
This page builds the mental model of what happens between your SDK call and the response.
A principal is the identity making the request.
It is usually an IAM user or, far more often in production, an IAM role that your application has assumed.
Every principal carries credentials: an access key ID, a secret access key, and (for roles) a session token.
The SDK never sends the secret key over the wire.
Instead it uses the secret to compute a cryptographic signature over the request, a process called SigV4 signing (AWS Signature Version 4).
AWS recomputes the same signature on its side using its copy of the secret.
If the signatures match, the request is authenticated - AWS now trusts that the request came from that principal and was not tampered with in transit.
Authentication only answers "who are you."
A separate step answers "are you allowed to do this," and that step reads policies.
Think of a single SDK call as a five-stage pipeline.
First, the SDK resolves credentials from the default provider chain - environment variables, shared config files, then instance or container metadata - stopping at the first source that yields credentials.
Second, the SDK builds the HTTPS request: method, endpoint, headers, and body.
Third, it signs that request with SigV4, attaching an Authorization header derived from the secret key.
Fourth, AWS authenticates the signature.
Fifth, AWS runs policy evaluation to authorize the specific action against the specific resource.
You rarely write signing code yourself - the SDK does it. This snippet shows that the client, not your code, holds the credential logic.
# --- Python (boto3) ---
import boto3
# No keys in code: boto3 resolves credentials from the
# default provider chain and signs every request with SigV4.
s3 = boto3.client("s3")
# This one call is authenticated (SigV4) AND authorized (IAM policy).
resp = s3.list_buckets()
print([b["Name"] for b in resp["Buckets"]])// --- TypeScript (AWS SDK v3) ---
import { S3Client, ListBucketsCommand } from "@aws-sdk/client-s3";
// Same idea: the client resolves credentials and signs with SigV4.
const s3 = new S3Client({});
const resp = await s3.send(new ListBucketsCommand({}));
console.log(resp.Buckets?.map((b) => b.Name));Policy evaluation is the conceptual heart of IAM.
AWS gathers every policy that applies to the request: identity policies on the principal, resource policies on the target, and any permission boundaries or service control policies.
It then applies one rule that you must never forget: an explicit Deny always wins.
If no policy allows the action, the default is an implicit deny.
So a request succeeds only when at least one policy explicitly allows it and no policy explicitly denies it.
This is why permissions feel "closed by default" - silence means no.
The evaluation model has practical consequences for debugging.
An AccessDenied error is not a bug in your code or the network - it is IAM telling you the authorization step returned deny.
The fix is a policy change, not a retry.
Credentials also differ in lifetime, and this shapes architecture decisions.
| Credential source | Strength | Weakness | Best fit |
|---|---|---|---|
| IAM user access keys | Simple to create | Long-lived, easy to leak, manual rotation | Rare - break-glass or legacy only |
| Assumed-role (STS) | Short-lived, auto-rotated | Requires a role and trust setup | Applications, CI, cross-account access |
| Instance/task/Lambda role | Zero secrets in code | Only works inside that AWS compute | Any code running on AWS |
The right default is a role, not a user with keys.
Roles deliver temporary credentials through STS (Security Token Service), which expire in minutes to hours and rotate automatically, so a leaked token has a short blast radius.
There is also a subtle scaling point.
Because IAM evaluates policies on every request, extremely broad wildcard policies do not make calls faster - they only widen your exposure.
Tightening a policy has no runtime cost, so least privilege is effectively free at request time.
For observability, IAM decisions are logged in AWS CloudTrail, which records the principal, action, resource, and outcome of API calls - the authoritative record when you need to prove who did what.
Action: * policy improves performance." - Policy breadth has no effect on request latency; it only increases risk.The identity making the request - typically an IAM user or, more commonly in production, an IAM role your application has assumed. The principal is who IAM evaluates policies against.
No. The SDK uses the secret to compute a SigV4 signature over the request. AWS recomputes the same signature with its own copy of the secret and compares. The secret itself never travels over the wire.
From the default provider chain: environment variables, then shared config and credentials files, then container or instance metadata. It uses the first source that returns credentials.
Because AccessDenied is an authorization result, not a code error. Authentication likely succeeded, but no policy allowed the action, or an explicit Deny blocked it. The fix is a policy change.
During policy evaluation, if any applicable policy explicitly denies the action, the request is denied - regardless of how many policies allow it. Deny is not overridden.
The request is denied by an implicit deny. IAM is closed by default: access requires an explicit Allow with no matching Deny.
Yes. Role credentials are temporary - they come from STS, include a session token, expire automatically, and rotate. User access keys are long-lived and must be rotated manually.
No. IAM evaluates policies on every request regardless of size, so a narrow least-privilege policy costs nothing extra at runtime while greatly reducing risk.
AWS CloudTrail records API calls with the principal, action, resource, and result. It is the authoritative log for auditing who called what and whether it was allowed.
Very few. Some intentionally public, anonymous operations (like reading a public S3 object) do not require a signed principal. The overwhelming majority of AWS API calls go through IAM.
Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).
Revisado por Chris St. John·Última atualização: 23 de jul. de 2026