[thrw42A8N]

No way that is true if you did it properly. Practically nobody has a workload where this could be true - and it's definitely not a workload smaller than several DCs.

It doesn't work out well if you just create some long lived EC2 instances and call it a day. But that's not really using a cloud, just a VPS - and that has indeed never been cheaper than having your own servers. You need to go cloud native if you want to save money.

[kasey_junk]

Any egress heavy workload can quickly cost more on cloud than on prem. Especially if you’ve got consistent egress bandwidth that can be negotiated against.

[thrw42A8N]

If it's so heavy that you pay 8x the price of deployment and maintenance of physical servers then you're either very small in which case I'm surprised you don't need the flexibility, or you have many options to make a deal. Don't accept the listed prices.

[kasey_junk]

Can I suggest that perhaps I have extensive experience with very large aws deployments and negotiations and stand by what I said.

[thrw42A8N]

Sorry but this claim makes me seriously question your experience with this particular regard. I'm an AWS partner and this (negotiating better prices) is what we do every week for our clients. There is no way egress causes your costs to 8x compared to on-premise deployment, even if you pay the listed price, and definitely not if you pick up the phone and call the first partner in registry.

If you said 2 times I'd think it's overestimated but okay, let's not dwell on details. 3x is bullshit and so is the rest.

Perhaps you're comparing apples and oranges - yes, it's possible to do a much less capable on-premise deployment that will obviously cost much less. But if we're comparing comparable - just the internet subscription you'd need in your DC to match the AWS offer in availability, connectivity and stability would make any egress costs pale in comparison. Saying this as someone who used to run a hosting company with 3000 servers before the clouds made it obsolete.

And lastly, yes - paying people to do stuff for you usually costs more than time and materials. If you fuck it up, it's up to you to fix it. If AWS fucks it up, you're compensated for it - part of the price are guarantees that are impossible to get with a DIY deployment. Maybe you don't need it, so choose accordingly - a cheaper hosting provider, or even the less capable on premise. But matching the cloud offer all by yourself is not going to be cheaper than the cloud unless you're on AWS scale.

[theamk]

There are so many blogposts about AWS egress being crazy expensive. Here is one: https://www.vantage.sh/blog/cloudflare-r2-aws-s3-comparison . Their example "image hosting" has ~$7K for AWS, vs $36 on R2, mostly due to egress costs.

Yeah, maybe "AWS partner" can give a discount but I bet it'd be 10% for most, or maybe 30% tops. This won't turn $7K into $36.

[thrw42A8N]

AWS offers Cloudfront as an alternative to Cloudflare. Serving traffic straight from your S3 bucket is wrong. S3 stands for Simple Storage Service and they really mean it - it's a low level object storage service intended for programatic usage that does exactly what you tell it without any caching or anything else, not a web hosting. Add Cloudfront and your costs will instantly lower multiple times. AWS tells you this during S3 bucket creation when you try to make it public, btw - it's not hidden.

Cloudflare networking solution doesn't nearly match - and to be fair, they're not trying - what AWS offers. Cloudflare is a small, focused service; AWS is enterprise universal do everything and stay secure&compliant while doing it solution that has the entire Cloudflare offering included and it's not even a big part of AWS. Don't conflate the two - use whatever is better for your use case, budget/margin, risk profile, reliability requirements etc, but each has some and the price is justified.

[hggigg]

It’s easy. Lift and shift, then fuck it up by not quite completely migrate everything to numerous badly managed kubernetes clusters. That’s what we did.

[dlisboa]

> No way that is true if you did it properly.

It's quite easier to mess up in a hyperscaling cloud because it's extremely forgiving. In a different setting you wouldn't be able to make as many mistakes and would have to stop the world and fix the issue.

[randomcarbloke]

there is absolutely a crossover point at which it would've made more sense to stay put.

My organisation is feeling it now and while our cloud environment isn't fully optimised it has been designed with cost in mind.

Using opex to make up for otherwise unjustifiable capex is suitable only in the beginning or if you need the latest servers every six (or whatever) months