7 ms·

Disclosure: I work on Google Cloud. That should have been made more clear, sorry about that. On a per-second basis without a sustained use discount (so for bur

by boulos 7y ago

Disclosure: I work on Google Cloud. 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%.

mythz 7y ago
I'm not a fan of manual inefficiencies of AWS's Reserved Pricing but at least their pricing is clear. 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?
- boulos 7y ago
  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/ https://aws.amazon.com/ec2/instance-types/t3/
  - mythz 7y ago
    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/pricing/ https://aws.amazon.com/ec2/pricing/reserved-instances/pricin... [2] https://cloud.google.com/compute/docs/instances/signing-up-committed-use-discounts https://cloud.google.com/compute/docs/instances/signing-up-c...
    - boulos 7y ago
      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-resource-based-pricing-for-google-compute-engine https://cloud.google.com/blog/products/gcp/announcing-resour... [2] https://cloud.google.com/compute/all-pricing#e2_machine-types https://cloud.google.com/compute/all-pricing#e2_machine-type...
      - cobookman 7y ago
        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
    - nl 7y ago
      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-1828-410c-93f2-271386db67dd https://cloud.google.com/products/calculator/#id=79186cdb-18... ($30.82/month) 3 year committed use: https://cloud.google.com/products/calculator/#id=afd446fc-7485-4518-8b6b-ae363b204da3 https://cloud.google.com/products/calculator/#id=afd446fc-74... ($22.01/month) And here without: https://cloud.google.com/products/calculator/#id=3ff5d861-7557-4d20-885c-03610d3eb0f0 https://cloud.google.com/products/calculator/#id=3ff5d861-75... ($48.92/month)
  - ti_ranger 7y ago
    > 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?
- scarface74 7y ago
  I'm not a fan of manual inefficiencies of AWS's Reserved Pricing but at least their pricing is clear. AWS introduced the “Savings Plan” earlier this year that covers both EC2 instances and Fargate. https://aws.amazon.com/savingsplans/ https://aws.amazon.com/savingsplans/
- marfelipe 7y ago
  This is why a Cloud Management Platform is needed to control idle resource warnings, cost tracking / allocation. See more on www.4matt.com.br
williamstein 7y ago
So is the main point of these new E2 instances to provide VM's for users who do NOT benefit from sustained use discounts? Does "general purpose VMs" basically mean "VMs that do not benefit from sustained use discounts?" I'm confused because the article itself says "For all but the most demanding workloads, we expect E2 to deliver similar performance to N1, at a significantly lower cost." So the article is claiming that the whole point is to save money if you do not need big memory or CPU (what I want!). However, what you write above and the prices seem to say that the whole point is save money if you do not benefit from sustained use discounts, which is a totally different thing. Help! I spend nearly $10K/month on Google Compute Engine and get substantial committed use discounts, so these are very important questions for me.
- fastest963 7y ago
  As I mentioned below, they also have significant savings on the commitment pricing. So if you're spending 10k/month and keeping around the same instances every month (which it seems like you are based on getting commited-use discounts) then you can save additional money by buying commitments of e2 instances.
- boulos 7y ago
  "most demanding" here refers to things like "I want to be sure I'm on a Cascade Lake" or "I want a 3.x GHz processor" or "I want a 96-vCPU instance with hundreds of GBs of memory". 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 :).
YawningAngel 7y ago
Since you're here: We currently have a lot of workloads running on N1 machines, which seem comparable cost-wise to E2. Are we likely to see performance improvements shifting to E2, or is the only concern with N1 the fact that it's a previous generation and will presumably suffer limited availability at some point?
- boulos 7y ago
  The opposite. If you're okay with your current N1 perf, and can use small instances (up to 16 vCpus), you can probably save up to 30% by moving to E2. If you want a perf boost, you can move from N1 to either N2 or the speedy C2. Hope that helps!
