StageAuto 1.0.8 — I added 5 FinOps checks and improved Multi-AZ false-positive handling
I just finished StageAuto 1.0.8.
StageAuto is a desktop Terraform infrastructure risk analyzer focused on Security, Architecture, Compliance and FinOps.
This update was mainly focused on making the FinOps analysis more useful.
What changed in 1.0.8
I added five new FinOps checks focused on infrastructure cost optimization, including signals around:
- NAT Gateway traffic and potential VPC endpoint opportunities
- RDS storage optimization
- potentially unused EBS volumes
- potentially unused Elastic IPs
- additional storage/cost optimization opportunities
I also improved the RDS Multi-AZ check.
Previously, treating a missing multi_az attribute as a problem could create false positives.
The analyzer now distinguishes between an explicitly disabled configuration and an attribute that simply isn't specified.
For example:
multi_az = false
can generate a finding.
But:
resource "aws_db_instance" "database" {
engine = "postgres"
}
does not automatically mean that the database is incorrectly configured.
I specifically tested the safe case to make sure the change didn't remove the existing detection.
The goal isn't to generate the maximum number of warnings.
It's to generate findings that are actually useful.
I'm continuing to build StageAuto around that principle: fewer noisy warnings, more actionable infrastructure analysis.
Would love feedback from people working with Terraform/AWS on which FinOps checks you think would be most valuable next.
The “fewer noisy warnings” principle is probably more important than the number of checks added. Once infrastructure findings become noisy, people stop trusting the analyzer altogether. Curious which FinOps checks users actually find worth acting on rather than merely interesting to see.
Couldn't agree more — alert fatigue is the quickest way for a developer tool to get uninstalled or ignored.
From what I’ve seen, FinOps checks fall into two clear buckets:
Immediate Low-Risk Wins (High Actionability):
Unused Elastic IPs and unattached EBS volumes. These are literal money sinks with almost zero risk to clean up. When an analyzer points these out, people act on them immediately because it's instant ROI.
High-Impact Architectural Shifts:
NAT Gateway data transfer vs. VPC Endpoints. In AWS, cross-AZ or internet-routed traffic to internal services (like S3) through a NAT Gateway gets expensive fast. Pointing out that a Gateway Endpoint could route that traffic for free/cheap isn’t just "interesting"—it often cuts hundreds from a monthly bill with a minor Terraform change.
What we actively avoid:
Guessing resource sizing (like telling someone to downgrade an EC2 instance) purely from static code analysis without runtime metrics. That creates massive noise because the analyzer doesn't know the workload's actual CPU utilization.
Keeping checks deterministic and high-ROI is definitely the priority over sheer check count!
That distinction is useful. I’d be interested in continuing the conversation around what users actually act on. If you’re open to it, what’s the best email to reach you at?