DEV Community: KloudAudit

How to cut your AWS RDS costs by 65% in 20 minutes (without touching production)

KloudAudit — Wed, 13 May 2026 11:37:30 +0000

This is the single most common finding in every cloud bill I audit.

Dev and staging RDS instances running 24/7 at production size.

A db.r5.xlarge costs $876/month running continuously. If your team uses it 8 hours a day on weekdays, you're paying for 720 hours and using 170. That's a 76% waste rate on a single instance.

The fix takes 20 minutes and touches nothing in production.

The problem in numbers

db.r5.xlarge on-demand:  $876/month  (720 hrs)
db.r5.xlarge scheduled:  $306/month  (252 hrs — weekdays 8am-7pm)
Monthly saving:          $570/month
Annual saving:           $6,840/year

Multiply that by 2-3 dev/staging environments and you're looking at $15,000–$20,000/year on instances that sleep most of the time.

Step 1: Find your idle RDS instances

# List all RDS instances with their sizes and status
aws rds describe-db-instances \
  --query 'DBInstances[*].{ID:DBInstanceIdentifier,Class:DBInstanceClass,Status:DBInstanceStatus,MultiAZ:MultiAZ}' \
  --output table

Look for anything that:

Has "dev", "staging", "test", or "qa" in the name
Is the same instance class as production
Has Multi-AZ enabled (almost never needed for dev)

Step 2: Create the IAM role

cat > trust-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "lambda.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}
EOF

aws iam create-role \
  --role-name rds-scheduler-role \
  --assume-role-policy-document file://trust-policy.json

aws iam attach-role-policy \
  --role-name rds-scheduler-role \
  --policy-arn arn:aws:iam::aws:policy/AmazonRDSFullAccess

Step 3: Create the Lambda function

# rds_scheduler.py
import boto3
import os

def handler(event, context):
    rds = boto3.client('rds')
    action = event.get('action')  # 'start' or 'stop'
    instances = os.environ.get('RDS_INSTANCES', '').split(',')

    for instance_id in instances:
        if not instance_id.strip():
            continue
        try:
            if action == 'stop':
                rds.stop_db_instance(DBInstanceIdentifier=instance_id.strip())
                print(f'Stopped: {instance_id}')
            elif action == 'start':
                rds.start_db_instance(DBInstanceIdentifier=instance_id.strip())
                print(f'Started: {instance_id}')
        except Exception as e:
            print(f'Error on {instance_id}: {e}')

    return {'status': 'done', 'action': action, 'instances': instances}

Deploy it:

zip scheduler.zip rds_scheduler.py

aws lambda create-function \
  --function-name rds-scheduler \
  --runtime python3.12 \
  --role arn:aws:iam::YOUR_ACCOUNT_ID:role/rds-scheduler-role \
  --handler rds_scheduler.handler \
  --zip-file fileb://scheduler.zip \
  --environment "Variables={RDS_INSTANCES=your-dev-db,your-staging-db}"

Step 4: Create the EventBridge schedules

# Stop at 7pm every weekday
# Adjust UTC offset for your timezone — CET/Warsaw is UTC+1, so 18:00 UTC = 7pm local
aws events put-rule \
  --name "StopDevRDS" \
  --schedule-expression "cron(0 18 ? * MON-FRI *)" \
  --state ENABLED

# Start at 8am every weekday
aws events put-rule \
  --name "StartDevRDS" \
  --schedule-expression "cron(0 7 ? * MON-FRI *)" \
  --state ENABLED

# Get your Lambda ARN
LAMBDA_ARN=$(aws lambda get-function \
  --function-name rds-scheduler \
  --query 'Configuration.FunctionArn' \
  --output text)

# Add targets
aws events put-targets \
  --rule StopDevRDS \
  --targets "Id=1,Arn=$LAMBDA_ARN,Input='{\"action\":\"stop\"}'"

