WAF-REL-010 – SLA & SLO Definition Documented

Säule: Reliability | Schweregrad: Kritisch | Kategorie: Logging Monitoring | Automatisierbar: High

Beschreibung

Every production workload MUST have documented Service Level Objectives (SLOs) and Service Level Agreements (SLAs). SLOs must define availability, latency, error rate, and throughput targets with explicit measurement windows. SLAs must reference SLOs and define consequences of non-compliance. Both documents must be version-controlled, reviewed quarterly, and linked to monitoring dashboards with automated alerting when error budgets are consumed.

Begründung

Risiko	Beschreibung
Risk	Workloads without documented SLOs cannot measure or communicate user impact.
Risk	Missing availability targets lead to inconsistent expectations between teams and stakeholders.

Risiko

Beschreibung

Risk

Workloads without documented SLOs cannot measure or communicate user impact.

Risk

Missing availability targets lead to inconsistent expectations between teams and stakeholders.

Anforderungen

Every production workload MUST have documented Service Level Objectives (SLOs) and Service Level Agreements (SLAs).
SLOs must define availability, latency, error rate, and throughput targets with explicit measurement windows.
SLAs must reference SLOs and define consequences of non-compliance.
Both documents must be version-controlled, reviewed quarterly, and linked to monitoring dashboards with automated alerting when error budgets are consumed.

Implementierungsleitfaden

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.

Reifegrade

Level	Name	Kriterien
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

Kriterien

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-rel-010.tf.aws.cloudwatch-slo-alarm

Engine: terraform | Provider: aws | Automated: Ja

AWS CloudWatch alarm must be configured for SLO availability monitoring

An Amazon CloudWatch alarm must be defined to track availability and trigger when the error rate exceeds the SLO threshold. This acts as the automated enforcement of the SLO monitoring requirement.

Scope: resource — aws_cloudwatch_metric_alarm

Assertions: * alarm_name not empty — CloudWatch alarm must have a descriptive name. * metric_name not empty — CloudWatch alarm must specify the metric to monitor. * alarm_actions not empty — CloudWatch alarm must have at least one action configured. * threshold attribute exists — CloudWatch alarm must define a threshold value.

Remediation: Define a CloudWatch alarm that monitors the primary SLO metric (e.g., error rate, latency). Configure alarm_actions to notify SNS topics used by on-call rotation.

Compliant

resource "aws_cloudwatch_metric_alarm" "slo_error_rate" {
  alarm_name          = "slo-payment-service-error-rate"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 5
  metric_name         = "5XXError"
  namespace           = "AWS/ApiGateway"
  period              = 60
  statistic           = "Sum"
  threshold           = 10
  alarm_description   = "SLO: error rate > 0.1% over 5 minutes"
  alarm_actions       = [aws_sns_topic.oncall.arn]
  ok_actions          = [aws_sns_topic.oncall.arn]
  treat_missing_data  = "notBreaching"
}

Non-Compliant

resource "aws_cloudwatch_metric_alarm" "error_alarm" {
  alarm_name          = "errors"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 1
  metric_name         = "Errors"
  namespace           = "AWS/Lambda"
  period              = 300
  statistic           = "Sum"
  threshold           = 100
  # Missing: alarm_actions – no one is notified
}

waf-rel-010.tf.azurerm.monitor-metric-alert-slo

Engine: terraform | Provider: azurerm | Automated: Ja

Azure Monitor metric alert must be configured for SLO monitoring

An Azure Monitor metric alert must be configured for each production workload to track availability and latency against SLO targets.

Scope: resource — azurerm_monitor_metric_alert

Assertions: * name not empty — Monitor alert must have a descriptive name. * criteria attribute exists — Monitor alert must define alert criteria. * action attribute exists — Monitor alert must have at least one action group configured.

Remediation: Configure an azurerm_monitor_metric_alert with criteria referencing the SLO metric and an action block pointing to an azurerm_monitor_action_group that notifies on-call.

Compliant

resource "azurerm_monitor_metric_alert" "slo_availability" {
  name                = "slo-api-availability"
  resource_group_name = azurerm_resource_group.main.name
  scopes              = [azurerm_application_insights.main.id]
  description         = "SLO: availability < 99.9%"
  severity            = 1
  criteria {
    metric_namespace = "microsoft.insights/components"
    metric_name      = "availabilityResults/availabilityPercentage"
    aggregation      = "Average"
    operator         = "LessThan"
    threshold        = 99.9
  }
  action {
    action_group_id = azurerm_monitor_action_group.oncall.id
  }
}

Non-Compliant

resource "azurerm_monitor_metric_alert" "alert" {
  name                = "alert"
  resource_group_name = azurerm_resource_group.main.name
  scopes              = [azurerm_application_insights.main.id]
  criteria {
    metric_namespace = "microsoft.insights/components"
    metric_name      = "requests/failed"
    aggregation      = "Count"
    operator         = "GreaterThan"
    threshold        = 100
  }
  # Missing: action – no notification configured
}

