How SMBs can deploy a multi-account environment quickly using AWS Organizations and AWS CloudFormation StackSets

Small and Medium Businesses (SMBs) need to operate with high availability and mitigate security risks while keeping costs low. An AWS multi-account environment with workload isolation, robust access control, cost visualization, and integrated security mechanisms can help SMBs build a platform to support growth. SMBs want to deploy a multi-account environment on AWS quickly and securely to maximize the benefits of the cloud.

Last year we published the Multi-account strategy for small and medium businesses blog post that delved into why SMBs should build a multi-account cloud environment, and the AWS best practices for setting one up. In this blog post, we will walk you through a quick, simple, secure, and scalable multi-account environment using IaC (Infrastructure as Code) with AWS Organizations and AWS CloudFormation template. AWS CloudFormation provides a simplified way to model and provision AWS resources as a unified stack. Creating organizational resources via CloudFormation StackSets enables centralized, consistent resource provisioning across accounts, reducing operational overhead and costs.

With the right foundation in place, SMBs can easily leverage cost optimization, security and governance services and features to manage their environment at scale, and lower their administrative burden with reduced cost. The guidance discussed in this blog uses services such as AWS Organizations and AWS CloudFormation to help you set up a lean multi-account environment. If you’d like to opt for automated and managed set up of your multi-account environment following best practices with deployment of cloud governance services such as AWS Config, AWS CloudTrail, and AWS Security Hub, you should consider AWS Control Tower.

Solution Overview

AWS Organizations implements a hierarchical account structure with a single management account and member accounts. It allows you to implement workload isolation, centralize monitoring and centrally manage security policies. It also enables access to a large number of security services from AWS that integrate with AWS Organizations to efficiently manage your security posture with limited resources. AWS CloudFormation StackSets enables you to create, update, or delete stacks across multiple AWS accounts and AWS Regions with a single operation. You can configure the templates to define the organizational resources you need to manage along with their interdependencies. AWS Organizations resources in CloudFormation require using organization’s management account or delegated administration account. Integrating AWS CloudFormation with AWS Organizations allows you to deploy stack instances to member accounts in your organization.

In this blog post, we will do the following

• First, we will deploy an AWS CloudFormation template to set up an organization consisting of recommended organizational units (OUs), associated with service control policies and a resource policy to grant all member accounts the ability to retrieve information about the organization they belong to.
• Then we will enable AWS IAM Identity Center to provide your workforce with federated access to your organization.
• We will deploy IAM roles to member accounts to support the services used and to enable emergency access in case of an issue with Identity federation.
• Finally, we will deploy three AWS Systems Manager parameters that will come handy when defining IAM policies in member accounts.

When the AWS CloudFormation template is deployed, the resultant set up will be as shown in the Image 1.

Image 1: Sample multi-account environment deployed with the CloudFormation StackSet

Prerequisites

When setting up a multi-account environment we recommend that

• You create a new, empty AWS account to be your management account, where you will deploy the AWS CloudFormation StackSet that will create the multi-account environment.
• Use an alias or group email id to set up the management account.
• Do not use an email address associated with an individual as it can cause issues if that person leaves the organization.
• Ensure you activate MFA for your root user.
• If you have any existing workload accounts, you can invite them to join as member accounts once you set up your organization.

Walkthrough

In this section, we will walk you through how to deploy a CloudFormation StackSet template (CFN template) to spin up a lean AWS Organization following AWS best practice guidance. We will also provide other recommendations that you need to set up outside of this template. When the AWS CloudFormation template is deployed, the resultant set up will contain an organization consisting of recommended organizational units (OUs), associated with service control policies and an AWS Organizations resource policy to grant all member accounts the ability to retrieve information about the organization they belong to as. The details are as below.

Seven organizational units

• Security–Within the organizational root
• Infrastructure–Within the organizational root
• Workloads–Within the organizational root
• Non-Prod–Within the Workloads OU
• Prod–Within the Workloads OU
• Sandbox–Within the organizational root
• Exception–Within the organizational root

One service control policy attached at the root of the organization, to

• Deny all root actions.
• Prevent member accounts leaving the organization.

An AWS Organizations Resource Policy which grants the ability to retrieve information about the organization the member accounts belong to.

A CloudFormation service role in each member account with an associated permissions boundary to allow deployment of stacks without allowing access to IAM administrative actions that could lead to privilege escalation.

AWS Systems Manager Session Manager (SSM) Parameter Store parameters for all the member accounts.

Please note that the above AWS Organizations resources are being deployed as an example for a lean starting point for SMBs. Please refer to Organizing Your AWS Environment Using Multiple Accounts whitepaper for more information on multi-account strategy best practices and recommendations.

Deploy the CloudFormation template

