Carbon-Aware Routing

License: pro tier and above. See Licensing. Reference: step semantics, blend math, and query-tracer output are in docs/reference/FilterChains.md.

Nobody else in the GSLB space routes on carbon. ESG procurement questionnaires increasingly ask "does your infrastructure account for carbon intensity?" — with Nexus, the honest answer is yes, and it's a one-line filter-chain step, not a research project.

signal-weight biases DNS answers toward the region with the lower configured value — carbon intensity (gCO2/kWh), a cost table for expensive egress or spot regions, or any scalar where lower is better. It's a bias, not a hard rule: a healthy member in a "worse" region is never excluded, only deprioritized. The same mechanism works for either use case — swap the numbers, not the code.

No external API required for v1: you supply the per-region table yourself, either from a public carbon-intensity source (ElectricityMaps, WattTime) you check periodically, or from your own cost/procurement data.

Step 1 — Configure your zone table

Add to config.yaml on every node (or via GitOps):

signals:  static:    us-east: 450   # gCO2/kWh, or any unit you like — lower wins    eu-west: 120    ap-south: 610  weight: 0.5      # 0 disables the bias; 1 lets it dominate. Default 0.5.

systemctl reload gslbd (or wait for GitOps to apply it) — no restart needed. Zones map to your members' existing region field, the same one geo-ip routing already uses.

Step 2 — Add the step to a service's filter chain

WebUI: open the service, switch to filter chain mode, add Signal Weight (carbon/cost) — place it after any narrowing steps (like geo-ip) and before the terminal selector.

API / Terraform:

{  "filterChain": ["geo-ip", "signal-weight", "weighted-round-robin"]}
resource "nexus_service" "web" {
  filter_chain = ["geo-ip", "signal-weight", "weighted-round-robin"]
}

Step 3 — See it working

  • Query tracer (gslbctl trace <service-id> or the WebUI trace panel) shows the zone values it used and whether it actually reordered anything.

  • Signal Weight page under Infrastructure in the WebUI (or gslbctl signals list) shows the live configured table.

  • Metrics: gslbd_signal_zone_value{zone} (the configured table) and gslbd_signal_queries_steered_total{service} — an honest count of queries where the bias actually changed the answer. That's your "X% of traffic steered toward lower-carbon regions" number for a press release or an ESG questionnaire — computed from real routing decisions, not a marketing estimate.

The Tuning Knob

weight controls how strongly the signal competes with health/latency scoring:

  • 0.0 — disabled (same as omitting the step).

  • 0.2–0.4 — tiebreaker: only reorders candidates that were already close in score.

  • 1.0 — dictator: the lowest-signal healthy candidate always wins.

Most operators want a tiebreaker, not a dictator — start low and raise it once you've watched the query tracer confirm it's doing what you expect.

Notes

  • A member with no region set (or a region with no configured signal value) is never penalized — it keeps its original score and competes fairly on the rest.

  • A future version may add a live feed poller (ElectricityMaps, WattTime) so the table updates itself; today it's operator-maintained, which also means it works air-gapped with zero external dependency.

Was this article helpful?