Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Slashing data transfer costs in AWS

bitsand.cloud

Post reply on HN
Print view View original

151–160 of 268 posts

Re: Slashing data transfer costs in AWS

#151

Post by simplyinfinity »

glintik wrote: post #130
holoduke wrote: post #111

Earlier quoted context omitted.

My small business once spend 50k per month on AWS. We brought that back to 800 dollars for a similar setup at Hetzner. I find this a significant number.

Reliability differs, right?

I have hetzner vms going on 500+ DAYS without restart. I've been a hetzner customer for about 8 years now. Aws has been down x10 times more than hetzner has. And even when hetzner has issues they are localized to a single DC at worst, most often a single host is down. When aws has issue.. The whole internet has issues. Or their central region goes out, also can affect their other regions.

For the small/medium businesses infra I manage here in bulgaria , the same thing would cost 5-10 times as much on aws just for the compute, throw in 1tb of bandwidth.. And this makes no financial sense.

On hetzner I pay 40 euros for 2 vms, dedicated ips, daily backups, 100gb of ssd external storage, and firewall.

Re: Slashing data transfer costs in AWS

#152

Post by overstay8930 »

chongli wrote: post #138
dzikimarian wrote: post #113

Earlier quoted context omitted.

Apparently we're doing the impossible for over 12 years now. Who knew? Some people act like it's some kind of black magic. It's not. We've some customers in our DC and some on AWS for various reasons. AWS isn't less problematic. AWS is about 10x more expensive. Both on prem and cloud require people familiar with them and cloud-engineers are in no way cheaper. Only meaningful problem is that on-prem requires some up f…

Both on prem and cloud require people familiar with them and cloud-engineers are in no way cheaper. I think the real story is a bit sordid: office politics. On-prem and cloud are different skillsets. Companies that have been around for a while can end up with both on-prem and cloud experts who end up competing with each other, often on separate teams. Throw in some slick consultants from Amazon who are able to bend t…

Cloud engineers can do the job of 4-5 on-prem people. Our AWS devs don't need to be BGP or ZFS experts, they just need to be AWS experts.

Re: Slashing data transfer costs in AWS

#153

Post by lillecarl »

overstay8930 wrote: post #149
fabian2k wrote: post #142

Earlier quoted context omitted.

People have been running real businesses before the cloud providers existed. Of course you can run a business with rented dedicated servers.

Of course you can run your business on it, you will just suffer because there is practically 0 automation to it. I guess if you are a small business but we are very obviously not talking about mom and pop shops who need a web and email server.

Incorrect, there's automation for on-prem or smaller providers as well, just because you're unable to doesn't mean it's the truth.

How do you think AWS or Cloudflare is built?

Re: Slashing data transfer costs in AWS

#154

Post by photonthug »

shermantanktop wrote: post #127
Radim wrote: post #85

Earlier quoted context omitted.

I've experienced the opposite too: orgs looking at down on cloud-only devs. The idea being that devs who lean on cloud excessively do that to masks their lack of fundamentals, which will cause costly fuck ups no matter what technology they use, cloud or on-prem. Maybe directionally similar idea to hiring ex-Googlers? Some orgs also don't like those. Specific mindset, specific toolbox.

It is absolutely true that some devs have the AWS product set as the tech toolkit they know best. Whatever their fundamental skills are, the most important way they add value is by optimizing things like lambda startup time or EC2 CPU utilization. Does this allow them to mask deep problems with fundamentals? I guess it could, but that sounds a bit gatekeep-y to me.

Sort of, but IDK, If you have specific needs this might be a somewhat reasonable heuristic for hiring.

Devs who came up building software more or less from scratch really do have a different skillset than ones who stick to working in service-rich environments because there's a significant difference between glueing services together vs building out those same services. For example something like using a paginated API is quite a bit easier than designing/implementing one. A developer who is skilled and methodical about reading and understanding service-level documentation may not actually be able to step through debugging in a REPL, and vice versa. (Not to say that either kind of person cannot learn the other persons tricks, but as far as the differences in what they already know, those can be pretty significant.)

Assuming someone only has one of these skillsets, the most valuable one totally depends on the situation. On the one hand it's pretty cool that service-familiarity tends to be language-agnostic, but it's less cool when your S3-API expert barely understands the basics of tooling in the new language.

Re: Slashing data transfer costs in AWS

#155

Post by dzikimarian »

no_wizard wrote: post #145
dzikimarian wrote: post #113

Earlier quoted context omitted.

Apparently we're doing the impossible for over 12 years now. Who knew? Some people act like it's some kind of black magic. It's not. We've some customers in our DC and some on AWS for various reasons. AWS isn't less problematic. AWS is about 10x more expensive. Both on prem and cloud require people familiar with them and cloud-engineers are in no way cheaper. Only meaningful problem is that on-prem requires some up f…

In many organizations the biggest appeal of services like AWS or GCP isn’t simply cost, it’s that the service is approved and therefore all the services of that service are approved and I no longer have to justify spinning up more compute or leveraging one of their more bespoke services like SQS (or wherever equivalent). It’s all just there, ready to be used. It may not be true for you and where you work but this is…

