I wouldn't assume that VM migration does not exist in AWS. The overall design and implementation of Google's infrastructure somewhat mandated the development live migration support from day one. AWS was designed and built differently, and some types of events that force live migration in GCE do not exist in AWS.
One specific example from Google's VM Live Migration At Scale paper [1] is "Regular maintenance on the power infrastructure in our data centers requires powering down subsets of machines for extended periods of time". The power infrastructure at AWS is designed to be redundant and concurrently maintainable, which removes a significant need for workload mobility within the datacenter.
Personally, I think it was a very good idea to turn the thing that had to be built to launch into a marketed differentiated feature. But that doesn't mean that AWS doesn't have an ability to live migrate some workloads if it is able to do so without disrupting customers, or if it delivers a better experience than alternatives (e.g., instance degrade notices).
VM Migration is only for maintenance on GCP -- and customers can't control it, just Google.
AWS can hot patch live systems in place without any downtime, so, that's better than a migration (which has a brown out / maintenance period)
AWS's non-bare-metal systems can boot in ~10s with enough tuning.
Their bare-metal systems take tens of minutes to boot.
Nested virtualization would allow scaling up and starting new nodes much faster.
Even when you offer bare metal, it’s actually still nice to have nested virt! Otherwise, every node has to be a full sized host. So when you have a K8s cluster or similar with a pile of nodes and want to allow some teams to use it (e.g., Android emulator, firecracker, whatever), it’s really nice not to have to say “okay, this group requires full bare metal hosts that they manage themselves”.
tl;dr: nested virt is still a nice to have so that all your infrastructure looks the same.
Edit: Also, you can trigger migration yourself if you want (gcloud compute instances simulate-maintenance-event), but that's mostly to convince yourself that nothing bad will happen.
A few people were noting that SimpleDB has been deprecated, it's not listed in the AWS web console, you can't find docs for it anymore, but if you have a running instance, your service API calls still work. And I think there have been many deprecation warnings since, plus migration messages. But they don't want to break existing clients.
I'm guessing this is a similar case where they want to be really, really sure that it's worth offering the service.
Here are the docs: https://aws.amazon.com/simpledb/