Hi, author here. The reason I chose the n2-standard-2 over the n1-standard-2 was because the N1 instance in question has only 7.5GB of memory rather than 8GB.

Hi, author here. The reason I chose the n2-standard-2 over the n1-standard-2 was because the N1 instance in question has only 7.5GB of memory rather than 8GB. I let OVH slip on this one because they didn't have any other instances in the same ballpark but Google did. One of the eggs you have to crack when doing such a comparison I'm afraid. With respect to the discussion of what really is a fair comparison to 1 unit of Google's proprietary vCPU units: that is of course open to speculation. One of the tremendous problems of cloud computing pricing is that the big three suppliers like to a) take a proprietary unit like "vCPU" which is not in common parlance and b) then repeatedly quote the cost for it in a tiny unit like hours. An n2-standard-4 is 0.0517 USD per hour - great. And let me really get the boot in: I hate that google's pricing page continuously defaults to the this useless unit on every page load. That company is probably the largest producer of web cookies worldwide but to remember that one, essential, UI slider was too much apparently. I broadly file this under the objection of "This is a naive navigation of the pricing schemes of $BIG_TECH" that I cover in the article Transfer pricing is a real issue and arguably where $BIG_TECH really come and rip your face off. Egress bandwidth is priced at an unreal level precisely because people like me doing comparisons forget about it. In this respect $BIG_TECH are like the chinese restaurants where the dish is £5 but a 250ml bottle of coke to go with it is £6. I should have included it and if I did the comparison again I would model a small defined application rather than a small specific spec size. Mea culpa. I still think the view I express in the article is right: $BIG_TECH cost a chunk more.