If your spark jobs are mostly batch workloads, that can tolerate moderately infrequent failures and restarts, try using google dataproc with preemptible vms or amazon emr using spot instances.
Depending on your use case, you might spend many times less than you would using regular VMs. Many instances that are several dollars an hour on AWS can be used for a fraction of the price.
Its also fairly easy to automate the region selection and bid (on AWS that is, not sure about gcloud).
If you need streaming, obviously this might not be the way to go.
It is, but you can run the bare minimum number of core nodes (3 I think?) and use spot instances for any others.
At a previous job, we just built our own ec2 image that ran spark in standalone mode for ephemeral spark clusters, and it was wonderful and cheap. And the clusters launched very fast compared to EMR.
So I've been knee deep in glue for the past month. Great service but we really need more examples and an easier dev flow. I wasn't able to get consistent results between juypter and dev endpoint as i was with the glue running the script directly. So i spent a lot of wasted time waiting for glue to run my job that eventually failed and then getting a less than helpful error message. Now that i have my jobs running and orchestrated with step functions it's a thing of beauty but should have taken 1/10 of the time if i had good examples and a proper environment.
We're using Spark on EMR with Data Pipeline to do ETL and to run Scheduled Jobs. Data pipelines terminates the cluster once ETL or job gets completed, helps us a lot to save cost.
Depending on your use case, you might spend many times less than you would using regular VMs. Many instances that are several dollars an hour on AWS can be used for a fraction of the price.
Its also fairly easy to automate the region selection and bid (on AWS that is, not sure about gcloud).
If you need streaming, obviously this might not be the way to go.