1 00:00:00,450 --> 00:00:03,180 So now let's talk about AWS Organizations. 2 00:00:03,180 --> 00:00:05,219 So it's a global service and it allows you 3 00:00:05,219 --> 00:00:09,330 to manage multiple AWS accounts at the same time. 4 00:00:09,330 --> 00:00:12,330 So you create an organization and the main account 5 00:00:12,330 --> 00:00:15,600 in your organization is called the management account, 6 00:00:15,600 --> 00:00:18,930 while the other accounts that join the organization 7 00:00:18,930 --> 00:00:21,120 or that are created from the organizations 8 00:00:21,120 --> 00:00:23,190 are called member accounts. 9 00:00:23,190 --> 00:00:27,120 And member accounts can only be part of one organization. 10 00:00:27,120 --> 00:00:29,880 The cool thing about organization is that the billing 11 00:00:29,880 --> 00:00:32,790 is consolidated across all the accounts, 12 00:00:32,790 --> 00:00:34,620 so you have a single payment method 13 00:00:34,620 --> 00:00:36,390 on the management accounts 14 00:00:36,390 --> 00:00:39,930 and then it will be paying for all the organization's cost. 15 00:00:39,930 --> 00:00:41,610 But because you have an organization 16 00:00:41,610 --> 00:00:43,950 and it's all part of one big family 17 00:00:43,950 --> 00:00:47,460 then you get pricing benefits from aggregated usage. 18 00:00:47,460 --> 00:00:50,640 So if you use a lot of EC2 or if you use a lot Amazon S3 19 00:00:50,640 --> 00:00:53,640 across all your accounts, then you will get big discounts 20 00:00:53,640 --> 00:00:56,010 because it will summarize and sum up 21 00:00:56,010 --> 00:00:58,113 all the usage across all the accounts. 22 00:00:59,520 --> 00:01:01,920 You can also share reserved instances 23 00:01:01,920 --> 00:01:04,620 and savings plans discounts across accounts. 24 00:01:04,620 --> 00:01:08,100 So if a reserved instance is unused in one accounts 25 00:01:08,100 --> 00:01:09,660 another account can benefit from it 26 00:01:09,660 --> 00:01:11,850 and therefore the discounts apply 27 00:01:11,850 --> 00:01:13,410 across the entire organization 28 00:01:13,410 --> 00:01:15,600 which is really good for cost savings. 29 00:01:15,600 --> 00:01:19,110 Now there's also an API to automate the account creation 30 00:01:19,110 --> 00:01:20,550 from within the organization. 31 00:01:20,550 --> 00:01:22,380 So you can create accounts very easily 32 00:01:22,380 --> 00:01:24,360 using an organization. 33 00:01:24,360 --> 00:01:25,193 So how does that work? 34 00:01:25,193 --> 00:01:29,580 So we have what's called a Root Organizational Unit or OU 35 00:01:29,580 --> 00:01:33,720 and this is the outermost OU of your accounts. 36 00:01:33,720 --> 00:01:36,810 And then within it sits the management accounts. 37 00:01:36,810 --> 00:01:38,700 Then you can create sub OUs, 38 00:01:38,700 --> 00:01:42,180 so you can create, for example an OU for the dev accounts 39 00:01:42,180 --> 00:01:45,360 and then you can create member accounts within the dev OU 40 00:01:45,360 --> 00:01:47,700 or you can create OU for a prod account 41 00:01:47,700 --> 00:01:49,530 and also add member accounts there 42 00:01:49,530 --> 00:01:51,240 but you can be as free as you want. 43 00:01:51,240 --> 00:01:55,380 You can create within the prod OU an OU for your HR 44 00:01:55,380 --> 00:01:58,860 member accounts and an OU for your finance member accounts. 45 00:01:58,860 --> 00:02:01,170 So you can organize it the way you want. 46 00:02:01,170 --> 00:02:04,890 So you have different examples for your business, 47 00:02:04,890 --> 00:02:05,723 for your OU. 48 00:02:05,723 --> 00:02:07,500 So you can organize by business units, 49 00:02:07,500 --> 00:02:09,960 so you have, for example, the management accounts 50 00:02:09,960 --> 00:02:12,570 and then the sales, retail, and finance OU, 51 00:02:12,570 --> 00:02:15,480 and then different accounts within each OU, 52 00:02:15,480 --> 00:02:17,970 or you can have an OU by environment. 53 00:02:17,970 --> 00:02:21,240 So for example, one OU for prod, one OU for test, 54 00:02:21,240 --> 00:02:24,034 one OU for dev, and within each OU some accounts, 55 00:02:24,034 --> 00:02:27,570 or project based, so you can have an OU per project within, 56 00:02:27,570 --> 00:02:29,220 and accounts within each project, so, 57 00:02:29,220 --> 00:02:30,053 and you can mix and match, 58 00:02:30,053 --> 00:02:32,490 you're really free to do whatever you want. 59 00:02:32,490 --> 00:02:35,790 So what are the advantages of using organizations? 60 00:02:35,790 --> 00:02:38,790 Well, thanks to having multiple accounts, 61 00:02:38,790 --> 00:02:41,430 you can have better security versus having 62 00:02:41,430 --> 00:02:43,380 one account with multiple VPC, 63 00:02:43,380 --> 00:02:46,110 because accounts are more separated than VPCs. 64 00:02:46,110 --> 00:02:49,590 You can also enforce tagging standards for billing purposes 65 00:02:49,590 --> 00:02:52,200 and you can in one go enable CloudTrail 66 00:02:52,200 --> 00:02:53,670 for all your accounts 67 00:02:53,670 --> 00:02:57,510 and send all the logs into a central S3 account 68 00:02:57,510 --> 00:02:59,520 or we can also send CloudWatch Logs 69 00:02:59,520 --> 00:03:01,170 to central logging accounts. 70 00:03:01,170 --> 00:03:03,090 And we can establish cross account roles 71 00:03:03,090 --> 00:03:04,950 for admin purposes automatically, 72 00:03:04,950 --> 00:03:07,020 so we can administer all the member accounts 73 00:03:07,020 --> 00:03:09,420 from the management accounts. 74 00:03:09,420 --> 00:03:11,190 So these are big advantages. 75 00:03:11,190 --> 00:03:13,950 Also, there's a big security advantage, 76 00:03:13,950 --> 00:03:17,880 we can define Service Control Policies or SCP 77 00:03:17,880 --> 00:03:22,260 and it's an IAM policy applied to specific OUs or accounts 78 00:03:22,260 --> 00:03:25,500 and this allows you to restrict what the users and roles, 79 00:03:25,500 --> 00:03:28,200 all of them can do within the accounts. 80 00:03:28,200 --> 00:03:33,150 The SCPs apply to everything but to the management accounts 81 00:03:33,150 --> 00:03:35,460 which will forever have full admin power, 82 00:03:35,460 --> 00:03:38,700 otherwise you could do a mistake 83 00:03:38,700 --> 00:03:40,170 and never come back from it. 84 00:03:40,170 --> 00:03:42,000 So the SCPs by default, 85 00:03:42,000 --> 00:03:44,070 they don't allow anything just like IAM. 86 00:03:44,070 --> 00:03:47,100 You need to have an explicit allow for things to work. 87 00:03:47,100 --> 00:03:50,310 So let's go through an example to understand how that works. 88 00:03:50,310 --> 00:03:54,210 So let's take, for example, this organization. 89 00:03:54,210 --> 00:03:55,887 We have the Root OU and the Management Account 90 00:03:55,887 --> 00:03:59,100 and then we have a Prod OU and we have an Account A in it 91 00:03:59,100 --> 00:04:00,977 and then we have two sub OUs, the HR OU, 92 00:04:00,977 --> 00:04:04,110 and the Finance OU with Account B and Account C. 93 00:04:04,110 --> 00:04:06,240 And let's have a look at how SCPs will affect 94 00:04:06,240 --> 00:04:08,070 the permissions of each accounts. 95 00:04:08,070 --> 00:04:11,970 So at the Root OU, it is very common to attach 96 00:04:11,970 --> 00:04:15,450 the full AWS access SCP 97 00:04:15,450 --> 00:04:19,740 and therefore any accounts within the Root OU 98 00:04:19,740 --> 00:04:21,839 will have full permissions on their accounts. 99 00:04:21,839 --> 00:04:24,360 That means the management accounts, the account AIM prod, 100 00:04:24,360 --> 00:04:27,600 the account B and account C, well can do anything they want. 101 00:04:27,600 --> 00:04:29,970 And then we would apply more SCPs. 102 00:04:29,970 --> 00:04:31,560 So that's one way of doing things, of course, 103 00:04:31,560 --> 00:04:33,840 and I'm going show you the most common way. 104 00:04:33,840 --> 00:04:36,630 So then let's apply a DenyAccessAthena SCP 105 00:04:36,630 --> 00:04:40,140 on the Management Account, we apply a DenyRedshift SCP 106 00:04:40,140 --> 00:04:43,950 on the OU in Prod and then more SCPs, and let's have a look 107 00:04:43,950 --> 00:04:47,490 at what it does for each account's perspective, okay? 108 00:04:47,490 --> 00:04:49,830 So for the Management Account, 109 00:04:49,830 --> 00:04:53,820 even though we have applied the DenyAccessAthena SCP 110 00:04:53,820 --> 00:04:56,250 to deny access to the Athena service, 111 00:04:56,250 --> 00:04:59,220 the management accounts can still do anything 112 00:04:59,220 --> 00:05:01,560 because no SCP applied to it. 113 00:05:01,560 --> 00:05:03,600 So the management account has full admin power 114 00:05:03,600 --> 00:05:05,280 over everything. 115 00:05:05,280 --> 00:05:08,250 Okay, now what about account A? 116 00:05:08,250 --> 00:05:10,920 So account A is in the Root OU, 117 00:05:10,920 --> 00:05:12,990 so it can do a lot of things 118 00:05:12,990 --> 00:05:17,040 and then it's also in the Prod OU and on the Prod OU 119 00:05:17,040 --> 00:05:18,693 there is the DenyRedshift SCP 120 00:05:18,693 --> 00:05:23,130 that has been attached to it and therefore the Account A 121 00:05:23,130 --> 00:05:26,490 does not have access to Redshift 122 00:05:26,490 --> 00:05:29,790 even though we have attached an SCP on top of the Account A 123 00:05:29,790 --> 00:05:33,600 saying authorized Redshift, because if there is one deny 124 00:05:33,600 --> 00:05:35,820 in your policy, an explicit deny, 125 00:05:35,820 --> 00:05:37,620 then by default it's denied. 126 00:05:37,620 --> 00:05:40,680 So account A, in this example can do anything 127 00:05:40,680 --> 00:05:43,680 but access the Redshift service. 128 00:05:43,680 --> 00:05:47,580 Now, if you look at Accounts B it's within the HR OU 129 00:05:47,580 --> 00:05:50,790 which is within the Prod OU, so it inherits everything. 130 00:05:50,790 --> 00:05:54,781 So Account B has full AWS access from the Root OU, 131 00:05:54,781 --> 00:05:57,980 DenyRedshift SCP from the Prod OU 132 00:05:57,980 --> 00:06:00,989 and DenyLambda SCP from the HR OU 133 00:06:00,989 --> 00:06:02,739 and therefore it can do anything 134 00:06:02,739 --> 00:06:05,906 but access Redshift and access Lambda. 135 00:06:08,141 --> 00:06:10,992 And now, Account C is within the Finance OU 136 00:06:10,992 --> 00:06:13,909 which is in the Prod OU, which is within the Root OU 137 00:06:13,909 --> 00:06:17,730 and therefore it can do anything except access Redshift. 138 00:06:17,730 --> 00:06:19,380 So we've seen a few examples of SCP 139 00:06:19,380 --> 00:06:21,810 and hopefully this is clear to you. 140 00:06:21,810 --> 00:06:24,750 So two strategies for SCP, 141 00:06:24,750 --> 00:06:26,910 you have a block list or an allow list. 142 00:06:26,910 --> 00:06:29,700 So a block list is saying, hey, 143 00:06:29,700 --> 00:06:32,940 here are the services that I don't want you to use. 144 00:06:32,940 --> 00:06:36,000 So usually we attach first an allow star 145 00:06:36,000 --> 00:06:38,580 to allow all actions on all services 146 00:06:38,580 --> 00:06:40,590 and then we attach a denied statement, for example, 147 00:06:40,590 --> 00:06:42,670 to deny access to DynamoDB 148 00:06:43,530 --> 00:06:47,070 or allow list is we don't allow elections, which only allow 149 00:06:47,070 --> 00:06:49,710 for example, in this example, EC2 and CloudWatch. 150 00:06:49,710 --> 00:06:52,260 And so only EC2 and CloudWatch are authorized 151 00:06:52,260 --> 00:06:55,860 on your account where this SCP has been attached 152 00:06:55,860 --> 00:06:57,780 and any other service is not usable 153 00:06:57,780 --> 00:07:00,990 because it would need an explicit allow to be used. 154 00:07:00,990 --> 00:07:02,580 So that's it for organizations, 155 00:07:02,580 --> 00:07:05,530 I hope you liked it and I will see you in the next lecture.