Hacker News Reader

Comment by boulos | Hacker News Reader

Sorry for the lack of clarity (I've tilted at this windmill, and failed).

E2-std-2 != t3.large. A t3.large only has a "baseline performance" of 30% [1]. That's more like our e2-small though they have more memory.

Instead, I'd compare e2-std-2 to m5.large like you started to do so. An m5.large on-demand is $.096/hr => $70/month, while the e2-std-2 is $48/month. I think your $41.75/month is from the 1-yr Standard RI (a 40% discount). For that, the most direct comparison would be to use a Committed Use Discount on our side which comes with a similar percentage discount (I can't find this on my phone right now) so that's like $29/month.

Does that make sense?

[1] https://aws.amazon.com/ec2/instance-types/t3/

View on HN

As stated I'm only trying to get a comparison of the cost for the very popular use-case of running a "Website 24/7 for 12 months". I use this simple basic core metric as a baseline for comparing hosting costs amongst different hosting providers.

This is trivial to work out in AWS, I just go to their Reversed Pricing Page [2], look for the total cost for an m5.large (2x VCPU/8GB RAM) instance for 12 months which is $501 (12 x 41.75).

I'd like to be able to do the same for GCP, I see the committed usage page [2] but I don't see any easy way to work out the cost for 12 months / 24/7, it mentions things like "discount is up to 57% for most resources like machine types or GPUs", what does "up to" mean? Is that the discount for running 24/7? So is the E2-Std-2 monthly price of a $48.92 * (1 - .57) = $21.04?

All I see back in GCP's compute pricing page related to "committed usage" is "1 year commitment price" of "$10.03 / vCPU month" but this says it's for "E2 custom vCPUs and memory", does this apply to E2-Std-2 instances? So is the cost for 2x VCPU = $10.03 x 2 + 8GB = 8x $1.34 = 10.72 for the total monthly cost of $30.78?

If it's not how am I supposed to workout what E2-Std-2 cost of 12 months / 24/7 is? It's frustrating that there's no clear/easy way to determine the pricing of a simple and popular hosting scenario like this.

[1] https://aws.amazon.com/ec2/pricing/reserved-instances/pricin...

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

> This is trivial to work out in AWS, I just go to their Reversed Pricing Page [2], look for the total cost for an m5.large (2x VCPU/8GB RAM) instance for 12 months which is $501 (12 x 41.75).

Well, nowadays, you don't buy reserved instances; you buy compute savings plans. And be sure to compare the strengths and limitations of an EC2 Savings Plan versus a general Compute Savings Plan; they have differing characteristics concerning instance type convertibility, regional transfers, and applicable products.

And with Compute Savings plans, its not like an RI where you say "I'm paying for one instance upfront, give me 30% off". You instead commit to a level of spend, in Dollars per Hour. Then they convert that spend into fungible credits that have differing exchange rates depending on the instance type, region, and even compute product. Then, through the magic of the AWS Billing System, you save money.

Very rarely do you come out the other end of AWS Compute consumption with a good understanding of the exact trace of "dollar spent to which compute product?" With products like Fargate, its even worse. Don't get me started on Fargate and its billing characteristics.

I'm nitpicking here. But only because: Nothing is ever as simple as it seems. GCP is just different; I wouldn't classify it as more or less complex.

Isn't savings plans brand new? And can't you still just buy typical reserved instances?

Yes, and Yes. Though, as far as I know, there is no financial reason to buy RIs at this point. Check out this comparison table [1]; you get the same savings, but far more flexibility.

AWS very rarely removes features. People may still buy RIs because they have corporate or technical processes in place where they make sense. But, from a pure financial standpoint, RIs are inferior to Savings Plans.

[1] https://docs.aws.amazon.com/savingsplans/latest/userguide/wh...

You can just go to their calculator (which I find much better than the AWS one).

Here it is with the 1 year committed use: https://cloud.google.com/products/calculator/#id=79186cdb-18... ($30.82/month)

3 year committed use: https://cloud.google.com/products/calculator/#id=afd446fc-74... ($22.01/month)

