AWS IAM and Security: Reference Cheatsheet
Cheatsheet · AWS · Identity and security
AWS IAM and Security: Reference Cheatsheet
The identity and perimeter half of the AWS architect syllabus on one sheet: IAM principals, policy types and the evaluation order, federation through Identity Center, SAML, OIDC and Cognito, Organizations guardrails, Directory Service, KMS and CloudHSM, WAF, Shield and Firewall Manager, and RAM. Built from Jeremy Bates’ SAA-C02 study notes, with the eight original diagrams redrawn and every point checked against how AWS behaves in 2026. The tickable companion is bubim-awsiam-run.
aws sts get-caller-identity cpx · bub.im
MAP
Which service answers which question
Three questions sit under every row: who is calling, what may they do, and where that decision is made.
| Need | Service | Notes |
|---|---|---|
| People into many AWS accounts | IAM Identity Center | successor to AWS SSO; a permission set becomes a role in every assigned account |
| People into one account from a corporate IdP | IAM SAML 2.0 provider | one role per job function; move to Identity Center once there are several accounts |
| Customers of your web or mobile app | Amazon Cognito | user pool signs them in, identity pool hands out AWS credentials |
| Workloads running on AWS | IAM roles | instance profile, Lambda execution role, ECS task role, EKS Pod Identity; no stored keys |
| Workloads outside AWS | IAM Roles Anywhere, IAM OIDC provider | X.509 certificates for servers, OIDC tokens for CI such as GitHub Actions or GitLab |
| Guardrails across many accounts | Organizations SCPs and RCPs | SCPs cap principals, RCPs cap resources; neither grants anything |
| Windows Active Directory for AWS workloads | AWS Directory Service | Managed Microsoft AD, AD Connector, Simple AD (closed to new customers) |
| Use a resource from another account | AWS RAM or a resource-based policy | RAM for subnets, transit gateways, Resolver rules; policies for S3, KMS, SQS, Lambda |
| Encryption keys | AWS KMS, AWS CloudHSM | KMS is the managed default; CloudHSM when you need single-tenant HSMs under sole control |
| Layer 7 filtering | AWS WAF | web ACLs on CloudFront, ALB, API Gateway, AppSync, Cognito and more |
| DDoS protection | AWS Shield | Standard is free and always on; Advanced adds a response team and cost protection |
| One firewall policy for the whole org | AWS Firewall Manager | WAF, Shield Advanced, security groups, Network Firewall, DNS Firewall |
IAM
IAM core: principals and access methods
IAM is global and free. A new user, group or role starts with no permissions; everything is implicitly denied until a policy allows it. IAM is for access to AWS, not for authenticating the users of your own application: use Cognito or your IdP for that.
| Principal | What it is | Credentials | Use it for |
|---|---|---|---|
| Root user | the identity behind the account e-mail | password, MFA; never access keys | billing and the root-only tasks below, nothing else |
| IAM user | long-lived identity in one account, a person or a service account | password, up to 2 access keys, up to 8 MFA devices | break-glass and tools that cannot use roles; prefer Identity Center for people |
| IAM group | collection of users, one level only, no nesting | none; carries policies | assigning the same policies to many users; a group is not a principal and cannot be named in a policy |
| IAM role | identity with no long-term credentials, assumed by a trusted entity | temporary STS keys plus session token, 15 min to 12 h | applications, AWS services, cross-account access, federation |
| Service-linked role | role predefined and owned by an AWS service | assumed only by that service | created by the service; you cannot edit its permissions, SCPs do not restrict it |
| Instance profile | container for exactly one role, attached to EC2 | delivered through IMDS (use IMDSv2) | giving an instance a role at launch or later; shown on the instance details page |
| Federated principal | user from an external IdP via SAML 2.0 or OIDC | temporary credentials | workforce and app users without creating IAM users |
Access methods
| Method | Credential | Where it lives | Notes |
|---|---|---|---|
| Console | password plus MFA, or the Identity Center access portal | browser session | federated sign-in avoids passwords in AWS altogether |
| CLI and SDK | access key ID plus secret access key, or an SSO profile | ~/.aws/credentials, ~/.aws/config | never embed keys in code; aws configure sso gives short-lived keys |
| Code on AWS compute | role credentials | IMDS, container endpoint, Lambda env | rotated automatically by AWS, nothing to store |
| Server certificates | X.509 certificate and key | ACM, or the IAM certificate store | use ACM; the IAM store is only for Regions or cases ACM does not cover |
Tasks only the root user can do
| Task | Notes |
|---|---|
| Change account name, e-mail, root password, close the account | member account root credentials can be removed centrally; recovery then goes through the management account |
| Restore IAM permissions when the only admin locked itself out | keep a break-glass role instead of relying on this |
| Change or cancel the AWS Support plan | |
| Configure S3 MFA delete on a bucket | only the root user can enable it |
| Remove an S3 bucket policy or SQS queue policy that denies everyone | in org member accounts: sts:AssumeRoot with S3UnlockBucketPolicy or SQSUnlockQueuePolicy |
| Register as a seller in the Reserved Instance Marketplace, sign up for GovCloud | rare |
POL
Policy types and anatomy
Two policy kinds grant permissions: identity-based (on a user, group or role) and resource-based (on the resource). Everything else in this table only narrows what those two allow.
| Type | Attached to | Grants? | Typical use |
|---|---|---|---|
| AWS managed policy | users, groups, roles | grants | common use cases and job functions such as ReadOnlyAccess, AmazonDynamoDBFullAccess; AWS owns and edits them, they have an ARN |
| Customer managed policy | users, groups, roles | grants | your least-privilege policies; reusable, up to 5 stored versions, 6,144 characters |
| Inline policy | exactly one user, group or role | grants | strict one-to-one binding; deleted with the identity; prefer managed policies |
| Resource-based policy | S3 bucket, KMS key, SQS, SNS, Lambda, ECR, Secrets Manager, role trust policy | grants | has a Principal; can name other accounts, so it enables cross-account access without switching roles |
| Permissions boundary | a user or a role | caps | the maximum an identity can ever get; lets developers create roles without escalating |
| SCP | org root, OU, account | caps | maximum permissions for IAM principals in member accounts; management account exempt |
| RCP | org root, OU, account | caps | maximum permissions on resources in member accounts, for any caller, including outsiders |
| Session policy | passed to AssumeRole, AssumeRoleWithSAML, GetFederationToken | caps | narrow one session below what the role allows |
| VPC endpoint policy | interface or gateway endpoint | caps | limit what may pass through the endpoint, for example only your org’s buckets |
| ACL | S3 buckets and objects (legacy), VPC subnets (network, not IAM) | legacy | S3 ACLs are disabled by default on new buckets; leave them off |
Quotas Roles carry up to 20 managed policies by default since August 2026 (raise to 25 through Service Quotas); users and groups keep their lower defaults. Inline policy totals: 2,048 characters per user, 5,120 per group, 10,240 per role.
Anatomy of a policy statement
| Element | Meaning | Example |
|---|---|---|
| Version | language version; always use the current one, it enables policy variables | “2012-10-17” |
| Sid | optional label for the statement | “ReadReports” |
| Effect | Allow or Deny | “Deny” |
| Principal | who; only in resource-based and trust policies | {“AWS”: “arn:aws:iam::222222222222:root”} |
| Action, NotAction | API operations, wildcards allowed | “s3:GetObject”, “ec2:Describe*” |
| Resource, NotResource | ARNs the statement covers | “arn:aws:s3:::reports/*” |
| Condition | when the statement applies, for example source IP or MFA | {“Bool”: {“aws:MultiFactorAuthPresent”: “true”}} |
customer managed policy: read one bucket, MFA required, nothing from outside the office range
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ReadReports",
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:ListBucket"],
"Resource": ["arn:aws:s3:::reports", "arn:aws:s3:::reports/*"],
"Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
},
{
"Sid": "OfficeOnly",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "*",
"Condition": {
"NotIpAddress": {"aws:SourceIp": "203.0.113.0/24"},
"Bool": {"aws:ViaAWSService": "false"}
}
}
]
}Condition keys worth knowing
| Key | Use |
|---|---|
| aws:PrincipalOrgID | in resource policies: only principals from my organization |
| aws:ResourceOrgID | in identity, SCP or endpoint policies: only resources that belong to my organization |
| aws:SourceIp | caller public IP range; does not match calls arriving through a VPC endpoint |
| aws:SourceVpce, aws:SourceVpc | only through this endpoint or VPC |
| aws:MultiFactorAuthPresent, aws:MultiFactorAuthAge | require MFA, or MFA within the last N seconds |
| aws:RequestedRegion | region deny in SCPs |
| aws:PrincipalTag, aws:ResourceTag, aws:RequestTag, aws:TagKeys | attribute-based access control (ABAC) |
| aws:SecureTransport | deny requests over plain HTTP |
| aws:SourceAccount, aws:SourceArn | confused-deputy protection when a service principal acts for you |
| sts:ExternalId | third parties assuming a role in your account |
| aws:ViaAWSService, aws:CalledVia, kms:ViaService | allow or deny when an AWS service makes the call on your behalf |
| iam:PermissionsBoundary, iam:PassedToService | force boundaries on created roles, limit which service a role can be passed to |
EVAL
Policy evaluation logic
Everything starts denied, an explicit deny always wins, and an Allow has to survive every filter on the way down. The chart below follows the current AWS flow, which adds RCPs and splits resource-based policies by the principal they name; the 2020 original had six lanes.
fig 1 · evaluation order as AWS documents it today: deny first, then RCP, SCP, resource-based, identity-based, boundary, session
| Rule | Consequence |
|---|---|
| Default deny | no policy, no access; the root user is the only exception inside its own account |
| Explicit deny wins | a Deny in any identity, resource, SCP, RCP, boundary or session policy ends the evaluation |
| Organizations filters | RCP and SCP each need an Allow at every level from the root to the account, and no Deny |
| Same account: union | an Allow in either the identity policy or the resource policy is enough |
| Cross account: intersection | the caller account must allow the call and the target resource policy or role trust must allow the caller |
| Boundaries and session policies | only filter, never add; the result is the overlap with the identity policy |
| Role trust and KMS key policies | must name the principal or the account; an IAM Allow alone does not open a KMS key or a role |
XACCT
Cross-account access
Use it when someone in one account needs a resource in another, for example production and development. Either the caller switches into a role in the target account, or the target resource carries a policy that names the caller.
fig 2 · both halves are required: B allows John to call AssumeRole, A trusts B in the role
account A: trust policy on role ReportsRead
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::222222222222:root"},
"Action": "sts:AssumeRole",
"Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
}]
}account B: identity policy on John or his group
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111111111111:role/ReportsRead"
}]
}# CLI: assume once by hand aws sts assume-role \ --role-arn arn:aws:iam::111111111111:role/ReportsRead \ --role-session-name john \ --serial-number arn:aws:iam::222222222222:mfa/john --token-code 123456 # or let the CLI do it: ~/.aws/config [profile reports] role_arn = arn:aws:iam::111111111111:role/ReportsRead source_profile = default mfa_serial = arn:aws:iam::222222222222:mfa/john
| Aspect | Assume a role | Resource-based policy |
|---|---|---|
| Caller permissions | given up for the session; acts only as the role | kept; the caller acts as itself |
| Works for | every service | services that support resource policies: S3, SQS, SNS, KMS, Lambda, Secrets Manager, ECR and others |
| CloudTrail shows | the role session, plus source identity if set | the caller’s own ARN |
| Typical | console Switch role, multi-account tooling, pipelines | bucket shared with a partner, Lambda invoked from another account |
| Third parties | add sts:ExternalId to the trust policy against the confused deputy problem | add aws:SourceAccount or aws:SourceArn for service principals |
FED
Identity providers, federation and sign-on
Federation lets users live in a directory outside AWS and still use AWS resources: no sign-in code to maintain, no credentials embedded in the app, no IAM user per person. AWS trusts any IdP that speaks SAML 2.0 or OpenID Connect; OIDC for consumer logins is what the notes call web identity federation.
| Source of identities | Protocol | AWS side | Pick it when |
|---|---|---|---|
| Corporate IdP (Entra ID, Okta, Ping, AD FS) to many accounts | SAML 2.0 plus SCIM provisioning | IAM Identity Center | default for workforce access to an organization |
| Corporate IdP to a single account | SAML 2.0 | IAM SAML provider and roles | one account, or a setup that predates Identity Center |
| On-premises Active Directory | Kerberos and LDAP through Directory Service | AD Connector or Managed AD as the Identity Center source | AD stays the source of truth; AD itself queries users over LDAP |
| Google, Apple, Amazon, Facebook, any OIDC IdP | OIDC, OAuth 2.0 | Cognito user pool | customers of a web or mobile app |
| CI/CD (GitHub Actions, GitLab, Bitbucket) | OIDC | IAM OIDC provider plus role | pipelines without stored access keys |
| Servers outside AWS | X.509 | IAM Roles Anywhere | on-premises or other-cloud workloads calling AWS APIs |
| Custom identity broker | your code calls STS | GetFederationToken or AssumeRole | legacy; do not build new ones |
STS operations behind every login
| API | Caller | Session length |
|---|---|---|
| AssumeRole | IAM user or role | 1 h default, up to the role maximum of 12 h; capped at 1 h when chaining roles |
| AssumeRoleWithSAML | holder of a SAML assertion | up to the role maximum, also limited by the SessionDuration attribute |
| AssumeRoleWithWebIdentity | holder of an OIDC token (Cognito, GitHub, EKS) | up to the role maximum |
| GetSessionToken | IAM user, usually to add MFA | 15 min to 36 h, 12 h default |
| GetFederationToken | IAM user acting as a broker | 15 min to 36 h, 12 h default |
| AssumeRoot | management or delegated admin account, for a member account | up to 15 min, one privileged task |
COG
Amazon Cognito
Identity for web and mobile apps, in two independent halves: user pools sign people in, identity pools turn a signed-in user (or a guest) into temporary AWS credentials.
fig 3 · tokens come from the user pool, AWS credentials from the identity pool, then the app calls services directly
| Aspect | User pool | Identity pool |
|---|---|---|
| Answers | who is this user (authentication) | which AWS permissions this user gets (authorization) |
| Returns | ID, access and refresh tokens (JWT) | temporary STS credentials for an IAM role |
| Sign-in sources | native users, Google, Apple, Facebook, Amazon, SAML, OIDC | user pool tokens, social and SAML or OIDC IdPs directly, developer-authenticated identities, guests |
| You configure | password policy, MFA, required attributes, username type, Lambda triggers, managed login pages, app clients | authenticated and unauthenticated roles, role mapping rules, principal tags for ABAC |
| Protect it with | AWS WAF web ACL on the pool, threat protection (Plus plan) | tight role policies, for example dynamodb:LeadingKeys or an S3 prefix per identity ID |
| Plans | Lite, Essentials, Plus | no plans, priced through the services the credentials call |
IDC
IAM Identity Center (formerly AWS SSO)
One user identity, one sign-in, access to many AWS accounts and SAML apps without re-entering passwords. Renamed from AWS Single Sign-On in July 2022. Key exam scenario from the notes, still valid: the company already has Active Directory and wants single sign-on into many accounts, so use Identity Center with AD as the identity source.
| Concept | Meaning |
|---|---|
| Identity source | one of: the built-in Identity Center directory, Active Directory (Managed AD or AD Connector), or an external SAML 2.0 IdP with SCIM |
| Permission set | a template of managed, inline and boundary policies; deployed as a role named AWSReservedSSO_* in every assigned account |
| Account assignment | user or group, plus permission set, plus account; groups are the sane unit |
| Session duration | per permission set, 1 to 12 h |
| Access portal | one URL listing accounts and roles; the CLI uses it through aws configure sso and aws sso login |
| ABAC | user attributes from the identity source arrive as session tags |
| Instance types | organization instance for multi-account access; account instance only for single-account application use |
| Delegated administration | run day-to-day administration from a member account, keep the management account empty |
ORG
AWS Organizations
Central management of many accounts: billing, access, compliance and security, a hierarchy of OUs, automated account creation, policies applied to all accounts, one payment method and resource sharing across accounts.
fig 4 · policies attach to the root, an OU or an account and inherit downward; OUs nest up to five levels
| Capability | Detail |
|---|---|
| Consolidated billing | one payer; usage is aggregated for volume tiers (S3, data transfer), Reserved Instances and Savings Plans are shared across accounts |
| Hierarchy | root, OUs nested up to five levels, each account in exactly one OU |
| Account creation | CreateAccount API, Control Tower Account Factory, or invitations for existing accounts |
| Policy types | SCP RCP tag backup AI opt-out declarative, each enabled per organization |
| Trusted access | services that act across the org: CloudTrail, Config, GuardDuty, Security Hub, IAM, RAM, Identity Center |
| Delegated administrator | security services run from a dedicated member account instead of the management account |
Service control policies
If an SCP says nobody may create EC2 instances, no IAM permission in the account can override it. The example the notes use, deny any launch that is not a micro instance, is drawn below.
fig 5 · SCPs filter, they do not grant; the deny on OU 1 still binds Account B under OU 2
| Rule | Detail |
|---|---|
| Never grants | effective permission is the IAM Allow and the SCP Allow together, minus any Deny |
| Inheritance | an Allow is needed at every level from root to account; a Deny anywhere above wins; the most restrictive result applies |
| Out of reach | the management account, service-linked roles |
| Strategy | deny list: keep FullAWSAccess and add denies (usual); allow list: replace it with explicit allows |
| Limits | up to 5 SCPs per root, OU or account, 5,120 characters each |
| Usual denies | leaving the organization, disabling CloudTrail, Config, GuardDuty or Security Hub, Regions outside your list, root user actions, launches without IMDSv2 |
SCP: the micro-instance rule from fig 5 plus a Region deny
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "MicroOnly",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {"StringNotEquals": {"ec2:InstanceType": "t3.micro"}}
},
{
"Sid": "EuOnly",
"Effect": "Deny",
"NotAction": ["iam:*", "organizations:*", "sts:*", "support:*", "route53:*", "cloudfront:*", "budgets:*"],
"Resource": "*",
"Condition": {"StringNotEquals": {"aws:RequestedRegion": ["eu-central-1", "eu-west-1"]}}
}
]
}Setup order from the notes
| Step | Action | CLI |
|---|---|---|
| 1 | Create the organization with all features | aws organizations create-organization –feature-set ALL |
| 2 | Create or invite accounts (invites go out by e-mail) | create-account, invite-account-to-organization |
| 3 | Create OUs | create-organizational-unit –parent-id r-xxxx |
| 4 | Enable the policy type, create the SCP, attach it to an OU; children inherit it | enable-policy-type, create-policy, attach-policy |
DIR
AWS Directory Service
Three managed flavours plus the do-it-yourself option. Managed Microsoft AD is a real Windows AD whose domain controllers AWS runs in two Availability Zones; it can trust your on-premises AD so users stay where they are and still authenticate to AWS.
fig 6 · Managed Microsoft AD as the hub; WorkDocs, WorkMail and Chime from the original slide are retired or retiring and left out
| Flavour | What it is | Size | Trusts | Pick it when |
|---|---|---|---|---|
| AWS Managed Microsoft AD | full Windows Server AD, AWS patches and backs up the DCs | Standard: about 5,000 users (30,000 objects); Enterprise: up to 500,000 objects, multi-Region | yes one-way or two-way, forest or external | more than 5,000 users, trusts, schema extensions, GPO, SQL Server and .NET apps; in-place upgrade Standard to Enterprise since August 2026 |
| AD Connector | directory gateway that proxies requests to your existing DCs; nothing cached in the cloud | Small or Large, upgrade only | n/a | you want to use existing AD with AWS: console sign-in mapped to IAM roles, WorkSpaces, EC2 domain join, MFA through RADIUS |
| Simple AD | standalone, Samba 4 based, AD compatible | Small up to 500 users, Large up to 5,000 | no | existing deployments only: closed to new customers; no SQL Server, schema extensions or trusts |
| Self-managed AD on EC2 | your DCs in AWS, replicated with on-premises | your design | your design | low-latency authentication in the cloud with full control; you carry replication, patching and backups |
Network Managed AD needs two subnets in different AZs. Trusts and AD Connector need line of sight to the on-premises DCs over VPN or Direct Connect, with DNS forwarding in both directions.
fig 7 · which Directory Service flavour; redrawn from the comparison table as a decision tree
KMS
AWS KMS and CloudHSM
KMS keys used to be called customer master keys (CMKs). You create a customer managed key with key material generated by KMS or imported from outside, define which users and roles may use and administer it, and AWS handles the hardware.
fig 8 · who sees, who manages, who shares; rotation applies to symmetric keys with KMS-generated material only
| Item | Detail |
|---|---|
| Key material origin | AWS_KMS (default), EXTERNAL (imported, you keep a copy), AWS_CLOUDHSM (custom key store), EXTERNAL_KEY_STORE (keys stay in your HSM outside AWS) |
| Key specs | symmetric AES-256 (default, used by service integrations), asymmetric RSA and ECC, HMAC |
| Access control | the key policy is primary; IAM policies count only when the key policy delegates to the account; grants give temporary, narrow use to a service or principal |
| Rotation | customer managed: optional, every 90 to 2,560 days (default 365), or on demand; AWS managed: every year; old material is kept so old ciphertext still decrypts |
| No automatic rotation | asymmetric keys, HMAC keys, imported material, custom key stores: rotate manually with a new key and an alias swap |
| Deletion | scheduled with a 7 to 30 day waiting period (default 30), cancellable until then; disable the key first if in doubt |
| Envelope encryption | Encrypt handles at most 4 KB; for data use GenerateDataKey, encrypt locally, store the encrypted data key next to the data |
| Scope | Regional; multi-Region keys (mrk- prefix) share ID and material across Regions |
KMS against CloudHSM
| Aspect | AWS KMS | AWS CloudHSM |
|---|---|---|
| Tenancy | multi-tenant managed service on FIPS-validated HSMs | single-tenant, tamper-resistant HSMs in your VPC; keys only for your use |
| Who controls keys | you through policies, AWS operates everything | you alone: crypto users, keys, cluster; AWS cannot see key material |
| Interfaces | KMS API, native integration with most AWS services | PKCS#11, JCE, OpenSSL, Microsoft CNG and KSP |
| High availability | built in | a cluster of HSMs spread over AZs; add at least two for HA and load balancing |
| Setup | one API call | create the cluster, sign its CSR with your issuing CA, upload the certificates, activate |
| Pricing | per key per month plus requests | per HSM per hour, no upfront cost |
| Pick it for | almost everything | regulations demanding dedicated hardware, TLS offload, Oracle TDE, private CA keys, or as a KMS custom key store |
EDGE
AWS WAF, Shield and Firewall Manager
WAF inspects HTTP and HTTPS requests and answers with the content or with HTTP 403. Shield absorbs DDoS. Firewall Manager pushes both, plus network firewall rules, across every account in the organization.
AWS WAF
| Item | Detail |
|---|---|
| Protects | CloudFront (global; web ACL in us-east-1), ALB, API Gateway REST API, AppSync GraphQL API, Cognito user pool, App Runner, Verified Access, Amplify (global web ACL), Bedrock AgentCore Gateway |
| Web ACL | ordered rules plus a default action: allow all except what rules block, or block all except what rules allow; one web ACL per resource |
| Match on | IP set, country, headers, query string, body, URI, string or regex content, size, SQL injection, cross-site scripting, labels from earlier rules |
| Rate-based rules | block or challenge a client above N requests per window; first line against floods and scraping |
| Managed rule groups | AWS: core rule set, known bad inputs, SQL database, IP reputation, anonymous IP, Bot Control, account takeover and account creation fraud prevention; plus Marketplace sellers |
| Actions | Allow, Block (403 or a custom response), Count (test a rule before enforcing), CAPTCHA, Challenge |
| Logging | CloudWatch Logs, S3 or Data Firehose; sampled requests in the console |
| Legacy | the condition-based model in the 2020 notes is WAF Classic; build everything on the current WAF (v2) API |
Shield Standard against Shield Advanced
| Aspect | Shield Standard | Shield Advanced |
|---|---|---|
| Cost | free, on by default for every account | $3,000 per month per organization, 1-year commitment, plus data transfer out |
| Layers | network and transport (L3, L4) | L3, L4 and application layer with WAF; on CloudFront, Route 53, Global Accelerator, ELB, Elastic IPs |
| Response | automatic mitigation | Shield Response Team around the clock, optional proactive engagement |
| Cost protection | no | credits for scaling charges caused by a DDoS event |
| Extras | none | attack diagnostics and metrics, health-based detection, WAF and Firewall Manager for protected resources at no extra fee |
DDoS design Expose only what must face the internet, put CloudFront or Global Accelerator in front, let Auto Scaling and ELB absorb spikes, and add WAF rate-based rules. Shield sits on top of WAF, not instead of it.
AWS Firewall Manager
| Item | Detail |
|---|---|
| Prerequisites | Organizations with all features, AWS Config recording in member accounts, a Firewall Manager administrator account |
| Manages | WAF web ACLs, Shield Advanced protections, VPC security groups, Network Firewall, Route 53 Resolver DNS Firewall, third-party firewalls |
| Behaviour | applies policies by OU, account and tag scope; new accounts and resources pick them up automatically; optional auto-remediation |
RAM
AWS Resource Access Manager
Share resources between accounts without copying them: create a resource share, add the resource and the principals, and it appears in the other account. Useful between test and development accounts, or from a central network account to workload accounts.
| Shareable (examples) | What the other account gets |
|---|---|
| VPC subnets | launches resources into the owner’s subnets; the owner keeps routing, NACLs and the VPC |
| Transit Gateway, Cloud WAN core network | attaches its VPCs |
| Route 53 Resolver rules and profiles | the same forwarding rules for hybrid DNS |
| Aurora DB clusters | creates clones of the cluster |
| EC2 prefix lists, capacity reservations, Dedicated Hosts | uses them in its own configuration |
| AWS Private CA, IPAM pools, License Manager configurations, CodeBuild projects | issues certificates, allocates CIDRs, tracks licences, runs builds |
Tip Enable sharing with AWS Organizations once; shares to your org or an OU then apply without invitations. Services with resource policies (S3, KMS, SQS) share through the policy instead of RAM.
CRED
Credentials, access keys and profiles
Access keys are an access key ID plus a secret access key for API and CLI use. They are long-lived, so the right number in code is zero: roles on AWS compute, Identity Center profiles for people.
| File | Holds |
|---|---|
| ~/.aws/credentials | aws_access_key_id, aws_secret_access_key, aws_session_token per profile; nothing else |
| ~/.aws/config | region, output, sso_session, role_arn and source_profile, mfa_serial, credential_process |
Correction The notes put the Region in the credentials file. The Region belongs in ~/.aws/config; the credentials file is for secrets only.
~/.aws/config with an Identity Center session and a cross-account role
[sso-session corp] sso_start_url = https://d-1234567890.awsapps.com/start sso_region = eu-central-1 sso_registration_scopes = sso:account:access [profile dev-admin] sso_session = corp sso_account_id = 333333333333 sso_role_name = AdministratorAccess region = eu-central-1 [profile prod-read] role_arn = arn:aws:iam::444444444444:role/ReadOnly source_profile = dev-admin region = eu-central-1
| Order | Where the SDK looks for credentials (typical default chain) |
|---|---|
| 1 | environment: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN |
| 2 | web identity token file (AWS_WEB_IDENTITY_TOKEN_FILE), used by EKS and CI |
| 3 | shared files: the selected profile, including SSO, role assumption and credential_process |
| 4 | container credentials: ECS task role, EKS Pod Identity |
| 5 | EC2 instance profile through IMDS |
| Task | Command |
|---|---|
| Who am I right now | aws sts get-caller-identity |
| List keys and their age | aws iam list-access-keys –user-name alice |
| When was a key last used | aws iam get-access-key-last-used –access-key-id AKIA… |
| Everything for every user | aws iam generate-credential-report; aws iam get-credential-report |
| Rotate (max 2 keys per user) | create-access-key, deploy, update-access-key –status Inactive, delete-access-key |
| Require IMDSv2 on an instance | aws ec2 modify-instance-metadata-options –instance-id i-0abc –http-tokens required |
BP
IAM best practices
The two lists in the notes merged, de-duplicated and brought up to date. The runbook turns each row into steps.
| # | Practice | Why | Check |
|---|---|---|---|
| 1 | Lock away the root user: no access keys, hardware MFA, billing and root-only tasks only; remove member-account root credentials centrally | root ignores IAM and SCP limits in its own account | credential report, root row |
| 2 | People sign in through Identity Center or federation, not IAM users | temporary credentials, one place to revoke | aws iam list-users |
| 3 | Where IAM users remain, one per person, never shared | accountability in CloudTrail | credential report |
| 4 | Permissions through groups or permission sets, by job role | no per-user drift | list-attached-user-policies |
| 5 | Least privilege: start from AWS managed policies, refine into customer managed ones | AWS managed policies are broad by design | Access Analyzer policy generation |
| 6 | Customer managed policies over inline policies | reusable, versioned, visible | list-role-policies |
| 7 | Review with access levels and last-accessed data | find unused services and actions | generate-service-last-accessed-details |
| 8 | Strong password policy for any IAM user that still has a password | baseline hygiene | get-account-password-policy |
| 9 | MFA for everyone; phishing-resistant FIDO2 keys or passkeys for privileged users | the notes’ U2F advice, in today’s terms | list-mfa-devices |
| 10 | Roles for applications on EC2, Lambda, ECS; never copy keys onto instances | keys on disk leak | IMDSv2 required |
| 11 | Roles to delegate, including across accounts and to third parties | no shared secrets | trust policies with ExternalId |
| 12 | Never share access keys; rotate the ones that must exist, remove the ones that are unused | long-lived keys are the top leak | get-access-key-last-used |
| 13 | Policy conditions for extra security: MFA, source IP or VPC endpoint, org ID | a stolen credential alone is not enough | validate-policy |
| 14 | Permissions boundaries wherever teams create their own roles | stops privilege escalation | get-role, PermissionsBoundary |
| 15 | Guardrails at org level: SCPs for principals, RCPs for the data perimeter | holds even when an account admin errs | list-policies-for-target |
| 16 | Monitor activity: org CloudTrail trail, GuardDuty, Security Hub, alarms on root sign-in | detect what prevention missed | cloudtrail describe-trails |
EXAM
Exam picks: if the question says X, answer Y
The “best choice” lines from the notes, with the ones AWS has since moved on.
| Scenario | Answer |
|---|---|
| Users of a mobile or web app need to sign in and reach S3 or DynamoDB | Cognito user pool plus identity pool |
| Company has its own AD and wants single sign-on to many AWS accounts | IAM Identity Center with AD (AD Connector or Managed AD) as the identity source |
| Users on the corporate network into one AWS account | SAML 2.0 federation to IAM roles |
| Use the existing on-premises AD with AWS services, nothing stored in AWS | AD Connector |
| More than 5,000 users, or a trust with on-premises AD | AWS Managed Microsoft AD |
| Cheap, small, basic directory | Simple AD in older questions; for new builds Managed AD Standard |
| Low-latency authentication in AWS with users copied from on-premises | self-managed AD on EC2 replicating with on-premises; works, but carries sync and copying overhead |
| EC2 application needs to read S3 | IAM role through an instance profile |
| Third-party auditor needs access to your account | role with sts:ExternalId in the trust policy |
| Developers may create roles but must not escalate | permissions boundary, enforced with iam:PermissionsBoundary |
| No account in an OU may use a service, whatever its IAM says | SCP deny attached to the OU |
| No principal outside the org may read any bucket in the org | RCP with aws:PrincipalOrgID |
| Remove root passwords from all member accounts | centralized root access management, sts:AssumeRoot |
| Keys must be in dedicated, single-tenant hardware | CloudHSM, optionally as a KMS custom key store |
| Encrypt data larger than 4 KB with KMS | envelope encryption with GenerateDataKey |
| Block SQL injection in front of an ALB | WAF web ACL with the SQL database managed rule group |
| DDoS response team and cost protection | Shield Advanced |
| Same WAF rules in every account automatically | Firewall Manager |
| Let workload accounts launch into central subnets | RAM VPC sharing |
DIFF
What changed since the 2020 notes
Everything above already reflects these; the table is here so the original notes can be read without being misled.
| 2020 notes | Today |
|---|---|
| Customer master key (CMK) | KMS key: customer managed, AWS managed or AWS owned |
| Keys rotate every year | customer managed: 90 to 2,560 days, default 365, plus on-demand rotation; AWS managed: every year |
| AWS Single Sign-On | IAM Identity Center (renamed July 2022) |
| U2F security keys | FIDO2 security keys and passkeys; up to 8 MFA devices per IAM user |
| SCPs as the only org guardrail | plus RCPs and centralized root access (November 2024) and declarative policies |
| Policy evaluation chart with six lanes | seven lanes with RCPs; resource-based Allows branch by session, role or account |
| WAF conditions, CloudFront, API Gateway, ALB, AppSync | WAF v2 rules, managed rule groups, labels, CAPTCHA and Challenge; also Cognito, App Runner, Verified Access, Amplify, AgentCore Gateway |
| Simple AD as the low-cost option | closed to new customers |
| Managed AD editions fixed at creation | in-place Standard to Enterprise upgrade (August 2026) |
| WorkDocs, WorkMail and Chime in the AD diagram | WorkDocs ended April 2025, Chime February 2026, and WorkMail closed to new customers in April 2026 with support ending March 2027; the redrawn figure leaves all three out |
| Azure AD, Office 365 | Microsoft Entra ID, Microsoft 365 |
| 10 managed policies per role | 20 by default since August 2026, up to 25 |
| Region stored with the access keys | Region goes in ~/.aws/config |
| Shield Advanced at 3,000 per month | unchanged: $3,000 per month per organization, 1-year term |
Original notes and diagrams: Jeremy Bates, AWS SAA-C02 IAM and Security (2020). Diagrams redrawn for this sheet; content checked against the AWS documentation for KMS rotation, IAM root access management, policy evaluation, Organizations RCPs, WAF protected resources, Shield pricing and Directory Service.
AWS IAM and Security Cheatsheet · REV 2026.10
© 2026 · BUB.IM · made in vim
0 comments