1. Download the CloudFormation template from GitHub.
2. Sign in to the management account for your organization, navigate to the CloudFormation console, and choose Create stack.
3. Choose With new resources (standard), upload the template.yml file, and choose Next and configure the template parameters as follows:
   a. pSSOInstanceId: Leave this blank for now.
   b. pDeveloperPrefix: Used for naming self-service IAM roles and CloudFormation stacks in member accounts. Defaults to app.
   c. pCloudFormationRoleName: IAM Role used by CloudFormation to deploy stacks in member accounts. Defaults to CloudFormationRole.
   d. pRegions: Regions in which to deploy the StackSets. Defaults to us-east-1. Include any regions you plan to use.
   e. pSandboxOuName: A name for the sandbox OU. Defaults to Sandbox.
   f. pSecurityOuName: A name for the security OU. Defaults to Security_Prod.
   g. If you want to customize the template to your needs. We have used AWS Serverless Application Model (AWS SAM) CLI to create the template, and you can find the original code in this GitHub Repo.

At a broader level, the template.yml deploys an organizational structure as depicted in the Image 2.

Image 2: Organizational structure deployed by template.yml

Let’s now discuss the organizational elements created using the template.yml in detail.

Foundational OUs

Foundational OUs host accounts which host resources that provide shared services like Security and Infrastructure for your organization. There is no technical difference between these OUs and the others, it’s just a logical distinction based on their intended content.

• The Security OU will contain accounts hosting your security services. This will typically include an account to centralize logs from across your organization, and another for centralizing security tooling to give you organization-wide visibility into your security posture and compliance status. Access to this OU should be restricted to the team responsible for your cloud security.
• The Infrastructure OU is intended for accounts hosting other shared services like Networking, DevOps, Image factory amongst others. Access to this OU should be restricted to your cloud operations team.

Workloads OUs

The Workloads OU is where your applications will live. Under the workloads OUs are nested the Non-Prod OU and the Prod OU. As the name suggests the Non-Prod OU hosts all non-production account and the Prod OU hosts all production accounts.

If you have existing accounts containing workloads, you can invite them into your AWS Organizations and then move them to the suitable OU. Segregating OUs in this manner allows you to test infrastructure changes such as those in service control policies (SCPs) in lower environment (ex: test) before pushing them to production.

For day to day operations, resource provisioning in workloads account should be infrastructure as code CI/CD pipelines. This will not only prevent drift due to manual changes made through the console in your applications but also facilitate consistent deployments across environments. In the template.yml, we have configured appropriate permissions to use AWS Proton for deploying your workloads. AWS Proton is a service designed to allow creation, sharing and reuse of infrastructure as code templates for serverless and container based workloads, along with their CI/CD tooling. The permissions granted for AWS Proton are given as an example and can be replaced with permissions required by your developer tooling of choice.

Sandbox OU

The Sandbox OU will provide your builders with an environment with fewer constraints, giving them freedom to experiment without putting production workloads at risk. You may allow your builders to use new services in this OU for experimentation.

Controls

The template.yml defines a single service control policy (SCP), attached at the root of the organization, which implements some fundamental constraints across all the member accounts.

• Denying all root actions.
• Preventing member accounts leaving the organization.
• It also defines an AWS Organizations Resource Policy which grants all of the member accounts the ability to retrieve information about the organization they belong to.

IAM roles

IAM roles are deployed to all member accounts in the organization from a CloudFormation StackSet (AWSPlatform-BASELINE-ROLES) in the management account. The Arn and Name of these roles are available as Stack outputs in the member accounts.

A service role for CloudFormation has the AdministratorAccess managed policy attached but is also constrained by a permissions boundary intended to allow developers to deploy and manage resources from commonly used developer services as well as IAM roles and policies via CloudFormation without permitting privilege escalation.

Miscellaneous

Finally, an AWS CloudFormation StackSet (AWSPlatform-BASELINE-PARAMETERS) is deployed to the management account, which pushes out some useful AWS Systems Manager Session Manager (SSM) Parameter Store parameters to all member accounts in the AWS Organizations, such as

• /platform/org/OrganizationId
• /platform/iam/CloudFormationRole
• /platform/iam/CloudFormationRoleArn

