Cloud Cost Anomalies as Security Signals

An unexpected jump in the cloud bill is often the first sign that someone else is using your accounts, yet cost alerts usually land in a FinOps inbox that nobody on the security team reads. Stolen access keys, leaked AI API keys, abused storage and exfiltration over the network all show up as spend before, or instead of, a security finding. This guide covers how to treat cost anomalies as a detection source: what the native anomaly tools in AWS, Google Cloud and Microsoft Azure actually see and how late they see it, how to route alerts to people who can act, and a triage method that separates a forgotten test cluster from a compromise. It is for cloud security, SOC and FinOps teams. Miner abuse is covered in depth in the Cryptojacking Guide and runaway AI and API spend in the Denial-of-Wallet and AI Agent Cost Runaway Guide; this page covers the generic triage of any spend spike. Providers are listed alphabetically.

Key takeaways

Cost is a lagging but independent signal. It still fires when logging is off, a region is unmonitored or a threat detector is not enabled, which is exactly when attackers prefer to work.
Know your detection delay. AWS Cost Anomaly Detection can take up to 24 hours after usage, Azure evaluates each day 36 hours after it ends, and Google Cloud reports standard anomalies through next-day channels, so pair cost alerts with real-time threat findings.
Budgets alert, they do not stop. Google Cloud states that alerts-only budgets do not cap usage; AWS Budgets actions can apply a deny policy or stop named instances, but only if you configured them in advance.
Route anomalies to security as well as finance. Send them to a topic or mailbox the SOC monitors, with the anomaly's root-cause dimensions (account, region, service, usage type) attached.
Triage by the shape of the spend. New region plus new service plus no owner tag is a compromise until proven otherwise; growth in an existing, tagged workload usually is not.

Why spend is a security signal

Most cloud abuse is monetised by consuming resources the victim pays for. MITRE ATT&CK groups this under T1496 Resource Hijacking, with sub-techniques including T1496.001 Compute Hijacking and T1496.004 Cloud Service Hijacking; see Cryptojacking Guide. Attackers also favour T1535 Unused/Unsupported Cloud Regions because those regions are less likely to have logging and detection switched on. Billing is aggregated across every region and service, so it sees activity that a region-scoped detector misses.

The cost of these attacks can be large and fast. In the LLMjacking campaigns, stolen cloud credentials and AI API keys were used to run hosted models on the victim's account, and the potential consumption costs reported for these campaigns were large enough to matter within days. Budget alarms were one of the controls that would have shortened those incidents.

Spend also reveals incidents that are not about resource theft at all:

Exfiltration: a sudden rise in data transfer out, inter-region transfer or NAT gateway processing can mean data is leaving the estate.
Persistence and staging: new snapshots, images, storage buckets or long-running instances in an account that rarely changes.
Abuse of exposed services: request charges on a public bucket, API gateway or function endpoint climbing without a matching release.
Ransom and destruction preparation: unusual backup, snapshot copy or key management activity, which shows as new usage types.

What the native anomaly tools see, and when

Each provider offers machine-learning anomaly detection at no extra charge, but they differ in scope, data and timing. Treat the table as a description of each tool's documented behaviour as of November 2026, not a comparison.

Provider and feature	Scope	Timing (per provider docs)	Root-cause detail	Alert delivery
AWS Cost Anomaly Detection (Billing and Cost Management)	All AWS services, or chosen member accounts, cost allocation tags or cost categories	Runs about three times a day on net unblended cost; Cost Explorer data can lag up to 24 hours; a new monitor needs up to 24 hours, and a new service needs 10 days of history	Ranked by dollar impact, split by service, account, Region and usage type	Individual or aggregated alerts by email or Amazon SNS; EventBridge and AWS User Notifications integration
Google Cloud Billing anomalies (Anomalies dashboard)	All projects on a billing account, or project-scoped for project billing users	Standard anomalies through next-day channels; early anomalies (Preview) for the Gemini API and Vertex AI alert about 20 to 40 minutes after usage	Root cause analysis panel: top services, regions and SKUs	Email to billing admins, essential contacts or project owners, as individual alerts or a daily summary; Pub/Sub
Microsoft Azure Cost Management anomaly detection (Cost analysis smart views)	Subscription	Evaluated daily, 36 hours after the end of the day (UTC), against a model trained on 60 days of history	Daily usage by resource group, then drill down by resource and meter	Anomaly alert rules (up to five per subscription) by email, sent once at detection

Three practical consequences follow. First, a fast-moving attack will run for most of a day before any of these tools speaks, so they complement, not replace, Amazon GuardDuty or equivalent threat detection. Second, scope matters: an Azure anomaly alert configured on one subscription says nothing about a new subscription an attacker creates. Third, AWS Cost Anomaly Detection does not monitor most AWS Marketplace third-party charges; AWS documents using AWS Budgets with the Billing entity filter for those.

