How to manage your cloud projects on AWS, GCP, and Azure

Why do you need an organizational model?

If you start building your projects in the cloud, you will need to organize them.

When designed right, the organizational structure can be efficiently utilized when defining different kinds of policies, access controls, management settings, cost management, isolation, monitoring access, etc.

On the other hand, a wrong design might even lead to severe security issues and compromised production workloads in the worst case.

This is a critical decision in your cloud implementation. Knowing the different organizational models between the major cloud providers - AWS, Azure, and GCP - will give you a more detailed view of which one is right for you.

Generic organization models

Firstly, we can look at the organizations that can be set up regardless of the cloud provider:

• Separation by naming convention and tags: This method adopts a convention whereby each resource is prefixed by the name of the application or project.

  Pros :

  • Developers only need one set of credentials to access the resources they need
  • Resources are easily recognizable and identifiable

  Cons:

  • Enforcing convention across a team is difficult to police
  • Easy mistake by forgetting the tag or name prefix for a resource
  • No default isolation between projects, which means that each resource can theoretically access other projects’ resources.
    
    

• Separation by roles and networks: This approach involves creating a network for each project and using different roles to grant access to each project to a certain group of users.

  Pros :

  • Isolation of the resources by network
  • Access control with rules directly on the network
  • A single set of credentials is needed for a developer to access his projects resources

  Cons :

  • Naming convention and tags are still needed to differentiate resources and analyze cost
  • Enforcing convention across a team is difficult to police
  • Access control is difficult to manage and limit for large organizations
  • Some cloud providers have restrictions on how many networks each account can create.
  • Lack of flexibility in IP management

We note that for both generic organization solutions, there is a lack of project isolation, difficulty in limiting access to each resource, and difficulty in enforcing compliance.

We can now look at how the various cloud providers have responded to these challenges, implementing organizational models that solve most of these problems.

AWS Multi-account strategy

The recommended organization model for AWS is a multi-account strategy. This involves creating one account per project. By default, no resource sharing is allowed between accounts. This provides total isolation and helps contain security threats to your AWS workloads. This isolation also makes it possible to quickly create an environment tailored to specific business needs. It also enables better billing management, as costs can be segregated directly at an account level and redirected to the appropriate business unit, team, or customer.

AWS Organizations

However, as you'd expect, these accounts need to be organized and grouped together in order to take full advantage of all the possibilities offered by the multi-account strategy. There's an AWS service for this: AWS Organizations. It's best to use a diagram to explain how it works.

An Organization is an entity that you create to consolidate your AWS accounts so that you can administer them as a single unit. An organization has one management account along with zero or more member accounts.

This service allows you to organize the accounts in a hierarchical, tree-like structure with a root at the top and organizational units nested under the root. Each account can be directly in the root or placed in one of the OUs in the hierarchy.

The Organization root is the parent for all the accounts for your organization.

An Organization Unit is a container for accounts within a root. An OU can also contain other OUs, enabling you to create a hierarchy that resembles an upside-down tree, with a root at the top and branches of OUs that reach down, ending in accounts that are the tree's leaves. When you attach a policy to one of the nodes in the hierarchy, it flows down and affects all the branches (OUs) and leaves (accounts) beneath it. An OU can have exactly one parent, and each account can be a member of exactly one OU.

In addition to organizing accounts, OUs allow you to create compliance and rules in different scopes, like business units and teams.

AWS Control Tower

To easily create a landing zone following AWS Well-Architected Framework, there is a service called AWS Control Tower. It offers a straightforward way to set up and govern an AWS multi-account environment, following best practices.

AWS Control Tower orchestration extends the capabilities of AWS Organizations. To help keep your organizations and accounts from drift, which is a divergence from best practices, AWS Control Tower applies controls. For example, you can use controls to help ensure that security logs and necessary cross-account access permissions are created and not altered.

Pros and Cons

Pros :

• Isolation per project
• Billing management at the account level makes it easier to consolidate costs
• Security, permissions, and compliance can be managed at all levels
• Fast implementation of a landing zone via Control Tower

Cons :

• User access is managed at the account level and can’t be managed at the Organization or OU level (This disadvantage can be overcome by using SSO authentication with the AWS IAM identity center.)

