Defining an AWS Multi-Account Strategy for telecommunications companies

Amazon Web Services (AWS) is enabling Communications Service Providers (CSPs) to achieve huge gains in productivity, innovation, and cost reduction, at the same time that they build their SI capabilities through their B2B business. AWS offers a variety of services and features that allow for flexible control of cloud computing resources and services as well as tools to manage the AWS accounts from which these are deployed.

In this blog post, we show account-level considerations, best practices, and high-level strategic guidance to help CSPs use AWS Organizations service to structure and manage several AWS accounts.

For a CSP, there are plenty of benefits from using more than one AWS account:

• An administrative or operational boundary: The CSP can implement multiple AWS accounts to define boundaries between internal departments and organizations. Ex: AWS accounts for B2B team, AWS accounts for network team, AWS accounts for Digital team, etc.
• A billing entity: Some CSPs also operate in multiple countries having a distributed operation that may require separated invoices for each Operating Company (OpCo).
• CSP as an APN Partner: the CSPs may have a B2B organization and be part of the AWS Partner Network (APN) where they provide hardware, connectivity services, or software solutions that are either hosted on, or integrated with, the AWS Cloud. In other scenarios the CSPs help customers of all types and sizes design, architect, build, migrate, and manage their workloads and applications on AWS, accelerating their journey to the cloud
• Workload and security boundary: CSPs can use AWS account service limits to impose restrictions on a particular business unit, development team, project or to set administrative controls over their AWS resources to isolate accounts based on the workload, development lifecycle, BU, or data sensitivity.
• Cost control: Detailed bills are generated at an account level. An account has higher “granularity” that is enabled by billing tags that enable tracking vs budgets for specific projects, areas or customers.

Before starting with best practices strategies, let’s review some concepts of the AWS Organizations service that are key for the purpose of this post:

Organization:

An entity that you create to consolidate your AWS accounts so that you can administer them as a single unit. You can use the AWS Organizations console to centrally view and manage all of your accounts within your organization. An organization has one master account along with zero or more member accounts. You can organize the accounts in a hierarchical, tree-like structure with a root at the top and organizational units nested under the root. Each account can be directly in the root, or placed in one of the OUs in the hierarchy. An organization has the functionality that is determined by the feature set that you enable.

Root:

The parent container for all the accounts for your organization. If you apply a policy to the root, it applies to all organizational units (OUs) and accounts in the organization.

Currently, you can have only one root. AWS Organizations automatically creates it for you when you create an organization.

Organization unit (OU):

A container for accounts within a root. An OU also can contain other OUs, enabling you to create a hierarchy that resembles an upside-down tree, with a root at the top and branches of OUs that reach down, ending in accounts that are the leaves of the tree. When you attach a policy to one of the nodes in the hierarchy, it flows down and affects all the branches (OUs) and leaves (accounts) beneath it. An OU can have exactly one parent, and currently each account can be a member of exactly one OU.

Account:

A standard AWS account that contains your AWS resources. You can attach a policy to an account to apply controls to only that one account.
There are two types of accounts in an organization: a single account that is designated as the master account, and member accounts.

• The master account is the account that creates the organization. From the organization’s master account, you can do the following:
  • Create accounts in the organization
  • Invite other existing accounts to the organization
  • Remove accounts from the organization
  • Manage invitations
  • Apply policies to entities (roots, OUs, or accounts) within the organization

The master account has the responsibilities of a payer account and is responsible for paying all charges that are accrued by the member accounts. You can’t change an organization’s master account.

• The rest of the accounts that belong to an organization are called member accounts. An account can be a member of only one organization at a time.

Landing Zone:

A landing zone is a well-architected, multi-account AWS environment that’s based on security and compliance best practices. It provides a baseline to get started with multi-account architecture, IAM, governance, data security, network design, and logging.

Consolidated Billing:

AWS Organizations provides consolidated billing, which allows you set up a single payment method in the organization’s master account and receive one invoice with the details of individual activity in each member account.

AWS Control Tower:

AWS Control Tower provides the easiest way to set up and govern a new, secure, multi-account AWS environment based on best practices established through AWS experience working with thousands of enterprises as they move to the cloud.