JMTQp8lwXL 7y ago
I'm never a fan of "up to" marketing discounts, since they almost never apply to me. Clothing goes on sale at a store, "up to" 40%? It's never the garment I was looking at. That one barely moved in price. In this case, I typically run long-lived processes (servers accepting network requests), so not much of a savings here.
merb 7y ago
well from the blog it looked way more dynamic. i.e I tought that e2 is some way of over commitment, where I pay less when I do not use my full power. i.e. we use 3x n1-std2 with sustained use discount but we basically do not use any power over night. i.e. at night we use ~25% of memory and cpu. it's sad that it's not a cost saving for us. (i mean it's also impossible to sell/trade our sustained-use discount (switch from n1-2 to e2)
boulos 7y ago
And I'm past the Edit window, but for 24x7 workloads you can also use a 1-year or 3-year Committed Use Discount to save ~31% as well for E2 vs N1. The pricing matches for 24x7 w/o a commitment but is otherwise strictly better.
mdasen 7y ago
From what I understand about the E2 instances, the point is that there's often a lot of idle CPU cores compared to the vCPUs that have been allocated by users. That observation in combination with live-migration and larger host machines, it becomes possible to over-sell CPU cores in a way that users won't notice except in tiny ways in around 1 in 100 or 1,000 occasions. That makes great sense. Larger instances mean that you'll be more likely to handle spikes and live-migration means that you can balance people who are actually using the CPU a lot. 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.

by boulos 7y ago

mythz 7y ago

I'm not a fan of manual inefficiencies of AWS's Reserved Pricing but at least their pricing is clear. 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?

boulos 7y ago
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/ https://aws.amazon.com/ec2/instance-types/t3/
- mythz 7y ago
  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/pricing/ https://aws.amazon.com/ec2/pricing/reserved-instances/pricin... [2] https://cloud.google.com/compute/docs/instances/signing-up-committed-use-discounts https://cloud.google.com/compute/docs/instances/signing-up-c...
  - boulos 7y ago
    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-resource-based-pricing-for-google-compute-engine https://cloud.google.com/blog/products/gcp/announcing-resour... [2] https://cloud.google.com/compute/all-pricing#e2_machine-types https://cloud.google.com/compute/all-pricing#e2_machine-type...
    - cobookman 7y ago
      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
  - nl 7y ago
    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-1828-410c-93f2-271386db67dd https://cloud.google.com/products/calculator/#id=79186cdb-18... ($30.82/month) 3 year committed use: https://cloud.google.com/products/calculator/#id=afd446fc-7485-4518-8b6b-ae363b204da3 https://cloud.google.com/products/calculator/#id=afd446fc-74... ($22.01/month) And here without: https://cloud.google.com/products/calculator/#id=3ff5d861-7557-4d20-885c-03610d3eb0f0 https://cloud.google.com/products/calculator/#id=3ff5d861-75... ($48.92/month)
- ti_ranger 7y ago
  > 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?
scarface74 7y ago
I'm not a fan of manual inefficiencies of AWS's Reserved Pricing but at least their pricing is clear. AWS introduced the “Savings Plan” earlier this year that covers both EC2 instances and Fargate. https://aws.amazon.com/savingsplans/ https://aws.amazon.com/savingsplans/
marfelipe 7y ago
This is why a Cloud Management Platform is needed to control idle resource warnings, cost tracking / allocation. See more on www.4matt.com.br

williamstein 7y ago

So is the main point of these new E2 instances to provide VM's for users who do NOT benefit from sustained use discounts? Does "general purpose VMs" basically mean "VMs that do not benefit from sustained use discounts?" I'm confused because the article itself says "For all but the most demanding workloads, we expect E2 to deliver similar performance to N1, at a significantly lower cost." So the article is claiming that the whole point is to save money if you do not need big memory or CPU (what I want!). However, what you write above and the prices seem to say that the whole point is save money if you do not benefit from sustained use discounts, which is a totally different thing. Help! I spend nearly $10K/month on Google Compute Engine and get substantial committed use discounts, so these are very important questions for me.

fastest963 7y ago
As I mentioned below, they also have significant savings on the commitment pricing. So if you're spending 10k/month and keeping around the same instances every month (which it seems like you are based on getting commited-use discounts) then you can save additional money by buying commitments of e2 instances.
boulos 7y ago
"most demanding" here refers to things like "I want to be sure I'm on a Cascade Lake" or "I want a 3.x GHz processor" or "I want a 96-vCPU instance with hundreds of GBs of memory". 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 :).

YawningAngel 7y ago

Since you're here: We currently have a lot of workloads running on N1 machines, which seem comparable cost-wise to E2. Are we likely to see performance improvements shifting to E2, or is the only concern with N1 the fact that it's a previous generation and will presumably suffer limited availability at some point?

boulos 7y ago
The opposite. If you're okay with your current N1 perf, and can use small instances (up to 16 vCpus), you can probably save up to 30% by moving to E2. If you want a perf boost, you can move from N1 to either N2 or the speedy C2. Hope that helps!

JMTQp8lwXL 7y ago

I'm never a fan of "up to" marketing discounts, since they almost never apply to me. Clothing goes on sale at a store, "up to" 40%? It's never the garment I was looking at. That one barely moved in price. In this case, I typically run long-lived processes (servers accepting network requests), so not much of a savings here.

merb 7y ago

well from the blog it looked way more dynamic. i.e I tought that e2 is some way of over commitment, where I pay less when I do not use my full power. i.e. we use 3x n1-std2 with sustained use discount but we basically do not use any power over night. i.e. at night we use ~25% of memory and cpu. it's sad that it's not a cost saving for us. (i mean it's also impossible to sell/trade our sustained-use discount (switch from n1-2 to e2)

boulos 7y ago

And I'm past the Edit window, but for 24x7 workloads you can also use a 1-year or 3-year Committed Use Discount to save ~31% as well for E2 vs N1. The pricing matches for 24x7 w/o a commitment but is otherwise strictly better.

mdasen 7y ago

From what I understand about the E2 instances, the point is that there's often a lot of idle CPU cores compared to the vCPUs that have been allocated by users. That observation in combination with live-migration and larger host machines, it becomes possible to over-sell CPU cores in a way that users won't notice except in tiny ways in around 1 in 100 or 1,000 occasions. That makes great sense. Larger instances mean that you'll be more likely to handle spikes and live-migration means that you can balance people who are actually using the CPU a lot. 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.