How Savings Recommendations Are Generated

Idle

Resources that are provisioned but showing no meaningful activity — no connections, no traffic, or near-zero utilization over the lookback period. These are strong candidates for stopping, archiving, or deleting, since they're incurring cost without supporting an active workload.

Rightsize

Resources that are actively in use but don't match their actual workload demand — either oversized and underutilized, or approaching capacity and at risk of being overutilized. These are candidates for resizing, configuration changes, or moving to a more cost-effective tier or commitment option, rather than being removed outright.

Orphan

Resources that are no longer attached to or supporting any other active resource — such as unattached disks or unassociated IP addresses. These typically serve no function on their own and are strong candidates for deletion.

App Service Plan Instance Unused

App Service Plans that have no apps deployed but are still incurring cost should be reviewed and, where appropriate, deleted to
reduce unnecessary cloud spend.

Mavvrik identifies Azure App Service Plans that have no apps deployed (deployed-app count = 0) and are still incurring a monthly cost. This policy is configuration/state-based rather than utilization-based, so no utilization metric is required; an
age filter is applied so only plans older than a configurable period, with 14 days used by default, are evaluated. Because an unused plan
can be deleted, its full monthly cost is treated as the potential saving.

Review the App Service Plan ownership and application dependency. If no apps are deployed and the plan is no longer required, consider deleting it based on internal requirements. Note: WorkflowStandard plans host Logic Apps (Standard) - confirm no workflow application depends on the plan before deleting.

App Service Plan deployed-app count

Virtual Machine Idle

Unused or idle virtual machine instances should be reviewed and, where appropriate, stopped, archived, or deleted to reduce unnecessary cloud spend.

Mavvrik evaluates VM usage over a configurable lookback period, with 14 days used by default. A VM is flagged as idle when the 95th percentile of Max CPU % falls within the configured threshold range, with 0%–5% used by default.

Review the VM usage pattern and workload dependency. If there are occasional peaks above the idle threshold, consider downsizing. If there is no meaningful utilization, consider stopping or terminating the VM based on business requirements.

CPU % (95th percentile, Max)

Disks attached to Stopped VM

Disks attached to stopped virtual machines should be reviewed to determine whether they are still required.

Mavvrik identifies data disks that remain attached to virtual machines in a stopped (deallocated) state. This policy is event-based, so no lookback period is required. The recommendation is generated based on the current VM power state and disk attachment status. Note: evaluates additional data disks only — the VM's OS disk is not included.

Review the stopped VM and attached disk. If the disk is no longer required, consider detaching, archiving, or deleting it based on internal retention and recovery requirements.

N/A (VM power state + disk attachment status)

Disk is idle

Disks with no read/write activity should be reviewed to determine whether they are still required.

Mavvrik evaluates attached data disk activity (excluding OS disks) over a configurable lookback period, with 14 days used by default. A disk is flagged as idle when Max IOPS + Max Throughput = 0, indicating no disk read/write operations or read/write bytes during the selected period. Unattached disks are covered separately under the "Disk is Unattached" recommendation.

Review the disk ownership and dependency. If the disk is no longer required, consider deleting or archiving it based on internal retention requirements.

Max Read/Write IOPS + Max Read/Write Throughput (Avg)

MariaDB Server Idle

MariaDB servers with no active connections should be reviewed to determine whether they are still required.

Mavvrik evaluates MariaDB server connection activity over a configurable lookback period, with 14 days used by default. A server is flagged as idle when there are no active connections during the selected period, based on the Max Active Connections metric. Servers already in a stopped state are excluded.

Review the MariaDB server ownership and application dependency. If the server is no longer required, consider stopping, deleting, or archiving it based on internal retention and recovery requirements.

Max Active Connections

MySQL Flexible Server Idle

MySQL Flexible Servers with no active connections should be reviewed to determine whether they are still required.

Mavvrik evaluates MySQL Flexible Server connection activity over a configurable lookback period, with 14 days used by default. A server is flagged as idle when there are no active connections during the selected period, based on the Max Active Connections metric. Servers already in a stopped state are excluded.

Review the MySQL Flexible Server ownership and application dependency. If the server is no longer required, consider stopping, deleting, or archiving it based on internal retention and recovery requirements.

Max Active Connections

MySQL Single Server Idle

MySQL Single Servers with no active connections should be reviewed to determine whether they are still required.

Mavvrik evaluates MySQL Single Server connection activity over a configurable lookback period, with 14 days used by default. A server is flagged as idle when there are no active connections during the selected period, based on the Max Active Connections metric. Servers already in a stopped state are excluded.

Review the MySQL Single Server ownership and application dependency. If the server is no longer required, consider stopping, deleting, or archiving it based on internal retention and recovery requirements.

Max Active Connections

Old Volume Disk Snapshot

Older disk snapshots should be reviewed to determine whether they are still required for backup, recovery, or retention purposes.

Mavvrik evaluates disk snapshots based on a configurable age threshold, with 90 days used by default. A snapshot is flagged when its age exceeds the selected threshold, indicating it may no longer be actively needed.

Review the snapshot ownership, retention policy, and recovery requirements. If the snapshot is no longer required, consider deleting or archiving it based on internal backup and compliance requirements.

N/A (snapshot age)

PostgreSQL Flexible Server Idle

PostgreSQL Flexible Servers with no active connections should be reviewed to determine whether they are still required.

Mavvrik evaluates PostgreSQL Flexible Server connection activity over a configurable lookback period, with 14 days used by default. A server is flagged as idle when there are no active connections during the selected period, based on the Max Active Connections metric. Servers already in a stopped state are excluded.

Review the PostgreSQL Flexible Server ownership and application dependency. If the server is no longer required, consider stopping, deleting, or archiving it based on internal retention and recovery requirements.

Max Active Connections

PostgreSQL Single Server Idle

PostgreSQL Single Servers with no active connections should be reviewed to determine whether they are still required.

Mavvrik evaluates PostgreSQL Single Server connection activity over a configurable lookback period, with 14 days used by default. A server is flagged as idle when there are no active connections during the selected period, based on the Max Active Connections metric. Servers already in a stopped state are excluded.

