Microsoft AZ-104: Cost Governance for Azure Subscriptions

Azure cost governance is the operating system that makes cloud spend attributable, reviewable, and controllable before teams begin one-off optimization. Subscription structure, management groups, resource groups, tags, Cost Management, budgets, alerts, cost allocation, reservations, savings plans, Azure Policy, and ownership all contribute. The goal is to show who is spending, why the spend exists, which costs are shared, and who has authority to change the architecture that creates the cost.

Microsoft’s current Cost Management guidance emphasizes resource hierarchy, tags and tag inheritance, budgets and alerts, cost analysis, and allocation rules. Azure Policy can enforce tagging and restrict expensive resource types or SKUs where that matches organizational policy. Savings plans and reservations optimize eligible usage rates, but they work best after the organization understands stable demand and ownership.

Cost governance belongs inside Azure Architecture in Practice.

Use subscriptions as accountability boundaries

Subscriptions create boundaries for cost analysis, quotas, RBAC, Policy, and lifecycle.

Azure governance should align subscription structure with product, business unit, environment, or another durable ownership model.

A giant shared subscription can make cost and access easy at first but difficult to attribute and govern later.

Use management groups for consistent policy

Management groups can organize subscriptions and inherit RBAC and Azure Policy downward.

They can also help platform teams view and govern spending across related subscriptions.

Landing-zone structure should make cost governance part of the same hierarchy used for platform and security governance.

Use tags for business context

Resource tags can describe application, owner, environment, cost center, product, or initiative.

Microsoft Cost Management can use tag inheritance to enrich cost records from resource-group or subscription tags in supported scenarios.

Tags should have controlled names and values; inconsistent free-text tags can make reporting as unreliable as having no tags at all.

Create budgets as communication guardrails

Budgets can be defined at supported scopes and can alert on actual or forecasted spending.

Budgets do not automatically stop resources, so teams should pair alerts with ownership and a response process.

Cost-spike analysis is more useful when the owner knows which release, resource, or traffic change drove the alert.

Allocate shared-platform costs deliberately

Hub networking, logging, security, build platforms, and shared services often live in central subscriptions.

Microsoft Cost Management allocation rules can redistribute selected shared costs across subscriptions, resource groups, or tags for reporting in eligible billing agreements.

Allocation does not change the invoice; it improves internal accountability and chargeback/showback models.

Use Policy for enforceable cost standards

Azure Policy can require tags, restrict regions or SKUs, or prevent deployment of resource types that violate platform standards.

Policy initiatives can group cost-related controls with environment parameters and staged rollout.

Do not use deny policies as a substitute for architecture; publish approved alternatives so product teams know how to meet performance and reliability requirements economically.

Optimize rates after demand is understood

Reservations and savings plans can reduce cost for stable eligible usage, but a commitment made before demand is understood can create unused spend.

FinOps architecture should separate rate optimization from utilization optimization and from structural design decisions.

Measure commitment coverage and utilization instead of assuming a discount automatically means savings.

Track cost per business unit

Total subscription spend is useful but not sufficient.

Product teams should understand cost per transaction, user, environment, tenant, build, or other workload unit where feasible.

This connects architecture changes to business value and helps distinguish healthy growth from inefficient growth.

Make cost review continuous

Review cost after releases, growth, scale changes, new services, and provider pricing changes.

Azure cost architecture should be revisited before teams jump to small optimization tasks, because a poor subscription, storage, network, or resilience design can dominate spend.

For Azure administrators and architects, mature cost governance is hierarchy → metadata → visibility → budgets → allocation → policy → rate optimization → product-unit economics.

Cost ownership should be visible in resource and subscription metadata. Alerts that route to a generic cloud team force central engineers to investigate spending they cannot explain. Send budget and anomaly signals to the product team that can change the workload.

Nonproduction environments deserve lifecycle controls. Schedules, autoscaling, ephemeral test environments, and shutdown automation can reduce waste where resources do not need to run continuously. These controls should preserve test validity and developer productivity rather than create arbitrary shutdowns that teams immediately bypass.

