Cloud Account Structure: Part-2 Single Vs Multiple accounts | Top 10 needs for multiple cloud Accounts

Code: C02-P2| Author: Saransundar N | Applies To: AWS | Azure | Google Cloud

In a previous post (part-1), we understood the cloud account overview. Now, we will see Single Vs multiple accounts. To read other relevant posts, click below.

Part-1: Cloud Account overview – AWS Account | Azure Subscription | Google Cloud project
Part-2: Single Vs Multiple Cloud Accounts; Top 10 needs for multiple cloud accounts (WE ARE HERE !)
Part-3: Cloud Account structure and Hierarchy – AWS | Azure | Google Cloud
Part-4: Importance of the AWS root user | Azure account admin | Google Billing account owner

Overview

One of the most common ask is “Should we host all cloud resources in single or multiple accounts?”

Few feel that billing and account management is easy if it is in a single account. There are several risks associated with that as well. It also depends on the volume of the resources that you host, size of the organization(small, mid-size, enterprise) and also the isolation mechanism which you want to do within account.

If not single, what are the areas to be considered to decide the number of cloud accounts? Before we conclude multiple accounts are needed, let’s understand the factors to be considered for planning cloud accounts.

Let’s recap what is Cloud account. A Cloud account is the container for hosting resources like VMs, storage, etc.. and provides administrative capabilities for access and billing.

Public Cloud	AWS	Azure	GCP
Account Name	Account	Subscription	Project

Areas to be considered for Account structure decisions:

Now, it’s time to decide the factors to be considered in Account structure planning for any organization. The below mind map provides high-level insights on the areas to consider let’s use it as a reference.

Area-1:- Organization Structure & Process

An organization might contain several departments or Business units and also focus on business priorities like cloud migration and innovation. The priorities and goals also vary across stakeholders. Refer to the below mindmap.

You can ask this specific question ” Does the business require strong fiscal and budgetary billing isolation between business units/departments, or specific to workloads?”

If the answer to the question is ‘Yes’, then you need to plan effectively for a multi-account strategy. The other important aspect is Data and the IT world revolves around data. We need to strategize the isolation of data based on its sensitivity and also meet its relevant compliance needs.

Area-2: Technical consideration

Application Workloads along with production and non-prod environments play an important role. There are also cases where businesses require administrative isolation between workloads. The most straightforward approach is to isolate accounts based on workloads, environments, and development lifecycle.

Area-3: IT Operations

There are multiple IT operating models and modern practices adopted by today’s organizations. The cloud account structure also has to be aligned with the Ops model viz., CloudOps, DevOps, SecOps, and DataOps. It should also focus on providing least-privileged access to the roles – data scientists, cloud ops engineers, etc… The account structure should also favor and support the operating models for effective delivery.

With these factors in mind, let us understand the need for multiple cloud accounts.

Top 10 needs for adopting multiple cloud accounts:

1. Business structure and process:
   
   Considering you have multiple Business units or product teams or several departments/sectors, it is easy to define distinct accounts. Grouping workloads that have a common business purpose helps to align the ownership and avoid dependencies.
   
   The use of multiple accounts allows you to set up your IT infrastructure in a way that reflects the needs of your business processes or requirements. Today most enterprises want to operate with decentralized control and also avoid conflicts in the way it is managed and secured.
   
   
2. Foundational setup (aka landing zone) and Shared Services:
   
   Setting up a cloud landing zone becomes one of the key activities as part of cloud adoption. A landing zone in simple terms is the foundational setup to host any workloads in the cloud. All the public cloud providers have defined the guidelines to set up the landing zone. A few notable services are AWS Control tower (as service), and Azure enterprise landing zone (as framework). The landing zone covers the major areas viz.,
   
   a. Identity and access management – Describes authentication, authorization mechanisms & storing passwords, secrets in vaults; One of the major aspect also to extend the existing authentication solution from on-premises like Active Directory solution to cloud.
   b. Network topology – Connectivity across cloud networks and on-premise networks; DNS endpoints, network gateways for VPN (Virtual Private Network), Internet, SD-WAN routing, NAT (Network address translation) and so on.
   c. Security services – Auditing and logging; change tracking; Centralized traffic management using firewalls, load balancers, Web Application Firewall (WAF), etc…
   d. Shared services – Contains the resources that are usually shared by all accounts in your organization, such as OS Images or container registries or any centralized repos.
   
   It is always recommended to setup individual account/subscription for the each areas as part of the landing zone for enterprise customers.
   
   
3. Business priorities matter:
   
   In today’s world lot of organization needs to perform Research, development, and testing. This promotes innovation, enhances business agility, and enables them to compete in the market. Disconnected accounts like Sandbox accounts provide developers to experiment better without affecting the existing services. Multiple accounts can be created based on the business needs and can be closed when not in use. This will not have an adverse impact on the production or existing enterprise workloads.
   
   One of the common ask is also “How to automate the multiple sandbox environment account creations and its resource lifecycle?”
   
   Cloud provider like Azure provides multiple subscription offers. Pay-as-you-go or Enterprise with Dev/Test subscription can be effectively utilized for R&D and testing.
   
   