Designing alerts that reach the right people

An anomaly that lands only with finance is a detection that never fires. Design the routing as carefully as any SIEM rule.

Thresholds and monitors

AWS: create one monitor across all AWS services for broad coverage, plus monitors for high-risk member accounts (production, shared services, the security tooling account) so a small spike in a quiet account is not drowned by organisation-wide growth.
Google Cloud: set Cost impact and Deviation percentage thresholds in Manage anomalies (Billing Account Administrators only). Thresholds apply to the whole billing account, so separate billing accounts are the way to get different sensitivity for sandbox and production.
Microsoft Azure: create an anomaly alert (Cost alerts, Add, Alert type Anomaly) on every subscription, including sandboxes. Microsoft notes that delivery uses the creator's current access, so a creator who loses Reader stops receiving alerts; Microsoft documents a service principal with the Scheduled Actions API (kind InsightAlert) for environments without standing access.

Delivery to the SOC

Machine-readable channel: use Amazon SNS or EventBridge, Google Cloud Pub/Sub, or for Azure a monitored mailbox processed by Logic Apps or ingested into Microsoft Sentinel, which Microsoft describes as automation options.
Enrichment: attach the root-cause dimensions and look up the account or project owner, environment and cost centre from tags before the alert reaches an analyst. The Cloud Resource Tagging Standard Template sets out the tags that make this possible.
Severity: raise severity automatically when the anomaly is in a region you do not use, a service you have never used, or an account tagged production or security.

Budgets as a second layer

Fixed budgets catch steady creep that a learning model gradually accepts as normal. Use forecast-based thresholds so alerts fire before the money is spent. Google Cloud recommends setting budgets below available funds because of reporting delay, and its Pub/Sub budget notifications are sent multiple times per day, unlike email. AWS Budgets actions can apply an IAM policy or a service control policy, or target specific running EC2 or RDS instances, either automatically or after manual approval. Keep automatic actions for sandboxes; in production, use manual approval so a containment action does not cause an outage. Billing roles that can change these controls are privileged; see the FinOps Security guide.

Triage: benign growth or compromise?

Every anomaly needs a quick, consistent answer to one question: is this activity authorised? The pattern of the spend usually tells you where to look.

Anomaly pattern	Likely benign explanation	Compromise indicators	First check
New region with any meaningful spend	Planned expansion, disaster recovery test	Region not in your approved list; resources with no owner tag	Audit log for resource creation in that region and the calling identity
GPU or large compute instances appear	ML team experiment, scale-out event	Instances launched by an access key or service account that never launched compute before; outbound connections to mining pools	Threat findings for crypto activity; instance launch events
Generative AI or model inference charges jump	New feature release, batch job	Model access newly enabled; calls from unfamiliar IPs or identities; no release in change records	Model invocation logging, key usage; see the LLMjacking Guide
Data transfer out or NAT processing rises	Customer growth, new integration, backup to another cloud	Transfer from a data store to unknown destinations; access by a new identity; outside business hours	Flow logs and storage access logs for the top source resources
Storage request charges spike on one bucket	Popular asset, CDN misconfiguration	Bucket is publicly readable; requests from many unknown sources; listing operations	Bucket policy and access logs; see the Cloud Storage Exposure Playbook
New account, project or subscription billed	Account vending, a new team	Not created by your vending process; payment or billing link changed	Organisation and billing audit logs for the creating identity
Snapshot, image or backup copy costs rise	Backup policy change	Copies shared to external accounts; deletion of older recovery points	Sharing and deletion events on recovery resources

A ten-minute triage routine

Read the root cause: note the account or project, region, service and usage type or SKU from the anomaly record.
Find the owner: check owner and environment tags; in Azure, Microsoft points to the Activity log, users with write access and resource tags. If there is no owner, escalate.
Find the identity: search the audit log (CloudTrail, Cloud Audit Logs or the Azure Activity log) for the create and start events behind the top resources, and record the principal, source IP and user agent.
Check change records: a matching approved change or deployment closes most benign cases.
Check threat findings: look for open findings on the same resources or identity.
Decide: close as benign with the owner's confirmation, or open a security incident and move to containment.

Record the outcome against the anomaly. AWS and Google Cloud both accept feedback on whether a detection was a real anomaly, which tunes the model; do this for benign cases so the noise falls over time.

When it is compromise: containment and recovery

Once you treat a spend spike as an incident, run your normal process; the Cloud Incident Response Guide covers it in full. Points specific to cost-led incidents:

