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.)