Neptune clusters answering no graph queries in any language

Absence of request metrics is the signal, not a gap

Neptune has an unusual CloudWatch behaviour that shapes this whole rule: among the series it publishes it sends GremlinRequestsPerSec, SparqlRequestsPerSec and OpenCypherRequestsPerSec only when the value is non-zero. A genuinely idle cluster therefore has few or zero datapoints on those series across the entire window, and that empty series is the evidence of no queries.

An earlier revision of this rule missed that, requiring each request axis to carry 30 days of its own datapoints. A non-zero-only metric can never accumulate coverage on an idle cluster, so the rule abstained on exactly the clusters it existed to find. The current logic treats an absent request series as idle-consistent, and vetoes the finding the moment any present series shows an average or peak at or above 0.10 requests per second.

CPU anchors the 30-day evidence window

Since silence on the query axes proves nothing about whether telemetry is even flowing, the evidence window rides on CPUUtilization instead, a series a running Neptune instance reports continuously. The rule requires it to be present, covered for at least 30 days, and under 5% on both average and peak. A cluster answering no queries but burning CPU on replication or a scheduled bulk load is doing real work, and deleting it would be wrong; missing or under-covered CPU means the window itself cannot be trusted. Either way: abstain.

The openCypher axis is declared but not yet harvested

The openCypher floor of 0.10 requests per second is wired into the rule, but the metrics pipeline does not collect that series yet. Today the axis is always absent, which reads as idle-consistent, so an openCypher-only cluster with heavy traffic is protected only by the 5% CPU veto until the collector lands. Once it does, the same gate becomes a real per-language veto with no rule change.

Query the Gremlin request rate yourself

aws cloudwatch get-metric-statistics \
  --namespace AWS/Neptune --metric-name GremlinRequestsPerSec \
  --dimensions Name=DBClusterIdentifier,Value=my-graph-cluster \
  --start-time "$(date -u -v-30d +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 86400 --statistics Average Maximum

An empty result is expected for an idle cluster, given the non-zero-only publishing. Check SparqlRequestsPerSec and CPUUtilization the same way.

What the Neptune saving covers

The dollar figure is the cluster’s single-instance compute run-rate: it excludes the standing storage and I/O lines Neptune bills alongside compute and is not multiplied by instance count. Deleting recovers all of it. With no priced cost the rule reports nothing. Snapshot the cluster before removal, and weigh Neptune Serverless if the workload is intermittent rather than gone.