When One AWS Account Is Not Enough

While hosting all your different applications, workloads, and environments in a single account is possible, this can easily become difficult to manage. Each application requires a different environment to support the various stages of its lifecycle, such as development, testing, and production. Hosting multiple environments for multiple applications in a single account is possible, but this can quickly turn complicated. This complexity arises for various reasons, including the need to ensure separation and isolation of workloads and environments for security reasons or budget and cost allocation.

Furthermore, hosting all your application workloads and environments in a single AWS account increases the risk of significant mishaps, which could wipe out all your applications and their different stages of development.

Having a separate account for development, testing, and production and one (or multiple) separate account(s) for experimental workloads makes sense. As depicted in Figure 1.2, any adverse events in the sandbox (experimental) account will not affect workloads in the other accounts.

Figure 1.2 – AWS Organization – limiting the blast radius of major disasters

AWS highly recommends adopting a multi-account strategy and provides specific services to help build and manage such multiple accounts. In the following subsection, you’ll get to understand how AWS Organizations enable the secure and efficient management of multiple AWS accounts.

Introducing AWS Organizations

You can create several AWS accounts to help you separate different workloads or application life cycles. However, you need a mechanism to secure and manage them. You also need to define policies and permissions in the form of guardrails that allow you to specify what services can be consumed in each account, what resources can be deployed, and even what regions those accounts can deploy applications in. This ensures that you adhere to strict compliance and regulatory requirements for your industry and helps you meet corporate governance and management.

The AWS Organizations service is the ultimate tool to help you effectively provision and manage multiple AWS accounts. To set up AWS Organizations, you must designate an AWS account as the management account. This account hosts the actual AWS Organizations service for your business. You can then invite existing accounts or create additional AWS accounts that will become member accounts of the organization.

You can also have multiple member accounts in your AWS organization, where some share similar workloads or functions. For example, you may have multiple development accounts or multiple production accounts. These logical groups of accounts may share similar security requirements as well. To effectively manage these groups, you can create Organization Units (OUs), logical containers that club members’ accounts within the AWS Organization that share common workloads. So, for example, as depicted in the following diagram, we have three different OUs. Within each OU, you can place the relevant AWS accounts and apply policies and permissions that the members of the OU may share in the organization, as shown in Figure 1.3:

Figure 1.3 – AWS Organizations with OUs and SCPs

The number of AWS accounts required for your business is not a fixed quantity. It varies based on several factors including the functional needs of your business, the complexity of workloads, and the specific security and compliance requirements your business must adhere to. Often, you have some shared services accounts, too – for example, a separate identities account that can be used to centrally manage users (usually representing your colleagues or technical staff) and define the permissions on what they can do in your member accounts. Using a process known as cross-account access or single sign-on (SSO), discussed in Chapter 2, Securing Access with AWS Identity and Access Management, Federation, and Amazon Cognito, you will learn how these users can switch roles into other AWS accounts within your organization and carry out various job functions.

In the next subsection, we look at service control policies, a mechanism to enforce rules in how your AWS accounts are used, what services can be consumed, and even which regions you can access.

Service Control Policies (SCPs)

As depicted in Figure 1.2, you can apply SCPs that act as guardrails on what services can be consumed in each AWS account. SCPs are policy documents written in JavaScript Object Notation (JSON) format, and they enable you to define what type of resources can be deployed in your AWS account and what actions can be performed against those services. SCPs can also restrict which regions those accounts can provision resources in. The guardrails are designed to help ensure that only approved services can be accessed in your AWS accounts.

Note

SCPs do not define what individual users can do in your AWS account. They define the maximum permissions administrators can assign to those users and what actions against AWS services are permitted.

The AWS Identify and Access Management (IAM) service is then used to assign those permitted permissions to those individual users. We will look at the IAM service in greater detail in the next chapter.

SCPs are disabled when setting up AWS Organizations. When you enable them, a default SCP policy called FullAWSAccess is attached to the root and applied to any OUs and AWS accounts in the organization.

Note

You can also apply a policy at the account level.

SCPs follow a deny-by-default design. So, unless permission is defined to allow a specific action at all levels from the root, through OUs, and to the accounts in its path, it will be denied. When you first enable SCPs, the FullAWSAccess policy is applied at all levels from the root, through OUs, and, finally, directly to accounts; there are no restrictions to any services or actions you can perform in your AWS accounts. You should then strategically plan and apply your policies to align with your corporate requirements.

