IAM and the shared-responsibility model

By the end of this lesson you will know exactly where the security boundary falls for each service type, how to read and write an IAM policy that doesn’t hand attackers your account, and why a single explicit Deny beats every Allow in the stack.

The shared-responsibility model: where AWS stops and you start

AWS frames it in four words: AWS handles security of the cloud; you handle security in the cloud. AWS owns the hardware, the global infrastructure (regions, availability zones, the physical network), the hypervisor, and the internals of every managed service. You own your data, who can touch it, and how it is configured. The leaked-invoice bucket sat in an S3 service AWS keeps patched and durable — but the bucket policy, the IAM permissions, and the exposed key were all yours.

The critical nuance is that the line moves by service type. The more managed the service, the more AWS absorbs:

• EC2 (a raw virtual machine): AWS gives you patched hardware and a hypervisor. You patch the guest OS, configure the firewall (security groups), manage the application, and encrypt the disks. This is the most responsibility you can hold.
• Containers on ECS/Fargate: AWS additionally manages the host OS and the container runtime; you still own the image contents, IAM task roles, and app code.
• Lambda: AWS manages the OS, the runtime, and the scaling. You own only your function code, its IAM execution role, and its dependencies.
• S3 / DynamoDB (fully managed): AWS runs the entire service. Your remaining job is access control, encryption choices, and the data itself.

One responsibility never shifts no matter the service: identity and access management is always yours. That is the half this lesson is about.

IAM identities and policies: the vocabulary

Why does this vocabulary matter in practice? Because every misconfigured access control — from the leaked invoice bucket to a privilege-escalation exploit — is either a wrong identity shape or a policy that’s too broad. Getting the vocabulary right means you stop making those mistakes by default.

IAM (Identity and Access Management) is the global service that decides who can do what. It has two halves: identities (the who) and policies (the what).

Identities come in three shapes:

• Users — a long-lived identity for a human or a legacy system, optionally with a password and/or access keys.
• Groups — a bucket of users that share policies; you attach a policy to the group, and every member inherits it. Groups are an organisational convenience, not an identity that can be assumed.
• Roles — an identity with no permanent credentials. A principal (an EC2 instance, a Lambda function, a user from another account) assumes the role and receives short-lived, automatically-rotated credentials from STS. Roles are the senior default — more on why below.

Permissions are expressed as policies: JSON documents made of statements, each with up to four core keys.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::invoices-prod/uploads/*",
      "Condition": { "StringEquals": { "aws:RequestedRegion": "eu-central-1" } }
    }
  ]
}

• Effect — Allow or Deny.
• Action — the API operations, e.g. s3:GetObject. Wildcards are legal (s3:*) and dangerous.
• Resource — the ARNs this applies to. * means “every resource”, which is almost always too broad.
• Condition — optional guards (region, source IP, MFA present, tag match) that must hold for the statement to apply.

The policy above grants exactly two actions, on exactly one bucket prefix, in exactly one region. Contrast the policy that leaked the invoices:

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

"Action": "*" on "Resource": "*" is administrator access to the entire account. Attached to a CI user whose key escaped, it is the difference between “an attacker can read one upload prefix” and “an attacker owns your account”. Granting only what a principal needs, and nothing more, is the principle of least privilege — the single most load-bearing idea in IAM.

IAM also imposes hard quotas that shape how you structure access, and senior engineers design against them: a single managed policy document is capped at 6,144 characters, you can attach at most 10 managed policies to one role/user/group, and an account is limited to roughly 5,000 roles and 300 customer-managed policies by default (some are soft limits you can raise). These ceilings are why teams converge on a few reusable, well-scoped managed policies plus permissions boundaries, rather than hand-writing a bespoke inline policy per principal — that approach hits the character cap and the attachment limit fast, and becomes unauditable long before it does.

How a request is decided: deny wins

When a principal makes a request, AWS gathers every policy that applies — identity-based policies on the user/role, resource-based policies on the target, plus boundaries and SCPs if present — and evaluates them with one rule you must hold in your head:

1. Default is deny. A request with no matching Allow is rejected. This is the implicit deny.
2. An explicit Allow overrides the implicit deny — if some applicable policy allows the action and nothing denies it, the request proceeds.
3. An explicit Deny overrides everything. If any applicable policy denies the action, the request is rejected, no matter how many allows exist.

So the precedence is: explicit deny > explicit allow > implicit (default) deny. A Deny is a guarantee; an Allow is only effective in the absence of a Deny. This is why guardrails are written as denies — an SCP that denies disabling CloudTrail cannot be undone by any allow an account admin grants.

Senior practice: roles over keys, root locked down

The mechanism above is only as safe as the credentials feeding it. AWS’s identity best practices are unambiguous, and they are exam-relevant:

• Prefer roles over long-lived access keys. A role hands out short-lived credentials that auto-expire and rotate; a leaked role session dies quickly, a leaked access key works until someone notices. Give EC2 an instance profile (a role for the instance) and Lambda an execution role instead of embedding keys. For access across accounts, have the other account assume a role — never copy keys between accounts.
• Never embed credentials in code or images. No access keys in source, in a container layer, or in environment variables checked into git. Use the role attached to the compute, or fetch secrets from Secrets Manager / SSM Parameter Store at runtime.
• Lock the root user away. The account root can do anything and cannot be restricted by IAM policies. Enable MFA on it, delete its access keys entirely, and use it only for the handful of tasks that genuinely require root. Day-to-day work happens through IAM roles/users with least privilege.
• Least privilege, then tighten. Start from the minimum, grant specific actions on specific resources, add Condition guards (require MFA, restrict region/IP), and use IAM Access Analyzer to find permissions nobody actually uses.

Together, these four practices collapse the blast radius of any single failure: a short-lived role credential limits the attacker’s window, least-privilege scoping limits what they can reach, no embedded keys removes the easiest exfiltration target, and a locked root prevents total account takeover. Skip any one of them and the remaining three are weaker — the chain is only as strong as its weakest link.

The real tension here is least privilege vs operational friction, and it has a failure mode at each extreme. Over-tighten and engineers hit AccessDenied mid-incident, can’t ship, and the pressure-valve response is the disaster: someone attaches AdministratorAccess “just to unblock the deploy” and never removes it — the most common way least-privilege accounts quietly drift to over-privileged. Under-tighten and you recreate the leaked-invoice blast radius. The senior resolution is not to pick a side but to make tightening cheap: derive policies from real usage (Access Analyzer generates a least-privilege policy from CloudTrail history), grant temporary elevated access through short-lived assumed roles rather than permanent grants, and treat a wildcard policy as a code-review red flag, not a convenience.