Forem: Germán Neironi

Building in Public: The Technical Decisions Behind an AWS Cost Optimization Tool

Germán Neironi — Fri, 27 Feb 2026 12:01:56 +0000

I'm going to share something most founders don't: the actual technical journey of building a product from scratch.

No "we raised $10M and hired 50 engineers." Just one developer and a lot of coffee.

This is how I built CloudPruneAI - an AWS cost optimization tool that scans accounts and generates infrastructure-as-code to fix waste.

The Problem I Wanted to Solve

After years of managing AWS infrastructure, I kept seeing the same pattern:

Company grows fast
Engineers spin up resources "temporarily"
Nobody cleans them up
CFO asks "why is our AWS bill so high?"
Everyone panics and manually audits for a week

The tools that existed either:

Cost $45K+/year (CloudHealth, Cloudability)
Only showed dashboards without actionable fixes
Required a dedicated FinOps team to operate

I wanted something that a solo developer or small team could use: scan, see waste, get code to fix it. Done.

The Stack Decisions

Backend: FastAPI + Python

Why FastAPI?

Async by default (critical when you're making dozens of AWS API calls per scan)
Auto-generated OpenAPI docs (saves time during frontend integration)
Type hints with Pydantic (catches bugs before they reach production)
Easy to deploy on Lambda with Mangum (one handler, done)

Python was the natural choice because AWS SDKs, CDK, and most infrastructure tooling lives in the Python ecosystem.

Frontend: Next.js 14 + Material UI

Why Next.js 14?

App Router is finally stable
Server components reduce client bundle
Easy deployment on AWS Amplify (SSR support)

Material UI gave me a professional-looking dashboard without spending weeks on design. For an MVP, speed matters more than pixel-perfect custom UI.

Infrastructure: AWS CDK

Why CDK over Terraform?

Same language as backend (Python) — one less context switch
Better AWS integration for the services I needed
And honestly... I'm building a tool that generates CDK, so I should use it myself

Database: PostgreSQL on RDS

Simple choice. Relational data, need transactions, familiar with it. Used SQLAlchemy 2.0 with async support to keep everything non-blocking.

The Core: How the Scanner Works

The scanner is the heart of the product. At a high level:

User connects their AWS account (read-only access via IAM role)
The scanner runs multiple analyzers in parallel — each one specialized for a different AWS service
Each analyzer calls AWS APIs, checks utilization metrics via CloudWatch, and identifies waste patterns
Results are aggregated with estimated monthly savings per recommendation

The key insight was making each analyzer independent and atomic. They don't know about each other. This means I can add new ones without touching existing code, and a failure in one doesn't break the others.

The Differentiator: AI-Powered Code Generation

Most cost tools stop at "you're wasting money on X." We go further: for each recommendation, you can generate a CDK project that implements the fix.

I use Claude's API for code generation. The tricky part wasn't the AI — it was the infrastructure around it:

Generation can take 10-30 seconds
API Gateway has a 30-second timeout
Users don't want to stare at a spinner

Solution: Async processing with a queue. User clicks "Generate," gets an immediate response with a task ID, and polls for completion. A separate worker processes the queue and stores results. When ready, the user downloads a ZIP with a complete CDK project.

This pattern (queue + worker + polling) solved the timeout issue cleanly and scales naturally.

Mistakes I Made

1. Underestimating Auth Complexity

I thought "just add Auth0" would take a day. It took a week.

Problems:

Session handling between SSR and client components
JWT verification on the backend
Logout not actually logging out (cached sessions)

Lesson: Auth is never "just add a library."

2. Not Setting Up Environments Early

I built everything in staging first. When it was time for production, I had to:

Duplicate all CDK stacks
Create separate databases
Configure separate Auth0 applications
Debug environment variable issues for days

Should have done staging + production from day one. The marginal effort is tiny compared to retrofitting later.

3. Overthinking the Business Model

First idea: SaaS subscription ($99/month)
Second idea: One-time payment per scan
Third idea: Gainshare (percentage of savings)
Final: Gainshare + optional subscription

I spent too much time on pricing before having users. Should have just launched with something simple and iterated.

What Worked Well

1. Monorepo with Turborepo

Frontend, backend, infrastructure — all in one repo. One command to run everything locally. One PR for full-stack changes. No version mismatches between services.

2. Early User Testing

I scanned a friend's AWS account before the UI was even done. Found significant waste across multiple accounts.

That validated the core value prop before I wrote a single line of frontend code. If the scanner hadn't found real savings, I would have known early, not after building the entire product.

3. Building the Hard Part First

Scanner + code generation were the riskiest parts. I built those first.

If the AI couldn't generate production-quality CDK code, the whole product wouldn't work. Better to find out early.

Architecture Overview

Request flow:

User → Route 53 (DNS) → splits into two paths:

Frontend path:

AWS Amplify (Next.js SSR) → Auth0 (authentication)

Backend path:

API Gateway (HTTP API) → Lambda (FastAPI) → RDS PostgreSQL + DynamoDB (cache)

Code generation flow:

Lambda → SQS queue → CDK Worker Lambda → stores result → user downloads ZIP

Everything serverless except the database. Two isolated environments (staging + production) with separate infrastructure.

Costs

Running this in production:

Service	Monthly Cost
RDS (db.t4g.micro)	~$15
Lambda	~$5
Amplify	~$5
API Gateway	~$1
DynamoDB	~$1
Total	~$27/month

Serverless keeps costs near zero until you have real traffic. That's important when you're bootstrapping.

What's Next

Currently looking for beta testers. If you have an AWS account spending >$1K/month and want a free scan, sign up here.

In exchange, I just need 15 minutes of feedback on what works and what doesn't.

Key Takeaways

Start with the risky parts — validate core tech before building UI
Set up environments early — staging + production from day one
Async processing for slow operations — don't fight API timeouts
Auth is always harder than you think — budget extra time
Test with real users early — even before the product is "ready"

Questions about the stack or decisions? Drop them in the comments — happy to go deeper on any part.

I Was Writing Marketing Posts Disguised as Advice. My Audience Noticed Before I Did.

Germán Neironi — Wed, 11 Feb 2026 18:40:29 +0000

I've been building CloudPruneAI, an AWS cost optimization tool, and part of the journey has been figuring out how to talk about it.

Last night I sat down to review our LinkedIn content performance from the past month. What I found made me rethink everything.

The data that changed my mind

We've published about 15 LinkedIn posts since mid-January. Some did well. Some flopped. When I looked at the numbers, a clear pattern emerged:

Posts that worked:

Post	Theme	Result
"The most expensive mistake I've seen in AWS? 'We'll optimize later.'"	Behavioral pattern, no blame	8,100 impressions
CloudWatch logs tip with a CLI command	Practical, immediately useful	Good engagement
Beta testers request	Transparent, asked for help	Good DMs

Posts that didn't work:

Post	Theme	Result
"Most FinOps tools are just expensive dashboards"	Adversarial, us vs them	Low traction
"Stop buying dashboards. Start deploying fixes."	Direct comparison to competitors	Low traction
"What if the tool that found the problem also wrote the fix?"	Thinly veiled product pitch	Low traction

The difference was obvious once I saw it side by side.

What I was doing wrong

I thought I was writing helpful content. But several of my posts were really just marketing wrapped in an opinion format:

The adversarial pattern:

"Other tools give you X. You actually need Y. [Implied: we give you Y]."

It seems clever when you're writing it. But readers see right through it. They scroll past because it feels like an ad, even if you never mention your product.

The disguised pitch:

"What if the tool that found the problem also wrote the fix?"

That's not a question. That's a tagline. And LinkedIn audiences can smell a tagline from three paragraphs away.

What actually resonated

The post that went semi-viral (8.1K impressions for an account with ~500 connections) was this one:

"The most expensive mistake I've seen in AWS? Not the m5.24xlarge someone left running. Not the 10TB of logs. It's this: 'We'll optimize later.'"

Why did it work?

It described a pattern, not a product. Anyone who's worked with AWS recognized the behavior.
It didn't point fingers. No "your tools are bad" or "you're doing it wrong."
It gave something to think about. The reader left with a reflection, not a sales pitch.
It ended with a genuine question. "What's your 'I'll fix it later' that never got fixed?" People wanted to share their own stories.

The voice we're building now

After this analysis, we documented what we're calling our brand voice. The core principle:

"The engineer who's been through this and shares what they learned."

Not a vendor talking to a prospect. A peer sharing a trench.

Five rules we're following now:

1. Experience before opinion

Before: "Most FinOps tools are just expensive dashboards."
After: "A CTO told me they had 3 dashboards showing $5K in waste. Six months later, nothing changed. I asked why."

2. Give before you ask

Every post should leave the reader with something useful. If someone reads our post and doesn't need our product, they should still feel like they gained something.

3. Show, don't tell

We don't say "we deliver solutions, not dashboards." We tell stories where the gap between knowing and acting cost real money. Our value proposition emerges from the narrative, not from a comparison chart.

4. Vulnerability over perfection

Share mistakes, real numbers, honest doubts. Building in public means actually being public, not curating a highlight reel.

5. Invite conversation, not debate

Before: "Agree or disagree?"
After: "Has anyone else experienced this?"

One triggers a debate. The other triggers storytelling. Storytelling builds community.

What we stopped doing

We archived several posts that were already written and scheduled:

"Hot take: If you're still writing CloudFormation YAML..." → adversarial tone
"Stop buying dashboards. Start deploying fixes." → us vs them
"What if the tool that found the problem also wrote the fix?" → pitch disguised as reflection
"I ran a scan on a fintech's AWS. Found $21K/month in waste." → sounds like a sales demo

Killing content you already wrote is painful. But publishing content that makes people scroll past is worse.

The new content plan

We replaced the archived posts with five new ones that follow the new voice:

"The resource nobody remembers creating" - About orphaned AWS resources and the pattern of "I think someone from the previous team set that up." Practical tips for tagging and monthly cleanup.
"Your staging environment doesn't sleep" - Quick math on how dev/staging running 24/7 wastes 76% of its cost. Practical solution with Lambda scheduling.
"Month 1: $1,974 and zero customers" - Full building in public post. Real investment numbers, what we built, what we got wrong.
"The Friday ritual that saves thousands" - A 10-minute weekly cost review habit anyone can start immediately. No tools required.
"The conversation that changed how I think about cloud costs" - A founder who knows they have waste but doesn't have bandwidth to fix it. The compound effect of "we'll get to it."

Notice the difference: none of these posts require CloudPruneAI to exist. They're useful on their own. That's the test.

Why I'm sharing this

Because I think a lot of early-stage founders fall into the same trap.

You build something you're excited about. You want to tell the world why it's different. So you write posts that explain why your approach is better than the alternatives.

And it feels productive. You're "doing content marketing."

But your audience doesn't care about your competitive positioning. They care about their problems. They engage with content that helps them, teaches them, or makes them feel seen.

The product pitch can come later. First, earn the right to pitch by being genuinely useful.

The real metric

The best signal we've gotten wasn't impressions or likes. It was a DM after the "We'll optimize later" post:

"This is literally what's happening at my company right now. Can we talk?"

That came from a post that never mentioned CloudPruneAI. Never mentioned our product at all.

That's the voice we're building toward.

I'm building CloudPruneAI in public — an AWS cost optimization tool that generates deployable infrastructure-as-code instead of just reports. If you're interested in following the journey, I share monthly updates with real numbers.

This is month 1. Total invested: $1,974.06. Paying customers: 0. Lessons learned: priceless (and free, apparently).

FinOps for Startups: How to Stop Bleeding Money on Cloud Without Hiring a Team

Germán Neironi — Sun, 25 Jan 2026 14:49:41 +0000

Let me share a number that should make every startup founder uncomfortable:

27% of cloud spend is wasted.

That's not my opinion. That's Flexera's 2025 State of the Cloud Report. And it's actually improved from previous years (it was 32% in 2022).

If your startup spends $10K/month on AWS, around $2,700 is probably going to resources you don't need.

The problem? Most FinOps advice assumes you have:

A dedicated FinOps team
Enterprise tools with $45K+ annual contracts
Time to build dashboards and review reports

Startups have none of that. You have a Slack channel where someone occasionally posts "why is our AWS bill so high?" and everyone shrugs.

Let me show you how to do FinOps without the overhead.

What is FinOps (In Startup Terms)

FinOps is just "don't waste money on cloud." That's it.

The fancy definition involves "cloud financial management" and "cross-functional collaboration." But for a 10-person startup, it means:

Know what you're spending
Understand why
Fix the obvious waste
Don't let it creep back

No team required. No enterprise tools. Just discipline.

The 80/20 of Cloud Waste

After analyzing dozens of AWS accounts, I've found that 80% of waste comes from 5 sources:

1. Zombie Resources (30% of waste)

Resources that were created and forgotten:

EC2 instances from that "quick test" 6 months ago
Load balancers pointing to nothing
EBS volumes from terminated instances
Unattached Elastic IPs ($3.60/month each - sounds small until you have 20)

Quick fix:

# Find unattached EBS volumes
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].[VolumeId,Size,CreateTime]' \
  --output table