Review the PostgreSQL Single Server ownership and application dependency. If the server is no longer required, consider stopping, deleting, or archiving it based on internal retention and recovery requirements.

Max Active Connections

SQL Database Idle

SQL databases with no active sessions should be reviewed to determine whether they are still required.

Mavvrik evaluates SQL database session activity over a configurable lookback period, with 14 days used by default. A database is flagged as idle when there are no sessions during the selected period, based on the Max Sessions Count metric. Only databases with status "Online" & “Paused” and non-zero monthly cost are evaluated.

Review the SQL database ownership, application dependency, and usage pattern. If the database is no longer required, consider deleting, archiving, or retaining it based on internal retention and recovery requirements.

Max Sessions Count

App Service Plan Instance Underutilized

App Service Plan instances with low CPU and memory usage should be reviewed to determine whether the current size is appropriate.

Mavvrik evaluates App Service Plan instance utilization over a configurable lookback period, with 30 days used by default. An instance is flagged as underutilized when the 95th percentile of Max CPU % falls within the configured CPU threshold range, with 0%–40% used by default, and the 95th percentile of Max Memory % falls within the configured memory threshold range, with 0%–50% used by default. These thresholds can be adjusted by the customer based on their environment and workload requirements.

Review the App Service Plan workload, performance requirements, and scaling configuration. If the instance is consistently underutilized, consider downsizing to a smaller SKU or adjusting the plan based on application needs.

CPU % (95th percentile, Max) + Memory % (95th percentile, Max)

Bastion Per Region

Regions with multiple Azure Bastion instances should be reviewed to determine whether all instances are required.

Mavvrik identifies regions where more than one Azure Bastion instance exists. This recommendation is event-based, so a lookback period is not applicable. Multiple Bastion instances in the same region are flagged as potential consolidation opportunities.

Review the Bastion instances in the region and their associated network access requirements. Where appropriate, consolidate usage to a single Azure Bastion instance per region to reduce unnecessary costs.

N/A (resource count per region)

Disks High IOPS

High IOPS disks are costly and should be reviewed to confirm whether the current performance tier is required.

Mavvrik identifies Azure disks configured with read/write IOPS above 2,000. This recommendation is event-based, so a lookback period is not applicable. Note: this threshold is fixed in the system and is not currently customer-configurable, unlike most other policies. Disks with high IOPS configuration are flagged as potential rightsizing opportunities.

Review the disk performance requirements, workload dependency, and actual usage needs. If high IOPS is not required, consider moving to a lower-cost disk tier or resizing the disk configuration to better match workload demand.

N/A (disk IOPS configuration)

Disk Size Too Large

Large compute disks are unusual, expensive, and should be reviewed to confirm whether the allocated disk size is required.

Mavvrik identifies Azure disks with provisioned capacity above 100 GB. This recommendation is event-based, so a lookback period is not applicable. Note: this threshold is fixed in the system and is not currently customer-configurable. Large disks are flagged as potential rightsizing opportunities because higher provisioned capacity can increase storage costs.

Review the disk size, workload dependency, and actual storage requirements. If the disk is larger than needed, consider resizing to a smaller disk tier or reducing provisioned capacity where supported and safe to do so.

N/A (provisioned disk size)

Disks Standard Snapshots

Managed disk snapshots using Premium Storage should be reviewed to determine whether Standard Storage is sufficient.

Mavvrik identifies Azure managed disk snapshots that are using Premium Storage. This recommendation is event-based, so a lookback period is not applicable. These snapshots are flagged because using Standard Storage instead of Premium Storage can help reduce snapshot storage costs.

Review the snapshot performance and recovery requirements. If Premium Storage is not required, consider moving managed disk snapshots to Standard Storage to reduce costs.

N/A (snapshot storage tier configuration)

MariaDB Server Underutilized

MariaDB servers with low CPU usage but active connections should be reviewed to determine whether the current size is appropriate.

Mavvrik evaluates MariaDB server utilization over a configurable lookback period, with 14 days used by default. A server is flagged as underutilized when the 95th percentile of Max CPU % falls within the configured CPU threshold range, with 0%–40% used by default, and Max Active Connections > 0. These thresholds can be adjusted by the customer based on their environment and workload requirements.

Review the MariaDB server workload, performance requirements, and connection activity. If the server is consistently underutilized, consider resizing to a smaller compute tier or adjusting capacity based on application needs.

CPU % (95th percentile, Max) + Max Active Connections

MySQL Flexible Server Underutilized

MySQL Flexible Servers with low CPU usage but active connections should be reviewed to determine whether the current size is appropriate.

Mavvrik evaluates MySQL Flexible Server utilization over a configurable lookback period, with 14 days used by default. A server is flagged as underutilized when the 95th percentile of Max CPU % falls within the configured CPU threshold range, with 0%–40% used by default, and Max Active Connections > 0. These thresholds can be adjusted by the customer based on their environment and workload requirements.

Review the MySQL Flexible Server workload, performance requirements, and connection activity. If the server is consistently underutilized, consider resizing to a smaller compute tier or adjusting capacity based on application needs.

CPU % (95th percentile, Max) + Max Active Connections

MySQL Single Server Underutilized

MySQL Single Servers with low CPU usage but active connections should be reviewed to determine whether the current size is appropriate.

Mavvrik evaluates MySQL Single Server utilization over a configurable lookback period, with 14 days used by default. A server is flagged as underutilized when the 95th percentile of Max CPU % falls within the configured CPU threshold range, with 0%–40% used by default, and Max Active Connections > 0. These thresholds can be adjusted by the customer based on their environment and workload requirements.

Review the MySQL Single Server workload, performance requirements, and connection activity. If the server is consistently underutilized, consider resizing to a smaller compute tier or adjusting capacity based on application needs.

CPU % (95th percentile, Max) + Max Active Connections

PostgreSQL Single Server Underutilized

PostgreSQL Single Servers with low CPU usage but active connections should be reviewed to determine whether the current size is appropriate.

Mavvrik evaluates PostgreSQL Single Server utilization over a configurable lookback period, with 14 days used by default. A server is flagged as underutilized when the 95th percentile of Max CPU % falls within the configured CPU threshold range, with 0%–40% used by default, and Max Active Connections > 0. This threshold can be adjusted by the customer based on their environment and workload requirements.

