I suspect cold-start performance of arbitrary Docker containers would be intolerable for most customers in light of the sizes and number of layers of many of the images seen in the wild. Most people aren't building "FROM scratch" images yet, if they ever will. Single binaries, or scripting languages with well-defined runtime environments, are far easier to meet customer-demanded SLOs when building a serverless platform.

(Disclaimer: I work for AWS, but this is strictly my personal opinion/observation.)

Docker isn't a runtime, its a packaging technology. The Runtime API is a simple standard interface that will allow you to run even Docker containers if you so desired.

Docker doesn’t let you take the union of separately-authored base images together as a runtime image for your app. Lambda (apparently) does.

That’s the only major difference I can see, though. The rest is convention/standardization on what’s put into the image (an executable that speaks HTTP over its stdio; separately-namespaced projects under /opt rather than use of the global namespace; etc.)

I think over time Lambda and Fargate[1] will get closer and closer to each other in terms of functionality and deployment speed.

1. https://aws.amazon.com/blogs/aws/aws-fargate/

Yes, it's strange they didn't do this. Azure and GCP are headed that way, and there are smaller vendors doing the same thing.

Per-event invocation of a docker container instead of a specific bundle of code seems much more flexible, especially with the Firecracker tech they announced.

https://aws.amazon.com/ecs/ They don't tend to miss an opportunity.

They said they didn't do this for security reasons, they wanted hardware virtualisation to separate Lambdas - not container separation.

That’s what Fargate is.