The advantages of “Baking in” antivirus in your model on Amazon Web Services (AWS)

As an AWS customer, chances are you made a great business decision to move to that model for some or all the following reasons:

•      Flexibility
•      Capacity
•      Agility
•      Speed
•      Accessibility
•      Ease of use
•      Scalability
•      Continuous Delivery

Whether you’re a startup or a DevOp in a large enterprise, some of the most compelling reasons to move a business model or develop a business process on AWS is that incredible and versatile infrastructure.

The power and productivity is second to none (well except in the case of the odd outage here and there – but that’s another story). When all is running smoothly, so is your business or your project. The ability to scale and spend according to your delivery model, timelines and needs, while delivering world-class applications and business processes is like no other time in history.

With a keen eye to compliance and proper protection for those instances you or your team are working with, you have some coverage on those fronts based on your agreements with AWS. But Amazon Web Services is very clear about what is and ISN’T covered, which is pretty-much everything and anything running in your AMIs.

 If you have to deal with regulatory compliance of any kind, which most organizations do these days, overlooking the importance of antivirus/antimalware could be deadly for your organization or project – but this isn’t news.

Logically, if you’ve adopted the public cloud model that affords you all those great benefits listed above, shouldn’t malware and virus protection dovetail with all the benefits of public cloud? It’s pretty hard to disagree – but all naysayers are welcome to comment. Yes, you could easily say, antivirus slows the AMIs with the scanning and memory drain. Sure, if you’re using traditional approaches. But a hosted solution that you spool up and wind down with your instances is totally doable and available. 

In looking at a hosted solution, look for one that hosts the management component (you don’t need to be paying for more AMIs). Also look for one that offloads a good portion of the scanning to another hosted system. Again, you don’t want to pay for the system doing the heavy lifting. Also, especially with smaller instance types, you don’t want the performance impact to remain on your AMIs. With a traditional anti-virus that runs a full agent, you don’t want to be forced to move an instance level up because you have to host heavy anti-virus workloads.

To control costs, you should pay for what you use. When you bring-up your AMIs, you pay for protection hourly, and stop paying when you cycle them down. If you use instances very dynamically (100 today, none tomorrow, 500 the day after), going with yearly or even monthly licensing for a fixed number of protected AMIs will create a cost burden; and the same goes for fixed fees for the management console or other hosted elements. Everything should be neatly tied to how and when you use your AMIs.

But one could argue that it is the completion of the app, the project or the business process that is of greater importance, and that security can be ‘added in’ later. Yes, and potentially at your own peril. 

Why would anyone wait or expose themselves to a potential AMI compromise or a compliance oversight at the beginning of a project? ‘Baking in’ antivirus/antimalware from the get-go is irrefutably the best approach, and smart startups and enterprises realize their part in protecting instances and customers from any damaging results and insist on malware protection early in the delivery cycle. 

Are you doing that? 

{{cta('c6272c5a-8230-4925-95f7-892fe177789f','justifycenter')}}