Review the PostgreSQL Single Server workload, performance requirements, and connection activity. If the server is consistently underutilized, consider resizing to a smaller compute tier or adjusting capacity based on application needs.

CPU % (95th percentile, Max) + Max Active Connections

Long Running SQL Database

Long-running SQL database instances should be reviewed to determine whether they are good candidates for reserved instance coverage.

Mavvrik evaluates SQL database runtime over a configurable lookback period, with 90 days used by default. Databases that have been running consistently during the selected period are flagged as potential reservation candidates because reserved instances can provide discounted pricing for predictable, long-running workloads.

Review the SQL database usage pattern, expected runtime, and future workload plans. If the database is expected to continue running, consider associating it with a reserved instance to reduce long-term costs.

N/A (instance age/runtime)

Virtual Machine Disable Premium SSD

Virtual machines using Premium SSD disks should be reviewed to determine whether Premium storage performance is required.

Mavvrik evaluates Premium SSD disk usage attached to virtual machines over a configurable lookback period, with 14 days used by default. A VM is flagged when the attached Premium SSD disk usage is below 6,000 IOPS and 750 MiB/s throughput during the selected period, indicating that a lower-cost storage tier may be sufficient. VMs running SQL Server workloads are excluded from this recommendation.

Review the VM disk performance requirements and workload dependency. If Premium SSD performance is not required, consider switching to Standard SSD storage to reduce storage costs.

Max Read/Write IOPS + Max Read/Write Throughput (Avg)

Long Running Virtual Machines

Long-running virtual machines should be reviewed to determine whether they are good candidates for reserved instance coverage or other commitment-based discounts.

Mavvrik evaluates VM runtime over a configurable lookback period, with 90 days used by default. Virtual machines that have been running consistently during the selected period are flagged as potential commitment candidates because reserved instances or similar purchasing options can reduce costs for predictable, long-running workloads.

Review the VM usage pattern, expected runtime, and future workload plans. If the VM is expected to continue running, consider applying reserved instance coverage or another suitable commitment option to reduce long-term costs.

N/A (instance age/runtime)

Virtual Machine Underutilized

Virtual machines with low CPU utilization should be reviewed to determine whether the current VM size is appropriate.

Mavvrik evaluates VM CPU utilization over a configurable lookback period, with 14 days used by default. A VM is flagged as underutilized when the 95th percentile of Max CPU % falls within the configured CPU threshold range, with 6%–40% used by default. The CPU threshold can be adjusted by the customer based on their environment and workload requirements.

Review the VM workload, performance requirements, and utilization pattern. If the VM is consistently underutilized, consider downsizing to a smaller VM size to reduce compute costs.

Max/Avg CPU % (95th percentile)

SQL DTU Database Underutilized

SQL DTU databases with low utilization but active sessions should be reviewed to determine whether the current database size is appropriate.

Mavvrik evaluates SQL DTU database utilization over a configurable lookback period, with 14 days used by default. A database is flagged as underutilized when the 95th percentile of Max DTU Consumption % falls within the configured threshold range, with 0%–40% used by default, and Max Sessions Count > 0. Only databases with non-zero monthly cost are evaluated. This threshold can be adjusted by the customer based on their environment and workload requirements.

Review the SQL DTU database workload, performance requirements, and session activity. If the database is consistently underutilized, consider resizing to a lower DTU tier or adjusting capacity based on application needs.

DTU Consumption % (95th percentile, Max) + Max Sessions Count

Disk is Unattached

Unattached disks should be reviewed to determine whether they are still required, as they may continue to incur storage costs even when not connected to a virtual machine.

Mavvrik evaluates disk attachment status over a configurable lookback period, with 14 days used by default. A disk is flagged as orphaned when it is currently unattached, has existed for at least the selected period, and has shown no read activity during that time, indicating it is not associated with an active virtual machine.

Review the disk ownership, backup needs, and recovery requirements. If the disk is no longer required, consider deleting it to eliminate unnecessary storage costs.

Public IP Unattached

Unattached Azure Public IP addresses should be reviewed to determine whether they are still required, as they may continue to incur costs when not associated with an active resource.

Mavvrik evaluates Azure Public IP attachment status. This recommendation is event-based, so a lookback period is not applicable. A Public IP address is flagged as orphaned when it currently has no IP configuration, no associated NAT Gateway, and no associated Public IP Prefix. Note: only Standard SKU Public IPs are evaluated — Basic SKU IPs are excluded from this recommendation.

Review the Public IP ownership and dependency. If the Public IP address is no longer required, consider deleting it to eliminate unnecessary costs.

CloudWatch Unused Log Streams

Unnecessary or inactive CloudWatch log streams should be reviewed to determine whether they are still required.

Mavvrik evaluates CloudWatch log stream activity over a configurable lookback period, with 90 days used by default. A log group is flagged when at least one of its log streams has had no ingestion activity during the selected period, indicating it may no longer be needed.

Review the log stream ownership, retention requirements, and application dependency. If the log stream is no longer required, consider deleting it to reduce CloudWatch storage costs.

N/A (log stream last-ingestion timestamp)

EMR Cluster Unused

Amazon EMR clusters with no active workload activity should be reviewed to determine whether they are still required.

Mavvrik evaluates EMR cluster activity over a configurable lookback period, with 14 days used by default. A cluster is flagged when it has at least one hour flagged idle (no running tasks) during the selected period. Only clusters currently in a WAITING state are evaluated.

Review the EMR cluster ownership, job schedule, and workload dependency. If the cluster is no longer required, consider terminating it to reduce unnecessary compute costs.

IsIdle (Avg, hourly)

EC2 Instance Idle

EC2 instances with very low CPU utilization should be reviewed to determine whether they are still required.

Mavvrik evaluates EC2 CPU utilization over a configurable lookback period, with 14 days used by default. An instance is flagged as idle when the 95th percentile of Max CPU % falls within the configured CPU threshold range, with 0%–5% used by default. The CPU threshold can be adjusted by the customer based on their environment and workload requirements.

