Guides

Onboarding Multiple AWS Member Accounts from a Management Account using AWS StackSets

Save time and streamline your onboarding process for multiple AWS cloud accounts by setting things up for bulk onboarding.

Suggest Edits

🚧

Note:

AWS management and member accounts were formerly known as master and linked accounts, respectively. Some areas in the platform UI may still use the old naming conventions.

This user guide uses the latest naming conventions as per AWS. We appreciate your patience while we update the platform UI to align with this.

Introduction

When it comes to onboarding multiple AWS member accounts into CoreStack, it’s certainly possible to do it one at a time, but you can save a lot of time and streamline that process by following the procedure described in this document. This approach uses AWS CloudFormation templates and the AWS CloudFormation StackSets service to onboard multiple AWS member accounts through your AWS management account.

While this process is relatively straightforward, it does require users to do things in a particular order and create IAM access roles for CoreStack across both management and member accounts using automation services.

In this user guide we’ll walk you through the process of doing that, as well as explain the options you have for using automation templates and creating IAM roles for CoreStack in your AWS accounts so you can decide which approach is right for you.

Overview of the end-to-end process for onboarding multiple AWS accounts

Before you can start onboarding multiple member accounts into CoreStack, IAM roles need to be created in both the management account (by a user) and all member accounts (by automation). This will provide CoreStack with the access it needs to assume the necessary roles in your AWS accounts.

To do this, you can use the AWS Service known as AWS CloudFormation StackSets to create and manage this access at scale.

Once this is completed, you can use the bulk account onboarding feature/utility in CoreStack to onboard these accounts into CoreStack.

From that point onward, you can continue to manage the IAM access for CoreStack in your AWS accounts by updating and re-running StackSets. You can also add/revoke access to additional cloud accounts to enable continuous onboarding.

This process is summarized at a high-level in the below graphic, and in the following short summaries provided for each step:

Step 1: Create an IAM role in your AWS management account

The first step in this process of onboarding multiple member accounts always begins with the AWS management account. First, ensure you have Administrator Access in your AWS management account – you’ll need it to create the necessary IAM role for CoreStack.

📘

Note:

You will not be required to provide Admin Access to CoreStack.

Using your Administrator access, you can create an IAM Role using the least privilege access CloudFormation template provided in the management account onboarding section of this user guide. This will allow CoreStack to assume a role in your AWS management account that only has the required access level specified in the aforementioned CloudFormation template. This least privilege access template limits CoreStack to Read-Only permissions in the AWS services it needs access to.

Additionally:

  • If you plan to use CoreStack FinOps and have a centralized billing CUR file in an S3 bucket, keep those bucket details on-hand.
  • You will also need to create an additional role in your AWS management account for AWS StackSets (CloudFormation) to assume roles in your member accounts. This can be done in Step 3, based on level of control and flexibility you want to provide to AWS Stacksets.

Step 2: Onboard your AWS management account into CoreStack

Next, in the CoreStack Portal, you’ll onboard your AWS management account using the steps provided later in this user guide. This will start the onboarding process, which includes discovery of all your member accounts, inventory in your management account, running system policies, processing cost data, and more based on which CoreStack products you have access to.

Once your management account is onboarded and this discovery is completed for your AWS member accounts, you should be able to see basic details (i.e. cost posture) about them in CoreStack portal. However, you cannot onboard the member accounts yet since CoreStack doesn’t have the necessary level of access to them. This will be done in Step 3.

Without onboarding member accounts, CoreStack will not have the required data to provide capabilities such as Inventory, Cost Optimizations, Budgets, policies etc. for the member accounts.

Step 3: Create IAM roles in your member accounts using StackSets

Using AWS StackSets, you can grant CoreStack access into multiple member accounts in your AWS Organization. Based on your organization policy and control needs, you can choose from the following options:

  1. Service-Managed option (Recommended): If you want to automatically provide access to CoreStack as new member accounts are added into your AWS Organization under your Organization Units (OUs), then this is the ideal option to choose when creating a StackSet.

The downside of this approach is that a new role will be created with admin access (for AWS CloudFormation service, not CoreStack) in each member account, which may cause security alerts based on your organization’s policy.

