Live data from Hacker News

Effectively using AWS Reserved Instances

stripe.com

11–20 of 123 posts

Re: Effectively using AWS Reserved Instances

#11
post #5

Despite being a strong advocate for AWS, this is where I will say Google completely outshines Amazon. Google's approach to pricing is, "do it as efficiently and quickly as possible, and we'll make sure that's the cheapest option". AWS's approach is more, "help us do capacity planning and we'll let you get a price break for it.". Google applies bulk discounts after the fact, AWS makes you ask for them ahead of time.

Disclosure: I work on Google Cloud.

Thanks jedberg. You've definitely captured how we feel about it.

I will say that while our sustained use discount (SUD) works as you describe, our committed use discounts (CUD) are more similar to the AWS Flexible RIs. For some customers, even if it's obviously cheaper to use on-demand and just get the SUD benefit, they prefer the predictable "let me be sure I pay X" model.

As a note, even though CUDs and Flexible RIs are similar, I prefer ours (obviously). It's just a pile of cores and RAM in a region that you sign up to. That is easy enough to do in arrears that no ETL is necessary, and like you imagine: we want to automate this, too. We also don't play games with upfront payment or not, but most enterprises don't care.

Re: Effectively using AWS Reserved Instances

#12
post #5

Despite being a strong advocate for AWS, this is where I will say Google completely outshines Amazon. Google's approach to pricing is, "do it as efficiently and quickly as possible, and we'll make sure that's the cheapest option". AWS's approach is more, "help us do capacity planning and we'll let you get a price break for it.". Google applies bulk discounts after the fact, AWS makes you ask for them ahead of time.

I have to think AWS will get there eventually. But maybe not.

Either way, there is way more $$$ consulting for AWS than for GCP because of the expertise required to optimize costs.

Re: Effectively using AWS Reserved Instances

#13
post #7

I thought that payment processors are using their own hardware. How is AWS protecting their own customers' privacy? - can uncle Bob insert his fancy flash drive, copy my data, and sell it? Before you say it is encrypted - where does the encryption happen and doesn't AWS employees have access to the keys too?

AWS has different options for different companies/data. They even have options for US government data that are certified by DSS I believe, and they have options if you need PCI, HIPAA, and other types of compliance.

See: https://aws.amazon.com/compliance/hipaa-compliance/

https://aws.amazon.com/compliance/pci-dss-level-1-faqs/

Re: Effectively using AWS Reserved Instances

#14

> To automate this, we built an ETL process in SQL and Python that detects when we fall outside this band and automatically prepares a purchase for us to approve. @Stripe: Will this (or parts of it) be open sourced?

You can see a complete example in the accompanying Gist for this article: https://gist.github.com/lopopolo-stripe/e00b4bfa0839c125ed7a...

Re: Effectively using AWS Reserved Instances

#15
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 just to avoid the cost of migration.

RIs are a lock in.

Re: Effectively using AWS Reserved Instances

#16

> To automate this, we built an ETL process in SQL and Python that detects when we fall outside this band and automatically prepares a purchase for us to approve. @Stripe: Will this (or parts of it) be open sourced?

They published the code in a gist. It doesn't have a license, but since the python code is only 61 lines, would be trivial to rewrite yourself from their example.

https://gist.github.com/lopopolo-stripe/e00b4bfa0839c125ed7a...

Re: Effectively using AWS Reserved Instances

#17
post #7

I thought that payment processors are using their own hardware. How is AWS protecting their own customers' privacy? - can uncle Bob insert his fancy flash drive, copy my data, and sell it? Before you say it is encrypted - where does the encryption happen and doesn't AWS employees have access to the keys too?

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/

Re: Effectively using AWS Reserved Instances

#18
post #5

Despite being a strong advocate for AWS, this is where I will say Google completely outshines Amazon. Google's approach to pricing is, "do it as efficiently and quickly as possible, and we'll make sure that's the cheapest option". AWS's approach is more, "help us do capacity planning and we'll let you get a price break for it.". Google applies bulk discounts after the fact, AWS makes you ask for them ahead of time.

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.564
edit: confused commited vs sustained use for a second there

Re: Effectively using AWS Reserved Instances

#19

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…

It's not a total lock-in as if you get convertible instances you can change the underlying instance type.

Re: Effectively using AWS Reserved Instances

#20
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 mention, throw elasticity out the window -- all of this has to be planned in advance, and purchased, and installed, months ahead of when it will be operable. So forget the ease and convenience of just spinning up more capacity.

Also, there's a massive distraction of having to focus management attention on this non-value-adding part of the business, all so that you can shave down some cost, rather than investing in growing revenue.

Having been in this position firsthand, don't do this. If netflix can run 1/3 of Internet traffic off of AWS, I guarantee they're much larger than you, and it should say something, that they'd rather outsource this part of their business than dealing with all this crap.

Focus on software and product/market fit. It's just a much, much, much better use of expensive technical people, that will be done on day 1, without any risk, hassle, or complexity, than trying to replicate something someone else already does for you, much better and at competitive costs, than trying to reinvent all of this yourself.

To be honest, I don't even want to deal with EC2 anymore; I'd rather just use a PaaS.

Post reply on HN