So now let's talk about AWS Organizations.
So it's a global service and it allows you
to manage multiple AWS accounts at the same time.
So you create an organization and the main account
in your organization is called the management account,
while the other accounts that join the organization
or that are created from the organizations
are called member accounts.
And member accounts can only be part of one organization.
The cool thing about organization is that the billing
is consolidated across all the accounts,
so you have a single payment method
on the management accounts
and then it will be paying for all the organization's cost.
But because you have an organization
and it's all part of one big family
then you get pricing benefits from aggregated usage.
So if you use a lot of EC2 or if you use a lot Amazon S3
across all your accounts, then you will get big discounts
because it will summarize and sum up
all the usage across all the accounts.
You can also share reserved instances
and savings plans discounts across accounts.
So if a reserved instance is unused in one accounts
another account can benefit from it
and therefore the discounts apply
across the entire organization
which is really good for cost savings.
Now there's also an API to automate the account creation
from within the organization.
So you can create accounts very easily
using an organization.
So how does that work?
So we have what's called a Root Organizational Unit or OU
and this is the outermost OU of your accounts.
And then within it sits the management accounts.
Then you can create sub OUs,
so you can create, for example an OU for the dev accounts
and then you can create member accounts within the dev OU
or you can create OU for a prod account
and also add member accounts there
but you can be as free as you want.
You can create within the prod OU an OU for your HR
member accounts and an OU for your finance member accounts.
So you can organize it the way you want.
So you have different examples for your business,
for your OU.
So you can organize by business units,
so you have, for example, the management accounts
and then the sales, retail, and finance OU,
and then different accounts within each OU,
or you can have an OU by environment.
So for example, one OU for prod, one OU for test,
one OU for dev, and within each OU some accounts,
or project based, so you can have an OU per project within,
and accounts within each project, so,
and you can mix and match,
you're really free to do whatever you want.
So what are the advantages of using organizations?
Well, thanks to having multiple accounts,
you can have better security versus having
one account with multiple VPC,
because accounts are more separated than VPCs.
You can also enforce tagging standards for billing purposes
and you can in one go enable CloudTrail
for all your accounts
and send all the logs into a central S3 account
or we can also send CloudWatch Logs
to central logging accounts.
And we can establish cross account roles
for admin purposes automatically,
so we can administer all the member accounts
from the management accounts.
So these are big advantages.
Also, there's a big security advantage,
we can define Service Control Policies or SCP
and it's an IAM policy applied to specific OUs or accounts
and this allows you to restrict what the users and roles,
all of them can do within the accounts.
The SCPs apply to everything but to the management accounts
which will forever have full admin power,
otherwise you could do a mistake
and never come back from it.
So the SCPs by default,
they don't allow anything just like IAM.
You need to have an explicit allow for things to work.
So let's go through an example to understand how that works.
So let's take, for example, this organization.
We have the Root OU and the Management Account
and then we have a Prod OU and we have an Account A in it
and then we have two sub OUs, the HR OU,
and the Finance OU with Account B and Account C.
And let's have a look at how SCPs will affect
the permissions of each accounts.
So at the Root OU, it is very common to attach
the full AWS access SCP
and therefore any accounts within the Root OU
will have full permissions on their accounts.
That means the management accounts, the account AIM prod,
the account B and account C, well can do anything they want.
And then we would apply more SCPs.
So that's one way of doing things, of course,
and I'm going show you the most common way.
So then let's apply a DenyAccessAthena SCP
on the Management Account, we apply a DenyRedshift SCP
on the OU in Prod and then more SCPs, and let's have a look
at what it does for each account's perspective, okay?
So for the Management Account,
even though we have applied the DenyAccessAthena SCP
to deny access to the Athena service,
the management accounts can still do anything
because no SCP applied to it.
So the management account has full admin power
over everything.
Okay, now what about account A?
So account A is in the Root OU,
so it can do a lot of things
and then it's also in the Prod OU and on the Prod OU
there is the DenyRedshift SCP
that has been attached to it and therefore the Account A
does not have access to Redshift
even though we have attached an SCP on top of the Account A
saying authorized Redshift, because if there is one deny
in your policy, an explicit deny,
then by default it's denied.
So account A, in this example can do anything
but access the Redshift service.
Now, if you look at Accounts B it's within the HR OU
which is within the Prod OU, so it inherits everything.
So Account B has full AWS access from the Root OU,
DenyRedshift SCP from the Prod OU
and DenyLambda SCP from the HR OU
and therefore it can do anything
but access Redshift and access Lambda.
And now, Account C is within the Finance OU
which is in the Prod OU, which is within the Root OU
and therefore it can do anything except access Redshift.
So we've seen a few examples of SCP
and hopefully this is clear to you.
So two strategies for SCP,
you have a block list or an allow list.
So a block list is saying, hey,
here are the services that I don't want you to use.
So usually we attach first an allow star
to allow all actions on all services
and then we attach a denied statement, for example,
to deny access to DynamoDB
or allow list is we don't allow elections, which only allow
for example, in this example, EC2 and CloudWatch.
And so only EC2 and CloudWatch are authorized
on your account where this SCP has been attached
and any other service is not usable
because it would need an explicit allow to be used.
So that's it for organizations,
I hope you liked it and I will see you in the next lecture.