Loading…
While this loads — worth knowing
ElastiCache RedisnotElastiCache Memcached
Redis has data structures — sorted sets, counters, pub/sub. Memcached has plain keys and nothing else.
Loading…
While this loads — worth knowing
Redis has data structures — sorted sets, counters, pub/sub. Memcached has plain keys and nothing else.
Who can do what to which AWS resource, and under what conditions. Every request to AWS is checked against it.
Where IAM takes you5 steps, all open
Every call to AWS is a request: someone wants to do something to something. It can come from the console, the CLI, an SDK, or another AWS service acting for you. IAM decides whether it is allowed.
Nothing is allowed until a policy allows it, and an explicit deny in any policy that applies overrides every allow. Most IAM questions in the exam are one of those two rules in disguise.
IAM itself is offered at no additional charge.
Nobody gets through a door by default. A badge opens only the doors written on it. Visitors pick up a badge at reception that stops working at the end of the day, which is far safer than handing out keys. A sign saying no entry beats any badge. The building's owners set rules no tenant can change, and a team lead can hand out badges only up to their own limit.
User or roleIdentity-based policysts:AssumeRoleRole sessionEffect: DenySCPPermissions boundaryAn explicit Deny in any policy that applies ends it here. Nothing overrides it.
If the account is in an organisation, the SCPs above it must allow the action. They grant nothing themselves.
If the user or role has a permissions boundary, the action must fall inside it.
Something has to allow it. Within one account, a resource-based policy such as a bucket policy can grant it too.
Pick a case to follow the request through each check.
The instances get a role through an instance profile, and the app picks up temporary credentials from the instance metadata. They are updated automatically before they expire, so there is nothing to rotate. The Lambda function has a role of its own. Each role allows only what its code does: one bucket, one table.
People: federate, and use MFA. AWS recommends that people sign in through an identity provider, ideally IAM Identity Center, and work with temporary credentials. Where an IAM user or the root user cannot be avoided, require MFA, preferably phishing-resistant passkeys or security keys.
The root user has complete access to everything in the account. Use it only for the few tasks that need it, such as closing a standalone account or changing its root email address or password, and never for everyday work.
Least privilege, checked by tools. IAM Access Analyzer runs over 100 checks on a policy, can generate a policy from what a role actually did according to CloudTrail, and flags resources shared publicly or with other accounts. Last accessed information shows permissions nobody uses.
iam:PassRole is a permission too. Launching an instance with a role needs permission to pass that role. Limit which roles each person may pass, or they could run code with more access than they have themselves.
IAM is offered at no additional charge: users, groups, roles and policies cost nothing to create or use.
The real cost is getting it wrong. A leaked access key can do anything its policy allows until someone notices, which is the practical case for roles and temporary credentials.
Prices change, so none are printed here. Check the IAM FAQs on aws.amazon.com.
| Identity | Credentials | Meant for | Choose it when |
|---|---|---|---|
| IAM role | Temporary, from AWS STS | Workloads, other accounts, federated people | An application runs on AWS, or access crosses accounts |
| IAM user | Long-term: a password and access keys | Cases that cannot use a role | A third-party tool only accepts access keys |
| IAM Identity Center | Temporary, through federation | Your workforce, across accounts | Staff need access to many accounts in an organisation |
| Cognito user pool | Tokens (JWTs) for your app | Your app's own users | Customers sign up and sign in to a web or mobile app |
| Cognito identity pool | Temporary AWS credentials | App users who must reach AWS directly | A mobile app uploads straight to S3 |
an application on EC2 needs to read from S3An IAM role, through an instance profile
Temporary credentials that update themselves. Never access keys stored on the instance.
grant users in another AWS account accessA role they assume, whose trust policy names their account
Their own account must also allow them to call sts:AssumeRole on it.
developers may create roles, but never beyond a set limitA permissions boundary
It sets the most an identity-based policy can grant, and grants nothing itself.
no account in the organisation may use a particular serviceA service control policy
SCPs cap every user and role in member accounts, the root user included. They do not affect the management account.
one policy allows the action and another denies itDenied
An explicit deny in any policy overrides any allow.
the SCP allows S3, but the user still cannot read the bucketSCPs grant nothing
The user still needs an identity-based or resource-based policy that allows the read.
find the permissions a role has never usedIAM Access Analyzer, or last accessed information
Both show what is used, so you can remove the rest.
secure the account's root userMFA, no everyday use, no access keys
Use it only for the tasks that need it, and do those as rarely as possible.
A company runs an application on EC2 instances that writes objects to one S3 bucket. A security review finds an access key and secret key in the application's configuration file on every instance. The team wants no long-term credentials on the instances and the least operational effort. What should a solutions architect do?
A photo app on EC2 instances must write to one S3 bucket. The security team will not allow long-term access keys anywhere on the instances. What goes in the gap?
1 h by default, up to 12 h, set per role.Next: EC2Virtual machines you choose, size and run yourself: the most flexible compute on AWS, and the most work.
Open EC2Every fact on this page was checked against AWS’s own documentation on 15 Sept 2026. If AWS has changed something since, its page is the one to trust.