I am in a similar situation as Brian. Having the exact build process for the CentOS AMIs would allow us to not only replicate the process but also verify the origin state for all images which use the base image as a starting point.
Using Packer, we have a relatively streamlined build process for Vagrant, Openstack, XenServer, QEMU, Docker, and VirtualBox We're able to use a standardized kickstart to build all of our base images. We've built a blue printing tool that calculates the state of a running machine. We use the output of this, in conjunction with the kickstart file, Packer configurations, and install media to create a release artifact.
With both Openstack and AWS, instead of using kickstart to create the image, we start with a image and make modifications to this image. However in the case of Openstack, we are able to build a QEMU image first, then upload that to Openstack. This allows us to continue to pair the kickstart with the release, which is very helpful for ensuring completeness when replicating builds in other environments.
While there are other options we have pursued to achieve the ensure the known state of an AMI, in the epistemological sense, having the build process used and approved by CentOS would be immensely helpful. Our preference is to begin with an official CentOS release, whether it be an ISO or an AMI in this case. However the AMI is not only behind in releases, requiring a more intensive update, but is also not as transparent as the minimal 1503 release ISO.
Finally, in regards to the EULA, there is no seamless way to accept the EULA, that I havbe found, without logging in through the web portal. This is a small issue but generally more disruptive than desired for unattended build systems.
Hopefully this adds a little more insight into how some of us are consuming the AMI's and perhaps some of the issues currently presented when trying to achieve parity across the releases.
Joseph F. Reynolds