agentleFS
stevancrisstevancris/sre-ai-agent/skills/cost-optimization/SKILL.md

cost-optimization

Skill0 starsChanged 5 months agoMITView on GitHub

Identify and reduce cloud infrastructure costs without compromising reliability. Use when reviewing cloud bills, investigating cost spikes, rightsizing resources, planning Reserved Instance or Savings Plan purchases, or building a FinOps practice. Trigger keywords: cost, cloud bill, spend, rightsizing, reserved instances, savings plans, waste, idle resources, FinOps, cost anomaly, budget alert, expensive, overprovisioned, underutilized, cost spike, cloud spend, AWS cost, GCP cost, monthly bill, reduce spend.

19 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use git-workflow and code-review.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • Microsoft AzureSkill

    git-workflow

    Squad branching model: dev-first workflow with insiders preview channel

    Also in 3 projects that use this

  • GoogleSkill

    code-review

    Adversarial systems, concurrency, memory-model, and architecture code review protocol. Use this skill whenever asked to review code, PRs, diffs, or branches in Filament.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

7 rules. 0 are common, 5 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 16 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Before loading context files, check if context/CONTEXT.md exists in the current directory.

    line 17
  2. Distinctive:

    Use the answers inline for this session.

    line 29
  3. Very specific:

    Read context/company/tech-stack.md for cloud provider and platform.

    line 38
  4. Distinctive:

    Ask the user to share:

    line 41
  5. Distinctive:

    Check if cluster autoscaler is configured and working.

    line 95
  6. Distinctive:

    Check node utilization: if < 40% average, the cluster may be over-provisioned.

    line 97
  7. Distinctive:

    Never recommend a cost saving that introduces a reliability risk without explicitly stating the trade-off and getting confirmation.

    line 138

“Common” is measured: kept by at least 6 in 10 of the 16 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Cost Optimization Skill

Setup Check

Before loading context files, check if context/CONTEXT.md exists in the current directory.

If context/CONTEXT.md exists — read it and proceed normally.

If context/CONTEXT.md does not exist — this skill was installed standalone (e.g. via npx skills add). Ask the user these questions before proceeding:

  1. Role — junior-sre / senior-sre / sre-manager (shapes output depth and tone)
  2. Cloud provider — aws / gcp / azure / on-prem / hybrid
  3. Observability stack — e.g. Datadog, Prometheus+Grafana, New Relic
  4. Company name and primary services affected (if relevant to this task)

Use the answers inline for this session. For persistent setup across all skills, suggest:

pipx install sre-agent
sre-agent init

Instructions

Step 1: Load Context

Read context/company/tech-stack.md for cloud provider and platform.

Step 2: Identify Cost Drivers

Ask the user to share:

  • Top cost categories from the billing dashboard (compute, storage, data transfer, etc.)
  • Any recent cost spikes (when and how much)
  • Current monthly total and recent trend

Classify costs into:

CategoryTypical % of billOptimization potential
Compute (EC2/GCE/VMs)40–60%High
Managed services (RDS, ElastiCache)15–25%Medium
Storage (S3, EBS, GCS)5–15%Medium
Data transfer / egress5–20%Variable
Kubernetes (EKS/GKE)10–20%High
Logging / observability5–15%Medium

Step 3: Waste Identification

Idle resources:

  • EC2/VM instances with CPU < 5% sustained
  • Unattached EBS volumes
  • Unused Elastic IPs
  • Unused load balancers
  • Old snapshots (> 90 days with no restore)
  • Dev/staging resources running 24/7 (schedule to turn off nights/weekends)

Overprovisioned resources:

  • Instances where CPU is consistently < 20% and memory < 40%
  • Database instances with < 20% utilization
  • Over-specified Kubernetes resource requests (pod requests >> actual usage)
  • EBS volumes that are only 20–30% full but sized for 10x current data

On-demand vs. commitment opportunity:

  • Instances running > 3 months on-demand → Reserved Instance or Savings Plan candidate
  • Steady-state workloads → Compute Savings Plans (1-year, no-upfront)
  • Flexible workloads → Spot Instances (batch jobs, CI/CD workers, stateless services)

Step 4: Rightsizing Analysis

For compute rightsizing:

Rightsizing recommendation logic:
  If avg CPU < 20% and avg memory < 40%:
    → Downsize to next smaller instance type
  If avg CPU > 70% or avg memory > 80%:
    → This is correctly sized or may need upsizing
  If CPU is high but memory is low:
    → Consider compute-optimized instance type
  If memory is high but CPU is low:
    → Consider memory-optimized instance type

Step 5: Kubernetes Cost Optimization

  • Compare pod resource requests vs. actual usage (Vertical Pod Autoscaler recommendations).
  • Identify namespaces or workloads with no resource limits (risk of resource starvation and overspend).
  • Check if cluster autoscaler is configured and working.
  • Evaluate whether Spot/Preemptible nodes can be used for non-critical workloads.
  • Check node utilization: if < 40% average, the cluster may be over-provisioned.

Step 6: Storage Optimization

  • S3: lifecycle rules to transition to Infrequent Access after 30 days, Glacier after 90 days.
  • EBS: delete unattached volumes, rightsize over-provisioned volumes.
  • Log retention: audit log retention periods (7 days for debug logs, 30 days for info, 1 year for audit).
  • Old snapshots: automate deletion of snapshots older than retention policy.

Step 7: Generate Recommendations

Rank by: (monthly savings) × (implementation ease) / (reliability risk)

Recommendation Report — Cloud Cost Optimization

Current monthly spend: $XX,XXX
Potential savings identified: $X,XXX/month (XX%)

Priority 1: Reserved Instances for steady-state EC2 (save ~$1,200/mo)
  Risk: Low | Effort: Low (1-click purchase) | Payback: immediate
  Action: Purchase 1-year no-upfront Compute Savings Plan for $X commit/hr

Priority 2: Schedule dev/staging environment off-hours (save ~$800/mo)
  Risk: None | Effort: Low | Payback: immediate
  Action: Lambda function to stop instances 6pm–8am weekdays, all weekend

Priority 3: Rightsize 8 overprovisioned RDS instances (save ~$600/mo)
  Risk: Medium (test in staging first) | Effort: Medium
  Action: See rightsizing table below

Priority 4: S3 lifecycle rules for logs bucket (save ~$200/mo)
  Risk: None | Effort: Low
  Action: Add lifecycle rule: IA after 30d, Glacier after 90d

Total addressable: ~$2,800/month (~28% reduction)

Guidelines

  • Never recommend a cost saving that introduces a reliability risk without explicitly stating the trade-off and getting confirmation.
  • Spot instances are only appropriate for stateless, fault-tolerant workloads.
  • Reserved Instances are a financial commitment — confirm with finance/management before purchasing.
  • Persona (sre-manager): frame the savings as ROI and include the time to implement each item. Calculate cost of engineering time to implement vs. expected savings.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.