aws events put-targets \
  --rule StartDevRDS \
  --targets "Id=1,Arn=$LAMBDA_ARN,Input='{\"action\":\"start\"}'"

# Allow EventBridge to invoke Lambda
aws lambda add-permission \
  --function-name rds-scheduler \
  --statement-id allow-eventbridge \
  --action lambda:InvokeFunction \
  --principal events.amazonaws.com \
  --source-arn $(aws events describe-rule --name StopDevRDS --query 'Arn' --output text)

Step 5: Downsize the instance too

While you're here — dev doesn't need a db.r5.xlarge. Drop to db.t3.medium for another 70% saving:

aws rds modify-db-instance \
  --db-instance-identifier your-dev-db \
  --db-instance-class db.t3.medium \
  --apply-immediately

Combined result:

db.r5.xlarge 24/7:       $876/month  (original)
db.r5.xlarge scheduled:  $306/month  (schedule only)
db.t3.medium scheduled:  $89/month   (schedule + downsize)

Annual saving:           $9,444/year — from one dev database

Step 6: Add a wake-up Slack command (optional)

Your team will occasionally need the DB outside hours. Give them a self-service way to start it:

# Create a Lambda function URL
aws lambda create-function-url-config \
  --function-name rds-scheduler \
  --auth-type NONE

Then in Slack: Apps → Slash Commands → /start-devdb → point to the URL with body {"action": "start"}.

Engineers can start the DB themselves without waiting for someone with AWS console access.

What this looks like in real teams

I've helped teams set this up in about 20 minutes. The conversation afterwards is always the same:

"I can't believe we were paying for that for 14 months."

Not because they didn't know. Because nobody sat down and looked.

This is one of 18 checks in KloudAudit — a free self-guided cloud cost audit that walks through all of these systematically. No AWS credentials required. Takes 15 minutes.

Quick reference

Action	Command
Find idle RDS	`aws rds describe-db-instances --query ...`
Stop instance now	`aws rds stop-db-instance --db-instance-identifier NAME`
Start instance now	`aws rds start-db-instance --db-instance-identifier NAME`
Check instance state	`aws rds describe-db-instances --db-instance-identifier NAME --query 'DBInstances[0].DBInstanceStatus'`

What's your team's current RDS setup — scheduled or running 24/7?

Drop your setup in the comments — genuinely curious how common this is.

The 5 AWS charges silently draining your budget (and how to fix each one)

KloudAudit — Sun, 03 May 2026 18:29:14 +0000

The 5 AWS charges silently draining your budget (and how to fix each one)

I've reviewed a lot of cloud bills over 7 years as a DevOps engineer.

The waste isn't exotic. It's not misconfigured Kubernetes clusters or obscure data transfer fees nobody knew existed. It's the same five things, over and over, on teams that genuinely believe they're managing costs well.

Here's what they are — and exactly how to fix each one.

1. Dev and staging RDS running 24/7

Your production database needs to run continuously. Your dev database does not.

A db.r5.xlarge runs ~$876/month. If your team uses it 8 hours a day on weekdays, you're paying for 720 hours and using roughly 170. That's $626/month funding nothing.

The fix is a Lambda schedule. Takes 20 minutes to set up, runs forever:

# Stop dev RDS at 7pm every weekday
aws events put-rule \
  --name "StopDevRDS" \
  --schedule-expression "cron(0 17 ? * MON-FRI *)" \
  --state ENABLED

# Start it at 8am
aws events put-rule \
  --name "StartDevRDS" \
  --schedule-expression "cron(0 8 ? * MON-FRI *)" \
  --state ENABLED

Typical saving: 65% on affected instances.

The objection I always hear: "But what if someone needs it on the weekend?" In 7 years I've seen this come up twice. The fix: add a manual start button in your internal tooling. A single Lambda invocation.

2. Everything on On-Demand pricing

On-Demand is the rack rate. The price AWS publishes because they have to, not because they expect serious workloads to stay there.

