AWS is 10x slower than a dedicated server for the same price [video] (opens in new tab)

When your cheap dedicated server goes down and your admin is on holiday and you have hundreds of angry customers calling you, you'll get it.

Or you need to restore your Postgres database and you find out that the backups didn't work.

And finally you have a brilliant idea of hiring a second $150k/year dev ops admin so that at least one is always working and they can check each other's work. Suddenly, you're spending $300k on two dev ops admins alone and the cost savings of using cheaper dedicated servers are completely gone.

What AWS gives you is the ability to spin up dozens if not thousands of hosts in a single click.

If you run your own hardware, getting stuff shipped to a datacenter and installed is 2 to 4 weeks (and potentially much longer based on how efficient your pipeline is)

> “nobody ever got fired for choosing IBM”

Agreed, there's definitely a heavy element of that to it.

But, at the risk of again being labelled as an AWS Shill - there's also other benefits.

If your organisation needs to deploy some kind of security/compliance tools to help with getting (say) SOC2 certification - then there's a bunch of tools out there to help with that. All you have to do then is plug them into your AWS organisation. They can run a whole bunch of automated policy checks to say you're complying with whatever audit requirements.

If you're self-hosting, or using Hetzner - well, you're going to spend a whole lot more time providing evidence to auditors.

Same goes with integrating with vendors.

Maybe you want someone to load/save data for you - no problems, create an AWS S3 bucket and hand them an AWS IAM Role and they can do that. No handing over of creds.

There's a bunch of semi-managed services where a vendor will spin up EC2 instances running their special software, but since it's running in your account - you get more control/visiblity into it. Again, hand over an AWS IAM Role and off you go.

It's the Slack of IAAS - it might not be the fastest, it's definitely not the cheapest, and you can roll your own for sure. But then you miss out on all these integrations that make life easier.

>>As a CTO of a number of small startups, I am still struggling to understand what exactly AWS and other cloud providers give you to justify the markup.

If you are having a company that warrants building a data center, then AWS does not add much.

Other wise you face the 'if you want to build apple pie from scratch, you need to first invent the universe' problem. Simply put you can get started right on day one, in a pay as you go model. Like you can write code, deploy and ship from the very first day, instead of having to go deep down the infrastructure rabbit hole.

Plus shutting down things is easy as well. Things don't workout? Good news! You can shut down the infrastructure that very day instead of having to worry about the capital expenditure spent to build infrastructure, and without having to worry about its use later.

Simply put, AWS is infrastructure you can hire and fire at will.

As a Staff+ Engineer -- Principal in a couple of weeks -- for me it's about "batteries included", support availability, and ability to hire.

Using a cloud platform means that while your needs are small, you're overpaying. Where it pays off is when you have a new requirement that needs to be met quickly.

I've done my share of managing database instances in the past. I can spin up a new RDS Postgres instance in much less time than I can configure one from scratch, though. Do we need a read replica? Multi-site failover? Do we need to connect it to Okta, or Formal, so we can stand up a process to provision access to specific databases, tables, or even columns? All of those things I can do significantly faster and more quickly on AWS than I can do it by hand.

What if a NoSQL database is the right solution for us? I have much less experience adminning those, so will either have to allocate a fair amount of my time to skill up or hire someone who already has those skills.

Need a scheduled task? Sure, I could set up a Jenkins server somewhere and we could use that... or we could just add an ECS scheduled task to our existing cluster.

Need an API endpoint to handle inbound Zoom events and forward them to an internal queue? Sure, I can set up a new VPC for that... that'll be a couple of days... or we whip up a Lambda, hook it up to API Gateway, and be up and running in a couple of hours.

AWS helps me do more in less time - and my time is a cost to the business. It's also extremely flexible, and will let us add things far more quickly than we otherwise could.

IMO, the correct comparison isn't "what would it cost to run this platform on Hetzner?" - it's "What would it cost to run it, plus what would cost to acquire the talent to build it, plus retain that talent to maintain it?"

AWS isn't competing with other infrastructure providers. They're competing with other providers and the salaries of the engineers you need to make them work.

It makes sense to think about price in the context of your business. If your entire infra cost is a rounding error on your balance sheet, of course you would pick the provider with the best features and availability guarantees (choose IBM/AWS). If your infra cost makes up a significant percentage of your operating expenses, you will start spending engineering effort to lower the cost.