I'm not saying using AWS is universality bad. Depends on your needs.

What I'm saying is some people are trying to portrait rolling your own k8s or on-prem as equivalent to rolling your own crypto - better left to the chosen ones with years of training in secret monastery. This is BS :-)

Re: Slashing data transfer costs in AWS

#156

Post by rzzzt »

lijok wrote: post #109
ttul wrote: post #107

Earlier quoted context omitted.

Incompetence. Take my friend’s company for instance. They were frustrated paying $60K/mo to Amazon so their brilliant sysadmin bought $600K of servers and moved them into a cheap colo. Over Christmas, everything died, and the brilliant sysadmin was on holiday. Nobody could get things going again for many days and so their entire SaaS business was failing. They lost a lot of business and trust as a result. The sysadmi…

No key person risk management -> no risk register -> no management. Your friends company will fail regardless of poor sysadmin decision making or not. They need to hire competent management ASAP.

Faint ISO 27001 sounds in the background

Re: Slashing data transfer costs in AWS

#157

Post by rescbr »

steveBK123 wrote: post #78
robertlagrant wrote: post #66

Earlier quoted context omitted.

You can still use standard stuff like Kubernetes, even if you go microservices. I don't think it's that bad. I'd say Cloud lets you do a few things, but the way I think of it ultimately is it lets you spend opex instead of capex. If that means though that your opex will end up higher than your capex, then it would be silly to go with it. The other thing is in theory your reliability should be higher, but, again, that…

You CAN, but of course that's not what AWS steers you to. Once your org has gotten to that step, it's been so steered by AWS staff it's hard to imagine suddenly finding sense and building with open standard stuff. Very few AWS shops I have encountered avoid the siren call of various AWS-only or AWS-specific services, which they then become heavily ingrained in.. Generally I do think its mostly about transforming CapE…

I was one of those AWS people that worked with Financial Services customers.

We (at least my team) were always pushing for a minimum of modernization when architecting migration projects - even a simple move to containers, managed by whatever orchestrator they want to run. It helps enormously on costs at least by just taking off so many overhead and overprovisioned VMs from the roster of migration candidates.

More often than not, the customer will refuse that and opt for lift + shift. It's either too hard, they don't have the resources or time, etc.

Re: Slashing data transfer costs in AWS

#158

Post by tqi »

dzikimarian wrote: post #113
overstay8930 wrote: post #91

Earlier quoted context omitted.

If you're at the point you're doing sophisticated cloud cost analysis you are doing the cloud right, because that is completely impossible anywhere else. I swear the people who say go on premise have no idea how much the salary costs of someone who will not treat their datacenter like a home lab is. Even Apple iCloud is in AWS and GCP because of how economical it is, you suck at the cloud you think you have to go bac…

Apparently we're doing the impossible for over 12 years now. Who knew? Some people act like it's some kind of black magic. It's not. We've some customers in our DC and some on AWS for various reasons. AWS isn't less problematic. AWS is about 10x more expensive. Both on prem and cloud require people familiar with them and cloud-engineers are in no way cheaper. Only meaningful problem is that on-prem requires some up f…

These types of debates always seem to go this way - one person saying one option works way better for them so the other option must be crazy, followed by another person saying the opposite. I'm not an infra guy, but my guess is the reality is both are choosing the right option for themselves, because is no one objectively "best" option. Just tradeoffs.

I also think if a company is unhappy with their current set up and thinks that switching from cloud to on-prem (or vis versa) is the answer, they're probably delusional because "the fault, dear Brutus, is not in our stars, but in ourselves."

Re: Slashing data transfer costs in AWS

#159

Post by api »

Aissen wrote: post #135
martinald wrote: post #97

Earlier quoted context omitted.

That's why I said 'virtually'. Hurricane Electric does 40gig/sec IP transit for $2k/month. Assuming you used 50% of the capacity of that link that's about 1/200th (I think, numbers are so small) of the cost of AWS for bandwidth.

And at scale, AWS does not pay the HE price. So add another factor 3 to 10 there.

Yep. Big cloud bandwidth is a 200X markup from list price. Its ludicrous.

It serves two purposes for them. One is obviously a nice profit center. The other is that free ingress but expensive egress causes data to flow in but not out, creating a center of gravity and a form of lock in.

Re: Slashing data transfer costs in AWS

#160

Post by overstay8930 »

lillecarl wrote: post #153
overstay8930 wrote: post #149

Earlier quoted context omitted.

Of course you can run your business on it, you will just suffer because there is practically 0 automation to it. I guess if you are a small business but we are very obviously not talking about mom and pop shops who need a web and email server.

Incorrect, there's automation for on-prem or smaller providers as well, just because you're unable to doesn't mean it's the truth. How do you think AWS or Cloudflare is built?

You're arguing semantics, you are on massive copium if you think that automation is useful to anyone. Go ahead and set up cryptographic attestation (or just try and interface with a TPM ffs) for your apps on Hetzner to decrypt customer data and see how impossible it is.
Post reply on HN