BLOGDevOps

Set Yourself Up For Success: Cloud Organization

Category
DevOps
Time to read
Published
February 22, 2024
Author

Key Takeaways

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 realised the problem of accountability, and provided means to organise 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.

Organic roots

Organisations 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. Organisations realised 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 organisation through things like multi account strategies and how best to organise your organisation, teams and users to give better control and compliance.

Single account

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:

  • Realisation that not all workloads are the same!
  • Making sure you have good controls over your single account, with regards to
  • Security
  • 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 organisation

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 organisation 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:

  1. Base your organisation/grouping/control based on function rather than existing company reporting structures
  2. Create staging and production structures to segregate development and test from production function/workloads
  3. Apply policy at the higher organisational 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 organisation 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!

Amazon AWS

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 organising AWS resources and usage lies in two container structures, AWS Accounts and organisational Units.

AWS account

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.

Organisation unit

The OU is a higher level grouping of AWS accounts which allows you to create an organisational 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

Microsoft Azure provides a well defined organisational 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 organisation 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 organisational structures.

Google GCP

Much like AWS and Azure, GCP provides organisation 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

Organisation

The Organisation resource is the root node of the Google Cloud resource hierarchy providing central visibility and control over every resource that belongs to that organisation.

Folders and projects

Folders are an additional grouping mechanism as organisational units that reside within an organisation. (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 organisation resource and folders, allows companies to map their organisation onto Google Cloud resources providing logical attach points for access management and organisation policies. Both access and organisation policies are inherited through the hierarchy.

Summary

Getting your account organisation 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 organisation into your use of public cloud.

Related Posts

Related Resources