A Machine Catalog created with MCS has the following characteristics:
 
• A golden image is prepared and created based on a standard Windows instance, that has all desired software and customizations that an admin wants to make available in users’ virtual
desktops.
 
• The finalized Golden image is an instance transformed in an AMI via the Create Image procedure. And can be a private AMI (owned by the user or an AMI owned by someone else with
the appropriate access rights) or a public AMI.
 
• An administrator defines the configuration of the instances by choosing the EC2 instance type and network configuration for each catalog of instances.
 
• The administrator chooses how many instances need to be created and added to the machine catalog and defines a naming convention, such as “W2K12R2-MCS-###” (where ### will
automatically increment as 001, 002, etc.).
 
• Instances are based on the snapshot of the Golden Image. Each instance created has two – three disks assigned to it.
                • Master Image, A snapshot of the Golden Image. Depending on the machine type and delivery group type, this snapshot will be retained for persistent catalog types and
                  discarded upon shutdown for pooled or shared catalogs.
                • Personality disk, a small 1 GB Volume. This disk contains some basic information such as the machine name, SID, domain computer account password, and any other unique
                  info that needs to be injected into the OS on boot-up.
                • Personal vDisk (option) – This disk is used in cases where you want persistence in your instance (out of scope of this document).
 
• Personalization of each instance in the machine catalog is done automatically and there are no special requirements.

For a pooled or shared catalogs, changes should be discarded on shutdown.
MCS terminates the instances <EC2> and re-creates AWS machines as part of the power cycle. It does this in order to implement the pooled-VM reset behavior (where user changes to the base disk are intentionally discarded).
AWS does not offer any facilities for discarding user changes, which means that our only option is to completely terminate the VM and re-provision it. We do this routinely whenever an AWS MCS instance is powered on, unless it is a dedicated desktop machine.

Termination is not by itself a problem. The expected behavior is that a new replacement instance should be spawned on reboot. This replacement instance will have a new root EBS volume from the base disk AMI, but it will inherit the non-root identity volume <Personality disk> and the elastic network interfaces (ENIs) from the terminated instance. This means that the new instance will have the same AD identity and network properties as the original. For all intents and purposes, the replacement instance is “the same machine”.

During a reboot of pooled VM, you might see detach volume and delete volume in Cloud trail log on AWS. When the target instance is terminated, the only volume that should be deleted is the base disk volume (via the DeleteOnTermination mechanism).