The Account Foundation solution provides organizations with a simple, automated approach to managing their AWS cloud environments as the quantity and complexity of AWS accounts increase. Currently, many organizations begin their cloud journey by manually provisioning accounts, configuring guardrails, and leaving baseline account setup to the account owners. However, as an organization’s cloud presence scales upwards, this manual process slows down the account provisioning process and introduces many security vulnerabilities.
To address these issues, the Account Foundations solution demonstrates how an Account Vending Machine can automate account provisioning to ensure agility and security at scale.
Organization Baseline
The Account Foundations solution leverages AWS Organizations to build an organization structure and Control Tower to automate the governance and configuration of accounts throughout the organization.
Components
- AWS Organizations – Allows you to centrally manage and govern all the AWS Accounts across your organization. Management and governance features include, but are not limited to, centralized billing, uniform deployment of security guardrails across accounts, and seamless resource sharing across accounts.
- Organizational Unit (OU) – Logical component of AWS Organizations that allows users to design their organization. Each OU can hold AWS Accounts or other OUs. Since OUs can be nested, this allows for all AWS Accounts to be organized into a tree structure.
- AWS Accounts – Unique container for resources and services. The account owner can create, manage, and delegate access to resources. It is best practice to provide each application team with their own account to organize billing, isolate resources for security, and provide teams with more freedom to build their solutions.
- AWS Control Tower – Extends the functionality of AWS Organizations by providing an expansive set of additional features including the ability to apply Service Control Policies (SCP) and deploy baseline resources to AWS Accounts based on the OUs they reside beneath.
- AWS SSO – AWS SSO provides a federated access solution to centrally manage access across the organization. In this solution, it is implemented within the AWS Organizations management account, and provides federated access to the accounts across the organization. For instance, the organization’s management account should have access to all the accounts, whereas each account owner would only have access to their own account.
How it works
The first step to implementing AWS Organizations is to designate an account to serve as the Management Account for the entire organization. This account will have privileges to provision member accounts, manage finances of member accounts, and implement guardrails for member accounts. Since the Management Account has such expansive privileges, it is important to avoid using it to host workloads, shared services, or security tools.
Rather than manually creating the AWS Organization, we recommend using AWS Control Tower. AWS Control Tower allows you to create an AWS Organization with baseline OUs and default guardrails such as deletion protection for log archives. Although some basic OUs are included upon creation, it is imperative to create additional OUs to form a tree structure that can optimally govern the variety of accounts across your organization.
Like the hierarchical tree structures that system administrators are familiar with, the AWS Organizations tree structure allows accounts to inherit the customizations attached to the above it. For instance, if an account resides beneath the Production OU and the Production OU resides beneath the Workloads OU, the account will inherit all the customizations from both OUs. While the structure can differ slightly based on the specific needs of the organization, we typically recommend a design similar to the following.
From top to bottom, the purposes of the entities at each level of our recommended organization structure are as follows:
Level 0
- Organization Root – This is a logical representation of the root of the tree hierarchy. This is neither an OU nor an account.
- Management Account – This account uses Control Tower to create the AWS Organization, onboards new and existing accounts to the organization, and handles the billing for each account across the organization. Since it governs over all the accounts in the organization, it must be locked down and only used for AWS Organizations, AWS Control Tower, AWS SSO, and AWS Billing.
Level 1
- Critical Controls OU – This is uppermost OU in the AWS Organization hierarchy so the SCPs and StackSets that are attached to it are inherited by every account across the organization. We leverage this OU to enforce the most integral governance rules and configure security tools in each account.
Level 2
- Core OU – This OU holds accounts that aggregate administrative data from each account such as log archives and audit data. Since the resources and data from these accounts will mostly be accessed by auditors and teams across the organization, we recommend using this OU to apply guardrails to limit users to read-only access and configure deletion protection measures to ensure data integrity.
- Security OU – This OU holds accounts that the security team uses to aggregate monitoring data from each account across the organization (e.g. Security Hub), analyze the data (e.g. Athena), identify potential vulnerabilities and security events (e.g. GuardDuty), host automated-remediation tools, and conduct incident response activities. Since the security team is accessing accounts across the organization to aggregate data, we recommend creating SCPs that prevent accounts in this OU from creating, changing, or deleting resources in any workload accounts across the organization.
- Shared Services OU – This OU holds shared infrastructure resources (e.g. Transit Gateways and Amazon Cognito user pools) and service catalog products (e.g. CI/CD Pipelines).
- US Markets Workloads OU and European Markets Workloads OU – Alongside the other Level 2 OUs, we recommend creating OUs based on similarities of the workloads they hold. This design decision typically varies based on the organization, but for this example we created an OU to separate workloads pertaining to US Markets and European markets. This allows us to create SCP guardrails that will ensure that the organization is compliant with Data Protection Regulation within the respective divisions.
Level 3
We recommend that each of the Workload OUs (e.g. US Markets Workloads OU) contain all three of the following Software Development Lifecycle (SDLC) OUs. These SDLC OUs ensure that the cloud infrastructure is governed by the correct controls at each stage of the software development process.
- Non-Production OU – This OU contains accounts where teams develop new infrastructure and features. We recommend isolating infrastructure at this stage of software development by leveraging SCPs to limit connectivity to the organization’s networking resources and the public internet. This allows us to provide developers with more flexibility during the early stages of their development while removing security risks.
- Unit Acceptance Testing (UAT) OU – This OU contains testing accounts to allow developers and QA teams to test in environments that have the same controls and restrictions as the Production OU. As opposed to the Non-Production OU, the accounts in this OU allow for connectivity to all the same resources that are required in the production environment.
- Production OU – This OU contains accounts that run production workloads. To meet Service Level Agreement (SLA) requirements, we recommend implementing additional SCP guardrails to protect against potential incidents such as accidental resource termination and data deletion.
Account Vending Machine
The Account Vending Machine portion of the solution allows organizations to simplify the account provisioning process by automating security guardrail deployment and initial configuration of newly provisioned accounts. This allows you to immediately provision accounts while ensuring consistent security, compliance, and baseline configuration requirements are met.
Once the Account Vending Machine is implemented, the baseline SCPs and baseline resource deployment will be handled at the time of account creation. While this allows application teams to start building immediately, as they continue to develop their solutions their needs will evolve. Teams will likely need to leverage a variety of common infrastructure patterns such as specialized deployment pipelines, complex networking capabilities, and credential management solutions. To fulfill the unique requests from each team as efficiently and consistently as possible, we recommend leveraging an automated self-service strategy as discussed in our Infrastructure Foundation.
The reference architecture below illustrates how the Account Vending Machine operates alongside an ongoing self-service solution.
Components
- Customizations for Control Tower (CfCT) – Enables customers to customize their account provisioning process by attaching SCPs and deploying CloudFormation StackSets to accounts based on the OU that they reside under.
- CfCT Manifest.yml – Provides instructions for where to find the definitions of SCPs and StackSets and states which OUs each one should be applied to.
- Service Control Policy (SCP) – Organization-level policy that manages permissions across the accounts in the organization. These policies can range from course-grained permissions such as denying an account from using a specific AWS service, to as fine-grained as preventing users from disabling encryption of S3 buckets. SCPs are applied to accounts based on the OU they reside under.
- CloudFormation StackSet – In the context of CfCT, StackSets are a collection of resources that Control Tower deploys to accounts based on the OU that the account resides under. These resources can range from basic networking components such as VPCs to security tooling such as GuardDuty.
How it works
The implementation of the account vending machine relies on the three components of CfCT – manifest.yml, SCPs, and StackSets. Since the manifest.yml provides instructions for which SCPs and StackSets should be deployed to the accounts in each OU, a well-planned manifest.yml is integral to creating an account vending machine that can properly scale to meet business requirements.
To reduce redundancy and optimize the account vending process, we attach customizations that are required for all accounts to the Critical Controls OU at the top of the tree structure, and those that are specifically tailored to smaller subsets of accounts to OUs lower in the tree structure.
While we typically design our manifest.yml to include each OU in the organization, for the purposes of the Account Foundation, we will be focusing on the areas of the organization highlighted below since they are where the account vending machine delivers the most value.
The following sections detail the baseline SCPs and StackSets that we recommend attaching to each OU in your organization. By doing this, every account that resides beneath the respective OU will be governed by the SCP and have the StackSet deployed to it. The baselines detailed below enable organizations to stand up a secure and efficient strategy for provisioning accounts to teams throughout their enterprise and can be extended to fit specific business needs.
Critical Controls OU
The Critical Controls OU is at the top of the AWS Organization hierarchy, so the SCPs and StackSets that are attached to it are inherited by every account across the organization. We leverage this to implement the most integral governance rules and configure security tools in each account.
- Critical Controls SCP – Provides custom security guardrails to govern each account in the organization. These guardrails prevent accounts from leaving the organization, modifying billing settings, using prohibited services, and disabling a variety of security tools such as AWS IAM Access Analyzer and Amazon GuardDuty.
- Baseline Security Controls StackSet – Configures a baseline of security and compliance controls within every account in the organization. These controls include but are not limited to AWS Config Conformance Packs and Amazon GuardDuty. This StackSet is designed to be extended and used in conjunction with the solution discussed in the Controls Foundation.
US Markets Division OU
The US Markets Division OU is one level below the Critical Controls OU. This OU holds the workload accounts at every stage of the Software Development Lifecycle (SDLC) from Non-Production to Production.
- Data Protection Compliance SCP – Since all the operations of the US Markets Division of this example organization can be conducted within the US, this SCP provides guardrails to ensure that it’s application teams can’t deploy cloud infrastructure outside of the US. This ensures that the company not violating foreign data protection regulations such as General Data Protection Regulation (GDPR).
- Baseline VPC StackSet – To simplify the account setup process after provisioning, this StackSet automatically configures a three-tier VPC in the account so application teams can begin building as quickly as possible.
- Baseline IAM Deployment StackSet – This StackSet creates a collection of properly scoped IAM users and roles to minimize the overhead of IAM configuration and prevent overly permissive policies from being created.
Development Workloads OU
The Development Workloads OU resides beneath its respective business division’s OU. As opposed to the Unit Acceptance Testing (UAT) and Production Workload OUs, the Development Workload OU is intended to serve as a sandbox environment that is almost entirely segregated from the rest of the workloads.
- Sandbox SCP – To provide application teams with the most flexibility during the early stages of development, it is important to ensure that their development environment accounts are segregated from the rest of the workloads and cannot interact with the public internet or corporate networking components. This SCP ensures that this level of segregation is met by restricting users from creating components such as Internet Gateways in their development environment accounts.
Blueprint
- Account Vending Machine is a reusable CDK construct that deploys all the required SCP and CloudFormation scripts to S3 buckets so they can be consistently managed and accessed by the Control Tower orchestration process.
- Manifest.yaml provides Control Tower with the instructions for where to access the SCP and CloudFormation scripts and what OUs they should be attached to.
- SCPs and CloudFormation Templates are created and updated within the CDK project. When updates are ready for release, the CDK construct pushes them to an S3 bucket for version-control and deployment purposes.
Benefits
- AWS Organizations structure optimized to leverage account vending and security guardrails
- Improved visibility into security and compliance at the account level
- Centralized audit data and log archival for all accounts across the organization
- Consistent security and compliance controls deployed across all accounts
- Automated configuration of baseline account resources (IAM entities, networking components, etc.) allows account owners to immediately begin developing in their new account
End Result
After implementing the Account Foundation solution, an organization can onboard accounts with confidence that each account will be governed by baseline security guardrails and have baseline infrastructure resources deployed. This enables teams across the company to begin developing cloud solutions at a moment’s notice without having to sacrifice security, compliance, or consistency.
Interested in learning more?
If you are looking to provide automation, consistency, predictability, and visibility to your software release process contact us today.
