Public cloud has provided huge benefits in getting infrastructure and services to people at the click of a button. For everyday users, getting server infrastructure into your hands in minutes really was impossible to imagine only 10 or 15 years ago. But the simplicity of cloud came at the price of unmanaged control leading to spiralling costs and lack of accountability.
One part of the bigger picture is figuring out how to add structure and organisation when providing access to public cloud services to users without hindering agility. The public cloud providers quickly realized the problem of accountability, and provided means to organize access and billing.
Although the public cloud providers have recognised the problems, there is still a gap as to how this fits into your organisation’s structure and processes. We will look at best practice cloud account organisation strategies and how these relate to the public cloud capabilities from Microsoft, Amazon and Google clouds.
Organizations often started their foray into cloud with a single goal or a single project. As with all good IT, organic growth provided an ideal breeding ground for complexity. The single project turned into a department or company wide everything on cloud and it became a little unwieldy.
Before long, problems start to appear: large bills came as a huge shock, causing a lot of angst and internal finger pointing, but nailing down where resources are being consumed and costs incurred is a problem. Organizations realized that cloud was something that needed to be tamed and constrained, but didn’t want to lose the awesome agility and capabilities that were provided.
The public cloud providers started to create reference architectures to help customers understand what a well architected cloud looked like. Landing zones became a thing that described your core cloud architecture to bring some order and consistency. A core part of the architecture thinking was how to best manage cloud usage within the organization through things like multi account strategies and how best to organize your organization, teams and users to give better control and compliance.
Most cloud accounts start by just taking a credit card and getting on with doing things in the account that was created without thinking about future scaling. This was great for getting things done quickly, but fast forward 12 months and you find yourself in trouble.
Once your use of public cloud increases, managing through that single account becomes unsustainable, posing cost and security concerns. Things users found when scaling with that single account were:
- Realization that not all workloads are the same!
- Making sure you have good controls over your single account, with regards to
- Control (access, management, budgeting)
- Looking out for cross pollution of workloads which may deplete account resources
- Putting good budget and spend constraints in place to ensure the account does not run away with spiralling costs
- Looking out for autoscaling nodes that you don’t control, scaling up the costs
- Looking out for hosting production workloads on the same account as development workloads
- Making sure that the ‘blast radius’ of things being compromised in your account is manageable
Multi account organization
The problems outlined with single accounts become much easier to control when moving away from a single account strategy and into managing your cloud with multiple account and organization strategies.
Most of the public cloud providers have a set of best practice guidelines around landing zones (setting up your cloud architecture) and organisational structure (setting up groups, users and policies). The high level guidelines generally follow a similar set of high level principles:
- Base your organization/grouping/control based on function rather than existing company reporting structures
- Create staging and production structures to segregate development and test from production function/workloads
- Apply policy at the higher organizational level rather than at the base level.
An example of using public cloud organisational structures to group policy and control is described below. All of the cloud providers give you a method of creating hierarchical structures to manage the access, control and billing policies that make creating these structures straightforward.
Public cloud differences
One of the things that is confusing when looking at how public clouds provide account and organization structures is that none of the three big clouds have a standard way of doing things or even naming things. Account, subscription or project? They sound different but are very closely related depending on which cloud you are using. Here’s a quick overview!
AWS provides a service called AWS Control Tower, specifically to address the needs of controlling AWS accounts and help in orchestrating a multi account strategy.
The core of organizing AWS resources and usage lies in two container structures, AWS Accounts and organizational Units.
An AWS account acts as a resource container and resource isolation boundary (this is not the same as a user account). An AWS account is the core concept for providing a segmented controlled place for AWS resources to reside. Accounts are where users or workloads can be monitored and constrained in resource usage and cost control.
The OU is a higher level grouping of AWS accounts which allows you to create an organizational hierarchy making it easier to apply policy and control over a set of accounts. An OU contains one or more accounts and can be used as a logical grouping where a broad set of constraints and policy can be applied.
Microsoft Azure provides a well defined organizational structure hierarchy. Microsoft’s best practice details how to create a landing zone to organise your cloud workloads and resources as well as a best practice guide called a Cloud Adoption Framework.
The top level organization unit is a management group.
Care must be taken in designing which items live within the management group hierarchy as policy and control will be defined at this level and each of the items in the management group will inherit the top level policies.
An Azure subscription is a container under which resources are defined and used. The subscription can be used to define a logical boundary for functions or resources as well as the billing and access policy enforcement points to control:
- Billing boundary: This subscription type defines the billing requirements for using resources. You can create different subscriptions for different billing requirements, and Azure sends separate billing resources for each subscription.
- Access control boundary: you can create an access control boundary at the subscription level by applying different access management policies to different subscriptions to reflect different organizational structures.
Much like AWS and Azure, GCP provides organization through “containers” in a hierarchy to provide:
- A hierarchy of ownership, which binds the lifecycle of a resource to its parent in the hierarchy
- Inherited access control and organisation policies
The Organization resource is the root node of the Google Cloud resource hierarchy providing central visibility and control over every resource that belongs to that organization.
Folders and projects
Folders are an additional grouping mechanism as organizational units that reside within an organization. (You are required to have an Organisation resource as a prerequisite to using folders.)
The Google Cloud resource hierarchy, especially in its most complete form which includes an organization resource and folders, allows companies to map their organization onto Google Cloud resources providing logical attach points for access management and organization policies. Both access and organization policies are inherited through the hierarchy.
Getting your account organization and structure right is important once you start to scale. Putting a multi account strategy in place is only part of your whole cloud strategy but when implemented, will give you a great starting place to provide the control, compliance and organization into your use of public cloud.