This is a well-documented approach from AWS for using StackSets. Also, for this option to work fully, you need to enable trusted access for AWS StackSets in your management account.

  1. Self-Managed option: If you want more control over when to provide access to CoreStack for new member accounts, or for specific member accounts, you can choose this option when creating a StackSet.

For this to work, you need to create an additional (service linked) role named “AWSCloudFormationStackSetAdministrationRole” in your AWS management account and allow the AWS CloudFormation service to assume the OrganizationAccountAccessRole role in the member accounts you want to provide access to. The OrganizationAccountAccessRole role is created by default as part of the AWS organization setup, so no new roles will be created in your member accounts.

With this approach, any time you want to give CoreStack access to more member accounts, you can manually update the StackSet and provide the additional member account IDs. You can also create new StackSets with a new set of member accounts IDs.

📘

Note:

Depending on what you prefer, you can create a StackSet that includes all member accounts to provide CoreStack with access to all or create multiple StackSets to grant CoreStack access to only a few accounts at a time.

You can even grant different levels of permissions for different sets of AWS accounts/OUs. For example, you could provide CoreStack with Read-Write access to your development OU but Least-Privilege Access to Production accounts.

The outcome of this third stage is that a role will be created in each of the member accounts that provides required access to CoreStack. Role ARNs and External IDs will be available for each of the member account as outputs of the StackSet deployment.

Step 4: Onboard member accounts into CoreStack using a bulk upload feature

Now that the necessary access permissions have been created, you can proceed with the process for onboarding your member accounts into CoreStack.

Currently, CoreStack provides a utility to accomplish this. You can contact your Customer Success Manager to learn more and get access to this utility.

Step 5: Manage IAM access over time by updating StackSets

On an ongoing basis, if you plan to update the access given to CoreStack in your AWS accounts, onboard a new set of accounts, or revoke access to a set of accounts, you can do so by updating the appropriate StackSet.

This provides a great amount of control and flexibility for you and your customers, and simplifies the process of onboarding multiple accounts to CoreStack for visibility and governance.

Configure an AWS Management Account for onboarding

Before users can onboard an AWS management account, they must first create an IAM role for CoreStack to have the required access to their AWS accounts.

This role can be created manually in AWS, but it can be done more easily by running a CloudFormation template known as a Stack. Once this template is done executing, the information it outputs can be used to onboard the cloud account into CoreStack.

CoreStack provides CloudFormation templates that will take care of the process of creating the required IAM role and assigning the necessary permissions automatically. These templates use the native roles already available in your AWS account to create an access role for CoreStack to use – preserving your security and limiting CoreStack’s access to only certain kinds of data.

The required IAM role must be created with the following access permissions depending on which type of cloud account users want to onboard:

  • For Assessment onboarding: Read-Only Access.
  • For Assessment + Governance onboarding: Read-Write Access.

The previously mentioned CloudFormation templates can be downloaded by clicking the S3 URLs provided below, based on the type of access you wish to provide for CoreStack:

  • S3 URL with Template for Assessment Only (Read-Only Access): Download here
  • S3 URL with Template for Assessment + Automation (Read-Write Access): Download here

Setting Up the IAM Role:

  1. Log in to the AWS account.

  2. Navigate to CloudFormation.

  3. Click Create Stack with new resources.

  4. Select the Template is ready option in the Prepare template field.

  5. Select the Amazon S3 URL option in the Template source field.

  6. Copy the relevant S3 URL from the above section and paste it in the Amazon S3 URL text field.

  7. Click Next.

  1. Provide values for the Stack name and Role name fields. If you have used the Amazon S3 template URL for Read-Write Access, you can view additional fields that can keep their default values. However, if you do NOT want to configure CFN, GuardDuty, or Inspector for your AWS account, you can set them to “false”.

  1. Click Next. The Step 3 screen appears.

  2. You can leave the values for the fields in this screen as their defaults or make changes as necessary, including assigning Tags, providing notification options, etc.

  1. Click Next. The Step 4 screen appears.

  2. The information provided in all the steps will be displayed. After reviewing the provided information for correctness, scroll down to the end of the screen and click on the acknowledge checkbox.

  1. Click Submit. The stack creation process will now be initiated, and the status should be visible.
  1. Navigate to the Stack Info tab to see an overview of the stack as well as the final status.

  1. Click the Refresh icon to retrieve the latest status. When it is successfully completed, you will see the status change to “CREATE_COMPLETE”.

  2. Navigate to the Outputs tab to view the access credentials (ARN).