For example, you may want to restrict access to reading logs from your centralized logging Amazon Simple Storage Service (Amazon S3) bucket (Name: centralized-logs) to only accounts in your organization (Org ID: o-xxxxxxxxxxx). You can achieve this easily using the SSM parameter /platform/org/OrganizationId which contains your organization ID.

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "AllowOrgWideRead",
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::centralized-logs/*",
    "Condition": {
      "StringEquals": {
        "aws:PrincipalOrgID": "{{resolve:ssm:/platform/org/OrganizationId}}"
      }
    }
  }
}

Enable IAM Identity Center for single sign-on for the workforce in your organization

We recommend you use AWS IAM Identity Center to provide workforce access for your organization. It provides secure single sign-on, centralized identity management, and access control, reducing IT overhead for SMBs with limited resources while improving security and productivity.

Moreover, AWS IAM Identity Center provides short lived temporary credentials to allow federated user access to AWS accounts instead of using the long-lived credentials associated with an IAM user. This is a security best practice to curtail unauthorized access to your resources.

It isn’t currently possible to enable the Identity Center via API so we can’t automate this step with the CloudFormation template yet.

Since you already deployed the template.yml and your AWS Organizations is now configured, you can log in to your management account as the root user and manually enable Identity Center.

You can get your Identity Center Instance ID from the Identity Center console as shown in the Image 3.

Image 3: IAM Identity Center Settings page

We will now update the existing CloudFormation stack with the Instance ID value from AWS IAM Identity Center. From the command prompt, run the command sam deploy –parameter-overrides pSSOInstanceId=ssoins-XXXXXX.

AWS IAM Identity Center Permission Sets

You will now have a collection of Identity Center PermissionSets that can be associated with your federated users in member accounts. These cover four common personas.

• AccountManager allows full access to Billing and Cost Management tooling, using the Billing managed policy, for your FinOps team.
• Support allows support teams to audit and troubleshoot in production accounts using the AWSBillingReadOnlyAccess, ViewOnlyAccess, and AWSSupportAccess managed policies. It also has an inline policy defining additional permissions to PassRole for CloudFormation, provide access to ssh into EC2 instances through SSM and perform some administrative functions on stacks.
• Developer is the PermissionSet which will be used by your builders. This also has AWSBillingReadOnlyAccess, ViewOnlyAccess, and AWSSupportAccess managed policies. This PermissionSet should include any access your builders will need for their deployment tooling. In this case, we are granting AWSProtonDeveloperAccess to create and deploy AWS Proton services. In addition, DeveloperAccess includes an inline policy allowing use of CloudFormation for stacks under your specified developer prefix namespace and ability to create an S3 bucket for their CloudFormation templates and upload templates into that bucket. It also allows developers to pass the CloudFormationRole, created by the template, to CloudFormation. This role allows developers broad deployment permissions via CloudFormation but constrained by a PermissionsBoundary to prevent privilege escalation.

For builders to use the DeveloperAccess permission set, they must adhere to specific guidelines. Developer created CloudFormation stack names must begin with the pDeveloperPrefix value provided in the template (defaults to app). An example CloudFormation stack name could be app-users-service. Builders also have the ability to create IAM roles in their own CloudFormation, as long as the IAM role path begins with the same prefix (app/MyLambdaRole is a valid path and role name). The DeveloperBoundary IAM permission boundary policy includes an overly permissive list of services to allow your builders access to. By default, the template includes

Sid: OverlyPermissiveAllowedServices
Effect: Allow
Action:
  - "lambda:*"
   - "apigateway:*"
  - "events:*"
  - "s3:*"
  - "cloudwatch:*"
   - "logs:*"
Resource: "*"

This allows access to AWS Lambda, Amazon API Gateway, Amazon EventBridge, Amazon S3, Amazon CloudWatch, and Amazon CloudWatch Logs. The permission boundary doesn’t grant access to these services, it only allows a builder to make use of these services within their own templates. You can customize this list of services to the recommended (or approved) services you want builders to use within your company.

Here’s an example to help you understand how to use the ShellAccess permission set and SSM to gain shell access to the EC2 instance in a private subnet.

# Configure the AWS CLI to access IAM Identity Center (one-time setup)
aws configure sso
# Login using the profile defined above
aws login sso --profile <my_profile_name>
# Start a new SSM session to the EC2 instance
aws --profile <my_profile_name> ssm start-session target <ec2_instance_id> --document-name SSM-SessionManagerRunShell

Conclusion

This blog post provides SMBs with a simple yet robust baseline AWS Organizations structure with OUs, roles, service control policies in line with AWS best practices; all set up using Infrastructure as Code (IaC). We also set up an IAM Identity Center instance to provide workforce access for this organization. With this multi-account environment set up, SMBs are now set up with a strong foundation and have central governance, compliance, and security controls across their AWS environment to meet the challenges of their evolving business needs.

Starting with the approach discussed in this blog post, you can have the flexibility to continue building on top of this multi-account environment as your need grows. You can also migrate to AWS Control Tower, a managed service that provides prescriptive management of your multiple accounts along with helping you orchestrate and manage cloud governance services in the future. Read establish your initial foundation with AWS Control Tower for more information.

To further improve your operations and security posture, you can leverage AWS services such as AWS Config, AWS Security Hub, AWS Systems Manager that integrate with AWS Organizations. We recommend you take a free, self-paced security training to learn more. You can also keep expanding your environment for additional use-cases, which you can read about in the Organizing Your AWS Environment Using Multiple Accounts.

To learn how to scale globally and improve reliability, read how Clearwater Analytics were able to successfully grow and manage 200% more resources using AWS Organizations and other services.

We can’t wait to see what you build next!

About the authors