waf-rel-010.tf.google.monitoring-alert-policy-slo

Engine: terraform | Provider: google | Automated: Ja

GCP Monitoring alert policy must be configured for SLO tracking

A Google Cloud Monitoring alert policy must be configured to track SLO compliance and notify on-call when error budget burn rate exceeds thresholds.

Scope: resource — google_monitoring_alert_policy

Assertions: * display_name not empty — Alert policy must have a descriptive display name. * conditions not empty — Alert policy must define monitoring conditions. * notification_channels not empty — Alert policy must have notification channels configured.

Remediation: Define a google_monitoring_alert_policy with conditions referencing the SLO metric and notification_channels pointing to configured channels (PagerDuty, email, etc.).

Compliant

resource "google_monitoring_alert_policy" "slo_burn_rate" {
  display_name = "SLO Error Budget Burn Rate – Payment API"
  combiner     = "OR"
  conditions {
    display_name = "Fast burn: >14x for 1h"
    condition_threshold {
      filter          = "select_slo_burn_rate(\"projects/${var.project}/services/payment-api/serviceLevelObjectives/availability\", 3600)"
      comparison      = "COMPARISON_GT"
      threshold_value = 14.4
      duration        = "0s"
    }
  }
  notification_channels = [google_monitoring_notification_channel.oncall.name]
  alert_strategy {
    notification_rate_limit { period = "300s" }
  }
}

Non-Compliant

resource "google_monitoring_alert_policy" "errors" {
  display_name = "Errors"
  combiner     = "OR"
  conditions {
    display_name = "Error count"
    condition_threshold {
      filter          = "metric.type=\"logging.googleapis.com/user/errors\""
      comparison      = "COMPARISON_GT"
      threshold_value = 100
      duration        = "60s"
    }
  }
  # Missing: notification_channels – alert fires silently
}

waf-rel-010.tf.stackit.availability-slo-defined

Engine: terraform | Provider: stackit | Automated: Ja

Every production workload for stackit

Every production workload must be documented in IaC via a availability-slo-defined tag/label on stackit_project. This validates the control is tracked as code.

Scope: resource — stackit_project

Assertions: * labels key exists — stackit_project is missing the availability-slo-defined tag/label.

Remediation: Add a availability-slo-defined tag/label to the stackit_project resource to show the stackit implementation of WAF-REL-010 is tracked in IaC.

Compliant

resource "stackit_project" "example" {
  labels = {
    availability-slo-defined = "true"
  }
}

Non-Compliant

resource "stackit_project" "example" {
  # Missing availability-slo-defined labels
}

waf-rel-010.tf.ovh.availability-slo-defined

Engine: terraform | Provider: ovh | Automated: Ja

Every production workload for ovh

Every production workload must be documented in IaC via a availability-slo-defined tag/label on ovh_cloud_project. This validates the control is tracked as code.

Scope: resource — ovh_cloud_project

Assertions: * tags key exists — ovh_cloud_project is missing the availability-slo-defined tag/label.

Remediation: Add a availability-slo-defined tag/label to the ovh_cloud_project resource to show the ovh implementation of WAF-REL-010 is tracked in IaC.

Compliant

resource "ovh_cloud_project" "example" {
  tags = {
    availability-slo-defined = "true"
  }
}

Non-Compliant

resource "ovh_cloud_project" "example" {
  # Missing availability-slo-defined tags
}

waf-rel-010.tf.hcloud.availability-slo-defined

Engine: terraform | Provider: hcloud | Automated: Ja

Every production workload for hcloud

Every production workload must be documented in IaC via a availability-slo-defined tag/label on hcloud_server. This validates the control is tracked as code.

Scope: resource — hcloud_server

Assertions: * labels key exists — hcloud_server is missing the availability-slo-defined tag/label.

Remediation: Add a availability-slo-defined tag/label to the hcloud_server resource to show the hcloud implementation of WAF-REL-010 is tracked in IaC.

Compliant

resource "hcloud_server" "example" {
  labels = {
    availability-slo-defined = "true"
  }
}

Non-Compliant

resource "hcloud_server" "example" {
  # Missing availability-slo-defined labels
}

Evidenz

Art Erforderlich Beschreibung

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

iac

Erforderlich

Terraform configuration implementing the control.

governance

Erforderlich

Policy, ADR, or standard documenting the requirement.

config

Optional

Cloud console or API output confirming runtime state.

WAF-REL-010 – SLA & SLO Definition Documented

Beschreibung

Begründung

Anforderungen

Implementierungsleitfaden

Reifegrade

Checks

waf-rel-010.tf.aws.cloudwatch-slo-alarm

waf-rel-010.tf.azurerm.monitor-metric-alert-slo

waf-rel-010.tf.google.monitoring-alert-policy-slo

waf-rel-010.tf.stackit.availability-slo-defined

waf-rel-010.tf.ovh.availability-slo-defined

waf-rel-010.tf.hcloud.availability-slo-defined

Evidenz

Verwandte Controls