AMI (AWS) Weirdness

In general, we don't use the vendor-published AMIs. So, all of our tool-testing is done against our customized instances That said, our AMIs aren't exactly super custom — they exist mostly because things like FIPS-hardening and carving up the boot disk into STIG-compliant partitions isn't easily doable as an instance launch-time task.

At any rate, we had a new-hire onboard this week. As he was attempting to familiarize himself with some of our processes, he accidentally selected the Red Hat published AMI for RHEL 7. Since our tools make some (apparently) erroneous assumptions about instance starting-points he got some errors. The error he ran into was due to the fact that firewalld isn't installed in the Red Hat published AMI.

Given that firewalld is part of the @Core RPM group, (and prior to this week's errors) assuming its presence didn't seem like a bad bet. In looking at the Red Hat AMI it looks like firewalld is very-specifically excluded/removed. For whatever reason, the Red Hat team that builds the AMIs leaves both an anaconda.ks file in /root and the yum-history from before the source system was turned into an AMI. Both show firewalld being explicitly removed. So, my core question would be: "Why is firewalld explicitly removed?"

Of far lower importance — but still curiosity-piquing — would be the question, "why isn't the AMI's build-environment more-thoroughly 'cleaned up' prior to conversion to an AMI?" It seens kind of poor AMI hygiene to leave build-construction materials inside the AMI.