AWS Partner Network (APN) Blog

AWS Control Tower Best Practices for AWS Solution Providers

By Josh DeMuth, Partner Solutions Architect at AWS
By Fritz McCormick, Sr. Partner Development Manager at AWS

AWS-Solution-Provider-Program-1

If you’re an AWS Consulting Partner in the AWS Solution Provider Program, you may have customers that need a multi-account architecture.

While this can be done within a multi-customer AWS Organization by giving customers isolated Organizational Units (OUs), there are scenarios where this is not possible. The most prevalent scenario we’ve seen recently is the customer’s desire to leverage AWS Control Tower.

In this post, we will detail the approach for a Solution Provider Program customer to leverage AWS Control Tower. First, we’ll give a quick overview of how the Solution Provider Program and Control Tower relate, and then we’ll detail how to make the process work from onboarding to ongoing operations.

For this post, there is an assumption you are familiar with AWS Organizations terms and concepts.

AWS Solution Provider Program Overview

The AWS Solution Provider Program is designed for Systems Integrators, Managed Service Providers (MSPs), Value-Added Resellers, and Public Sector Partners to resell AWS services to end customers as part of their differentiated solution.

Under this program, Authorized Solution Providers manage, service, support, and bill AWS accounts for end customers.

There are two account ownership models within the Solution Provider Program: End-Customer Account Model, and Solution Provider Account Model.

In both models, the AWS Partner is responsible for the billing across all accounts. The models differ when considering account ownership. An owner is defined as what entity has agreed to the AWS Customer Agreement and owns the root user email address.

Solution-Providers-Control-Tower-1

Figure 1 – Comparing the two Solution Provider Program account models.

Solution Providers and AWS Organizations

The backbone of Solution Provider Program billing is AWS Organizations Consolidated Billing. The Partner is open to choose their preferred account architecture within AWS Organizations, including:

  • Leverage a single AWS Organization for a multi-customer architecture. There would be a single payer for all customers in this structure.
  • Have a separate AWS Organization for each customer. In this structure, the Partner would have multiple payer accounts within their Solution Provider Program setup.
  • Or, there can be a mix of multi-customer Organizations and single-customer Organizations. This structure would also have multiple payer accounts and one per Organization.

The account approach is typically based on customer requirements or the Partner’s backend billing preferences. All account architectures would require the Partner to own the Organizations management account. The Solution Provider Program account model would determine what entity owns the child accounts.

The Partner is required to onboard each payer account separately into the Solution Provider Program.

For the remainder of this post, we’ll focus on how leveraging AWS Control Tower will drive AWS Organizations architecture decisions.

AWS Control Tower Overview

Customers are increasingly adopting a multi-account strategy because an AWS account can act as a resource container to segregate workloads, development lifecycles, access patterns, billing controls, and more. Learn more about multi-account best practices.

AWS Control Tower provides the easiest way to set up and govern a secure, multi-account AWS environment.

Solution Providers and AWS Control Tower

Since both the Solution Provider Program and AWS Control Tower leverage AWS Organizations, we need to understand where requirements intersect.

The Solution Provider Program features that relate to Control Tower are:

  • Partner must own the payer.
  • Payer is tied to either the End-Customer Account Model or the Solution Provider Account Model.
  • Partner can have multiple payers of each type.
  • Partner can create accounts on behalf of a customer in the End-Customer Account Model and still have those accounts owned by the customer.

Control Tower features that relate to the Solution Provider Program are:

  • Deployed within an Organizations management account, which is also the payer account.
  • To manage Control Tower, a customer needs access to the payer account.
  • The email domain of child accounts, including the logging and audit accounts, can be different from the management account.

For the Solution Provider Account Model, the main consideration is if the Partner will have a single-customer or multi-customer Control Tower. If single-customer, then a separate payer account is needed for each customer.

The Partner can use Control Tower to manage the landing zone for a multi-customer architecture since the Partner will own and manage all accounts.

For the End-Customer Account Model, the Partner must run a single-customer setup since the customer would manage their own Control Tower.

Best Practices

There are two areas of focus to ensure success leveraging AWS Control Tower within the Solution Provider Program: onboarding and operations.

Onboarding

The onboarding process for a new customer into the Solution Provider Program depends on several factors:

  • Is the customer onboarding under the End-Customer Account Model or the Solution Provider Account Model?
  • Does the customer have existing account(s)?
  • Are the accounts already part of an existing AWS Organization?
  • Is the existing payer account transitioning to the Solution Provider Program?
  • Do the existing accounts have any AWS Organizations-wide AWS Artifact agreements?
  • Do you plan to deploy AWS Control Tower?