If you've had stable compute running for 6+ months — and most teams have — you're paying a 30-45% premium for flexibility you're not using.

Compute Savings Plans are the easiest path. No instance family commitment, no region lock-in:

# See exactly how much you'd save
aws savingsplans describe-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days THIRTY_DAYS

Run that. Read the output. The "Estimated Monthly Savings" figure is money you're leaving on the table every month you wait.

Typical saving: 30-45% on covered compute. Zero architecture changes required.

3. Unattached EBS volumes

When you terminate an EC2 instance, AWS doesn't automatically delete the attached EBS volume. Unless you explicitly configured it to do so when you launched the instance, the volume sits there — charged at $0.10/GB/month — indefinitely.

Find them:

aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].{ID:VolumeId,Size:Size,Created:CreateTime,Type:VolumeType}' \
  --output table

Review the output. Anything created more than 30 days ago from an instance that no longer exists is almost certainly orphaned. Snapshot it for $0.05/GB/month if you're not sure, then delete the volume.

I've found $200–$1,400/month from this command alone. The worst case I've seen: a team that migrated to EKS 18 months prior and left 67 volumes from their old EC2 fleet running the whole time.

Typical saving: variable, but this takes 10 minutes to audit.

4. S3 storage never tiered

S3 Standard is $0.023/GB/month. S3 Glacier Instant Retrieval is $0.004/GB/month.

Your logs from 2023 don't need Standard. Neither do your backups, your old deployment artifacts, or the compliance exports nobody has opened since they were generated.

A lifecycle policy fixes this automatically:

aws s3api put-bucket-lifecycle-configuration \
  --bucket your-bucket-name \
  --lifecycle-configuration '{
    "Rules": [{
      "ID": "AutoTier",
      "Status": "Enabled",
      "Filter": {"Prefix": ""},
      "Transitions": [
        {"Days": 30, "StorageClass": "STANDARD_IA"},
        {"Days": 90, "StorageClass": "GLACIER_IR"}
      ]
    }]
  }'

Set it once. It runs forever. Data moves through tiers automatically as it ages.

Typical saving: 30-60% on storage older than 90 days.

5. NAT Gateway data processing charges

This one surprises people every time.

NAT Gateway charges $0.045 per GB processed — in both directions. If your microservices are calling AWS APIs (S3, DynamoDB, SQS) through a NAT Gateway instead of VPC endpoints, you're paying per-GB for every single request.

At scale this adds up fast. I've seen teams with $800/month NAT Gateway bills that dropped to $60 after adding two free endpoints.

The S3 and DynamoDB Gateway endpoints are free:

# Free endpoint for S3 — traffic no longer routes through NAT
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-xxxxxxxxx \
  --service-name com.amazonaws.eu-west-1.s3 \
  --route-table-ids rtb-xxxxxxxxx

# Free endpoint for DynamoDB
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-xxxxxxxxx \
  --service-name com.amazonaws.eu-west-1.dynamodb \
  --route-table-ids rtb-xxxxxxxxx

Typical saving: 10-40% of your NAT Gateway bill.

The pattern underneath all of this

None of these are obscure. Every experienced AWS engineer knows they exist.

The reason they accumulate anyway is always the same: the team is busy, the bill is complex, and nobody has sat down to look systematically. Cost Explorer shows you the numbers. It doesn't tell you which specific instances to reschedule, which volumes are orphaned, or which buckets have never had a lifecycle rule.

That's the gap.

A tool I built for exactly this

I got tired of doing this analysis manually on every engagement, so I built KloudAudit — a structured 18-checkpoint audit that walks through all five of these (and 13 more) with savings estimates specific to your bill size.

Free to run. Takes 15 minutes. No AWS account access required — you answer questions about your own setup, and it tells you what to fix and in what order.

If you write about cloud costs or DevOps, I also built a free embeddable savings calculator your readers can use directly on your articles. One script tag, no signup, no cost: kloudaudit.eu/widget/

