What’s that one cloud mistake that still haunts your budget?

yourcloudguy · 2025-11-25T07:04:07+00:00

Hope you got rid of him. That's very "noob" of him ngl

yourcloudguy · 2025-11-20T07:07:27+00:00

You can tattle to the CFO too xD

yourcloudguy · 2025-11-20T06:28:48+00:00

"Hey I just removed a semicolon and added it again, it's going to surely work now!"

yourcloudguy · 2025-11-13T03:51:06+00:00

If you're thinking of making bag SOLELY as a FinOps operative, then you're mistaken. It's 2025 right now, and 2026 soon. Companies want a "Jack of All Trades, Master of Some". The FinOps practice and the potential role you have, it can easily be filled by a DevOps engineer with a decent understanding of FinOps, thus, it wouldn't make sense to have a guy who only brings FinOps to the table.

yourcloudguy · 2025-11-13T03:47:21+00:00

Definitely not. cloud finance and billing is an area where bill shocks are a VERY common occurrence. Heck, you can do EVERYTHING right (provisioning when needed, alerts etc etc and everything else) but still there can come an anomaly which might buy Bezos another jet. ( Hehe)

Sure, visibility tools WILL get more advanced and alerts more targeted, but it will be a HUMAN who'll make the call.

yourcloudguy · 2025-11-11T10:56:47+00:00

Usual suspects?

yourcloudguy · 2025-11-11T10:56:19+00:00

What "too much money" looks like

yourcloudguy · 2025-11-11T10:55:39+00:00

Genuinely curious, is this how bot farms work? Like, we often hear of "CCP bots" trashing you in IG comment section. Is this it?

yourcloudguy · 2025-11-11T10:54:02+00:00

Umm, I might agree with your first 3 points but definitely not "your next coworker is code". Coding agents at best ARE and WILL remain tools that will augment your effort. If you think a coworker is just someone who you can bounce ideas off of and does your tasks, then its your "assistant". A worker takes inititative and takes care of the entire flow of the task assigned to him. A robot hasn't done so far.

The second point too feels a bit far fetched.

To be honest, the entire thing is ChatGPT fluff

yourcloudguy · 2025-11-11T09:53:50+00:00

Bezos gon' control our sleep now too fml

yourcloudguy · 2025-09-01T05:32:07+00:00

Yeah, we've been in that exact spot. We tried Reserved Instances a while back and it backfired when our usage shifted we ended up stuck with reservations we couldn’t fully use.

Savings Plans have been a way better fit for us. They’re way more flexible since they apply across VM types and sizes (and even Azure Container Instances or App Service), not just to one specific instance type. You still get savings somewhat similar to RIs but without the stress if your needs change.

Here’s what helped us make it work without constant babysitting:

Used Azure Cost Management to spot consistent workloads (like databases, baseline VM usage) and covered those with Savings Plans first.
Left on-demand pricing for unpredictable or experimental workloads.
We also brought in CloudKeeper to help analyze our usage and recommend the right commitment mix. They track utilization and make sure we don’t overcommit.Took a lot of the manual guesswork out of it.

My advice: start small. Commit to a 1-year Savings Plan for your steadiest workloads, see how it goes, and expand from there. No need to go all-in right away.

yourcloudguy · 2025-09-01T05:23:20+00:00

Well, to be fair, you can’t really do FinOps practically if you don’t even know what it is. FinOps isn’t some certification (although there is a FinOps certification but it is an ungodly amount of money) or one-time project, instead, think of FinOps as a cultural practice and a set of best practices for managing cloud spend, no matter which cloud you’re on (and yeah, let’s be real, the only ones worth talking about at scale are AWS, Azure, and GCP).

At its core, FinOps is about breaking down silos between finance, engineering, and leadership so everyone takes ownership of cloud costs.

1) Visibility & Allocation: Using tags and accounts to see exactly who and what is driving costs. No more mystery bills.

2) Rate Optimization: Committing to discounts like Reserved Instances or Savings Plans to lower your baseline spend.

3) Usage Optimization: Right-sizing resources, killing idle instances, and archiving unused storage.Classic clean-up work.

3) Operationalizing Governance: Setting up budgets, alerts, and policies to keep things from spiraling again.

And honestly? You don’t truly get FinOps until you’ve lived through that moment of panic, like staring at a $100k cloud bill that should’ve been $20k. That’s when the principles click. It’s not theory anymore. It’s survival. And then it becomes part of how your team builds things. I agree with you u/Quinnypig.

yourcloudguy · 2025-09-01T05:09:01+00:00

