# Automation Reply CMP Automation lets you schedule routine operations and enforce standards at scale. Policies target groups of resources and run on a schedule or on demand. ```{note} Automation acts on resources you scope via Groups (defined in FinOps → Allocate). Membership is dynamic—if a resource enters a group, it is included automatically in future runs. ``` ## Quick start 1) Open Automation → New Policy. 2) Name the policy and set Status = Active. 3) Choose a Type (Start VM, Stop VM, or Enforce Tags). 4) Select one or more Groups to target. 5) Set the Schedule (cron expression). 6) Save. You can also Run now to execute immediately. ```{tip} Use separate policies for prod and non‑prod to keep scopes simple and audit trails clear. ``` ## How it works A policy defines: - Name and Status (Active/Disabled) - Type: the action to perform - Schedule: when to run (cron) - Scope: Groups whose resources are affected Execution flow: - On schedule or manual trigger, the policy resolves the targeted resources from the selected Groups. - The action runs provider‑side using the identity attached to the connection. - Results are recorded with per‑resource outcomes (processed, failed, skipped) and an overall status. --- ## Policy types and supported resources ### Start/Stop Resources Start or stop compute and selected managed services. Azure: - Virtual Machines, VM Scale Sets, Application Gateways, MySQL, PostgreSQL, AKS clusters AWS: - EC2 Instances, RDS Databases, Redshift Clusters GCP: - Compute Engine Instances - Managed Instance Groups (stop scales target size to 0; start restores the previous target size) - Cloud SQL Instances - GKE Clusters (Autopilot clusters cannot be stopped) ```{warning} Managed Instance Groups are controlled at the group level. Individual instances in a MIG are excluded to avoid conflicts. ``` ### Enforce Tags Ensures required tags/labels exist and, where supported, sets/updates them. Azure: - All Azure resources that support tags AWS: - All AWS resources that support tags GCP: - Compute Engine Instances, Disks - Cloud SQL Instances - Cloud Storage Buckets - Pub/Sub Topics - Cloud Run Services - Cloud Functions - GKE Clusters ```{note} Not all services allow tag updates after creation. Unsupported items are reported as skipped with a reason. ``` --- ## Scheduling Policies use cron syntax. Examples: - Every day at 18:00 → `0 18 * * *` - Weekdays at 08:00 → `0 8 * * 1-5` - Every 30 minutes → `*/30 * * * *` ```{tip} Use the policy preview (“Next run”) to validate expressions before activating. Stagger high‑impact jobs to avoid peaks. ``` --- ## Groups and scope Select one or more Groups to define the scope. Groups come from FinOps → Allocate (organization tree) and can represent BU, product, or team. Pair with Environments (dev/qa/prod) and Projects via allocation rules to target exactly the right set. ```{example} Create a “Stop Dev after hours” policy that targets Group = BU:Web, Environment = dev. Only dev workloads in that BU are affected. ``` --- ## Example: Stop Dev after hours A common policy saves costs by stopping non‑prod workloads outside business hours. Prerequisites: - Define Groups and Environments in {doc}`FinOps → Allocate ` so dev resources are scoped correctly. Steps: 1) Open Automation → New Policy. 2) Name: "Stop Dev after hours"; set Status = Active. 3) Type: Stop Resources. 4) Scope: Select your BU/Product Groups and Environment = dev. 5) Schedule: Weekdays at 19:00 → `0 19 * * 1-5`. 6) Save. Use Run now to test on a small subset first. ```{tip} Create a companion "Start Dev in the morning" policy (08:00 → `0 8 * * 1-5`) to restore capacity at the start of the workday. ``` Monitoring the result: - Open the policy, check the last run status, and review per‑resource outcomes. - Investigate failures (for example, service doesn’t support stop) and adjust scope or resource types. --- ## Execution and monitoring - Run automatically on schedule or trigger Run now. - View execution history with status (Success, Failed, In Progress). - Inspect per‑resource results: processed, failed (with error), skipped (with reason). - See who initiated the run and total duration. - Export logs if you need to share results externally. ```{warning} Always test new policies on a small non‑prod group first. ``` --- ## Customization on demand ```{note} Need a new action, different resource type, or extra policy conditions? Contact your CMP administrator or your Reply CMP contact point. We can extend supported resources or add custom policy types upon request. ``` --- ## Troubleshooting - Nothing was processed: The selected Groups may be empty at execution time. Verify allocation rules in FinOps and try again. - Unauthorized errors: Ensure the connection identity has the rights to start/stop or tag the resource. - Cron didn’t trigger: Check policy Status = Active and verify the next run preview; adjust the expression if needed. - Partial failures: Review per‑resource errors (for example, service doesn’t support stop/start, tag is immutable) and adjust scope or policy type. --- ## FAQ **Can multiple policies target the same resources?** Yes. Coordinate schedules to avoid conflicting actions (for example, start and stop at the same time). **Do policies evaluate tags at run time or at creation time?** At run time. Group membership is resolved when the policy executes. **Can I pause a policy without deleting it?** Yes. Set Status = Disabled; the schedule will not run until reactivated. **Where can I see what changed?** Use the execution details for per‑resource outcomes. For configuration history, refer to Discovery (resource History) and FinOps for any cost effects. --- ## Glossary - Policy: A scheduled action with a scope and execution plan. - Group: An organizational scope defined in FinOps (organization tree). - Run: A single policy execution instance with logs and results. - Scope: The set of resources resolved from selected Groups at run time.