The cloud bill arrives. Again, it’s higher than last month. The Redshift costs have mysteriously jumped from $2,000 to $9,000, and no one can explain why. Finance sighs but doesn’t ask questions. IT scrambles to investigate, burning two-weeks trying to understand what changed. 

This isn’t a hypothetical scenario—it’s the reality Ryan Wood, Engineering Manager at ElectroRoute Japan (ERJ), faced. But what makes his story compelling isn’t the problems he encountered. Every company faces cloud cost challenges. What matters is how a lean team of just five engineers transformed these challenges into a practice that saved millions of yen while managing nearly a petabyte of data. 

The Misconception That Holds Japanese Companies Back

Before diving into solutions, we need to address a fundamental problem: most Japanese companies don’t actually understand what FinOps is.

“When you say FinOps to anybody at my company, they think you actually mean financial operations in a more traditional sense,” Wood explains. “We have a FinOps team and they go around calculating our P&L for given projects, things like that. But they don’t think of it in maybe the more modern term where we’ve got a bunch of stuff we do in the cloud and how do we relate that to given projects.”

This confusion isn’t unique to ERJ. Across Japan, the term ‘FinOps’ is interpreted as traditional financial operations—tracking P&L, managing budgets, and calculating project costs. The modern definition—combining DevOps agility with financial accountability to maximize business value from cloud spending—remains foreign to most organizations. This misunderstanding extends to the various FinOps personas involved in cloud financial management, from executive to engineers.

The consequence of this misunderstanding is significant. Companies continue treating IT as a single line item expense, missing the opportunity to understand what drives value and what doesn’t. Finance departments accept that cloud bills will perpetually increase without understanding why engineers lack the visibility to optimize their architectures, and business stakeholders can’t make informed decisions about which projects or opportunities are worth pursuing. “This country does sort of consider any software development or IT to be a cost generator rather than a way to surface opportunity costs,” Wood notes. 

This mindset creates a vicious cycle: without proper FinOps practices, IT does appear to be a cost center. But without visibility into unit economics and project-level costs, companies can’t recognize IT’s value in enabling business opportunities. Implementing a robust FinOps strategy can break this cycle and transform how organizations view and manage their cloud resources.

The Surprise Billing Problems: Symptoms vs. Root Causes

Every organization experiences surprise billing events—those moments when costs spike unexpectedly and teams scramble to understand what happened. But these surprises are symptoms, not root causes.

For ERJ, the Redshift bill spike was symptomatic of a deeper issue: lack of granular visibility into what drives costs. “The bill just goes up and it always seems to just go up. It never goes down, you know?” Wood says with knowing frustration.

The team spent two weeks investigating before discovering the culprit: table locking. Their ETL processes were locking tables before writing data. With multiple processes trying to write concurrently, tables remained locked for 28 out of every 30 minutes. The Redshift cluster could never spin down because it was constantly in use.

But here’s the crucial insight: they only discovered this because they had implemented unit metrics through Octo—Alphaus’ cloud cost management tool. By tracking Redshift compute per query, they could see which processes consumed disproportionate resources. “We realized there were three or four processes that were consuming about 45% of our RPUs,” Wood explains.

The solution wasn’t just removing table locks. The team implemented a broader optimization strategy: batching smaller Parquet files in S3 into larger loader files optimized for Redshift ingestion. This reduced resource consumption by 45% while simultaneously improving performance.

This illustrates a fundamental FinOps principle: you can’t optimize what you can’t measure. Surprise bills will continue until you establish visibility into usage patterns and can attribute costs to specific processes, teams, and projects.

The Shared Resources Dilemma: Perfect vs. Good Enough

One of the most challenging aspects of FinOps is allocating costs for shared resources. Many companies struggle with this, and Japan is no exception. The common “solution”-dividing shared cost equally among teams- feels unsatisfying because it doesn’t reflect actual usage.

ERJ considered this approach. “We thought about doing it that way,” Wood says. “Our trading department is probably going to be about 75% of our usage, and then maybe after that, our FinOps department is another 20%, and then the rest is pretty standard.”

