WAF-COST-080 – Commitment & Reserved Capacity Planning

Pillar: Cost | Severity: Medium | Category: Data Governance | Automatable: High

Description

Compute resources with sustained utilization >= 70% over 30 days MUST be covered by Reserved Instances or Savings Plans. All persistent on-demand compute resources MUST carry a 'capacity-commitment' tag documenting their reservation status and the date of the last commitment review. Spot/Preemptible Instances are the preferred option for variable and interruptible workloads.

Rationale

Risk	Description
Risk	High sustained load without capacity planning leads to expensive on-demand resources and budget variance.
Risk	Missing reserved-instance or savings-plan documentation prevents optimization opportunities.

Risk

Description

Risk

High sustained load without capacity planning leads to expensive on-demand resources and budget variance.

Risk

Missing reserved-instance or savings-plan documentation prevents optimization opportunities.

Requirements

Compute resources with sustained utilization >= 70% over 30 days MUST be covered by Reserved Instances or Savings Plans.
All persistent on-demand compute resources MUST carry a 'capacity-commitment' tag documenting their reservation status and the date of the last commitment review.

Implementation Guidance

Document the requirement in a version-controlled policy or standard.
Assign ownership and establish a review cadence (e.g., quarterly).
Implement the required configuration as code in Terraform or equivalent IaC.

Maturity Levels

Level	Name	Criteria
L1	Ad hoc – control not consistently applied	* Manual evidence exists for some workloads, but coverage is unknown.
L2	Standardised – policy defined and communicated	* A version-controlled policy, ADR, or standard describes the requirement.
L3	Integrated – automated validation in CI/CD	* Terraform checks run automatically on pull requests and report results.
L4	Auditable – metrics and exceptions tracked	* Control coverage, failures, and approved exceptions are reported quarterly.
L5	Optimised – continuous improvement based on data	* Control effectiveness is measured and iteratively improved.

Level

Name

Criteria

Ad hoc – control not consistently applied

* Manual evidence exists for some workloads, but coverage is unknown.

Standardised – policy defined and communicated

* A version-controlled policy, ADR, or standard describes the requirement.

Integrated – automated validation in CI/CD

* Terraform checks run automatically on pull requests and report results.

Auditable – metrics and exceptions tracked

* Control coverage, failures, and approved exceptions are reported quarterly.

Optimised – continuous improvement based on data

* Control effectiveness is measured and iteratively improved.

Checks

waf-cost-080.tf.aws.ec2-capacity-commitment-tag

Engine: terraform | Provider: aws | Automated: Yes

EC2 instances must declare their capacity commitment status

All EC2 instances must carry a 'capacity-commitment' tag documenting whether the instance is covered by a reservation, savings plan, spot pricing, or on-demand. This tag proves active commitment management and enables automated coverage reporting.

Scope: resource — aws_instance, aws_launch_template

Assertions: * tags key exists — EC2 instance missing 'capacity-commitment' tag. Reservation status must be declared. * tags.capacity-commitment in ['reserved', 'savings-plan', 'spot', 'on-demand', 'reviewed'] — capacity-commitment must be: reserved, savings-plan, spot, on-demand, or reviewed.

Remediation: Add 'capacity-commitment' tag to all EC2 instances. Value 'reserved' or 'savings-plan' = commitment exists. Value 'on-demand' = no commitment, flagged for review. Value 'reviewed' = reviewed and consciously left on-demand (needs date + justification).

Compliant

# Baseline instance with savings plan coverage
resource "aws_instance" "app" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "c5.2xlarge"
  tags = merge(module.mandatory_tags.tags, {
    rightsizing-reviewed = "2025-03-01"
    capacity-commitment  = "savings-plan"
    commitment-type      = "compute-savings-plan-1yr"
    commitment-expiry    = "2026-03-01"
  })
}

# Spot instance for CI/CD
resource "aws_instance" "ci_runner" {
  ami                    = data.aws_ami.ubuntu.id
  instance_type          = "c5.xlarge"
  instance_market_options {
    market_type = "spot"
  }
  tags = merge(module.mandatory_tags.tags, {
    capacity-commitment = "spot"
  })
}

Non-Compliant

resource "aws_instance" "app" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "c5.2xlarge"
  tags = {
    cost-center = "fintech-platform"
    # Missing capacity-commitment – commitment status unknown
  }
}

waf-cost-080.tf.azurerm.vm-commitment-tag

Engine: terraform | Provider: azurerm | Automated: Yes

Azure VMs must declare their capacity commitment status

All Azure Virtual Machines must carry a 'capacity-commitment' tag documenting whether the VM is covered by a Reserved VM Instance, Azure Savings Plan, Spot pricing, or On-Demand. This enables automated coverage gap detection.

Scope: resource — azurerm_linux_virtual_machine, azurerm_windows_virtual_machine, azurerm_virtual_machine_scale_set

Assertions: * tags key exists — Azure VM missing 'capacity-commitment' tag.

Remediation: Add 'capacity-commitment' tag to all Azure VM resources. Use Azure Advisor to identify baseline VMs that should have Reserved VM Instances.

Compliant

