Introducing E2, new cost-optimized general purpose VMs for Google Compute Engine

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?

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.

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?

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.

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)

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.

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.

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?

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.

CPU hotplug has been supported for a long time. I once managed some Sun boxes that allowed replacing/upgrading CPUs without shutting down... They don't build em like that anymore.

It’s a lot easier and safer to scale hosts horizontally than vertically. You can predict the limits and behavior of each host, the VMs/processes on each host don’t need to deal with fundamental resources changing, etc. For services I own that are high availability, require GC tuning, etc., these hosts with dynamic resource adjustments (also T2/T3 in AWS) are a nightmare because the behavior can change at runtime under load, exactly when I want it to behave predictably.

> I mean how would linux behave when you add/remove cores and RAM f.ex.?

This is already possible on ESXi with Linux guests for years now, so it’s certainly a solved problem in some capacity.

You can still get migrated with a local ssd:

"Compute Engine can also live migrate instances with local SSDs attached, moving the VMs along with their local SSD to a new machine in advance of any planned maintenance." [1]

[1] https://cloud.google.com/compute/docs/instances/live-migrati...

I wish it was simply flat 30% cheaper. It is very misleading that 0.99% of month will be 30% cheaper than a full month, considering that Google Cloud is advertising sustained usage discounts everywhere.

Yeah, but I could just unload that balloon driver and get to keep all my ram all the time while still paying 30% less?

Ah, I've been assuming that a vCPU == a CPU hyperthread since forever, hadn't realized that changed.

It seems that Policy Documents only work for uploads but I'm talking about downloads.

Replying to myself again: So you will NOT get two physical cores, both HyperThreads will be on the same physical core so no real benefits to having these smaller shared instances give you "2 cores"?

See my comments for feedback from AWS engineer. I'm guessing since both AWS and GCE run the same hypervisor now that GCE will have the same "feature"?

4 socket boards (or 8) make a lot more sense than those abominations, though. Two entirely separate CPUs in one package for a vastly increased price...

Support for arm is not as pervasive as x86, if you are using docker you need to be mindful of the base images

Optionality, choice, ultimately the freedom.

For one thing, everyone is painfully aware of Intel's monopoly pricing a few years ago before AMD came back to life. To prevent this, 3 supplier of CPUs seems minimal, so there can be dynamism of check and balance. (2 is insufficient, as seen from Intel vs. AMD)

It doesn't, that's what's great about it. But ARM equipment is generally better value than x86 and I would expect Google to offer it as a more affordable target config (like AWS does).

One advantage of Amazon's ARM is that it doesn't do hyperthreading, so when you rent a "thread" you actually get a full core rather than half a core.

If other people want to run on ARM, then I need to test my code on ARM, so that's why I want it.

> Still no live VM migrations?

Based on what evidence? Statements from Google that AWS doesn't do live migration?

MySQL 8, for starters.