A lot of these articles look at on-demand pricing for AWS. But you're rarely paying on-demand prices 24/7. If you have a stable workload, you probably buy reserved instances or a compute savings plan. At larger scales, you use third party services to get better deals with more flexibility.

A while back I looked into renting hardware, and found that we would save about 20% compared to what we actually paid AWS – in partially because location and RAM requirements made the rental more expensive than anticipated, and partially because we were paying a lot less than on-demand price for AWS.

20% is still significant, but it's a lot less than the ~80% that this and other articles suggest.

▲

vidarh 6 days ago | parent [-]

This is usually only true of you lift and shift your AWS setup exactly as-is, instead of looking at what hardware will run your setup most efficiently.

The biggest cost with AWS also isn't compute, but egress - for bandwidth heavy setups you can sometimes finance the entirety of the servers from a fraction of the savings in egress.

I cost optimize setups with guaranteed caps at a proportion of savings a lot of the time, and I've yet to see a setup where we couldn't cut the cost far more than that.

▲

SatvikBeri 5 days ago | parent [-]

I'd definitely be curious to hear how you'd approach our overall situation. We don't have significant egress costs, nor has any place I've worked with before. Our AWS costs are about 80% EC2 and Fargate, with the rest scattered over various services. Roughly half our spend is on 24/7 reserved instances, while the other half is in bursty analytics workloads.

Our workloads are primarily memory-bound, and AWS offers pretty good options there, e.g. x2gd instances have 16gb RAM/cpu, while most rental options we found were much more CPU focused (and charged for it.)

	▲	Nextgrid 5 days ago \| parent \| next [-]
		> while most rental options we found were much more CPU focused Out of curiosity have you benchmarked it? I find that AWS "vCPUs" are significantly slower than a core (or even hyperthread) of a real CPU, and this constrains memory bandwidth too. A single bare-metal can often replace many EC2s. Another thing to consider is the easy access of persistent NVME drives, something not possible on AWS. Yes you still need backups, but ideally you will only need those backups once a year or less. I've dealt with extremely complex and expensive solutions on AWS that could be trivially solved by just one persistent machine with NVME drives (+ a spare for redundancy). Having the data there persistently (at a cheap price per GB) means you avoid having to shuffle data around or can precompute derived data to speed up lookups at runtime. If you're actually serious about exploring options to move your infra to bare-metal or hybrid feel free to reach out for a no-obligations call; email in my profile. It seems like you've already optimized it quite well so I'd be curious to see if there is still room for improvement. (Or if you don’t mind, share what your stack is and let others chip in too!)
	▲	vidarh 3 days ago \| parent \| prev [-]
		I don't know what to say to this. X2gd instances are horrifically expensive - if you haven't trivially found cheaper machines elsewhere, there are essential details of your requirements you're leaving out.