These credentials contain the information required to onboard new cloud accounts into CoreStack. Copy this information and have it readily available so you’ll be able to easily copy and paste it into the CoreStack UI while onboarding.

Onboard AWS management account in Corestack:

The following steps need to be performed to onboard an AWS management account into CoreStack.

🚧

Note:

In the CoreStack UI, the former terminology for AWS account names may be used in some places.

Anything referring to a Master Account should be used for Management Accounts, and anything referring to a Linked Account should be used for Member Accounts.

  1. Once logged in to CoreStack, click the Add New button in the Account Governance dashboard and select Single Account, then click Start Now. The onboarding screen appears.
  1. Select the AWS option in the Public Cloud field.

  1. Click the Get Started button.

  2. Select the required option in the Access Type field: Assessment or Assessment + Governance.

  3. Select the Master Account option in the Account Type field.

  4. Select the required option in the AWS Environment field. The options are: AWS Standard and AWS Gov Cloud.

  5. Select the required option in the Authentication Protocol field. The options are: Assume Role and Access Key.

  6. Click Next.

  1. Provide the necessary details (Amazon Resource Name ID (ARN), External ID, & MFA Enabled OR Access Key & Secret Key) explained in the Pre-onboarding section based on the option selected in the Authentication Protocol field.

  1. Click Validate.

  2. The Advanced Settings section will be displayed with additional fields (Name, bucket details, Preferred Regions, and Scope).

  3. Modify the pre-populated name of the account in the Name field, if required.

  4. Specify the name of the S3 bucket to be used for storing cost reports in the Bucket Name field.

  5. Select the required option in the Cost Report Format field. The options are: Standard and Amazon Athena. Choose Standard or Athena based on how your cost reports are configured. The default option is Standard, where your cost reports are placed as a CSV file in an S3 bucket.

  6. Select the required regions in the Preferred Regions drop-down list. Multiple regions can be selected.

  7. Select the required option in the Scope field. The options are: Account, Private, and Tenant.

  8. Click the I’m Done button.

Once done, the AWS management account will be onboarded successfully into CoreStack. The relevant insights and information about the resources available in the cloud account will be populated for each onboarded account in the Account Governance dashboard.

Configure multiple AWS member accounts for onboarding from a management account

As mentioned at the start of this user guide, onboarding individual AWS member accounts into CoreStack one at a time is possible, but it can save a lot of time and effort to onboard multiple AWS member accounts through your AWS management account.

Again, this requires creating IAM roles for CoreStack to use to access the required data across each of your AWS member accounts. This can be done manually, or in an automated way with CloudFormation templates called Stacks/StackSets.

📘

Note:

To create IAM roles across each of your AWS member accounts through your AWS management account, you need to first create an IAM role for CoreStack in the management account.

Please refer to the previous section Configure and onboard an AWS Management Account for instructions on how to do this.

It’s much more efficient and can help mitigate security concerns if you use AWS CloudFormation StackSets to create and run multiple stack templates with a single operation. This will use the native OrganizationOwnerAdmin role available by default in your AWS account to create the necessary IAM access roles for CoreStack – not create any new admin roles.

By taking this approach, then using a utility we provide to onboard multiple cloud accounts at once into the CoreStack platform, you can streamline the process of onboarding AWS member accounts into CoreStack without needing to make any major changes to the roles and permissions in your AWS account.

Validate AWS Organization account enabled with all features

AWS has introduced a new setting to configure your organization's management account as an all features or Consolidated Billing account.

To follow the forthcoming steps, your organization's account must be configured as an all features account. To check if your account is configured as an all features account, you can navigate to your AWS Organization account and then click Settings. Under organization details, you can see a message as shown in the image below.

If your organization is only enabled with the Consolidated Billing feature, you can refer to the link provided below to enable all features: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html

Enable trusted access using the AWS CloudFormation console

As a first step, users need to enable trusted access for StackSets in the relevant AWS Organization Unit(s). With trusted access between StackSets and Organizations enabled, the management account has permissions to create and manage stack sets for your organization (source).

  1. Sign into AWS as an administrator in the related management account and open the AWS CloudFormation console at https://console.aws.amazon.com/.

  2. From the navigation pane, choose StackSets. If trusted access is disabled, a banner displays that prompts you to enable trusted access.

  1. Choose to Enable trusted access.

