The most important function of Docker is dependency management (allowing you to pack your own runtime with your apps with consummate ease), followed by standardising image distribution and deployment across environments.
A Docker image is not a VM image - it doesn't have a kernel, for starters, and is not designed to be booted in the usual sense (i.e., kernel+init+scripts) - it just has a Linux userland (often quite restricted) and will run _a single process_ by design[1].
Also, AWS and Google Cloud already allow you to run Docker images (on EC2 Container Service and Kubernetes).
Cloud providers won't accept existing VM images in the sense that large-scale hypervisor platforms usually use different formats and they don't need the hassle involved in building and supporting VM conversion services.
It's pointless to have those as a service when anyone can grab Packer or a similar tool and convert a .vbox/.vmdk to an AWS AMI or an Azure Hyper-V image - and support the resulting images themselves (which is another reason why providers make a clear distinction between certified/tested images and third-party ones).
[1]: of course you can launch supervisord and a bunch of stuff underneath it, but if you're doing that, you're doing it wrong.