Live data from Hacker News

Effectively using AWS Reserved Instances

stripe.com

51–60 of 123 posts

Re: Effectively using AWS Reserved Instances

#51

The notion that the break even point is 70% is ignoring some really important stuff. If you reserve workload x on hardware y for n years, you're effectively strapping yourself into a sure-to-be-obsolete and more expensive platform which you'll have to then move off of at an arbitrary point n years in the future. If you don't move, you wind up paying a premium to be stuck with the obsolete / more expensive platform ju…

I don't see how arbitrary AWS instances are in any way going to go 'obsolete'. They have been around for a decade and are becoming more and more normative.

Second, the underlying financial principle is that with visibility comes lower volatility comes lower cost - that's some very basic financial logic that's at play here.

Yes, of course the contract implies a degree of vendor lock-in, but this is inherent in the nature underlying operational costs.

"RIs are a lock in." - of course. And if you don't want to be locked in, then you're going to have to pay a lot more: AWS, GCC it doesn't matter, it's the same financial reality everywhere.

Re: Effectively using AWS Reserved Instances

#52
post #21
post #10

Earlier quoted context omitted.

How exactly does that solve the problem? Don't you have to do the same capacity planning to decide how many servers to buy for your datacenter? Except you get less flexibility because you can't buy servers and have them instantly available like you can for reserved instances? Also, what kind of workloads are you running that don't require databases? The biggest expense in any distributed system is moving data. If you…

Right, you have to do the same capacity planning, but you are getting the massive upside involved in that work instead of Amazon. >What you might save in not paying AWS's profit margin you will probably spend in not being able to be as efficient as they are. This isn't how I've seen the numbers work out for the huge chunk of workloads that require mostly static instances (a.k.a haven't been modernized into a serverle…

I think this is a really illustrative example of how business strategy can influence decision-making.

"Paying AWS's profit margin" assumes you can get access to their cost structure. You can't. In order to get AWS's cost structure, you need to (a) be buying servers by the truckload to get volume discounts, (b) have a scaled labor force for physically moving, racking, and installing all of this that's insured, directed, and managed to high rates of utilization (want to pay devs to rack servers?), (c) hire expensive network engineers whose cost is fully amortized across AWS's massive installed base, (d) fully amortize all the software engineering required to control all of this, etc.

So the more realistic option for a typical company is, do I (a) try to do this myself, with the time delay, risk, and cost profile of a nonspecialist provider, or (b) pay Amazon, which will cost about the same as (a), but be better in every other way, EVEN THOUGH amazon's superior cost structure lets them make a decent profit off of that decision?

(b) is clearly the right choice. It costs you nothing more, Amazon gets to make profit, and everyone is better off. Point being, you are forced to go with Amazon because they have structural advantages you don't, which gives them access to a better cost structure that you can't replicate.

Re: Effectively using AWS Reserved Instances

#53
post #29
post #21

Earlier quoted context omitted.

Right, you have to do the same capacity planning, but you are getting the massive upside involved in that work instead of Amazon. >What you might save in not paying AWS's profit margin you will probably spend in not being able to be as efficient as they are. This isn't how I've seen the numbers work out for the huge chunk of workloads that require mostly static instances (a.k.a haven't been modernized into a serverle…

You don't have to move all the data, but you have to constantly move the needed data back and forth, unless you store a second copy in the cloud. And then you have to start capacity planning again. > This isn't how I've seen the numbers work out for the huge chunk of workloads that require mostly static instances. Any time someone says this I have to question if they really looked at the "all in" number. Did you incl…

>There are so many other costs to running your own datacenter besides the servers and the space, which Amazon gets to amortize over all their customers, but you have to bear 100% on your own.

Yes, but those costs may be low (or zero) for you, but Amazon has to architect at a level much higher than that. For example, I have researchers with data that has zero backup/DR requirements. This is 10s of TB of data, but if they lost it all due to a fire or a catastrophic system crash, they would just shrug, order a new storage array from the insurance money, and request new copies of the data from the research labs at other institutions that also have it. Amazon doesn't offer any storage products at that reliability level, and the ones that are even close have significant data access latencies or file transfer costs to run analysis over a significant chunk of the data.

So, they buy a basic NAS, stuff if with 12T drives, and pay $0.19/Gig for it. That's one time, not monthly, and at only 50% utilization. Assuming S3 Reduced Redundancy is $0.02/Gig/mo (it's actually a little more, but we're being generous), they start saving money in month 10 not counting the data transfer or compute costs associated with processing that data either locally or in the cloud.

Re: Effectively using AWS Reserved Instances

#54
post #32
post #17

Earlier quoted context omitted.

What are you talking about? I have so many questions - who is uncle Bob in this scenario, an AWS employee? Who's uncle is he and why is that important? And what makes his flash drive fancy? AWS has several encryption products you can easily look up, such as KMS. No, the employees don't have the keys. [1] [1] https://aws.amazon.com/kms/faqs/

Uncle Bob is AWS employee. How is the application residing on AWS decrypt private data if it does not have access to the master(private) key?

KMS is a hardware security module, kind of like the secure enclave on an iPhone. The private key doesn't leave the hardware, your process requests that KMS should encrypt or decrypt something (which is probably another disposable key used for your session to the a DB or whatever, like in a browser TLS session). All of AWS's core services are neatly integrated with KMS: EBS, EFS, RDS, DynamoDB, etc.

I'd trust the AWS datacenter security and processes over your average big-corp datacenter any day, having seen quite a few.

Re: Effectively using AWS Reserved Instances

#55
post #30

Earlier quoted context omitted.