4. Simplified billing for effective Cost Management:
   
   As you are aware, any resource consumption and bills are bounded to the cloud account. Tracking costs at each resource level will help to use the budget allocated effectively and also helps for forecasting.
   
   For instance, consider there are 3 different business units. Each business unit (BU) wants to understand the itemized bills of cloud resources. Allocating one cloud account for each business unit (BU) will simplify the process and also helps the business owners to track the allocated budgets.
   
   Therefore, consider individual accounts for businesses that require strong fiscal and budgetary billing isolation between cost centers or business units. This might be helpful in other scenarios like using different payment methods to pay different accounts.
   
   Note: Even though tagging each resource under single account helps to find the actual consumption across BUs, there are cases where resources don’t support tagging.
   
   
5. Data Isolation with restricted access:
   
   There is always a mandate to safeguard highly sensitive and confidential or private data. This should not be exposed to unauthorized persons. The strategy is to isolate data stores into an account. This also helps to limit the number of people who have access to data and can manage the data store effectively.
   
   For example, restricting publicly accessible object storage like AWS S3, and Azure Blob might need to be implemented. Most of the PaaS services are accessible with public endpoints. Customers ask to disable public endpoints for specific workloads and use them only through private networks. It becomes necessary to block public endpoints for applicable resources at the specific cloud account level.
   
   
6. Reduce the blast radius:
   
   “Too many cooks, spoil the broth” is the saying. Too many workloads in a single account create risks and if things go wrong, the entire workload gets compromised.
   
   Even though you follow well-practiced security standards, there is always a chance of events with security issues or misconfigured resources. If you have workloads in multiple accounts, the blast radius is reduced to a single account.
   
   Obviously, this will help to limit the scope of impact in case of adverse events.
   
   
7. Meet the compliance needs:
   
   There are workloads that should meet specific industry-wide compliance standards like HIPAA for Healthcare or PCI DSS (Payment Card Industry Data Security Standard). For example, PCI-DSS compliance controls should be enabled and tracked for resources that store, process, and handle cardholder data. It is always recommended to enable these controls only for specific workloads where applicable. Hence, grouping and scoping the PCI controls at the cloud account level enables remediate in case of non-compliance.
   
   Similarly, there are also other standards viz., AWS/Azure/GCP foundation benchmarks, CIS – Center for Internet Security standards, and operational standards/frameworks like NIST – National Institute of Standards and Technology controls. Grouping the workloads across accounts and mapping the right security controls enables us to achieve the business goals in terms of security and compliance needs.
   
   
8. Multiple Environments based on Software Development Life Cycle (SDLC):
   
   Most organizations have different policy requirements for non-production and production environments. Non-production can be split into Development, System testing, Quality assurance (QA), staging, pre-production, User acceptance testing (UAT) and so on. Ideally, these non-prod workloads need to be isolated and should not have production dependencies.
   
   Few customers, prefer to host all non-prod workloads into a single account wherein few host individual accounts for Dev, QA, and UAT. Regardless of any, a separate account should be used to host production workloads. Plan out the account structure based on the SDLC practices followed in the company.
   
   
9. IT Operating models and its distributed team structure:
   
   The way customers (or you) perform IT operations and the associated operating models also need to be considered. In today’s trends, most enterprises started adopting modern practices like DevSecOps, SRE (Site Reliability Engineering), and DataOps (Agile + DevOps + Process controls for data).
   
   Also, the next-gen operating model changes in the way they adopt cloud services like fully PaaS or SaaS. Most companies prefer a decentralized way of working rather than a centralized team. The use of separate accounts enables you to apply distinct governance and operational controls that are appropriate for each of your operating models.
   
   Even though the operating model evolves over a period and changes based on the service providers you choose, it is always good to plan by considering this in mind. This also enables the roles of the persona – CloudOps engineers, DevOps experts, Data analysts, etc.. in mapping their responsibilities and accountabilities clearly.
   
   
10. Technical consideration – Cloud Account Quotas and limits:
    
    Service Quotas and request rate limits are allocated for each cloud account as shown in the previous post. Service Quotas come with default limits and can be increased to the maximum allowable hard limit. Beyond that, provisioning additional accounts will be helpful. Hence, the use of separate accounts for workloads can help distribute the potential bottlenecks of the quotas and limits.
    
    For example: In AWS, there is a limit on the S3 buckets that can be created per region per account. Similarly, in Azure, there is a quota limit on the maximum number of resource groups to be created per subscription, and the number of load balancers that can be provisioned per region per subscription and the same applies to storage accounts as well.
    
    This also invokes other queries:
    a) Does the business require a particular workload to operate within specific cloud service limits?
    b) Is there any need, not to impact the limits of another workload?
    
    Yes, we have come across several situations, where individual business units want to restrict the resources like the number of EC2/VM instances that can be provisioned under each account. You can make use of cloud account service limits to impose restrictions across several resources.
    

Refer to the below image, where creating a quota limit within an account for multiple users/projects/BUs needs a complex solution and involves third-party tools today to achieve the same. Wherein, the same is possible if the quota limit is applied only at the account level for each individual BU/project.

Hope this post covers the areas that need to be considered before planning for multiple accounts and their benefits. The next step is to build a Cloud account structure and hierarchy. We will see this in detail in the next post.

Thanks for reading!