WAF-SUS-060 – Workload Scheduling & Time-Shifting

Pillar: Sustainability | Severity: Low | Category: Deployment Automation | Automatable: High

Description

Batch workloads, report generation, data processing pipelines, and other non-latency-sensitive jobs MUST be scheduled during off-peak hours (22:00–06:00 local grid time) when carbon intensity of the electricity grid is typically lower. Workloads with flexible execution windows SHOULD integrate carbon intensity APIs (WattTime, electricityMaps) to execute during low-carbon windows. All EventBridge scheduled jobs and cron-based workloads MUST document their scheduling rationale including whether carbon-aware timing was considered.

Rationale

Risk	Description
Risk	Batch jobs without flexible time windows consume peak-load capacity and miss renewable-energy potential.
Risk	Missing spot or scheduler optimization leads to expensive and carbon-intensive processing.

Risk

Description

Risk

Batch jobs without flexible time windows consume peak-load capacity and miss renewable-energy potential.

Risk

Missing spot or scheduler optimization leads to expensive and carbon-intensive processing.

Requirements

Batch workloads, report generation, data processing pipelines, and other non-latency-sensitive jobs MUST be scheduled during off-peak hours (22:00–06:00 local grid time) when carbon intensity of the electricity grid is typically lower.
Workloads with flexible execution windows SHOULD integrate carbon intensity APIs (WattTime, electricityMaps) to execute during low-carbon windows.
All EventBridge scheduled jobs and cron-based workloads MUST document their scheduling rationale including whether carbon-aware timing was considered.

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-sus-060.tf.aws.eventbridge-flexible-window

Engine: terraform | Provider: aws | Automated: Yes

EventBridge Scheduler schedules should use flexible time windows for batch workloads

EventBridge Scheduler supports a flexible_time_window that allows AWS to execute the schedule within a defined window around the target time. This enables carbon-aware execution: the job can be deferred to a lower-carbon window within the allowed range.

Scope: resource — aws_scheduler_schedule

Assertions: * flexible_time_window.mode not equals False — EventBridge schedule uses no flexible window – enable FLEXIBLE mode to allow carbon-aware execution.

Remediation: Set flexible_time_window { mode = "FLEXIBLE"; maximum_window_in_minutes = 120 } on all non-latency-sensitive batch schedules. This allows AWS to execute the job within a 2-hour window, enabling carbon-aware timing without missing SLAs.

Compliant

resource "aws_scheduler_schedule" "nightly_report" {
  name = "nightly-report-generator"

  schedule_expression = "cron(0 22 * * ? *)"  # 22:00 UTC – off-peak window

  flexible_time_window {
    mode                      = "FLEXIBLE"
    maximum_window_in_minutes = 120  # allow up to 2h window for carbon-aware exec
  }

  target {
    arn      = aws_lambda_function.report_generator.arn
    role_arn = aws_iam_role.scheduler.arn
  }
}

Non-Compliant

resource "aws_scheduler_schedule" "nightly_report" {
  name = "nightly-report-generator"

  schedule_expression = "cron(9 9 * * ? *)"  # 09:00 – peak hours, no reason documented

  flexible_time_window {
    mode = "OFF"  # WAF-SUS-060 Warning: no flexible window, fixed peak-time execution
  }
}

waf-sus-060.tf.aws.batch-compute-spot

Engine: terraform | Provider: aws | Automated: Yes

AWS Batch compute environments should use SPOT allocation strategy

AWS Batch jobs are by definition batch/asynchronous workloads that can tolerate spot interruption. Using SPOT allocation strategy reduces energy consumption from dedicated on-demand capacity and improves overall data center utilization efficiency.

Scope: resource — aws_batch_compute_environment

Assertions: * compute_resources.type in ['SPOT'] — Batch compute environment uses ON_DEMAND – consider SPOT for batch workloads to reduce energy overhead.

Remediation: Change compute_resources.type to "SPOT" for AWS Batch compute environments. Configure spot_iam_fleet_role and bid_percentage = 100 to maximize spot usage. Implement retry policies on batch jobs to handle spot interruptions gracefully.

Compliant

