I thought the use case for things like Lambda were more along the lines of rarely used web requests that you'd save money on by not running a full box. I do remember them being slow too.
In my case we use lambda to perform ETL based on S3 events, so when a file drops into S3, Lambda is invoked to process it.
That works very well for us and is cheaper than running a box 24x7, as the file drops arrive sprodically throughout the day and Lambda can scale to meet the demand.
If your job is easily parallelizable then you can run multiple lambdas in parallel. For the above use case they probably should have kicked off one lambda per prefix or similar.
We considered it, but at the time we just felt implementing map/reduce over Lambda would just introduce a more complex architecture for such a simple problem.
Maybe the recently introduced SQS->Lambda support might make it a bit cleaner, but in the end we opted for EC2.
In my case we use lambda to perform ETL based on S3 events, so when a file drops into S3, Lambda is invoked to process it.
That works very well for us and is cheaper than running a box 24x7, as the file drops arrive sprodically throughout the day and Lambda can scale to meet the demand.