But they decided against simple proportional allocation for an important reason: “The company’s still in the growth phase. So we'd have to go back and sort of massage those numbers every month.” This reveals a critical decision point for organizations: the right allocation strategy depends on your context. For established companies at steady state, proportional allocation might work fine as a starting point. You can adjust the percentage monthly based on evolving understanding. For a small team, this manual approach might be less sustainable.

ERJ chose a different path: automation through tagging and unit metrics. Using Infrastructure as Code (Terraform), they achieved comprehensive resource tagging, enabling automated cost allocation. “We use Terraform, so that’s actually pretty easy to do because it’s just code, right? So we have really high levels of tagging across everything.”

But tagging alone wasn’t sufficient. “There’s so many resources that are just shared across all of our departments that just tagging alone doesn’t get you there,” Wood acknowledges. The next level required analyzing usage data—tracking compute per query, understanding which teams and processes consumed resources, and algorithmically splitting shared costs based on actual usage.

The lesson? Start with what’s achievable. Proportional allocation beats no allocation. Tagging beats proportional allocation. Usage-based allocation beats tagging. But don’t let perfect be the enemy of good. “You don’t start with everything being perfect, right?” Wood emphasizes. “You just kind of whittle it down.”

Unit Economics: The Game-Changing Metric

The ultimate goal of FinOps isn’t just understanding costs—it’s tying those costs to business outcomes. This is where unit economics becomes transformative.

ERJ’s journey toward unit economics began with a conversation with their head of contracting, “Wouldn’t it be great if we could get an idea of how much it costs from a cloud perspective for us to put in the contract?” Wood proposed. “You spend months trying to get everything lined up and get all this stuff ready. The risk team looks at it, the pricing team looks at it, but you have no idea how much it costs from the cloud.”

This becomes especially critical when moving into smaller contracts. “We’re trying to move into smaller contracts, like low voltage sites where you might be going to a single Lawson convenience store that has a rooftop solar,” Wood explains. “All of a sudden, cloud costs become a more significant portion of the business.”

Imagine being able to tell stakeholders: “This system costs us $8,000 per month and processed 10,000 trades. That’s 80 cents per trade.” Suddenly, business decisions become much clearer. When evaluating a potential trade that would net 200 yen but costs 100 yen to execute, stakeholders can make informed risk-reward assessments.

This is what ERJ is working toward. “We can say, hey, trading team, you wanted this system. Here’s how much it costs us a month, and here’s how much it costs us per trade you made using this system. How does that look for you guys?”

Unit economics transforms cloud costs from an abstract IT expense into a concrete business metric that enables better decision-making across the organization.

The Forecasting Challenge: Beyond Simple Extrapolation

Budgeting and forecasting represent another nuanced challenge in FinOps. Most tools simply extrapolate from historical data, assuming the future will resemble the past but “more so”.

“The more difficult part is figuring out which assumptions are going to be valid,” Wood explains. “You’re assuming that the future is going to be like the present, just more so. But if you’ve got things planned for the coming year and you say we are going to build this new system, and this new system is going to have costs associated with it, but it’s going to replace the current system that also has costs—how do I choose what I'm going to forecast?”

This becomes particularly problematic when you don’t know how much your current system costs. “If you don’t know how much the current thing costs, you don’t know what the forecast is going to be like. Right. So at the end of the day, most people just kind of revert to using whatever AWS or Datadog or whoever says your costs are going to be like this next year. Well, okay. I guess they are.”

The solution requires disaggregating costs to the system level. Once you understand that System A costs $X per month and processes Y transactions, you can forecast the costs of replacing it with System B by estimating its usage based on System A’s patterns.

This is why ERJ prioritized cost visibility and unit metrics. “Having knobs that you can turn that tell you what your costs are hugely important because you know what the business is going to do next year and then you have suspicions on what the business is going to do next year. So you have to build all that into your budget.”

Build Lean: The Five-Engineer Enterprise Platform

