Skip to main content

Enrichment Rules

Enrichment rules help Cloudaware enhance CMDB data as it is ingested. They turn raw discovery data — tags, labels, names, and technical attributes — into consistent business metadata and classifications that other modules can rely on.

Typical enrichment scenarios include:

  • Classifying assets by environment, tier, or data sensitivity based on names, locations, or labels.
  • Flagging resources that meet certain conditions (for example, internet‑facing, public data access, missing monitoring, or backup).
  • Attaching applications, services, or business units to CIs using rules (e.g., based on tags or custom attributes) instead of manual updates.
  • Mapping heterogeneous tags from different teams or clouds into unified fields (for example, multiple owner tag keys into a single Owner attribute).

How Enrichment Works in Cloudaware​

At a platform level, Cloudaware automatically discovers resources across AWS, Microsoft Azure, Google Cloud, VMware, on‑prem, and other environments. Cloudaware then enriches those resources with additional attributes such as OS version, IDS status, cost, compliance posture, and ownership, while also identifying and mapping cross-system relationships between resources from different integrated systems. As a result, each CI becomes a consolidated “hub” of information that combines cloud‑native metadata, business tags, security context, and financial data.

Data Sources Used for Enrichment​

Cloudaware pulls enrichment signals from multiple sources:

  • Cloud providers:
    • AWS, Azure, GCP, and other sources via configuration and inventory services (for example, AWS Config, Azure Resource Graph, GCP Asset Inventory, etc.).
    • Billing and usage APIs, plus tags/labels such as cost_center, owner, and environment.
  • Third‑party tools:
  • Custom collectors:
    • Customer‑built collectors on the underlying Force.com platform can ingest any additional system data and write it into CMDB fields.

How Cloudaware Applies Enrichment​

  • Continuous collectors:
    • Real‑time or scheduled collectors fetch attributes and merge them into existing CIs instead of creating duplicates.
    • Updates may include new facts (for example, OS details), health signals (agent status, monitoring coverage), or relationships.
  • Auto‑tagging and ownership detection:
    • Metadata such as account/subscription, tags, and organizational hierarchy is used to infer:
      • Owner and team.
      • Environment (prod/test/dev, etc.).
      • Application or service mappings.
  • Relationships and dependencies:
    • “Hosted on”, “uses”, “depends on”, and similar relationships are automatically inferred, so enriched CIs show how components fit into the full stack.

How Enriched CMDB Data Is Used​

Enrichment makes CMDB the system of record for many downstream workflows:

  • Security:
    • The Log Management (Conflux) module and other security tools can consume CMDB‑enriched context, so events are tagged with owner, application, environment, and region.
    • This accelerates triage, prioritization, and incident response by showing who owns an asset and how critical it is.
  • FinOps/ITAM:
    • Enriched CIs tie technical assets to costs, usage, and business dimensions.
    • This enables Cost Management workflows such as allocation, showback/chargeback, waste detection, and lifecycle tracking.
  • ITSM/operations:
    • Operations teams use enriched CIs and dependency maps for:
      • Impact analysis (which services and applications are affected by a change or incident).
      • Faster incident resolution with clear ownership and dependencies.
      • Change approvals and compliance reporting based on accurate, normalized metadata.

Governance and Maintenance​

  • Periodically review rule effectiveness using CMDB queries and BI analytics dashboards (for example, assets with missing or conflicting metadata).
  • Coordinate enrichment logic with Change Management and automation teams so downstream workflows and policies depend on well‑defined fields.