Amazon AWS Certified SysOps Administrator Associate – AWS Account Management Part 2

4. [SAA] Organizations Overview

So let’s get into the multi account realm with AWS Organizations. So, AWS Organizations is a global service and it is allowing you to manage multiple AWS accounts in your organization. The main account is going to be called the Master account and you cannot change it. And the other accounts within your organizations are member accounts. The member accounts can only be part of one organization, although they can be moved from one organization to another. It’s called a migration, and we’ll see how to do this in this theory lecture as well. So the benefits of organizations is that you get consolidated billing across all the accounts and with a single payment method. So you can have as many accounts as you want and they will all be billing under the Master accounts and the pricing benefits you get from aggregated usage.

For example, if you have a volume discount for EC two or Amazon S three, you get it at the organization level. So it’s really great to federate all these accounts into one organization to pay less and simplify your billing methods. And there’s a really cool API that allows you to automate the AWS account creation. So you can create a list discounts on demand using an API through Organization and make sure that the billing of that account will be rolled back into the bigger accounts. So what would we have multiple accounts? In AWS, you have multiple strategies for it. For example, you may want to create one account per department or percuss center or per environment, for example, for dev tests and prod, or based on regulatory restrictions, for example, or for better resource isolation. So you want to make sure that you don’t have resources that can talk to each other within the same VPC.

So you create two accounts and you don’t pair them together, and so the resources are virtually isolated. There’s also good, you have per account services limits and also isolated accounts for lugging. So there’s multiple strategies for multiple accounts and it depends really on the wish of the main architects in your organization. Now, there is a difference between having multiple accounts or one account with multiple VPC in it. Okay? The thing is, if you have multiple accounts, you know they’re really well separated and you have different user accounts and so on. Whereas if you have one giant account with multiple VPC, there is a chance that your resources may talk to one another, there’s a chance that the users also get access to multiple VPCs and so on. So it’s really up to you to choose what you want to have and how you want to run your organization. It can have also tagging standards for billing purposes and you can enable cloud trail on all accounts to send the logs to Central, for example, Amazon Sri accounts, and also have cloud watch logs sent to a central logging account. So many, many different strategies for your cross accounts.

And if you wanted to administer all the accounts. Then you can establish cross account roles for admin purposes, where the master accounts can assume an admin role into any of the children accounts. Okay, so how do we organize all these accounts? We organize them using organizational units or Ou. So you can organize them by business units. For example, in this example we have the master account, and then we have the sales ou, the retail ou, and the finance ou, and under each Ou we have different accounts. So the sales account, one two, retail account one two, and so on.

Or you can have it by environment. For example, you have the master account, and then you’re going to have production, development Ou and test Ou. And within each ou, again multiple accounts. Or you can be project based, project one, project two, project three, and multiple accounts. Again, this could be completely different. You can mix and match. It’s really up to you to design the type of Ou you want, but it gives you some ideas around how Ous are being used. So for your organization, let’s have a look at all the possibilities.

You have the roots Ou, we have the root account, that’s the master account, and then you can have Ous within it. For example, a development Ou with two accounts in it, a prod Ou with two accounts in it, and another ou deep within the prod, which is the finance ou with another two accounts in it, and another Ou within prod, again, which is the Hrou with two accounts in it. So we see the kind of structure we can create with organizations, and you can go really crazy. You can assign accounts to whatever ou you want, and they will inherit some rules and some SCP. I will see in the next lecture, in the next slide of security.

So hopefully you can visualize now what an Ou is, because we’re getting into the security of these Ou. There is something called a service control policy or SCP. It allows you to whitelist or blacklist im actions applied at the Ou or account level, but it doesn’t apply to the master account. The SCPs have no effects on the master account. So the SCP will see an example very shortly. They can be applied to only the users and the roles of the account, including a route. So if you apply an SCP onto your account within an Ou, and you say you cannot use EC Two, even an admin within that account cannot use EC Two.

But the SCP does not apply to service linked roles. So this is the service roles that other services use to integrate with organizations. Okay, SCP must have an explicit allow to allow things, so by default it does not allow anything. And so use cases for SCP, and this is what the exam will test you on, would be to restrict access to certain services. For example, you’re saying, okay, in my production accounts, you cannot use EMR or to enforce PCI compliance by explicitly disabling services that are not compliant with PCI yet in AWS. So I’ll try to make this a little bit clearer. Let’s have a look at our ou. So we have the route Ou with a root account A, production Ou with an account A in it, and with an Hreu with account B and a finance Ou with account C. So let’s assume that you usually do this on the route Ou. You add an SCP called Full AWS Access, which tells that every service in every action can be done, basically allowing you to use your account. But let’s apply a deny access Athena SCP onto the master account. Now, what can the master account do or cannot do? Well, the master account can do anything because it inherited the full aus access SCP from the root Ou. And even though we have attached a deny access Athena SCP to the master account because it is the master account of your root Ou, no SCP apply.

