Advanced Identity in AWS

1. From one account to many

At the basic level you manage access with IAM users, groups, roles and policies inside a single AWS account. As an organization grows — several teams, separate dev, test and production environments, many projects — that single account starts to hurt: the bill is one undifferentiated blob, blast radius is hard to contain, and a mistake in dev can reach production.

This chapter covers the identity tools that sit one level above plain IAM: grouping accounts into an organization (AWS Organizations), restricting permissions at the organization level (SCPs, Permission Boundaries), signing users in once across every account (IAM Identity Center), connecting to an existing Active Directory (AWS Directory Services), and standing up a compliant multi-account environment from a template (AWS Control Tower).

2. AWS Organizations

AWS Organizations is a global service for managing multiple AWS accounts together. The account you start from becomes the management account; every other account is a member account, and a member account can belong to only one organization at a time.

The immediate benefit is consolidated billing across all accounts with a single payment method. Because usage is aggregated, you get volume pricing benefits on services such as EC2 and S3, and reserved instance and Savings Plans discounts are shared across the accounts. An API is available so that account creation itself can be automated.

Organizational Units

Accounts hang off a Root Organizational Unit, and you nest OUs beneath it to match how you want to govern. Common layouts are:

• By business unit — a Sales OU, a Retail OU and a Finance OU, each holding that unit’s accounts.
• By environment lifecycle — a Prod OU, a Dev OU and a Test OU.
• By project — one OU per project, each with its own accounts.

Why multiple accounts

Compared with running one account with many VPCs, a multi-account organization gives you cleaner separation and better tooling:

• tagging standards that make billing meaningful;
• CloudTrail enabled on every account with logs delivered to one central S3 account;
• CloudWatch Logs shipped to a central logging account;
• cross-account roles for administration;
• and, for security, Service Control Policies.

3. Service Control Policies (SCP)

An SCP is an IAM policy applied to an OU or an account that restricts what the users and roles inside it are allowed to do. Two rules matter above all:

• SCPs do not apply to the management account, which keeps full administrative power.
• Like IAM, an SCP allows nothing by default. A permission must have an explicit allow from the root through every OU in the direct path down to the target account.

Working through the hierarchy

Consider a root OU carrying FullAWSAccess, with a Deny Athena policy attached to the management account that hangs off it, a Sandbox OU carrying FullAWSAccess plus Deny S3, and a Workloads OU carrying FullAWSAccess. Inside Sandbox, Account A additionally has Deny EC2; inside Workloads there is a Test OU with Allow EC2 holding Account D, and a Prod OU with FullAWSAccess holding accounts E and F.

Account	Effective result
Management account	Anything — SCPs do not apply, so even the Deny Athena attached to it changes nothing
Account A	Anything except S3 (explicit deny inherited from the Sandbox OU) and except EC2 (its own explicit deny)
Accounts B and C	Anything except S3 (explicit deny from the Sandbox OU)
Account D	Can access EC2
Prod OU, accounts E and F	Anything

Exam tip

SCPs come in two strategies: a blocklist (start from FullAWSAccess and deny specific services) and an allowlist (attach only the permissions you intend to grant). An explicit deny anywhere on the path always wins, and nothing is allowed by default — an SCP has to allow an action explicitly at every level on the way down.

4. Tag Policies

A Tag Policy standardises tags across the resources in an AWS Organization. You define the tag keys and the values allowed for them, which keeps tagging consistent, makes tagged resources auditable and keeps resource categorisation sane.

Tag policies pay off with AWS Cost Allocation Tags and with attribute-based access control. They prevent non-compliant tagging operations on the services and resources you specify — note that they have no effect on resources that carry no tags at all — and they can generate a report listing tagged and non-compliant resources. Use EventBridge to monitor for non-compliant tags.

5. IAM Conditions

Condition keys narrow an IAM policy statement to the circumstances you care about. Four keys come up repeatedly:

Condition key	What it restricts
aws:SourceIp	The client IP address from which the API calls are being made
aws:RequestedRegion	The region the API calls are made to
ec2:ResourceTag	Access based on the tags on a resource
aws:MultiFactorAuthPresent	Forces MFA on the calling session

IAM for S3

S3 permissions split by ARN level, and mixing them up is a classic mistake:

