Queries Immuta Runs in Your Data Platform

Once your data platform integration is configured, Immuta periodically runs queries in that data platform to orchestrate policies or implement various features. Depending on your configuration, data platform cost model, and data platform query load, there may be incremental cost incurred when various Immuta features are enabled. The actions and features that trigger Immuta queries in your remote platform are listed below.

• Configuring an integration: Immuta uses compute resources to set up the integration in the data platform. After the integration is configured, Immuta runs periodic validation queries to ensure the integration is still healthy. By default, this simple SELECT query is run once per hour to validate that the credentials, connection information, and network configuration are all functional.

• Registering data sources: Immuta uses compute resources to register data sources. If schema monitoring is enabled, Immuta uses the compute warehouse that was employed during the initial data source registration to periodically monitor the schema for changes. To adjust the schedule of the schema monitoring job to reduce cost, see the Schema monitoring guide. Additionally, these data source actions will use compute resources:

  • Data source disabled

  • Data source enabled

  • Data source deleted

• Policy applied to a data source: Immuta uses compute resources to orchestrate policies in the data platform. Consider registering data before creating global policies. Immuta does not apply a subscription policy on registered data unless an existing global policy applies to it, which allows Immuta to only pull metadata instead of also applying policies when data sources are created. Registering data before policies are created reduces the workload and the compute resources needed; Immuta will only perform a grant for the user who registered the data source. The following actions that trigger updates to policies will also use compute resources:

  • External user ID modifications

  • Group name changes

  • Policy modifications

  • Tags changing on data sources

  • User attributes changing

  • Users being added to or removed from groups

• Scheduled audit ingest or manually-triggered audit ingest (clicking the Load Audit Events button): Generally, the data platform cost from enabling query audits is directly related to warehouse uptime governed by the audit frequency and average query compute cost. During query audit retrieval, Immuta runs standard query operations (e.g., SELECT) against the system views and does not use other data transfer methods that incur additional data egress costs. For example, during query audit retrieval for Snowflake, Immuta will use the Snowflake warehouse that was configured during integration registration to query the Snowflake system views. If this warehouse is stopped, Immuta will start it.

• Identification:

  To evaluate your data, identification generates a SQL query that Immuta then executes in the remote technology. The query result contains the column name and the matching identifiers, and Immuta applies tags to the appropriate columns.

  This evaluating and tagging process occurs when identification runs, which happens from the following events:

  • A new data source is created.

  • Schema monitoring is enabled and a new data source is detected.

  • Column detection is enabled and new columns are detected. Here, identification will only run on new columns, and no existing tags will be removed or changed.

  • A user manually triggers identification to run from the data source health check menu, domains page, or through the API.