2. Oversized Instances (25% of waste)

That m5.xlarge "because we might need it" running at 8% CPU.

This is the most common waste in startups. Someone provisions a big instance "to be safe," and no one ever checks if it's actually needed.

Quick fix:

# Check CPU utilization (last 7 days)
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-YOUR_INSTANCE_ID \
  --start-time $(date -d '7 days ago' -u +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 3600 \
  --statistics Average

If average CPU is under 20%, you're probably oversized.

3. Logs Growing Forever (20% of waste)

CloudWatch Logs have no default retention. Your logs from 2022 are still there, and you're still paying for them.

I've heard of companies paying $40K+/month just for log storage.

Quick fix:

# Find log groups without retention
aws logs describe-log-groups \
  --query 'logGroups[?retentionInDays==`null`].[logGroupName,storedBytes]' \
  --output table

Set retention to 14 or 30 days for most logs. You probably don't need 3-year-old debug logs.

4. Wrong Storage Classes (15% of waste)

Data that's accessed once a year sitting in S3 Standard instead of Glacier.

Or worse: gp2 EBS volumes instead of gp3 (gp3 is 20% cheaper with better performance).

Quick fix:

# Find gp2 volumes (should be gp3)
aws ec2 describe-volumes \
  --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[*].[VolumeId,Size,VolumeType]' \
  --output table

5. Idle RDS Instances (10% of waste)

Development databases running 24/7 when they're only used during work hours.

Quick fix: Aurora Serverless v2 for dev/staging, or at minimum, stop instances outside work hours.

The 15-Minute Weekly Audit

You don't need a FinOps platform. You need 15 minutes every Monday.

Week 1: Check the Bill

Go to AWS Cost Explorer. Look at:

Top 5 services by cost
Any spikes vs last month
Cost by tag (if you're tagging... you are tagging, right?)

Week 2: Hunt Zombies

Run the commands above. Delete what you don't need.

Week 3: Check Utilization

Look at your biggest EC2 instances and RDS databases. Are they actually busy?

Week 4: Review Reservations

Are you running anything consistently 24/7 for 6+ months? Consider Reserved Instances or Savings Plans.

Rotate through these. Takes 15 minutes if you're focused.

Automation That Actually Helps

Some things should be automated from day one:

1. Budget Alerts

aws budgets create-budget \
  --account-id YOUR_ACCOUNT_ID \
  --budget '{
    "BudgetName": "Monthly-Limit",
    "BudgetLimit": {"Amount": "1000", "Unit": "USD"},
    "TimeUnit": "MONTHLY",
    "BudgetType": "COST"
  }' \
  --notifications-with-subscribers '[{
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 80
    },
    "Subscribers": [{
      "SubscriptionType": "EMAIL",
      "Address": "your@email.com"
    }]
  }]'