• s3:ListBucket applies to the bucket ARN, arn:aws:s3:::test — a bucket-level permission.
• s3:GetObject, s3:PutObject and s3:DeleteObject apply to the object ARN, arn:aws:s3:::test/* — object-level permissions.

6. Resource policies and aws:PrincipalOrgID

The condition key aws:PrincipalOrgID can be used in any resource policy to restrict access to principals that belong to a given AWS Organization. Put it on an S3 bucket policy and every member account of the organization can reach the bucket while a user outside the organization is refused, without you having to list account IDs one by one.

7. IAM Roles vs resource-based policies

For cross-account access you have two options: attach a resource-based policy to the resource (an S3 bucket policy, for example), or use a role as a proxy that the caller assumes.

The difference is what happens to the caller’s own permissions:

• When you assume a role — as a user, an application or a service — you give up your original permissions and take on the permissions assigned to the role.
• When you use a resource-based policy, the principal keeps its own permissions and simply gains access to that resource.

Real-world example

A user in account A needs to scan a DynamoDB table in account A and dump the result into an S3 bucket in account B. A resource-based policy on the bucket is the right answer: the user keeps DynamoDB access in account A while gaining write access to the bucket. Assuming a role in account B would strip away the DynamoDB permissions.

Resource-based policies are supported by Amazon S3 buckets, SNS topics, SQS queues and others.

EventBridge security

When an EventBridge rule runs, it needs permission on its target, and which mechanism applies depends on the target:

• Resource-based policy — Lambda, SNS, SQS, S3 buckets, API Gateway. The target itself allows EventBridge to invoke it.
• IAM role — EC2 Auto Scaling, Systems Manager Run Command, ECS tasks. The rule assumes a role that carries the permissions.

8. IAM Permission Boundaries

A permission boundary is an advanced feature: you point a managed policy at an IAM entity and that policy becomes the ceiling on the permissions the entity can ever end up with. Boundaries work on users and roles; groups are not supported.

Effective permissions are the intersection: what the IAM policy grants and what the boundary allows. If the IAM policy grants something the boundary does not allow, the result is no permission at all.

Permission boundaries can be combined with AWS Organizations SCPs. Typical use cases:

• delegating responsibilities to non-administrators inside their boundary, for example letting them create new IAM users;
• allowing developers to self-assign policies and manage their own permissions while guaranteeing they cannot escalate to administrator;
• restricting one specific user, rather than an entire account as an SCP would.

Exam tip

Reach for a permission boundary when the limit must apply to a single user or role, and for an SCP when it must apply to a whole account or OU. Neither one grants permissions; both only cap them.

Policy evaluation

The full evaluation logic — the order in which AWS weighs each kind of policy — lives in the IAM documentation rather than in this chapter. What has already been established here usually settles an exam question anyway: an explicit deny anywhere wins outright, an SCP has to allow the action at every level from the root down, and a permission boundary caps whatever the identity policy grants.

The matching exercise is to read a policy and answer three questions about it: can you perform sqs:CreateQueue, can you perform sqs:DeleteQueue, and can you perform ec2:DescribeInstances? Work through one of those by hand — action by action against every statement, deny first — before trusting a general rule.

9. AWS IAM Identity Center

AWS IAM Identity Center, the successor to AWS Single Sign-On, gives a user one login for:

• all the AWS accounts in an AWS Organization;
• business cloud applications such as Salesforce, Box and Microsoft 365;
• SAML 2.0-enabled applications;
• EC2 Windows instances.

Identities can come from the built-in identity store in IAM Identity Center, or from a third party: Active Directory, OneLogin, Okta and similar. The user signs in once through a browser interface and reaches whichever accounts and applications they have been assigned.

Permission sets

A permission set bundles one or more IAM policies together; you then assign that bundle to users and groups, and it is what decides the AWS access they get. In a typical layout, IAM Identity Center runs in the management account; a group named Developers containing Bob and Alice is assigned the ReadOnlyAccess permission set on the production accounts and a FullAccess permission set on the development accounts. Behind the scenes the permission set becomes an IAM role in each target account, which the user assumes.

Fine-grained permissions and assignments

• Multi-account permissions — manage access across the accounts in your AWS Organization using permission sets.
• Application assignments — SSO access to SAML 2.0 business applications (Salesforce, Box, Microsoft 365), configured by supplying the required URLs, certificates and metadata.
• Attribute-based access control (ABAC) — fine-grained permissions derived from user attributes held in the Identity Center identity store, such as cost center, title or locale. Define the permissions once, then change a user’s AWS access simply by changing their attributes.

10. Microsoft Active Directory and AWS Directory Services

Microsoft Active Directory comes with any Windows Server on which AD Domain Services is installed. What it holds is a database of objects: the user accounts, the computers, the printers, the file shares and the security groups of an organization. Managing security from that one place is the point — you create an account there and assign its permissions there. The objects are arranged into trees, and several trees together form a forest.

AWS offers three directory options:

Option	What it is	On-premises AD
AWS Managed Microsoft AD	Your own AD running in AWS, users managed locally, supports MFA	Can establish a trust connection with your on-premises AD
AD Connector	A directory gateway (proxy) that redirects authentication to your on-premises AD, supports MFA	Users stay managed on the on-premises AD
Simple AD	An AD-compatible managed directory on AWS	Cannot be joined with an on-premises AD

Identity Center with Active Directory

IAM Identity Center connects to a directory in one of two ways:

• AWS Managed Microsoft AD (Directory Service) — the integration works out of the box.
• A self-managed directory — either create a two-way trust relationship between your directory and an AWS Managed Microsoft AD, or create an AD Connector that proxies to it.

11. AWS Control Tower

AWS Control Tower takes the work out of standing up a multi-account AWS environment that is secure and compliant from the start, laying it out along AWS best practices. Underneath, the accounts themselves are created through AWS Organizations.

What you get out of it: the initial setup is automated down to a few clicks, ongoing policy management is automated through guardrails, policy violations are detected and remediated, and compliance is monitored on an interactive dashboard.

Guardrails

Guardrails provide ongoing governance for the accounts in a Control Tower environment, and come in two flavors:

• Preventive guardrails, implemented with SCPs — for example restricting which regions can be used across all accounts.
• Detective guardrails, implemented with AWS Config — for example identifying untagged resources.

Real-world example

A detective guardrail backed by AWS Config monitors member accounts for untagged resources. When Config marks a resource NON_COMPLIANT, the guardrail triggers SNS to notify an administrator and invokes a Lambda function that remediates the problem by adding the missing tags.

Exam tip

Remember the mapping: preventive means SCP (blocked before it happens), detective means Config (found after it happens) — which is the same “Config cannot deny” point made in the Monitoring & Audit chapter. Control Tower does not replace Organizations — it builds on top of it.

Quick recap

Item	What to remember for the exam
AWS Organizations	Global service; one management account plus member accounts; an account belongs to only one organization; consolidated billing, volume discounts, shared reserved instances and Savings Plans; account creation via API
Organizational Units	Root OU with nested OUs, typically by business unit, environment lifecycle or project
SCPs	Do not apply to the management account; deny by default, so an explicit allow is needed from the root through every OU on the path; explicit deny wins; blocklist or allowlist strategy
Tag Policies	Standardise tag keys and allowed values; support Cost Allocation Tags and ABAC; no effect on untagged resources; monitor non-compliance with EventBridge
IAM Conditions	aws:SourceIp, aws:RequestedRegion, ec2:ResourceTag, aws:MultiFactorAuthPresent
IAM for S3	s3:ListBucket is bucket level (arn:aws:s3:::test); GetObject, PutObject, DeleteObject are object level (arn:aws:s3:::test/*)
aws:PrincipalOrgID	Usable in any resource policy to limit access to members of an AWS Organization
Role vs resource-based policy	Assuming a role replaces your permissions; a resource-based policy lets you keep them — the cross-account DynamoDB-to-S3 scenario
EventBridge targets	Resource-based policy for Lambda, SNS, SQS, S3, API Gateway; IAM role for EC2 Auto Scaling, SSM Run Command, ECS tasks
Permission Boundaries	Users and roles only, never groups; a maximum, not a grant; effective permissions are the intersection with the IAM policy; prevents privilege escalation by developers
IAM Identity Center	One login for AWS accounts in an organization, business cloud apps, SAML 2.0 apps and EC2 Windows instances; built-in identity store or AD, OneLogin, Okta; permission sets, application assignments and ABAC
Directory Services	AWS Managed Microsoft AD (own AD in AWS, trust with on-premises, MFA); AD Connector (proxy, users stay on-premises, MFA); Simple AD (cannot join on-premises AD)
Control Tower	Sets up and governs a multi-account environment on top of Organizations; preventive guardrails use SCPs, detective guardrails use AWS Config