meshBlog
Cloud Tenant Management: What You Need to Know in 2021
This post gives an overview over important cloud tenant management concepts.
If you work as a CIO, as a Cloud Architect, in DevOps or you are just interested in the cloud tenant lifecycle and its implications, this post is for you.
We’ll look at the cloud tenant, or cloud account, lifecycle from fundamental considerations, to provisioning, running workloads, and de-provisioning.
In this new guide you will learn:
- What cloud tenant management is
- Why cloud tenant management is at the core of good cloud governance
- How cloud tenant management ties in with billing, IAM and cloud security
- Best practices in structuring cloud accounts
- The resource hierarchies of AWS, Azure and GCP
- Why tagging and labeling is an essential part of cloud tenant management
Let’s get started with the basics:
What is Cloud Tenant Management?
Cloud tenant management is the coordination and administration of a cloud tenant throughout its entire lifecycle to provide developers with a secure, efficient, and fitting working basis in the cloud.
We refer to a cloud tenant as an account with a cloud provider. In the case of AWS, it would be an account, Azure calls it a subscription and Google coined it GCP project. Other providers may have come up with other names but they all describe what we call a cloud tenant. Others just go with cloud account – this post covers the management of such tenants or accounts.
How Cloud Tenant Management Ties in with Cloud Governance
Thorough cloud governance is essential for enterprises and it gets more complex with the number of clouds in use and the number of projects running.
Cloud tenant or cloud account management is an integral part of cloud governance: It’s important to effectively manage many cloud accounts over numerous cloud platforms.
Take Care of Cloud Tenant Management Early
Losing track of cloud accounts costs money and risks security: Enterprises embarking on their cloud journey may start with a small number of projects and accounts. But putting thought into proper cloud tenant management can save a great deal of effort in later stages when things grow and get more complex.
The Cloud Tenant Lifecycle
The lifecycle of a cloud tenant is closely related to the cloud project lifecycle, in which a tenant is configured, users are invited, resources are provisioned and at last, everything is de-provisioned again. The cloud project lifecycle is a subset of the cloud tenant lifecycle so to speak.
Resource Hierarchies for AWS, Azure and GCP
In this section, we’ll describe the resource hierarchies of AWS, Azure, and GCP on a very high level. The resource hierarchy refers to the organization of resources inside a cloud platform account. The three big providers offer several levels, some of which are optional:
AWS and GCP allow for the cloud tenant (account or project) to be the highest up in the resource hierarchy. Azure requires you to have a root management group for all tenants, that can’t be moved or deleted.
Azure also requires you to have at least one resource group – a level that the other two providers do not have at all.
The levels determine the inheritability of policies, how access is managed, and so on. These levels are your building blocks to map your organization to the cloud.
Best Practices for Organizational Structure in the Cloud
Mapping your organization to the cloud is a major and fundamental part of the cloud journey. In this section, we’ll cover best practices to provide some guidance along the way.
Planning a consistent scheme ahead of time is important to avoid structures that occlude what is actually going on further down the road.
A best practice we see in the industry and with our customers is creating cloud accounts according to the environments an application should run in. Commonly that means three cloud accounts for one application: One for development, one for staging/QA, and one cloud account for the production environment.
Keep in mind, that for every new cloud account this can mean management overhead piling up – depending on the maturity of your cloud governance capabilities. We’ll get to that later.
Flat hierarchies reduce complexity and avoid vendor lock-in to a single cloud service provider.
From our as well as from a best practice point of view your organizational structure should be modeled after your use cases or IT products instead of aligning it to your departments or organizational hierarchy.
Looking at you cloud organization from three different angles:
- How you want your teams to work?
- How you want your IT products managed?
- and from the life cycle perspective
This clearly shows why modeling your organizational structure after IT products or use cases is meaningful:
- Start with how you want your team to work on IT products or use cases. "The right person for the right job" describes pretty nicely what you want, and to gather a team of specialists you may need employees from the different departments as most goals can be only achieved if various departments work cooperatively.
- How do you want IT products to be managed? Avoiding bottlenecks and enable teams to self-organize and drive innovation! This means you want to have a self-service approach for each IT product so that the team can be self-sovereign to some degree i.e. having their own DevOps team, rights and role structure, chargeback, and metadata.
- Everything changes and the organizational structure model should be robust against these changes. Responsibilities of departments for IT products change overtime or IT products move between departments, or maybe the departments themselves will be reorganized. These events would require major remodeling for the organizational structure in your multi-cloud modeled after your departments.
The Importance of a Multi-Cloud-Account Strategy in the Cloud
Most enterprises need a multi-cloud strategy and within these clouds a multi-cloud-account strategy.
Having only one cloud account – or cloud-tenant – for each cloud in use brings major drawbacks that have caused serious trouble: Hackers used the chaos created by running all applications on one cloud tenant to mine cryptocurrency in Teslas AWS account.
Here are 4 risks and limitations caused by running both production and non-production services in one cloud tenant:
1. Concentration risk
2. Service limits
3. Permissions and transparency (think of the Tesla case)
4. Cost allocation (also think of Tesla)
Multi-Tenant Approach for better Security, Agility, and Transparency
The solution to avoid these unnecessary and dangerous downsides of running everything in one cloud tenant is – of course – having a cloud tenant for every production and non-production stage of your applications.
It’s also a prerequisite for enabling teams to create their own cloud tenants in self-service – we’ll get to that later. This approach is great for tenant isolation, innovation, and enablement. But it definitely needs a good grasp on proper cloud tenant management to keep track of every cloud tenant’s lifecycle.
Cloud Account Meta Data
When creating a cloud account – a cloud tenant – metadata is required to manage the specific new cloud account and the overall number of accounts in the organization. here are some common examples of cloud tenant metadata:
- Budget
- The responsible developer
- Type of environment: development, staging or production?
Many companies gather this data over a form or a survey prior to the provisioning of the cloud account from the requesting team. Some store this important metadata in a database, an excel sheet, or simply a PowerPoint presentation.
This manual process is slow, prone to errors and manipulation. Over time the reality of a specific cloud account or all cloud tenants in the organization will differ dramatically from the static metadata: A single source of truth is missing.
Cloud Tagging needs to be consistent. Establishing authoritative sources for each tag and clarifying responsibilities for keeping the tag value up to date is essential.
Metadata to cloud tenants needs to be integrated – meshStack serves as a metadata layer for many of our customers.
Tagging and Labeling Your Cloud Accounts
One way of integrating metadata to a cloud tenant is using tags (Azure and AWS) and labels (GCP). Tagging or labeling cloud tenants increases transparency within the organization:
One central advantage of using the cloud is rapid scalability. And with this comes the necessity to keep track of what is going on in your cloud infrastructure while it is constantly growing and changing. That’s where tags come in: You will need a consistent set of tags to apply globally across all of your resources following a consistent set of rules. Tagging is the cornerstone to effective cloud governance: Cost allocation, reporting, chargeback and showback, cost optimization, compliance, and security – all these aspects can only be managed with proper tagging in place.
Everything can be put into this mnemonic: Tag early, tag often.
We’ve been talking about how tagging is essential and coming up with a cloud tagging strategy should be an early stage step in setting up your cloud governance.
Here are the most common use cases to show you why:
1. Cloud Cost Management
Gain transparency when it comes to cloud usage and costs: Tagging cost centers, business units, and specific purposes help you keep track.
2. Cloud Access Management
Proper tagging enables administrators to control the access of users or user groups to resources or services.
3. Cloud Security Management
Tags are essential to identify sensitive cloud tenants and keeping them secure. Cloud tenant tagging is a matter of compliance and should be treated as such by the central cloud team (the Cloud Foundation Team).
4. Automation
The added metadata of tags enable a whole new level of automation: Many different automation tools can read these tags and utilize them to make your life easier in almost every regard concerning the previously mentioned use cases.
Self-Service Cloud Tenant Creation
We talked about the advantages that draw enterprises to the cloud in the first place: To leverage these advantages you will need a self-service cloud tenant creation for your DevOps teams.
A DevOps team lead should be able to provision a cloud tenant and deploy applications without the interference of some kind of central IT. Offering a self-service cloud account creation requires a high degree of automation. This reduces manual workload and with that reduces the "time-to-cloud" for the developers.
The user interface for that has to be easy to use to enable as many users as possible to provision their own cloud tenants.
Automate Tenant Configuration
Automating the cloud tenant creation and enabling users to do so in self-service can only be the first step. Automating the tenant configuration has to follow to keep a consistent level of cloud security, compliance, and transparency throughout all company cloud accounts and across cloud providers.
Depending on if the newly created cloud account is for development, QA or production – as an example – different configurations and policies should automatically apply. An Azure subscription for production gets a different set of tags and a specific blueprint than let’s say an AWS account that’s used for staging and is automatically configured with the according landing zone.
The cloud service provider offers their own tooling and support for third-party tools to automate the cloud tenant configuration. AWS has its AWS Vending Machine and GCP provides the Google Project Factory to work with terraform configuration files. The same is possible with Microsoft Azure.
To learn more about the meshcloud platform, please get in touch with our sales team or book a demo with one of our product experts. We’re looking forward to get in touch with you.