‫Now let's tackle a long section
‫on Account Management, Billing and Support.
‫And we will be starting with AWS Organizations.
‫So it's a very simple service, it's a global service.
‫And the idea is that by creating an organization
‫you're able to manage multiple AWS accounts.
‫The main account is going to be called the master accounts
‫and all the other ones will be called child accounts.
‫The cost benefits you get from using an organization
‫is that you get consolidated billing.
‫That means that all the accounts will be paid
‫by just the master accounts.
‫And so you will have one longer bill at the end.
‫So you don't just set up as payment method
‫for all the other accounts.
‫The other thing is that you get pricing benefits
‫from aggregated usage.
‫So when you use a lot EC2, when you use a lot S3
‫you get a discounts because you've used that at lots.
‫And so if you have multiple accounts,
‫you could lose that volume, but with an organization
‫because the billing is consolidated
‫the aggregated usage is as well consolidated.
‫And that means that you get more discounts.
‫Also, if you're using reserved instances, they're shared
‫across all the accounts to make sure
‫that if one account does not use a reserved instance
‫another one can and again, maximize the cost savings.
‫There's an API that is available to automate AWS account
‫creation to do so automatically, which is very helpful.
‫For example if she had some processes to create an accounts
‫programmatically for someone, for example
‫is a sandbox accounts.
‫And then finally you can restrict account
‫privileges using a Service Control Policy or SCP.
‫And that is a common exam question.
‫So all the things highlighted in bold
‫in this slides are going to be common exam questions.
‫And I'm gonna go a bit deeper on the organization.
‫So you can have a multi account strategy in AWS.
‫That means that you wanna create the accounts
‫for example, per department per cost center, per
‫environment, for example dev test and prod based
‫on regular share restrictions.
‫For example, if you don't want a service to be using
‫an account you can use an STP or if you want to isolate
‫the resources better you could have different VPC
‫in different accounts and is also very good to have separate
‫per account service limits
‫and also isolated accounts for logging.
‫So all of these could be multi account strategies is really
‫up to each organization to choose what type
‫of accounts they want.
‫So the idea is that you have two options
‫you can use Multi Accounts or One Account and Multiple VPC.
‫That is a trade-off, I personally liked
‫the multi account better.
‫You can use tagging standards across all the accounts
‫for billing purposes and we'll see billing
‫in depth in the section.
‫And you should enable CloudTrail on all the accounts
‫send that the logs to a central S3 accounts.
‫And also as well for the CloudWatch Logs
‫you should send them all to a central logging accounts.
‫So how can you organize your accounts?
‫Well, you can organize them by business units, for example
‫with a master account.
‫And then we have the sales OU, we have the retail OU
‫and the finance OU.
‫And within each OU, so each organizational units
‫you will have multiple accounts.
‫Or you can organize them by environments, production,
‫developments and tests.
‫Or we can have them project-based, for example
‫project one, project two, project three
‫or a mix of all these things.
‫Okay so an organization it looks like this.
‫The Roots OU contains everything.
‫It contains the master accounts
‫and then you can create a different OU.
‫So the Dev OU maybe with the two accounts in it.
‫The Prod OU maybe with two accounts in it.
‫And within the Prod OU you can also have different OU.
‫So a Finance OU and an HR OU with their respective accounts.
‫Oh, that makes sense.
‫There's something called a Service Controlled Policy or SCP.
‫It allows you to whitelist or blacklist IAM actions applied
‫at the OU or account level
‫but it doesn't apply to the master accounts.
‫The SCPs have no effects on the master accounts.
‫So the SCPs, we'll see an example of very shortly.
‫They can be applied to only the users and the roles
‫of the accounts, including the roots.
‫So if you apply an SCP onto your account
‫with an OU and you say you cannot use EC2
‫even an admin within an account can not use EC2.
‫But the SCP does not apply to service-linked role.
‫So this is a 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 will be to restrict access
‫to certain services.
‫For example, you were 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 and make this a little bit clearer.
‫Let's have a look at our OU.
‫So we have the Root OU with a root accounts, a production OU
‫with an account A in it and with an HR OU
‫with account B and a Finance OU with account C.
‫So let's assume that you usually do this on the Root
‫OU you add an SCP called FullAWSAccess
‫which tells that every services in every action can be done
‫basically allowing you to use your accounts.
‫But let's apply a DenyAccessAthena SCP
‫onto Veet master accounts.
‫Now what can the master it can do or cannot do?
‫Well, the master accounts can do anything because
‫it inherited the full alias access SEP from the root OU.
‫And even though we have attached a DenyAccessAthena SCP
‫to the master accounts because it is the master account
‫of your root OU no SCP apply.
‫And therefore this SCP replied 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 DenyRedshift SCP that is applied to the Prod OU.
‫And an AuthorizeRedshift SCP applied
‫it to the accounts A.
‫So now about account A, it can do anything because
‫you have full access SCP.
‫But it cannot access Redshift because
‫there's a DenyRedshift SCP applied to the Prod OU.
‫And even though I would attach an AuthorizedRedshift SCP
‫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 authorized.
‫So even though I have this authorized Redshift SCP
‫on the account A, actually that authorized 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 HR OU, it has a DenyAWSLambda 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 is the bigger OU.
‫And also it can not access AWS Lambda
‫because it's within the HR OU.
‫So accounts C though in finance OU is not affected
‫by this DenyAWSLambda the SCP because only apply
‫to the HR OU but not the finance OU.
‫And therefore account C has the exact same information
‫as account A which is to do anything but access Redshift.
‫Hopefully that makes sense.
‫If you understand this, you've basically understood SCP
‫and their power.
‫So let's take an example of what it looks like
‫an SCP looks just like a IAM policy.
‫So this is AllowALLActions, so we allow star on star.
‫So this star you can do anything.
‫But DenyDnynamoDB 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 ec2 star in CloudWatch star
‫on resource star.
‫But any other services but ec2 in CloudWatch
‫cannot be usable.
‫If you don't know exactly what this means
‫or 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.
‫So that's it for organizations, I hope you liked it.
‫And in the next lecture I'm going to do an optional
‫walk-through organization, it's a bit more complicated.
‫So I would just recommend if you just want to, to just watch
‫me do and see how I use organization to demonstrate
‫the creation of accounts and to demonstrate
‫as well the use of SCP.
‫So hope you like this and I will see
‫you in the next lecture.