Accounts access

Grant applications access to AWS without IAM user access keys: use IAM roles for EC2, Lambda, ECS, and other services so workloads assume a role and get temporary credentials. Use this for all new and existing apps to avoid long-lived keys and meet least privilege.

Enable multi-factor authentication on the AWS root user, verify the MFA device works, and confirm sign-in requires the second factor. Use this after securing the root account and before any break-glass procedure.

Create IAM user access keys for CLI and API use, rotate them on a schedule, and deactivate or delete old keys. Use this for human or script access that cannot use IAM roles; prefer roles for applications.

Attach AWS managed or customer-managed policies to an IAM user via console or CLI, and verify effective permissions. Use this to grant or change permissions without editing inline policies; prefer groups for multiple users with the same role.

Attach managed or inline policies to an IAM role so the role has the permissions needed when assumed by a service or principal. Use the console or CLI to attach and verify; prefer managed policies and least privilege.

Assume an IAM role from the AWS CLI to get temporary credentials: use assume-role (or assume-role-with-saml/web-identity), set the returned credentials in the environment or profile, and run commands as the role. Use this for cross-account or delegated access without long-lived keys for the role.

Create an IAM role that EC2 instances can assume via an instance profile: set the trust policy to ec2.amazonaws.com, attach least-privilege policies, and attach the instance profile to the instance. Use this so applications on EC2 access AWS APIs without access keys.

Create an IAM role that an AWS service can assume to perform actions on your behalf: set the trust policy to the service principal, attach least-privilege permissions, and use the role in the service configuration. Use this for service-to-service access without long-lived keys.

Create an IAM role for AWS Lambda so the function can call AWS APIs: trust policy for lambda.amazonaws.com, attach execution and resource policies, and set the role as the function's execution role. Use this so Lambda runs without access keys.

Create an IAM user with only the permissions needed for their role: no full admin unless required, use groups and managed policies, and enable MFA. Use this for human operators who need console or CLI access without using root.

Revoke a user's access to AWS when they use IAM Identity Center (SSO) or another federated identity: remove the user from IdP groups or disable the user in the IdP, remove Identity Center assignments, and invalidate existing sessions. Use this when someone leaves or when federated access must be cut off immediately.

Revoke all access for an IAM user without deleting the user: deactivate console password, delete all access keys, and detach MFA. Use this when someone leaves or credentials are compromised; optionally delete the user after revoking.

Lock down the AWS root account: enable MFA, remove access keys, create an IAM admin user for daily use, and apply a root-usage alert. Use this guide before using root for anything except account-level tasks and break-glass.

Install your existing SSH public key on a remote server (via ssh-copy-id or authorized_keys) or in GitHub so you can authenticate without a password. Includes verification and common pitfalls: permissions, wrong key, and ssh-agent.

Enable 2FA on an account using an authenticator app (TOTP), save recovery or backup codes in a safe place, and verify that the next login requires the second factor. Includes what to do before turning 2FA on and how to recover if locked out or if the app clock is wrong.

Create an Ed25519 SSH key pair, set correct permissions and optional passphrase, and verify passwordless login to a remote server. Use this guide before adding keys to servers or GitHub.

Connect AWS IAM Identity Center to an external identity provider (IdP) such as Active Directory, Okta, or Azure AD: configure SAML 2.0 or OIDC, set attribute mapping for user and group, and set Identity Center as the identity source. Use this so users sign in with corporate credentials and access AWS via SSO.

Execute controlled emergency access to the AWS root account when IAM or IAM Identity Center is unavailable. Covers when to use break-glass, how to sign in as root with MFA, and how to restore normal access and audit the event.

Enable AWS IAM Identity Center (SSO) in your organization so users sign in once and access assigned AWS accounts and applications. Configure the identity source, create permission sets, and assign users or groups to accounts. Use this for centralized access without creating IAM users per account.

Review and tighten IAM role trust policies: who can assume the role, under what conditions, and whether trust is least privilege. Use get-role and inspect AssumeRolePolicyDocument; remove overly broad principals and add conditions (e.g. MFA, source ARN) where appropriate.

Audit effective permissions for an IAM user: list attached and group policies, simulate actions with the IAM policy simulator, and use last-used for access keys. Use this to verify least privilege and before revoking or changing access.

Require multi-factor authentication for IAM users signing in to the console or calling sensitive APIs. Use an IAM policy condition that allows actions only when MFA is present, and assign MFA devices to every human user.

Detect AWS access keys or credentials that may be leaked or compromised: search code and public repos, check CloudTrail for anomalous use, use AWS credentials report and last-used, and revoke keys immediately when found. Use this when you suspect a key was exposed or for periodic audits.

Identify IAM users that have not signed in or used access keys recently using last-used timestamps and CloudTrail, then safely remove or deactivate them. Use this to reduce attack surface and meet compliance; avoid removing users that own critical resources.

Reduce risk from IAM user access keys and long-lived credentials: enforce MFA, restrict with conditions, scope policies to specific resources, and plan migration to IAM roles. Use this when you must keep some long-lived keys but want to minimize blast radius and misuse.

Migrate applications from IAM user access keys to IAM roles so workloads use temporary credentials and keys can be removed. Use instance profiles for EC2, execution roles for Lambda, and OIDC or assume-role for external/on-prem; then rotate off and delete the old keys.

Safely remove or decommission an IAM role: detach all policies, delete inline policies, remove the role from instance profiles, then delete the role. Use this when a workload is retired or the role is consolidated; ensure no resources still assume or reference the role.

Safely rotate IAM access keys used by applications and automation: create a second key, update all consumers, verify they use the new key, then deactivate and delete the old key. Use this on a schedule or when a key may be compromised; prefer migrating to IAM roles to avoid long-lived keys.

Systematically revoke a departing user’s access: remove or rotate their SSH keys, revoke API tokens and sessions, remove them from organizations and team apps, and rotate shared credentials. Includes verification steps and a short audit so you can confirm access is gone.

Diagnose and fix 'permission denied' and 'access denied' errors on Unix-like systems: SSH publickey and file permission issues. Learn how to read error messages, run minimal checks, and apply safe chmod/chown without using chmod 777 or weakening security.

Use this checklist before going live or handing off a system: confirm SSH keys and 2FA are in place, passwords and API tokens are managed safely, access is least-privilege, and you have a way to recover and revoke access. Reduces lockout and security risk at launch.