resource "azurerm_linux_virtual_machine" "app" {
  name                = "vm-payment-app"
  resource_group_name = azurerm_resource_group.main.name
  location            = var.location
  size                = "Standard_D4s_v3"
  tags = merge(local.mandatory_tags, {
    "capacity-commitment" = "reserved"
    "commitment-type"     = "1yr-no-upfront"
  })
}

Non-Compliant

resource "azurerm_linux_virtual_machine" "app" {
  name     = "vm-payment-app"
  location = var.location
  size     = "Standard_D8s_v3"
  # Missing: capacity-commitment tag
}

waf-cost-080.tf.google.vm-capacity-commitment-label

Engine: terraform | Provider: google | Automated: Yes

GCP compute instances must declare capacity commitment status

All persistent GCP Compute Engine instances and GKE node pools must carry a 'capacity-commitment' label documenting whether the resource is covered by Committed Use Discounts, Spot/Preemptible pricing, or On-Demand.

Scope: resource — google_compute_instance, google_container_node_pool

Assertions: * labels key exists — GCP compute instance missing 'capacity-commitment' label.

Remediation: Add 'capacity-commitment' label to all google_compute_instance and google_container_node_pool resources. Use CUD analysis to identify baseline workloads that should have Committed Use Discounts.

Compliant

resource "google_compute_instance" "app" {
  name         = "vm-payment-app"
  machine_type = "e2-standard-4"
  zone         = var.zone

  labels = merge(module.mandatory_tags.labels, {
    capacity-commitment = "cud-1yr"
    commitment-expiry   = "2026-03-01"
  })
}

Non-Compliant

resource "google_compute_instance" "app" {
  name         = "vm-payment-app"
  machine_type = "e2-standard-4"
  zone         = var.zone
  # Missing capacity-commitment label – on-demand assumed
}

waf-cost-080.tf.stackit.server-capacity-commitment-label

Engine: terraform | Provider: stackit | Automated: Yes

STACKIT compute resources must document capacity commitment decision

STACKIT compute resources must document capacity commitment decision. This check validates the Terraform configuration uses the expected resource and attribute.

Scope: resource — stackit_server, stackit_ske_cluster, stackit_ske_node_pool

Assertions: * labels key exists — STACKIT compute resource is missing the 'capacity-commitment' label.

Remediation: Review the Terraform configuration for the listed resource types and ensure the required attribute or tag is present. See the control narrative for provider-specific guidance.

Compliant

# Example resource meets the requirement.
resource "stackit_server" "example" {
  # required attribute/tag/label present
}

Non-Compliant

# Example resource does not meet the requirement.
resource "stackit_server" "example" {
  # Missing required attribute/tag/label
}

waf-cost-080.tf.ovh.instance-capacity-commitment-tag

Engine: terraform | Provider: ovh | Automated: Yes

OVHcloud compute resources must document capacity commitment decision

OVHcloud compute resources must document capacity commitment decision. This check validates the Terraform configuration uses the expected resource and attribute.

Scope: resource — ovh_cloud_project_instance, ovh_vps, ovh_dedicated_server

Assertions: * tags key exists — OVHcloud compute resource is missing the 'capacity-commitment' tag.

Remediation: Review the Terraform configuration for the listed resource types and ensure the required attribute or tag is present. See the control narrative for provider-specific guidance.

Compliant

# Example resource meets the requirement.
resource "ovh_cloud_project_instance" "example" {
  # required attribute/tag/label present
}

Non-Compliant

# Example resource does not meet the requirement.
resource "ovh_cloud_project_instance" "example" {
  # Missing required attribute/tag/label
}

waf-cost-080.tf.hcloud.server-capacity-commitment-label

Engine: terraform | Provider: hcloud | Automated: Yes

Hetzner Cloud compute resources must document capacity commitment decision

Hetzner Cloud compute resources must document capacity commitment decision. This check validates the Terraform configuration uses the expected resource and attribute.

Scope: resource — hcloud_server

Assertions: * labels key exists — Hetzner Cloud server is missing the 'capacity-commitment' label.

Remediation: Review the Terraform configuration for the listed resource types and ensure the required attribute or tag is present. See the control narrative for provider-specific guidance.

Compliant

# Example resource meets the requirement.
resource "hcloud_server" "example" {
  # required attribute/tag/label present
}

Non-Compliant

# Example resource does not meet the requirement.
resource "hcloud_server" "example" {
  # Missing required attribute/tag/label
}

Evidence

Kind Required Description

Kind	Required	Description
`iac`	Required	Terraform configuration implementing the control.
`governance`	Required	Policy, ADR, or standard documenting the requirement.
`config`	Optional	Cloud console or API output confirming runtime state.

iac

Required

Terraform configuration implementing the control.

governance

Required

Policy, ADR, or standard documenting the requirement.

config

Optional

Cloud console or API output confirming runtime state.

Related Controls

Framework	Controls
FinOps Foundation	* Optimize Phase – Rate Optimization and Commitment Management * Operate Phase – Commitment Planning and Renewal Management

Framework

Controls

FinOps Foundation

* Optimize Phase – Rate Optimization and Commitment Management * Operate Phase – Commitment Planning and Renewal Management