Andy: [00:10] Good morning, everybody, and good afternoon over there in Europe. Welcome to another Nacho Tuesday. Today I have Alex here with ElasticScale. Without further ado, we would love if you could introduce yourself and your company.

Alex: [00:21] Yeah, so I'm Alex. I'm the founder of ElasticScale. We're an AWS Partner, and we help companies reduce their AWS bills. That's why we partnered with NachoNacho. We see a lot of people spending too much money on AWS. I see it on a daily basis, and it makes me kind of sad. I have a personal mission to actually reduce those costs, so that's why I'm here.

Andy: [00:45] That's great. We're all about saving people money here. What are some of the most common AWS cost traps that companies overlook?

Alex: [00:50] You have to be aware that in AWS, it's often a "death by a thousand cuts." You have a $10 cost here, maybe a $100 cost there, and all of it tends to add up to a massive amount in the end.

The most common costs we see are actually related to storage—database storage—and compute. There's also a component of not knowing how to optimize it, which often leads to people not wanting to touch it because they are afraid they might break something.

Andy: [01:31] At what point should companies actively start managing their cloud costs? At what point in a company's growth do you really see things start to get out of control?

Alex: [01:41] The ideal answer would be "from the start." But we also know that managing costs ties directly into how much time you actually have. More importantly, it should be tied to your unit economics.

For example, if you're building a $10 million-a-year company and making a healthy profit, it's not a problem if your AWS costs are $10,000 a month. But if you're building a $20,000-a-year company and your AWS costs are $10,000 a year, then that is completely out of perspective. You should definitely make changes at that point. There are benchmarks floating around regarding what percentage of your revenue your AWS spend should be.

Andy: [02:36] Where do you typically see companies when they come to you with this problem? It seems like a lot of people "kick the can down the road" and then realize there is a massive cost center they should be saving money on. When do they typically reach out to you?

Alex: [02:50] Once you are spending around $1,000 a month, you can almost always save money on AWS by providing commitments or right-sizing your compute. If you are under that threshold, it can be very hard to find significant savings—maybe you can bring it down to $600 or $700 a month. But above $1,000 a month, you can actually see a real ROI.

You have to factor in the opportunity cost: if you have a developer who spends three or four days working on infrastructure costs just to bring the bill down by $200 a month, you're not going to earn that developer's time back. There has to be a pragmatic way of looking at cost reduction.

Andy: [03:40] Which AWS services tend to be the biggest cost centers that create those surprise bills when you least expect them?

Alex: [03:47] We see this happen heavily with data transfer. This is anything that scales directly with your traffic. If your traffic is unpredictable, or if you get hit by a lot of bots, you will suddenly see high CloudFront costs. You haven't served any more real, paying customers, but since AWS is purely usage-based, these things can spiral out of control if you don't keep them in check.

Surprise costs can also stem from misconfigurations in your accounts. For instance, if you have a series of Lambda functions that recursively call each other, they will happily execute indefinitely, and you will have to pay for all that compute. Most surprises come from things that explode alongside traffic when no limits or alerts are put in place.

Andy: [04:49] What are some of the warning signs that your cloud costs are getting out of control? Are there any immediate red flags?

Alex: [04:53] A good benchmark we use is that your cloud spend should be around 8% to 10% of your revenue. It depends on your business model; if you run an AI business, it might be a bit higher. But treating it as a flat percentage is a good way to assess if it still makes sense for your business.

Another warning sign is simply being surprised by the bill. If you find yourself saying, "I remember it being lower," or if it was $6,000 three months ago and now it's $12,000, that is a red flag. This comes down to establishing clear responsibility and having a process in place to eliminate surprises.

Andy: [05:51] How does AI play into all of this? Obviously, token usage is becoming a massive cost center. Are you seeing AI lead to a big increase in these cloud costs?

Alex: [06:02] Definitely. We specialize in SaaS companies, and SaaS companies have historically been very comfortable with 80% margins on their compute. In traditional SaaS, you just add a few more servers and databases, scale them down when they aren't in use, and it works.

But AI is heavily reliant on GPUs. You have to keep them on standby all the time, they are expensive to rent, and market demand is driving those prices up. This makes AI infrastructure much less predictable. There is also a massive amount of data involved, which makes everything more expensive. The core principles underlying the AI wave are different, and as an industry, we are still getting used to how we need to price this to our customers. It is vital that you budget for it and tag resources so you can see exactly what is driving your spend.

Andy: [07:02] What are the biggest mistakes teams make when deploying AI infrastructure?

Alex: [07:07] A lot of people use the most expensive model for everything. They assume that because a model is the smartest, they must use it, even when they are just doing a simple task like summarizing text. That means they are paying a premium for input and output tokens.

