AWS Organizations

Management / Root account

An administrative root (root) is contained in the management account and is the starting point for organizing your AWS accounts. The root is the top-most container in your organization’s hierarchy. Under this root, you can create OUs to logically group your accounts and organize these OUs into a hierarchy that best matches your needs.

If you apply a management policy to the root, it applies to all OUs and accounts, including the management account for the organization.

If you apply an authorization policy (for example, a service control policy (SCP)), to the root, it applies to all OUs and member accounts in the organization. It does not apply to the management account in the organization.

The root account can delete OUs, accounts or the entire organization. This account can use AWS services although it's not recommended; when you set a root account up, its only purpose should be used to manage policies to keep its level of exposure down.

The Management account is not the same as the root user of each account. There can only be one per organization and it's usually created automatically when an org is created.

By default, anyone from a management account is able to access any child account with administrator permissions: this because when we create a child account, the OrganizationAccountAccessRole role is automatically created and set to trust the org's root account.

Organizational Units (OUs)

An organizational unit (OU) is a group of AWS accounts within an organization. An OU can also contain other OUs enabling you to create a hierarchy. For example, you can group all accounts that belong to the same department into a departmental OU. Similarly, you can group all accounts running security services into a security OU.

OUs are useful when you need to apply the same controls to a subset of accounts in your organization. Nesting OUs enables smaller units of management. For example, you can create OUs for each workload, then create two nested OUs in each workload OU to divide production workloads from pre-production. These OUs inherit the policies from the parent OU in addition to any controls assigned directly to the team-level OU.

Including the root and AWS accounts created in the lowest OUs, your hierarchy can be five levels deep.

AWS Accounts

An AWS account is a container for your AWS resources. You create and manage your AWS resources in an AWS account, and the AWS account provides administrative capabilities for access and billing.

Using multiple AWS accounts is a best practice for scaling your environment, as it provides a billing boundary for costs, isolates resources for security, gives flexibility or individuals and teams, in addition to being adaptable for new processes.

Service Control Policies (SCPs)

SCPs specify the services and actions that users and roles can use in the accounts affected by the policy by limiting a user's permission over an entity as SCP define a permission guardrail, or sets limits. They don't affect users or roles in the management account, they affect only the member accounts in your organization.

• SCPs affect only IAM users and roles that are managed by accounts that are part of the organization. SCPs don't affect resource-based policies directly. They also don't affect users or roles from accounts outside the organization. For example, consider an Amazon S3 bucket that's owned by account A in an organization. The bucket policy (a resource-based policy) grants access to users from account B outside the organization. Account A has an SCP attached. That SCP doesn't apply to those outside users in account B. The SCP applies only to users that are managed by account A in the organization.

• An SCP restricts permissions for IAM users and roles in member accounts, including the member account's root user. Any account has only those permissions permitted by every parent above it. If a permission is blocked at any level above the account, either implicitly (by not being included in an Allow policy statement) or explicitly (by being included in a Deny policy statement), a user or role in the affected account can't use that permission, even if the account administrator attaches the AdministratorAccess IAM policy with / permissions to the user.

• SCPs affect only member accounts in the organization. They have no effect on users or roles in the management account.

• Users and roles must still be granted permissions with appropriate IAM permission policies. A user without any IAM permission policies has no access, even if the applicable SCPs allow all services and all actions.

• If a user or role has an IAM permission policy that grants access to an action that is also allowed by the applicable SCPs, the user or role can perform that action.

• If a user or role has an IAM permission policy that grants access to an action that is either not allowed or explicitly denied by the applicable SCPs, the user or role can't perform that action.

• SCPs affect all users and roles in attached accounts, including the root user. The only exceptions are those described in Tasks and entities not restricted by SCPs.

• SCPs do not affect any service-linked role. Service-linked roles enable other AWS services to integrate with AWS Organizations and can't be restricted by SCPs.

• When you disable the SCP policy type in a root, all SCPs are automatically detached from all AWS Organizations entities in that root. AWS Organizations entities include organizational units, organizations, and accounts. If you reenable SCPs in a root, that root reverts to only the default FullAWSAccess policy automatically attached to all entities in the root. Any attachments of SCPs to AWS Organizations entities from before SCPs were disabled are lost and aren't automatically recoverable, although you can manually reattach them.

• If both a permissions boundary (an advanced IAM feature) and an SCP are present, then the boundary, the SCP, and the identity-based policy must all allow the action.

Some examples are the following: This is the default policy that gets created in an OU, it cannot be deleted and allows any user to perform any action on any resource

{
	"Version": "2024-01-01",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": "*",
			"Resource": "*"
		}
	]
}

The following is a policy that doesn't allow users from leaving an organization

{
	"Version": "2024-01-01",
	"Statement": [
		{
			"Effect": "Deny",
			"Action": [
				"organizations:LeaveOrganization"
			],
			"Resource": "*"
		}
	]
}

Amazon Resource Names (ARNs)

ARNs are unique names given to resources inside an organization and they follow the "ARN Formats": ARNs are delimited by colons, and composed of segments, which are the parts separated by colons (:). The specific components and values used in the segments of an ARN depend on which AWS service the ARN is for.

So a ARN such as

arn:partition:service:region:account-id:resource-type/resource-id

contains the following segments:

• partition: the partition the resource is in. For standard AWS regions the partition is aws, for other kinds of partitions the naming convention will be aws-something

• service: the service namespace that identifies the AWS product

  • quicksight

  • s3

  • iam

  • ...

• region: the AWS region the resource resides in - some resources don't require the region to be specified in their ARN

• account-id: the ID of the AWS account that owns the resource - some resource don't require the account ID to be specified in their ARN: QuickSight ARNs require an AWS account number but that doesn't apply to services like S3

• resource / resource_type: this segment varies based on the service. A resource identifier can be the name, ID or path of the resource

You can use wildcard characters (* and ?) within any ARN segment. An asterisk (*) represents any combination of zero or more characters, and a question mark (?) represents any single character. You can use multiple * or ? characters in each segment.

If you are using the ARN for permissions, avoid using * wildcards if possible, to limit access to only the required elements.