Accounts, IAM, and short-lived access

Know who is calling before choosing a service

An AWS account groups resources, access administration, and billing. A Region is a geographic service location; Availability Zones are separate locations within a Region used to design for failures. Some services are regional and some have global aspects, so an account number alone does not identify every target.

An identity is the principal making a request. Authentication establishes that identity; authorization decides whether the request is allowed. IAM policies express permissions using actions, resources, and conditions. An IAM role is assumed by an allowed principal to obtain temporary credentials. Its trust policy controls who may assume it; its permissions determine what an assumed session can do.

A named CLI profile stores configuration or points to a credential source. The profile is not itself a role or a permission grant. AWS Organizations can group accounts and apply controls such as service control policies, but those controls do not grant a user permissions merely by allowing an action at the organization level.

Use short-lived access when it is available

Use an assigned sandbox or dedicated learning account. Protect the root identity and reserve it for operations that require it; it is not the everyday automation identity. Install AWS CLI v2 through its official instructions and check aws --version.

With an existing IAM Identity Center assignment, run:

aws configure sso --profile learning
aws sso login --profile learning
aws sts get-caller-identity --profile learning

The wizard requires your real start or issuer URL, SSO region, assigned account, and permission set. It cannot create that assignment for you. A successful identity call returns fields including Account, Arn, and UserId. Compare the actual account and role with your intended sandbox privately; do not publish account inventory or credentials in notes.

Without assigned access, complete the reasoning exercise below. No cloud resource creation is needed to learn this model, and there is no benefit in inventing access keys.

Trace an authorization decision

Consider a practice role intended to read one S3 object. Authentication may succeed, yet the object request can fail because its action or resource is not allowed, a required condition does not match, or an applicable explicit deny overrides an allow. Resource policies, organization controls, permission boundaries, and session policies can affect the result. The exact evaluation depends on the request and policy types; do not assume one visible allow explains everything.

GetCallerIdentity reports the caller; it does not prove permission to read S3, create EC2 instances, or change IAM. Likewise, a successful request in one Region says little about a differently scoped regional resource.

Write this small operation card without making a change:

Environment variables, profiles, and runtime role credentials can change credential selection. Check the documented precedence when the identity differs between shell, SDK, and CI. Do not put keys in source files or Terraform variables to work around an expired session.

Checkpoint and next step

A caller identity succeeds but S3 returns access denied. Are the credentials necessarily invalid? No; this is commonly an authorization question. A role permits an action but an applicable explicit deny also matches. Which wins? The deny.

Retain the intended account/profile/Region in private lab notes. Clear cached SSO sessions when they are no longer needed, considering other work using them. Next, map network paths before selecting compute and data services.

References: Identity Center CLI setup↗, IAM roles↗, policy evaluation↗, and AWS Regions and zones↗.