The European Commission is expected to drop one of the most significant regulatory findings in enterprise technology this week, with preliminary results from a long-running investigation set to classify Amazon Web Services and Microsoft Azure as "gatekeepers" under the Digital Markets Act. If confirmed, both companies would be compelled to open their ecosystems, guarantee data portability, and abandon the pricing practices that make leaving prohibitively expensive for most enterprises.
Regulators took this long to get here because the problem is genuinely complex. We have been thinking about it differently at Obmondo. The cloud industry's biggest dirty secret is not that these platforms are bad. It is that the same services that make IT easy to start are engineered to make it expensive to leave. The lock-in is not accidental. It is a product decision, baked into pricing models, architectural choices, and contract structures from day one.
Most enterprises do not realise they are trapped until the bill arrives for trying to escape.
The EU's market investigation into cloud computing was formally opened in November 2025, triggered in part by two major infrastructure failures in October that year. A 15-hour AWS outage, caused by a DNS race condition in its DynamoDB service, took down not just Amazon's own streaming services but also Atlassian, Docker, Epic Games, and the Signal messenger. A separate Azure Front Door configuration failure disrupted airline check-in systems, Heathrow Airport, and the Scottish Parliament.
Those events gave regulators concrete evidence of something the industry had long resisted acknowledging: concentrating critical infrastructure inside two or three hyperscalers is not just a commercial risk. It is a systemic one.
The Commission's April 2026 DMA progress report had already signaled that cloud and AI services would be the next major enforcement focus. AWS and Azure together account for more than 65 percent of EU cloud infrastructure revenue, a combined market share larger than the positions that triggered gatekeeper designation for any consumer-platform service to date. A formal designation is expected before the end of 2026, though both companies are anticipated to mount legal challenges that could extend implementation timelines by years.
But here is the thing: enterprises cannot wait for policy to solve an architecture problem.
Vendor lock-in is not the result of a single bad decision. It is the outcome of accumulated choices over time, each one reasonable in isolation, collectively catastrophic when you need to leave. There are four distinct layers, and they reinforce each other.
The outermost layer is also the most visible. Multi-year commitment contracts, reserved instance pricing, enterprise discount agreements, and volume incentives all share a common structure: the pricing gets attractive precisely when you commit to staying.
A three-year reserved instance on AWS can reduce compute costs by up to 60% compared to on-demand pricing. That sounds like a sensible financial decision until you realise that you have just signed a document that makes leaving more expensive than staying, regardless of what the vendor does to you in year two. Auto-renewals, penalty clauses for early exit, and ambiguous product usage rights are standard features of enterprise cloud contracts. The organisations that discover this late are the ones that show up to renewal negotiations with no leverage and no credible alternative.
Ingress is free. Egress is not. This asymmetry is not an oversight.
AWS charges approximately $0.09 per GB to transfer data out to the internet. Azure charges between €0.05 and €0.087 per GB. GCP charges $0.085 per GB. These numbers sound harmless until you do the maths at enterprise scale.
Moving one petabyte of data out of AWS S3 costs somewhere between $90,000 and $120,000 in egress fees alone, before any engineering work, migration tooling, replatforming, or service disruption is factored in. For organisations with multi-petabyte data lakes, that number becomes a board-level conversation, not an engineering one.
When 37signals decided to leave the cloud, AWS reportedly waived $250,000 in egress fees, which itself tells you something important. The waiver was a business decision to retain goodwill, not a technical necessity. The fees were real, the leverage was real, and most companies negotiating alone do not get the waiver.
Consider a typical modernisation path on AWS. You start with EC2 instances. Then you adopt RDS for managed databases. Some workloads move to Lambda for serverless execution. You add DynamoDB for session storage, SQS for message queuing, CloudFront for CDN, and Cognito for authentication. Each service works beautifully within the AWS ecosystem.
None of them have a direct, cloud-portable equivalent elsewhere.
Your application is now coupled to a single vendor's proprietary APIs at every layer of the stack. When renewal time comes, the hyperscaler knows exactly how entangled you are. Your ability to negotiate pricing is directly proportional to your ability to credibly threaten to leave, and they know you cannot.
This is not unique to AWS. Azure Cosmos DB, Azure Service Bus, and Azure Active Directory create identical lock-in patterns on Microsoft's side. Google's BigQuery and Spanner do the same on GCP. The proprietary services are excellent. That is precisely the point.
The deepest layer is the hardest to see on a spreadsheet. Organisations hire staff with vendor-specific certifications. AWS architects, Azure administrators, and GCP specialists build institutional knowledge around particular toolsets. Internal runbooks, deployment pipelines, and incident response procedures are all written for a specific cloud's APIs and console.
Swapping platforms does not just require rewriting infrastructure code. It requires rebuilding operational models, retraining teams, and accepting a period of reduced operational confidence while the new environment is learned. Managed service providers make this worse. Some MSP contracts include clauses that increase fees as the number of users, devices, or data consumption grows. Some MSPs withhold admin credentials during offboarding disputes. The operational lock-in layer means that even organisations with the budget and the will to migrate face a human cost that rarely appears in migration cost estimates.
The financial case against lock-in is not theoretical.
Basecamp, which runs the project management tool of the same name and the email client Hey, published a detailed breakdown of its decision to leave AWS. The company was spending approximately $3.2 million per year on cloud infrastructure. After migrating to owned and leased hardware, it projected savings of $7 million over five years, and confirmed after the migration completed in 2023 that the numbers were real.
Dropbox completed a larger repatriation years earlier, moving the majority of its storage workloads off AWS. The company reported $75 million in cumulative savings over two years.
These are not small startups finding clever workarounds. These are mature technology companies with complex infrastructure requirements, making a deliberate architectural choice to own their exit.
The UK Cabinet Office, in a separate analysis of public sector cloud dependency, estimated that overreliance on a single provider could cost public bodies £894 million. The figure reflects not just egress and migration costs but the compounding effect of reduced negotiating leverage on every subsequent renewal cycle.
Across the industry, IT project costs run an average of 14% over budget. Cloud migration projects, where proprietary coupling adds layers of complexity that are difficult to estimate in advance, tend to overshoot even that benchmark.
Cloud hyperscalers are not the only IT vendors that engineer lock-in. Managed service providers operate the same playbook at a different layer.
MSPs often segment their service tiers so that higher service levels come at disproportionately higher costs. Contracts that look fixed frequently include clauses that escalate fees as device counts, user numbers, or data volumes grow. Overbilling, lack of transparency in monthly reports, and withheld credentials during contract disputes are documented patterns across the MSP industry.
The most insidious version: a managed services provider who holds your admin keys has all the leverage of a cloud provider, but with none of the regulatory scrutiny that the DMA and equivalent frameworks are beginning to apply to hyperscalers.
When your IT operations vendor knows you cannot easily leave because the knowledge, the credentials, and the runbooks are inside their organisation, the power dynamic inverts completely. The vendor stops optimising for your outcomes and starts optimising for their retention.
The EU's anticipated gatekeeper designation for AWS and Azure is genuinely significant. If designated, both companies would face obligations including interoperability requirements, data portability guarantees, restrictions on self-preferencing, and potentially the elimination of egress fees for switching, expected to take effect in January 2027 under the EU Data Act. Non-compliance can trigger fines of up to 10% of global annual turnover, rising to 20% for repeated breaches.
European cloud alternatives, including OVHcloud, Hetzner, and Scaleway, stand to benefit most directly from any mandated changes. Those providers currently hold an estimated 15% of EU cloud market revenue combined, competing against two vendors who maintain structural pricing advantages through the very practices under investigation.
But regulatory protection is jurisdiction-specific, incomplete, and slow. Implementation timelines for DMA obligations typically run six months from formal designation, and legal challenges from AWS and Microsoft could extend that by years. The Data Act's egress fee prohibitions do not apply globally. And no regulation addresses the technical and operational lock-in layers, which exist entirely within the architecture choices organisations have already made.
The regulation validates the problem. It does not solve it for the infrastructure you are already running.
At Obmondo, we built KubeAid and LinuxAid around a single constraint: the exit door should always be open, and leaving should be as close to zero cost as possible.
After all, the exit door from the public cloud is technically "always open"—but as we've highlighted, walking through it is incredibly expensive due to egress fees, proprietary API rewrites, and operational retraining. An exit door that costs hundreds of thousands of dollars to pass through is not an exit; it is a toll booth.
That is why our constraint is not just about the technical possibility of leaving, but the economic reality of doing so. Every decision in how we run infrastructure for our customers is made with the question: if you wanted to leave tomorrow, what would it cost you?
The answer, by design, is as close to zero as possible.
Cloud portability by default. KubeAid runs on AWS, Azure, GCP, Hetzner, bare metal, or any combination. The Kubernetes layer is the abstraction that makes this real. Because application workloads target Kubernetes APIs rather than cloud-provider APIs, moving between providers is an infrastructure operation, not an application rewrite. We run customers on Hetzner alongside customers on AWS, with the same operational model, the same tooling, and the same support.
Open source, all the way down. KubeAid is licensed under AGPL-3. LinuxAid is open source. The entire stack we use to manage customer infrastructure is publicly available on GitHub. If you stop working with us, you take the stack with you. There is no proprietary agent, no vendor-locked monitoring system, no secret sauce that lives only inside Obmondo's systems.
You own the config, always. The KubeAid configuration repository lives in your version control system. ArgoCD pipelines run from your repo. Secrets are managed with sealed-secrets, encrypted locally and committed to your repository, not ours. A git pull keeps your infrastructure current. If Obmondo ceased to exist tomorrow, your infrastructure would keep running and you would know exactly how to operate it.
Month-to-month contracts, full stop. We do not offer multi-year lock-in packages with exit penalties. If we are not delivering value, you should be able to leave. That constraint forces us to keep delivering value. It is a better incentive structure than a three-year contract that benefits the vendor regardless of outcomes.
Honest cost comparisons. Running on Hetzner with KubeAid typically costs 60 to 80 percent less than equivalent workloads on AWS or Azure, before egress fees are considered. We will tell you that clearly at the start of the engagement, including the cases where a hyperscaler genuinely is the right answer for your workload.
The EU's anticipated findings are important because they confirm something that a growing number of engineering leaders already know: the cloud hyperscalers built systems that are excellent at creating dependency and structurally resistant to competition. That is not a bug in the business model. It is the business model.
The question for every CTO and infrastructure lead is not whether vendor lock-in is bad. Everyone agrees it is. The question is whether you have actually built an architecture that reflects that belief, or whether you have accumulated proprietary integrations over years of pragmatic decisions that have quietly made leaving impossible.
SaaS vendors increased prices by 8.8% in 2023, more than double the prevailing inflation rate. Software prices have climbed 62% over the past decade, more than three times the average consumer price index over that period. The organisations that have zero viable alternative when their renewal comes are the ones paying those increases without negotiation.
The ones with a credible exit option are the ones with leverage.
If you want to understand what your current lock-in exposure actually looks like, the first step is an honest audit of how many of your production workloads depend on proprietary cloud services with no portable equivalent.
Not all lock-in is avoidable, and not all of it is bad. A vendor-specific service that saves significant engineering time may be worth the dependency. The problem is when the dependency accumulates invisibly, across every layer of the stack, without anyone having made a deliberate decision that the trade-off was worth it.
We are happy to work through that audit with you.