Most cloud problems are old infrastructure problems wearing a new name.
y. · Mission, BC · *
Before cloud, before AWS, before FinOps, there was hardware. I started as an electronics maintenance engineer in India, maintaining heavy factory machinery where downtime was not an abstract metric. If something failed, production stopped. You learned to troubleshoot with your hands, your ears, a multimeter, and whatever documentation the machine still had left.
After that, I taught math and reasoning for GMAT, GRE, SAT, CAT, and other exams. That chapter still shows up in how I build: break the problem down, find the pattern, explain it clearly, and never confuse a formula with understanding.
Then I moved to Canada for wireless telecom. My first infrastructure work here was physical: pulling LAN cables, racking routers and switches, mounting firewalls, tracing ports, labeling gear, and learning how networks actually live in buildings. Not architecture diagrams. Real closets. Real cables. Real outages.
From there came larger environments: Canadian enterprises, merger work, MSP infrastructure where BGP, peering, and carrier relationships were everyday tools. Cloud consulting later put me in rooms where architecture, cost, security, and networking decisions had to be explained clearly to executives and engineers. That was the chapter where infrastructure stopped being a certification topic and became an operating discipline.
Kulshan is the tool I wanted during real customer conversations. Local, read-only, and boring in the best way.
Kulshan produces deterministic, inspectable evidence that humans and AI systems can verify.
The AWS chapter added another layer. Networking, hybrid connectivity, and the cost side of cloud at scale. The same pattern kept repeating. Finance had the bill, engineering had the blame, and the dashboards had numbers without causes.
Kulshan runs inside the customer's environment, uses the IAM policy they approve, and produces one report people can actually discuss instead of argue around. Founder-led and deliberately small. The goal is not to collect customer data or build another place to log in. The goal is to make the AWS bill explainable, connect cost to architecture, and turn a vague cloud-spend argument into a clear technical conversation.
If any of this resonates, send the shape of your AWS bill problem in two sentences. I will read it.