Perhaps the most remarkable aspect of ERJ’s story is what they’ve accomplished with resource constraints: a team of just five engineers managing an enterprise trading platform processing nearly a petabyte of data.

Their strategy? “You’re not constrained on budget, but you can only hire one person. What do you do in that situation? You say, well, I’m just going to find the most expensive senior guy I can get and we’ll hire him. So we’ve just got a bunch of heroes slinging code all day.”

But hiring senior talent is only part of the equation. ERJ’s success stems from several complementary strategies.

Heavy automation through Infrastructure as Code: Everything built with Terraform enables one engineer to manage complex multi-account AWS environments efficiently. “I could just go and press a button and all of a sudden we have a new account.”

Standardized technology stack: Instead of letting engineers choose optimal tools for each problem, ERJ maintains a narrow focus. “You’re deploying an API, you use ECS. You’re deploying ETL, you use DAGster. You’re building a data warehouse, Redshift.” This creates economies of scale and reduces operational complexity.

Serverless-first architecture: ECS Fargate, serverless RDS, and serverless Redshift eliminate OS management and enable automatic scaling. “We don’t have to worry about implementing new ECS instances or OS migration or anything like that.”

Strategic AI leverage: “We leverage AI pretty heavily. We have discussions on a semi-regular basis about which models we should use.” AI multiplies output without increasing headcount.

The result? A small team that moves just like many larger teams while maintaining high quality cloud cost management practices.

The First Step: Permission to be Imperfect

If there’s one message Wood wants to convey to companies still at the crawl stage of FinOps, it’s this: just start.

A lot of people, especially in Japan, have this idea that they don’t really want to take the first step because they’re not going to do a good job of it. But you kind of have to start somewhere, right? And even if you’re not perfect at it, as long as you just keep putting some effort into it, then you’ll keep having good results.”

The path forward is clearer than many organizations realize:

Week one: Set up a cloud cost management tool. Start collecting data. You don’t need Infrastructure as Code or perfect processes yet.

Month one: Implement basic tagging on key resources. Even manual tagging provides immediate value.

Quarter one: Create cost groups and start allocating shared resources, even if you use simple proportional division initially.

“You don’t have to do everything,” Wood explains. “Just start by setting up Octo. Look at your tagging and see what you could structure your cost groups around. Once you do that, you could start playing with it. Even if you've got a huge amount of stuff that’s shared and it goes into one big bucket, you don’t start with everything being perfect. You just keep whittling it down.”

The Business Value of FinOps: Beyond Cost Savings

While ERJ saved approximately 4 million yen through Reserved Instance purchases recommended by Octo, the true value of FinOps extends far beyond cost reduction.

FinOps enables:

Informed business decisions about which opportunities to pursue on true cost implications.

Operational insights that improve performance while reducing costs (like the 45% reduction in Redshift resource consumption).

Accurate forecasting and budgeting that prevents the frustrating cycle of unexpected overruns.

Accountability and transparency that transforms IT from a mysterious cost center into a valued business partner.

Faster innovation by clarifying which projects deliver ROI and which don’t.

This is what modern FinOps offers: not just cheaper cloud bills, but smarter business outcomes. And contrary to the fear that FinOps will slow innovation, the opposite proves true. When engineers and business stakeholders understand costs and can make informed tradeoffs, they move faster and more confidently.

Progress Over Perfection

The FinOps journey isn’t about achieving perfect cost allocation or implementing every best practice simultaneously. It’s about continuous improvement: starting with basic visibility, iterating based on what you learn, and gradually building sophistication that serves your business needs.

ElectroRoute Japan’s experience demonstrates that even small teams can implement effective FinOps practices. The key is prioritizing the right capabilities in the right sequence and refusing to let perfect be the enemy of good.

Whether you’re at the crawl stage struggling with surprise bills, the walk stage implementing tagging and cost groups, or the rum stage building unit economics, remember Wood’s advice: “You kind of have to start somewhere. Even if you’re not perfect at it, you’ll keep having good results as long as you keep putting effort into it.”

The cloud bill will arrive next month regardless. The question is: will you understand it any better than you do today?