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.
The "selected" answer is correct, but I wanted to add some extra information as most people using EB and RDS together should have the same requirement too - even if they don't know it yet.
First question: Why would you want the RDS instance to exist outside the EB environment?
Answer: So that the lifetime of the RDS instance is not tied to the lifetime of the EB environment. i.e. when you remove an environment, you don't want to destroy the DB with it. There are very few reasons why you'd want to actually tie your RDS instance to your environment.
A problem with settings up RDS independently of EB is that you don't get the RDS_* variables automatically populated and therefore need to retrieve their values and populate them yourselves via web console or .ebextensions. It's not recommended that you add credentials to your code though, as that can be a security hole.
But then, the next problem is if you want to programmatically create environments (such as for blue-green zero downtime deployments) then you need a solution for how to populate the sensitive RDS values (e.g. password) every time. Unfortunately, this requires you to drop further down the AWS stack and use a CloudFormation template.
The ideal solution is an enhancement to EB so that the "use an existing database" link mentioned in the question actually lets you manually associate an existing RDS database and then have the RDS_* environment variables automatically populated again, rather than redirecting you to unhelpful documentation. AWS Support said this has been raised as a feature request but of course no timeframe given.
Best Answer
The recommended and supported way to upgrade your AWS Beanstalk environment is documented here and managed platform updates are discussed here, honestly I'd stick to that if you want things to be easy (and that's what Beanstalk is all about), you'll theoretically only get the non-breaking updates and AWS will manage the process so there's no downtime.
So I just want to reiterate that managed platform updates are probably what you or anyone else coming here from Google will want, but if you want to know the latest AWS provided AMI for your Beanstalk environment it can be done fairly trivially with AWS CLI (thanks to sane naming conventions from Amazon on their AMIs).
Starting with an instance from your environment, describe the instance to get the current AMI (skip if you already know the current AMI).
Take the resulting AMI ID and describe it.
We can use the output of the above as input to a new, sorted
describe-imagesbut this time we replace the timestamps with*wildcard symbols, like so:Due to the power of lexical sorting and ISO 8601, we end up with the latest AMI, which in my example is
ami-1be5de78.Again, I wouldn't recommend you try to change to this AMI by hand, Beanstalk has provisions to do all this for you!