Cost governance should include marketplace and data-transfer spend, not only virtual machines. Logs, backups, public egress, managed databases, security products, and third-party offers can become major cost drivers that tagging and ownership must cover.

The strongest FinOps culture makes cost a normal architecture metric beside reliability, performance, and security. Engineers can then discuss whether a resilient or high-performance design is worth its cost instead of discovering financial impact after deployment.

Cost governance should define which metadata is mandatory at resource creation. Owner, product, environment, cost center, and lifecycle are common examples, but every required tag should have a reporting or automation purpose. Too many mandatory tags create developer friction and often lead to meaningless placeholders that weaken cost data.

Tag inheritance in Microsoft Cost Management can improve reporting even when resources do not emit all tags in usage records. This is a reporting feature rather than a resource-property change, so teams should understand that other Azure services do not automatically see inherited cost tags.

Budgets are most effective when thresholds trigger different actions. An early threshold can notify product owners, a later forecasted threshold can initiate an architecture review, and an exceptional spike can involve platform or finance teams. A budget without a response plan becomes email noise.

Azure Advisor, Cost Analysis, and exported cost data can support optimization, but recommendations still need workload context. Shutting down an apparently idle standby resource can weaken recovery; resizing a database can violate peak performance. Product owners should validate optimization against service objectives before automation applies it.

Shared cost allocation should use stable drivers where possible. Equal split may be simple, but usage-based or business-unit allocation can be more accurate when the required data exists. Document the allocation method so internal consumers understand why their reported cost changed.

Reservations and savings plans should have owners for purchase, utilization review, scope, and renewal. A commitment that once matched stable compute can become underutilized after modernization or migration. Review utilization before renewal instead of treating the discount instrument as permanent.

Cost governance should include data, security, and observability services whose spend can grow independently from compute. Log ingestion, storage transactions, egress, backup retention, Defender plans, WAF, and managed network services can become large recurring costs and should be attributable to the workloads that drive them.

Unit economics should be incorporated into architecture experiments. If a new cache, premium database tier, or multi-region design changes cost per transaction materially, include that metric in the release decision beside latency and reliability.

The enterprise goal is financial accountability without centralized micromanagement. Platform teams provide hierarchy, policy, tagging, allocation, reporting, and commitment governance; workload owners remain responsible for architectural choices and whether the resulting cost creates sufficient business value.

Cost anomalies should be correlated with deployment and usage events. A sudden increase can come from traffic growth, a new SKU, log-volume change, backup retention, data transfer, or a forgotten test environment. Release metadata and ownership tags make anomaly investigation much faster than reviewing invoice lines without context.

Chargeback and showback should distinguish shared-platform cost from direct workload cost. Central security, hub networking, DNS, monitoring, and identity infrastructure may be necessary even if no single application owns them. A transparent allocation model prevents product teams from treating those costs as “free central services” while still keeping the platform team’s spend accountable.

Optimization automation should have guardrails. Automatically resizing or stopping resources based only on utilization can violate redundancy, patching, or test requirements. Recommendations should flow through workload ownership and service-level context before high-impact changes are applied.

Cost governance also needs lifecycle for subscriptions. Sandboxes, mergers, proof-of-concept subscriptions, and retired products should have closure criteria so unused subscriptions do not retain resources, commitments, public IPs, or security services indefinitely.

Review the cost model annually and after large reorganizations. Management-group hierarchy, business ownership, billing contracts, and product structure change over time, which can make an old allocation model misleading even when its reports continue to run correctly.

Cost governance should also distinguish avoidable waste from intentional resilience. Duplicate zone capacity, warm standby, retained backups, and security logging can look inefficient if the business requirement behind them is invisible. Tag or document the service objective so optimization reviews do not remove controls that were purchased deliberately.

Keep one FinOps review cadence that includes architecture owners, not only finance. Engineers can explain why spend changed, while finance and product owners can explain whether the value remains justified.

Make cost exceptions visible and temporary. A high-cost SKU or always-on test environment can be justified, but it should have an owner, reason, and review date.

Keep subscription cost ownership current after reorganizations, mergers, product transfers, and major platform redesigns so reporting continues to match the teams that can actually change spend.