Skip to content

Align the zombie NAT detection window with the 60-day fix criterion - #173

Merged
OptimNow merged 1 commit into
mainfrom
claude/happy-kilby-af299e
Aug 20, 2026
Merged

Align the zombie NAT detection window with the 60-day fix criterion#173
OptimNow merged 1 commit into
mainfrom
claude/happy-kilby-af299e

Conversation

@OptimNow

Copy link
Copy Markdown
Owner

What

Fixes an internal inconsistency in skills/cloud-finops/playbooks/aws-zombie-nat-gateway.md, surfaced by the 2026-08-20 coverage probe: the Detection section's Athena/CUR query filtered to the last full month only, while Fix step 1 required confirming < 5 GB/month over a 60-day window ("one month can be misleading - some workloads run quarterly"). An agent walking a user through the playbook hits a query that cannot satisfy the fix criterion it feeds.

How

  • The query's WHERE window widens from interval '1' month to interval '2' month (still bounded at the start of the current month, so it covers the last two full months, roughly 60 days).
  • Traffic is now selected as gb_per_month (total over the window divided by 2, a monthly average), so the < 5 GB/month threshold in the HAVING clause and the CloudWatch symptom keep identical semantics.
  • cost_month is renamed cost_period to match the wider window.
  • The leading comment states why the window is deliberately 60 days.
  • Fix step 1 now points back at the query's window instead of implying a second, wider query is needed.

The COALESCE NULL-traffic guard from #166 is preserved (both SELECT and HAVING).

Scope

Content PR: no version bumps, no frontmatter changes (so playbook-coverage.md is unaffected), structure / British spelling / footer intact. The 14-day quick-screen variant of this query in references/finops-waste-detection-playbooks.md is a deliberately different first-pass screen and is untouched (a separate defect there - the NULL-blind SUM that #166 fixed in the playbooks - has been flagged as its own follow-up task).

The Athena/CUR query screened only the last full month while Fix step 1
required confirming < 5 GB/month over 60 days - an internal inconsistency
flagged by the 2026-08-20 coverage probe. The query now spans the last
two full months, expresses traffic as gb_per_month (monthly average, so
the < 5 GB/month threshold reads unchanged), renames cost_month to
cost_period, and Fix step 1 points back at the query's window instead of
implying a second wider query.
@OptimNow
OptimNow merged commit 200e0d5 into main Aug 20, 2026
3 checks passed
@OptimNow
OptimNow deleted the claude/happy-kilby-af299e branch August 20, 2026 15:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant