I do like watching these comparisons however it reminds me of a conversation I had recently with my 10 year old.
Son: Why does the croissant cost €2.80 here while it's only €0.45 in Lidl? Who would buy that?
Me: You're not paying for the croissant, you're paying for the staff to give it to you, for the warm café, for the tables to be cleaned and for the seat to sit on.
Why is this a video? I'm not going to watch it. I will read the AI summary of the transcript though:
The video argues that AWS is dramatically overpriced and underpowered compared to cheap VPS or dedicated servers. Using Sysbench benchmarks, the creator shows that a low-cost VPS outperforms AWS EC2 and ECS by large margins (EC2 has ~20% of the VPS’s CPU performance while costing 3× more; ECS costs 6× more with only modest improvements). ECS setup is also complicated and inconsistent. Dedicated servers offer about 10× the performance of similarly priced AWS options. The conclusion: most apps don’t need cloud-scale architecture, and cloud dominance comes from marketing—not superior value or performance.
Didn't even mention the difference in data costs, or S3 plus transfer, because then we'll be going into 2-orders-of-magnitude differences ...
Not to mention what happens when you pay per megabyte and someone ddos-es you. Cloud brought back almost all hosting antipatterns, and means denial-of-service attacks really should be renamed denial-of-wallet attacks. And leaving a single S3 bucket, a single Serverless function, a single ... available (not even open) makes you vulnerable if someone knows of figures out the URL.
I'm migrating my last AWS services to dedicated servers with Gitops.
In principle, AWS give you a few benefits that are worth paying for. In practice, I have seen all of them to be massive issues.
Price and performance are obviously bad. More annoying than that, their systems have arbitrary limitations that you may not be aware of because they're considered 'corner cases' -- e.g. my small use-case bumped against DNS limitation and the streaming of replies was not supported.
Then, you have a fairly steep learning curve with their products and their configuration DSLs.
There are Gitops solution that give you all the benefits that are promised by it, without any of the downsides or compromises.
You just have to bite the bullet and learn kubernetes. It may be a bit more of a learning curve, but in my experience I would say not by much. And you have much more flexibility in the precise tech stack that you choose, so you can reduce it by using stuff you're already know well.
Pricing in AWS is heavily dependent on whether you reserve the instance and for how long.
In my experience, if you reserve a bare metal instance for 3 years (which is the biggest discount), it costs 2 times the price of buying it outright.
I'm surprised to hear about the numbers from the video being way different, but then, it's a video, so I didn't watch it and can't tell if he did use the correct pricing.
I'm struggling to find a way to express my opinion about this video without seeming like a complete ass.
If the author's point was to make a low effort "ha ha AWS sucks" video, well sure: success, I guess.
Nobody outside of AWS sales is going to say AWS is cheaper.
But comparing the lowest end instances, and apparently, using ECS without seeming to understand how they're configuring or using it just makes their points about it being slower kind of useless. Yes you got some instances that were 5-10x slower than Hetzner. On it's own that's not particularly useful.
I thought, going in, that this was going to be along the lines of others I have seen, previously: you can generally get a reasonably beefy machine with a bunch of memory and local SSDs that will come in half or less the cost of a similar spec EC2 instance. That would've been a reasonable path to go. Add on that you don't have issues with noisy neighbors when running a dedicated box, and yeah - something people can learn from.
But this... Yeah. Nah. Sorry
Maybe try again but get some help speccing out the comparison configuration from folks who do have experience in this.
Unfortunately it will cost more to do a proper comparison with mid-range hardware.
This is always an unfair comparison because for any realistic comparison you need to have two servers on two locations for georedundancy and need to pay for the premises and their physical security, too. For example, you need to pay for security locks with access log and a commercial security company, or you have to pay for co-location in a datacenter.
When you add up all these costs plus the electricity bill, I wager that many cloud providers are on the cheaper side due to the economy of scale. I'd be interested in such a more detailed comparison for various locations / setups vs cloud providers.
What almost never goes into this discussion, however, is the expertise and infrastructure you lose when you put your servers into the cloud. Your own servers and their infrastructure are MOAT that can be sold as various products if needed. In contrast, relying on a cloud provider is mostly an additional dependency.
I’ve come to believe that such comparisons usually come from people who don’t understand the trade-offs of AWS in production.
Each project has certainly its own requirements. If you have the manpower and a backup plan with blue/green for every infrastructure component, then absolutely harness that cost margin of yours. If it’s at a break even when you factor in specialist continuity - training folks so nothing’s down if your hardware breaks, then AWS wins.
If your project can tolerate downtime and your SREs may sleep at night, then you might profit less from the several niners HA SLOs that AWS guarantees.
It’s very hard and costly to replicate what AWS gives you if you have requirements close to enterprise levels. Also, the usual argument goes - when you’re a startup you’ll be happy to trade CAPEX for OPEX.
For an average hobby project maybe not the best option.
As for latency, you can get just as good. Major exchanges run their matching engines in AWS DCs, you can co-locate.
This is exactly true, and is something we have built our business around. In fact, I just kicked-off a multi-TiB Postgres migration for one of our clients this morning. We're moving them out of Supabase and onto a bare-metal multi-AZ Postgresql cluster in Hetzner.
I'm going to say what I always say here - for so many SME's the hyperscaler cloud provider has been the safe default choice. But as time goes on a few things can begin to happen. Firstly, the bills grow in both size and variability, so CFOs start to look increasingly askance at the situation. Secondly, so many technical issues start to arise that would simply vanish on fixed-size bare-metal (and the new issues that arise are well addressed by existing tooling). So the DevOps team can find themselves firefighting while the backlog keeps growing.
The problem really is one of skills and staffing. The people who have both the skills and desire actually implement and maintain the above tend to be the greying-beards who were installing RedHat 6 in their bedrooms as teenagers (myself included). And there are increasingly few of us who are not either in management and/or employed by the cloud providers.
So if companies can find the staff and the risk appetite, they can go right ahead and realise something like a 90% saving on their current spend. But that is unusual for an SME.
So we started Lithus[0] to do this for SMEs. We _only_ offer a 50% saving, not 90%. But take on all the risk and staffing issues. We don't charge for the migration, and the billing cycle only starts once migration is complete. And we provide a fixed number of engineering days per month included. So you get a complete Kubernetes cluster with open source tooling, and a bunch of RedHat-6-installing greying-beards to use however you need. /pitch
For example, if the service is using a massive dataset hosted on AWS such as Sentinel 2 satellite imagery, then the bandwidth and egress costs will be the driving factors.
compare the worldwide latency, I released an app in the App Store, I got users from Japan to Saudi Arabia to the United States. AWS basically guarantees to reach anyone who speaks English low latency.
IIRC, when the cloud services were taking over the argument was that it’s much cheaper to pay for the AWS than paying engineers to handle the servers. This was also a popular argument for running an unoptimized code(i.e. it’s much cheaper to run two servers instead of making your code twice as fast).
Since the industry has matured now, there must be a lot of opportunity to optimize code and run it on bare metal to make systems dramatically faster and dramatically cheaper.
If you think about it, the algorithms that we run to deliver products are actually not that complicated and most of the code is about accommodating developers with layers upon layers of abstraction.
When you're a solo SaaS developer/company owner, the dedicated server option really shines. I get a 10x lower price and no downsides that I've ever seen.
"But are your database backups okay?" Yeah, I coded the backup.sh script and confirmed that it works. The daily job will kick up a warning if it ever fails to run.
"But don't you need to learn Linux stuff to configure it?" Yeah, but I already know that stuff, and even if I didn't, it's probably easier to learn than AWS's interfaces.
"But what if it breaks and you have to debug it?" Good luck debugging an AWS lambda job that won't run or something; your own hardware is way more transparent than someone else's cloud.
"But don't you need reproducible configurations checked into git?" I have a setup.sh script that starts with a vanilla Ubuntu LTS box, and transforms it into a fully-working setup with everything deployed. That's the reproducible config. When it's time to upgrade to the next LTS release (every 4 years or so), I just provision a new machine and run that script again. It'll probably fail on first try because some ubuntu package name changed slightly, but that's a 5-minute fix.
"But what about scaling?" One of my crazy-fast dedicated machines is equal to ~10 of your slow-ass VPSes. If my product is so successful that this isn't enough, that's a good problem to have. Maybe a second dedicated machine, plus a load balancer, would be enough? If my product gets so popular that I'm thinking about hundreds of dedicated machines, then hopefully I have a team to help me with that.
Although the video is correct in the sense that AWS is vastly overpriced compared to most other cloud/VPS providers, the title is wrong: OP is not using a dedicated server (see 2:40 of the video) -- he is using a shared VPS. Hetzner sell proper dedicated servers, whether bare metal or virtualized.
I believe their bare metal servers should have even better price/perf ratio, but I don't have data to back that up.
I suspect Hetzner has the latest CPU generation and AWS is giving you something they bought 10+ years ago, so it wouldn't be a fair comparisson unless he selects something that guarantees the CPU generation
24 comments
[ 0.19 ms ] story [ 38.7 ms ] threadThe entire point of AWS is so you don't have to get a dedicated server.
It's infra as a service.
Managed NAT gateways are also 10000x more expensive than my router.
This is a boring argument that has been done to death.
Son: Why does the croissant cost €2.80 here while it's only €0.45 in Lidl? Who would buy that?
Me: You're not paying for the croissant, you're paying for the staff to give it to you, for the warm café, for the tables to be cleaned and for the seat to sit on.
The video argues that AWS is dramatically overpriced and underpowered compared to cheap VPS or dedicated servers. Using Sysbench benchmarks, the creator shows that a low-cost VPS outperforms AWS EC2 and ECS by large margins (EC2 has ~20% of the VPS’s CPU performance while costing 3× more; ECS costs 6× more with only modest improvements). ECS setup is also complicated and inconsistent. Dedicated servers offer about 10× the performance of similarly priced AWS options. The conclusion: most apps don’t need cloud-scale architecture, and cloud dominance comes from marketing—not superior value or performance.
Not to mention what happens when you pay per megabyte and someone ddos-es you. Cloud brought back almost all hosting antipatterns, and means denial-of-service attacks really should be renamed denial-of-wallet attacks. And leaving a single S3 bucket, a single Serverless function, a single ... available (not even open) makes you vulnerable if someone knows of figures out the URL.
There are Gitops solution that give you all the benefits that are promised by it, without any of the downsides or compromises. You just have to bite the bullet and learn kubernetes. It may be a bit more of a learning curve, but in my experience I would say not by much. And you have much more flexibility in the precise tech stack that you choose, so you can reduce it by using stuff you're already know well.
In my experience, if you reserve a bare metal instance for 3 years (which is the biggest discount), it costs 2 times the price of buying it outright.
I'm surprised to hear about the numbers from the video being way different, but then, it's a video, so I didn't watch it and can't tell if he did use the correct pricing.
If the author's point was to make a low effort "ha ha AWS sucks" video, well sure: success, I guess.
Nobody outside of AWS sales is going to say AWS is cheaper.
But comparing the lowest end instances, and apparently, using ECS without seeming to understand how they're configuring or using it just makes their points about it being slower kind of useless. Yes you got some instances that were 5-10x slower than Hetzner. On it's own that's not particularly useful.
I thought, going in, that this was going to be along the lines of others I have seen, previously: you can generally get a reasonably beefy machine with a bunch of memory and local SSDs that will come in half or less the cost of a similar spec EC2 instance. That would've been a reasonable path to go. Add on that you don't have issues with noisy neighbors when running a dedicated box, and yeah - something people can learn from.
But this... Yeah. Nah. Sorry
Maybe try again but get some help speccing out the comparison configuration from folks who do have experience in this.
Unfortunately it will cost more to do a proper comparison with mid-range hardware.
When you add up all these costs plus the electricity bill, I wager that many cloud providers are on the cheaper side due to the economy of scale. I'd be interested in such a more detailed comparison for various locations / setups vs cloud providers.
What almost never goes into this discussion, however, is the expertise and infrastructure you lose when you put your servers into the cloud. Your own servers and their infrastructure are MOAT that can be sold as various products if needed. In contrast, relying on a cloud provider is mostly an additional dependency.
Each project has certainly its own requirements. If you have the manpower and a backup plan with blue/green for every infrastructure component, then absolutely harness that cost margin of yours. If it’s at a break even when you factor in specialist continuity - training folks so nothing’s down if your hardware breaks, then AWS wins.
If your project can tolerate downtime and your SREs may sleep at night, then you might profit less from the several niners HA SLOs that AWS guarantees.
It’s very hard and costly to replicate what AWS gives you if you have requirements close to enterprise levels. Also, the usual argument goes - when you’re a startup you’ll be happy to trade CAPEX for OPEX.
For an average hobby project maybe not the best option.
As for latency, you can get just as good. Major exchanges run their matching engines in AWS DCs, you can co-locate.
I'm going to say what I always say here - for so many SME's the hyperscaler cloud provider has been the safe default choice. But as time goes on a few things can begin to happen. Firstly, the bills grow in both size and variability, so CFOs start to look increasingly askance at the situation. Secondly, so many technical issues start to arise that would simply vanish on fixed-size bare-metal (and the new issues that arise are well addressed by existing tooling). So the DevOps team can find themselves firefighting while the backlog keeps growing.
The problem really is one of skills and staffing. The people who have both the skills and desire actually implement and maintain the above tend to be the greying-beards who were installing RedHat 6 in their bedrooms as teenagers (myself included). And there are increasingly few of us who are not either in management and/or employed by the cloud providers.
So if companies can find the staff and the risk appetite, they can go right ahead and realise something like a 90% saving on their current spend. But that is unusual for an SME.
So we started Lithus[0] to do this for SMEs. We _only_ offer a 50% saving, not 90%. But take on all the risk and staffing issues. We don't charge for the migration, and the billing cycle only starts once migration is complete. And we provide a fixed number of engineering days per month included. So you get a complete Kubernetes cluster with open source tooling, and a bunch of RedHat-6-installing greying-beards to use however you need. /pitch
[0] https://lithus.eu
For example, if the service is using a massive dataset hosted on AWS such as Sentinel 2 satellite imagery, then the bandwidth and egress costs will be the driving factors.
Since the industry has matured now, there must be a lot of opportunity to optimize code and run it on bare metal to make systems dramatically faster and dramatically cheaper.
If you think about it, the algorithms that we run to deliver products are actually not that complicated and most of the code is about accommodating developers with layers upon layers of abstraction.
"But are your database backups okay?" Yeah, I coded the backup.sh script and confirmed that it works. The daily job will kick up a warning if it ever fails to run.
"But don't you need to learn Linux stuff to configure it?" Yeah, but I already know that stuff, and even if I didn't, it's probably easier to learn than AWS's interfaces.
"But what if it breaks and you have to debug it?" Good luck debugging an AWS lambda job that won't run or something; your own hardware is way more transparent than someone else's cloud.
"But don't you need reproducible configurations checked into git?" I have a setup.sh script that starts with a vanilla Ubuntu LTS box, and transforms it into a fully-working setup with everything deployed. That's the reproducible config. When it's time to upgrade to the next LTS release (every 4 years or so), I just provision a new machine and run that script again. It'll probably fail on first try because some ubuntu package name changed slightly, but that's a 5-minute fix.
"But what about scaling?" One of my crazy-fast dedicated machines is equal to ~10 of your slow-ass VPSes. If my product is so successful that this isn't enough, that's a good problem to have. Maybe a second dedicated machine, plus a load balancer, would be enough? If my product gets so popular that I'm thinking about hundreds of dedicated machines, then hopefully I have a team to help me with that.
I believe their bare metal servers should have even better price/perf ratio, but I don't have data to back that up.