I’m a Cloud Architect, and I built aws-doctor because I found myself constantly running the same manual checks across different AWS accounts to find "zombie" resources. While AWS Trusted Advisor exists, the best checks are often locked behind paid Business/Enterprise support plans, and the AWS Console can be slow when you just want a quick "health check."
What it does: It’s a TUI (Terminal User Interface) that acts as a proactive checkup for your account.
Waste Detection: Scans for stopped instances (>30 days), unattached EBS volumes, unassociated Elastic IPs, and expiring Reserved Instances.
Cost Diagnosis: Compares your current month-to-date costs against the exact same period last month (e.g., Jan 1–15 vs. Feb 1–15) to spot spending velocity issues.
Trends: Visualizes cost history over the last 6 months.
The Tech Stack:
Written in Go (1.24).
Uses AWS SDK v2.
UI built with Charm's Bubbletea and Lipgloss (for the tables/styling).
It’s completely open-source and runs locally on your machine (using your standard ~/.aws/credentials).
I’d love to hear your feedback on the code structure or suggestions for other "waste patterns" I should add to the detection logic.
have you considered using https://github.com/hashicorp/terraform-exec to run terraform inside you go process to manage the entire AWS connection piece. Terraform being largely rock solid and frequently updated on this.
This is true, but be careful about losing the work experience. Companies love cloud computing and somehow are conditioned to want to pay for them and anyone who works on them. I received a devops job application rejection because they didn't see cloud computing providers on my resume. That's because I highlighted running my own dedicated servers.
That’s because architecting stuff for the cloud effectively means you’re building your infrastructure differently to how you’d run dedicated servers. I say this as someone who’s done both professionally.
As a DevOps hiring manager, if you said to me “I don’t have cloud experience but I can do all the same things with dedicated servers” then I’d likely pass on you for another candidate too.
A better way to frame your applications is “I have significant on prem experience using DevOps methodologies, and I’m excited to broaden them with Cloud technologies.” That way you’re acknowledging your knowledge gap and turning it into a positive.
One day, as you spend vast resources tracking and cutting and worrying about your AWS expenses, you’ll think “hey I could cut 100% of AWS costs by not using it!”.
Thinking about cutting AWS costs is your first step on the journey to never using it.
That’s great, until realise that you’re now spending money on infrastructure elsewhere instead.
I’m not going to pretend AWS is cost effective for every type of problem. But the comments here are overly simplistic.
Also, and more generally, I find it disappointing that when someone has made an open source tool to help the community, most of the comments are cheap attacks at the cost of running AWS. Poor etiquette guys.
> I’m not going to pretend AWS is cost effective for every type of problem. But the comments here are overly simplistic.
There overly simplistic comments from the "run from AWS" crowd as well as from the "just outsource everything to cloud" crowd. Nowadays going to cloud is still the easiest and safest bet if the company is not yours and it's big enough.
Run from AWS is also completely arbitrary. Someone building an expensive Rube Goldberg machine out of lambdas might hit cost problems way before someone essentially using AWS as a VPS provider with bare metal EC2
Hi HN,
I’m a Cloud Architect, and I built aws-doctor because I found myself constantly running the same manual checks across different AWS accounts to find "zombie" resources. While AWS Trusted Advisor exists, the best checks are often locked behind paid Business/Enterprise support plans, and the AWS Console can be slow when you just want a quick "health check."
What it does: It’s a TUI (Terminal User Interface) that acts as a proactive checkup for your account.
Waste Detection: Scans for stopped instances (>30 days), unattached EBS volumes, unassociated Elastic IPs, and expiring Reserved Instances.
Cost Diagnosis: Compares your current month-to-date costs against the exact same period last month (e.g., Jan 1–15 vs. Feb 1–15) to spot spending velocity issues.
Trends: Visualizes cost history over the last 6 months.
The Tech Stack:
Written in Go (1.24).
Uses AWS SDK v2.
UI built with Charm's Bubbletea and Lipgloss (for the tables/styling).
It’s completely open-source and runs locally on your machine (using your standard ~/.aws/credentials).
I’d love to hear your feedback on the code structure or suggestions for other "waste patterns" I should add to the detection logic.
Thanks!
have you considered using https://github.com/hashicorp/terraform-exec to run terraform inside you go process to manage the entire AWS connection piece. Terraform being largely rock solid and frequently updated on this.
could make this considerably more robust.
My AWS cost optimiser is to use a hosting provider instead of AWS.
Using AWS may not be your decision. If you're stuck using it by company policy, OP's tool could make you a workplace hero.
Sorry, I didn't understand the comment
Using Hetzner or IVH will cut your infra bill by 4x or 5x
This is true, but be careful about losing the work experience. Companies love cloud computing and somehow are conditioned to want to pay for them and anyone who works on them. I received a devops job application rejection because they didn't see cloud computing providers on my resume. That's because I highlighted running my own dedicated servers.
That’s because architecting stuff for the cloud effectively means you’re building your infrastructure differently to how you’d run dedicated servers. I say this as someone who’s done both professionally.
As a DevOps hiring manager, if you said to me “I don’t have cloud experience but I can do all the same things with dedicated servers” then I’d likely pass on you for another candidate too.
A better way to frame your applications is “I have significant on prem experience using DevOps methodologies, and I’m excited to broaden them with Cloud technologies.” That way you’re acknowledging your knowledge gap and turning it into a positive.
Cool. Enjoy!
Yup.
One day, as you spend vast resources tracking and cutting and worrying about your AWS expenses, you’ll think “hey I could cut 100% of AWS costs by not using it!”.
Thinking about cutting AWS costs is your first step on the journey to never using it.
That’s great, until realise that you’re now spending money on infrastructure elsewhere instead.
I’m not going to pretend AWS is cost effective for every type of problem. But the comments here are overly simplistic.
Also, and more generally, I find it disappointing that when someone has made an open source tool to help the community, most of the comments are cheap attacks at the cost of running AWS. Poor etiquette guys.
> I’m not going to pretend AWS is cost effective for every type of problem. But the comments here are overly simplistic.
There overly simplistic comments from the "run from AWS" crowd as well as from the "just outsource everything to cloud" crowd. Nowadays going to cloud is still the easiest and safest bet if the company is not yours and it's big enough.
> There overly simplistic comments from the "run from AWS" crowd as well as from the "just outsource everything to cloud" crowd.
Not in this thread there isn’t. And that’s what I’m replying to.
Run from AWS is also completely arbitrary. Someone building an expensive Rube Goldberg machine out of lambdas might hit cost problems way before someone essentially using AWS as a VPS provider with bare metal EC2
looks cool, are you using any tui framework for this?
They are using charm bracelet lip gloss and some others.
https://github.com/charmbracelet/lipgloss
I was thinking of building something like this just a couple of days ago. Looks awesome! Will definitely try it out
Thanks, if you think about something that might be improved, please open an issue!!!
Will try this one soon, ty!
Thanks!!! If you find something that can be improved, don't doubt opening an issue!