When I first started working in cloud computing, I thought the platform was something like Google Drive or Dropbox—just a place to upload files or photos that no longer fit on your phone. I assumed working in the cloud meant uploading stuff as fast as possible, and since that sounded simple enough, I decided to start my career in the cloud.
Initially, the project aimed to migrate workloads from physical servers to the cloud, specifically to AWS and GCP. But once I saw what the cloud really was… I wanted to quit! Still, I needed the job, so I stayed—for the learning opportunity and, honestly, for survival (it was my first paid job). I learned by Googling every tool I was supposed to use. I’d search things like “What is AWS for?” and compare that to the technical requirements of the company. I’d type “What is EC2 and how to launch it?”—and I’d launch it. I did the same with all the services: S3, RDS, and others that seemed to connect everything we’d deployed. In the end, we had a working infrastructure—but far from optimized. I was thrilled to hear we were part of the company’s most innovative project, the one that would keep us from becoming the next Kodak or Blockbuster (spoiler alert: it actually turned out worse).
The organizational structure was clear: apples with apples, pears with pears. The procurement team handled payments to the cloud provider, and the infrastructure team—us—just had to use it.
By the end of the fiscal year, the finance team realized the costs were out of control. Not because we had exceeded a specific budget—simply because we couldn’t afford it. With all the resources being launched daily by a 22-person team, we racked up nearly $10,000 a month in cloud costs, while our revenue wasn’t even half that.
That’s when we identified two big issues: first, we had no idea what resources were running or how much they cost, so we had no clue how to optimize them. Second, we didn’t know who was responsible for managing any of it.
We jumped into a panic plan aimed at quick wins to keep things going. We deleted instances, paused resources, and managed to cut costs by 20% compared to our average bill—we were saved! But… we also lost functionality due to deleting so many resources. After that, my searches shifted to “how to reduce cloud resources,” while internally I kept wondering, why am I, an infrastructure engineer, worrying about costs if I’m not in finance? These days I’d have a solid answer. Back then, I just kept cutting resources—without optimizing—until I had full control over who launched what, when, how, and why. It was complex and far from agile. Everyone (including me) hated “Cloud Economics.” But the truth is, we didn’t hate the concept—we hated the bad infrastructure practices we had created. Who would’ve thought everything in the cloud was so interconnected?
Our next organizational move was what I like to call the “deep and indecisive-pocket, victim” phase. Leadership decided to relaunch all the original functionalities that had been paused due to cost issues. They did it without setting a clear budget… and as you might guess, we blew past whatever invisible budget they hadn’t planned for. That uncertainty weakened our cloud strategy. We constantly played the “Are we really doing this or not?” game. After relaunching, we took steps like shutting down instances, resizing databases, and finally implementing lifecycle policies in S3. At last, we saw a light at the end of the tunnel. But the results were a never-ending cycle of changes that burned out our tech teams. They had no time for maintenance, updates, or real optimization—and the product started showing inconsistencies in the market, which led to decreased demand.
The next resource cleanup wasn’t just technical—it was human. I lost my job 😞, along with many of my teammates. Word was, that resource cleanup was super effective… cost-wise. A few months later, the company left the cloud altogether. Yep, full-on cloud repatriation. And just like that, I became a cloud hater. No job, no cloud. I went back to searching the internet—not just for how to find a job, but how to land one and keep it.
Years later, I now look back and call this my most humbling experience. It was a series of unfortunate events that led me into the world of FinOps. And today, I’m proud to remember that journey with every new project I take on, because I’ve learned that costs don’t just need to be reduced—they need to be optimized. And FinOps isn’t just about money—it’s about fostering a culture of innovation and value. (Happy ending: I was rehired by the same company to lead their FinOps efforts during their return to the cloud.)