That's why AWS can get away with charging the prices they do, even though it is expensive, for most companies it is not expensive enough to make it worth their while to look for cheaper alternatives.

Because people aren't going on AWS for EC2, they go on it to have access to RDS, S3, EKS, ELB, SNS, Cognito, etc. Large enough customers also don't pay list price for AWS.

I'm saying that if you do want to compare two different platforms on performance, it should probably be done in consultation with someone who has worked with it before.

To use an analogy it's like someone who's never driven a car, and really only read some basic articles about vehicles deciding to test the performance of two random vehicles.

Maybe one of them does suck, and is overpriced - but you're not getting the full picture if you never figured out that you've been driving it in first gear the whole time.

Great link. I find my instances are more sensitive to RAM pricing than CPU performance as my needs are generally more IO-bound than CPU.

I'm pretty sure this was posted on HN a while ago, and that I read it then.

It's good - makes it's point well.

Well, you're entitled to your opinion.

For what it's worth - my day job does involve running a bunch of infrastructure on AWS. I know it's not good value, but that's the direction the organisation went long before I joined them.

Previous companies I worked for had their infrastructure hosted with the likes of Rackspace, Softlayer, and others. Every now and then someone from management would come back from an AWS conference saying how they'd been offered $megabucks in AWS Credit if only we'd sign an agreement to move over. We'd re-run the numbers on what our infrastructure would cost on AWS and send it back - and that would stop the questions dead every time.

So, I'm not exactly tied to doing it one way or another.

I do still think though that if you're going to do a comparison on price and performance between two things, you should at least be somewhat experienced with them first, OR involve someone who is.

The author spun up an ECS cluster and then is talking about being unsure of how it works. It's still not clear whether they spun up Fargate nodes or EC2 instances. There's talk of performance variations between runs. All of these things raise questions about their testing methodology.

So, yeah, AWS is over-priced and under-performing by comparison with just spinning up a machine on Hetzner.

But at least get some basics right. I don't think that's too much to ask.

Bingo.

In this particular case the only need was for Postgres migration, no other services needed.

The problems we've seen or heard about with Supabase are:

* Cost (in either magnitude or variability). Either from usage, or having to go onto their Enterprise-tier pricing for one reason or another * The usual intractable cloud-oddities – dropped connections, performance speed-bumps * Increased network latency (just the way it goes when data has to cross a network fabric. Its fast, but not as fast as your own private network) * Scaling events tend not to be as smooth as one would hope

None of these are unique to Supabase though, they can simply all arise naturally from building infrastructure on a cloud platform.

Regarding self-hosted Supabase - we're certainly open to deploying this for our clients, we've been experimenting with it internally. Happy to chat with you or anyone who's interested. Email is adam@ company domain.

Also. Your company is paying. You are not.

So for enough people the price is not an issue. Someone else is paying.

On other side. People are pretty bad at this sort of cost analysis. I fall on this issue, prefer to spend more time myself on something I should just recommend to buy.

On point.

We don't pay million $ bills on AWS to "hang out" in a cozy place. I mean, you can, but that's insanity.

He means the location, not the fluid. My coffee better be hot, not warm.

Exactly. The whole promise behind cloud was "you don't need an ops team". Now go check for yourself if that's true: go to your favorite jobs portal and search for AWS, or to include Azure and Github sysadmins search for "devops engineer". And for laughs search for "IAM engineer", which is a job only about managing permissions for users (not deciding about permissions, JUST managing them and fixing problems, nothing more. And frankly, the cloud is to blame: figuring out correct permissions now requires teams of PhDs to do correctly on infuriating web interfaces. I used to think Active Directory permissions were bad. I was wrong. The job portals show: no corporate department should ever go without a team of IAM engineers who are totally not really sysadmins)

