In a previous post we described options for patching VMs in your environment - the virtual machines within your firewall and within your control.


You’re facing different challenges when it comes to the public cloud -- a multi-tenant infrastructure as a service environment such as Amazon Web Services. The technical issues aren’t any different but the legal and contractual issues are. They boil down to: Who is responsible for keeping the server and applications patched, and how and when are those patches applied?


Patch Management Questions to Ask Your Cloud Provider

The first and most basic question to address is whether you (the customer) or the IaaS provider is responsible for patching. Can you, for example, use your corporate WSUS server to patch your VMs’ applications in the public cloud, even if you don’t own the license for the operating system on those VMs?


Assuming the IaaS provider is responsible, you’ll need to know how they will execute the patch process. Will they let you, the customer, control when the deployments are done, so you have some warning in case the patches go wrong? Can you decide when the patches are applied, or at least get a warning, if servers need to be taken off-line or rebooted as part of the patch process?


If failed patches cause service failures, does your provider have enough redundancy in place so your users never see the impact of patching? And if a patch affects application performance or availability, what legal or financial recourse do you have?


Patch Management is Your Responsibility
Regardless of whoever actually does the patching, you’re in the best position to know which systems are most critical and when they should be patched.


Your first, and maybe most difficult choice, is deciding (just as in your private cloud) how often you should update the master images.  More frequent patching of the master image will require fewer machines to be patched down the road (if in the case you are frequently spinning up new VMs).  Many organizations only update their images when a new service pack is released (oh my).  That, however, makes for a lot more work because once you’ve decided to deploy a patch, you have to find and update every VM made from the master image.  Updating on an infrequent basis also opens the door to hackers attacking your systems. 


Once you’ve made your decisions on how frequently patches should be applied, how will you communicate to your IaaS provider your patching policy (including your planned patching schedule) to prevent patching issues (such as if the service provider is performing maintenance).  How will you obtain the necessary information on whether the patch was successful, or it failed, or whether it caused a performance issue? 


However you divide the work with your provider, the bottom line is that just as with security, you can’t outsource the ultimate responsibility for patch management. These are your servers and your applications serving your users and customers, and it’s up to you to work with your provider to make sure they’re patched appropriately.


Do you patch applications on servers residing in a public cloud?  Tell us, how do you patch them?