How to handle cloud instances that change frequently?

ennorab asked a question.

October 17, 2018 at 7:00 AM

Hi - new to the world of Snow and SAM, and just getting our organisation up and running with agents etc.

I'm looking to understand how organisations are tracking their cloud inventory such as AWS instances or Azure VM's. In particular, where the instances are spun up and down on a regular basis through automation. We have, for example, our development environment that has around 200 instances running spun up during the day and are then terminated in the evening. The next day a new set of instances will be spun up with completely new IP's, hostnames, MAC addresses etc.

This is replicated throughout our environments from test, to pre-production and production (with less frequency of changes to production of course - however we still deploy fortnightly a new release through the CI/CD pipeline).

I can't see how best to manage this scenario because if all the instances are spun up through automation (from templates) - those templates would have the Snow agent installed and we would soon start to see a LOT of computers showing up in the Snow portal, many of which would no longer be in existence.

Is it therefore not worth deploying the agents out in this way?

Does the AWS integration solve this in any way?

How are you tackling this problem in your environments?

Should we focus on only keeping a manual tracking of the AMI (templates)?

I'd appreciate your thoughts and suggestions on this.

Cheers,

Baronne

THowland
8 years ago
Hi Baronne, I certainly don't have all the answers to this, but is something that I am actively researching, investigating and lobbying for. In our situation we have opted not not to deploy Snow agents to AWS and Azure instances with the fear of over-inflating our SLM estate and skewing our compliance picture because this isn't a real-time view. I can tell you that the AWS integration/connector doesn't help because this will only provide you with basic discovery of the instances and not the application installed on those instances. I.e. will return the asset name, etc. but not what is installed on it. It is also restricted by AWS account, so if you have multiple accounts you will need to configure the connector for each AWS account in use. What we are doing at present is leveraging other solutions like Cloud Health to retrieve detailed information about what cloud instances are out there, their usage, configuration, consumption and cost. Other solutions like Tanium are also really good if you want to interrogate what is in use and have a mechanism to manage patching and updates, etc. FYI - I am lobbying for connectors for these types of 3rd party solutions too. Overall, because of the ethereal nature of cloud estates there is still a large proportion of the work that is manual interrogation and interpretation of the software usage. Our organisation is working with Snow and Tanium to try find a solution to this ever present challenge. Hope that helps shed some light - or at a minimum reassure you that you are not alone with this. BR, Tyrone
Expand Post
- ennorab
  8 years ago
  Thanks, yeah we used to use Cloudability but found we had some overlap with other tools we're using and now are looking at utilizing our investment in Splunk to aid inventory/discovery usage/consumption etc. I'll check out Tanium - do you know, is it like Splunk?
  Expand Post
  - THowland
    8 years ago
    Splunk I would liken more to CloudHealth rather than Tanium. Tanium is focused on endpoint security and systems management, so looking more at managing patching, updates and in some cases application deployment. Software Asset Management is more a hobby for Tanium, rather than a core focus. Tanium is great for the most part, but has downsides: Uses live 'sensors' (similar to agents, but more configurable) to interrogate the assets, which means that every time you do a new search, it will scan EVERYTHING in that moment not just a subset of assets, which will add to resource constraints - and depending on the size and complexity of your estate, there is the added risk of pulling systems down. It can only see what is live/active during each scan, so any historic data or inactive assets are excluded from view. Tanium offer (for an extra fee) a Tanium Asset Module that apparently collects the offline assets to aggregate the data, and has an indexing function to provide a deep interrogation of the assets (useful for Linux/Unix when items like Java could be installed in quite literally any directory). Software recognition is a bit scatty, because it looks for executables and whether or not the software is uninstallable or not. Tanium and Snow have the same issue - neither know how to handle non-persistent assets at the moment; although I believe all software discovery / SAM tools have the same issue. Oh - lest I forget, no one has a clue how to handle containers for the foreseeable future, because by nature of their structure you can't transmit data out of them making agents redundant.
    Expand Post