Data Model

Cloudaware CMDB data model is designed to aggregate data from multiple sources using fields and relationships. For example, the AWS EC2 Instance object has a relationship with the Cloudaware Vulnerability Scan object, which is fetched from data sources such as Tenable, Qualys, and Rapid 7. In addition, the EC2 Instance object also has a ‘Cloudaware Last Scan Date’ field, populated based on the last scan date received from supported scanning integrations.

Nerd out →

Cloudaware implements virtual applications to group IT infrastructure assets. Using automated workflows that rely on tags and other CI attributes, Cloudaware will automatically associate inventory with specific applications and tiers. Additional modules such as Compliance Engine and Cost Analysis use application inventory data to enable violation routing and spend attribution based on a resource’s application membership. In addition, application owners can use application inventory data to generate real-time documentation for compliance and reporting purposes.

Nerd out →

During a cloud provider outage or an application-specific incident, mappings between assets and applications are critical for immediate impact assessment and execution of recovery plans. Application owners can use inventory data to understand their exposure and dependency on specific cloud provider services by availability zone and region. When individual resources are in a degraded state, response teams can quickly publish a catalog of impacted business services.

Nerd out →

Customers can extend the cloud-native data model by adding custom attributes. Using Breeze facts and related lists, Cloudaware users can promote any machine fact to become an instance-level attribute. For example, a simple Breeze fact like kernel version becomes the instance attribute of the same level as instance type or availability zone.

Nerd out →

Cloudaware consolidates multiple physical tags with inconsistent spelling and presents them as a single logical tag inside CMDB. For example, 'environment', 'enviroment_' and 'env' become 'Environment'. Users can also exploit Cloudaware Compliance Engine to enforce alignment with enterprise tagging standards using customizable tagging compliance policies.

Nerd out →

Estimating the cost of vCenter in the cloud is the first step in the cloud migration strategy. Using a formula field, Cloudaware users can customize estimated cloud runtime expenditures based on RAM, storage and hardware age. Customers can adjust the formula field to consider their organization-specific cost structure, such as data center cost, software licensing fees and other parameters.

Nerd out →

Using data about software assets and infrastructure capacity, Cloudaware users can create custom software license CMDB objects to track software usage across cloud and non-cloud infrastructure based on hardware specifications and running hours. License management dashboards provide a single real-time view of costs, consumption, and optimization opportunities for licenses in use.

By leveraging Cloudaware CMDB APIs and Custom Objects, users can develop their own collector integrations to consolidate data from existing off-the-shelf and in-house CMDBs.

Customers can extend native Cloudaware CMDB schema by adding their own CI types such as, for example, Product Owner, Business Unit, and others. Once the schema is ready, users can import data to CMDB via APIs and various out-of-the-box continuous bulk data load integrations.