Cloud tenants are an essential part of the cloud Resource Hierarchy. Provisioning tenants is an essential capability for any cloud foundation. Access to a cloud tenant like an AWS Account or Azure subscription enable self-service cloud resource provisioning for application teams.
The cloud foundation maturity model uses the term “tenant” to refer to the abstract concept of an isolated environment in a multi-tenant cloud platform. Cloud foundation teams can choose different platform-specific concepts to implement tenants. This choice should depend on the landing zone and workload type. Some practical examples of tenant concepts
In a Cloud-native Landing Zone, every application team receives their own AWS Account to provide strong isolation.
A managed Container Platform Landing Zone based on Kubernetes provides a Kubernetes namespace to every application team. These provide lightweight isolation between different workloads on the same cluster.
A Lift & Shift Landing Zone on Azure provides dedicated resource groups to every customer. This allows easily sharing common resources like an on-prem connected VNet while providing a reasonable level of isolation for configuring RBAC access to VMs and connected resources like storage accounts.
Why You Need to Automate Cloud Tenant Provisioning
Since Tenant provisioning is so quintessential, practitioners should consider the following implementation maturities as they are growing the overall maturity of offered cloud foundation capabilities.
⭐️ manual provisioning: when starting out and serving only a small amount of internal customers, manual provisioning of "naked" cloud provider tenants via cloud provider portals (GUI) is a feasible approach
⭐️⭐️ semi-automated provisioning: as the number of other cloud foundation capabilities grows, more and more post-provisioning steps will be required to enable advanced cloud foundation capabilities like Landing Zones. Automation is key to achieving consistent results.
⭐️⭐️⭐️ - ⭐️⭐️⭐️⭐️ fully automated provisioning: a repeatable and fully automated provisioning process saves significant amounts of time and streamlines development of new cloud foundation capabilities. For managing a high number of internal customers, this level of automation is crucial.
In practice, many cloud foundation teams miss the right point in time to invest in full automation capabilities for tenant provisioning. This occurs because each time adding "just one more manual step" to a semi-automated process feels like an insignificant decision. However, the compounding effect of these decisions together with increasing internal demand burdens cloud foundation teams with operational chores. The burden of these chores eventually leaves teams with too little time and resources to rectify the situation
⚠️ Consider full automation of tenant provisioning early on while operational chores still leave enough room to invest in automation.
Best Practices for Tenant Provisioning
Apply Proper Tenant Isolation
Isolate teams and workloads using tenants - no sharing! One of the worst anti-patterns caused by not having sufficient tenant provisioning capability is that teams put development and production workloads into the same tenant. This encourages bad security practices that can lead to compromise of production environments.
IAM Should Be Part of Tenant Provisioning
Tenant provisioning alone is rarely useful without a minimal Shared Responsibility Model Alignment and Resource Authorization Management that details how and to what extent teams can access cloud tenants.
Maintain a Cloud Tenant Database
Record provisioned cloud tenants and their purpose in a Cloud Tenant Database from day one. This way your organization always has a complete inventory of the cloud tenants managed by the cloud foundation.
Establish Tenant Naming and Tagging Conventions
💡 Use lowercase and dashes
Consider making Cloud Tenant Tagging a part of the provisioning process.
Automate Tenant Provisioning
Beware of the pitfalls of insufficient automation. Semi-automated provisioning often leads to a “monolithic” landing zone design, which is a bottleneck for achieving higher-level capabilities in later journey stages (see Modular Landing Zones for a discussion).
Self-Service Tenant Provisioning
See a fully automated tenant provisioning process live in action or learn more on best practices for tenant management.Get a Demo → Learn More →
Fully automated provisioning of tenants is a pre-requisite for more advanced capabilities like Multi-cloud tenant database integrated with lifecycle management.
meshStack automatically provisions and reconciles cloud tenants based on the desired state. This includes metadata (tags) as well as authorization (role assignments, groups).Learn More
- GCP Fabric FAST
With the project factory, GitOps-based tenant provisioning can be applied. As the project configs should better be reviewed by a cloud foundation member, it is not full self-service for the end users. When removing the project definition again, the tenant will be deprovisioned by terraform.Learn More
- GCP CFT - Example Foundation
With stage 4-projects you can define projects, but you have to touch Terraform files to create or change projects. This feels more like coding instead of configuring it as it is done with Fabric FAST. So this approach of modifying Terraform does not seem to result in the best GitOps flow for managing projects.Learn More
- Azure CAF Terraform Modules
There is a mechanism called subscription vending machine to create subscriptions for EA and MCA. But since it wasn’t documented we haven’t tried it.Learn More
- AWS Control Tower with AFT
AFT’s main functionality is automation around tenant provisioning. Deprovisioning is not supported. Removing the aft-account-request terraform for a specific account only removes it from AFT management.Learn More
- AWS Landing Zone Accelerator
Workload Accounts can be defined in the accounts-config.yaml. Only the very basic account information can be entered here. Tags, Service Accounts, etc cannot be defined for workload accounts.Learn More