Skip to main content

Cloudaware Virtual Applications

Cloudaware Virtual Applications provide an application‑centric view of infrastructure and services. They group configuration items (CIs) from multiple clouds and data sources into a single logical application within CMDB, so you can manage cost, ownership, risk, and operations in business terms rather than per‑resource lists.

Concept And Benefits​

Virtual Applications are built on top of CMDB objects and relationships:

  • Application – a top‑level record that represents a business application, service, product, customer, or any other logical boundary.
  • Application tiers – child records that represent layers such as web, app, database, or shared services.
  • Attachable objects – cloud and non‑cloud CIs (instances, databases, load balancers, queues, VMs, network devices, and more) that can be linked to an application tier.

Key benefits:

  • Multi‑cloud and hybrid coverage – group AWS, Azure, Google Cloud, Kubernetes, vCenter, network discovery, and other resources in one place.
  • Consistent scoping – use the same application definition for CMDB queries, dashboards, Compliance Engine policies, and cost reports.
  • Simplified ownership and access – align applications with teams, customers, or environments (prod/non‑prod) and use them as scopes for RBAC and reporting.
  • Operational context – see dependencies, change history, and posture (backups, vulnerabilities, monitoring) by application instead of per resource.

Use Cases​

Common patterns for defining Virtual Applications include:

  • Business services and products – map all supporting infrastructure to a named service or product.
  • Customers or tenants – for managed service providers, group resources by customer.
  • Projects or environments – group CIs by project, program, or environment (production, staging, development).
  • Access boundaries – use applications to define what subset of the estate certain teams or stakeholders should see.
tip

Create applications early in your rollout. Cost and other time‑series metrics are typically available in the application view only from the moment the application is created and populated.

Access Virtual Applications​

To open Virtual Applications from the CMDB UI:

  1. In Cloudaware, open CMDB Navigator.
  2. On the Home page or in the sidebar, locate the Cloudaware section.
  3. Select Applications and choose the application you want to view.

From there you can:

  • Navigate between DETAILS, INVENTORY, COST, and SETTINGS tabs for the selected application.
  • Drill into attached CIs and their CI detail pages.
  • Filter inventory by tier, provider, or other attributes.

For more background on the Navigator experience, see CMDB Navigator.

Application Structure​

Each Virtual Application typically includes:

  • Application header – application name, description, owner, environment, and high‑level KPIs (for example, 30‑Day Cost, 30‑Day Spend Change).
  • Tiers – one or more tiers (web, application, database, shared services, network, etc.) that logically group attached objects.
  • Inventory – a multi‑cloud list of attached resources, grouped by cloud/provider and object type.
  • Settings – management area for application name, tiers, and counts of attached objects.

Design tiers to reflect how your teams think about the service (for example, external vs. internal, online vs. batch, frontend vs. backend) while keeping the structure simple enough to operate.

Attaching Resources To Applications​

You can attach CIs to applications in two primary ways:

  • From the application UI
    • Open a Virtual Application and use inventory actions (for example, Attach Objects or equivalent controls) to search for and attach eligible resources.
  • From a CI detail page
    • Open a CI detail page in CMDB (for example, an AWS EC2 instance).
    • Use the ATTACH TO APPLICATION action in the CI header to associate the CI with a specific application and tier.

When you attach a resource, Cloudaware records the relationship in CMDB so that:

  • The resource appears in the application’s inventory and tier views.
  • Application‑level queries, dashboards, and policies can include or exclude the resource based on the application scope.

Virtual Applications support cascades, meaning that when certain resources are attached, their directly related objects can be attached automatically. For example:

  • Attaching an AWS EC2 instance may also attach its EBS volumes and network interfaces.
  • Attaching higher‑level constructs (load balancers, clusters, application gateways) can bring along their member instances or pods.

Best practices for cascades:

  • Prefer attaching higher‑level objects (for example, load balancers, clusters, or URLs) instead of individual instances when that better represents the service.
  • Reserve manual attachment for edge cases or static resources; use automation where possible for dynamic fleets.

Auto‑Attachment Via Flows (Advanced)​

For larger estates, Cloudaware administrators often rely on auto‑attachment rules rather than manual assignment. Auto‑attachment rules help keep application inventories current as new resources are created, renamed, or re‑tagged, and they work alongside cascades for related objects.

At a high level:

  • Cloudaware uses Salesforce Flow–based automation to update an “Application Tier Client Name” style field on attachable resources.
  • That field encodes both the application and tier (for example, MyApp - Web) and drives automatic attachment of matching objects to the right Virtual Application and tier.
  • Flows can use names, tags, or other metadata (for example, tag:Application and tag:Tier) to derive the correct application and tier.

Examples of attachment logic:

  • If an instance name starts with prod-, attach it to the production tier of a given application.
  • If tag:Customer equals CustomerA, attach the resource to CustomerA - Core.
  • If both tag:Application and tag:Tier are populated, concatenate them into the application/tier value.

Operational Best Practices​

To operate Virtual Applications effectively:

  • Define clear ownership – assign each application to a business owner or team and reflect that in CMDB metadata.
  • Standardize naming and tagging – align application names and tiers with existing tag keys/values or service catalogs so automation rules are easier to maintain.
  • Start with key services – model a small number of critical applications first (customer‑facing services, crown‑jewel systems) before expanding coverage.
  • Use applications as scopes – reuse application filters in CMDB queries, Compliance Engine policies, dashboards, and cost reports to keep signals consistent.
  • Review cascades and flows periodically – ensure that attachment logic still matches reality as architectures change.