DEV Community: Slawa Pidgorny

Finally a real-world proof that developers can do FinOps. Take a look.

Slawa Pidgorny — Sun, 23 Aug 2026 12:04:44 +0000

Slawa Pidgorny

Aug 23

How One AWS Bill Went From Almost $8,000 a Month Toward $6,000

#aws #devops #infrastructure

5 min read

How One AWS Bill Went From Almost $8,000 a Month Toward $6,000

Slawa Pidgorny — Sun, 23 Aug 2026 12:02:50 +0000

Two real scans, eight weeks apart, on the same account

Cloud bills rarely jump overnight. They drift.

A launch adds an oversized Fargate service. A prototype gets a managed database. An experiment ends, but the resources it created stay running. Buckets accumulate without a lifecycle policy because no one owns the cleanup decision. By the time the monthly total becomes uncomfortable, the waste is already spread across a dozen services.

This post is not a hypothetical. It's two greenops-scan reports run against the same AWS account, eight weeks apart, plus that account's own AWS Cost Explorer graph. Here is exactly what the scans found, what changed between them, and what AWS's own forecast says next.

The account

The account runs a mix of ECS/Fargate services, a DocumentDB (MongoDB-compatible) cluster, an Application Load Balancer, ElastiCache, a smaller RDS instance, AWS Transfer Family, and the usual security/compliance tooling (GuardDuty, CloudTrail, Config, KMS, Secrets Manager). By the most recent Cost Explorer data pulled through the scanner, the account was billing $7,726.20 for the month, with the two largest line items being ECS ($3,235.93) and DocumentDB ($1,506.78).

The account's real Cost Explorer history: a near-continuous climb from about $2,000/month in late 2023 to nearly $7,800/month by mid-2026. The last bar is AWS's own forecast (marked with `` and an 80% prediction interval) for the following month — not a confirmed result, but a trend AWS's own model expects given recent changes to the account.

What the first scan found

Running npx greenops-scan against a read-only profile for this account returned 53 findings worth an estimated $1,176.83 a month ($14,121.96/year) in identifiable waste. Nothing in the list was exotic — it was ordinary drift, spread across three modules.

ECS: 15 over-provisioned Fargate tasks — $756.83/month

The scanner flagged 15 Fargate task definitions running well above any resource profile the workload needed, ranging from 2 vCPU/4 GB up to a single task provisioned at 16 vCPU / 32 GB. It also flagged one ECS cluster with no running tasks or services at all.

Task size	Findings	Est. savings/mo
16 vCPU / 32 GB	1	$172.99
8 vCPU / 16 GB	4	$86.50 each
4 vCPU / 8 GB	2	$43.25 each
2 vCPU / 4 GB	7	$21.62 each
Empty cluster	1	$0 (still worth cleaning up)

S3: 37 buckets with no lifecycle policy — $415/month

Thirty-seven S3 buckets — mostly CodeBuild/CodePipeline artifact buckets — had no lifecycle rules, meaning every object stayed in the Standard storage tier indefinitely instead of transitioning to Glacier or being expired. Individually cheap ($10–15/month per bucket), collectively the third-largest line item in the report.

EC2: 1 stopped instance still billing storage — $5/month

A stopped t2.small instance was still incurring EBS storage costs. Small on its own, but the kind of thing that's invisible in Cost Explorer's per-service view and only shows up when something checks per-resource state.

What changed by the second scan

Eight weeks later, the same account, scanned again: 1 finding, worth $105.12 a month.

The one remaining item was a DocumentDB cluster (kaeinstancedb) still running on an Intel-based db.r5.xlarge instance class, where switching to a Graviton-based class would cut roughly 30% off that instance's cost.

That means between the two scans, 91% of the originally flagged waste was addressed — the 15 over-provisioned Fargate tasks, the 37 S3 buckets missing lifecycle rules, and the idle EC2 instance were no longer showing up as findings, while a new opportunity (the DocumentDB instance family) surfaced on the second pass.

