Companies usually start thinking about moving away from AWS not because of one single reason, but because of a combination of three problems: hidden costs, growing platform dependency, and a budget that becomes less predictable as the system scales.
This is not just a feeling shared by a few dissatisfied teams, but a visible market signal. According to Flexera’s 2025 data, 84% of organizations name cloud cost management as their top challenge, while expected cloud spending growth over the next year is estimated at 28%.
Put simply, the picture usually looks like this:
- First, the business notices that the bill is growing not only because of virtual machines, but also because of network costs, storage, backups, NAT, supporting infrastructure, and other “small” items.
- Then it becomes clear that the project has grown too deeply into IAM, databases, queues, monitoring, and other platform services.
- And at the growth stage, the budget no longer scales linearly: workload grows by one percentage point, while costs and complexity grow much more sharply.
And this is not only theory or analyst reports. There are also public cases where companies directly linked leaving AWS with economics and cost control.
For example, 37signals has openly criticized AWS costs and in 2025 spoke about an additional $1.3 million per year in savings after continuing its cloud exit. Dropbox reported even earlier that it stores and serves more than 90% of user data on its own infrastructure. In other words, for large players, leaving AWS has not looked exotic for quite some time.
Below, we will look at what exactly pushes companies toward the thought “it is time to calculate an exit,” where AWS begins to become expensive in non-obvious ways, what vendor lock-in looks like in practice, and what cases, feedback, and market signals say about all of this.
What Usually Pushes Companies Toward the Thought “It’s Time to Calculate an Exit”
The conversation about leaving AWS rarely begins with a polished strategic session. Usually, it is much more practical: at some point, the platform stops feeling like a convenient foundation and starts being perceived as a source of extra limitations, costs, and dependency.
At first, this shows up as separate irritants. Somewhere, the bill becomes more painful. Somewhere else, a new feature suddenly requires another service, another setting, and another layer of approvals. And somewhere, the team already struggles to answer a simple question quickly: what exactly is the project paying for, and what happens if something needs to change sharply tomorrow?
Then these small irritants start turning into a more serious feeling. The business begins to sense that the cloud is no longer simply helping run the product, but is gradually dictating how the product should live, scale, and how much it will cost.
The usual push toward this thinking looks like this:
| What starts creating pressure | How it feels in practice |
| Costs grow faster than expected | The bill becomes less understandable and harder to explain to the business |
| The architecture accumulates cloud-specific “wrapping” | Even a simple change requires taking into account more and more service dependencies |
| The team loses the feeling of control | Any infrastructure change feels heavier and riskier than before |
| The platform holds the project too tightly | Leaving no longer looks like changing a platform, but like rebuilding part of the architecture and production environment |
| Product growth makes the budget nervous | New workload brings not only more resource consumption, but also a new layer of secondary costs |
But here it is important not to confuse platform fatigue with a real reason to leave.
Sometimes the company has genuinely grown to the point where the current model no longer matches its economics or control requirements. And sometimes the problem is not the platform itself, but that the project has grown for too long without proper cost control, without cleaning up unused resources, and without strict architectural discipline.
That is why the thought “it is time to calculate an exit” does not prove anything by itself. It only shows that the business no longer considers the current setup obviously convenient.
Hidden Costs: Where AWS Starts Becoming Expensive in Non-Obvious Ways
Frustration with AWS rarely begins with one large line item in the bill. More often, it builds up quietly: the business looks at compute costs, while the actual cost growth is not limited to the compute layer at all.
That is why hidden costs are so unpleasant. They do not always look like a “mistake” or an “unnecessary service.” On the contrary, each item may seem normal and even reasonable on its own. The problem is that, over time, these cost categories begin to live their own life and grow more noticeably than the project itself.
What Businesses Pay for Beyond the Core Resources
On paper, teams usually count virtual machines, databases, and storage. In practice, the bill quickly expands because of networking overhead, supporting services, and everything else required to keep the infrastructure running.
This is exactly where hidden costs appear. They rarely look like one big mistake. More often, they are a set of perfectly normal cost items that, taken individually, seem reasonable — but over time start growing faster than the project itself.
This becomes especially clear in a simple breakdown:
| What the team sees as the main cost | What later starts noticeably eating into the budget |
| Virtual machines and databases | NAT Gateway, data transfer, backups, logs, service traffic |
| Storage as a “clear” budget item | Requests, data movement, snapshots, and related operations |
| Basic platform support | Paid support plans, if the project already needs faster response times |
| One service as the unit of calculation | The entire cloud overhead built around it |
And that is exactly what makes it unpleasant. The business feels like it is paying for the “core,” while the budget starts getting pulled apart by things that for a long time are treated as mere background.
While the project is still small, this can go unnoticed. But as it grows, it turns out that money is not leaking through one large hole, but through a collection of small channels that, together, no longer look small at all.
Why Small Cost Items Later Turn Into a Big Problem
The problem with hidden costs is rarely that each individual line item is huge on its own. The real problem is that there are too many of them, and they become harder and harder to read.
At first, it looks harmless. Network traffic grows a little. Backup costs rise somewhere. Support or supporting infrastructure becomes more noticeable. Taken separately, each of these items can still be explained.
But then the business suddenly sees not one clear bill “for servers,” but a whole set of small, sticky expenses that together pull the budget upward much more than expected.
That is why hidden costs are so frustrating. They damage not only the economics, but also the sense of control. And when platform dependency starts growing alongside them, the question is no longer only about money, but also about room to maneuver.
From here, the next natural step is to look at what happens when the issue is not only cost, but also dependency on the platform itself.
Vendor Lock-In: When the Platform Holds the Project More Tightly Than You’d Like
With money, at least the problem is visible in the bill. With vendor lock-in, it is more complicated: for a long time, it does not look like a problem at all — it looks like convenience.
At the beginning, it may even feel like a clear advantage. The platform offers ready-made services, understandable roles, built-in access mechanisms, automation, monitoring, queues, databases, and storage. The team builds a working setup from all of this and feels that the product is moving faster.
The problem appears later. The longer the project lives inside this kind of model, the less it resembles “just a set of servers and data” that can be calmly moved somewhere else.
Where the Architecture Stops Being Portable
Lock-in usually does not appear in one large obvious place, but in dozens of small decisions that look reasonable on their own.
The service stores data in a specific model. Background processes depend on particular queues. Access rights are built around the current role logic. Monitoring and alerts are tied to familiar services. Release automation, backups, and network rules also follow the platform’s own logic.
Because of that, the architecture gradually stops being portable by default. It becomes portable only after rework.
For clarity, here is a simple table:
| What first looks like convenience | What it turns into when leaving |
| Ready-made services around the application | They have to be replaced or rebuilt on the new platform |
| Familiar roles and access model | Permissions have to be reconstructed under a different logic |
| Built-in observability and alerts | Monitoring and operational workflows need to be rebuilt almost from scratch |
| Platform-side automation | Scripts, pipelines, and runbooks begin depending on the old environment |
| Platform networking and routes | The new design often no longer matches how the project used to live |
That is why vendor lock-in rarely feels like “someone is holding us by contract.” More often, it looks like this: the team has built a convenient but highly platform-dependent way of working, and now has to pay for that convenience with a difficult exit.
Why Even Free Data Transfer Does Not Make Leaving Simple
Against this background, it is easy to overestimate news about lower exit barriers. For example, if a provider makes data transfer out easier, that is genuinely useful. But it removes only one problem — and not necessarily the hardest one.
Moving the data out does not mean moving the project out.
Even if the data transfer itself becomes cheaper or simpler, the business still has to:
- Reconnect services and dependencies
- Build a new access model
- Move or rebuild monitoring and operational workflows
- Recheck how everything behaves under real load
- Help the team adapt to the new setup without its old familiar supports
That is why lock-in affects not only technology, but also momentum. The deeper a project has grown into the current platform, the more migration looks not like changing a supplier, but like partially rebuilding the company’s own way of working.
And this is where it becomes clear why companies so often look for confirmation of their doubts not only in documentation and invoices, but also in other people’s experience. From here, the natural next step is to look at what practitioners, public cases, and real market signals say about this.
What Practitioners Say About It: Cases, Feedback, and Signals From the Market
If you look not only at reports and documentation, the picture becomes more vivid. In practice, the conversation about leaving AWS usually revolves around three things: a bill that has started to produce unpleasant surprises, platform lock-in that is hard to unwind, and the feeling that as the company grows, the budget stops scaling in a predictable way.
Public cases show this well. 37signals, which we mentioned at the very beginning, linked its cloud exit directly to economics and in 2025 said it was seeing about $1.3 million in additional annual savings after continuing its cloud exit.
Dropbox said even earlier that it already stores and serves more than 90% of user data on its own infrastructure. That does not mean every company should repeat their path. But it is a good signal: for some businesses, the question “is it time to start calculating an exit?” has long since stopped being exotic.
At the level of bottom-up feedback, the picture is usually less formal but very recognizable. In discussions on Reddit and Hacker News, people most often complain not about one outrageously expensive service, but about a set of small, sticky costs that do not look dangerous for a long time. A public IP can add almost 50% on top of a small instance’s monthly cost. NAT and service traffic can suddenly turn into a large share of the bill for some teams. And in some discussions, people say outright that the most painful part is not the servers themselves, but the cloud overhead built around them.
If simplified, the market signals usually look like this:
| What practitioners say | What is useful to take away from it |
| “The bill became unpredictable” | The problem is often not one resource, but the combination of many small expenses |
| “We got too deeply tied to the platform” | Lock-in usually sits in architecture and processes, not in the contract |
| “As we grew, budgeting became really painful” | Scaling breaks not only price, but also the sense of control |
| “It became cheaper after we left” | That does happen, but usually at companies with a different scale and stronger engineering capacity |
| “The cloud is still convenient if you manage it properly” | Leaving is not always the best answer; sometimes it is cheaper to clean up the current setup |
But it is important not to overestimate reviews. Reddit and Hacker News are useful not as hard statistics, but as a layer of real pain points. They show well where exactly frustration tends to accumulate, but they do not prove that leaving is the right move for everyone.
Conclusion
If you look at leaving AWS without emotion, companies usually do not move away “from the brand.” They move away from a combination of three things: hard-to-read costs, platform dependency that has become too deep, and a budget that no longer grows predictably.
This is visible both in industry reports and in public cases. Cloud cost management remains the top pain point for most organizations, while stories like 37signals and Dropbox show that, for some companies, calculating an exit has already become a practical business question rather than an exotic idea.
But that does not mean everyone should leave by default. For some companies, AWS remains a convenient and justified platform — especially when the real problem is not the cloud model itself, but weak cost control and an inflated architecture. For others, however, the combination of hidden costs, lock-in, and an increasingly nervous budget can make leaving a reasonable option.
So the final question is better phrased not as “is AWS bad?” but as this: does your current setup still help the business grow — or has it already started pulling the business down through cost, complexity, and platform dependency?
FAQ
Do companies leave AWS mainly because of price?
Price is often the first trigger, but usually not the only one. Hidden costs, platform lock-in, and the feeling that budget scaling has become less predictable quickly get added to the discussion.
Are hidden costs a real problem or just fearmongering?
They are a real problem. AWS separately documents the cost of NAT Gateway, data transfer, and other networking components, and in user discussions these “small” cost items are often among the most frustrating parts of the bill.
Does free data transfer out solve the lock-in problem?
No. The free data transfer program removes one barrier — egress charges during migration — but it does not remove the cost of migration itself, dependency rework, or rebuilding the project’s processes. AWS also clarified the terms in 2025: after approval, customers have 90 days to complete the move.
Why shouldn’t Dropbox and 37signals be copied blindly?
Because these are stories at a different scale. Dropbox had data volumes and a workload profile where its own infrastructure created a serious effect. 37signals has also publicly discussed multimillion-dollar savings, but that does not mean the same math will work for an average business.
What usually breaks the budget the most?
Most often, not one large line item, but the combination of small and hard-to-read costs: network traffic, NAT, backups, supporting services, paid support, and the cloud overhead around the core resources.
When does leaving AWS look reasonable?
When an honest calculation shows that the new setup will provide not only a lower bill, but also clearer economics, less platform dependency, and a more suitable operating model. If not, a cloud exit can easily turn into an expensive project for the sake of leaving itself.
Sources
1. Flexera — 2025 State of the Cloud: 84% struggle to manage cloud spend
2. AWS News Blog — Free data transfer out to internet when moving out of AWS
3. The Register — 37signals saves a further $1.3M a year by moving storage off AWS
4. Dropbox Tech — storing and serving more than 90% of users’ data on its own infrastructure