No Existing Accounts

If the customer is starting fresh without any existing accounts, the process is straightforward. The Partner is required to own the payer account, so the Partner creates a new account under their email address, agrees to the AWS Customer Agreement, and links this new payer account into their SPP.

At this point, AWS Control Tower can be deployed, and depending on which Solution Provider Program account model is used, the appropriate email address domains should be used in the log archive and audit accounts.

Existing Accounts

If the customer has existing accounts, we need to understand if the customer has an existing AWS Organization, Control Tower deployed, or if it’s just a standalone account.

Existing Organization

If there’s an existing Organization but no Control Tower deployed, there are several options and it’s out of scope of this post to give a formal recommendation

The options include:

  • Creating a new payer account and having all existing accounts leave the existing Organization and join the new one owned by the Partner. There are operational considerations with this approach.
  • Transferring ownership of the existing payer account to the Partner, and then deploying Control Tower into that account.

We recommend reaching out to your AWS Partner Network (APN) development team for more information on these options.

Control Tower Exists

If AWS Control Tower already exists, the recommended approach is for the customer to transfer ownership of at least the management account over to the Partner. This can be done through the ownership transfer process. This change is behind-the-scenes and would not impact any active workloads.

Under the End-Customer Account Model, the account ownership requirement is for the Partner to own the payer account. So, if Control Tower already exists, the only account that would need to transfer is the management account. All other accounts can remain as-is (i.e. owned by the customer).

Under the Solution Provider Account Model, all accounts would need to be transferred to partner ownership.

It’s possible for the Partner to create a new payer account, with a new Control Tower deployment, and transfer accounts over to the new one. However, breaking up a Control Tower setup and adding to a new one would require upfront work and can impact historical billing.

The least disruptive path is to perform the ownership transfer behind the scenes, which does not impact any existing workloads, including existing Service Control Policies.

Standalone Account

Follow these instructions to enroll a standalone account directly into Control Tower.

AWS Artifact Agreements

If the customer has existing AWS Artifact agreements:

  • Under the End-Customer Account Model, they will transition with the non-payer child accounts as long as digitally signed.
  • If the agreement is an Organization-wide policy, since Organizations ownership will be transferred, individual agreements may need to be signed in the workload accounts.

Contact your APN representatives for further guidance on specific use cases.

Operations

Once AWS Control Tower is set up and all accounts are owned by the correct entities, there are a few considerations for ongoing operations:

  • Control Tower access
  • Adding new accounts
  • Cost visibility

Control Tower Access

For the Solution Provider Account Model, it’s business as usual for the Partner since they own all of the accounts and manage Control Tower.

However, the End-Customer Account Model creates a unique scenario where both the Partner and customer will need access to the management account. The Partner will need access for billing and the customer will need access to manage Control Tower.

While it’s recommended to have an admin user deploy Control Tower for the first time, the Partner can limit access to only what is required for the customer to manage it. Learn more about ideas on what the role could look like.

Adding New Accounts

Since the owner of the management account is the Partner, when new accounts are created via Control Tower Account Factory (or AWS Service Catalog), the Partner creates that account.

However, when customers onboard to the Solution Provider Program, they are able to give the Partner permissions to create new accounts on their behalf.

The customer would provide written approval for the Partner to do this, and as long as the customer’s name is on the new AWS account and the root email address is in the customer’s email domain, the customer would effectively be signing the AWS Customer Agreement under the End-Customer Account Model.

The customer can also create a new standalone account and enroll into Control Tower.

Cost Visibility

Another consideration is that since the customer will need access to management account for Control Tower, access is needed to the payer account. The Partner should limit the customer’s role from accessing AWS Cost Explorer if the Partner doesn’t want the customer to see any margins.

Conclusion

As AWS Control Tower is adopted more and more, it’s important that AWS Consulting Partners within the AWS Solution Provider Program can leverage the multi-account benefits Control Tower offers.

We learned in this post that the Solution Provider Program is flexible in the types of customer models it allows. This flexibility serves the end customer’s business needs. However, Partners must take care in how they architect AWS Organizations for their customers, which directly impacts the use of Control Tower.

Solution Provider Program Partners should collect a detailed customer profile of current accounts and AWS usage models. This knowledge will drive best practices during onboarding and operations phases, enabling a positive customer outcome. This approach supports the successful use of Control Tower and creates a platform for adding new accounts and maintaining billing controls.

For more information about the AWS Solution Provider Program, visit the program page. For more information about AWS Control Tower, visit the product page or try it for yourself in the AWS Management Console.