Preserve before you delete: AWS's guidance on unauthorised activity says to back up what you need for investigation, for example an EBS snapshot before terminating an EC2 instance.
Contain the identity, not only the resources: deactivate the access key or disable the service account behind the launches; deleting instances while the key is live just invites relaunch. AWS describes creating a new key and deactivating the original before deleting it, and checking for the AWSCompromisedKeyQuarantineV2 policy.
Sweep every region: AWS advises checking all Regions and comparing current usage with the previous month. Attackers spread launches to dodge per-region quotas and monitoring.
Remove persistence: look for new IAM users, roles, keys, trust policies and temporary credentials created during the window.
Stop the bleeding with policy: a deny policy or region restriction at the organisation level stops new spend while you investigate; see the AWS Organizations and SCPs Guide.
Engage the provider: confirm remediation through the provider's support channel; for AWS irregular-activity notices, AWS asks you to reply in the Support Center confirming the steps taken.
Check account details: AWS also lists verifying the account name, root user email and contacts, which an attacker may have changed. If root was involved, use the AWS Root Account Compromise Playbook.

Where identity fits

Almost every cost-led compromise begins with a non-human credential: a long-lived access key in a repository, a service account key on a build server, or an AI provider API key in a client application. Cost anomalies are therefore a useful backstop for secrets hygiene. Map each anomaly back to the calling identity, and track which identities caused confirmed incidents: that list is your priority for moving to short-lived credentials. See the AWS Access Keys Security Guide.

Choosing controls for your size

Organisation	Minimum	Add when ready
Small (one or a few accounts)	Native anomaly detection on every account, project or subscription; a forecast budget at a level you can afford to lose; alerts to a shared security mailbox	Region restrictions; an automatic budget action on sandboxes
Mid-sized	Per-account monitors for production and security accounts; alerts to SNS, Pub/Sub or Sentinel; owner tags enforced	Enrichment that adds owner and change context; a triage runbook with SLA
Large or multi-cloud	Anomaly data in the SIEM, correlated with audit logs and threat findings; severity rules for unused regions and services	Hourly cost and usage exports analysed for near real-time patterns; feedback loop to tune models

Detection and measurement

Coverage: percentage of accounts, projects and subscriptions with anomaly detection and an alert route to security. Target 100%, including sandboxes.
Time to triage: median time from anomaly alert to a recorded benign or incident decision.
Owner resolution rate: share of anomalies where the owner was found from tags alone.
Cost-first detections: number of confirmed incidents where the cost anomaly fired before any security finding; a rising number points to gaps in threat detection coverage.
False positive rate: benign anomalies as a share of all anomalies, trending down as feedback is given.

Framework mapping

Activity	NIST CSF 2.0	NIST SP 800-53 Rev 5	MITRE ATT&CK
Monitor cloud usage and spend for adverse events	DE.CM-09	SI-4 System Monitoring	T1496, T1496.001, T1496.004
Analyse and correlate anomalies with audit logs and findings	DE.AE-02, DE.AE-03	AU-6 Audit Record Review, Analysis, and Reporting	T1078.004, T1535
Investigate confirmed cases	RS.AN-03	IR-4 Incident Handling	T1578 Modify Cloud Compute Infrastructure
Maintain owner and inventory context	ID.AM-01	CM-8 System Component Inventory	None

Common failure patterns

Alerts only to finance: the anomaly fired on day one and was read at month end.
Coverage stops at known accounts: a new subscription or project created by an attacker has no monitor and no alert.
Treating a budget as a cap: the budget emailed at 100% and spend continued for days.
Deleting resources without revoking the credential: the attacker relaunches from the same key, and the bill starts climbing again.
Relying on cost alone: careful attackers keep usage low. In the Tesla Kubernetes cryptojacking case the miners kept CPU usage low to avoid notice, and the intrusion was found by researchers tracing exposed credentials, not by spend. Cost anomalies catch the noisy cases; credential and network monitoring catch the quiet ones.
No owner tags: analysts spend hours finding out whose workload it is, so most anomalies are closed as "probably fine".
Silent alert rules: an Azure alert created by someone who has since left stops delivering because it runs with the creator's access.

Practitioner checklist

Turn on native anomaly detection for every account, project and subscription, including sandboxes.
Create separate monitors or billing scopes for production and security accounts.
Route anomaly alerts to a channel the SOC watches, not only to finance.
Enrich alerts with owner, environment and change context from tags.
Raise severity automatically for unused regions, never-used services and AI inference spend.
Add forecast-based budgets, with budget actions on sandboxes and manual-approval actions in production.
Write and drill the ten-minute triage routine, including how to find the calling identity.
Contain the credential first, sweep every region, and preserve evidence before deleting.
Give feedback on benign anomalies and track triage time and cost-first detections.

Cloud Cost Anomalies as Security Signals: Budgets, Alerts and Triage for Compromise