Why I Still Recommend OVH and Contabo Alongside AWS

A new client project starts, and before any infrastructure decisions get made, AWS is already assumed, sometimes because a previous developer set it up that way, sometimes just because it's the name everyone knows. Then I look at what's actually running: a Node app, a Postgres database, Redis for sessions, Nginx in front. Nothing that needs auto-scaling groups, nothing that needs twelve regions, nothing that's actually using more than a handful of AWS's hundreds of services. And the monthly bill for that handful of services is several times what the same resources would cost as plain VPS instances.

What AWS is actually good at

This isn't an "AWS is bad" take, it isn't. If you genuinely need to scale from zero to a sudden traffic spike and back down automatically, if you're deep into managed services like RDS Aurora, Lambda, or SQS and the integration between them is doing real work for you, or if a client's compliance requirements specifically call for AWS, it's the right tool and worth the premium. Auto Scaling Groups, multi-AZ RDS failover, and the breadth of managed services solve real problems that would otherwise need to be built and maintained by hand.

The catch is that those features have a cost whether you use them or not, AWS's pricing model is built around granular, metered billing across dozens of dimensions, and a small EC2 instance with EBS storage, a data transfer allowance, and a small RDS instance adds up to noticeably more than the equivalent specs from a VPS provider, often by a factor of two to four.

What a plain VPS gets you

OVH, Contabo, Hetzner, and similar providers sell you a fixed amount of CPU, RAM, and disk for a flat monthly price, full stop. No data transfer surprises, no per-hour billing for a dozen different resource types, no bill that needs a spreadsheet to understand. For a workload that's a handful of services running fairly steadily, that flat price is both cheaper and, often more importantly for a small business, predictable. "The server costs €40 a month" is a sentence a client can plan around. "It depends on traffic, storage, requests, and which AZ" is not.

The tradeoff is that you're managing more yourself: there's no managed database with automatic failover, no auto-scaling, no managed load balancer, you're setting those up if you need them. For a lot of the projects I work on, that tradeoff is fine, the workload doesn't need automatic failover because it's not at a scale where downtime risk justifies the added complexity, and the time saved not configuring AWS-specific tooling more than makes up for the manual setup.

How I actually decide

The question isn't "AWS or not AWS" as a philosophy, it's: does this specific workload need something AWS provides that a VPS doesn't, and is that something worth its cost? If the answer involves "we might need to scale rapidly" as a hypothetical rather than a documented pattern, a VPS that can be resized in minutes covers that without the ongoing premium. If the answer is "we're already deep in RDS and Lambda and it would cost more in engineering time to leave than to stay," that's a real reason to stay.

For new projects that don't have that gravity yet, I default to a VPS and revisit the decision if and when the workload's actual shape, not its hypothetical future shape, calls for something AWS does better. Plenty of profitable, reliable services run entirely on a couple of well-configured VPS instances, and the client never has to explain a surprising invoice to anyone.