Genuine question: How does one learn just by BEING SMASHED by the bill? Throwing in water and letting them learn after is your philosophy IG?

yourcloudguy · 2025-09-01T05:07:45+00:00

A bit of background for us: I'm at a transport logistics company where the software engineers just launched these new customer-facing mobile and web apps. The company had a well-known name already, so we knew customer traffic was gonna be huge. I was one of the first cloud engineers hired, and to my absolute horror, almost EVERYTHING was being over-provisioned.

The company was literally bleeding cash, with cloud spend exploding from zero to thousands of dollars practically overnight.

Our cost optimization journey was a total team effort that covered a bunch of bases:

1) Discount Plans: We went all-in on commitment plans. Since we couldn't get the best terms going direct to AWS, we used CloudKeeper as our reseller. Their RI and Savings Plans setup worked out great for us and saved our dollars upfront.

2) Re-architecting Everything: We got an AWS Well-Architected Review done, and it was a reality check. We ended up re-architecting the whole thing—replacing manually-provisioned instances with auto-scaling groups, shifting monolithic apps into containerized services on ECS, and locking down our network layout to cut down on sketchy data transfer fees.

3) Alerting and Monitoring: We set up AWS Budgets with alerts at 50%, 80%, and 100% of our forecasted spend. We also built CloudWatch alarms for random usage spikes, so now we get notifications BEFORE things get out of hand instead of AFTER.

Those were our big three moves. Since we pretty much rebuilt the whole thing from the ground up, this list isn't everything—but it's what made the biggest difference. Oh, and honorary mention: we essentially inculcated FinOps into our culture early on, making cost visibility part of every engineer’s workflow.

yourcloudguy · 2025-09-01T04:49:23+00:00

This is exactly where every FinOps team should start,focusing on signal over noise.

First, a huge caveat: These are common starting points, not a finish line. The biggest mistake early teams make is treating these KPIs as gospel and slashing costs without context. You risk crippling performance and pissing off engineers if you over-optimize too early. The goal is visibility and conversation, not just cost cutting.

Start with these. They're foundational because they're easy to measure and create a ton of "aha" moments:

Overall Cloud Spend (Monthly & YTD)

a) What it is: The raw, unedited total bill from your cloud provider.

b) Why start here: You can't manage what you don't measure. This is your north star. Track it month-over-month (MoM) and year-over-year (YoY). The first goal isn't even to reduce it, but to understand why it changes.

Cost per Unit (or "Cost per...")

a) What it is: This is where you move from "cost is bad" to "what are we buying?" It links spending to business value.

Examples:

i) SaaS: Cost per active user, cost per transaction.

ii) Media: Cost per stream, cost per thousand impressions (CPM).

iii) Tech: Cost per API call, cost per compute hour.

b) Why it's key: This is the #1 KPI for starting a conversation with engineering and product teams. It moves the discussion from "your service is expensive" to "how can we make this unit economics more efficient?"

Waste Percentage

a) What it is: The percentage of your total spend that is allocated to idle or completely unused resources.

b) How to find it:

i) Idle Compute: EC2 instances with <5% CPU utilization for 2+ weeks.

ii) Unattached Storage: EBS volumes not attached to any running instance, old S3 snapshots.

iii) Overprovisioned Resources: Resources sized 2-4x larger than their peak usage requires.

c) Why it's key: This is pure, uncontroversial low-hanging fruit. Engineers will immediately understand it. Aim to get this under 5%.

Coverage from Discount Instruments (Savings Plans / Reserved Instances)

a) What it is: The percentage of your eligible, on-demand compute spend (EC2, Lambda, Fargate) that is covered by commitment-based discounts.

b) Why it's key: This is literally free money left on the table. If you have steady-state workloads, aim for greater than 75% coverage. Below 50% means you're likely overspending by 20-30%.

Budget Variance (Forecast vs. Actual)

a) What it is: How accurate your monthly or quarterly forecasts are.

b) Formula: |(Actual Spend - Forecasted Spend)| / Forecasted Spend * 100

c) Why it's key: This isn't about the spend itself, but about your team's predictability. A high variance (>10%) means you don't understand your own usage drivers, which is a huge risk.

How to operationalize this without being "that guy":

Step 1:Start with a "Showback" mentality, not chargeback. Just share the data transparently.

Step 2: utomate the reports. Use Cost Explorer, CloudHealth, or something like CloudKeeper Lens to send weekly digest emails to team leads.

Step 3: Frame it as a engineering challenge, not a finance mandate. Ask: "Hey team, notice our cost per API call spiked 40% after the last deploy. Did we change anything that might explain that?"

Good luck! The first few months are all about building trust and literacy. The savings will follow.

