Stop Pasting AWS CLI Commands Into Prod — Let Your Agent Fix the Code Instead

Every scanner gives you a finding. Almost none of them give you a safe way to fix it.

Run any cost/carbon scanner — including GreenOps Scan's own --fix-commands — and you eventually hit the same wall: the tool hands you a ready-to-run aws CLI command, and now you have a choice. Paste it into a terminal against production and hope nothing drifts, or open a ticket, find the Terraform module or CDK stack that actually defines the resource, make the change by hand, and wait for a PR review.

Most engineers don't do either. The finding sits in a backlog, the resource stays oversized, and the "quick fix" command rots in a .sh file nobody trusts anymore.

The real problem isn't that remediation commands are hard to generate — it's that running them directly mutates a resource your infrastructure-as-code thinks it owns. The next terraform apply or cdk deploy either silently reverts your fix or fights with it. That's not a remediation workflow, it's a ticking time bomb.

GreenOps Scan's new --llm-prompts flag takes a different approach: instead of a command to run against the live resource, it gives you a prompt to hand to your coding agent — the same one you already use to write code — telling it to find the resource in your actual source and fix it there.

How it works

Add --llm-prompts to any scan (it only affects the default human output, and it's off by default so normal scans stay compact):

npx greenops-scan --profile production --region eu-west-1 --severity critical --llm-prompts

Every finding gets its usual YAML-like summary, plus a clearly delimited, copy/paste-ready prompt underneath it:

  - severity: CRITICAL
    module: RDS
    resource: prod-orders-db
    resourceType: RDS Instance
    region: eu-west-1
    issue: Idle database — avg CPU 4.3% over 14 days
    costSavings: $49.64/mo
    confidence: MED
    co2Savings: 1.48 kg/mo
    recommendation: Consider stopping, downsizing, or consolidating this database
    ----- COPY BELOW: LLM fix prompt -----
    Fix this AWS cost/carbon finding in my infrastructure as code (Terraform, AWS CDK,
    CloudFormation, Pulumi, Serverless Framework, or whatever this repo uses) — do not
    change the live resource via the AWS CLI or console, make the change in code so it
    stays in sync with the rest of the stack:

    Resource: RDS Instance "prod-orders-db" (region: eu-west-1)
    Module: rds
    Issue: Idle database — avg CPU 4.3% over 14 days
    Recommendation: Consider stopping, downsizing, or consolidating this database
    Estimated savings: $49.64/mo ($595.68/yr), 1.48 kg CO2/mo
    Context:
      - avgCpuPercent: 4.3
      - instanceClass: "db.t3.medium"
      - engine: "postgres"

    Please:
    1. Search this repository for where "prod-orders-db" (or a matching tag/logical
       name) is defined in infrastructure-as-code.
    2. Apply the change described in the recommendation above, keeping all other
       configuration unchanged.
    3. Show me the diff before applying/deploying anything — do not run
       `terraform apply`, `cdk deploy`, or equivalent without my review.
    4. If you can't find this resource in the codebase, tell me instead of guessing.
    ----- COPY ABOVE -----

Copy everything between the markers, paste it into GitHub Copilot, Claude, Cursor, or any tool-calling LLM with access to your repository, and it will:

1. Grep/search for the resource by ID, tag, or logical name across your Terraform, CDK, CloudFormation, Pulumi, or Serverless Framework source.
2. Make the equivalent change — right-size the instance class, add the lifecycle rule, remove the orphaned resource — in code.
3. Show you a diff instead of silently applying anything.
4. Tell you honestly if it can't find the resource, instead of guessing and touching the wrong thing.

No new permissions, no new AWS API calls, no separate command to learn. It's the same scan, the same findings, just with a second way to act on them.

Why this is deliberately not another --fix-commands

We already ship --fix-commands, which prints raw, runnable aws/kubectl commands for exactly the cases where that's the right tool — a one-off account with no IaC, a sandbox you're happy to hand-manage, an S3 bucket lifecycle rule that isn't tracked anywhere. That flag isn't going away, and it's still the fastest path when there's genuinely no source of truth to keep in sync.

--llm-prompts exists for the much more common case: the resource is already defined somewhere in code, and the fix needs to land there, not on the live resource. It intentionally:

• Never suggests running anything against AWS directly. The prompt explicitly tells the agent not to touch the live resource and not to deploy without review.
• Stays tool-agnostic. It doesn't assume Terraform, CDK, or any specific IaC — it asks the agent to search first, so it works whether your team is on Terraform, CDK, CloudFormation, Pulumi, Serverless Framework, or something else entirely.
• Ends every prompt with a review gate. "Show me the diff before applying" isn't boilerplate — it's the one line that keeps this safe to hand to an autonomous agent in the first place.
• Is free, with no gating. Unlike the detailed remediation payloads in saved JSON reports, this is available to every CLI user, because the whole point is to make the safe path the easy path.

This is genuinely how most engineers will use the scanner

Ask around and the actual workflow most teams already follow with an AI-assisted scanner looks like this:

1. Run the scan, usually filtered down with --severity critical,high or --min-cost 50 so you're only looking at findings worth acting on.
2. Skim the list, decide which ones are worth fixing this sprint.
3. For each one: paste the finding into whatever agent you're already using, and ask it to make the change.

Step 3 used to mean manually re-typing the resource ID, issue, and recommendation into a chat window, or copying a raw aws command and hoping it matched the IaC. --llm-prompts just makes step 3 a single copy/paste, with the context, the guardrails, and the "don't touch prod directly" instruction already baked in.

Combine it with the flags you already have:

# Re-filter a cached scan down to just the critical RDS findings, with prompts
npx greenops-scan --cached --modules rds --severity critical --llm-prompts

# Fresh scan, high-impact findings only, ready to hand to your agent
npx greenops-scan --profile prod --region eu-west-1 --min-cost 50 --llm-prompts

Try it

npx greenops-scan --llm-prompts

If you're already running greenops-scan regularly, this doesn't change anything about the scan itself — it's off by default, so nothing gets longer or noisier unless you ask for it. Turn it on the next time you sit down to actually fix findings instead of just triaging them, and let your agent do what it's already good at: finding the right file and writing the diff.

Tags: #AWS #FinOps #CloudCostOptimization #InfrastructureAsCode #Terraform #AWSCDK #AICoding #GitHubCopilot #GreenOps