You’ll know trusted access is successfully enabled when the following banner displays:

📘

Side note:

If you want to use a member account to run a StackSet, it should be set as a Delegated Administrator.

To register a member account as a delegated administrator (from the AWS console):

  1. Sign into AWS as an administrator of the selected member account and open the AWS CloudFormation console from the link below,

https://console.aws.amazon.com/cloudformation/.

  1. From the navigation pane, choose StackSets.

  2. Under Delegated administrators, choose Register delegated administrator.

  3. In the Register delegated administrator dialog box, choose Register delegated administrator.

The success message indicates that the member account has successfully been registered as a delegated administrator.

Run the StackSet in member accounts using the management account

Now that trusted access is enabled between the StackSet service and the member accounts, users can proceed with running the StackSet to create the necessary IAM roles for in the member accounts and generate the outputs needed for onboarding.

Login to the management account and navigate to CloudFormation.

Select Create StackSet:

There are two ways to run StackSets, as referred to in the diagram included at the start of this user guide:

  • Service-managed permissions approach
  • Self-service permissions approach

Run a StackSet with service-managed approach

Creating the StackSet with this methodology will create an IAM role in each member account for the StackSet service (not CoreStack) to use that has administrator access. This allows the StackSet to deploy stacks in the member accounts.

After selecting to Create StackSet, select the proper box to proceed with Service-managed permissions.

In the Amazon S3 URL field, input a CloudFormation template path, then click Next.

As mentioned earlier in this user guide, you can download a CloudFormation template or get the web address by clicking the S3 URLs provided below, based on the type of access you wish to provide for CoreStack:

  • S3 URL with Template for Assessment Only (Read-Only Access): Download here
  • S3 URL with Template for Assessment + Automation (Read-Write Access): Download here

Next, enter a StackSet Name in the field with the same title:

Enter values for the ExtenalID and Role Name (ARN), which need to be created for the member accounts.

Enter any required tags, then select Execution Configuration.

  • Inactive: Run this stack only one time.
  • Active: Run this stack for an account and add it as a member account under this management account in the future.

Select Deploy new stacks.

Select the Deployment Targets:

Deploy to Organization – Deploy the CloudFormation template for all the member accounts under the management account.

Deploy to Organizational Units (OUs) – Deploy the CloudFormation template for user-specified OU accounts.

The below screenshot shows an example for an account under an OU.

Next, select the region where the CloudFormation template must run.

Click to acknowledge and finish the process in order to run the CloudFormation stack set on the member accounts.

Now you should be able to see the stack set is Active, once the run is successful.

In the member accounts, you can see the stack under CloudFormation in the region you selected previously.

Run a StackSet with the self-service approach

Creating the StackSet with this methodology will not create any new IAM roles for the StackSet service in the member accounts. Instead, it proceeds by assuming an existing AWS role with administrator access in each member account. This allows the StackSet to deploy stacks in the member accounts without creating a new IAM role.

Prerequisites:

  • There needs to be an assumed role created in the management account along with a custom policy enabled. And the policy with the role name “OrganizationAccountAccessRole” should be customizable.
  • By default, in a member account, when creating an account an IAM role will get created named “OrganizationAccountAccessRole.” This name can be customized. CoreStack will use this role to run stack sets.

After selecting Create StackSet, select the proper box to proceed with Self-service permissions.

After selecting Self-service permissions, we need to provide the “IAM execution role name” as “OrganizationAccountAccessRole.”

In the Amazon S3 URL field, input a CloudFormation template path, then click Next.

As mentioned earlier in this user guide, you can download a CloudFormation template or get the web address by clicking the S3 URLs provided below, based on the type of access you wish to provide for CoreStack:

  • S3 URL with Template for Assessment Only (Read-Only Access): Download here
  • S3 URL with Template for Assessment + Automation (Read-Write Access): Download here

Next, enter a StackSet Name in the field with the same title:

Enter values for the ExtenalID and Role Name (ARN), which need to be created for the member accounts.

Enter any required tags, then select Execution Configuration.

  • Inactive: Run this stack only one time.
  • Active: Run this stack for an account and add it as a member account under this management account in the future.