And here without: https://cloud.google.com/products/calculator/#id=3ff5d861-75... ($48.92/month)

Have you tried the new Aws pricing calculator: https://calculator.aws/

«This is trivial to work out in AWS,»

Is it, really? Last time I checked, AWS charges separately for network traffic, so unless you know exactly how much traffic you will serve over the next 12 months, you can't know how much it will cost.

That's one of the reason I like simple VPS providers as the first 1-2 TB/month (typically) is free/included in the base instance price.

I assume the context was "as compared to Azure and GCP, which also charge for egress".

I agree that our tables are inconsistent for E2 (I sent an email about this internally, we'll try to get it fixed).

tl;dr: You did calculate it right. $10.3/vCPU/month x 2 vCPU + $1.34/GB/month x 8 GB for a 1-year commitment aka $30.78/month (and $22/month for a 3-year commitment). All of the predefined shapes are just "how many vCPUs times $/vCPU + how many GBs times $/GB".

Ignoring the lack of columns for commitment pricing in the predefined shapes tables (which some instance types have and some don't... grr), I want to explain the reasoning. One thing that's different for GCP vs AWS is that we actually don't have a SKU for e2-standard-2 or e2-standard-16. We instead do "Resource Based Pricing" [1], and there's only "E2 Instance Core" and "E2 Instance Ram" or whatever.

So if you have 100 e2-standard-2s and 100 e2-standard-16s running for a month, your bill will have two line items:

- 1800 vCPUs times 2.6M seconds of Predefined E2 vCPU

- 7200 GB times 2.6M seconds of Predefined E2 GB Memory

The price for E2 is apparently the same ($10.03/vCPU/month) for both Custom vCPUs as well as Predefined vCPUs [2] (meaning the price for your vCPUs is the same whether you make a custom E2 with 8 vCPUs and 29 GB of memory, or use an e2-standard-8 which has the same 8 vCPUs and 32 GB). Memory is the same (your $1.34/GB/month for a 1-year commitment).

Hope that makes sense. We'll try to improve the docs. Sorry.

[1] https://cloud.google.com/blog/products/gcp/announcing-resour...

[2] https://cloud.google.com/compute/all-pricing#e2_machine-type...

However n1 and other instance classes have different sku pricing for custom vs predefined pricing.

E.g. n1 predefined machine bills $0.031611 / vCPU hour. Whereas a custom sized n1 machine is $0.033174 / vCPU hour

This is also trivial to work out on GCP: their cost quote when creating a VM shows the discount, as well as the breakdown of what you're paying for. I'm not sure how much more trivial this could be. That's actually a great thing about GCP - their pricing and resource usage is front and center in the UX, you don't have to chase it down.

I'm trying to compare hosting costs across hosting providers, not at the creating VM's stage. I expected to be able to work out determine costs from their pricing page, which wasn't clear. But I've since been referred to GCP's pricing calculator which does make it easy, where 1x e2-standard-2 always running instance with a 12 month commitment will cost $30.82 /month ($369.84 total) [1].

[1] https://cloud.google.com/products/calculator/#id=905f5722-5f...

"Running a website 24/7" would fit something like a $10/mo instance on DO or Linode.

Unless you specify what kind of site you run, and what traffic do you face, the use case is nebulous.

OP didn’t mention scale. Not all websites can be run on a single VM/node. Many can though

> A t3.large only has a "baseline performance" of 30%

> Instead, I'd compare e2-std-2 to m5.large like you started to do so.

Yes, a "baseline performance" of 100% would more or less be an M-family instance, but with additional overhead to manage noisy neighbors etc. (and thus T-family is slightly more expensive for the same constant performance than M-family). T-family is specifically for non-constant workloads where CPU over-commit provides value, but without memory over-commit, which can result in highly-variable performance.

Neither T-family or M-family do "memory stealing" aka memory overcommit, like GCP's E2 seemingly does (but the pricing page doesn't explicitly state this, and your detailed comparisons omit this crucial difference).

So, apples and oranges; you shouldn't really "compare" without benchmarking ...

What is the "baseline" memory GCP E2 instances get?

Reply on news.ycombinator.com