Teams should move away from using a single model for everything and build in the ability to switch models dynamically. Tools like OpenRouter allow you to route prompts to different models under the hood. For example, I might use the newest Claude model on Thursday, but if it is unavailable or cost-prohibitive on Friday, I can switch. You really need to think about your specific use cases, test properly, and choose the most cost-effective model for each task rather than defaulting to the latest and greatest.

Andy: [08:23] Right, you don't need a Ferrari to go pick up groceries.

Alex: [08:28] Exactly, that’s a perfect analogy.

Andy: [08:34] How else can companies scale AI initiatives without seeing their cloud costs spiral? Do you have any other tips?

Alex: [08:40] It helps immensely to gain visibility into your costs before code goes to production. If you have a small development team with no dedicated DevOps, developers are often not worried about the cloud bill; it isn’t being taken out of their salaries. If you tried to do that, all your developers would probably leave! So don't take that route.

But you should ask critical questions: Is this the right model? What will this cost? Can we estimate how many tokens we are inputting and how much traffic we expect? Doing this might lead you to choose a different pricing model for your product.

Right now, token usage is heavily subsidized, so you need to think ahead: Will this business model be sustainable if token prices go up tenfold? Often, once things are already in production or staging and customers are using them, it is too late to plan. These discussions should happen before deployment. In traditional SaaS, the marginal cost of adding a feature was near zero. With AI, that playing field has changed, so how we design and build software must change too.

Andy: [10:36] I think we see a lot of costs rising. The go-to-market strategy for these AI models is to get you hooked, and many builders aren't thinking forward. They build their entire infrastructure around a model they like today, but if those prices go up, it's very difficult to decouple from it. You get hit with that sunk cost.

Alex: [11:07] Exactly. The model you use today might not be the model you use in six or eight weeks. You need to ask: Will this model serve us long-term, and how easily can we switch away from it if jurisdictional rules or cost-prohibitive measures arise? As long as there is a "free lunch," everyone is happy, but it still needs to hold up as a viable business case.

Andy: [11:37] As they say, the free lunch is never free, so you have to be careful. If you inherited an AWS environment tomorrow, where would you look first for savings?

Alex: [11:48] There are a couple of simple, pragmatic things you can do immediately. For example, shutting down your staging and development environments outside of office hours can save around 80% on those monthly costs. You can easily enable them again with a simple link. In the middle of the night, nobody is using those environments, and AWS lets you pay only for what you use.

I would also look at database storage. Customers often run massive databases where they could easily optimize their queries or reduce database sizes.

The same goes for S3 storage. A lot of people are storing data in S3 that they will never need again, or they are storing it in tiers that are too expensive.

Most importantly, we frequently see companies spending 30% of their bill on cloud resources they aren't even using. When we ask, "Who spun this up and who is responsible for it?" the response is often, "Oh, that was a guy who worked here five years ago. We don't know where he is now, but it's costing us $400 a month." In those cases, you should absolutely delete it. The first step should always be an analysis of what is actually in use, and you can get great results by using AI tools to perform that audit.

Andy: [13:39] It sounds like these costs can easily get out of control as you grow, add team members, and have people coming and going who forget which environments they opened.

Alex: [13:48] Absolutely. When I was a CTO, we never measured a developer's productivity based on how much infrastructure cost they saved. We only looked at whether they delivered the features on the Jira board. That is what keeps customers happy.

Infrastructure management is unsexy. It is the engine of the company, and if it fails, you have a massive problem, but no developer wants to work on it unless they are forced to. That is a major part of the issue.

Andy: [14:27] They like to build. They don't necessarily care about the costs; they are focused on shipping the feature and dealing with everything else later.

Alex: [14:43] Yes, and "later" always comes. But that's good for us because it keeps us in business!

Andy: [14:55] What percentage of savings can companies typically expect from an AWS optimization effort? If they were to call you today, what are you seeing across the board with your clients?

Alex: [15:01] On average, we save companies around 30%, but it can go up to 50% for unoptimized environments that have been running for three years without any changes. We've been around for 18 months, we just hit the AWS Advanced Tier Partnership, and we have saved around a million dollars in AWS spend for our customers.

The savings depend heavily on the type of workload. For example, we cannot easily optimize or get extra discounts on data transfer out. If a customer does a lot of video streaming as a core part of their business model, we are stuck with those data transfer costs. But in most cases, significant savings are possible if you are willing to put in the time and effort, which can sometimes be the scary part for teams.

Andy: [16:21] Which initiative produces the most immediate results? What delivers the fastest ROI—is it shutting down non-production environments or deleting unused resources?

Alex: [16:43] If you can only pick one thing for the fastest ROI, it is gaining a clear understanding of exactly what is running in your cloud and whether it is being utilized efficiently.