Get alerted at 80% of budget. Not at 150%.

2. Auto-Stop Dev Environments

Use AWS Instance Scheduler or a simple Lambda:

import boto3

def lambda_handler(event, context):
    ec2 = boto3.client('ec2')

    # Stop instances tagged with AutoStop=true
    instances = ec2.describe_instances(
        Filters=[
            {'Name': 'tag:AutoStop', 'Values': ['true']},
            {'Name': 'instance-state-name', 'Values': ['running']}
        ]
    )

    for reservation in instances['Reservations']:
        for instance in reservation['Instances']:
            ec2.stop_instances(InstanceIds=[instance['InstanceId']])

Run it at 8pm, start instances at 8am. Save 50%+ on dev instances.

3. Lifecycle Policies

Always set these on S3 buckets:

{
  "Rules": [{
    "ID": "TransitionToIA",
    "Status": "Enabled",
    "Transitions": [{
      "Days": 30,
      "StorageClass": "STANDARD_IA"
    }],
    "Expiration": {
      "Days": 365
    }
  }]
}

Data older than 30 days moves to cheaper storage. Data older than a year gets deleted.

When to Use Tools

DIY works until ~$20K/month. After that, the time spent manually auditing exceeds the cost of tools.

But here's my advice: don't buy dashboards, buy action.

