Remove dependency of wildcard permission

This section describes how to remove the dependency on wildcard permissions in Kyvos by defining specific permissions.

Cluster scaling without EC2 wildcard access

Kyvos supports cluster scaling without EC2 wildcard access by removing the following IAM permissions:

The following known limitations may occur when removing the permissions.

Automated deployments are not supported. Deployments must be performed using the wizard-based approach.
While wizard-based deployments:
- In the deployment wizard, dropdown selections for BI Server, Query Engine, and Kyvos Manager nodes are not available. You must manually provide the IP addresses and start the deployment.
- The deployment process completes successfully but may displays warnings related to the following parameters:
  - Tagging
  - Instance ID
  - Maximum QE instance type
  - Region
  - Volume
- After deployment, users are required to manually update following parameters in the cluster.properties file, including:
  - OE_INSTANCE_ID
  - REGION
  - QE_INSTANCE_ID
  - QE_MAX_CAPACITY_INSTANCE_TYPE
After Kyvos upgrade, users are required to manually update following parameters in the cluster.properties file, including:
- OE_INSTANCE_ID
- QE_INSTANCE_ID
Dedicated compute without wildcard permission is supported (valid only from Kyvos 2026.2.1 onwards).
During instance addition or deletion:
- Query Engine and Olapengine instance IDs will become empty in the cluster.properties file.
Tag-related errors may occur during the add instance operation.
The Change Instance Capacity functionality from Kyvos Manager UI is not supported.

Kyvos supports dedicated compute without wildcard access by removing the autoscaling:DescribeAutoScalingGroups permission.

The following known limitations may occur when removing the permission.

Compute Server Scale-In Behavior: Compute server cluster nodes will not be scaled in automatically, regardless of whether compute server auto-scaling is enabled or disabled. Once all semantic model processes are completed, the BI server updates the Auto Scaling Group (ASG) capacity to zero through the buildClusterShutdown thread, which runs by default at 15-minute intervals. As a result, all compute server nodes are terminated at that point.

Potential Over-Scaling of Nodes: In some cases, the system may scale out more nodes than expected. This occurs because the BI server does not have direct visibility or control over the current ASG capacity. Instead, it relies on Helix live participants to determine the active cluster capacity. Due to this indirect mechanism, there may be temporary discrepancies that lead to additional nodes being scaled out.
On the Activity Monitor, the Compute Server tab displays only those nodes on which the compute server services are currently running.