Operations | Monitoring | ITSM | DevOps | Cloud

On March 18, Jensen Huang took the stage at NVIDIA’s GTC conference in San Jose for a keynote that ran well over two hours — covering everything from CUDA’s 20-year history to humanoid robots that may one day wander Disneyland. But buried inside the spectacle was a remarkably clear-eyed articulation of the economic forces now bearing down on every enterprise that builds on cloud infrastructure.

Engineering teams are shipping faster than ever. AI coding tools like Claude Code and OpenAI’s Codex have quietly removed some of the biggest friction points in the development cycle — and the result is that FinOps teams are being asked to keep up with a pace most practitioners haven’t fully reckoned with yet. That acceleration has a cost consequence. More shipping means more services, more experiments, more infrastructure spun up without review cycles.

In 2025, many teams built strong FinOps foundations: These practices created visibility and control. Now it’s time to elevate. FinOps in Action is a three-part series focused on applying that foundation in real engineering scenarios. Each post highlights a different persona and shows how to move from visibility to operational discipline. Today, we focus on Engineering. Engineering teams influence cost through architecture decisions, scaling policies, and workload design.

If your SaaS product handles 1 million chatbot interactions per month, Amazon Lex alone could cost between $4,000 and $7,500. That range assumes current Amazon Lex V2 pricing of about $0.00075 per text request and $0.004 per speech request. Multiply the requests by the rate, and you’re done. Or are you? Conversational AI services rarely behave that neatly in production — and that includes AWS Lex. Amazon Lex is AWS’s conversational AI service for building chatbots.

Women leaders from CloudZero, Campfire, and Preql AI sat down to talk about what it actually takes to modernize finance in 2026 — AI spend, smarter tooling, and the skills that matter now for finance practitioners and executives looking to manage cloud and AI spend in a rapidly changing and unpredictable financial environment. On March 19, 2026, CloudZero and Campfire co-hosted a virtual panel in honor of International Women’s Month, called Building the Finance Function for the Future.

A real workflow showing how Claude + CloudZero MCP turns plain-English questions into actionable cost intelligence — no dashboards, no tickets, no waiting As Director of Finance and Accounting at a software company, my job can be described simply: Understand what we’re spending, who’s responsible, and whether we can get more efficient. But as anyone who’s had to wrangle AI costs knows, doing so for AI is anything but simple.

We hear a lot of war stories from the teams we work with. Horror stories about cloud bills, surprise overages, and the infrastructure decisions that seemed perfectly reasonable at the time. This one comes from Erik Dasque, CTO at Allure Security. It involves a junior developer, a Kubernetes CronJob, and a recurring bill that, if not caught, would have happened on a yearly basis.

Not long ago, cloud cost was an engineering problem. FinOps teams owned it, finance leaned in occasionally, and everyone else stayed out of it. Now, that’s changed. AI changed who has skin in the game. CFOs get asked about it in board meetings. CEOs field questions on earnings calls. The audience for cloud cost management has exploded — and that means the conversation CloudZero is built to enable isn’t only a technical one, it’s a business one.

Back in May of 2021, containers had already won. Kubernetes adoption was surging. ECS and EKS were powerful. But for many teams, deploying a simple containerized web service still meant stitching together clusters, networking rules, scaling policies, load balancers, IAM roles, and CI/CD pipelines. It felt heavier than it should. Developers no longer wanted more orchestration power. They wanted less operational drag.

Like most SaaS companies, CloudZero uses its own product. When we released cost per customer reporting, we tested it on ourselves first. And today, we use cost per customer reports regularly. Why? Because they help leadership answer board and renewal questions, including customer-level margins. Cost per customer is valuable and hard to get right. Multi-tenant systems and Kubernetes can hide the link between shared infrastructure (like EC2) and the customers using it.