Introduction

Azure Cloud Subscriptions are essential to managing cost, aligning with business strategy and also provide a way to manage GxP expectations. In our journey to mature, we are planning on making incremental changes to align our subscriptions to achieve the following business goals.

  1. simplify identification and classification by having a consistent naming convention

  2. optimize value by aligning to sandbox and dev/test concepts

  3. speed up the delivery of assets by requiring delivery pipelines

  4. reduce technical debt and cost overruns by moving resources appropriately

Sandboxes

  1. We want each product team to have a sandbox where they can experiment.

  2. The sandbox needs to destroy all resources every 30 days.

  3. The sandbox is not long-lived.

  4. The sandbox is not promotable to dev or any other subscription.

Dev/Test

  1. We want to transform all development subscriptions to a dev/test type to optimize savings.

  2. Users cannot create resources in Azure by default and need to use pipelines through Terraform to deliver their resources.

  3. Dev/Test subscriptions can be promoted to stage.

Standardization

The team needs to standardize the naming convention of the subscriptions and remove any unneeded or inconsistent subscriptions. Subscription names need to be identifiable because we are scanning them and tying deployments, cycle/lead time to those subscriptions. We should not use random numbers/alpha on the subscriptions.

For core product resources like the base config management or base product operations, use “core”. (see below) Some products may have multiple subscriptions because of multiple distinct products that need to be created. Context is used to help describe the domain of differentiation. In many cases, we will only have one set of subscriptions for a product.

Naming convention should include the following.

  1. Product name

  2. Environment name

  3. Context

For example, for Signal Management, we would have something like

signalmanagement-core-dev (for internal processing only) signalmanagement-events-dev (has connectivity to external entities/3rd parties)

Resource Groups within Subscriptions

Within a subscription there will be many resource groups. Resource groups represent unique processing or compute environments. Many times they are apps or integrations which include everything to be stand alone.

Where a subscription has multiple resource groups for different environments, these need to be split and put into the appropriate subscription. For instance, for web development, we have dev, stage, prod resources in one subscription, we need to move all dev resource groups to the dev/test subscription, same with stage and production.