In most of my environments, it's usually a kickstart and post-install script to get the main system up and current with updates at that moment. I'll usually have a local repo that syncs with a CentOS mirror daily or weekly. I tend to freeze the kernel package at whatever's current as of the installation time and update packages individually or as necessary. Often times, my servers have peripherals that have drivers closely linked to kernel versions, so that's a consideration.
CentOS 5 has matured to the point where constant updates aren't necessary. But also keep in mind that CentOS 5 is winding down. The rate of updates has slowed somewhat, and the nature of the updates is more inline with bugfixes and less about major functionality changes.
So in this specific case, the first thing you could do is build a local mirror/repo. Use your existing configuration management to control access to third-party repos. Maybe schedule policy to yum update critical or public-facing services (ssh, http, ftp, dovecot, etc.) Everything else will require testing, but I get the feeling that most environments don't run with fully-updated/patched systems.
First off, to be clear, no Elastic Beanstalk is not PaaS in the way you are thinking about it. If you break it into pieces, it's really more like having virtualized instance templates and application deployment automation like puppet or chef. Along with this you get automated access to awe's load balancer service, and cloud watch monitoring, that allows you to startup new application servers or shutdown existing ones based on metrics.
What makes it feel like PaaS is that the main selling point is the application deployment system that takes your code and copies it to all the application servers in your cluster.
One of the complaints some people have about PaaS is that the PaaS vendor makes decisions for you about the application environment. This seems to me like the value proposition of PaaS: as a customer you get to concentrate on the application functionality and leave all the other details to the PaaS vendor. You're paying for someone else to manage the infrastructure and provide system administration. For that simplicity you're paying them a premium, as in the case of Heroku, which is running their infrastructure on top of ec2 as well, only in a way that's transparent to you.
Amazon is really offering Elastic Beanstalk on top of Ec2 and their REST api's, and not making much of an effort to hide that from you. This is because they are making their money via IaaS, and EB is just orchestrating the setup of a group of ec2 resources you could setup yourself, given the time and know how.
Now, in terms of the specifics of an AMI, again AMI's are one of the many ec2 pieces that are employed to facilitate EB. There is nothing magical about an EB AMI - it's just an Amazon linux ami preconfigured to work with EB. Like any other AMI you can start it up in EC2, tweak it, and derive a new customized AMI from your running instance. Amazon Linux is basically a cross between Centos and Fedora, with paravirtualization patches, and pre-configured yum repos maintained by Amazon.
As you probably know, Amazon linux is already configured to install security patches at boot time. However, running instances are no different than any other server in regards to patching. Patching may interrupt service. If you're extremely concerned about security patching, you can always use a container command and setup cron to run yum update --security at some periodicity.
You also can utilize the EB API to alter the EB configuration, or automate the creation of a new EB environment, you can then swap to it once it's up and ready, followed by shutting down the old one. This is described here: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html
Like the rest of AWS, there is a way to programmatically access and control every non SaaS feature, so there's nothing stopping you from creating patched AMI's, which are then used to create new EB environments, and rolling those out. EB isn't going to force configuration specifics on you, nor is it providing you a system administration group to maintain the infrastructure.
Best Answer
If you absolutely want to use
yum security plugin, there is a way to do this, although a little elaborate. But once you have it setup, it's all automated.The only requirement is that you will need to have at-least one subscription to RHN. Which is a good investment IMO, but lets stick to the point.
yum security.modifyrepocommand as shown here, to injectupdateinfo.xmlintorepomd.xml. Before doing this, you will have to modify the perl script to change the Rpm MD5 sums inside the xml, from the RHN to Centos sums. And you will have to make sure if CentOS repos actually have all Rpms mentioned inupdateinfo.xml, as they are behind RHN sometimes. But that's fine, you can ignore the updates CentOS hasn't caught up with, as there is little you can do about it, short of building them from SRPMs.With option 2, you can install
yum securityplugin on all clients, and it will work.Edit: This also works for Redhat RHEL 5 and 6 machines. And is simpler than using a heavy weight solution like Spacewalk or Pulp.