I've been reflecting on the balance between useful automation and automation to avoid at all costs when it comes to AWS cost optimizations. There are some actions that seem relatively safe, like changing instance types from gp2 to gp3, cleaning up CloudWatch log retention, or removing unattached EBS volumes after snapshots. However, other tasks feel riskier, such as making changes to NAT or endpoints, stopping or deleting RDS instances, or anything that could impact routing or application behavior. It appears many teams aren't against automation in general; they just have various comfort levels based on the potential impact and how easy it is to evaluate the changes. Really curious to hear your thoughts—where do you draw the line for AWS cost cleanup? What tasks would you be comfortable letting a tool manage, such as just flagging items, generating remediation plans, opening an IaC pull request, or actually executing changes? This trust boundary seems just as intriguing as the optimization itself.
6 Answers
FinOpsly is great for forecasting cost issues, and Infracost works well for estimating costs with IaC, albeit manually. Vantage adds visibility but is weaker on predictions.
I think it's best to use a tool that can suggest cost-saving actions but avoid any that automatically remediate issues. It's way easier to trust actionable guidance over actual execution.
Absolutely! Guidance feels safer than letting a tool make changes automatically. It’s all about finding that middle ground.
When designing solutions, cost optimization should be the main goal from the start. Otherwise, late fixes are either ineffective or too disruptive.
So true! If you don’t build cost in from the beginning, any fixes may end up causing more issues down the line than they solve.
I'd be wary of all tools. While I appreciate some recommendations, like from Trusted Advisor, automation on actual applications feels too risky.
I get that. Trusted Advisor is quite reliable for suggestions, and it's a whole different ballgame once a tool starts making decisions without human input.
I see auto-remediation as a recipe for configuration drift. I’d prefer a tool that does a pull request for humans to review and deploy. Anything else seems risky.
That’s a smart perspective. Direct changes can lead to drift in an IaC environment, so a review process is key to maintaining system integrity.
For tasks like deleting backups, I’d set strict parameters. AWS offers this capability, and trying to automate it wouldn't significantly enhance the value. The challenge lies in acknowledging the drift that might still incur costs and the follow-through at the team level, rather than relying solely on the tool.
Exactly! If AWS has a native way to manage backups, then it’s not really worth automating further. The real issue is keeping track of unseen costs and ensuring someone handles them.
Nice breakdown! But I'm often stuck on what needs fixing after we spot an issue, as no one seems to take ownership for the resolution.