If you detach the FullAWSAccess policy from a specific OU or account, you must ensure that you replace it with a policy that specifies the services you want to access and the actions you wish to perform. Otherwise, you cannot perform any actions in the account.

If you apply a deny permission at any level in the path of the account – that is, if you apply it at the root or the OU that contains the account – then the deny rule will override any conflicting allow permission.

In the following diagram, Figure 1.4, you will note two different configurations. In configuration A, permission to perform an action is applied at all levels, which results in the permission being allowed in Account B. However, in configuration B, permission to perform an action is being denied at the OU level, specifically applied to the Production OU. This results in the permission being denied in Account B, even though there is an explicit Allow rule being applied to this account. This is because a deny rule will always override an allow rule. Furthermore, allow permissions must be explicitly defined at all levels as the default rule is to deny the action.

Figure 1.4 – Comparing allow and deny rules for SCPs

SCP policies can have multiple statements with allow and deny permissions. This makes it easy to draft and apply a single policy with both allow and deny permissions to an OU and account.

For example, you can attach the following policy to an OU (or member account). This would result in being able to perform all actions against all services except Amazon S3:

{
    "Version": "2012-10-17",
    "Statement": [
     {
            "Sid": "AllowsAllActions",
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        },
        {
            "Sid": "DenyAmazonS3", 
            "Effect": "Deny",
            "Action": "S3:*",
            "Resource": "*"
        }
    ]
}

It’s perfectly fine if the structure of the policy seems a bit complex at this point; you’ll delve into the details of JSON policy documents in the upcoming chapter.

With AWS Organizations, you can also manage the costs associated with your AWS accounts more effectively using the Consolidated Billing feature, which is included as part of the service. The management account is responsible for charges incurred by individual member accounts, and you are provided with a consolidated view of those charges. One of the key benefits of this feature is volume discounts. By combining the costs across your accounts, you can get discounts when your total charges cross certain volume discount thresholds.

Furthermore, you can use AWS Organizations to share certain resources across your member accounts. For example, you may wish to share certain network resources, such as VPC subnets, or share reserve instances purchased across member accounts. VPC subnets are further discussed in Chapter 4, Building Private Networks in the Cloud with Amazon VPC.

This section analyzed the use case for architecting a multi-account strategy on AWS. We also looked at how to centrally create and manage multiple AWS accounts and apply SCPs to establish guardrails on what services can be consumed in those accounts. By now, it is evident that meticulous preparation is essential before starting your cloud journey with AWS, incorporating security best practices, and enforcing corporate governance.

In the next section, we look at another AWS service that allows you to set up and manage multiple AWS accounts following recommended guidelines and build landing zones.

AWS Control Tower

As discussed, planning and creating a multi-account strategy for your AWS journey will enable you to ensure higher levels of security, governance, compliance, and cost efficiency. However, building a multi-account environment can become very complex and time-consuming. You need to decide how many AWS accounts you will need, whether certain accounts will be used for internal shared services, and how many environments you will need to cater to.

AWS offers tools to help you build multi-account environments that follow best practices and adhere to well-architected principles using AWS Landing Zone. These blueprints will help design and architect a multi-account deployment, offering IAM, governance, data security, and audit logging capabilities.

To help automate the deployment of multiple accounts using these recommended blueprints, AWS offers a service known as AWS Control Tower. This service can automatically implement your landing zone to include the following:

• Your AWS Organizations and any member accounts for your various workloads and environments
• An IAM service that offers AWS SSO default directory services
• Account federation using SSO
• Centralized logging using AWS CloudTrail and AWS Config

Using AWS Control Tower, you can also select pre-packaged governance rules for security, operations, and compliance and apply them to the entire enterprise or specific groups of accounts.

The AWS Control Tower service also has a dashboard feature enabling you to view your AWS environment. Using the dashboard, you can see the various OUs and accounts provisioned and the number of guardrails defined and applied to the various OUs and accounts.

In this section, we looked at how you can automate the design and implementation of your multi-account strategy using AWS-recommended blueprints that adhere to its well-architecting principles.

In the next section, we will have a look at the options available to access your AWS account(s).