Hacker News Reader

Comment by anticodon | Hacker News Reader

I'm not surprised about 90% of savings. I remember that initially AWS was promoted everywhere as being "cheaper" than your own hardware, colocation or VPS/VDS hosting.

Once I was working in a quite small company (around 100 employees) that hosted everything on AWS. Due to high bills (it's a small company that resided in Asia) and other problems, I migrated everything to DigitalOcean (we still used AWS for things like SES), and the monthly bill for hosting became like 10 times lower. With no other consequences (in other words, it haven't become less reliable).

I still wonder who calculated that AWS is cheaper than everything else. It's definitely one of the most expensive providers.

View on HN

Interesting, comparing commodity services (VMs, storage etc) like-for-like, DO has always seemed more expensive than AWS. Do you remember what was the main source of savings?

I don't remember all the details. But the triggering point was Amazon RDS: it was complaining every week that our DB consumed all available space and we had to increase the size and pay more with every week. Our DB and flow of data wasn't that big. I've spent some time investigating but haven't found anything: sum of sizes of all tables was quite moderate and much less than the size of the storage we paid Amazon for.

I lacked both expertise and time to find out where the wasted space go. After I've set up Maria DB on a smallest Digital Ocean droplet, mysterious storage growth haven't repeated and the cheapest droplet had enough capacity to serve our needs for years.

Also, there were 7-10 forgotten "test" server instances and other artifacts (buckets, domains, etc) on Amazon (I believe it's also quite common, especially in bigger companies).

My memory might be off here but wasn’t the initial AWS "cheaper" promise only made vs buying & maintaining your own hardware?

AWS is cheaper under certain, favorable (to them) assumptions, primarily around needing fewer employees to maintain the hardware.

In my mind it's very similar to how people sometimes frame the cost-effectiveness of Apple products.

Like when the 5K iMac originally came out, there was a lot of people claiming it was a good value. Because if you bought a 5K display and then built a PC, that would end up being more expensive. So, like for like, Apple was cheaper.

But... that assumed you even needed a 5K display, which were horribly overpriced and rare at the time. As soon as you say "4K is good enough", the cost advantage disappears, and it's not even close.

A single developer in Denmark (it's a Danish company) would easily cost around $100K a year to the company.

They might save 90% of their $24K on hardware, but just spend probably double the amount on salaries.

This is why AWS is in the end cheaper if it is costs more for the same (let's be real it's not at all the same actually) software.

The OP already said that they spend the same amount of time maintaining this vs AWS

For now :)

If you want me to assess what I would be needing the next 5-10 years, I'd make a very different thread here on HN.

The defining conditions is my current setup and business requirement. It works well and we've resisted pretending that we know where we will be in 5 years.

I am reminded of the 2023 story of the surprisingly simple infra of Stack Overflow[1] and the 2025 story of that Stack overflow is almost dead[2]

Given that the setup works now, one can't add that it is only working "for now". I see no client demand in the foreseeable future leading me to think that this has been fundamentally architected incorrectly.

[1] https://x.com/sahnlam/status/1629713954225405952

[2] https://blog.pragmaticengineer.com/stack-overflow-is-almost-...

That is absolutely not what I was talking about.

I'm talking about the issues that will happen to your current setup and requirement. Disaster recovery, monitoring, etc.

> Disaster recovery, monitoring, etc

The ISO 27001 has me audited for just that (disaster recovery and monitoring) so that settles it, no?

Also worth noting that these are the two things you don't really get from the hyperscalers. If you want to count on more than their uptime guarantees, you have to roll some DR yourself and while you might think that this is easy, it is not easier than doing it with Terraform and Ansible on other clouds.

I have had my DR and monitoring audited in its AWS and EU version. One was no easier or harder than the other.

But the EU setup gave me a clear answer to clients on CLOUD act, Shrems II, GDPR, Safe Harbor, which is a competitive advantage.

It sounds like if you rent a VPS/VDS in any other place than Amazon, you'll have to hire a separate person to babysit it 24/7. It's not true.

Obviously it's not true, but if you want to put the following on your VPS:

> • Ansible roles for PostgreSQL (with automated s3cmd backups + Prometheus metrics) • Hardening tasks (auditd rules, ufw, SSH lockdown, chrony for clock sync) • Rolling web app deploys with rollback + Cloudflare draining • Full monitoring with Prometheus, Alertmanager, Grafana Agent, Loki, and exporters • TLS automation via Certbot in Docker + Ansible

You'll spend a heck of a lot of time on setting it up originally, and you will spend a lot of time keeping it up-to-date, maintaining it, and fixing the inevitable issues that will occur.

If their bill was 200K a year, why not. But at 24K a year, 25% of an employee's salary, it is negligible and most likely a bad choice.

People keep comparing cloud costs to employee costs, but I think that’s the wrong metric. The real ratio to look at is cloud spend vs. the revenue you can unlock.

For me, switching from AWS to European providers wasn’t just about saving on cloud bills (though that was a nice bonus). It was about reducing risk and enabling revenue. Relying on U.S. hyperscalers in Europe is becoming too risky — what happens if Safe Harbor doesn’t get renewed? Or if Schrems III (or whatever comes next) finally forces regulators to act?

Being able to stay compliant and protect revenue is worth far more than quibbling over which cloud costs a little less.

Some of these tasks are required when you run your service in Amazon Cloud as well. It's not all free and not all by default. You'll need someone experienced with Amazon Services to set up many of these things in the Amazon cloud as well.

Also, it's not like you need everything you mention and need it immediately.

NTP clock syncing is a part of any Linux distro for the last 20 years if not more.

I don't remember that Amazon automatically locks down SSH (didn't touch AWS for 7-8 years, don't remember such a feature out of the box 8 years ago).

Rolling web app deploys with rollback can be implemented in multiple ways, depends on your app, can be quite easy in some instances. Also, it's not something that Amazon can do for you for free, you need to spend some effort on the development side anyways, doesn't matter if you deploy on Amazon or somewhere else. There's no magic bullet that makes automatic rollback free and flawless without development effort.

Exactly. Well said.

A thing we learned in this process is that there's many levels of abstraction which you can think of rollback and locking down SSH and so on and so forth.

If your abstraction level is AWS and the big hyperscalers, it would be to use Kubernetes, but peeling layers of complexity off that, you could also do it with Docker Compose or even Linux programs that are really battle tested for decades.

Most ISO certified companies are not at hyperscale so here is a fun one: Instead of Grafana Agent from 2020, you could most likely get away better with rsyslog from 2004.

And if you want your EKS cluster to give you insights you have configure CloudWatch yourself so does what hands-off is there comparing that setup to Ubuntu+Grafana Agent?

Reply on news.ycombinator.com