Review the EC2 instance usage pattern, workload dependency, and business criticality. If there are occasional peaks above the idle threshold, consider downsizing the instance. If there is no meaningful utilization, consider stopping or terminating the instance.

CPU % (95th percentile, Max)

EC2 NAT Gateway Unused

Unused EC2 NAT Gateways with no active connections should be reviewed to determine whether they are still required.

Mavvrik evaluates NAT Gateway connection activity over a configurable lookback period, with 30 days used by default. A NAT Gateway is flagged when it has had zero active connections during the selected period, indicating it may no longer be actively used.

Review the NAT Gateway ownership, routing dependency, and workload requirements. If the NAT Gateway is no longer required, consider deleting it to reduce unnecessary networking costs.

Max Active Connections

EC2 Volume Attached To Stopped EC2 Instance

EBS volumes attached to stopped EC2 instances should be reviewed to determine whether they are still required.

Mavvrik evaluates EC2 volume attachment and instance state over a configurable lookback period, with 7 days used by default. A volume is flagged when it remains attached to an EC2 instance that is currently stopped and has generated no billing activity during the selected period, indicating the volume may be incurring storage costs without supporting an active workload.

Review the stopped EC2 instance and attached volume dependency. If the volume is no longer required, consider deleting or archiving it based on internal retention and recovery requirements.

N/A (instance state + billing activity check)

EC2 Volume Idle

EBS volumes with no meaningful usage should be reviewed to determine whether they are still required.

Mavvrik evaluates EBS volume activity over a configurable lookback period, with 14 days used by default. A volume attached to a running instance is flagged as idle when combined read/write throughput and bandwidth are zero during the selected period, indicating it may be incurring storage costs without supporting an active workload.

Review the EBS volume ownership, attachment history, backup needs, and recovery requirements. If the volume is no longer required, consider archiving or deleting it to reduce unnecessary storage costs.

Read/Write Throughput + Read/Write Bandwidth

EC2 Old Volume Snapshot

Old EBS snapshots should be reviewed to determine whether they are still required for backup, recovery, or retention purposes.

Mavvrik evaluates EBS snapshots based on a configurable age threshold, with 90 days used by default. A snapshot is flagged when its age exceeds the selected threshold, indicating it may be unnecessary or costly to maintain.

Review the snapshot ownership, retention policy, and recovery requirements. If the snapshot is no longer required, consider deleting or archiving it based on internal backup and compliance requirements.

N/A (snapshot age)

ECS Cluster Idle

ECS clusters with little or no usage should be reviewed to determine whether they are still required.

Mavvrik evaluates ECS cluster activity over a configurable lookback period, with 14 days used by default. A cluster is flagged as idle when average CPU utilization falls within the configured threshold range, with 0%–5% used by default, indicating the cluster may not be supporting active workloads. This threshold can be adjusted by the customer based on their environment and workload requirements. Note: only EC2-backed clusters are evaluated — clusters running purely on Fargate/Fargate Spot are excluded, since idle CPU is not a meaningful signal for serverless compute.

Review the ECS cluster ownership, running services, tasks, and workload dependency. If the cluster is no longer required, consider archiving or deleting it to reduce unnecessary costs.

Avg CPU %

ELB Classic Unused

Classic Elastic Load Balancers with no healthy attached instances or no traffic should be reviewed to determine whether they are still required.

Mavvrik evaluates Classic ELB host health and request activity over a configurable lookback period, with 14 days used by default. A Classic Load Balancer is flagged as unused when it has zero healthy hosts while having one or more unhealthy hosts registered, or when it has received zero requests during the selected period.

Review the Classic Load Balancer ownership, traffic routing, and application dependency. If the load balancer is no longer required, consider deleting it to reduce unnecessary costs.

Healthy/Unhealthy Host Count (Avg) + Request Count (Sum)

ELB V2 Idle

Application Load Balancers with no traffic should be reviewed to determine whether they are still required.

Mavvrik evaluates ELB V2 request activity over a configurable lookback period, with 14 days used by default. A load balancer is flagged as idle when it has received zero requests during the selected period, indicating it may not be serving application traffic.

Review the load balancer ownership, listener configuration, target groups, and application dependency. If the load balancer is no longer required, consider deleting it to reduce unnecessary costs.

Request Count (Sum)

OpenSearch Cluster Idle

OpenSearch clusters with very low CPU utilization should be reviewed to determine whether they are still required.

Mavvrik evaluates OpenSearch cluster CPU utilization over a configurable lookback period, with 14 days used by default. A cluster is flagged as idle when the average CPU utilization falls within the configured threshold range, with 0%–5% used by default. This threshold can be adjusted by the customer based on their environment and workload requirements.

Review the OpenSearch cluster ownership, workload dependency, and business need. If the cluster is no longer required, consider archiving or terminating it to reduce unnecessary costs.

Avg CPU %

RDS DB Instance Idle

RDS DB instances with no active database connections should be reviewed to determine whether they are still required.

Mavvrik evaluates RDS DB connection activity over a configurable lookback period, with 14 days used by default. A DB instance is flagged as idle when there are zero active DB connections during the selected period.

Review the RDS DB instance ownership, application dependency, and retention requirements. If the DB instance is no longer required, consider stopping, terminating, or archiving it based on internal backup and recovery requirements.

Max Database Connections

Redshift Cluster Idle

Redshift clusters with no active database connections should be reviewed to determine whether they are still required.

Mavvrik evaluates Redshift cluster connection activity over a configurable lookback period, with 14 days used by default. A cluster is flagged as idle when there are zero database connections during the selected period. Clusters currently in a paused state are excluded.

Review the Redshift cluster ownership, workload dependency, and business need. If the cluster is no longer required, consider archiving or deleting it to reduce unnecessary costs.

Database Connections (Max)

Secret Unused

Unused AWS Secrets Manager secrets should be reviewed to determine whether they are still required.

Mavvrik evaluates Secrets Manager secret usage based on a configurable staleness threshold, with 30 days used by default. A secret is flagged as unused when it has not been accessed (falling back to creation date if never accessed) for at least the selected period, indicating it may no longer be required by active workloads.

Review the secret ownership, application dependency, and retention requirements. If the secret is no longer required, consider archiving or deleting it to reduce unnecessary costs and improve hygiene.

