7 ms·

Trying to find out how much cheaper these new E2 instances are, these are the Monthly prices taken from their Compute Pricing page [1]: Machine type VCPUs

by mythz 7y ago

Trying to find out how much cheaper these new E2 instances are, these are the Monthly prices taken from their Compute Pricing page [1]: Machine type VCPUs Memory Price Preemptible price n1-standard-2 2 7.5GB $48.55 $14.60 e2-standard-2 2 8GB $48.92 $14.67 So how does E2 offer "31% savings compared to N1"? Whatever it is, there seems to be some kind of disconnect as it's not obvious from their pricing pages and they should provide better transparency on exactly where these savings are. [1] https://cloud.google.com/compute/all-pricing https://cloud.google.com/compute/all-pricing

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...
  - 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.
fastest963 7y ago
The commitment price is way cheaper: $14.53795/vCPU for n1 vs $10.03/vCPU for e2.
- mythz 7y ago
  I'm not familiar with GCP, what's the difference between Price vs Preemptible price vs Commitment Price? and where did you get the Commitment Pricing from?
  - fastest963 7y ago
    You can see the Commitment pricing [1] and a Commitment is a block of vCPUs or RAM you can buy ahead of time and reserve for a year in return for a discount [2]. [1] https://cloud.google.com/compute/all-pricing#e2_machine-types https://cloud.google.com/compute/all-pricing#e2_machine-type... [2] https://cloud.google.com/compute/docs/instances/signing-up-committed-use-discounts https://cloud.google.com/compute/docs/instances/signing-up-c...
  - manigandham 7y ago
    GCP price = AWS on-demand GCP preemptible = AWS spot GCP commitment price = AWS reserved instances Rough comparison. GCP preemptible instances only live 24 hours max and have a set rate, no bidding. GCP commitments are based on CPU/RAM combinations rather than instances. GCP also has automatic sustained use discounts on the normal price if you run an instance > 80% of the month.
    - simpsond 7y ago
      Maybe a little off topic: AWS also has savings plans now, which gives a discount based on a commitment of hourly spend on compute. A bit easier to manage than RIs.
hgjbhujxgjbv 7y ago
I just dont see any of savings here. Let me give you a little list i have put together just to compare. This was put together in 5 minutes, just to get some price: $74.99 MSI B450M PRO-VDH Max $189.99 AMD Ryzen 5 3600 6-Core, 12-Thread Unlocked Desktop Processor with Wraith Stealth Cooler $38.99 Ballistix 2x8GB Sport LT DDR4-3200 CL16 $63.99 WD Blue 3D NAND 500GB Internal PC SSD - SATA III 6 Gb/s, M.2 2280, Up to 560 MB/s - WDS500G2B0B $48.99 Thermaltake Smart BX1 450W Bronze $59.99 SilverStone Technology Micro-ATX Glass Computer Case PS15B-G =$476,94 In 10 months you have a new server paid. You have huge gap to 2 years of guarantee for components to bring in networking costs and electricity. It just doesnt make sense to pay google for this.
- dna_polymerase 7y ago
  Sorry, but that comparison is just wrong. Can I shut that thing down if I don't need it, not having any cost? What about electricity, is there a backup in case there is a power outage? This is about cloud offer vs cloud offer and not a discussion about cloud vs self-hosting. Side-note: You probably want to go with ECC memory for your server build.
  - hgjbhujxgjbv 7y ago
    Add $100 for UPS. And as I said, 5 minute list. I dont really understand what you guys are doing but the price of self hosting is almost 3 times cheaper. It is crazy that you pay for that.
    - dna_polymerase 7y ago
      Of course, if you need only one machine the cloud is probably not for you. If however you can make use of all the hosted options (CloudSQL, Pub/Sub, ML, etc.) and need scalability (in terms of number of machines used) these services are actually useful. Example, say you run an online shop that has more demand in certain timeframes (like black-friday or December) you can easily scale your website by spinning up machines, which you can easily stop using after the demand flats out. With own hardware/colo/traditional web hosting you can't do that and holding like 10x hardware for short-term traffic spikes makes no sense.

by mythz 7y ago

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...
- 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.

fastest963 7y ago

The commitment price is way cheaper: $14.53795/vCPU for n1 vs $10.03/vCPU for e2.

mythz 7y ago
I'm not familiar with GCP, what's the difference between Price vs Preemptible price vs Commitment Price? and where did you get the Commitment Pricing from?
- fastest963 7y ago
  You can see the Commitment pricing [1] and a Commitment is a block of vCPUs or RAM you can buy ahead of time and reserve for a year in return for a discount [2]. [1] https://cloud.google.com/compute/all-pricing#e2_machine-types https://cloud.google.com/compute/all-pricing#e2_machine-type... [2] https://cloud.google.com/compute/docs/instances/signing-up-committed-use-discounts https://cloud.google.com/compute/docs/instances/signing-up-c...
- manigandham 7y ago
  GCP price = AWS on-demand GCP preemptible = AWS spot GCP commitment price = AWS reserved instances Rough comparison. GCP preemptible instances only live 24 hours max and have a set rate, no bidding. GCP commitments are based on CPU/RAM combinations rather than instances. GCP also has automatic sustained use discounts on the normal price if you run an instance > 80% of the month.
  - simpsond 7y ago
    Maybe a little off topic: AWS also has savings plans now, which gives a discount based on a commitment of hourly spend on compute. A bit easier to manage than RIs.

hgjbhujxgjbv 7y ago

I just dont see any of savings here. Let me give you a little list i have put together just to compare. This was put together in 5 minutes, just to get some price: $74.99 MSI B450M PRO-VDH Max $189.99 AMD Ryzen 5 3600 6-Core, 12-Thread Unlocked Desktop Processor with Wraith Stealth Cooler $38.99 Ballistix 2x8GB Sport LT DDR4-3200 CL16 $63.99 WD Blue 3D NAND 500GB Internal PC SSD - SATA III 6 Gb/s, M.2 2280, Up to 560 MB/s - WDS500G2B0B $48.99 Thermaltake Smart BX1 450W Bronze $59.99 SilverStone Technology Micro-ATX Glass Computer Case PS15B-G =$476,94 In 10 months you have a new server paid. You have huge gap to 2 years of guarantee for components to bring in networking costs and electricity. It just doesnt make sense to pay google for this.

dna_polymerase 7y ago
Sorry, but that comparison is just wrong. Can I shut that thing down if I don't need it, not having any cost? What about electricity, is there a backup in case there is a power outage? This is about cloud offer vs cloud offer and not a discussion about cloud vs self-hosting. Side-note: You probably want to go with ECC memory for your server build.
- hgjbhujxgjbv 7y ago
  Add $100 for UPS. And as I said, 5 minute list. I dont really understand what you guys are doing but the price of self hosting is almost 3 times cheaper. It is crazy that you pay for that.
  - dna_polymerase 7y ago
    Of course, if you need only one machine the cloud is probably not for you. If however you can make use of all the hosted options (CloudSQL, Pub/Sub, ML, etc.) and need scalability (in terms of number of machines used) these services are actually useful. Example, say you run an online shop that has more demand in certain timeframes (like black-friday or December) you can easily scale your website by spinning up machines, which you can easily stop using after the demand flats out. With own hardware/colo/traditional web hosting you can't do that and holding like 10x hardware for short-term traffic spikes makes no sense.