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

231–240 of 268 posts

Re: Slashing data transfer costs in AWS

#231

Post by dzikimarian »

tqi wrote: post #158
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…

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 an…

Completely not my point. I don't say that using cloud is crazy(we're using it sometimes). I'm saying that opinion that on-prem is much harder than AWS is IMO wrong.

Requires some planning ahead of time - yes. Harder - not really.

Re: Slashing data transfer costs in AWS

#232

Post by holoduke »

overstay8930 wrote: post #131
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.

"Yea this small VPS provider with 1% of the features is just as good as AWS to us" yea that's because you aren't using features as basic as AWS Nitro Enclaves and you are years behind even basic cloud security. Hetzner is for running homelabs and basic compute, not businesses. That's why EU companies constantly ignore EU rulings on US-EU privacy shield because there's just no alternative to American cloud providers y…

My business is running on Hetzner. And many others as well.

Re: Slashing data transfer costs in AWS

#233

Post by sokoloff »

throwaway167 wrote: post #18
jakozaur wrote: post #2

S3 is a nice trick. More tricks: 1. Ask for discounts if you are a big AWS customer (e.g., spend $1mln+/year). At some point, they were huge for inter-AZ transfers. 2. Put things in one AZ. Running DB in "b" zone and your only server in "a" is even worse than just standardizing on one zone. 3. When using multiple AZ do load aware AZ balancing.

> Running DB in "b" zone and your only server in "a" There must be use cases for this, but I lack imagination. Cost? But not cost?

I can't see a reason to do this intentionally within a single account, but use cases with multiple accounts should be aware that what AZ has ID us-east-1a in Account 1 is not necessarily the same AZ that has the ID us-east-1a in Account 2.

https://docs.aws.amazon.com/ram/latest/userguide/working-wit...

Re: Slashing data transfer costs in AWS

#234

Post by rospaya »

xbar wrote: post #188

After my account started getting bills this month for pennies for which there was no obvious accounting, I slashed my AWS costs by 100%. I'm back to managing my own systems. So much cheaper and less chance of nonlinear bills.

Probably free tier expiration for some small change. With me it was AWS KMS.

Re: Slashing data transfer costs in AWS

#235

Post by ownagefool »

steveBK123 wrote: post #62
sofixa wrote: post #36

Earlier quoted context omitted.

> I think a lot of orgs move to cloud simply because it's popular and gartner told them so. Nah, I think it's mostly about the second part of your comment. Everyone hates waiting for months to get a VM or a database or a firewall rule because the infrastructure/DBA teams are stuck ten years in the past and take pride in their artisanal infrastructure building. So moving to the cloud eliminates a useless layer of time…

If your on-prem team can't spin up a VM same day, then firing them is probably higher ROI than "going to cloud". Further, a lot of the shops "going to cloud" because their infra team is slow.. then hide cloud behind their infra team. A prior 200+ dev shop went from automated on-prem VM builds happening within hours from when you raise a ticket, to cloud where there was a slack channel to nag&beg for an EC2 which coul…

They probably should be fired, but it's actually complicated because the orgs tend to be staffed with departments that believe this is the way things should be done, and best case the replacement needs to compromise with them, worse case they are like minded and you just get more of the same.

Re: Slashing data transfer costs in AWS

#236

Post by ownagefool »

photonthug wrote: post #71
steveBK123 wrote: post #62

Earlier quoted context omitted.

If your on-prem team can't spin up a VM same day, then firing them is probably higher ROI than "going to cloud". Further, a lot of the shops "going to cloud" because their infra team is slow.. then hide cloud behind their infra team. A prior 200+ dev shop went from automated on-prem VM builds happening within hours from when you raise a ticket, to cloud where there was a slack channel to nag&beg for an EC2 which coul…

Despite years of friendly sounding devops philosophy there's times when devs and ops are fundamentally going to be in conflict. it's sort of a proxy war between devs who understandably dislike red tape and management who loves it, with devops caught in the middle and on the hook for both rapid delivery of infrastructure but also some semblance of governance. An org with actual governance in place really can't deliver…