GCP resource hierarchy

The project organization model on GCP is very simple to understand, as the resource hierarchy is already adapted to projects.

GCP Organization

The purpose of the Google Cloud resource hierarchy is two-fold:

• Provide a hierarchy of ownership, which binds the lifecycle of a resource to its immediate parent in the hierarchy.
• Provide attach points and inheritance for access control and organization policies.

Their organization model provides all the capabilities required to meet both these needs.

Once again, it's best to use a diagram to explain how it works.

Google Cloud resources are organized hierarchically. All resources, except for the highest resource in a hierarchy, have exactly one parent.

Google Workspace and Cloud Identity customers can create organization resources. When an organization resource exists, it is at the top of the Google Cloud resource hierarchy. This provides central visibility and control over every resource that belongs to an organization resource.

Folder resources are an additional and optional grouping mechanism between organization resources and project resources. Folders can be used to model an organizational or project structure within an organization and allow you to share common IAM policies on a per-department basis.

The project resource is the base-level organizing entity. A project resource is required to use Google Cloud resources and forms a solid base to manage your project. It authorizes you to create, enable, and use all Google Cloud services. Within this entity, you can also manage APIs, enable billing, add and remove collaborators, and manage permissions. By default, all resources are linked to a single project and can’t be accessed by other projects. Consequently, it provides per-project isolation for data, security, network, etc.

Pros and Cons

Pros :

• Isolation per project
• IAM, security, permissions, and compliance can be managed at all levels
• Flexible billing accounts for all levels

Cons :

• No ready-to-use landing zone service or deployment
• The billing account is independent of the organization model and cannot be contained within a project, folder, or organization.

Azure Resource Manager

Azure organization model is based on its management service: Azure Resource Manager. It provides a management layer that enables you to create, update, and delete resources in your Azure account.

With this service, you can build a flexible structure of management groups and subscriptions to organize your resources into a hierarchy for unified policy and access management.

This diagram will help you to understand how Azure resource management works :

This organization is based on 2 different resources: Management Groups and Subscriptions.

Azure AD Tenant: A tenant represents an organization in Azure Active Directory and creates the root management group.

Management groups: Azure Management groups are logical containers that enable Azure administrators to simultaneously manage access, policy, and compliance for multiple Azure subscriptions. All subscriptions within a management group automatically inherit the conditions applied to the management group. Azure Management groups can be used in various ways, including reflecting your billing structure. The strength of management groups, however, lies in their use to model your business.

Subscriptions logically associate user accounts with the resources that they create. A subscription is the logical entity that grants access to deploy and consume Azure resources. Organizations can use subscriptions to manage costs and the resources that are created by users, teams, and projects. Can’t use subscriptions for billing.

Inside the subscriptions, you can define multiple Resource groups. They are logical containers where you can deploy and manage Azure resources like web apps, databases, and storage accounts. Resource groups may be used to segregate resources by application or environment.

Landing zone accelerators

To create a landing zone corresponding to your needs, Azure includes landing zone accelerators in its Cloud Adoption Framework (CAF). These are ready-to-use deployments that implement a conceptual architecture tailored to your needs and apply predetermined configurations to key components such as management groups and policies.

Pros and Cons

Pros :

• Isolation per project
• IAM, security, permissions, and compliance can be managed at all levels
• Flexible billing accounts that can be implemented in all scopes
• Fast implementation with ready-to-use landing zone deployment

Cons :

• Two separate entities for resource/cost management (subscription) and billing account

Conclusion

We've reviewed the main organizational models for the 3 major cloud providers: AWS, Azure, and GCP, as well as much more generic models that can be adapted to any cloud provider.

AWS uses a recommended multi-account approach, enabling isolation of all resources, including billing and user access. On the other hand, GCP focuses on a hierarchy of resources leading directly to projects. Meanwhile, Azure's model successfully combines user and service management with resource clustering.

Each of these models has its strengths and weaknesses, but some stand out from the rest. Azure and GCP have models with a hierarchy of user and resource access. However, AWS offers better management and greater variety in the use of billing accounts than any of its competitors.