And therefore this SCP we’ve applied to the master account is completely not taken into account. So, to summarize, we’ve inherited stuff from the root Ou, and the SCP applied to the master account. To deny anything does not apply. Now let’s go on. We have a deny redshift SAP that is applied to the prod Ou, and an authorized redshift SCP applied to the account A. So now about account A, it can do anything because you have full access SAP, but it cannot access redshift because there is a deny redshift SCP applied to the prod Ou. And even though I have attached an authorized redshift SAP to my account A, because we have an explicit deny on redshift at the Ou level, the deny is going to take precedence over the authorize.

So even though I have this authorized redshift SCP on account A, actually that authorize is useless because we already have a deny at the Ou level. So it’s interesting for you to know that this is a full tree. And so account A is going to inherit the SCP at its level, at the Ou level, and even the roots of the Ou. So it goes like a tree. And so if one of these says deny, then it’s going to be a deny. Now let’s look at Hru. It has a deny aeros lambda SCP. And so what about account B? Well, it can do anything because of the full access, but it cannot access redshift because it’s within the prod Ou, it’s the bigger Ou, and also it cannot access AWS lambda because it’s within the Hrou. So account C, though in finance ou, is not affected by this deny AWS lambda SCP because it’s only applied to the Hru, but not the finance Ou. And therefore account C has the exact same permission as account A, which is to do anything but access redshift. Hopefully that makes sense if you understand this.

You basically understood SCP and their power. So let’s take an example of what it looks like. An SCP looks just like Aim policy. So this is allow all actions. So we allow Star on star. So do you say you can do anything but deny DynamoDB? And we’re saying the effect is deny on DynamoDB Star for any resource. Another strategy would be to whitelist only a certain type of services. So we’re saying allow EC Two star and CloudWatch star on resource Star. But any other services but EC two and Cloud Watch cannot be usable if you don’t know exactly what this means.

You want more examples? There’s a link right here that takes you to the documentation and shows you different Ous SCPs you can have. Okay, finally, before we get into the hands on, how about moving accounts? So say we have orga and B, and we want to move an account from Orga to B. To migrate accounts, you need to know the process. The first thing is to remove the member accounts from the old organization. Then you send an invite to the new organization to include that account. And then you accept the invite for the new organization so that the member accounts can join it. So, as you can see in migrate diagram Hup, that’s how the account went in.

So it left the first one, and then it got an invite from the second one, and it was migrated. And if you want to migrate the master account, so you want to migrate the roots account of your organization, then you need to migrate every single account within it. And then when you’re done, you delete the organization and you migrate the account that is standalone back into orgB. So that makes sense. It’s just step that looked natural, but it’s once you set it, you know it’s possible. And you will be able to answer an exam question based on this. All right, so that’s it. We’ll try to make I will try to make a to its organization much clearer in the next lecture for the hands on, but you get a good overview of what it is. I hope you like this lecture, and I will see you in the next lecture.

5. [CCP/SAA] Organizations Hands-On

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 an ALS course master account and on the other window have a list course child account because I don’t want to use my main accounts for this and I wanted to do a demo with two separate accounts. So if you want to follow along, I would suggest creating two new accounts.

Call them as you want so 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 you can see right now, this is very quick, the organization is created and we have the root organizational unit and within it we have the AOS 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 Aeros 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 im 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 will just add the email which is addresschild account@stefanmarak. 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 channel accounts and on the left hand side there is invitation so I click on invitations. I’m going to refresh this page and now I see my invitation from the master accounts.

So as you can see in this organization right now we’ll get full controls but 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 aid of its 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 A list organization. Now if I go to my account, so I click on a list 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 what 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 under 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 last time we’ll have a prod. 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 Ou.

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 can 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 into, 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 a 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 kind 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 accounts 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 its 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 attack policy across all the accounts as well.

Okay, so service Control policies are enabled and so now what we would like to do is to have service controls 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 address access allows all the accounts to access all the services. But we can create a new policy and attach it. So we can create a policy called Oops. We can create a policy called Deny access to S three and this will deny access to the S Three 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 S Three service in here and within S Three 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 deny anything on this residence. Very simple policy and I’ll call it Deny sri has an Sid and then I will click on Create Policy.

So this when attached to my accounts, should deny access to Sray so we can have a look. So let’s go into our accounts. Okay, so if we look at the router, you want to click on route, as we can see there is enable policy type 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 route Ou, we have for example the prod Ou. And if you 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 address access. So it is duplicated this one for some reason. And then if I go into children and I go into finance and click on policies, we have three attached policies.

So one inherited from fraud, 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 ITER success was attached to every single element within my accounts. 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 fully accessed four times. So you understand at least the concept of inheritance, which makes sense. And you can just inherit things from root directly, 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 deny access S Three, I will attach it. And now that means that anything within my finance or you should also have this inheritance. So if I click on my Course Child and then Policies, as you can see, the deny access S Three 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 S Three console in a new tab, we are in S Three and the buckets are being loaded. But as we can see, we don’t have permissions to list buckets and therefore we cannot use Amazon S Three.

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 history. So this is very powerful and this is how SCPs 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.