With CentOS 7 AMIs only being available in the Marketplace, all resulting EC2 instances have the Marketplace codes attached to the EBS volumes. A significant restriction of this is that a resulting image cannot be the non-primary volume of an instance unless it is powered down. This presents itself to be a problem in at least the following scenarios:
- Unable to attach a CentOS 7 boot volume to another instance for repair without either creating a temporary instance or shutting down an existing one. For example, if you messed up the /etc/sudoers file and logged out, and wanted to repair, you would not be able to repair by mounting to another instance and editing the file without incurring additional (albeit small) cost, or having an existing instance be temporarily unavailable.
- The "amazon-chroot" Packer Builder (https://www.packer.io/docs/builders/amazon-chroot.html) does not work because it starts by mounting a copy of the snapshot tied to the AMI as part of a scripted operation and therefore cannot power off to do so
Custom AMIs, snapshots, copied EBS volumes, etc, all have the marketplace codes copied to them and inherit the restrictions. If an org was to use these features for automating environments and was disconnected from the original Marketplace agreement, they may be unaware of this limitation.
I would also appreciate being able to have the additional transparency of seeing how an AWS AMI is created as the docker/openstack/etc images from the repository referenced above. This would be useful in environments with regulatory compliance concerns, such as AWS GovCloud, HIPAA, FedRAMP, etc.
I understand the benefit that Marketplace registrations allow for the ability to notify users of any changes, and I am not necessarily advocating for switching away from the Marketplace as the primary AMI location. I would like to be provided the opportunity to build a private AMI in the exact same procedure as the official image so as to avert the restrictions provided by the Marketplace.