Whilst often true in practice, this doesn't have to be true.

The reality is, a lot of these orgs have likely already discovered devops, pipelines, deployment strategies, observability, and compliance as code.

There's basically little in compliance that can't be automated with patterns and platforms, but in most of these organizations a delivery teams interface with the org is their non-technical delivery manager who folds like a beach chair when they're told no by the random infosec bod who's afraid of automation.

I've cracked this nut a few times though. It requires you be stubborn, talk back, and have the gravitas and understanding to be taken seriously. i.e. yelling that's dumb doesn't work, but asking them for a list of what they'd check, and presenting an automated solution to their group, where they can't just yell no, might.

Re: Slashing data transfer costs in AWS

#237

Post by ownagefool »

marcus0x62 wrote: post #68
steveBK123 wrote: post #62

Earlier quoted context omitted.

If your on-prem team can't spin up a VM same day, then firing them is probably higher ROI than "going to cloud". Further, a lot of the shops "going to cloud" because their infra team is slow.. then hide cloud behind their infra team. A prior 200+ dev shop went from automated on-prem VM builds happening within hours from when you raise a ticket, to cloud where there was a slack channel to nag&beg for an EC2 which coul…

I've never seen an IT team that couldn't spin up a VM in minutes. I have seen a bunch of teams that weren't allowed to because of ludicrous "change control" practices. Fire the managers that create this state of affairs, not the devops folks, regardless of whether you "go cloud" or not.

The problem is the strong players are less likely to stick around, so you often do end up with folks who can't do the work in minutes - though, the work is usually slightly more than clicking the "give me the vm" button.

Re: Slashing data transfer costs in AWS

#238

Post by hirako2000 »

chongli wrote: post #182
hirako2000 wrote: post #144

Earlier quoted context omitted.

I concur. Many VPs bend ears so easily you got to wonder. do they also get invited to some private dinner by those so called slick consultants, who pay the bill in a rush and leaves after forgetting some thick envelope on the table.

It’s a story as old as time itself. IBM has been doing it at least as far back as the 60’s. Fancy consultants who know the tech and also know how to sell and make themselves seem way smarter than the VP’s reports. Do one slick presentation and the VP is asking his team “why didn’t you guys come up with this stuff?” Next thing you know these multi-million-dollar contracts are signed and the existing teams are just sha…

I'm not one of those smart ones. So many things I was seeing for years make much more sense now.

It's an old story but I guarantee you many don't know about it.

Re: Slashing data transfer costs in AWS

#239

Post by holoduke »

overstay8930 wrote: post #160
lillecarl wrote: post #153

Earlier quoted context omitted.

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.

Sorry but what kind of wubble wobble talk is this. Hardly anyone needs the stuff you refer to.

Re: Slashing data transfer costs in AWS

#240

Post by unclebucknasty »

martinald wrote: post #97
unclebucknasty wrote: post #77

Earlier quoted context omitted.

> it is virtually free The infrastructure comes at some cost though, right? And there must be some cap on the bandwidth / throughput that a given infrastructure can handle. So, given these, does it make sense to price bandwidth as a throttle?

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.

>That's why I said 'virtually'.

I hear you, and that is an egregious margin. Just wondering if part of their bandwidth pricing calculation is driven by a goal of constraining their infrastructure costs (or other considerations beyond profit). I'm actually wondering this exactly because it is so egregious.

There is of course a thing wherein if something is free people mindlessly use it. If all AWS customers did this with bandwidth, I wonder how it would impact total usage and AWS's subsequent infrastructure considerations.

I'm no fan of their pricing and I'm sure there's an unhealthy dose of greed in there. Your phrasing just prompted me to consider what other factors might also be involved. And, if part of the rationale is actually to influence customer behavior with disincentives, then by definition there would have to be some pain involved.

Post reply on HN