Automatically Applying Security Updates for AWS Elastic Beanstalk

I've been a fan of Heroku since it's earliest days. But I like the fact that AWS Elastic Beanstalk gives you more control over the characteristics of the instances. One thing I love about Heroku is the fact that I can deploy an app and not worry about managing it. I am assuming Heroku is ensuring all OS security updates are timely applied. I just need to make sure my app is secure.

My initial research on Beanstalk shows that although it builds and configures the instances for you, after that it moves to a more manual management process. Security updates won't automatically be applied to the instances. It seems there are two areas of concerns:

• New AMI releases - As new AMI releases hit it seems we would want to run the latest (presumably most secure). But my research seems to indicate you need to manually launch a new setup to see the latest AMI version and then create a new environment to use that new version. Is there a better automated way of rotating your instances into new AMI releases?
• In between releases there will be security updates released for packages. Seems we want to upgrade those as well. My research seems to indicate people install commands to occasionally run a yum update. But since new instances are created/destroyed based on usage it seems that the new instances would not always have the updates (i.e. the time between the instance creation and the first yum update). So occasionally you will have instances that aren't patched. And you are also going to have instances constantly patching themselves until the new AMI release is applied. My other concern is that perhaps these security updates haven't gone through Amazon's own review (like the AMI releases do) and it might break my app to automatically update them. I know Dreamhost once had a 12 hour outage because they were applying debian updates completely automatically without any review. I want to make sure the same thing doesn't happen to me.

So my question is does Amazon provide a way to offer fully managed PaaS like Heroku? Or is AWS Elastic Beanstalk really more of just a install script and after that you are on your own (other than the monitoring and deployment tools they provide)?

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.

As of April 2016, Elastic Beanstalk supports automatic platform updates:

https://aws.amazon.com/about-aws/whats-new/2016/04/aws-elastic-beanstalk-introduces-managed-platform-updates/

All Beanstalk applications and environments can be configured through EBEXTENSIONS files that are packaged up with your application deployment package (e.g. WAR file for Java apps) with YAML-based configuration to update or reconfigure any part of your application, container, OS etc. Beanstalk is PaaS since it is a platform that allows you to deploy applications without having to worry about the underlying IaaS. All PaaS providers at the end of the day obfuscate the underlying IaaS through some form of automation. However since this is computer science we are talking about there is no single optimal state for all applications and without the ability to tweak the IaaS under the PaaS, you are at the mercy of the PaaS service provider to assure you that your applications run smoothly, fast and securely.

Heroku runs on top of AWS using a different management layer that's all. However it becomes a pain in the ass when you have to do things like securing your application. While they do make best efforts to manage their solution efficiently and maintain security etc. they can't and won't take on the risk and the consequences of a vulnerability in your app at the end of the day. They want to make their services as cookie-cutter as possible.

The ability to tweak the IaaS underlying the platform is a strength and appeal of Beanstalk IMO.