On the question of Lambda vs. EC2, EC2 instances take much longer to start. So depending on the job, to get the performance you can get with a "burst parallel" flock of Lambda workers, you would need to keep a warm cluster of EC2 instances ready to take your job. At which point, the cost comparison depends on how often you have work to execute. EC2 is cheaper if you have a 100% duty cycle (but you probably don't).

The gg tool, though, is mostly agnostic to the backend -- you can take a job that's expressed in gg IR (e.g., "compile this program") and then execute it with any of the gg back-ends. We have one for Lambda and one for a cluster of warm VMs. The performance of gg-to-EC2 is generally better than outsourcing methods that leave your laptop in the driver's seat (e.g. bazel-to-icecc) and give less semantic information about data- and control-flow of the job to the remote execution engine. (E.g. in Figure 9, you can see that gg-on-EC2 is much faster than icecc-on-EC2 for compiling GIMP and Inkscape.)

At least a low-performing one -- it gets harder if you want to use (a) persistent workers [instead of invoking a new platform worker for every "thunk"] and (b) direct inter-worker networking [instead of putting every intermediate result in a storage medium].

or

https://en.wikipedia.org/wiki/Gustafson%27s_law

Basically there are parts of every workload that needs to be run sequentially, there will be a point where running more smaller functions will be less efficient than running one large function.