The cloud resources that waste the most money on AWS, Azure and Google Cloud, and how to find them with Active Findings

Cloud waste is surprisingly repetitive. Whatever the provider or the size of the bill, the same forgotten resources keep showing up, charging every hour while nobody uses them. Finding them by hand means walking through every console, region by region. In this article we go through those patterns, tell you which AAA Sentinel rule detects each one on AWS, Azure and Google Cloud, and show you how to work the Active Findings list until it becomes savings.

Why waste keeps repeating

Almost all useless spend comes from the same move: the main resource is deleted or stopped and the accessories survive. When you delete a virtual machine, its disk can stay behind. When you retire an environment, the reserved public IP, the load balancer or the NAT are still running. And whatever is in use is often sized for a peak that never came. None of these resources raise an alarm: they do not fail, they do not open incidents and their cost is diluted in a line of the bill.

What you get out of it

Detecting these resources systematically changes how you work on savings:

• One list for all three clouds, sorted by severity and by estimated monthly savings.
• Fixed, known criteria: every finding comes from a rule with a specific threshold, not from an opinion.
• Decisions that stick: whatever you dismiss or mark as resolved stays that way in later scans.
• A clear path from the finding to the fix, by hand, through a ticket or with the agent.

How AAA Sentinel solves it: scans, rules and findings

Every scan reads the resources and metrics of your connected accounts with read-only permissions and applies the analysis rules to them. Today there are 51 cost rules: 19 for AWS, 16 for Azure and 16 for Google Cloud. Each rule that matches produces a finding with a severity, a recommendation and an estimated monthly saving. Three screens cover the loop:

• Analysis rules: the full catalog, with the plan that includes each rule, the "Automatable" label when the agent can apply the fix, and a switch to turn it on or off.
• Scan History: every scan with its cost, its findings and the comparison with the previous one (new, disappeared, unchanged).
• Active Findings: the work list with every finding from the latest scan of each account.

Each pattern, its rule

These are the waste patterns and the rules that detect them, with their real thresholds. Free includes the basic rules; Pro adds the ones that need more detailed usage metrics.

• Unattached disks (Free): STORAGE_UNATTACHED_VOLUME on AWS (EBS volume in the available state), AZURE_DISK_UNATTACHED and GCP_DISK_UNATTACHED.
• Unassociated public IPs (Free): NETWORK_UNASSOCIATED_EIP on AWS, AZURE_IP_UNASSOCIATED and GCP_STATIC_IP_UNUSED.
• Stopped machines still paying for disks (Free): COMPUTE_STOPPED_WITH_VOLUME on AWS, AZURE_VM_STOPPED on Azure and GCP_VM_STOPPED on Google Cloud (stopped for at least a week).
• Nearly idle machines (Free): average CPU below 5% over 7 days, with COMPUTE_LOW_CPU, AZURE_COMPUTE_LOW_CPU and GCP_COMPUTE_LOW_CPU.
• Oversized machines (Pro): with 7-day average CPU below 20%, AWS_COMPUTE_RIGHTSIZE, AZURE_COMPUTE_RIGHTSIZE and GCP_COMPUTE_RIGHTSIZE propose going down exactly one size.
• Idle load balancers (Pro): NETWORK_IDLE_LB on AWS (an ALB averaging fewer than 10 requests a day over 7 days, or an NLB or GWLB processing less than 1 MiB a day) and AZURE_LB_IDLE (Standard load balancer with no traffic in 7 days) and GCP_LB_IDLE (forwarding rule with no traffic in 7 days, when deleting it lowers the forwarding rule fee).
• Databases with no connections (Pro): zero connections in 7 days (in Cloud SQL, at most a few brief stray ones), with DATABASE_ZERO_CONN_RDS, AZURE_SQL_ZERO_CONN and GCP_SQL_ZERO_CONNECTIONS.
• Orphan or underused NATs (Pro): NETWORK_ORPHAN_NAT, AZURE_NETWORK_ORPHAN_NAT and GCP_NETWORK_ORPHAN_NAT flag a NAT processing less than 1 GB a day with no routes or subnets depending on it. On AWS, NETWORK_UNDERUSED_NAT also flags a NAT under 1 GB a day even if it still has routes.
• Storage in an expensive class (Pro): buckets over 100 GB in the Standard class, with STORAGE_S3_WRONG_CLASS and GCP_GCS_WRONG_CLASS, and on Azure AZURE_STORAGE_WRONG_TIER, for accounts with over 100 GB in Hot, no lifecycle policy that moves the whole account down a tier and few reads in 30 days.
• Orphan snapshots (Free): STORAGE_ORPHAN_SNAPSHOT on AWS, for EBS snapshots whose source volume no longer exists, and AZURE_SNAPSHOT_ORPHAN and GCP_SNAPSHOT_ORPHAN, for snapshots older than 30 days whose source disk no longer exists.
• NoSQL databases with spare capacity (Pro): DATABASE_DYNAMO_OVERPROV on AWS and AZURE_COSMOS_OVERPROV on Azure, when they use less than 20% of what they reserve over 7 days.
• Previous-generation disks (Pro, AWS only): STORAGE_EBS_GP2_TO_GP3, for in-use gp2 volumes that would cost less as gp3 with the same performance.
• Versions on paid extended support (Pro): COMPUTE_EKS_EXTENDED_SUPPORT and DATABASE_RDS_EXTENDED_SUPPORT on AWS (EKS, RDS and Aurora), GCP_GKE_EXTENDED_SUPPORT and GCP_SQL_EXTENDED_SUPPORT on Google Cloud (GKE on the Extended channel and Cloud SQL) and AZURE_DB_EXTENDED_SUPPORT on Azure (MySQL and PostgreSQL), also 60 days before the charge starts, and AZURE_AKS_LTS for AKS clusters on the Premium tier with long-term support.
• Idle ML endpoints (Pro): COMPUTE_SAGEMAKER_ENDPOINT_IDLE, AZURE_ML_ENDPOINT_IDLE and GCP_VERTEX_ENDPOINT_IDLE, for SageMaker, Azure Machine Learning and Vertex AI endpoints with instances or replicas running and no requests in 14 days.
• Also on AWS (Pro): resources with more than 30 days of no activity that are not tagged as production.

