Learn about custom rules in NetApp Console
Suggest changes
PDFs
Custom rules let you set, check, and enforce your own architecture standards, along with NetApp best practices, in the well-architected dashboard.
Overview
The Rule builder lets you create custom rules using plain language. These rules are checked across all your resources.
Custom rules help you enforce your organization's standards, risk limits, and operational requirements that default rules might not cover.
|
If your account administrator has turned off AI features, you cannot create new rules or edit existing rules. Any rules that are already scheduled continue to run. Learn about managing AI features. |
How custom rules work
Custom rules use AI to turn plain-language instructions into clear, structured rules. The AI translates your request, suggests a rule, explains how it understood your instructions, and asks for approval before saving or scheduling the rule.
This process helps ensure that:
-
The rule is clearly defined and checked for errors
-
No custom code is executed
-
You can review exactly what will be evaluated before approving the rule
-
Each custom rule includes the resource type to evaluate, the condition logic, the severity, the evaluation schedule, and remediation guidance.
Before you begin
Before you can create and run custom rules, ensure you have the following:
- AWS credentials
-
Read-only access to your AWS environment. Custom rules require read-only permissions as a security boundary. Add AWS credentials to Workload Factory.
- ONTAP credentials
-
FSx viewer user with read-only permissions. Workload Factory creates a read-only user on each FSx for ONTAP file system if one does not already exist, allowing it to perform evaluations.
- Link or agent
-
Only required for rules that must connect directly to ONTAP to check settings that AWS APIs cannot access. Connect to an FSx for ONTAP file system with a link.
Limitations
-
Rules cannot fix issues automatically. You must correct non-compliant resources yourself using the provided guidance.
-
Each rule checks only one type of resource, but it can apply to a wide range of resources. For example, one rule can evaluate volumes in multiple regions, all regions, or multiple accounts. To evaluate different resource types, create separate rules.
-
Rules run at most once per hour to prevent excessive scanning.
-
Rules can only read your environment and cannot make changes.
-
You can update these settings later from the Rules catalog.
Rule lifecycle
Custom rules progress through the following states:
- In progress
-
Creating or checking rules.
- Failed to create
-
Could not create the rule. You can reopen the rule and continue editing in chat.
- Draft
-
Saved but not yet scheduled.
- Validated draft
-
Passed validation and can be saved or scheduled.
- Editing
-
Updating a draft copy of an existing rule. The current scheduled rule continues to run until you save the changes.
- Scheduled
-
Active and runs on the defined schedule.
- Disabled
-
Paused but not deleted. Can be re-enabled.
- Deleted
-
Permanently removed.
Custom rule examples
- Production volume protection
-
"All volumes with tag 'Prod' must have a snapshot policy installed"
This rule automatically creates snapshots to protect production volumes according to company requirements.
- Archive volume tiering
-
"All volumes with tag 'Archive' should have a tiering policy set to 'All'"
This rule lowers costs by automatically moving archived data to cheaper storage.
- File system naming standards
-
"All file systems must follow the naming convention 'fsx-{environment}-{application}'"
This rule validates that file systems adhere to organizational naming conventions for easier management and cost allocation.