Update: that last finding has since been resolved too. The kaeinstancedb cluster was migrated to db.r6g.large — Graviton, as the scan recommended, but one size class smaller than the db.r7g.xlarge the report suggested. That's a bigger cut than the flagged $105.12/month, since it downsizes the instance itself in addition to switching CPU architecture. With that change, every finding from the first scan has now been addressed.

Reading the Cost Explorer graph honestly

The graph above is the account's real multi-year cost history, not an illustration. Two things are true about it, and it's worth being precise about which is which:

Confirmed: the bill climbed steadily from roughly $2,000/month in late 2023 to nearly $7,800/month by mid-2026, and the scan-over-scan comparison above confirms that a meaningful chunk of flagged waste was cleaned up in that window.
Not yet confirmed: the final bar on the graph is AWS Cost Explorer's own forecast for the following month, explicitly marked with a double asterisk and an 80% prediction interval, projecting the bill down toward roughly $5,000–$6,000. That's AWS's own model reacting to the account's recent trend — a forecast, not a closed month.

We're reporting both numbers because a scanner report is only useful if it's honest about what it can and can't prove. The $1,176.83 → $105.12 change in flagged waste is a fact from two independent scans. The next month's total landing near $6,000 is AWS's own projection, and worth watching, not asserting as done.

What made the difference

Three things, consistently:

A clear list. The scanner turned an abstract "the bill keeps climbing" concern into 53 specific resources with issue descriptions and dollar estimates.
A safe first step. Because the scan is read-only and runs locally, nothing needed elevated write access to produce the list — the actual changes (right-sizing Fargate tasks, adding lifecycle rules, terminating an idle instance) were made deliberately, by hand.
A second (and third) scan to check the work. Re-running the same read-only scan two months later is what actually confirmed 91% of the flagged items were resolved, instead of assuming the fixes stuck — and the follow-up on the last item confirmed the rest.

A realistic takeaway

Not every account will show a full cleanup between two scans, and not every Cost Explorer forecast will play out exactly as projected. But the pattern here — over-provisioned compute, storage without lifecycle rules, and a stale instance family — is common enough that it's worth checking for on any account whose bill has been drifting upward for a while.

npx greenops-scan

The CLI is free to use. The output is local. Run it twice, a few weeks apart, and see what actually changed.

The Source Is Closed. Here's How You Can Still Trust the Supply Chain.

Slawa Pidgorny — Wed, 19 Aug 2026 20:35:47 +0000

Security considerations of the GreenOps Scan CLI

Whenever someone asks "why isn't this open source?" about GreenOps Scan, the honest answer is: it isn't. The CLI is free to use — npx greenops-scan runs on your machine, with your credentials, without a login or a paywall — but the source code itself is not published. If you clone github.com/spidgorny/greenops-scan, you'll find a README.md and a LICENSE, not the implementation.

That's a deliberate trade-off, not an oversight, and it's fair to ask what it costs you as a user. If you can't read the code yourself, how do you know it's safe to point at a real AWS account? This post is about the two things you can independently verify — the published package's dependency supply chain and its behavior at runtime — and why both hold up well even without access to the source.

What "closed source" does and doesn't mean here

Closed source means you can't read src/providers/aws/modules/ec2.ts on GitHub. It does not mean the package you actually install is a black box:

npx greenops-scan downloads a real, versioned npm package (greenops-scan) with a public npm registry page, a public dependency list, and a full history of every published version.
Every dependency it pulls in is itself open source and independently auditable — the AWS SDK for JavaScript v3, @inquirer/prompts, pdfkit, ora, chalk, and so on.
Third-party supply-chain scanners (not us, not anything we control) independently analyze the published package and its transitive dependencies for known vulnerabilities, licensing issues, and suspicious behavior.

That last point is the part worth taking seriously: you don't have to trust our claims about the code — you can check what independent tooling says about the artifact you're actually running.

What Snyk says

security.snyk.io/package/npm/greenops-scan runs Snyk's vulnerability database against every published version of the package and its full dependency tree. It's the same database and scanning approach Snyk uses for every package on npm — GreenOps Scan gets no special treatment, favorable or otherwise.

What Socket.dev says

