Okay, so let’s talk about AWS Organizations which is a way for you to manage multiple accounts at once.
So within Organizations, we have at the top, the root organizational units or OU, and it will contain our management account which is the account that will be used for all administration purposes.
Then within the root OU, you could have different OUs. You can have an OU for your development environment and this way can have multiple member accounts. So you have to make a distinction between the management account that used to manage all the other accounts and Organizations and then the member accounts, which are just normal and accounts that are part of an organization.
So we can have an OU for Dev, we can have an OU for Prod as well, with other member accounts and we can have OU within OU. So it’s very possible to have an HROU within the Prod OU which is by the way, within the root OU, so can HR or finance, and so on.
OrganizationAccountAccessRole
So once we have all these accounts, how does Organizations perform its administration? Well, there is a very special role we need to know about for the exam called the Organization Account Access Role.
So when we have the organization and the management accounts, if we happen to create a member account using an API from the organization service then automatically an IAM role within the member account is going to be created. And that IAM role is called the Organization Account Access Role.
Now, the management accounts, when it needs to perform administrative duties onto the member account, we’ll assume that administrative role using the API.
So this IAM role grants full administrative permissions in the member accounts to the management account. And this is the magic of how AWS Organizations work.
Now, this role is going to be used by the management account to perform admin tasks in the member account, for example, creating IAM users. This role can also be assumed by IAM users in the management accounts if they’re authorized to do so. And as I said, this role is automatically added to new member accounts created with the API of analytics Organizations.
But in case you are inviting an account into an Organization and that account already exists from out there, then you must manually create this role otherwise things will not work.
Multi Account Strategies
Now, we have an OU and multiple accounts. So we have multiple account strategy, and you can create accounts per department, per cost center, per visible dev test prod. You can create them based on the regulatory restrictions. You can get them for better resource isolation.
For example, you won’t have one account per VPC or you want to have separate per account service limits or you want to have a separate account for logging and so on. So you have, you know, different strategies to look at.
For example, you want multi accounts or one account with a multi VPC in it. And then of course you’re going to have multiple accounts.
So you need to have tagging standards for billing purposes as we’ll see this. And then some things we may want to do is to enable CloudTrail on all accounts and then send all the logs of CloudTrail into a central account that will have an Amazon industry buckets or also maybe aggregate all the CloudWatch logs within all accounts into a central logging accounts, or maybe create a central accounts for security. So these are just strategies.
Organizational Units (OU) — Examples
There’s really no guideline, it’s up to you and your architecture to decide what you want to do. So you have a business unit type of OU.
So you have management accounts then a OU per business unit and then maybe multiple accounts within each business unit. You can also get, for example, management accounts and then dev, test, prod types of OUs. And then you can also get project based type of OUs. It’s really up to you to decide but this just gives you a few ideas.
Feature Modes
So there are two feature modes you need to know for AWS Organization.
The first one is a consolidated billing feature. So this is going to aggregate billing across all accounts and give you a single payment method directly from the management accounts. And the reason you do so is that you’re going to get pricing benefits from the aggregated usage. You’re going to get volume discounts for EC2, for Amazon S3 and so on, because you are using more across all accounts.
All the features are also going to be another feature mode for Organizations. So this of course includes the consolidated billing feature, but on top of it, it adds the SCP feature that we’ll see in the next lecture.
And in case you invite in accounts, it needs to approve enabling all features to be part of that mode. And then once you have the all features enabled, then we can use an SCP, so, service control policy to prevent the member accounts from ever leaving the organization. And this is why the accounts that have been invited into an organization with all features must approve these features beforehand.
And once you have enabled all features, you cannot go back to using Organizations, only to consolidate billing.
Reserved Instances
Okay, so talking about what is shared and savings, we have Reserved Instances in Organizations. So for billing purposes, the consolidated billing feature of AWS Organizations will treat all the accounts as one account that we know. That means that all the accounts in the organization will receive the hourly cost benefit of a Reserved Instance that is purchased by any other account. So that means that it will give you the maximum amount of saving, even if a specific account is not using that Reserve Instance, but another is.
So the payer account of an organization, so the management account, can turn off the RI Reserved Instance sharing or savings plan discount sharing for any accounts including the payer accounts. So it’s possible for you to disable it and say, well this RI or this savings plan only belongs to that specific account.
That means that in that case then, the Reserved Instances and savings plan discounts will not be shared across accounts that have this turned off.
And then, on the opposite side, for a Reserved Instance or a savings plan to be shared across two accounts, then both these accounts must have sharing turned on.
Moving Accounts
You need to also know the process to move accounts between Organizations.
So if we have one AWS Organization and another one and we want to migrate a member account from one to the other, the first step is to remove the member account from the AWS Organization so that it’s standalone, then we can send an invite to the member account from the new AWS Organization.
And finally, we can accept the invite from the member account so that the member account joins the organization.
Service Control Policies (SCP)
So now let’s have a look at policies on AWS Organizations.
So we have the service control policies, or SCP, and they help us define allowlist or blocklist of specific IAM actions. They’re applied either at the OU or the account level and they do not apply to the management accounts.
The SCP is directly applied to all the users and roles within the account, including the root user but the SCP does not affect any service-linked roles. Service-linked roles enable other services, integrate with Organizations and therefore, they cannot be restricted by SCPs.
SCPs must have an explicit allow. So by default, they don’t allow anything. And the use cases for SCP is to restrict access to certain services only.
For example, a user cannot use EMR or enforce PCI compliance by explicitly disabling some services.
SCP Hierarchy
So let’s have a look at this hierarchy.
So we have our root OU management accounts, OU prod, account A, OU HR, OU finance with account B and C. And we have different SCPs apply at different levels. So when the arrow is pointing to an OU, that means that it’s applied to OU. Else, when it’s applied to an account it’s directly applied to an account.
So from top two bottom, if we look at the management accounts, the management account can do anything because no SCP applies. So even though there was a DenyAccessAthena SCP on management accounts, it does not apply because the management accounts keeps full administrative power.
Now, for account A, what happens? Well, let’s have a look. So account A can do anything because it inherits the top level SCP so the full AWS access SCP but then it will see and inherit any other SCP. So we will have a DenyRedshift SCP that’s applied on the OU prod, okay?
And even though we have attached an authorized Redshift SCP to the account A directly, because we have an explicit deny from the OU prod that’s been inherited, then the account A cannot access Redshift.
Now, account B in the HR OU, again, it inherits from the step two steps.
So it inherits stuff from root OU, prod OU and HR OU. So it’ll inherit a DenyRedshift SCP and also inherit a DenyAWSLambda SCP and therefore, it cannot access Lambda or Redshift. And account C, we can do anything except accessing Redshift because it is inheriting this from the OU in prod.
SCP Examples Blocklist and Allowlist strategies
So here’s an example where we allow everything but we block explicitly DynamoDB. And on the other side, on the right-hand side, we allow only EC2 and CloudWatch.
