Migration from Mongo to Dynamodb require application modification, right? So why D, not C.
D is preferred over just a lift-and-shift option in C due to the statement in the third paragraph, where they are looking for long-term cost and manageability improvement and are ok with modifications. Option C would not provide any significant manageability improvements as they would just be running the servers on someone elses platform.
C would provide manageability and cost improvements, as running VMware on AWS takes less management overhead than running it on AWS. It is also less cost when you factor in datacenter costs, power, refresh cycles.
I could second the decision if there was an option that says "let’s lift-and-shift and after this let’s evaluate how to migrate to DynamoDB". The suggested strategy to do this in one step I personally would consider as big architectural and management mistake.
Migration like this can take a year in the real world. And during the migration period new features development will be frozen or significantly slowed down. But cloud architects aren’t developers, so do they need to think about so such minor restrictions?.. Let’s use DynamoDB, even though it is absolutely incompatible with Mongo!