resource "aws_batch_compute_environment" "processing" {
  compute_environment_name = "data-processing"
  type                     = "MANAGED"

  compute_resources {
    type                = "SPOT"
    allocation_strategy = "SPOT_CAPACITY_OPTIMIZED"
    instance_role       = aws_iam_instance_profile.batch.arn
    spot_iam_fleet_role = aws_iam_role.spot_fleet.arn

    min_vcpus     = 0
    max_vcpus     = 256
    desired_vcpus = 0

    instance_type = ["m7g", "c7g", "r7g"]  # Graviton3 spot instances
  }
}

Non-Compliant

resource "aws_batch_compute_environment" "processing" {
  compute_environment_name = "data-processing"
  type                     = "MANAGED"

  compute_resources {
    type      = "ON_DEMAND"  # WAF-SUS-060 Warning: batch workload on on-demand
    min_vcpus = 4  # always-on capacity
    max_vcpus = 64
  }
}

waf-sus-060.tf.google.cloud-scheduler-timezone

Engine: terraform | Provider: google | Automated: Yes

GCP Cloud Scheduler jobs should use UTC timezone and off-peak scheduling

GCP Cloud Scheduler jobs should be scheduled in UTC timezone to enable consistent off-peak scheduling aligned with grid carbon intensity data.

Scope: resource — google_cloud_scheduler_job

Assertions: * time_zone equals Etc/UTC — Cloud Scheduler job uses local timezone – use UTC for consistent carbon-aware scheduling.

Remediation: Set time_zone = "Etc/UTC" on all Cloud Scheduler jobs and adjust schedule expressions to target off-peak UTC hours (22:00-06:00 UTC). This ensures consistency with carbon intensity data which is typically published in UTC.

Compliant

resource "google_cloud_scheduler_job" "data_export" {
  name      = "nightly-data-export"
  schedule  = "0 23 * * *"  # 23:00 UTC – off-peak hours
  time_zone = "Etc/UTC"

  http_target {
    uri         = var.export_endpoint
    http_method = "POST"
  }
}

Non-Compliant

resource "google_cloud_scheduler_job" "data_export" {
  name      = "data-export"
  schedule  = "0 9 * * *"  # 09:00 – peak hours
  time_zone = "Europe/Berlin"  # WAF-SUS-060 Warning: local timezone, peak hours
}

waf-sus-060.tf.azurerm.automation-schedule-offpeak

Engine: terraform | Provider: azurerm | Automated: Yes

Azure Automation schedules for batch workloads should run during off-peak hours

Azure Automation runbook schedules for batch, report generation, and data processing workloads should be configured to start during off-peak hours (e.g., between 22:00 and 06:00 local time) to reduce carbon intensity.

Scope: resource — azurerm_automation_schedule

Assertions: * start_time matches pattern T(0[0-6]|2[23]): — Azure Automation schedule start_time should be during off-peak hours (22:00-06:59 UTC or equivalent timezone).

Remediation: Set azurerm_automation_schedule.start_time to an off-peak hour (e.g., 02:00 UTC) and configure frequency appropriately for batch workloads.

Compliant

resource "azurerm_automation_schedule" "nightly_batch" {
  name                    = "nightly-batch"
  resource_group_name     = azurerm_resource_group.main.name
  automation_account_name = azurerm_automation_account.main.name
  frequency               = "Day"
  interval                = 1
  start_time              = "2024-01-01T02:00:00Z"
  timezone                = "Europe/Berlin"
}

Non-Compliant

resource "azurerm_automation_schedule" "daytime_batch" {
  name                    = "daytime-batch"
  resource_group_name     = azurerm_resource_group.main.name
  automation_account_name = azurerm_automation_account.main.name
  frequency               = "Day"
  interval                = 1
  start_time              = "2024-01-01T14:00:00Z"
  timezone                = "Europe/Berlin"
}

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
Green Software Foundation	* Carbon Aware Computing – Temporal Shifting * Software Carbon Intensity (SCI) – time-based carbon optimization
EU CSRD (Corporate Sustainability Reporting Directive)	* ESRS E1 – Climate Change – operational energy optimization
GHG Protocol	* Scope 2 – Market-based method – time-of-use carbon intensity

Framework

Controls

Green Software Foundation

* Carbon Aware Computing – Temporal Shifting * Software Carbon Intensity (SCI) – time-based carbon optimization

EU CSRD (Corporate Sustainability Reporting Directive)

* ESRS E1 – Climate Change – operational energy optimization

GHG Protocol

* Scope 2 – Market-based method – time-of-use carbon intensity