Cloud infrastructure has made it easier than ever to deploy applications, scale workloads, and experiment with new technologies.
But there is another side to that flexibility: cloud costs can grow quickly, and understanding where the money goes is not always straightforward.
This is something I experienced firsthand while building my own technology products.
As infrastructure expanded across cloud services and environments, I found myself asking a simple question:
Can we make cloud cost optimization more actionable, rather than just showing users how much they are spending?
That question eventually became the starting point for CloudSlasher.
In this article, I want to share the problem we are trying to solve, some of the engineering considerations behind the platform, and why I believe cloud optimization needs to move beyond dashboards and recommendations.
1. The problem: Visibility is useful, but action is what matters
Most organizations running cloud infrastructure already have access to some form of cost reporting.
They can view spending by service, account, subscription, project, or resource.
They can identify which services are consuming the most money and compare spending over time.
But identifying a high-cost resource does not automatically tell an engineering team what to do next.
Consider a virtual machine that appears underutilized.
Should it be resized?
Can it be stopped?
Is it supporting a production workload?
Does it have dependencies on other services?
Is there a performance or availability requirement that prevents modification?
A recommendation to reduce infrastructure cost is useful only when it considers the operational context.
This is where I believe many cloud optimization workflows need to evolve.
The objective should not simply be to identify potential savings. It should be to help teams understand the impact of a proposed change and make informed decisions about implementing it.
2. Why I started building CloudSlasher
While working on my own products, I was using cloud infrastructure and experimenting with different services and deployment configurations.
Like many developers and small teams, I had to be conscious of infrastructure costs.
I wanted better visibility into what was running, how resources were being utilized, and where optimization opportunities existed.
At the same time, I realized that this problem was not limited to individual developers.
Organizations operate across multiple cloud providers, Kubernetes clusters, and different infrastructure environments.
Each environment has its own services, billing structures, resource models, and monitoring capabilities.
Managing costs across these environments can become difficult.
CloudSlasher emerged from the idea of bringing infrastructure visibility, cost intelligence, and actionable optimization into a more unified experience.
3. Multi-cloud makes optimization more complicated
One of the interesting engineering challenges is that cloud providers do not all represent infrastructure in the same way.
AWS, Microsoft Azure, Oracle Cloud Infrastructure, and Google Cloud each have different resource models, APIs, pricing structures, and billing mechanisms.
Kubernetes introduces another layer of complexity, particularly when teams need to understand the relationship between workloads, nodes, namespaces, and underlying infrastructure costs.
A useful multi-cloud platform needs to account for these differences.
Some of the key considerations include:
- Discovering infrastructure resources across providers.
- Understanding resource configurations and utilization.
- Collecting and interpreting cost information.
- Identifying potential optimization opportunities.
- Maintaining consistent resource visibility.
- Preserving provider-specific context.
The challenge is to create a common experience without losing the details that matter within each cloud environment.
A virtual machine, storage volume, database, or Kubernetes workload may look similar from a high-level perspective, but the operational and commercial implications can be very different.
4. Moving from cost visibility to actionable insights
CloudSlasher is being developed around the idea that cost optimization should be more than a reporting exercise.
The platform focuses on bringing together infrastructure discovery, cost insights, utilization information, and what-if analysis.
For example, imagine a team wants to evaluate whether a compute instance can be resized.
Rather than simply showing the current monthly cost, the workflow should help answer:
- What is the current configuration?
- How is the resource being utilized?
- What alternative configurations are available?
- What could the potential cost impact be?
- What operational considerations should be reviewed before making the change?
This is where contextual analysis becomes important.
An optimization recommendation should be treated as a proposal to evaluate, not an instruction to execute blindly.
5. Why Terraform and OpenTofu matter
Another important part of the CloudSlasher direction is infrastructure as code.
Many engineering teams already manage infrastructure using tools such as Terraform and OpenTofu.
Instead of asking users to make every infrastructure change manually, there is an opportunity to translate an optimization recommendation into a proposed infrastructure configuration change.
For example, a proposed compute resizing operation could be represented as a change to the relevant infrastructure configuration.
The team can then review what is changing, understand the potential impact, and decide whether to proceed.
This approach has several advantages:
- Changes can be reviewed before implementation.
- Infrastructure configuration remains version-controlled.
- Teams can maintain an audit trail.
- Changes can follow existing engineering processes.
- Approval can remain with the people responsible for the environment.
The important distinction is that identifying an optimization opportunity and safely implementing it are two different problems.
Infrastructure as code provides a useful bridge between the two.
6. GitOps: Keeping engineering teams in control
I also believe cloud optimization workflows should fit into the way engineering teams already work.
For teams using Git-based infrastructure workflows, a proposed remediation can be represented through a change that can be reviewed before it is merged.
This creates an opportunity to connect optimization workflows with GitOps practices.
A possible workflow looks like this:
- Discover infrastructure and identify an optimization opportunity.
- Evaluate the proposed change.
- Generate or prepare the infrastructure configuration change.
- Submit it for review through a Git-based workflow.
- Allow the responsible team to review and approve it.
- Apply the change through the team's existing deployment process.
The benefit is that infrastructure changes do not need to bypass established governance and approval processes.
For enterprise environments, this matters.
Cost optimization should not introduce unnecessary operational risk or remove control from infrastructure teams.
7. Where AI fits into the picture
AI has the potential to improve how users interact with infrastructure information.
Cloud environments generate large amounts of configuration, utilization, cost, and operational data.
Understanding that information often requires knowledge of cloud services, infrastructure dependencies, and pricing models.
AI-assisted workflows can help users:
- Explore infrastructure information using natural language.
- Understand cost and utilization findings.
- Investigate potential optimization opportunities.
- Interpret proposed configuration changes.
- Work through remediation recommendations.
However, AI should not be treated as a replacement for accurate infrastructure data or deterministic validation.
An LLM may help interpret a user's request or explain a recommendation, but the underlying resource information, cost calculations, configuration changes, and approval workflows need appropriate validation.
For me, the interesting opportunity is combining AI with infrastructure intelligence and existing engineering automation practices.
8. Building for multiple cloud environments is not just an abstraction exercise
One of the lessons from working with multi-cloud environments is that standardization has its limits.
It is tempting to create a common model for every cloud resource and hide the provider-specific details.
But doing so can remove important context.
A cloud optimization platform needs to understand more than resource size and monthly cost.
It should also consider:
- Performance requirements.
- Availability and resilience.
- Security and governance.
- Application dependencies.
- Operational requirements.
- Provider-specific pricing and configurations.
The objective is not to make every cloud provider look identical.
It is to give users a consistent way to understand their environments while retaining the information required to make good decisions.
9. What building CloudSlasher has taught me
Building CloudSlasher has highlighted several important lessons.
Cost optimization is not just a finance problem.
It requires collaboration between engineering, operations, architecture, and finance teams.
Recommendations need context.
A resource that looks expensive or underutilized may have a valid operational reason for its current configuration.
Automation needs guardrails.
Generating a proposed infrastructure change is useful, but review, validation, and approval are essential.
Multi-cloud complexity is real.
Different providers have different resource models, APIs, pricing structures, and operational considerations.
Product usability matters.
Cloud optimization information needs to be understandable and actionable for the people making infrastructure decisions.
These are all areas we continue to explore and improve as the platform evolves.
10. Where we are going
The broader objective of CloudSlasher is to help teams move from simply understanding cloud expenditure to making more informed infrastructure decisions.
We want to bring infrastructure discovery, cost visibility, utilization insights, what-if analysis, and remediation workflows closer together.
The longer-term direction is to make cloud optimization more accessible and actionable while respecting the controls and governance required in real-world environments.
There is still plenty to build, test, and improve.
Website: https://cloudslasher.com
I'd love to hear from the cloud and DevOps community
For people working in cloud architecture, FinOps, platform engineering, and DevOps:
- What is the biggest challenge you face when optimizing infrastructure costs?
- Do you find cost dashboards sufficient, or do you need more actionable remediation workflows?
- Would you trust an AI-assisted system to propose Terraform or OpenTofu changes for review?
- How do you balance cost optimization with performance, availability, and security?
- What would make a multi-cloud optimization platform genuinely useful to your engineering team?
I'm sharing this as part of my journey building CloudSlasher and would genuinely appreciate feedback, technical perspectives, and ideas from the community.
Thanks for reading!
Top comments (0)