What do you get for this? A redundant database without support (because while AWS support really tries so hard to help that I feel bad saying this, they don't get time to debug stuff, and redundant databases are complicated whether or not you use the cloud). You also get S3 distributed storage, and serverless (which is kind of CGI, except using docker and AWS markups to make one of most efficient stateless ways to run code on the web really expensive). Btw: for all of these better open source versions are available as a helm chart, with effectively the same amount of support.

You can use vercel to get out from under this, but that only works for small companies' "I need a small website" needs. It cannot do the integration that any even medium sized company requires.

Oh, and you get Amazon TLA, which is another brilliant amazon invention: during the time it takes you to write a devops script Amazon TLA comes up with another three-letter AWS service that you now have to use, because one of the devs wants it on his resume, is 2x as expensive as anything else, doesn't solve any problem and you now have to learn. It's all about using AI for maximizing uselessness.

And you'll do all this on Amazon's patented 1994-styled webpages because even claude code doesn't understand the AWS CLI. And the GCP and Azure ones are somehow worse (their websites look a lot nicer though, I'll readily admit that. But they're not significantly more functional)

Conclusion: while cloud has changed the job of sysadmin somewhat, there is no real difference, other than a massive price increase. Cloud is now so expensive that, for a single month's cloud services, you can buy hardware and put it on your desk. As the youtube points out, even an 8GB M1 mac mini, even a chinese mini-pc with AMD, runs docker far better than the (now reduced to 2GB memory) standard cloud images.

Me too, but it's worth remembering that's not the case for everyone. Some people want to have a little chat with the person at the counter, sit down for 5 mins in the corner of the cafe and eat their croissant. 5 euro can be a good price if that's what you want, and it doesn't matter if the lidl croissant is free, it will still be disappointing to the person who wants the extras.

AWS counts as managed servers with constant security monitoring. That's a huge difference to paying for a dedicated server where you're responsible for the installation and maintenance of the operating system and all software, intrusion detection and thread responses, and server monitoring.

I am a Hetzner customer for my forthcoming small company in order to keep running costs low, but it's not as if companies using AWS were irrational. You get what you pay for.

You're also getting pretty stale instances by the end of the 3 years.

At two difference companies, I've seen a big batch of committed instances finally go off contract, and we replaced them with more modern instances that improved performance significantly while not costing us anything more or even letting us shrink the pool, saving us money.

It's a pain, but auto scaling groups with a couple different spot instance types in it seems to be quasi necessary for getting an ok aws compute value.

Elasticity is very expensive, in practice people only use it for one-off jobs, preferably using the cheaper unreliable "spot" instances (meaning the job must support being partially re-run to recover, which implies a complex job splitting and batching platform).

For traditional, always-on servers, you should reserve them for 3 years. You still have the ability to scale up, just not down. You can always go hybrid if you don't know what your baseline usage is.

Should you be designing for a single server to exist for 3 years when you have such elastic compute? Why not design for living on spot instances and get savings lower than hetzner with better performance? What about floating savings plans? There’s a ton left on the table here just to say ‘aws bad’ for some views

The problem with this discussion is that a lot of people on these threads work as overpaid assistants to the one private chef, but also have never cooked at home.

Translating:

A lot of people work with AWS, are making bank, and are terrified of their skill set being made obsolete.

They also have no idea what it means to use a dedicated server.

That’s why we get the same tired arguments and assumptions (such as the belief that bare-metal means “server room here in the office”) in every discussion.

My feeling is that a more apt comparison would be "cooking yourself vs. ordering Doordash all the time" (aka "a taxi for your burrito)

>The point of having a private chef is so you don’t have to cook food by yourself.

With cloud, you hire a private chef and ALSO have to cook the food by yourself.

You don't hire a team to maintain the server infrastructure, but you hire a team to maintain cloud infrastructure.

Havibg a private chef is more like havibg hired people to manage your own hardware. Doordash is aws

it's not interesting as a standalone question indeed. The question is, what do you enable by having a private chef?

Is it the fact that you don't want to spend the time cooking? or is it cooking plus shopping plus cleaning up after?

Or is it counting the time to take cooking lessons? and including the cost of taking the bus to those cooking lessons?

Does the private chef even use your house, or their own kitchen? Or can you get a smaller house without a kitchen alltogether? Especially at the rate of kitchen improvement, where kitchens don't last 20 years anymore, you're gonna need a new kitchen every 5 years. (granted the analogy is starting to fail here, but you get my point)

Big companies have been terrible at managing costs and attributing value. At least with cloud the costs are somewhat clear. Also, finding staff that is skilled is a considerable expense for businesses with a more than a few pieces of code, and takes time, you can't just get them on a whim and get rid of them.