Ask HN: Do I need AWS? Or am I thinking this wrong?

Now that I'm working on my own company, I'm curious about alternatives to AWS.

I'm keeping things simple, so I've got mostly Go services, pg + caching, and a svelte webapp. I deployed my Go services on a low-ish end bare metal provider, and for now it is fine. Deployments are triggered via scripts, and so far so good. Is it sexy, using all the latest and greatest tech? No, its just simple shell scripts. But it works?

I also benchmarked each endpoint with tens of millions of records (not a whole lot but still) and I'm seeing a pretty good latency to throughput ratio. In fact, the performance is better than what we got during peak at work, and this setup is costing me tens of dollars a month.

That makes me think if I even ever really need AWS. If I ever need to do multi region, I can just spin up a new machine there. CDN covers all static content.

Am I wrong to think that I could probably scale like crazy and avoid AWS completely with my stack? Why should I pay hundreds/thousands per month plus a premium for bandwidth? I'm also enjoying staying sane avoiding IAM.

Depending on your current provider, there may be advantages moving your existing bare metal server to EC2. For example, what happens if the drive on your server fails? You'll probably need to write a backup script and write documentation on how to restore from it. If that happened to an EC2, AWS would just restart your instance on a new host and your EBS volume would come with it, and automated snapshots can be set up with a single click. Security groups are simpler to set up than configuring a Linux firewall. Lastly, EC2 has support for automated horizontal scaling with on-demand pricing and Spot instances. But none of these are a must-have, they are conveniences, and you pay a premium cost for it. Hetzner has servers with 64 GB memory for €37 per month, and a similarly-specced EC2 will easily be 10x that cost.

This sticks out to me. IAM isn't crazy, and having access controls in place is going to be the very first thing you want to do when you bring someone else on board. Maybe you're not there yet, but it would be a wise time investment to understand how these work, to the point where they don't feel confusing.

The appeal of AWS' "insane" bills are that they are not so "insane" when compared to the salaries required to maintain a home grown stack in-house, especially as complexity increases.

It's not just application complexity, it's organizational complexity. Doing everything yourself is fine until that complexity increases and you start finding out that all your dozens or hundreds of expensive employees are spending a lot of time on home grown overhead.

For example, when you use shell scripts for your deploys, you can't as easily prove things to auditors like you can with a CI/CD system that's tied in to role based access control. That sort of thing will be dealbreaker for customers who expect your company to maintain industry compliance standards.

When you use a product like RDS you can tell your customers that Amazon is the one responsible for handling backups, security patching, etc.

Also keep in mind that anyone with a significant amount of AWS infrastructure should be buying reservations and savings plans. The sticker price of AWS is not what corporations pay.

As you grow your company, I encourage you to focus on the activities that make your business profitable and deliver value to customers. Every hour you spend upgrading a database or patching an operating system is an hour you could have been spending on developing a unique feature in your product that nobody else has.

For now, I'm sure using this setup is much better than getting something too complex for your size, but that can change quickly if you're lucky enough to reach a larger scale.