Using AWS Organizations to Manage Multiple AWS Accounts

What is AWS Organizations?

AWS Organizations is an account management service that lets you consolidate and centrally manage multiple AWS accounts. This allows you to separate your workloads across different accounts, centralize management of your AWS accounts and workloads, and apply organization-wide security policies. AWS Organizations includes consolidated billing, letting you handle all the billing for your entire organization from a single AWS Account.

Why Should You Use Multiple AWS Accounts?

Separating your workloads in different AWS Accounts lets you achieve better workload isolation, improves your security posture, and makes overall management significantly easier.

Each AWS Account should serve one single purpose, and hold one workload. For multiple applications, each different application should have its own AWS Account. If you're using multiple environments for the same application, such as development, staging and production environments, then each should be in its own AWS Account.

Support Accounts in a Multi-Account Environment

In addition to the accounts that will hold your workloads, you should create support accounts that hold shared or support resources. The most common examples are:

• Security Account: It is meant to contain security appliances and security configurations. It should have read-only access to all the other AWS accounts. Security experts can use it to install applications or set up AWS services that scan traffic or configurations across all the other AWS accounts. Additionally, they can use their access from the security account to perform incident detection and root cause analysis.

• Networking Account: This is where you deploy shared networking resources, such as a Direct Connect connection to your on-premises datacenter, or shared NAT Gateways. Resources from the Networking account are usually shared via VPC Peerings, AWS Transit Gateway, or AWS Resource Access Manager.

• Shared Services Account: Shared Services holds AWS services and installed applications that don't strictly belong to one workload, but which can be shared across multiple workloads. The most common example is CI/CD pipelines, which may be shared across some or all workloads. Other common shared resources are static code analysis tools, AWS Workspaces instances, or cross-workload monitoring tools and dashboards.

• Logging or Log Archive: This account holds an archive of all application and security logs from all accounts and workloads. Access is append-only, meaning that logs can be written to it, but can't be modified or deleted. Furthermore, most people in your company should only have read-only access to this account. It's meant to be used as an archival repository of anything that needs records kept for some period of time. These logs may be consulted for root cause analysis of incidents, or for audit purposes.

• Backup: This account's purpose is to store backups of your important data, so you don't lose access to it even if an attacker gains access to your production accounts. You can use AWS Backup to automate backup creation and cross-account sharing. Here's an article where you can learn more about data replication and disaster recovery in AWS.

Organizational Units

In an Organization, Accounts can be added to groups of accounts called Organizational Units (OUs). This provides a simple way to logically group them based on the account's role, workload, or area to which the account belongs.

This is an example account structure using AWS Organizations:

Benefits of AWS Organizations

These are the core benefits of separating your workloads across different accounts and using AWS Organizations to manage them.

Consolidated Billing

AWS Organizations lets you pay all the AWS charges from the entire Organization directly from the root account. This way, you only set up your credit card details once, and everything is expensed to the root account.

Costs can be analyzed granularly using Cost Explorer. Additionally, from the root account you can analyze costs across the entire Organization. This gives you a high-level view of where expenses come from, and you can dive into as much detail as you want by using Cost Explorer's filters.

Centralized Management and Governance

The Organizations console in the root account lets you manage all your Organization's Accounts from a single place. You can modify their Organizational Units, add or remove Service Control Policies, and modify central configurations.

You can also create new accounts directly from the root account, and they will be automatically joined into your Organization. Account creation can also be delegated using a solution called Account Vending Machine, to give your teams a full self-service experience.

Improved Security

You can use Service Control Policies to define maximum permissions in an Organization. These security mechanisms let you centrally manage permission boundaries, and restrict actions such as leaving the Organization or prevent usage of the root user of the account.

How Much Does AWS Organizations Cost?

AWS Organizations is free. There are no additional charges for using it to set up and manage your AWS Accounts. Moreover, there are no extra charges for using a multi-account setup with AWS, since accounts themselves are free.

All other resources needed by AWS Organizations, such as cross-account access via IAM Roles, are also free to set up and use.

What are Service Control Policies?

Service Control Policies (SCPs) are organization policies that let you restrict permissions across accounts in an AWS Organization. They allow you to set the maximum permissions for an account, making sure all permissions adhere to your permission guidelines.

Service Control Policies use the same syntax as IAM Policies. They're created and managed from the AWS Organizations console, with the AWS CLI, or with any of the AWS SDKs, using the root account of the organization. You can associate SCPs to accounts directly, or to Organizational Units, and all OUs and accounts inside that Organizational Unit will inherit those SCPs.