If you answer “yes” to any of the following questions, it is a good indication that you might want to structure your AWS accounts using AWS Organizations:

• Do you want to reuse a billing or payment instrument (e.g. credit card or purchase order) to pay for multiple AWS accounts?
• Do you want to maximize your potential volume, Reserved Instances (RI) or, Savings Plans discounts  by aggregating AWS resource usage and spreading any applicable discounts across multiple accounts?

CSPs and internal workloads:

While there is no one-size-fits-all answer for how many separated AWS Organizations a particular CSP should have, most companies want to create at least one AWS Organization with multiple AWS accounts for their internal workloads.

Depending on each CSPs structure and needs, implementing a single AWS Organization for internal workloads sometimes is not enough. Answering “yes” to any of the following questions is a good indication that you should create additional AWS Organizations for the internal workloads:

• Does the business require strong fiscal and budgetary billing with different payments methods or separated invoices for each department?

In this case, create an AWS Organization for each department.

• Does the business operate in multiple countries where each operation requires a specific payment method or separated invoices?

In this case, create an AWS Organization for each operating company (OpCo).

For internal workloads, the design of Organizational Units (OUs) and account structures can follow a strategy based on CSPs organizational, operational, or cost structure. For example:

CSPs and B2B workloads:

CSPs may have a “Business Solutions” or B2B organization by which they provide hardware, connectivity services, or software solutions that are either hosted on, or integrated with, the AWS Cloud. In general, it is recommended that CSPs will need to create a separate AWS Organization for each of the following cases:

• •  CSP as an APN Consulting partner: If CSP is part of APN and is part of AWS Solution Provider Program (SPP) authorized to manage, service, support, and bill AWS accounts and resell AWS services for end-customers, then it is necessary to create a new AWS Organization for this usage and create AWS accounts for each of these end-customers.
  • CSPs offering B2B multi-tenant packaged solutions: As an administrative boundary, it is recommended to create an AWS Organization to manage each of the multi-tenant packaged solutions. (ex. Multi-tenant backup solution, Multi-tenant Unified Communication solution, etc.).
  • CSPs serving end-customers with their own landing zone or requiring a dedicated master payer account: Depending on the size, complexity and needs of the end-customer, and the requirements of the solution provided, CSPs may need to create a single AWS Organization for those specific end-customers.
  • CSPs offering AWS with different support levels and models: In case the CSP offers Partner-Led Support, resells Enterprise Support or has AWS accounts with different support levels (ex. Business vs Enterprise), it is necessary to create different AWS Organizations for each support level.

Enterprise support considerations:

The AWS Solution Provider Program (SPP) enables qualified partners to resell AWS services, including AWS Support. Approved Solution Providers who offer Partner-led Support are backed by the AWS Support Organization. The AWS Solution Provider and AWS Support work together to make sure you can benefit from the knowledge and services of the Solution Provider and the expertise of AWS Support Agents.

There are some differences between AWS provided Support and Partner-led Support. For example, with Partner-led Support, all customer support cases are opened directly with the Solution Provider. The solution provider will troubleshoot and resolve support cases directly with an end-user and escalate, as necessary, to AWS Support.

If the CSP is offering Partner-Led Support or reselling Enterprise Support it is necessary to create separated AWS Organizations.

AMS considerations:

As enterprise customers move towards adopting the cloud at scale, some find their people need help and time to gain AWS skills and experience. AWS Managed Services (AMS) operates AWS on your behalf, providing a secure and compliant AWS Landing Zone, a proven enterprise operating model, on-going cost optimization, day-to-day infrastructure management, security control and compliance control.

When a CSP is an authorized AWS Managed Services partner, they will need to create separated AWS Organizations for this purpose.

Conclusion:

There is no one-size-fits-all approach for how many separated AWS Organizations or AWS accounts a particular CSP should have. The different cases described before should be helpful when considering the multiple variables in order to define the most appropriate AWS Multi-Account strategy for your specific case and needs.

It is important to consider that, as the number of AWS accounts within the AWS Organization grows, CSPs need to structure their governance to grow and scale. To help you with this, AWS has developed AWS Governance at Scale whitepaper to help identify and instantiate best practices.

To get guidance regarding your particular situation, please contact your AWS account team. If you don’t have an AWS account team, contact Sales.