What's the most surprising cloud cost you've discovered? I'm collecting war stories — drop it in the comments.

The 5 AWS charges silently draining your budget (and how to fix each one)

KloudAudit — Thu, 30 Apr 2026 06:39:09 +0000

Every AWS bill tells a story. After couple of years as a DevOps engineer reviewing cloud infrastructure, I've learned to read that story, and it almost always has the same five chapters.
These aren't exotic edge cases. They show up on the bills of well-run teams with experienced engineers. They survive because cloud billing is complex, everyone is busy, and "we'll optimise later" is the most expensive phrase in engineering.
Here's what to look for — and exactly how to fix each one.

1. Dev/Staging RDS Running 24/7

What it costs: A db.r5.xlarge running continuously costs ~$876/month. If it's only used 8 hours a day on weekdays, you're paying for 720 hours and using ~170.

Why it happens: The database got created for a sprint, the sprint ended, and nobody scheduled a shutdown.

The fix — Lambda stop/start schedule (20 minutes to implement):

`# Create an IAM role for Lambda with RDS stop/start permissions
aws iam create-role --role-name RDSScheduler \
--assume-role-policy-document file://lambda-trust-policy.json

Stop RDS at 7pm weekdays

aws events put-rule \
--name "StopDevRDS" \
--schedule-expression "cron(0 17 ? * MON-FRI *)"

Start RDS at 8am weekdays

aws events put-rule \
--name "StartDevRDS" \
--schedule-expression "cron(0 8 ? * MON-FRI *)"`

Savings: 65% reduction on affected instances.

2. Everything on On-Demand Pricing

What it costs: On-Demand is the list price the most expensive way to run EC2. If you've had stable workloads running for 6+ months, you're paying a significant premium for flexibility you're not using.
Why it happens: Reservations require commitment and upfront analysis. On-Demand requires neither.

The fix — Compute Savings Plans:

shell bash# Check your On-Demand spend for the last 3 months aws ce get-cost-and-usage \ --time-period Start=2026-01-01,End=2026-04-01 \ --granularity MONTHLY \ --filter '{"Dimensions":{"Key":"PURCHASE_TYPE","Values":["On Demand"]}}' \ --metrics BlendedCost

Check Savings Plans recommendations

shell aws savingsplans describe-savings-plans-purchase-recommendation \ --savings-plans-type COMPUTE_SP \ --term-in-years ONE_YEAR \ --payment-option NO_UPFRONT

Purchase a 1-year no-upfront Compute Savings Plan for your baseline usage. Zero architecture change. Zero risk.

Savings: 30–45% on covered compute.

3. Unattached EBS Volumes

What it costs: $0.10/GB/month sounds trivial. 50 forgotten 100GB volumes from a migration two years ago = $500/month. Every month. For nothing.

Why it happens: When you terminate an EC2 instance, AWS doesn't automatically delete the attached EBS volume unless you explicitly configured it to do so.
The fix — find and review them in 60 seconds:

bash# List all unattached EBS volumes with their size and creation date

aws ec2 describe-volumes \ --filters Name=status,Values=available \ --query 'Volumes[*].{ID:VolumeId,Size:Size,Created:CreateTime,Type:VolumeType}' \ --output table

# Delete a specific volume (after verifying you don't need it) aws ec2 delete-volume --volume-id vol-xxxxxxxxxxxxxxxxx

Before deleting: create a snapshot if there's any chance the data is needed. Snapshots cost ~$0.05/GB/month — a fraction of the volume cost.
Savings: variable, but I've seen $200–$1,200/month from this alone.

4. S3 Storage Never Tiered

What it costs: S3 Standard is $0.023/GB/month. S3 Glacier Instant Retrieval is $0.004/GB/month. Data from 2022 that nobody has accessed sitting in Standard costs 5.75x more than it needs to.
Why it happens: Lifecycle rules require deliberate configuration. Default bucket settings keep everything in Standard forever.

The fix — lifecycle policy (5 minutes):

