Recommendation rules

ZopNight ships with 490 audit rules covering every major resource type on AWS, GCP, and Azure. This page groups them by category so you can see what each category catches. The full per-rule detail (evidence shape, math, remediation steps) is visible inside each recommendation card in the app.

Coverage at a glance

490 rules in total, split across the three providers:

Provider	Total rules	Notes
AWS	216	Includes EC2, RDS, EKS, S3, Lambda, IAM, networking, and the AWS Bedrock, SageMaker, and Databricks rule families
GCP	127	Includes Compute Engine, GKE, Cloud SQL, GCS, Cloud Run, and Databricks
Azure	147	Includes VMs, AKS, Azure SQL, Blob Storage, Functions, and Databricks

The per-provider totals include the Kubernetes workload rules (41 per provider; 123 in total across EKS, GKE, and AKS) and the autoscaler rule family (6 rules covering ASG / VMSS / MIG / ECS scaling configuration). The composition is: 367 static cloud-native rules + 123 K8s workload rules = 490. The Databricks rule family (~15 per cloud) and the autoscaler family (6 rules) are counted inside the 367 static cloud-native rules, not added on top of them.

Idle

Resources running but doing no useful work. Largest savings category for most accounts.

Sample rules:

Resource type	What it catches
EC2	Instance with CPU < 5% and no network IO for 14 days
Lambda	Function with zero invocations for 7 days
NAT Gateway	NAT gateway with no traffic
Load Balancer	Load balancer with zero requests
ECS service	Service with zero running tasks for 7 days
EFS	File system with no IO operations
Redshift	Cluster with no queries for 14 days
OpenSearch	Domain with no search/indexing
MemoryDB	Cluster with no commands processed
ElastiCache	Cluster with no commands processed
RDS	Instance with no connections for 14 days

Plus equivalents on GCP and Azure: idle Compute Engine, idle GKE node, idle Cloud SQL, idle Azure VM, idle AKS node, idle Azure SQL, idle Blob Storage account, and so on.

Rightsizing

Resources sized larger than the workload needs. Drop one or two instance sizes, keep the same SLO, lower the bill.

Sample rules:

Resource type	What it catches
EC2	Underutilised. CPU < 20% sustained
EC2	Rightsizing opportunity; recommend specific smaller instance type
EC2	Oversized; recommend dropping a tier
EBS	gp2 to gp3 migration (cheaper, often faster)
RDS	Instance rightsizing
Lambda	Over-provisioned memory
EBS	Provisioned IOPS over-allocation
ECS Fargate	Oversized task definition
Glue	Job DPU rightsizing
GKE	Node-pool rightsize (guided)
AKS	Agent-pool rightsize (guided)

K8s workload rightsizing rules also catch missing or over-set CPU/memory requests via HPA ScalingLimited signals.

Schedule

Resources running 24×7 that have a clear off-hours usage pattern. Strong candidates for ZopNight’s start/stop scheduling.

Sample rules:

Resource type	What it catches
EC2	Non-production scheduling opportunity (tag-based + naming heuristics)
EC2	Heatmap-based schedule opportunity (usage hours analysis)
RDS	Dev/test database with weekend idle pattern
GKE	Non-prod node pool with off-hours idle pattern
Azure VM	Dev/test VM running 24×7
Azure Function App	Premium tier with predictable off-hours

Schedule recommendations integrate with ZopNight’s scheduling feature; one click attaches the resource to a recommended schedule.

Discount

Reserved Instance, Savings Plan, and Committed Use opportunities; places where steady, predictable usage justifies a commitment.

Sample rules:

Resource type	What it catches
EC2	Reserved Instance opportunity; stable instance running > 70% of last 30 days
RDS	Reserved Instance opportunity
EC2	Compute Savings Plan opportunity
EC2	Spot adoption candidate
ElastiCache	Reserved node opportunity

Plus GCP Committed Use Discount and Azure Reservation equivalents.

Orphan

Resources no longer attached to anything that needs them. Often the easiest wins because there’s nothing to break.