N/A (last-accessed / created date)

Workspace Idle

WorkSpaces with no user connection activity should be reviewed to determine whether they are still required.

Mavvrik evaluates WorkSpace user connection activity over a configurable lookback period, with 30 days used by default. A WorkSpace is flagged as idle when there are zero users connected during the selected period, the WorkSpace has recorded some uptime, and at least 7 days of connection data are available, indicating it may no longer be actively used.

Review the WorkSpace ownership, assigned user, and business need. If the WorkSpace is no longer required, consider archiving it first and then deleting it based on internal retention requirements.

Max User Connected

CloudTrails Redundant Global Trails

Redundant global CloudTrails should be reviewed to determine whether they are required, since additional trails may increase costs.

Mavvrik evaluates the count of multi-region CloudTrails per AWS account. This recommendation is event-based, so a lookback period is not applicable. Accounts with more than one multi-region trail are flagged as potential redundancy because additional trails may create duplicate logging and unnecessary costs.

Review the CloudTrail configuration, logging requirements, and compliance needs for the account. If additional global trails are not required, consider consolidating or removing redundant CloudTrails to reduce costs.

N/A (trail count per account)

CloudTrails Redundant Regional Trails

Redundant regional CloudTrails should be reviewed to determine whether they are required, since additional trails may increase costs.

Mavvrik evaluates the count of single-region CloudTrails per AWS account and location/region. This recommendation is event-based, so a lookback period is not applicable. Regions with more than one trail are flagged as potential redundancy because additional regional trails may create duplicate logging and unnecessary costs.

Review the CloudTrail configuration, logging requirements, and compliance needs for each region. If additional regional trails are not required, consider consolidating or removing redundant CloudTrails to reduce costs.

N/A (trail count per region)

EC2 Instance Older Generation

Older generation EC2 instances should be reviewed to determine whether a newer, more cost-effective instance family is available.

Mavvrik identifies EC2 instances running on older generation instance families, such as t2, m3, or m4, over a configurable lookback period, with 14 days used by default. This recommendation is event-based beyond the age check — these instances are flagged because newer generation instance types, such as t3 or m5, may offer better price-performance.

Review the instance family, workload compatibility, and performance requirements. If supported by the application, consider migrating to a newer generation instance type to improve cost efficiency.

N/A (instance family/type)

EC2 Instance Underutilized

EC2 instances with low CPU utilization should be reviewed to determine whether the current instance size is appropriate.

Mavvrik evaluates EC2 CPU utilization over a configurable lookback period, with 14 days used by default. An instance is flagged as underutilized when the 95th percentile of Max CPU % falls within the configured CPU threshold range, with 6%–40% used by default. The CPU threshold can be adjusted by the customer based on their environment and workload requirements.

Review the EC2 instance workload, performance requirements, and utilization pattern. If the instance is consistently underutilized, consider downsizing to a smaller instance type to reduce compute costs.

CPU % (95th percentile, Max)

EC2 Instance with Graviton Processor

EC2 instances that may benefit from AWS Graviton processors should be reviewed to determine whether a more cost-efficient instance option is available.

Mavvrik identifies EC2 instances that may be eligible to move to Graviton-based instance types. This recommendation is event-based, so a lookback period is not applicable. These instances are flagged because Graviton processors may offer better price-performance for compatible workloads. Note: this recommendation is disabled by default and must be explicitly enabled to generate results.

Review the application compatibility, operating system, architecture requirements, and performance needs. If the workload supports ARM-based instances, consider migrating to a Graviton-based EC2 instance type to improve cost efficiency.

N/A (processor architecture eligibility)

Large EC2 Instance

Large EC2 instances should be reviewed to determine whether the current instance size is required for the workload.

Mavvrik identifies EC2 instances that are running on large or high-cost instance sizes. This recommendation is event-based, so a lookback period is not applicable. These instances are flagged because oversized instances may increase compute costs if the workload does not require that level of capacity. Note: this recommendation is disabled by default and must be explicitly enabled to generate results.

Review the instance size, workload dependency, performance requirements, and utilization pattern. If the instance is larger than needed, consider resizing to a smaller or more cost-effective instance type.

N/A (instance size classification)

EC2 Long Running Instance

Long-running EC2 instances should be reviewed to determine whether they are good candidates for savings plans, reserved instances, or other commitment-based discounts.

Mavvrik evaluates EC2 instance runtime over a configurable lookback period, with 30 days used by default. Instances that have been running consistently during the selected period are flagged as potential commitment candidates because predictable, long-running workloads may be eligible for discounted pricing options. Note: this recommendation is disabled by default and must be explicitly enabled to generate results.

Review the EC2 instance usage pattern, expected runtime, and future workload plans. If the instance is expected to continue running, consider applying a suitable commitment option to reduce long-term compute costs.

N/A (instance age/runtime)

EC2 Volume GP2 to GP3

EBS gp2 volumes should be reviewed to determine whether they can be migrated to gp3 for better cost and performance efficiency.

Mavvrik identifies EBS volumes using the gp2 volume type over a configurable lookback period, with 30 days used by default, and models estimated cost savings based on actual usage. These volumes are flagged because gp3 can provide more flexible performance configuration and may reduce storage costs compared to gp2.

Review the volume performance requirements and application dependency. If compatible, consider migrating gp2 volumes to gp3 to improve cost efficiency and performance flexibility.

N/A (volume type + usage-based cost modeling)

EC2 Volume High IOPS

High IOPS io1/io2 EBS volumes should be reviewed to confirm whether the current performance configuration is required.

Mavvrik identifies EBS volumes using io1/io2 volume types with provisioned IOPS above 32,000. This recommendation is event-based, so a lookback period is not applicable. These volumes are flagged because provisioned high IOPS storage can be costly if the workload does not require that level of performance.

Review the volume performance requirements, workload dependency, and actual IOPS usage. If high IOPS is not required, consider moving to a more cost-effective EBS volume type or lowering the provisioned performance configuration.

N/A (provisioned IOPS configuration, fixed threshold)

EC2 Volume Unreliable IOPS

io1 EBS volumes should be reviewed to determine whether io2 provides better reliability for the same cost.

