How Savings Recommendations Are Generated

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.

Disks attached to Stopped VM

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

Mavvrik identifies disks that remain attached to virtual machines in a stopped 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.

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.

Disk is idle

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

Mavvrik evaluates disk activity 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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

SQL DTU Database Idle

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

Mavvrik evaluates SQL DTU 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.

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

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 CPU utilization falls within the configured CPU threshold range, with 0%–40% used by default, and memory utilization 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.

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.

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 high IOPS capability. This recommendation is event-based, so a lookback period is not applicable. 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.

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 large provisioned capacity that may be oversized for the associated workload. This recommendation is event-based, so a lookback period is not applicable. 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.

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.

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.

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.

PostgreSQL Flexible Server Overutilized

PostgreSQL Flexible Servers with high CPU usage and active connections should be reviewed to determine whether additional capacity is required.

Mavvrik evaluates PostgreSQL Flexible Server utilization over a configurable lookback period, with 14 days used by default. A server is flagged when the 95th percentile of Max CPU % meets the configured CPU threshold criteria, 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 Flexible Server workload, performance requirements, and connection activity. If the server requires more capacity, consider resizing to a larger compute tier or adjusting capacity based on workload demand.

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.

SQL DTU Database Idle

SQL DTU databases with low or no session activity should be reviewed to determine whether the current database configuration is still required.

Mavvrik evaluates SQL DTU database session activity over a configurable lookback period, with 14 days used by default. A database is flagged when session activity meets the configured threshold criteria, with 0%–40% used by default, and there are no sessions during the selected period, based on the Max Sessions Count metric. This threshold can be adjusted by the customer based on their environment and workload requirements.

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

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.

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.

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.

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.

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.

SQL DTU Database Underutilized

SQL DTU databases with low CPU usage 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 CPU % falls within the configured CPU threshold range, with 0%–40% used by default, and Max Sessions Count > 0. 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.

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 remains unattached during the selected period, 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 over a configurable lookback period, with 14 days used by default. A Public IP address is flagged as orphaned when it remains unattached during the selected period.

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 stream is flagged when it appears unused or inactive 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.

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 remains idle for more than 30 minutes without running tasks during the selected period.

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.

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.

EC2 NAT Gateway Unused

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

Mavvrik evaluates NAT Gateway attachment status over a configurable lookback period, with 30 days used by default. A NAT Gateway is flagged when it has no target attached 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.

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 in a stopped state 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.

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 is flagged as idle when it appears unused 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.

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.

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 usage 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.

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.

ELB Classic Unused

Classic Elastic Load Balancers without attached instances should be reviewed to determine whether they are still required.

Mavvrik evaluates Classic ELB attachment status over a configurable lookback period, with 14 days used by default. A Classic Load Balancer is flagged as unused when it has no attached instances during the selected period, indicating it may not be serving active traffic.

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.

ELB V2 Idle

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

Mavvrik evaluates ELB V2 configuration over a configurable lookback period, with 14 days used by default. A load balancer is flagged as idle when it has no listeners 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.

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.

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 no 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.

Redshift Cluster Idle

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

Mavvrik evaluates Redshift cluster CPU utilization over a configurable lookback period, with 14 days used by default. A cluster is flagged as idle when the 95th percentile 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 Redshift cluster ownership, workload dependency, and business need. If the cluster is no longer required, consider archiving or deleting it to reduce unnecessary costs.

Secret Unused

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

Mavvrik evaluates Secrets Manager secret usage over a configurable lookback period, with 30 days used by default. A secret is flagged as unused when it shows no meaningful usage during 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.

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, 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.

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 CloudTrails per AWS account. This recommendation is event-based, so a lookback period is not applicable. Accounts with more than the expected number of global trails 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.

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 CloudTrails per AWS account and location/region. This recommendation is event-based, so a lookback period is not applicable. Regions with more than the expected number of trails 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.

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. This recommendation is event-based, so a lookback period is not applicable. 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.

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.

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.

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.

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.

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.

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.

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.

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. 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.

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 high IOPS io1/io2 configurations. 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.

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.

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

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 where gp3 may support the required baseline performance more cost-effectively than io1/io2. This recommendation is event-based, so a lookback period is not applicable. Volumes are flagged when gp3 can provide the required baseline IOPS without requiring a higher-cost provisioned IOPS volume type.

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.

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.

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.

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 95th percentile 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 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.

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.

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.

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.

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.

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.

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.

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 95th percentile 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.

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 utilization over a configurable lookback period, with 14 days used by default. A DB instance is flagged as underutilized when the 95th percentile 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 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.

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.

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.

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.

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.

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.

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 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.

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 runtime over a configurable lookback period, with 30 days used by default. Clusters that have been running consistently during the selected period 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.

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.

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 is flagged when its usage pattern indicates that switching from hourly billing to a monthly plan may reduce costs.

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.

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 usage over a configurable lookback period, with 14 days used by default. An Elastic IP is flagged as orphaned when it remains unused or not associated with an active resource during the selected period.

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 not attached to any EC2 instance during the selected period.

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 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 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.

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.

Older Disk Snapshot - GCP

Older GCP 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 60 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.

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 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. 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. 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.

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 large provisioned capacity. 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 GCP Compute instances configured with 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 identifies GCP logging buckets configured with extended retention periods. This recommendation is event-based, so a lookback period is not applicable. These buckets are flagged because longer retention periods can increase logging storage costs when logs are retained beyond operational or compliance needs.

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 status over a configurable lookback period, with 14 days used by default. A disk is flagged as orphaned when it remains unattached during the selected period, indicating it is not associated with an active Compute instance.

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 Public IP attachment status over a configurable lookback period, with 14 days used by default. A Public IP address is flagged as orphaned when it remains unattached during the selected period.

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.