Securing Access to AWS Resources

AWS security starts with a simple rule: give every identity only the permissions it needs to do its job, and no more. This is the principle of least privilege, and in AWS it is enforced through AWS Identity and Access Management (IAM). An IAM user is a long-term identity for a person or application. An IAM group is a named collection of users that share the same permissions. An IAM role is an identity with no long-term credentials of its own — instead, a trusted identity assumes the role and receives temporary credentials.

Permissions are attached through policies: JSON documents that list which actions are allowed or denied on which resources. A policy can be attached to a user, a group, or a role, and one identity can have several policies attached at once.

Security in AWS is a shared job. Under the AWS shared responsibility model, AWS secures the infrastructure of the cloud — the hardware, the data centers, the host operating system — while you are responsible for security in the cloud: how you configure IAM, encrypt your data, and control network access. Nothing in this module removes that second half of the job from you.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::data-team-reports",
        "arn:aws:s3:::data-team-reports/*"
      ]
    }
  ]
}

When AWS decides whether to allow a request, it starts from implicit deny: nothing is allowed unless a policy says so. If any applicable policy contains an explicit Deny for that action, AWS denies the request no matter how many other policies allow it — an explicit deny always wins. This is why a permissions boundary or a service control policy (SCP) can only take permissions away, never grant them: they set the maximum an identity can do, and the identity's own policies still have to grant the action inside that ceiling.

Sharing access across AWS accounts works the same way, through a role rather than a shared password. The account that owns the resource creates a role with a trust policy naming which accounts (or which specific roles) are allowed to assume it. A user in the trusted account calls AWS Security Token Service (sts:AssumeRole) and receives temporary credentials scoped to that role's permissions — never the user's own permissions, and never a long-lived secret to leak.

For a whole organization's workforce, repeating this per account does not scale. AWS IAM Identity Center centralizes that: your engineers sign in once, and Identity Center hands out temporary, role-based access to every AWS account they are permitted to reach, based on group membership in your existing directory.