Mavvrik identifies EBS volumes using the io1 volume type. This recommendation is event-based, so a lookback period is not applicable. io1 volumes are flagged because io2 may provide improved reliability and performance characteristics at a similar cost. Note: this recommendation is disabled by default and must be explicitly enabled to generate results.

Review the volume type, workload criticality, and performance requirements. If appropriate, consider migrating io1 volumes to io2 for improved reliability.

N/A (volume type)

EC2 Low IOPS

EBS volumes with low provisioned IOPS requirements should be reviewed to determine whether gp3 is a better fit.

Mavvrik identifies EBS volumes using io1/io2 volume types with provisioned IOPS at or below 16,000, where gp3 may support the required baseline performance more cost-effectively. This recommendation is event-based, so a lookback period is not applicable.

Review the volume performance requirements and application dependency. If gp3 can meet the workload needs, consider migrating from io1/io2 to gp3 to reduce storage costs while maintaining required performance.

N/A (provisioned IOPS configuration, fixed threshold)

EC2 Volume Size Too Large

Large EBS volumes should be reviewed to confirm whether the allocated storage capacity is required.

Mavvrik identifies EBS volumes with large provisioned capacity. This recommendation is event-based, so a lookback period is not applicable. These volumes are flagged because oversized storage can increase costs when the workload does not require that level of capacity. Note: this recommendation is disabled by default and must be explicitly enabled to generate results.

Review the volume size, workload dependency, and actual storage requirements. If the volume is larger than needed, consider resizing or migrating to a more cost-effective volume configuration where supported and safe to do so.

N/A (provisioned volume size)

ECS Cluster Underutilized

ECS clusters with low utilization should be reviewed to determine whether the current cluster capacity is appropriate.

Mavvrik evaluates ECS cluster utilization over a configurable lookback period, with 14 days used by default. A cluster is flagged as underutilized when the average CPU utilization falls within the configured threshold range, with 6%–40% used by default. This threshold can be adjusted by the customer based on their environment and workload requirements. Only EC2-backed clusters are evaluated — Fargate/Fargate Spot-only clusters are excluded.

Review the ECS cluster services, running tasks, workload dependency, and capacity requirements. If the cluster is consistently underutilized, consider reducing capacity, resizing the underlying compute resources, or adjusting scaling configuration.

Avg CPU %

Lambda Function with High Error Rate

Lambda functions with high error rates should be reviewed because repeated failures and retries may increase execution costs.

Mavvrik evaluates Lambda function error activity over a configurable lookback period, with 14 days used by default. A Lambda function is flagged when the error rate is greater than 10% during the selected period, indicating that failed executions or retries may be contributing to additional charges. Note: this recommendation is disabled by default and must be explicitly enabled to generate results.

Review the Lambda function errors, retry behavior, logs, and application dependency. If errors are unexpected, investigate and resolve the root cause to reduce failed executions and unnecessary costs.

Error Count + Invocation Count

Lambda Function Without Graviton Processor

Lambda functions not using Graviton/Arm64 architecture should be reviewed to determine whether they can run more cost efficiently.

Mavvrik identifies Lambda functions that are not configured to use the Graviton/Arm64 processor architecture. This recommendation is event-based, so a lookback period is not applicable. These functions are flagged because Graviton-based execution may provide better price-performance for compatible workloads. Note: this recommendation is disabled by default and must be explicitly enabled to generate results.

Review the Lambda function runtime, dependencies, and architecture compatibility. If the function supports Arm64, consider changing the processor architecture to Graviton/Arm64 to improve cost efficiency.

N/A (processor architecture configuration)

Lambda Function with Excessive Timeout

Lambda functions with timeout settings higher than expected should be reviewed because excessive timeout values may increase execution duration and retry-related costs.

Mavvrik evaluates Lambda function timeout behavior over a configurable lookback period, with 14 days used by default. A function is flagged when its configured timeout appears high compared to its average execution duration, indicating the timeout setting may be larger than required. Note: this recommendation is disabled by default and must be explicitly enabled to generate results.

Review the Lambda function execution duration, timeout setting, retry behavior, and application dependency. If the configured timeout is higher than needed, consider reducing the timeout value to better align with actual function runtime.

Avg Duration (vs. configured timeout)

OpenSearch Cluster Underutilized

OpenSearch clusters with low utilization should be reviewed to determine whether the current cluster size is appropriate.

Mavvrik evaluates OpenSearch cluster utilization over a configurable lookback period, with 14 days used by default. A cluster is flagged as underutilized when the average CPU utilization falls within the configured threshold range, with 6%–40% used by default. This threshold can be adjusted by the customer based on their environment and workload requirements.

Review the OpenSearch cluster workload, performance requirements, and utilization pattern. If the cluster is consistently underutilized, consider resizing or reducing capacity to better match workload demand.

Avg CPU %

RDS DB Instance Underutilized

RDS DB instances with low utilization should be reviewed to determine whether the current instance size is appropriate.

Mavvrik evaluates RDS DB instance CPU utilization over a configurable lookback period, with 14 days used by default. A DB instance is flagged as underutilized when the 95th percentile of Max CPU % falls within the configured threshold range, with 6%–40% used by default, and Max Database Connections > 0. This threshold can be adjusted by the customer based on their environment and workload requirements.

Review the RDS DB instance workload, performance requirements, and utilization pattern. If the instance is consistently underutilized, consider resizing to a smaller DB instance class or adjusting capacity based on application needs.

CPU % (95th percentile, Max) + Max Database Connections

RDS DB Instance Without Graviton Processor

RDS DB instances not using Graviton/Arm64 architecture should be reviewed to determine whether they can run more cost efficiently.

Mavvrik identifies RDS DB instances that are not configured to use Graviton/Arm64 processor architecture. This recommendation is event-based, so a lookback period is not applicable. These instances are flagged because Graviton processors may offer better price-performance for compatible database workloads. Note: this recommendation is disabled by default and must be explicitly enabled to generate results.

Review the database engine, instance class compatibility, workload requirements, and performance needs. If the workload supports Graviton-based RDS instances, consider migrating to a compatible Graviton/Arm64 instance class to improve cost efficiency.