We often see that resources are heavily overprovisioned. If you tell a developer to spin up a server for a new feature, they are naturally going to choose a massive server because they don't want to get called in the middle of the night because the server ran out of memory. They don't care if it's overprovisioned; they just want peace of mind. Simply identifying what you are using and deleting what you don't need can easily save you 10% without any operational risk.

Andy: [17:51] Who really owns cloud cost management? It sounds like everyone tries to pass the buck. Is it the CEO, the CFO, or the DevOps team?

Alex: [18:22] If you have a dedicated DevOps team, they need to own it. They have the tools and expertise. Typically, once you have 10 to 15 full-time developers, you need a DevOps engineer. Before that stage, it often falls on engineering, but the incentives are misaligned. Developers care about shipping features, and the CFO just pays the bill because they have to, even if they don't understand the technical breakdown of AWS costs.

To solve this, you need to make infrastructure costs part of the engineering process. Just like you have acceptance criteria in Jira for features, you should include a criterion asking, "What will this feature cost us to run, and why?"

You should also establish a monthly cadence to discuss AWS costs with the development team. To make it work, avoid shared responsibility because shared responsibility means nobody is responsible. Assign one developer who is comfortable with AWS—or wants to learn—and make them explicitly responsible for cloud costs. You can incentivize them by paying for their AWS certifications. Putting it in engineering works best, provided you give them the tooling and the dedicated time to do it.

Andy: [21:10] It’s up to the CEO to push that ownership onto the team, so developers are incentivized to manage costs rather than just running off to build features.

Alex: [21:25] Yes. If you make it a general engineering team responsibility, it becomes a shared responsibility, which means zero responsibility. But if you assign it to one specific developer, they will step up. They feel the responsibility, they do the research, and they will find great savings they can implement themselves.

Andy: [22:01] Make it part of their monthly deliverables so they can report on the cost savings they've produced. Eventually, as you grow, you can hire a dedicated DevOps team built specifically for this task.

Alex: [22:23] Exactly. But you also have to factor in opportunity cost. Developers are highly productive when building features, but their productivity drops when they have to work on complex cloud infrastructure they are uncomfortable with. If they spend a day building a feature, that drives revenue. If they spend a day on DevOps, it lowers the bill but doesn't add new revenue. You have to balance those two. Plus, full-time DevOps people can be quite unhappy—I can tell you that from experience!

Andy: [23:17] But it’s good if they are thinking about costs as part of their DNA while building features, rather than ignoring it until it becomes a massive problem. How often should organizations review their AWS spend and architecture?

Alex: [23:31] First, you must have budgets in place. Around 60% to 70% of our customers have no budgets set up at all; their only budget is their credit card limit, which is a terrible limit to have! Setting a budget forces you to think about what you are willing to spend and how you can drive it down.

You should review your spend monthly, but you also need to build deep visibility. AWS Cost Explorer will aggregate virtual machine costs—like telling you that you have 63 T3 Large instances—but it won't tell you which business unit is driving that cost. You need a tagging strategy. Tag resources by business unit, feature, or customer tenant. That way, you can see if a tenant you are charging $100 a month is actually costing you $600 a month in AWS spend. Doing a monthly review is great, but you have to know what is actually driving those costs.

Andy: [25:27] What is the first thing attendees of this webinar can do today or tomorrow to start optimizing their costs right away—aside from calling you guys, of course?

Alex: [25:50] Even if you don't call us, the single best thing you can do is assign one person in your team to be responsible for cloud costs. That alone makes a massive difference. It eliminates the feeling that nobody cares about the bill except the credit card company, and it empowers that person to take ownership. This is usually a people problem, not a technology problem. Set up a monthly sync with them to track if your spend is trending up or down, which will also help you price your product more accurately.

Andy: [26:48] What are the key services, benefits, or value offers that ElasticScale provides?

Alex: [27:02] For everyone attending this webinar, you can email me at alex@elasticscale.com, and we will provide a completely free, 50-point AWS cost audit. We will check your account for savings, and you can either implement them yourself or have us handle it if your team doesn't have the time. It’s a sensible offer for teams who are afraid they might break something.

They can learn more at elasticscale.com. We have a dedicated page for FinOps. We operate on a pure success-fee model: there is no upfront fee, we work together for 12 months, and we take 50% of the actual savings we realize. If we don’t save you money, you don't pay us anything.

Andy: [28:02] It's hard to say no to that! Thanks so much for coming on today, Alex. We really appreciate our partnership. This offer is available in the NachoNacho B2B SaaS and AI Marketplace, or you can go directly to elasticscale.com. Thanks again, and I look forward to growing our partnership together.

Alex: [28:21] Thank you, Andy. Talk to you soon.

Andy: [28:27] Bye-byes. Perfect. Great job.