June 17, 2026
Relying entirely on commodity cloud hyper-scalers caps profit margins and product potential. Shifting mature workloads to open, bare-metal platforms breaks software lock-in and turns infrastructure into a defensible asset.
For decades, the playbook of every startup has been the same: start on a hyperscaler, launch quickly, and think about infrastructure later. It’s sensible advice early on, when you have unpredictable demand and a small team. You only pay for what you use, scale on demand, and abstract maintenance away to someone else.
It’s a trap. As the business matures and the workload becomes predictable, the bill keeps climbing, but the same limitations remain. The hyperscaler slowly becomes the decision that caps both your margins and your product’s potential.
At scale, cloud can double your infrastructure bill, more if you’re running GPUs. You’re paying for elasticity, global reach, managed services, and compliance certifications, many of which you may not need once your workload matures. Of course, the hyperscaler is also making a tidy sum. AWS, for example, runs at an estimated 30-40% operating margin, generating over half of Amazon’s profits despite making up 20% of Amazon’s sales.
But while compute is the number everyone looks at, costs pile up in metered extras, too. Egress at $0.08-0.12/GB. An additional 10-15% to receive meaningful support. Network-attached storage that’s slower and more expensive than NVMe.
On an industry level, the lost revenue is staggering. Estimates from a16z suggest that across the top 50 public software companies using hyperscalers, at least $100 billion in market value is lost to cloud margins.
Elasticity is worth paying for when demand is unpredictable; during launch, when traffic is spiking, or when workloads might scale suddenly without warning. Once your product matures and you’re able to effectively estimate demand, it becomes much less useful. You end up paying a premium for the hyperscaler to hold capacity that you don’t actually need on standby.
Unfortunately, it’s not quite as simple as opting out of elasticity. You can commit to a reserved usage contract for 1-3 years, but that’s essentially just committing to a minimum upfront spend for a bulk discount. And you’re still paying for all the extras such as egress, network-attached storage, and support. A dedicated instance is also an option, but while that will remove noisy neighbour and multi-tenancy concerns, it’s more expensive, not less, with the same add-on costs.
On a hyperscaler, you never truly control the machine. You interact with an abstraction layer on top of it: an API representing compute, storage, networking, and so on, with the provider making the key decisions underneath.
Reclaiming control means moving the infrastructure decisions closer to the people who work on the product. It doesn’t have to mean a data center of your own; it can be working with a true full-stack provider, dedicated servers, colocation, etc. What matters is that you can choose the hardware to match the workload, with full control over the cost, services, networking, and software stack. This allows businesses to eliminate bloat, break commercial software lock-in, and tap into the freedom that comes with open source.
Multi-tenancy only benefits the provider. Shared infrastructure is slower, more complicated, worse value, and less customizable. No customer wants their product to be reliant on dozens of backend services that exist only because the provider needs to serve millions of customers and could fail at any point.
Taking ownership of your infrastructure means no worrying about noisy neighbours and no abstraction from your product and the layers it sits on. You can strip out hyperscaler IAMs, the metering and billing plane, network virtualization overlays, storage disaggregation, and even the hypervisor entirely.
Owning the hardware doesn’t end the dependency if you’re still beholden to the hyperscaler’s proprietary software. Managed databases like Aurora and DynamoDB, serverless like Lambda, queues, event buses, and identity services with no off-platform equivalent. Each of these adoptions is convenient and cost-effective when you’re using the hyperscaler, but they become a trap when you want to leave. Egress is often a small cost compared to re-architecting everything that only runs on the hyperscaler.
The provider is counting on that friction to hold you back. But leaving is a one-time cost, while the tax is permanent and grows with your workload. The math will be different for every organization, but for many, leaving will be the cheaper decision in the long-term. Particularly when you factor in the benefits to your products and organizational expertise.
At Liber, we strongly believe that building on open foundations is the way forward from a strategic perspective. It allows you to build portably and maintain freedom and control over your stack.
Hypervisors are a key part of this. Look at what Broadcom is going with VMWare: per-core subscriptions at roughly $350 per core/year with a 16-core minimum. You’re locked into paying for cores you might not even use and are then met with reported 2x-12x increases on renewal, with a 20% surcharge if you’re late to renew. When you try to move, you run into that software lock-in we mentioned earlier. VMDK disk files, vSphere, vSAN, and so on.
VMWare is an extreme example, but others have similar traps. Nutanix, for example, bundles its hypervisor at no separate charge, but you have to pay a per-node platform subscription, which lands you data in its storage fabric.
KVM removes the vendor from the discussion entirely. Since it’s built into the Linux kernel, there’s no license, per-core minimum, or renewal cycle. You can use any management tool (Proxmox, oVirt) without worrying about compatibility down the line. Workloads are also in open formats so that you can move the whole stack elsewhere without a rebuild: a new server, a colo cage, or another provider. That portability is what enables true ownership and allows you to make strategic changes to your infrastructure to best suit market conditions and your product.
A company running on commodity cloud has very little room for infrastructure advantage. It’s running on the same platforms, at the same rates, as its competitors. It can pay for additional scale or performance, but the ceiling is the same. Infrastructure that’s designed to be “good enough” for as many products as possible, rather than tuned to their specific offering.
Owning the stack allows you to change your infrastructure to a defensible corporate asset. One that’s tuned to your exact workload, optimized down to the kernel layers, even with custom tooling built around it if you wish. All of these compound into a cost-per-unit and performance profile that competitors on hyperscalers usually can’t reach.
Ahrefs is a clear example of a product that would not have been viable had it not eschewed commodity cloud from the beginning. For its use case, it estimates a monthly cost of $1550 per server/month compared to a staggering $17,557 on AWS. Over three years and 850 servers, that’s $39.5 million versus $408 million. For context, Ahrefs had revenue of $257 million in the same period, meaning it would have been $151 million in the red just from AWS expenses.
Instead, it invested some of the money saved into product improvements, enabling it to deliver more comprehensive SEO reports faster than competitors on an inherently limited cloud.
The financial nature of the spend changes, too. A cloud bill is pure operating expense. The money leaves the account every month and builds you nothing you own from an infrastructure perspective. The bill keeps increasing, and you keep building equity for the platform instead of you.
Owned infrastructure is capital expenditure. With the same money, you invest in hardware that sits on the balance sheet, and yes, depreciates at a set rate, but belongs to the company throughout. It’s actively adding value to the enterprise rather than solely subtracting cash. Of course, there’s still operational overhead to think about, but the spend produces something that the business holds rather than consumes.
The hyperscaler is often the right call for early, uncertain workloads, which is exactly why the trap works. The decision you made at launch is rarely the obvious one to revisit. The bill and dependencies grow, and the ceiling on what you build quietly becomes permanent.
The way out is to treat infrastructure as a decision with an expiry date. This won’t just inform what you do in the future — it’ll affect how you build now. Once you view infrastructure as non-permanent, building on proprietary systems suddenly makes a lot less sense. Tying yourself into a long cloud contract no longer makes sense. The right decision becomes to build the product on open, portable software so that you can choose to step out of the trap before it closes.