socket.dev/npm/package/greenops-scan/alerts/0.1.30?tab=dependencies goes a step further than a CVE database. Socket's static analysis looks at behavior, not just known vulnerabilities — install scripts, filesystem/network/shell access, obfuscated code, typosquatting risk, maintainer changes, and dependency freshness. That kind of analysis is exactly what you'd want to check for a CLI tool that's about to run with your AWS credentials.

We treat Socket's findings as a maintenance backlog, not a one-time checkbox. Recently that meant:

Bumping every @aws-sdk/* client to a current release (one older version had a documented caching bug in credential resolution, unrelated to Socket but worth fixing anyway)
Bumping googleapis, @inquirer/prompts, ini, open, ora, and pdfkit off stale majors
Pinning gaxios to a version that drops a deprecated rimraf/glob chain pulled in transitively through googleapis-common — a case where the direct dependency (googleapis) was current, but a deep transitive pin was still forcing a deprecated package into the tree
Deliberately not jumping chalk to its latest major, because that version is ESM-only and would have forced a much larger, riskier rewrite of the CLI's module system for no security benefit — a reminder that "bump everything to latest" isn't always the safer choice

Some low-severity items remain and are expected to for a while — node-domexception, for instance, is deprecated several layers deep inside node-fetch (a dependency of Google's own gaxios HTTP client), with no fix available from our side short of dropping GCP support entirely. That's a normal, low-risk state for a Node.js project with any HTTP or cloud SDK dependencies — the goal isn't a zero-alert dashboard, it's making sure nothing exploitable or high-risk sits unaddressed.

What the CLI actually does at runtime — verifiable independent of the source

Beyond the dependency tree, the two things that matter most for a tool touching your cloud account are (1) what API calls it makes and (2) where your data goes. Both are observable without reading a line of source:

Read-only AWS calls only. Every AWS API call GreenOps Scan makes is a Describe*, Get*, List*, or equivalent read-only operation. You don't have to take our word for it — run the scan against an IAM profile with only the AWS-managed ReadOnlyAccess policy attached (see our read-only profile walkthrough) and any accidental write call would fail with AccessDenied, loudly, immediately. IAM enforces this, not the tool's good behavior.
Nothing leaves your machine. The scan runs locally, reads your local AWS credentials the same way the AWS CLI does, and writes its report (JSON, table, or PDF) to your local terminal or filesystem. There's no telemetry endpoint, no upload step, no server-side account required to get a scan result. You can verify this yourself with a network monitor (e.g. lsof -i or a proxy like mitmproxy) while a scan runs — the only outbound calls you'll see are to AWS's own API endpoints (and Google's, if you're scanning GCP).
Standard, versioned distribution. The package is published to the public npm registry under a fixed name and semantic version, the same distribution mechanism as every other npm package — no custom installer, no binary blob, no curl | bash.

So why keep the source closed at all?

Fair question, and we don't dodge it: GreenOps Scan is free to use but not free to fork or resell — the business behind it depends on that. Closed source is a commercial choice, not a security posture. The point of this post is that those are separable: you can independently verify the security of the published artifact (via Snyk and Socket) and its runtime behavior (via IAM and network inspection) without needing the source itself. Both checks currently come back clean, and we intend to keep it that way as new versions ship.

If you want to see the current numbers for yourself rather than trust a screenshot in a blog post, the links are right there at the top — check them before you run the scanner, and check them again after every version bump.

Try GreenOps Scan Safely: Create a Read-Only AWS Profile First

Slawa Pidgorny — Wed, 19 Aug 2026 20:33:23 +0000

A five-minute setup that guarantees the scanner can't touch anything

Running a third-party tool against your AWS account raises a fair question before you type a single command: what can it actually do with my credentials?

With GreenOps Scan the honest answer should be "nothing but read." But you do not have to take that on faith. AWS lets you create a dedicated IAM user or role that is technically incapable of making changes — no write, no delete, no configuration changes, anywhere. If you attach only ReadOnlyAccess to the credentials you scan with, there is no policy misconfiguration or bug in the scanner that could put your infrastructure at risk.

This post walks through creating that profile with the AWS CLI, so you can try npx greenops-scan with full confidence.

Why a dedicated profile instead of your existing one

Your day-to-day AWS CLI profile is probably tied to broad permissions you use for real work — deploying, provisioning, tagging, cleaning up. Even if you trust the tool, reusing that profile means the blast radius of any mistake (yours, the tool's, or a future dependency's) is as large as your normal permissions.

A dedicated read-only profile:

can be created and deleted in minutes
is scoped with an AWS-managed policy, not something you have to write and audit yourself
makes the guarantee "this can't change anything" enforced by IAM, not by trusting the tool's code
can be reused later for any other inspection tool, dashboard, or audit script

Step 1: Create an IAM user for scanning

aws iam create-user --user-name greenops-scan-readonly

This creates a new IAM user with no permissions attached yet.

Step 2: Attach the AWS-managed ReadOnlyAccess policy

aws iam attach-user-policy \
  --user-name greenops-scan-readonly \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

ReadOnlyAccess is an AWS-managed policy (you don't own or maintain it — AWS does) that grants Describe*, Get*, List*, and similar read-only actions across services, while explicitly excluding any action that creates, modifies, or deletes a resource. It's the same policy GreenOps' own cross-account scanner role uses for continuous monitoring.

Do not attach any additional policies to this user. The whole point is that this identity has exactly one capability: reading.

Step 3: Create an access key for the user

aws iam create-access-key --user-name greenops-scan-readonly

The output looks like this — copy the AccessKeyId and SecretAccessKey, since the secret is only shown once:

{
  "AccessKey": {
    "UserName": "greenops-scan-readonly",
    "AccessKeyId": "AKIAEXAMPLE1234567",
    "Status": "Active",
    "SecretAccessKey": "abcdEXAMPLEsecretkeyvaluexxxxxxxxxxxxxxxx",
    "CreateDate": "2026-08-13T09:00:00Z"
  }
}

Step 4: Add the credentials as a new local AWS CLI profile

Rather than overwriting your default profile, add a named profile — call it something obvious like greenops-readonly:

aws configure --profile greenops-readonly

You'll be prompted for:

AWS Access Key ID [None]: AKIAEXAMPLE1234567
AWS Secret Access Key [None]: abcdEXAMPLEsecretkeyvaluexxxxxxxxxxxxxxxx
Default region name [None]: eu-west-1
Default output format [None]: json

This writes the profile into ~/.aws/credentials and ~/.aws/config, alongside — not over — any existing profiles.

Step 5: Verify the profile actually has read-only access (and nothing more)

Confirm the identity resolves correctly:

aws sts get-caller-identity --profile greenops-readonly

Then confirm it can read, as expected:

aws ec2 describe-instances --profile greenops-readonly --region eu-west-1

And confirm it genuinely cannot write. Try something harmless but mutating, like creating a tag or a security group, and expect an UnauthorizedOperation / AccessDenied error:

aws ec2 create-tags --profile greenops-readonly \
  --resources i-0123456789abcdef0 \
  --tags Key=test,Value=should-fail

Expected output:

An error occurred (UnauthorizedOperation) when calling the CreateTags operation:
You are not authorized to perform this operation.

If that call fails with an authorization error, the profile is doing exactly what it should.

Step 6: Run GreenOps Scan against the read-only profile

Now you can run the scanner with full confidence that it is structurally unable to change anything in your account:

npx greenops-scan --profile greenops-readonly --region eu-west-1

Or omit the flags and let the interactive prompt list your available profiles, including greenops-readonly, so you can pick it explicitly each time.

GreenOps Scan itself only ever calls read-only AWS APIs (Describe*, Get*, List*) — see how GreenOps Scan handles credentials for more on that design. Pairing that behavior with a profile that is incapable of anything else gives you two independent layers of protection instead of one: the tool's own design, and IAM's enforcement.

Cleaning up afterwards

If you only wanted to try the CLI once, you can safely remove the user when you're done:

aws iam detach-user-policy \
  --user-name greenops-scan-readonly \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

aws iam list-access-keys --user-name greenops-scan-readonly
aws iam delete-access-key --user-name greenops-scan-readonly --access-key-id AKIAEXAMPLE1234567

aws iam delete-user --user-name greenops-scan-readonly

And drop the corresponding profile block from ~/.aws/credentials and ~/.aws/config if you no longer need it.

From a one-off scan to continuous, still-read-only monitoring

If the scan surfaces useful findings and your team wants recurring visibility instead of a one-time snapshot, GreenOps Cloud extends the same read-only model with a cross-account IAM role (scoped with sts:ExternalId and the same ReadOnlyAccess policy) so continuous monitoring never requires write access either.

Either way — a local profile for a single npx greenops-scan run, or a cross-account role for ongoing monitoring — the underlying guarantee stays the same: the scanner can look, but it cannot touch.

Tags: #AWS #IAM #ReadOnlyAccess #CloudSecurity #FinOps #GreenOps

GreenOps vs. AWS Native Cost & Carbon Tools

Slawa Pidgorny — Wed, 19 Aug 2026 20:31:44 +0000

Where the added value is

AWS gives teams an impressive set of cost and sustainability tools. If you are already using Trusted Advisor, Cost Explorer, the Customer Carbon Footprint Tool, or Compute Optimizer, you are doing the right things.

The question a lot of teams run into is: what do I do with the signal those tools give me? GreenOps is designed to answer that next step. It is not a replacement for AWS services; it is a focused, actionable second opinion that turns their high-level data into a ranked list of specific resources worth reviewing, with cost, carbon, and the exact command to investigate each one.

At a glance

What you want to do	AWS tool	What GreenOps adds
Get a high-level health check	Trusted Advisor	Resource-level findings with estimated savings, carbon impact, and the exact CLI command to review or fix it.
Understand where your money went	Cost Explorer	The specific resources driving that spend, why they are wasteful, and what to change.
Report annual carbon footprint	Customer Carbon Footprint Tool	Modeled carbon-reduction opportunities tied to individual resources and remediation actions.
Right-size EC2, ASG, Lambda, EBS	Compute Optimizer	A broader waste lens across more services — idle, zombie, stale, untiered resources — plus carbon and remediation commands.
Get alerted when spend spikes	Budgets / Anomaly Detection	A short, prioritized list of the actual resources that caused the variance.

What the output looks like

A read-only scan returns a ranked list of findings — each tied to a specific resource, with estimated monthly cost savings, carbon savings, and the context needed to review it.

The summary rolls those findings up into monthly and annual cost and carbon totals, plus relatable equivalents to make the numbers tangible.

Trusted Advisor: broad best-practice checks

Trusted Advisor is a great first-line health check. It covers cost, security, performance, fault tolerance, and service limits, and it can flag patterns like low-utilization EC2 instances or exposed security groups.

GreenOps narrows the focus to cost-and-carbon waste and adds a few things Trusted Advisor does not:

Resource-level scoring. Each finding is tied to a specific resource and estimated in dollars per month and kilograms of CO2 per month.
Carbon context. GreenOps uses regional grid-carbon intensity to estimate the carbon reduction of acting on each finding, not just the cost.
Actionability. Instead of a recommendation, GreenOps outputs the specific aws CLI command or configuration change to review, and includes a safety warning when a command is destructive.
History and trends. GreenOps Cloud stores findings over time so a team can see whether remediation actually moved the needle.

Cost Explorer: where the money went

Cost Explorer is the right place for historical spend analysis, chargeback, and reservation planning. It can slice your bill by account, service, tag, reservation, and time.

The next question is usually: which specific resources caused the change? GreenOps is built for that:

Cost Explorer says: "EC2 spend rose 18% last month."
GreenOps says: "Three t3.xlarge instances in us-east-1 averaged <5% CPU for 14 days; right-sizing them could save $X/month and avoid Y kg CO2/month, and here is the command to review it."

Customer Carbon Footprint Tool: account-level reporting

AWS's Customer Carbon Footprint Tool is designed for ESG and CSRD-style reporting. It gives an annual, account-level view of emissions from your AWS usage.

GreenOps takes a different cut. It is per-resource and forward-looking:

It estimates the carbon reduction you could achieve if a specific finding is fixed.
It links carbon directly to cost, so engineering, finance, and sustainability can triage with the same data.
It is not an audited carbon inventory. It is a modeled estimate intended for prioritization, not compliance.

Compute Optimizer: right-sizing for supported services

Compute Optimizer recommends instance sizes and configurations for EC2, Auto Scaling groups, Lambda, and EBS. When your workload is a good fit, it is the right tool.

GreenOps covers a wider waste surface and adds execution context:

It flags idle resources, not just oversized ones: zombie Lambda, empty ECS clusters, unattached EBS volumes, stale snapshots, unused CloudFront distributions, and more.
It estimates savings and carbon in the same view.
It gives you a shell command to investigate rather than only a sizing recommendation.

What GreenOps is best for

GreenOps makes sense when you want a fast, low-risk second opinion:

Run a local, read-only scan with npx greenops-scan against a dev or sandbox account.
Get a ranked list of waste with estimated cost and carbon.
Share a PDF or JSON report with the people who own the workloads.
Track findings over time with GreenOps Cloud once you are ready for continuous monitoring.

What AWS tools still do better

AWS tools are still the right place for several jobs:

Reservation and Savings Plan analysis — use Cost Explorer and Cost & Usage Reports.
Compliance-grade carbon accounting — use the Customer Carbon Footprint Tool and a formal GHG inventory.
Service-limit and security checks — use Trusted Advisor and Security Hub.
Enterprise chargeback and cost allocation — use Cost Explorer tags and AWS Billing Conductor.

Bottom line

GreenOps is a narrow, opinioned layer: find wasteful resources, estimate the cost and carbon impact, and hand the right person a concrete command to review. AWS tools are broad platforms for cost accounting and compliance.

If you already use Cost Explorer, Compute Optimizer, and Trusted Advisor, you can add GreenOps on the side and get a faster path from "we spent too much" to "this is the specific resource to fix."

Want to see what it surfaces for you? Run a read-only scan:

npx greenops-scan

For teams that need recurring scans, shared dashboards, and trend tracking, GreenOps Cloud adds continuous monitoring.

Tags: #AWS #FinOps #CloudCostOptimization #Sustainability #CarbonReduction #TrustedAdvisor #CostExplorer #ComputeOptimizer #GreenOps

Your Fargate Tasks Are Probably Bigger Than They Need to Be

Slawa Pidgorny — Mon, 17 Aug 2026 16:33:08 +0000

How to detect over-provisioned ECS/Fargate services and right-size them to actual load

AWS Fargate made it easy to stop thinking about servers. It also made it easy to stop thinking about task sizing.

Most teams pick a CPU/memory combination once — often copied from a template, a tutorial, or "what worked last time" — and never revisit it. Traffic patterns change, code gets optimized, dependencies get swapped, but the task definition stays the same. Six months later, a service that peaks at 15% CPU is still provisioned as if it were about to get hammered.

That gap between allocated and actual resource use is one of the most common (and most fixable) sources of waste on AWS.

Why Fargate over-provisioning is so easy to miss

A few things make this specific waste pattern sneaky:

Billing is per-task, not per-utilization. You pay for the vCPU and memory you reserved, whether the task uses 5% or 95% of it. The bill doesn't nudge you to look.
Nothing fails when a task is oversized. Unlike a memory leak or an outage, over-provisioning has no symptom. The service just quietly runs fine — at 3x the cost it needs.
CloudWatch has the answer, but no one's watching it. CPUUtilization and MemoryUtilization per ECS service are recorded by default. Almost nobody builds a habit of reviewing 30-day averages across every service in every cluster.
Empty clusters accumulate too. Test clusters, deprecated environments, and abandoned proofs-of-concept often keep existing with zero running tasks, adding clutter and occasional accidental cost.

A practical way to detect it

You don't need a full FinOps platform to find this. The core signal is straightforward:

List every ECS cluster and service in the account and region you care about.
Pull 30-day average CPU and memory utilization per service from CloudWatch (GetMetricStatistics, Period: 86400 for daily granularity, Statistics: Average).
Flag services where both CPU and memory averages sit below ~30%. A single low spike day isn't a signal — a sustained 30-day average is.
Estimate the achievable savings conservatively. Don't assume you can cut a service down to exactly its average usage — leave headroom for spikes. A reasonable rule of thumb: take the larger of the CPU or memory waste ratio, apply a 50% haircut for safety margin, and multiply that against the service's current Fargate cost (vCPU price + memory price × 730 hours/month).
Cross-check desiredCount vs runningCount. If a service consistently wants more tasks than it can get running, that's a different problem (constrained capacity or a stuck deployment) worth investigating separately from right-sizing.
Look for clusters with zero running tasks and zero active services. These are candidates for deletion, not right-sizing — but always back up the cluster config first (aws ecs describe-clusters output saved to a file) before deleting anything.

What to do once you've found one

Right-sizing a Fargate task is low-risk compared to most cost optimizations, because you can revert instantly if you get it wrong:

Pick the next tier down in vCPU/memory that still comfortably covers your 30-day peak, not just the average.
Deploy the change to a canary or a percentage of tasks first if your deployment tooling supports it.
Re-check CPUUtilization/MemoryUtilization a week later. If the new allocation still sits comfortably below 70-80% at peak, you're done. If you see throttling or OOM-kills, step back up one tier.
Repeat quarterly — traffic and code both drift over time, so a service sized correctly today may not be next year.

The pattern above (CPU/memory averages below 30% over 30 days, checked per service rather than per cluster) is deliberately conservative. It's meant to surface real candidates for review, not to declare every quiet service "wrong." Some services are supposed to run cool — that's headroom for traffic spikes, not waste. Use judgment before resizing anything customer-facing.

Checking this by hand doesn't scale

Doing this manually for one or two clusters is a reasonable afternoon project. Doing it for every cluster, every service, across every region and account your company runs — while also checking EC2, RDS, Lambda, S3, EBS snapshots, and the rest of the surface area where waste hides — is a different problem entirely.

That's exactly the check GreenOps Scan automates. It's a free, read-only CLI that runs the same kind of 30-day CloudWatch analysis described above across ECS/Fargate, along with idle EC2 instances, unused EBS snapshots, S3 buckets without lifecycle policies, underused RDS instances, stale Lambda functions, and more — in one pass, with cost and CO2 estimates attached to each finding.

Run it against a read-only IAM role:

npx greenops-scan

It won't touch anything in your account. Every finding comes with the specific resource, the issue, an estimated monthly cost and carbon impact, and a remediation command or recommendation you can review before acting on it. If your Fargate services are quietly over-provisioned, it'll be near the top of the list.

Learn more about GreenOps Scan →

My first article. Short. Request feedback.

Slawa Pidgorny — Thu, 06 Aug 2026 12:22:56 +0000

Slawa Pidgorny

Aug 6

The Cloud Waste No One Is Looking At

#aws #cloudwaste #finops #sustainability

4 min read

The Cloud Waste No One Is Looking At

Slawa Pidgorny — Thu, 06 Aug 2026 12:21:15 +0000

The Cloud Waste No One Is Looking At

How one command finds the money hiding in your AWS bill

Cloud waste is the electricity bill no one reads.

The total gets attention, but the individual line items often do not. An EC2 instance was sized for a launch that ended months ago. A Fargate service still has capacity for a traffic peak that never returned. A database is technically running but barely queried. Snapshots and object versions accumulate because nobody owns the cleanup decision.

None of these choices looks unreasonable when it is made. Together, they can become a quiet, recurring cost.

Industry surveys consistently estimate that 27–32% of cloud spend is wasted. That does not mean every company can remove a third of its bill tomorrow. It means many teams could benefit from a systematic way to find resources worth reviewing.

Waste hides behind ordinary line items

AWS gives teams extraordinary flexibility. It also distributes spending across thousands of resources, usage types, and decisions. Billing dashboards can show where money went without always explaining which specific resource no longer delivers enough value.

The difficult questions live below the account total:

Which compute instances are idle?
Which Fargate services are consistently over-provisioned?
Which Lambda functions are no longer invoked?
Which databases are quiet enough to review?
Which S3 buckets lack lifecycle policies?
Which snapshots and machine images have outlived their purpose?
Which workloads might be candidates for more efficient architectures?

Answering those questions manually takes time, service knowledge, and context. That is why the review is so easy to postpone.

A useful second opinion in one command

GreenOps Scan is a free CLI that inspects AWS resource metadata and usage signals for potential cost and carbon opportunities.

Run:

npx greenops-scan

Choose an AWS profile and region, then let the scanner check services including EC2, S3, ECS, EKS, Lambda, RDS, ElastiCache, CloudFront, and EBS snapshots.

The result is a terminal summary plus JSON and a branded PDF report. Each finding identifies the affected resource, explains the issue, estimates the potential cost and carbon impact, and provides remediation guidance for review.

The estimates are a starting point, not a promise. Workload requirements, contractual pricing, architecture, and business context determine whether a finding can become a realized saving.

What one real scan surfaced

On one real AWS account, GreenOps surfaced:

130 issues across nine services
approximately $2,209 per month in estimated savings opportunities
approximately $26,510 per year in estimated savings opportunities
approximately 1,210 kg CO2 per year in modeled carbon-reduction opportunities

The largest groups included over-provisioned ECS Fargate services, S3 buckets without effective lifecycle policies, idle or older RDS resources, and Lambda functions with low usage or efficiency opportunities.

Those figures describe one account at one point in time. They do not guarantee that another account will produce the same result, or that every surfaced estimate should be acted on. The value of the scan is that it turns an abstract concern into a concrete review list.

Even when only a small number of findings survive technical and business review, they might be enough to justify the few minutes required to run the command.

Safe by design: read-only and local

The first question for any infrastructure tool should be: what can it access, and where does the data go?

GreenOps Scan is designed for a low-risk first look:

it uses read-only AWS APIs
it runs locally on your machine
your AWS credentials never leave your machine
it does not install an agent in the account
it cannot modify, stop, resize, or delete resources
the report stays local unless you choose to share it

The scanner reports; it does not remediate automatically. Every recommendation should be reviewed by someone who understands the workload, its owners, and its recovery requirements before a change is made.

That separation matters. A team can begin with a dev or sandbox account, inspect exactly what the scanner finds, and decide whether the evidence is useful without granting write access or onboarding a SaaS platform.

Cost efficiency and carbon efficiency are connected

Unused and over-provisioned infrastructure is not only a financial inefficiency. Compute, storage, and data movement require hardware and energy even when they deliver little useful work.

GreenOps models carbon opportunities using principles from the Green Software Foundation methodology. The estimates help translate technical findings into a second dimension: the potential emissions associated with avoidable resource use.

These figures are modeled estimates, not audited emissions measurements. They do not make an organization CSRD compliant and should not be presented as guaranteed carbon reductions.

They could still be useful. CSRD and other sustainability programs increase the need for engineering, finance, and sustainability teams to understand where digital infrastructure consumes resources and how improvement opportunities are identified. A documented, repeatable scan can contribute evidence to that internal conversation.

From a one-time scan to continuous monitoring

A one-time scan answers an immediate question: what might be worth reviewing today?

Cloud environments do not stand still. Teams deploy new services, traffic changes, temporary resources become permanent, and yesterday's reasonable allocation can become tomorrow's waste. The same account can look different a month later.

That is where GreenOps Cloud fits. It extends the free CLI approach with continuous monitoring, scan history, shared visibility, and recurring detection for teams that need more than a point-in-time report.

Start with the lowest-friction step:

npx greenops-scan

Review the findings with the people who own the workloads. If the scan surfaces useful opportunities and the team wants ongoing visibility, explore GreenOps Cloud for continuous monitoring.

You might find a meaningful saving. You might find only a few cleanup tasks. Either way, you will have replaced a vague suspicion with evidence.

P.S. Upvote on Product Hunt: https://www.producthunt.com/products/greenops-scan