Worked example: ACME on three clouds

ACME is a fictional company with its store on AWS, its data platform on Azure and its analytics on Google Cloud, on the Pro plan. After the first scan of its three accounts, these are the findings we care about, with the estimated saving each rule calculates and what the team decides:

Step 1: run a scan

In My cloud accounts, every account has a "Scan" button. On Free you can run up to 3 scans a week; on Pro and Business accounts are scanned automatically every day, and you can still scan by hand. When it finishes, the scan appears in Scan History: "View" shows the cost, the potential savings and the comparison with the previous scan, split into new, disappeared and unchanged findings.

Step 2: review the analysis rules

Before working the list, take a look at Analysis rules. You can filter by provider and by category, and each card shows the plan that includes it and whether it is "Automatable". Rules outside your plan show a lock.

• Turn a rule off with its switch if it does not apply to you. The change applies from the next scan.
• Turning a rule off does not mark its findings as resolved: the platform stops looking, and it tells that apart from the problem going away.
• Rule thresholds are not configurable: the 5% CPU or the 7 days are the same for everyone.

Step 3: filter the active findings

Active Findings gathers the findings from the latest scan of each account, sorted by severity and, within each severity, by savings. The filters are at the top:

• Severity tabs: All, Critical, High, Medium and Low, each with its counter.
• Account selector, with "All accounts" to see the three clouds together.
• "Automatable only", to keep what the agent can fix.
• "Show dismissed", which brings back what you marked as dismissed or resolved.
• The "Search finding..." box, which searches the title, the resource name and the description.

Step 4: open the detail

Clicking a finding opens the "Finding detail" panel. It shows the severity, the description, the "Recommendation", the resource, the account, the region and the monthly "Estimated savings". The "View resource" link takes you to the resource page. If the finding has an automatic fix, you will also see the button to automate it, covered in step 7.

Step 5: decide the status

In the same panel, the "Status" block has four buttons. The decision is stored at organization level and carries over to later scans:

• Open: no decision. It is the starting state, and going back to it clears the previous decision.
• Accepted: you acknowledge the problem and will fix it. It still counts in the KPIs, because the spend is still there.
• Dismissed: you have decided not to act (at ACME, the staging load balancer). It stops counting in KPIs and reports.
• Resolved: you have already fixed it. It does not count in the KPIs either.

Step 6: send it to Jira or Linear

If your team works with tickets, connect Jira Cloud (with an API token) or Linear in Alerts → Integrations (Pro plan). In each integration you choose "Create ticket for alerts of severity", which defaults to high. From then on:

• When a scan detects new high-severity findings and the "New high-priority findings" notification is on in Alert channels, a ticket is created with the summary of that alert. It is one ticket per alert, grouping the findings of the scan, not one per finding.
• For a ticket about one specific finding, the "Create ticket" button appears on AI Agent actions that come from a finding (Business plan).

Step 7: propose the fix (Business)

On Business, findings with an automatic fix show an "Automate" button in the list and in the detail. It opens a window with "What will happen", "Why", "Impact", "Before you continue", "How to roll it back" and a "Reversible" or "Not reversible" label. "Create automation" leaves the action proposed in AI Agent → Panel, under "Pending approval". Nothing runs until someone with approval permission approves it, and after approval there is a grace period before execution (48 hours to delete a volume, for example) during which you can cancel it.

• The agent needs a separate write role, created in the "Enable autonomous agent (optional)" step when you connect the account.
• On AWS, stopping, resizing or terminating an EC2 instance requires the FinOpsSentinelManaged=true tag on it.
• Before deleting an EBS volume, the agent takes a backup snapshot. Releasing an Elastic IP, on the other hand, loses it: you can reserve another, but not the same address.
• With "Turn into playbook", the same fix is proposed automatically after every scan for that rule's findings, always pending approval.

The result at ACME

ACME acts on everything except the staging load balancer, which it marks as "Dismissed". The Lambda is deleted for hygiene and adds nothing. The estimated saving ends up as 70 + 50 + 45 + 38 + 33 + 10.80 + 7.30 = 254.10 US$ a month, about 3,050 US$ a year at list prices. As each resource goes away, its findings move to "Disappeared" in later scans. On Business, the agent panel shows "Verified savings" separately, measured against the account's real cost at least 7 days after each action.

What it does not do yet

So you know what to expect:

• There are no rules for Kubernetes or for cost inside clusters.
• There is no snapshot age rule: the orphan snapshot rules look for snapshots without a source disk, not for old snapshots.
• Google Cloud has no idle load balancer rule, and Azure has no expensive storage class rule.
• Rule thresholds cannot be tuned: you can only turn each rule on or off.
• Active Findings has no per-finding ticket button: tickets come from alerts or from the AI Agent.
• The estimated saving is based on the cost the rule attributes to the resource, not on your invoice. Treat it as an order of magnitude.

Checklist to get started

With this in place, waste stops piling up in silence:

• Your AWS, Azure and Google Cloud accounts connected in My cloud accounts.
• A first scan run and reviewed in Scan History.
• Rules that do not apply turned off in Analysis rules.
• Every high-severity finding with a status: accepted, dismissed or resolved.
• Jira or Linear connected in Alerts → Integrations, if you work with tickets.
• On Business, the agent role created and the first fixes proposed from the finding.