Undefined Subscription Strategy in NZ

How NZ organisations set subscription boundaries for cost centres, NZISM profiles, CPS 234 scoping, and small-tenant reality.

Part 4
SR
Steve Rackham
5 min read Guides

Ask a room of NZ platform engineers where subscription boundaries should sit and you will get a debate that outlasts the meeting: per application? Per environment? Per team? Per cost centre? Per compliance zone?

Without a documented answer, teams improvise. Within eighteen months you have:

  • prod-app1-final-v2 and prod-app1-final-v3
  • A shared “Dev” subscription containing forty unrelated apps, where one team’s cost is everyone’s problem
  • A subscription owned by a contractor who left in 2023
  • Nobody who can produce a clean cost report for the CFO


Why This Decision Carries More Weight in NZ

Cost attribution is existential, not cosmetic. NZ businesses, from SMBs to enterprises, typically run lean. When a platform fee is being charged back to business units, an unattributable 15% of cloud spend triggers real conversations. Subscription boundaries are your primary cost isolation mechanism; tags are secondary and weaker.

Compliance scoping is easier to shrink than to grow. If some workloads touch personal information (Privacy Act 2020), health information (HIPC 2020), or sit within NZISM scope for a public sector contract, putting them in dedicated subscriptions makes the compliance boundary technically enforceable and auditable. Mixing regulated and unregulated workloads in one subscription makes every subscription’s controls apply to everything, and gives auditors a reason to scope more, not less.

CPS 234 scoping for financial entities. If you are a registered bank or licensed insurer, cleanly scoped subscriptions make it dramatically easier to define the asset inventory and security capability you report against.

Quota and blast radius matter even at small scale. The one datacentre region (Azure NZ North) means NZ tenants often concentrate workloads regionally. Subscription level separation limits the damage when something goes badly wrong, and localises API/quota contention.

A Decision Framework That Works

Do not try to satisfy every axis. Choose primary boundaries and use other mechanisms for the rest:

Primary: compliance and regulatory scope

Separate subscriptions where the regulatory treatment of the workload differs:

  • Public sector contract workloads vs commercial (NZISM scoping)
  • Personal information processing workloads vs not (Privacy Act evidence boundaries)
  • Financial sector regulated systems (CPS 234 reporting scope)

Secondary: cost accountability

If two workloads have different owners of the money, they generally belong in different subscriptions. This makes Azure Cost Management, budgets, and chargeback trivially correct instead of tag archaeology.

Not boundaries: environments, teams, whims

  • Environments within an application do not need separate subscriptions by default. Management group, RBAC, and resource groups usually suffice. Exception: when a regulated environment must be technically isolated from a non regulated one.
  • Per team subscriptions work when teams own full product lifecycles; they break down when teams share products.

Codify It: Subscription Vending Is Non Negotiable

Once the strategy is documented, automate it:

  • A vending pipeline (ALZ Bicep/TF modules, or the ALZ subscription vending modules) that takes a request (app name, owner, environment, data classification, budget) and produces a subscription in the right management group with the right policies, budget alerts, and tags
  • A request form that asks the right questions, including data classification and whether personal information will be processed, because that question determines placement, and it is far cheaper to ask at request time than to remediate after
  • Naming and tagging standards enforced by policy, aligned to whatever the business actually reports on (cost centre codes, product codes, match your finance system, not a generic standard)

The NZ Sized Caveat

In a small organisation, it is tempting to skip all this: “We are only ten engineers, one subscription per environment is fine for now.” Understand what you are buying: vending automation that exists from the start is a two week build. Retrofitted onto three years of drift, it is a six month programme, and NZ organisations rarely have six months of platform capacity to spare.

The test: could your finance team, unaided, produce an accurate cloud cost breakdown by business unit today? Could your auditor list which subscriptions process personal information? If either answer is no, your subscription strategy is undefined, whatever the document says.

One Block

Write a one page subscription strategy that names your primary isolation boundary (compliance, cost, or blast radius). Share it with finance and one workload team before you create the next subscription.