We had the same problem with getting priced out of c3.8xlarge in Virginia. We fixed it by changing our allocation algorithm to find alternate instance types and zones. For example, instead of 1 c3.8xlarge, it might pick 2 c3.4xlarge instances or a cc2.8xlarge. Seems to work so far.
I looked through the pricing table and played with the calculator, it seems something equivalent to our needs would cost around a third more on google but each cpu would have twice as much ram. Not worth it for us.
For people coming from AWS, we currently don't have an instance shape that lines up with the c3/c4 ratio (pushing you either to our n1-standards or n1-highcpu-. Can you get by with less memory?
Note: we're very aware of this pain point, and maybe you'll see something soon ;).
We need maybe 1GB for each job, but we need some leeway to avoid the OOM killer when a group of work units is larger. Swapping takes so long that it's not cost effective.
But to be honest about the situation, the cost would have to be much lower to make it worthwhile for me to rewrite our scheduler on Google's API.
I looked through the pricing table and played with the calculator, it seems something equivalent to our needs would cost around a third more on google but each cpu would have twice as much ram. Not worth it for us.