AWS Organizations and Service Control Policies (SCPs)
Think about your AWS environment and answer the questions below,
Do you know how many AWS accounts your organization has?
Do you have multiple bills for those accounts?
Do you struggle to ensure baseline controls are enabled across those accounts?
If you've answered yes to any of the above questions, let me introduce you to AWS Organizations and Service Control Policies (SCPs)! Together, we're going to wrangle up our accounts and test out an SCP.
AWS Organizations
First off, what is an Organization? Well, it's AWS's way of allowing you to consolidate and centrally manage all of your AWS accounts under one "management account". Some of the benefits include:
Visibility and organization - see all of your accounts at a glance and organize them in ways that make sense
Consolidated billing - all charges across your accounts are consolidated as one and billed to the management account
SCPs - policies (think controls for compliance, security, configuration, etc.) that you can enforce on all or some of your accounts
These are some great benefits, and there are even more. However, let's go ahead and start setting this up!
Step 1 - Setting up AWS Organizations
You'll need to head on over to AWS Organizations within the AWS account you want to set up as the management account. I've already set mine up, so I can't show you what to click, but I can show you what it looks like. You'll see an option to enable it. Go ahead and click that to get started.
As you can see below, you'll have a hierarchical structure when you enable this feature. Everyone has a Root Organizational Unit (OU), and you can create more like I did (DEV, PROD). OUs are helpful for grouping accounts, e.g., by business unit, department, function, etc. Think of OUs as folders or containers. They're also beneficial for enabling SCPs across multiple accounts but more on that later.
Step 2 - Building Out an Organization
Now that we've got our management account set up, we need to add some "member" accounts. You invite these AWS accounts to join your Organization or create yourself.
Click that button you saw in the previous screenshot, "Add an AWS account." Now, this is where we would create a new AWS account. We can ensure the new account is added automatically to our Organization by doing this here.
The second option is to invite an existing AWS account to join your organization. The owner of that account will receive an email request to join.
Now that we have some accounts added to our Organization, it's time we created some policies!
Service Control Policies (SCPs)
So, SCPs are similar to other AWS policies you might create but with a few things to keep in mind,
SCPs cannot grant access, only restrict it
Depending on your policy, it will apply to the whole AWS account targeted, even its Root user
SCPs do not impact the management account, even if the policy is attached to it
It's also important to remember how AWS handles permissions. When you have multiple permission policies, e.g., SCP, IAM Policy, Resource Policy, AWS stacks all of them together and works out permissions as such,
Explicit deny
Explicit allow
Implicit deny
This means that for all applicable policies, if any of those policies specifically deny access (Explicit deny) to a resource, for example, then the resource is denied access regardless of another policy granting access.
After Explicit deny is worked out, if any applicable policy specifically grants access (Explicit allow) to a resource, for example, the resource is allowed.
And, as always, AWS denies access by default (implicit deny). So, if a policy doesn't exist to grant access to something, then that access isn't allowed.
So, now that we have that worked out let's move on to creating our first SCP!
Step 3 - Enabling SCP
The first thing we must do is enable SCPs. This setting is within AWS Organizations on the side panel. See below,
Step 4 - Creating an SCP
Once we've enabled SCP capability, let's go ahead and create our first policy. We'll create a policy that restricts the ability to create an EC2 instance that doesn't use either instance type t1.micro or t2.micro. EC2 instance types affect the number of CPUs and Memory allocated. T1 and t2.micro are free tier eligible, so this policy is preventing anyone from trying to spin up an EC2 instance outside of the free tier. Follow the screenshots below, and we'll meet up at the end to discuss the policy.
So, here's the policy. You're welcome to copy and paste this into your console. Let's walk through this.
Sid: This is optional and useful for differentiating between multiple Statements. We only have one in this case
Effect: Deny access
Action: Launch an EC2 instance
Resource: Applies to EC2 for all accounts
Condition: Where string, in this case, the name of the instance type, is not t1.micro or t2.micro
So, in summary, Deny the ability to Launch EC2 instances unless the instance type is t1.micro or t2.micro.
Step 5 - Attaching SCP to OU
Once you've created the SCP, let's attach it to an OU. Now, keep in mind the best practice here would be to attach the policy to a test OU, and thoroughly test it to ensure it works as intended. The last thing you want to do is take down something in Production. I'll be attaching my policy to my DEV OU, which will impact my DEV account (training-development). See below,
Step 6 - Testing SCP
Now that our policy is created and impacting our account let's go ahead and test it! I'll be logging into my Dev account and will attempt to create an EC2 instance using an instance type other than t1/t2.micro.
Here's the error when attempting to create the EC2 instance from AWS CloudShell. Notice the instance type is t2.nano.
And here's the same when attempting to create the EC2 instance from the AWS Console.
Recap
So there you have it. Today we learned about AWS Organizations and how they help gain visibility into all of your accounts, logically organizing them, consolidating billing, and applying SCPs. With SCPs, we learned how to enable, create, and apply them to one or more AWS accounts.
Last updated