Service Control Policies work by granting permissions to the root user of the account, which then are delegated to IAM Users and Roles inside that particular account. When you enable Service Control Policies for an Organization, the default is to create an SCP which grants all permissions, which has the same effect as if you hadn't enabled SCPs. From there, you can create additional SCPs with explicit Deny statements for certain actions, thus restricting the permissions of the root user of the account, and of all IAM Users and Roles in that account.

Some common SCPs are:

• Restrict Regions: An SCP that denies all actions for some regions. Since most companies only use a handful of the 20+ AWS regions, denying all access to AWS regions that aren't used simplifies management and security.

• Restrict Resource Size: It is highly unlikely that development or sandbox accounts will need to create large EC2 instances, RDS instances or Lambda functions. An SCP can be put in place to deny the creation of these resources if the size is bigger than "large", or for Lambda functions if the memory configuration is above a certain value.

• Require MFA: SCPs can be used to deny certain actions unless Multi-Factor Authentication has been used. With such a Service Control Policy in place, users who attempt those actions will be automatically required to enter their Multi-Factor Authentication code. It's common to enable this for irreversible actions such as deleting objects from an S3 bucket.

• Prevent Root Access: The root user should only be used for actions that can only be performed via root access, such as modifying the level of AWS support. To protect from malicious access, all actions for the root user can be blocked using a Service Control Policy. In the event that the root user is actually needed, the SCP preventing access can be temporarily removed, and then put back in place.

A Secure Cloud's Service Control Policies are a great starting point for setting up your own Service Control Policies. I highly recommend that you use them as a base or an inspiration for your own SCPs.

What is AWS Control Tower?

AWS Control Tower is a service that helps you set up and govern a secure, multi-account AWS environment. It is an opinionated architecture that builds out a multi-account architecture with pre-configured security and access settings. With Control Tower, you don't need to set up your organization from scratch. With just a few clicks, you can deploy predefined templates of organizations, including creating the necessary AWS accounts and setting up permissions.

Control Tower uses pre-defined controls and options to create an opinionated structure that suits most use cases. It applies best practices across the entire organization, and sets it up in a secure way. For most cases, AWS Control Tower is the best way to set up your AWS Organization.

How To Set Up a Multi-Account Environment Using AWS Organizations and Control Tower

These are the basic steps to set up an AWS Organization using Control Tower:

1. Log in to the AWS console

2. Go to the AWS Control Tower console

3. Check that you are in your desired home region

4. Click Set up landing zone

5. Follow the instructions, accepting all the default values.

6. Add the email address for your account, a log archive account, and an audit account

7. Verify all the options

8. Click Set up landing zone

9. Wait around 30 minutes while Control Tower sets everything up

If you'd like to set up an Organization without using the default values, read this guide.

AWS Organizations Best Practices

To get the most benefits out of Organizations, follow these best practices:

Don't Use The Root Account

In a sense, the root account of an Organization fulfills a similar role to the root user of an AWS Account. Anyone with access to the root can modify or remove Service Control Policies, leaving them exposed or locking you out. You should guard access to the root account, and only grant it to people who actually need it. To ensure that, don't deploy any workloads on the root account. Instead, create purpose-specific accounts for your workloads and resources.

Create an Organization From Scratch

If you already have an account with existing resources, it would feel natural to create your Organization there. However, that would mean you need to use the root account for managing your existing workload. Instead, you should create a brand new account to use as the root of the Organization, and invite your existing accounts to be a part of the Organization.

Use Service Control Policies

Service Control Policies let you limit permissions on accounts. Set them up for your different accounts and Organizational Units, so actions are restricted and security guardrails are enforced. Remember that with SCPs enabled all permissions need an explicit Allow statement in an SCP besides the Allow statement in IAM policies. Also, keep in mind that if there's an explicit Deny statement in an SCP, the action will be denied. Use these characteristics to deny certain actions, or to include certain conditions such as only using specific regions or requiring MFA authentication.

Use Single Sign-On

As the number of accounts grows beyond a handful, using IAM users and IAM roles to access your accounts becomes troublesome. Instead, you should set up IAM Identity Center to enable logging in to your different accounts with a single set of credentials. IAM Identity Center can use its own identity store or be connected to Active Directory, Google Workspaces, Okta, and any OAuth identity provider. Furthermore, you can allow different roles and sets of permissions on different accounts, limiting what each person can do.

Limit Access to Accounts

Just like not everyone needs access to all workloads, not everyone needs access to all accounts. Define your permissions carefully, and only allow actions that are actually needed. Enforce minimum permissions. This is made much easier by having workloads in separate accounts.