That should have been made more clear, sorry about that. On a per-second basis without a sustained use discount (so for burstier workloads, autoscaling, etc.) the E2 is ~31% cheaper (therefore the marketing "up to").
Clarifying your example: n1-std-2 is currently 9.5c/hour (which would be $69.35/month without Sustained-Use Discounting), but e2-std-2 is 6.7c/hr regardless of how many hours per month you use it. Which is about 30%.
What's the payoff for me? Paying less! Except that without sustained-use discounts, I'm not paying less. What strikes me as odd is that people getting the sustained-use discount are probably the people you'd want ton E2 instances. If someone is running a web server and ends up leaving you with a lot of idle CPU, that's really good for Google. That means that they're leaving a lot of unused space where you can schedule other VMs. At least to me, it seems like the people most likely to have empty space are the sustained-use people.
Who is likely to have the least unused space? The people paying by the second/hour. If I spin up a VM to do a video encoding task and then terminate it, I'm not leaving a lot of empty CPU that can be filled by other VMs.
That's why I find it so curious that there's no sustained-use discount for the E2 instances. People leaving relatively idle VMs running in a sustained way seems ideal for this kind of scheduling. Lots of companies are going to have workloads that, well, are less than efficient. For example, a task worker that gets around 6 tasks per hour and takes a minute per task. It's leaving around 90% of the requested CPU idle.
I guess the question is: why would anyone running with a sustained-use discount switch from an N1 instance to an E2 instance? The blog article sounds amazing: "we've found lots of CPU you aren't using that we re-use and pass the savings on to you!" Then it seems less fun: yea, you know how you're running a web server that's idle a lot? We'll re-use all that idle CPU, but you won't get a discount.
The weird thing is that Google is offering a ~30% discount for everything except sustained-use. You've noted the on-demand discount. A 1-year committed E2 price is 30% off the 1-year committed N1 price. The 3-year commitment is the same. So, it doesn't seem to be the case that Google found that there was a lot of idle CPU in on-demand VMs, but not in sustained-use VMs. It could certainly be that my expectation that long-running VMs would use less average CPU than short-running VMs is wrong, but Google isn't pricing it that way for the 1 and 3-year committed pricing.
Given that N2 instances lowered the sustained-use discount from 30% to 20% and the E2 instances have no sustained-use discount, it seems like Google is re-thinking whether it wants to offer sustained-use discounts. That's a pity to me. Sustained-use discounts drew me to Google Cloud over AWS. Google Cloud's offering said to me: "we get that a lot of people are using our VMs in a sustained way for long times and we'll automatically apply a discount for you without requiring you to sit in meetings determining how you want to allocate things." Committed-use discounts were great on top of that, but making sure that people didn't end up paying the on-demand price just because they didn't spend their time pre-allocating capacity was just such a consumer-friendly move and a key pricing differentiator with AWS.
It's also a bit odd that it means the committed-use discounts are so much higher over sustained-use. Like, I save ~10% by going with a 1-year commitment on an N1 and ~36% with a 3-year commitment (compared to just leaving them on). So, there isn't a huge benefit to going with a 1-year commitment on N1 instance (not that 10% can't be very beneficial). On the E2s, it's quite big - a ~37% discount for a 1-year commitment and a ~55% discount for 3-years. Frankly, those seem like AWS reserved-instance numbers and mean I'd really want to pre-allocate if I were going with E2 instances.
If the E2 instances got a 30% sustained-use discount like the N1 instances, Google could be undercutting AWS by around 50% for that use case. No pre-planning, no commitment, no meetings where people worry about buying something they won't use. Just half-price. It's basically the same savings you'd get if you did a 3-year commitment at AWS (with zero upfront), but without the pre-planning.
Instead, it makes me wonder if Google is really committed to the sustained-use discounts or if I'll have to start doing extra planning.
I see all these different prices being floated around but I'm still not clear on how much GCP's compute cost for the most popular scenario of running a website 24/7 would be.
It looks like AWS's t3.large may be the most comparable with 2x VCPU/8GB RAM which costs $426 for 12 months / $35.50 month.
Or for m5.large (2x VCPU/8GB RAM) the cost is $501 for 12 months / $41.75 month.
What would the n1-std-2 and e2-std-2 compute cost for 12 months be?
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?
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...
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...
E.g. n1 predefined machine bills $0.031611 / vCPU hour. Whereas a custom sized n1 machine is $0.033174 / vCPU hour
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)
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.
[1] https://cloud.google.com/products/calculator/#id=905f5722-5f...
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.
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...
Unless you specify what kind of site you run, and what traffic do you face, the use case is nebulous.
> 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?
AWS introduced the “Savings Plan” earlier this year that covers both EC2 instances and Fargate.
I spend nearly $10K/month on Google Compute Engine and get substantial committed use discounts, so these are very important questions for me.
We do expect it to be a good fit for folks doing web serving, and so on. I don't think it's a great fit for you, Bill :).
Hope that helps!