It's been a few years since doing the cost benefit analysis between AWS and self-hosting, but for around 50 racks worth of servers and storage, the numbers came in on AWS's side. That didn't even take into account the "free" multi-region capability you get from Amazon. Splitting our physical servers into a second region with enough capacity to failover would have nearly doubled our costs.

Why would you compare AWS vs managing your own data center? You could also compare AWS vs building your own silicon. I think it would be better to compare AWS vs renting dedicated servers from a large provider? I think you will find that the scales tip heavily in favor of renting bare metal as far as price is concerned.

Why would you compare AWS vs managing your own data center?

Because we were already managing our own data center.

I think it would be better to compare AWS vs renting dedicated servers from a large provider? I think you will find that the scales tip heavily in favor of renting bare metal as far as price is concerned.

We offloaded a lot of work to Amazon that we were doing ourselves -- database hosting, storage system management, etc (lots of little used data went into S3/Glacier that previously we had on live disks)

Also, we liked the ability to have a failover region essentially for free - we only pay for enough servers to replicate the key data we need for failover, and keep the rest of the infrastructure powered off.

Re: Effectively using AWS Reserved Instances

#56
post #32
post #17

Earlier quoted context omitted.

What are you talking about? I have so many questions - who is uncle Bob in this scenario, an AWS employee? Who's uncle is he and why is that important? And what makes his flash drive fancy? AWS has several encryption products you can easily look up, such as KMS. No, the employees don't have the keys. [1] [1] https://aws.amazon.com/kms/faqs/

Uncle Bob is AWS employee. How is the application residing on AWS decrypt private data if it does not have access to the master(private) key?

I had the same question as you and took a look at their FQA.

#1 You should check what "HSM" is, and will know the answer to your question :D. #2 KMS offers client-side encryptions. So if you don't trust AWS for whatever reason, you can choose to encrypt at client-side too. :D

Re: Effectively using AWS Reserved Instances

#57
post #18

Earlier quoted context omitted.

To be fair, AWS gives you bigger discounts for RI than GCP's sustained use. That makes sense; someone gotta pay for the risk. This said, GCPs committed use discounts still seem to be a better deal than convertible RIs. Looking at the run-of-the-mill 64GB RAM standard instance: AWS 1yr all upfront: $0.458 GCP commited use: $0.47878 AWS 1yr no upfront: $0.491 GCP sustained use: $0.532 AWS 1yr no upfront convertible: $0…

The customer takes all the risk. Reserving instances is a bad deal, that should be assimilated to gambling.

It's not a bad deal, companies purchase physical servers all the time which are around 3 year investments. Plus you can prorate your reserved instances to larger ones for only the difference in cost.

Re: Effectively using AWS Reserved Instances

#58
post #6

The best answer is of course not to at all. Burst into the cloud, static workloads in your own DC.

This is terrible advice for all but the largest of organizations. Running your own hardware is AWFUL. Get ready to dedicate an entire team to network engineering, fixing broken hard disks, patching operating systems, screwing around with RAID controllers, upgrading switches, planning power and cooling, and endless vendor negotiation -- with ISPs, hardware manufacturers, datacenter operators, etc. Oh, and did I mentio…

>This is terrible advice for all but the largest of organizations.

Don't start a conversation with an opening generalization like that if you want something constructive. Especially when the rest of your post is clearly based on the single anecdote of your experience.

>Running your own hardware is AWFUL.

Maybe for you. Not for any sysadmin with even just a couple of years of experience.

>patching operating systems

We're talking about instances, none of that sysadmin stuff goes away if you're on AWS. If you don't have patching management for operating systems on AWS then your instances are screwed. AWS instances don't eliminate the need for sysadmin work.

The only real difference is the hardware management. And if you read my post you would have seen that I said using aws for the on-demand flexibility is okay. All of the static workloads are what belongs down in your datacenter.

Netflix doesn't run 1/3 of the Internet traffic off of AWS, only a tiny subset because of the aforementioned shitty economics. The real workhorses are in custom netflix servers at peering points. Netflix would be bankrupt if they used AWS for video. Do some research before spreading free marketing propaganda.

This forum tends to only think in terms of explosive growth of traffic, which Also, your whole argument about non 'value-add' is bogus. That's the same excuse that management uses to outsource all development. Everything has a cost and provides some value to the company.

Re: Effectively using AWS Reserved Instances

#59

Google Cloud's pricing approach seems much more sane than each company having to spend all this effort juggling reserved instances.

It's not so much sane, as possibly a little more friendly to those who can't - or don't want to do capacity planning. Visibility in terms of outcomes means savings, or rather, variability means cost. Ultimately, you're going to bear the cost if you cannot provide visibility because Google is not likely ever going to do it as well as you can for your own business. Ultimately, if you knew exactly what you needed over t…

Disclosure: I work for Google Cloud.

> I think it would be nice to have Google's offer, but then also a longer term 'lock in' low price option as well, as frankly, this fits a lot of businesses.

We hear you. That's why we offer Committed Use Discounts [1]. Are you saying that a 3-year commitment to a specific price (or lower, as we do price cuts) is insufficient though? (I want to understand)

[1] https://cloud.google.com/compute/docs/instances/signing-up-c...

Re: Effectively using AWS Reserved Instances

#60
My experience with AWS reserved instances has not been very good previously.

1. Once you buy a reserved instance, you're locked in to that type and price for the duration, even though newer types at lower prices may get introduced (as they almost definitely would over 1-3 yrs).

2. If you're from outside the US, you might not be able to resell your reserved instance. So you're stuck with an old instance type at an inflated cost.

In contrast, Google Cloud just gives you a price equivalent to a reserved instance price (or better), based on hours of usage, without asking for an upfront commitment.

Post reply on HN