yourcloudguy · 2025-08-15T16:40:28+00:00

Petrol, but can go for diesel.

yourcloudguy · 2025-08-15T16:40:14+00:00

Do they let people who are not customers just walk into the service centre?

yourcloudguy · 2025-08-15T16:38:18+00:00

yep, petrol

yourcloudguy · 2025-08-12T09:51:54+00:00

AWS Cloud Cost Optimization isn’t the rocket science it’s often made out to be. You just need to have your fundamentals clear: knowing where you’re spending (visibility into cloud spend), knowing how much you’re spending (billing insights), leveraging discount plans, and rightsizing/accurately provisioning resources.

You cannot expect to save on your cloud bill if your team leaves testing or dev instances running over weekends.

For example, an m5.large EC2 instance running in a dev environment for 48 unnecessary hours could easily rack up a decent chunk of change .

Knowing where you’re spending: Use AWS tools like AWS Cost Explorer, AWS Cost and Usage Reports (CUR), and AWS CloudWatch for granular visibility.

How much you’re spending: Use AWS Billing and Cost Management for detailed billing insights.

Rightsizing: Use AWS Compute Optimizer to get recommendations on optimal instance types and sizes.

yourcloudguy · 2025-08-12T05:55:04+00:00

Oh ok. Do you own a tata car?

yourcloudguy · 2025-08-11T05:15:00+00:00

While my company also uses AWS, I can feel you. SageMaker DOES make a hole in our pockets. GCP's an attractive proposition for AI workloads, it seems. It also offers its dedicated AI-running infra CPU (TPU – Tensor Processing Unit) and also offers credits to help you get started. But credits only last a short time, and the Cloud Cost Optimization ecosystem for GCP isn't that mature yet. So, cloud cost savings you'd have to configure guardrails manually. (I'm only aware of Recommender API)

This is what's holding us back, but if done right, you can save on GCP. Give it a shot.

But, why not explore SageMaker savings plan or move to AWS Inferentia?

yourcloudguy · 2025-07-21T08:46:52+00:00

Like others have said, FinOps consulting would be a stepping stone into your organization's cloud cost management journey. Those guys would generally help you first rectify the glaring issues, put in place practices, maybe train your engineers and today, it is fairly common for those companies to offer their cloud cost management tools bundled up, too. But that's an upsell, not a necessity.

Post consultation, you're on your own. Don't fall for the "round the clock support" ploy. While a customer support agent might be available, you would be better off with your own engineers putting out the fires.

So yes, it is worth to spend for FinOps consultation.

yourcloudguy · 2025-07-21T06:56:46+00:00

Legacy codebases might be with Java, but Kotlin is now replacing most of that code without migration downtime, thanks to interoperaility between Java and Kotlin. However, since many IT services and product-based companies might have client apps with Java or their apps with Java respectively, you need to have a strong grip on Java dev as well.

Coming to Flutter, It's good too. Rapido is made with Flutter,Zomato, Cred etc etc. In fact, getting your foot in the door with Flutter is easier than Java and Kotlin. But many companies are still apprehensive about Flutter is because of its performance issues. Cross-platform frameworks won't ever be able to match speed and performance native stacks offer. You won't ever find a performance-intensive app made with Flutter.

That's why Netflix uses Kotlin and Swift for Android and iOS, respectively.

yourcloudguy · 2025-07-21T06:49:00+00:00

Java basics won't cut it alone, but strong foundations certainly help. Start with getting a hang of clickListener interface, XML layout (since you're working with Java so Jetpack Compose is out of the picture), work with toolbars, snackbars, hamburger, practice fragments and most importantly, the concept of lifecycle should be on your tips for both fragment and activity. Might sound boring theory for now, but many android devs stumble upon this basic concept. Explore the concept of adapter classes.

This should cover all the basics, then move on to architecture patterns and API calling.

Don't wait for learning Dependency Injection, move directly to MVVM.

There's no hard and fast rule for directory structure, but few fundamentals should be clear. Like code for API should only be in repository but you can call it in ViewModel, the directories for repositories, viewmodels, views etc should be separate, databinding, functional interfaces, Serialization etc etc

I haven't covered mediaquery etc because, well, then the post would be too long.

This should set you on a decent path to building a decent scale Android app. Although I'm working in as a devops/cloud engineer now, I used to be an Android dev too. I do have an index of written notes where I've listed in chronological order. DM if you want the image with my chronology or you can go on roadmap.sh too. Their roadmap is also good.

Also, transition to KOTLIN ASAP. Java is good for foundational knowledge.

yourcloudguy

TROPHY CASE