Most FinOps tools tell you what's wrong. Few tell you how to fix it. Even fewer give you the actual code to implement fixes.

That's why we built CloudPruneAI - scan your AWS, get deployable CDK code, not a 50-page PDF.

The Mindset Shift

FinOps isn't a one-time cleanup. It's a habit.

Every time you create a resource, ask:

Does this need to run 24/7?
What's the right size?
When should this be deleted?
Is it tagged so we know who owns it?

Build this into your engineering culture, and you'll never need a dedicated FinOps team.

Key Takeaways

27% of cloud spend is waste - yours is probably similar
80% of waste is 5 things: zombies, oversizing, logs, storage class, idle DBs
15 minutes/week is enough for most startups
Automate the basics: budgets, auto-stop, lifecycle policies
Tools should give you action, not just dashboards

Quick Reference

Problem	Quick Command
Unattached EBS	`aws ec2 describe-volumes --filters Name=status,Values=available`
Unattached EIPs	`aws ec2 describe-addresses --query 'Addresses[?AssociationId==null]'`
No log retention	`aws logs describe-log-groups --query 'logGroups[?retentionInDays==null]'`
gp2 volumes	`aws ec2 describe-volumes --filters Name=volume-type,Values=gp2`
Stopped instances	`aws ec2 describe-instances --filters Name=instance-state-name,Values=stopped`