N/A (processor architecture eligibility)

RDS DB Long Running Instance

Long-running RDS DB instances should be reviewed to determine whether they are good candidates for reserved instance coverage.

Mavvrik evaluates RDS DB instance runtime over a configurable lookback period, with 30 days used by default. DB instances that have been running consistently during the selected period are flagged as potential reservation candidates because reserved instances can provide discounted pricing for predictable, long-running database workloads. Note: this recommendation is disabled by default and must be explicitly enabled to generate results.

Review the RDS DB instance usage pattern, expected runtime, and future workload plans. If the DB instance is expected to continue running, consider applying reserved instance coverage to reduce long-term costs.

N/A (instance age/runtime)

RDS DB Old Generation Instance

RDS DB instances using older generation instance types should be reviewed to determine whether a newer, more cost-effective instance type is available.

Mavvrik identifies RDS DB instances created with older generation instance types, such as t2, m3, and m4. This recommendation is event-based, so a lookback period is not applicable. These instances are flagged because newer generation instance types, such as t3 and m5, may provide better cost efficiency.

Review the database engine, instance type compatibility, workload requirements, and performance needs. If supported, consider moving to a newer generation DB instance type, such as t3 or m5, to improve cost efficiency.

N/A (instance family/type)

Redshift Cluster Underutilized

Redshift clusters with low utilization should be reviewed to determine whether the current cluster size is appropriate.

Mavvrik evaluates Redshift cluster utilization over a configurable lookback period, with 14 days used by default. A cluster is flagged as underutilized when the 95th percentile CPU utilization falls within the configured threshold range, with 6%–40% used by default. This threshold can be adjusted by the customer based on their environment and workload requirements.

Review the Redshift cluster workload, performance requirements, and utilization pattern. If the cluster is consistently underutilized, consider resizing or reducing capacity to better match workload demand.

CPU Utilization (95th percentile)

Redshift Long Running Cluster

Long-running Redshift clusters should be reviewed to determine whether they are good candidates for reserved node coverage.

Mavvrik evaluates Redshift cluster age over a configurable lookback period, with 30 days used by default, and excludes clusters already covered by a reservation. Clusters old enough and not yet reservation-covered are flagged as potential reservation candidates because reserved nodes can provide discounted pricing for predictable, long-running workloads.

Review the Redshift cluster usage pattern, expected runtime, and future workload plans. If the cluster is expected to continue running, consider applying reserved node coverage to reduce long-term costs.

N/A (cluster age + reservation coverage check)

S3 Bucket Move To IA Storage Classes

S3 buckets using only Standard Storage should be reviewed to determine whether Infrequent Access storage is more cost-effective.

Mavvrik evaluates S3 bucket storage class and access activity over a configurable lookback period, with 30 days used by default. A bucket is flagged when its storage cost is made up only of Standard Storage and there has been no access activity during the selected period, based on operations such as PutObject, PutObjectForRepl, GetObject, or CopyObject.

Review the bucket access pattern, retrieval requirements, and lifecycle policy. If the data is accessed infrequently, consider moving eligible objects from Standard Storage to an Infrequent Access storage class to reduce storage costs.

N/A (storage class + access-operation activity)

Workspaces Usage Plan Hourly to Monthly

WorkSpaces on hourly billing should be reviewed to determine whether monthly billing would be more cost-effective.

Mavvrik evaluates WorkSpace usage over a configurable lookback period, with 30 days used by default. A WorkSpace on hourly billing is flagged once its usage crosses a fixed 100-hour monthly threshold, at which point monthly billing becomes more cost-effective.

Review the WorkSpace usage pattern, assigned user, and billing mode. If the WorkSpace is used consistently, consider switching from hourly billing to monthly billing to reduce costs.

Up-time Hours (Monthly)

EC2 Elastic IP Unused

Unused Elastic IP addresses should be reviewed to determine whether they are still required, as unattached Elastic IPs may continue to incur costs.

Mavvrik evaluates Elastic IP attachment status. This recommendation is event-based, so a lookback period is not applicable. An Elastic IP is flagged as orphaned when it currently has zero associated resources.

Review the Elastic IP ownership and dependency. If the Elastic IP is no longer required, consider releasing it to eliminate unnecessary costs.

EC2 Volume Unused

Unused EBS volumes should be reviewed to determine whether they are still required, as unattached volumes may continue to incur storage costs.

Mavvrik evaluates EBS volume attachment status over a configurable lookback period, with 14 days used by default. A volume is flagged as orphaned when it is currently unattached, has existed for at least the selected period, and has shown no read activity during that time.

Review the EBS volume ownership, backup needs, and recovery requirements. If the volume is no longer required, consider deleting or archiving it to reduce unnecessary storage costs.

Cloud Run Instance Idle

Cloud Run instances with very low CPU utilization should be reviewed to determine whether they are still required.

Mavvrik evaluates Cloud Run CPU utilization over a configurable lookback period, with 14 days used by default. A Cloud Run instance is flagged as idle when the 95th percentile of Max CPU % falls within the configured CPU threshold range, with 0%–5% used by default. The CPU threshold can be adjusted by the customer based on their environment and workload requirements.

Review the Cloud Run service ownership, traffic pattern, and workload dependency. If the instance is no longer required or has no meaningful utilization, consider deleting or reducing the service configuration to reduce unnecessary costs.

CloudSQL Instance Idle

CloudSQL instances with no active connections should be reviewed to determine whether they are still required.

Mavvrik evaluates CloudSQL connection activity over a configurable lookback period, with 14 days used by default. A CloudSQL instance is flagged as idle when it has 0 active connections during the selected period.

Review the CloudSQL instance ownership, application dependency, and retention requirements. If the instance is no longer required, consider stopping, deleting, or archiving it based on internal backup and recovery requirements.

Compute Instance Idle

Compute instances with very low CPU utilization should be reviewed to determine whether they are still required.

Mavvrik evaluates Compute instance CPU utilization over a configurable lookback period, with 14 days used by default. A Compute instance is flagged as idle when the 95th percentile of Max CPU % falls within the configured CPU threshold range, with 0%–5% used by default. The CPU threshold can be adjusted by the customer based on their environment and workload requirements.