Select Deploy new stacks.

Select the Accounts:

Deploy stacks in accounts – Upload a CSV file with the relevant accounts listed by Account ID, or enter the account numbers in the text box separated by commas.

Deploy stacks to Organization Units (OUs) – Enter the desired OU ID. Please note that only one OU can be executed at a time.

Here is a sample OU:

Select the region where the CloudFormation template must run.

Click to acknowledge and finish the process in order to run the CloudFormation stack set on the member accounts.

Now you should be able to see the stack set is Active, once the run is successful.

In the member accounts, you can see the stack under CloudFormation in the region you selected previously.

📘

Example:

If you are using an ExternalID of “Corestack_demo” and a Role ARN of “Corestack_onboard” for account ids“111111111111” and “222222222222”, your template outputs will be “Corestack_demo” as the ExternalID for both member accounts.

The Role ARNs will be:

arn:aws:iam::111111111111:role/Corestack_onboard

arn:aws:iam::222222222222:role/Corestack_onboard

Onboard multiple AWS member accounts in CoreStack

Once the initial configurations are done and the IAM roles created, users can proceed to onboard their member account sin bulk in the CoreStack portal.

Currently, bulk onboarding for AWS member accounts is available through a utility provided by CoreStack.

To learn more about this utility and how you can get access to it, please contact your Customer Success Manager.

Onboard a single AWS member account in CoreStack

The following steps need to be performed to onboard AWS member accounts into CoreStack. The initial steps here are very similar to the process for onboarding an AWS management account.

🚧

Note:

In the CoreStack UI, the former terminology for AWS account names may be used.

Anything referring to a Master Account should be used for Management Accounts, and anything referring to a Linked Account should be used for Member Accounts.

  1. After logging in to CoreStack, click the Add New button in the Account Governance dashboard and select Single Account.

  2. Click Start Now. The onboarding screen appears.

  3. Select AWS option in the Public Cloud field.

  4. Click the Get Started button.

  5. Select the required option in the Access Type field. Assessment or Assessment + Governance.

  6. Select the Linked Account option in the Account Type field.

  7. Select the required option in the AWS Environment field. The options are: AWS Standard and AWS Gov Cloud.

  8. Select the required option in the Authentication Protocol field. The options are: Assume Role and Access Key.

  9. Click Next.

  10. Provide the necessary details (Amazon Resource Name ID (ARN), External ID, & MFA Enabled OR Access Key & Secret Key) explained in the Pre-onboarding section based on the option selected in the Authentication Protocol field.

  11. Click the Validate button.

  12. The Advanced Settings section will be displayed with additional fields (Name, Master Account, Cost Report Access, S3 Bucket URI, Preferred Regions, and Scope).

  13. Modify the pre-populated name of the account in the Name field, if required.

  14. Select the associated AWS Management Account in the Master Account drop-down list. This field will be displayed only while onboarding an AWS Member Account.

  15. Select the required option in the Cost Report Access field. The options are: Master Account, Delegated Account, Current Account, and None.

  • Master Account: This option will enable the cost reports to be gathered in the associated AWS Management Account and utilized by CoreStack. S3 Buckets and Cost & Usage Reports must be configured in the relevant AWS Management Account. The S3 Bucket URI field will not be available for this selection.
  • Delegated Account: This option will enable the cost reports to be gathered in any one of your AWS accounts and utilized by CoreStack. S3 Buckets and Cost & Usage Reports must be configured in the relevant AWS Account.
    Specify the URL of the S3 Bucket in the S3 Bucket URI field.
  • Current Account: This option will enable the cost reports to be gathered in the AWS Account that is being onboarded and utilized by CoreStack. S3 Buckets and Cost & Usage Reports must be configured in the AWS Member Account that is onboarded. Specify the name of the S3 Bucket in the S3 Bucket URI field.
  • None: This option can be used if you do not want to use the cost data of your AWS Member Account. The S3 Bucket URI field will not be available for this selection.

  1. Specify the required S3 Bucket details, as explained above, in the S3 Bucket URI field.

  2. Select the required regions in the Preferred Regions drop-down list. Multiple regions can be selected.

  3. Select the required option in the Scope field. The options are: Account, Private, and Tenant.

  4. Click the I’m Done button.

Updated about 1 year ago