What's your biggest cloud cost pain point? Let me know in the comments - I might cover it in a future post.

Deploying Real Infrastructure Easily (AWS CDK)

Germán Neironi — Fri, 16 Jan 2026 18:47:20 +0000

You've probably heard about Infrastructure as Code. Maybe you've even written some CloudFormation YAML and felt your soul leave your body around line 847.

There's a better way.

AWS CDK (Cloud Development Kit) lets you define infrastructure using real programming languages - TypeScript, Python, Java, Go. No more YAML indentation nightmares. No more copy-pasting 200-line templates you found on Stack Overflow.

Let me show you how to go from zero to deploying real infrastructure in 10 minutes.

What is AWS CDK?

CDK is a framework that lets you define AWS resources using code. You write TypeScript (or Python, etc.), CDK converts it to CloudFormation, and deploys it.

Your Code (TypeScript) → CDK → CloudFormation → AWS Resources

The magic: you get loops, conditionals, functions, type checking, and IDE autocomplete. Things that are painful or impossible in YAML.

Setup (2 minutes)

You need Node.js and AWS CLI configured. Then:

npm install -g aws-cdk
mkdir my-first-cdk && cd my-first-cdk
cdk init app --language typescript

This creates a project structure:

my-first-cdk/
├── bin/
│   └── my-first-cdk.ts    # Entry point
├── lib/
│   └── my-first-cdk-stack.ts  # Your infrastructure
├── package.json
└── cdk.json

Your First Stack (3 minutes)

Open lib/my-first-cdk-stack.ts. Let's create an S3 bucket with some sensible defaults:

import * as cdk from 'aws-cdk-lib';
import * as s3 from 'aws-cdk-lib/aws-s3';
import { Construct } from 'constructs';

export class MyFirstCdkStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Create an S3 bucket
    const bucket = new s3.Bucket(this, 'MyBucket', {
      versioned: true,
      encryption: s3.BucketEncryption.S3_MANAGED,
      blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
      removalPolicy: cdk.RemovalPolicy.DESTROY, // For dev only!
    });

    // Output the bucket name
    new cdk.CfnOutput(this, 'BucketName', {
      value: bucket.bucketName,
    });
  }
}

That's it. A secure, versioned S3 bucket in 15 lines of readable code.

The equivalent CloudFormation? Around 40 lines of YAML.

See What You're Deploying (1 minute)

Before deploying, you can see exactly what CloudFormation CDK will generate:

cdk synth

And see the diff against your current AWS state:

cdk diff

This shows you exactly what will be created, modified, or deleted. No surprises.

Deploy (2 minutes)

cdk bootstrap  # First time only, sets up CDK in your account
cdk deploy

Watch your terminal. CDK creates a CloudFormation stack, provisions the resources, and shows you the outputs.

Done. You have a production-ready S3 bucket.

Why CDK Beats YAML

Let me show you the real power. Say you need 3 buckets for different environments:

const environments = ['dev', 'staging', 'prod'];

environments.forEach(env => {
  new s3.Bucket(this, `DataBucket-${env}`, {
    bucketName: `myapp-data-${env}-${this.account}`,
    versioned: env === 'prod', // Only version prod
    lifecycleRules: env !== 'prod' ? [{
      expiration: cdk.Duration.days(30), // Auto-cleanup non-prod
    }] : [],
  });
});

Try doing that cleanly in YAML. I'll wait.

Real-World Pattern: Lambda + API Gateway

Here's something more practical - a serverless API:

import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as apigw from 'aws-cdk-lib/aws-apigateway';

// Create Lambda function
const handler = new lambda.Function(this, 'ApiHandler', {
  runtime: lambda.Runtime.NODEJS_18_X,
  code: lambda.Code.fromAsset('lambda'),
  handler: 'index.handler',
  timeout: cdk.Duration.seconds(30),
  memorySize: 256,
});

// Create API Gateway
const api = new apigw.RestApi(this, 'MyApi', {
  restApiName: 'My Service',
});

// Connect them
api.root.addMethod('GET', new apigw.LambdaIntegration(handler));

Lambda function + API Gateway + all the IAM permissions, wired up correctly. In 20 lines.

Cost Optimization Patterns

One thing I've learned building CloudPruneAI: most cloud waste comes from missing simple configurations. CDK makes it easy to enforce good defaults:

// Always set log retention (CloudWatch logs grow forever by default!)
import * as logs from 'aws-cdk-lib/aws-logs';

const myFunction = new lambda.Function(this, 'MyFunction', {
  // ... config
  logRetention: logs.RetentionDays.TWO_WEEKS, // Don't pay for logs forever
});

// Always use lifecycle rules on S3
new s3.Bucket(this, 'LogsBucket', {
  lifecycleRules: [{
    transitions: [{
      storageClass: s3.StorageClass.INTELLIGENT_TIERING,
      transitionAfter: cdk.Duration.days(30),
    }],
    expiration: cdk.Duration.days(365),
  }],
});

These patterns prevent the "silent cost creep" that hits most AWS accounts.

Destroying Resources

When you're done experimenting:

cdk destroy

CDK removes everything it created. Clean.

Common Gotchas

1. Bootstrap once per account/region

cdk bootstrap aws://ACCOUNT_ID/REGION

2. Stateful resources need care

By default, CDK protects databases and buckets from accidental deletion. For dev environments:

removalPolicy: cdk.RemovalPolicy.DESTROY,
autoDeleteObjects: true, // For S3 buckets

3. Use cdk diff before deploy

Always. It's saved me from many "oops" moments.

Next Steps

Read constructs: Browse Construct Hub for pre-built patterns
Try L2 constructs: Higher-level abstractions like ApplicationLoadBalancedFargateService that wire up 10+ resources in one line
Organize with stages: Use cdk.Stage for multi-environment deployments

Resources

AWS CDK Documentation
CDK Patterns - Real-world examples
Construct Hub - Community constructs

CDK changed how I think about infrastructure. It's not a config file you maintain - it's code you can test, refactor, and actually understand 6 months later.

Give it 10 minutes. Your future self will thank you.

What's your experience with IaC? Still using CloudFormation YAML, or have you moved to CDK/Terraform? Drop a comment below.

5 AWS Resources You're Probably Overpaying For (And How to Fix Each One)

Germán Neironi — Tue, 13 Jan 2026 13:53:53 +0000

Last month I analyzed 249 EC2 instances across 3 AWS accounts for a mid-market fintech company. The result? $256,000/year in potential savings. That's $21,000 every month going to waste.

The scary part: this isn't unusual. According to Flexera's 2024 State of the Cloud Report, 32% of cloud spend is wasted. Most companies have no idea they're overpaying.

