Okay. So we're going to practice
using the organizations.
For this I'm just going to go into the organization service
and get started.
So as we can see in this example
Organizations is a global service
because it has to do with accounts
and regrouping them together, okay?
The other thing I did is that I created
my own new account for this.
So I created AWS course master account
and on the other window I have AWS course child account
because I don't wanna use my main accounts for this
and I wanted to do a demo with two separate accounts.
So if you wanna follow along
I would suggest creating two new accounts.
Call them as you want so that you can have one master
and one child account within your organization.
So from the master account
I'm going to go ahead and create an organization.
Now within the organization
we have to define the accounts within it.
So as we can see right now,
this is very quick, the organization is created
and we have the root organizational units.
And within it, we have the AWS course master account
which is the master account
or also called the management account, okay?
So we're going to do that.
And the organization is created.
Now we want to add a second
AWS as account into this organization.
And to do so I'm going to add an account.
And we have two options,
either we want to create an account
and you specify the account name,
the email address of the account owner
as well as an IAM role that will be created
in the target account
to be allowed to be managed by the organization.
Or you can invite an existing AWS account,
in which case you need to provide the email address
associated with that account
or the account ID of the account to invite.
And for this, I will just do the name of my account.
So I would just add the email which is
aws-child-account@stephanemaarek.com.
And this is good to go.
We can include the message if you wanted to
and add some tags but I will just go ahead
and send my invitation.
So now my invitation has been sent to my other account
and we can view all pending invitations through this UI
and it hasn't expired yet,
so if in two weeks
it doesn't get accepted, then this will expire.
So what I can do next is go
to my organization on my child account.
And on the left hand side, there is Invitations.
So I click on Invitations.
I'm going to refresh this page.
And now we see my invitation from the master account.
So as we can see in this organization right now
we'll get full control as this organization
has full features enabled
and can assume full control of your account.
So as soon as you're part of an organization,
you accept to be controlled
by whoever is the master of that organization.
So we'll accept the invitation.
And here we go.
Now my account, the child account is enrolled into
my AWS organization and we can only see the organization ID
as well as the feature set.
And an account may have
the ability to leave the organization.
So back into my AWS organization.
Now, if I go to my accounts, I click on AWS accounts.
As we can see now within my organization
we have roots and within roots, we have two accounts now,
the master and the child accounts.
So we can do is now organize our accounts
using organizational units or OUs.
So for this, we'll just do action
and we can create a new OU.
So to do so we'll go on the roots, okay?
And action creates new OU and I can have one,
for example, for my Dev accounts.
And I create the OU.
I can also go again in here and create the OU,
And this time I will say tests and maybe less time
we'll have a product, so I'll just do a prod OU.
And maybe within the prod OU we have different departments.
So I can again create OUs within OUs.
So I can have HR, if we have an HR department
that has production applications,
or maybe we have a finance department
that has analytics applications within it.
So as you can see here
you can create as many nested OUs as you want.
And if you go all the way to your organization
and then you look at the OU,
now we can see we have roots, dev,
and right now, no accounts within dev,
prod and we have finance and HR within prod
and then we have test.
So as we can see, we can start organizing the accounts
and we have many accounts in organization
within specific OUs.
And the reason we do so is to have service control policies.
So what we're going to do is first take our child account
and we want to move it in to,
for example, the finance department within prod.
So I take this account and I can say move
and then I can have it into my finance department
within my prod OU.
So I move the account there.
And now if we have a look we can see
that the finance department contains the course child.
It's best practice as well to leave the management account
under the root OU but you could move it if you wanted to.
Okay. So now we want to enable service control policies
to restrict what my course child account can do.
So to do so we go into Policies and as we can see
we have four different kinds of policies available
to us right now, and they're currently disabled.
So what we can do is take the important policy types
that we want and enable them.
So one we definitely want to enable is the
service control policy, because this will allow you to
restrict what our children account can do.
So this is enabled and I go back to Policies.
We have other ones that could be of interest,
for example, backup policy allows you to
deploy organization-wide backup plans, to ensure
that all your accounts are compliant
and have backups enabled
or tag policies also to help standardize how you use tags
within all the different accounts in your organization.
But for the sake of this hands-on
and from an exam perspective
I believe only service control policies will be used,
but still good to know
that you can apply a backup policy across all the accounts
and a tag policy across all the accounts as well.
Okay. So service control policies are enabled.
And so now what we'd like to do
is to have service control policy defined.
So I'm going to click on service control policy
and this is the documentation, excuse me.
And here we have one service control policy
that has been created so far, which is the full AWS access.
Okay? And the full AWS access allows all the
accounts to access all the services.
But we can create a new policy and attach it.
So we can created a policy called oops-
We can create a policy called DenyAccess to S3
and this will deny access to the S3 service
to whichever OU or account this is attached to.
So in terms of the policy, we could find a statement.
For example, we can find the S3 service in here
and within S3, we can say all actions
and the resource is going to be star as well.
So I'm going to have a star in here.
So we're denied anything on this (murmurs),
a very simple policy
and I'll call it deny S3 as an Sid.
And then I will click on Create policy.
So this, when attached to my accounts,
should deny access to S3.
So we can have a look.
So let's go into our accounts.
Okay. So if we look at the root to you and click on root,
as we can see, there is enabled policy types
which is service control policies.
And if I click on Policies
there is one applied policies that is attached directly
to the root OU, which is the full access to AWS,
which allows everything on root
and all its children to access all the services within AWS.
So if you look at the children
of the root OU, we have, for example, the prod OU.
And if we look at the prod OU, in terms of policies
there are two policies, one that is attached directly
which is the full AWS access,
but also one that is inherited from root,
which is the full AWS access.
So it has duplicated this one for some reason.
And then if I go into children in a go into finance
and click on policies, we have three attached policies.
So one inherited from prod, one inherited from root
and one attached directly.
And this is probably because I've enabled
service control policies after creating the OUs.
So this full AWS access was attached
to every single element within my account.
And if we look at the children of the course
of the finance OU within the prod OU,
and you click on the course itself, the account itself
and go to policies, now we have four.
So we have full AWS access four times.
So you understand at least the concept of inheritance,
which makes sense.
And you can just inherit things from Root that are clear.
You inherit things from the topmost layer,
but what we can do is if we go back one up.
So if we go to my prod and finance OU, for example,
we can attach a new policy.
So I'm going to attach a new policy
and this one will be the DenyAccessS3.
I will attach it
and now that means that anything within my finance OU
should also have this inherited.
So if I click on my course child and then policies,
as we can see the DenyAccessS3 has been inherited
from finance.
So how do we make sure that this is working?
Well, if I go to my account
now my child account, and open the S3 console in a new tab.
We are in S3 and the buckets are being loaded
but as we can see, we don't have permission
to list buckets and therefore we can not use Amazon S3.
And this was due to the policy we have attached to the OU.
So it's quite powerful because we are able to
restrict what an account can do overall,
even though I am logged in right now
with my root user, okay, with my root user of my account,
I still don't have the access to Amazon S3.
So this is very powerful and this is how STPs work.
And hopefully that makes sense for you.
So that's it for this hands-on.
I hope you liked it.
And I will see you in the next lecture.