Review the Compute instance usage pattern, workload dependency, and business criticality. If the instance is no longer required or has no meaningful utilization, consider stopping or deleting it to reduce unnecessary costs.

Disks Attached To Stopped Instances - GCP

Disks attached to stopped GCP Compute instances should be reviewed to determine whether they are still required.

Mavvrik identifies disks that remain attached to Compute instances in a terminated (stopped) state. This recommendation is event-based, so a lookback period is not applicable. These disks are flagged because they may continue to incur storage costs even when the associated instance is not running.

Review the stopped Compute instance and attached disk dependency. If the disk is no longer required, consider detaching, deleting, or archiving it based on internal retention and recovery requirements.

Disk is Idle - GCP

GCP disks with no read/write activity should be reviewed to determine whether they are still required.

Mavvrik evaluates attached, non-boot disk activity over a configurable lookback period, with 14 days used by default. A disk is flagged as idle when Disk IOPS + Throughput = 0 during the selected period, indicating no disk read/write operations or read/write bytes. Boot (OS) disks and unattached disks are not evaluated by this recommendation.

Review the disk ownership, attachment history, and recovery requirements. If the disk is no longer required, consider deleting or archiving it to reduce unnecessary storage costs.

Cloud Run Instance Underutilized

Cloud Run instances with low CPU utilization should be reviewed to determine whether the current configuration is appropriate.

Mavvrik evaluates Cloud Run CPU utilization over a configurable lookback period, with 14 days used by default. A Cloud Run instance is flagged as underutilized when the 95th percentile of Max CPU % falls within the configured CPU threshold range, with 6%–40% used by default. The CPU threshold can be adjusted by the customer based on their environment and workload requirements.

Review the Cloud Run service usage, traffic pattern, and performance requirements. If the instance is consistently underutilized, consider reducing the service configuration or adjusting capacity to better match workload demand.

CloudSQL Instance Underutilized

CloudSQL instances with low CPU utilization but active connections should be reviewed to determine whether the current instance size is appropriate.

Mavvrik evaluates CloudSQL CPU utilization over a configurable lookback period, with 14 days used by default. A CloudSQL instance is flagged as underutilized when the 95th percentile of Max CPU % falls within the configured CPU threshold range, with 6%–40% used by default, and Max Network Connections > 0. The CPU threshold can be adjusted by the customer based on their environment and workload requirements.

Review the CloudSQL instance workload, performance requirements, and utilization pattern. If the instance is consistently underutilized, consider resizing to a smaller instance configuration or adjusting capacity based on application needs.

Long Running Compute Instances

Long-running Compute instances should be reviewed to determine whether they are good candidates for committed use discounts or other commitment-based savings.

Mavvrik evaluates Compute instance runtime over a configurable lookback period, with 90 days used by default. Currently running instances older than the selected period are flagged as potential commitment candidates because predictable, long-running workloads may be eligible for discounted pricing options.

Review the Compute instance usage pattern, expected runtime, and future workload plans. If the instance is expected to continue running, consider applying a suitable committed use discount or commitment option to reduce long-term compute costs.

Compute Instance Underutilized

Compute instances with low CPU utilization should be reviewed to determine whether the current instance size is appropriate.

Mavvrik evaluates Compute instance CPU utilization over a configurable lookback period, with 14 days used by default. A Compute instance is flagged as underutilized when the 95th percentile of Max CPU % falls within the configured CPU threshold range, with 6%–40% used by default. The CPU threshold can be adjusted by the customer based on their environment and workload requirements.

Review the Compute instance workload, performance requirements, and utilization pattern. If the instance is consistently underutilized, consider resizing to a smaller machine type or adjusting capacity based on workload demand.

Disk Size Too Large - GCP

Large GCP disks should be reviewed to confirm whether the allocated storage capacity is required.

Mavvrik identifies GCP disks with provisioned capacity above 100 GB. This recommendation is event-based, so a lookback period is not applicable. These disks are flagged because oversized storage can increase costs when the workload does not require that level of capacity.

Review the disk size, workload dependency, and actual storage requirements. If the disk is larger than needed, consider resizing or migrating to a more cost-effective disk configuration where supported and safe to do so.

Instances With More Than 32 vCPUs

Compute instances with more than 32 vCPUs should be reviewed to determine whether that level of compute capacity is required.

Mavvrik identifies currently running GCP Compute instances whose machine type indicates more than 32 vCPUs. This recommendation is event-based, so a lookback period is not applicable. These instances are flagged because large compute configurations can increase costs when the workload does not require that level of capacity.

Review the instance size, workload dependency, performance requirements, and utilization pattern. If the instance is larger than needed, consider resizing to a smaller machine type or optimizing the workload configuration.

Logging Buckets Long Retention Period

Logging buckets with long retention periods should be reviewed to determine whether the configured retention duration is required.

Mavvrik evaluates GCP logging bucket retention configuration against a configurable retention-day threshold, with 30 days used by default. A bucket is flagged when its configured retention period exceeds the selected threshold, indicating logs may be retained longer than needed.

Review the logging bucket retention policy, compliance requirements, and operational needs. If long-term retention is not required, consider reducing the retention period to better align with internal requirements and reduce storage costs.

Disk is Unattached - GCP

Unattached GCP disks should be reviewed to determine whether they are still required, as they may continue to incur storage costs when not connected to a Compute instance.

Mavvrik evaluates disk attachment history over a configurable lookback period, with 14 days used by default. A disk is flagged as orphaned when it has existed for at least the selected period, is currently unattached, and either has never been attached, or was last detached at least the selected number of days ago.

Review the disk ownership, backup needs, and recovery requirements. If the disk is no longer required, consider deleting or archiving it to reduce unnecessary storage costs.

Public IP Unattached

Unattached GCP Public IP addresses should be reviewed to determine whether they are still required, as they may continue to incur costs when not associated with an active resource.

Mavvrik evaluates GCP external Public IP attachment status. This recommendation is event-based, so a lookback period is not applicable. A Public IP address is flagged as orphaned when it is an external address with no associated resource.

Review the Public IP ownership and dependency. If the Public IP address is no longer required, consider releasing or deleting it to eliminate unnecessary costs.