Here are the 5 most common culprits I find in almost every AWS account—and how to fix them.

1. Oversized EC2 Instances

The problem: You launched a t3.xlarge because you weren't sure what you'd need. Now it's been running at 5% CPU for 6 months.

How common: In my analysis, 70-80% of instances were oversized by at least one size class.

How to detect:

# Check average CPU over last 14 days
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-xxxxx \
  --start-time $(date -d '14 days ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date +%Y-%m-%dT%H:%M:%S) \
  --period 86400 \
  --statistics Average

The fix: If average CPU is below 20% for 2+ weeks, downsize. A t3.medium at $30/month vs t3.xlarge at $120/month adds up fast.

Potential savings: 50-75% per instance

2. Unattached EBS Volumes

The problem: You terminated an instance but forgot to delete its volumes. Now you're paying for storage nobody uses.

How common: I typically find 5-15 orphan volumes per account.

How to detect:

aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].[VolumeId,Size,CreateTime]' \
  --output table

If a volume shows status: available, it's not attached to anything.

The fix: Delete them. But first, create a snapshot if you're paranoid (snapshots are ~$0.05/GB/month vs $0.10/GB/month for volumes).

Potential savings: $0.10/GB/month per volume

3. Old EBS Snapshots

The problem: Automated backups create snapshots daily. Nobody deletes them. A year later you have 365 snapshots of the same volume.

How to detect:

aws ec2 describe-snapshots \
  --owner-ids self \
  --query 'Snapshots[?StartTime<=`2024-01-01`].[SnapshotId,VolumeSize,StartTime]' \
  --output table

The fix:

Keep the last 7-30 days (depending on your compliance needs)
Delete everything older
Set up a lifecycle policy with AWS Data Lifecycle Manager

Potential savings: Can be thousands/month for active accounts

4. EBS gp2 Volumes (Instead of gp3)

The problem: gp3 launched in 2020 with 20% lower base cost AND better performance. Yet most accounts still have gp2 volumes because "it works, why change it?"

How common: In my analysis, 60%+ of volumes were still gp2.

How to detect:

aws ec2 describe-volumes \
  --query 'Volumes[?VolumeType==`gp2`].[VolumeId,Size,VolumeType]' \
  --output table

The fix: Migrate to gp3. It's a live operation, no downtime required:

aws ec2 modify-volume \
  --volume-id vol-xxxxx \
  --volume-type gp3

Potential savings: 20% per volume, zero effort

5. Idle RDS Instances

The problem: A dev database someone created for testing 8 months ago. A staging DB that nobody uses anymore. They're running 24/7.

How common: 1-3 per account, often in non-prod environments.

How to detect: Check connections over the last 14 days:

aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name DatabaseConnections \
  --dimensions Name=DBInstanceIdentifier,Value=my-db \
  --start-time $(date -d '14 days ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date +%Y-%m-%dT%H:%M:%S) \
  --period 86400 \
  --statistics Maximum

If max connections = 0 for 2 weeks, it's idle.

The fix:

For dev/test: Stop it (you can start it when needed)
For truly unused: Take a final snapshot and delete it
Consider Aurora Serverless for dev workloads (scales to zero)

Potential savings: $50-500/month per idle instance

Real-World Example: Mid-Market Fintech

Here's a real analysis I ran recently for a fintech company with 3 AWS accounts:

Metric	Value
EC2 instances analyzed	249
Recommendations generated	72
Monthly savings potential	$21,340
Annual savings potential	$256,076

The breakdown:

Oversized instances: 60%+ were running at <20% average CPU
gp2 → gp3 migrations: Immediate 20% savings, zero downtime required
Orphan resources: Multiple unattached volumes and outdated snapshots

This aligns with industry benchmarks—Flexera reports 32% of cloud spend is typically wasted, and Gartner finds 2-3x overprovisioning is common.

The Real Problem

Running these checks manually is tedious. And even if you do it once, waste accumulates again within weeks.

That's why I built CloudPruneAI—it scans your AWS accounts automatically and generates Infrastructure as Code (CDK) to implement the fixes. Instead of a report you'll forget about, you get deployable code.

But even if you never use a tool, run these 5 checks today. You might be surprised what you find.

What's the biggest AWS cost surprise you've discovered? I'd love to hear your stories in the comments.