bash# Apply intelligent tiering lifecycle rule to a bucket aws s3api put-bucket-lifecycle-configuration \ --bucket your-bucket-name \ --lifecycle-configuration '{ "Rules": [{ "ID": "IntelligentTiering", "Status": "Enabled", "Filter": {"Prefix": ""}, "Transitions": [ {"Days": 30, "StorageClass": "STANDARD_IA"}, {"Days": 90, "StorageClass": "GLACIER_IR"} ] }] }'

Savings: 30–60% on storage older than 90 days.

5. NAT Gateway Data Processing Charges

What it costs: NAT Gateway charges $0.045 per GB processed; in both directions. Microservices calling each other through a NAT Gateway instead of VPC endpoints can generate $1,000+/month in charges that appear as "data transfer" on your bill.
Why it happens: It's invisible. The architecture diagram looks fine. Nobody knows NAT Gateway charges per-GB until they see the bill.

The fix — VPC endpoints for AWS services:

`bash# Create a VPC endpoint for S3 (free — Gateway type)
aws ec2 create-vpc-endpoint \
--vpc-id vpc-xxxxxxxxx \
--service-name com.amazonaws.eu-west-1.s3 \
--route-table-ids rtb-xxxxxxxxx

Create a VPC endpoint for DynamoDB (free — Gateway type)

aws ec2 create-vpc-endpoint \
--vpc-id vpc-xxxxxxxxx \
--service-name com.amazonaws.eu-west-1.dynamodb \
--route-table-ids rtb-xxxxxxxxx`

S3 and DynamoDB Gateway endpoints are free. Traffic to these services no longer routes through NAT Gateway.

Savings: 10–30% of your NAT Gateway bill, potentially much more.

How to Find All of This in 15 Minutes

If you want to run through all five of these, plus 13 more checks across compute, storage, database, and networking, I built a free structured audit tool that does exactly this.

No account access required. No IAM roles. No agents. You answer questions about your setup and it flags issues with savings estimates.

kloudaudit.eu — free to run, takes 15 minutes.

What's the biggest AWS cost surprise you've found on your bill?
Drop it in the comments, always curious what patterns others are seeing.

How to cut your AWS bill by 20–45% without touching your architecture

KloudAudit — Mon, 27 Apr 2026 19:58:51 +0000

Cloud bills grow quietly.
You add a feature, spin up a database for testing, forget to delete it. You launch on On-Demand because you're moving fast. Your S3 bucket fills up and nobody sets lifecycle rules because "we'll do it later.
Two years later you're paying $8,000/month and your CFO is asking questions.
Here's a systematic way to audit your own bill in under an hour.
Step 1 — Compute: find your zombies
Pull a utilization report for the last 30 days. Any instance averaging under 10% CPU and 20% memory is a zombie. Either rightsize it or kill it. This alone typically saves 15–25% of compute spend.
Step 2 — Reservations: stop paying on-demand tax
If you've been running instances for 6+ months and they're stable, you're paying the most expensive rate possible. 1-year Reserved Instances or Compute Savings Plans cut this by 30–45% with zero architecture change.
Step 3 — Storage: tier everything
Data you haven't accessed in 90 days should not be in S3 Standard. Set lifecycle policies to move to Infrequent Access at 30 days, Glacier at 90 days. S3 Intelligent-Tiering does this automatically.
Step 4 — Databases: dev environments
Stop running your staging RDS 24/7. Use Lambda schedules to shut them down at 7pm and restart at 8am. That's 65% of the hours eliminated.
Step 5 — Spot for batch
Any workload that can tolerate interruption — CI runners, ML training, data pipelines — should be on Spot. 60–80% cheaper. AWS rarely reclaims Spot for most instance types.

I built a free tool that walks you through all of this systematically — kloudaudit.eu. 18 checkpoints, takes 15 minutes, no account access needed.
What am I missing? Drop your favorite cost-saving trick in the comments.