Sample rules:

Resource type	What it catches
EBS	Unattached EBS volume
Elastic IP	Unassociated Elastic IP
EBS	Orphaned EBS snapshot (no source volume)
ECR	Repository missing lifecycle policy
EKS	Abandoned node group
VPC Interface Endpoint	Endpoint with no traffic
GCP	Orphan persistent disk
VPC	Unused Internet Gateway
TGW	Transit Gateway with no attachments

K8s orphan rules also catch unbound PVCs, released PVs, and empty Service endpoints.

Compliance

Configuration drift from best practice. These are not always about cost directly; they’re about operational hygiene that compounds into cost and risk over time.

Sample rules:

Resource type	What it catches
RDS	Production instance missing Multi-AZ
RDS	Excessive backup retention
VPC	Flow Logs writing to CloudWatch instead of S3
CloudWatch	Log group with no retention policy
S3	Bucket missing lifecycle policy
EC2	EBS optimisation not enabled
EC2	Detailed monitoring not enabled
Lambda	Using deprecated runtime

Security

Risky configurations with cost or operational implications. ZopNight surfaces them alongside cost recommendations so the same audit pass catches both.

Sample rules:

Resource type	What it catches
IAM	Role with wildcard principal
IAM	Role with AdministratorAccess
IAM	Access key older than 90 days
IAM	User without MFA enabled
Security Group	Unrestricted inbound access
RDS	Instance publicly accessible
S3	Bucket with public access
Various	Resource not encrypted at rest
EC2	IMDSv2 not required

K8s security rules catch privileged containers, root users, host network, and missing TLS.

Reliability

Production-shape issues that cause incidents and re-work. Mostly Kubernetes workload rules.

Sample patterns:

• Deployment with single replica in production
• HPA at max replicas (scaling-limited)
• Missing readiness/liveness probes
• Missing requests/limits
• Degraded workloads (pod restarts, crash loops)
• Stopped deployments
• Suspended cronjobs
• Failed jobs

Autoscaler

Six rules specific to scaling configuration on ASG, VMSS, MIG, and ECS services.

What it catches	Providers
Scaling group has no scaling policies	AWS (ASG)
Autoscale setting missing	Azure (VMSS)
Autoscaler missing	GCP (MIG)
Scaling target too high (> 90%)	All providers
Scaling target too low (< 30%)	All providers
Cooldown too short (< 120s)	All providers

All six are actionable via one-click apply through the autoscaler, provided the account is in Recommend or Autopilot mode; Monitor mode is read-only and can’t apply. See Autoscaling.

Databricks

A provider-parameterised rule family fires across all three clouds (15 rules per cloud) for Databricks compute: clusters, SQL warehouses, instance pools, jobs, and model-serving endpoints. See Databricks for the connection model.

The family covers, among others:

What it catches	Applies to
Cluster missing auto-termination	All-purpose clusters
SQL warehouse without auto-stop	SQL warehouses
Model-serving endpoint left always-on	Serving endpoints
Instance pool holding too many idle VMs (min-idle too high)	Instance pools
Cluster oversized for its workload	Clusters
Autoscaling disabled on an eligible cluster	Clusters
Photon disabled where it would cut runtime cost	Clusters
Job running on an expensive all-purpose cluster	Jobs
On-demand workers that could be spot	Clusters
No cluster policy attached	Clusters
Missing cost-allocation tags	Clusters, warehouses, jobs
Orphaned job (no recent runs)	Jobs
Orphaned SQL warehouse	SQL warehouses

Azure adds a metric-driven idle-cluster rule on top of the shared family.

Severity

Severity is assigned per finding, not per rule. The same rule can fire as Critical on one resource and Medium on another, depending on the savings size and the resource’s context.

Severity	Rough meaning
Critical	Large savings on a production resource, or a security finding with cost/risk implications
High	Substantial savings, or a clear best-practice violation
Medium	Default for most cost recommendations
Low	Small absolute savings, or a low-confidence signal

Filter the Recommendations page by severity to prioritise; start with Critical, work down.