Identity in AWS is managed primarily through IAM, which supports two principal identity types. An IAM user is a permanent identity with long-lived credentials, while an IAM role is an identity with no long-lived credentials that is assumed temporarily by users, services, or external identities to obtain short-lived STS tokens. AWS STS, the Security Token Service, issues those temporary credentials (access key, secret key, session token) for federated identities, assumed roles, or cross-account access. STS credentials can last from 15 minutes up to 12 hours, the absolute session duration hard cap, governed by the role's MaxSessionDuration.
Permissions in IAM are expressed through policies. A managed policy is a standalone, reusable policy that can be attached to many identities, while an inline policy is embedded in a single identity and removed when that identity is deleted. Managed policies attached to users and groups can be up to 5,120 characters, inline user policies up to 2,048 characters, and inline role policies up to 10,240 characters, with service-specific quotas also applying.
For workloads running on AWS you avoid embedding long-lived keys in code. An EC2 instance gets AWS API permissions by attaching an IAM instance profile, a container for an IAM role, so the SDK or CLI can automatically retrieve credentials from IMDS on the instance. Lambda functions obtain permissions via an attached IAM execution role, and Lambda automatically populates environment variables such as AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN.
Beyond IAM identities, applications that need user sign-in and federation use Amazon Cognito. User Pools are user directories that handle sign-up, sign-in, MFA, and social identity providers and return JWT tokens. Identity Pools exchange those tokens, or tokens from other IdPs, for AWS STS temporary credentials so that applications can access AWS resources directly. Access to S3 can also be granted through resource-based S3 bucket policies, which, unlike identity-based IAM policies, can be used for cross-account access and for public or anonymous principals.