WAF-REL-050 – Circuit Breaker & Timeout Configuration

Pillar: Reliability | Severity: High | Category: Data Governance | Automatable: High

Description

All inter-service and downstream HTTP/gRPC calls MUST define explicit timeout values. Critical service dependencies MUST implement circuit breaker patterns. Retry logic MUST use exponential backoff with jitter. Connection pools MUST have defined maximum sizes. Services MUST implement bulkhead isolation for different dependency classes. No service may rely on default (infinite or undefined) timeouts for external calls.

Rationale

Risk	Description
Risk	Unbounded timeouts and retries cascade failures into downstream systems and extend outages.
Risk	Missing circuit breakers let workloads remain in perpetual failure states when downstream breaks.

Risk

Description

Risk

Unbounded timeouts and retries cascade failures into downstream systems and extend outages.

Risk

Missing circuit breakers let workloads remain in perpetual failure states when downstream breaks.

Requirements

All inter-service and downstream HTTP/gRPC calls MUST define explicit timeout values.
Critical service dependencies MUST implement circuit breaker patterns.
Retry logic MUST use exponential backoff with jitter.
Connection pools MUST have defined maximum sizes.
Services MUST implement bulkhead isolation for different dependency classes.

Implementation Guidance

Implement the required configuration as code in Terraform or equivalent IaC.
Add an automated check to CI/CD so deviations are caught before deployment.

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-rel-050.tf.aws.alb-idle-timeout

Engine: terraform | Provider: aws | Automated: Yes

AWS ALB idle timeout must be explicitly configured

ALB idle_timeout must be set to a value appropriate for the workload, not relying on the default 60 seconds which may be too long or too short.

Scope: resource — aws_lb

Assertions: * idle_timeout attribute exists — ALB idle_timeout must be explicitly configured, not using default. * load_balancer_type equals application — This check applies to Application Load Balancers.

Remediation: Set idle_timeout on the aws_lb resource. Typical values: 30s for APIs, 300s for file uploads. Align with client-side timeout configuration.

Compliant

resource "aws_lb" "api" {
  name               = "payment-api-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb.id]
  subnets            = var.public_subnet_ids
  idle_timeout       = 30

  tags = var.mandatory_tags
}

Non-Compliant

resource "aws_lb" "api" {
  name               = "payment-api-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb.id]
  subnets            = var.public_subnet_ids
  # Missing: idle_timeout – using AWS default of 60s
  # WAF-REL-050 violation
}

waf-rel-050.tf.azurerm.app-gateway-timeout

Engine: terraform | Provider: azurerm | Automated: Yes

Azure Application Gateway backend settings must define explicit timeouts

Azure Application Gateway backend HTTP settings must define request_timeout_in_seconds rather than relying on defaults.

Scope: resource — azurerm_application_gateway

Assertions: * backend_http_settings attribute exists — Application Gateway must define backend_http_settings. * backend_http_settings.request_timeout_in_seconds attribute exists — Backend HTTP settings must define explicit request_timeout_in_seconds.

Remediation: Set request_timeout_in_seconds in the backend_http_settings block. Recommended values: 30 for APIs, 120 for batch operations.

Compliant

resource "azurerm_application_gateway" "main" {
  name                = "payment-appgw"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location

  backend_http_settings {
    name                  = "api-backend-settings"
    cookie_based_affinity = "Disabled"
    port                  = 8080
    protocol              = "Http"
    request_timeout_in_seconds = 30
  }
  # ... other required blocks
}

Non-Compliant

resource "azurerm_application_gateway" "main" {
  name                = "payment-appgw"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location

  backend_http_settings {
    name                  = "api-backend-settings"
    cookie_based_affinity = "Disabled"
    port                  = 8080
    protocol              = "Http"
    # Missing: request_timeout_in_seconds
    # WAF-REL-050 violation
  }
}

waf-rel-050.tf.google.cloud-run-timeout

Engine: terraform | Provider: google | Automated: Yes

GCP Cloud Run services must define explicit request timeout

GCP Cloud Run service templates must define timeout_seconds to prevent runaway requests from consuming resources indefinitely.

Scope: resource — google_cloud_run_service, google_cloud_run_v2_service

Assertions: * template.spec.timeout_seconds attribute exists — Cloud Run service must define timeout_seconds in the template spec.

Remediation: Set timeout_seconds in the template.spec block of google_cloud_run_service. Default is 300s; set to the appropriate value for your workload latency SLO.

Compliant

resource "google_cloud_run_service" "api" {
  name     = "payment-api"
  location = var.region

  template {
    spec {
      timeout_seconds = 30
      containers {
        image = var.container_image
        resources {
          limits = { cpu = "1000m", memory = "512Mi" }
        }
      }
    }
  }
}

Non-Compliant

resource "google_cloud_run_service" "api" {
  name     = "payment-api"
  location = var.region

  template {
    spec {
      # Missing: timeout_seconds – using default 300s
      # WAF-REL-050 violation
      containers {
        image = var.container_image
      }
    }
  }
}

waf-rel-050.tf.stackit.multi-az-workloads

Engine: terraform | Provider: stackit | Automated: Yes

STACKIT production workloads must span multiple availability zones

STACKIT production workloads must span multiple availability zones. This check validates the Terraform configuration uses the expected resource and attribute.

Scope: resource — stackit_ske_cluster, stackit_ske_node_pool, stackit_load_balancer

Assertions: * availability_zones attribute exists — STACKIT production workload must define availability zones.

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_ske_cluster" "example" {
  # required attribute/tag/label present
}

Non-Compliant

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

waf-rel-050.tf.ovh.multi-region-workloads

Engine: terraform | Provider: ovh | Automated: Yes

OVHcloud production workloads must span multiple regions or zones

OVHcloud production workloads must span multiple regions or zones. This check validates the Terraform configuration uses the expected resource and attribute.

Scope: resource — ovh_cloud_project_kube, ovh_cloud_project_kube_nodepool, ovh_cloud_project_instance

Assertions: * region attribute exists — OVHcloud production workload must define a region for resilience planning.

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_kube" "example" {
  # required attribute/tag/label present
}

Non-Compliant

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

waf-rel-050.tf.hcloud.multi-location-workloads

Engine: terraform | Provider: hcloud | Automated: Yes

Hetzner Cloud production workloads must span multiple locations

Hetzner Cloud production workloads must span multiple locations. This check validates the Terraform configuration uses the expected resource and attribute.

Scope: resource — hcloud_server, hcloud_placement_group, hcloud_load_balancer

Assertions: * labels.resilience-zone key exists — Hetzner Cloud production workload must declare a resilience-zone 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
ISO 27001:2022	* A.17.1 – Information security continuity
ITIL 4	* Service Continuity Management * Problem Management
SRE Book (Google)	* Chapter 22 – Addressing Cascading Failures

Framework

Controls

ISO 27001:2022

* A.17.1 – Information security continuity

ITIL 4

* Service Continuity Management * Problem Management

SRE Book (Google)

* Chapter 22 – Addressing Cascading Failures