How do I find which service caused a cloud cost spike?

Open the daily cost view grouped by service. On AWS: Cost Explorer, Daily granularity, Group by Service, filter charge type to Usage. On Azure: Cost Management → Cost analysis, Daily view, Group by Service name. Sort by the change over the spike period, not the total — a service that doubled off a small base can matter more than your biggest steady line. Once one service stands out, group that same service by usage type (AWS) or meter (Azure) to see exactly which meter moved.

Should I be worried a bill spike is a security incident?

Sometimes yes. A sudden appearance of compute spend in a Region you don't use, a large jump in EC2/VM or GPU usage you didn't provision, or new spend on a service nobody enabled can indicate compromised credentials being used to mine cryptocurrency. If the spike is a brand-new spend source with no legitimate owner, treat it as a security incident first: rotate the exposed keys, check for unfamiliar resources across all Regions, and involve security — then clean up the cost.

Cost governance · Azure & AWS · July 2026

Why Did My Cloud Bill Suddenly Increase? A Step-by-Step Investigation Playbook

Q: Why did my Azure or AWS bill suddenly go up?

A sudden cloud bill increase almost always traces to one of a handful of causes: a new or scaled-up resource left running, a data-transfer or egress blow-out, a storage or log-retention change, a forgotten test or load job, an expired free tier or credit, a commitment (reservation or savings plan) purchase, or compromised credentials spinning up compute. Investigate by isolating the single service and the specific day the increase started in Cost Explorer (AWS) or Cost Management cost analysis (Azure), then drilling to the resource and usage type — the cause is usually obvious once you know which meter moved.

By the CloudFinOpsKit team — we investigate these for a living. 9 min read.

A cloud bill that jumped overnight is a scavenger hunt with a deadline: money is leaving while you look for it. The instinct is to panic-scroll the invoice, but a bill is organized for accounting, not for diagnosis. This is the investigation we run every time — five steps, in order, using only the native Azure and AWS tools. It takes the spike from "the bill is up and I don't know why" to a named resource, a root cause, and a fix, usually in under half an hour. At the end: how to make sure the next one pages you on day one instead of surprising you on the invoice.

Step 1 — Confirm the increase is real (2 minutes)

Before you chase anything, rule out the three false alarms that account for a surprising share of "my bill spiked" reports:

Unfinalized days. The most recent 1–2 days of cost data are estimates and often revise down. A scary-looking today is frequently just incomplete. Judge the trend on days that have settled, not the trailing edge.
A commitment purchase, not usage. A reservation or savings-plan purchase, an annual Marketplace charge, or a support-plan fee lands as one big line but isn't runaway usage. Filter charge type to Usage (AWS: exclude Fee/RIFee/Credit/Refund; Azure: ChargeType = Usage) and the noise disappears.
An expired credit or free tier. Spend didn't rise — a discount stopped. Your usage is flat; the net cost stepped up when a credit ran out or a 12-month free tier ended. Check the credits/free-tier view before assuming a leak.

If the increase survives all three — it's real usage, on settled days, not a one-time charge — proceed.

Step 2 — Isolate the service and the day it started

This is the step that collapses the search space. You want two facts: which service moved and which day it started. Everything after is drill-down.

On AWS — Cost Explorer → set Granularity: Daily, Group by: Service, and a date range covering ~30 days before the spike. Filter Charge type: Usage. You're looking for the service whose daily bars change shape — a step up, a spike, or a steadily climbing staircase. Sort by the delta over the window, not the total.

On Azure — Cost Management → Cost analysis → Daily view, Group by: Service name, scope set to the subscription (or management group if you're not sure which subscription). Same read: which service's daily line changed, and on what date.

The shape of the change is your first clue to the cause, before you even know the resource:

Shape	What it usually means
One-day spike then back to normal	A runaway job, a load test, a bulk data transfer, a one-off backup or migration.
Step up that stays high	A deployment, a scale-out that never scaled back, a tier/SKU change, a new always-on resource.
Steady climb over weeks	Creep: log/storage growth, snapshot sprawl, an autoscaler with no ceiling. The class native anomaly tools miss.
New line from ~$0	A newly enabled service, an accidental Region — or, if nobody owns it, possibly compromised credentials.

Step 3 — Drill to the resource (or usage type)

Now filter to the one service that moved and change the grouping to find the specific meter and resource.

AWS: keep the filter on that service, then Group by: Usage Type to see which meter jumped (e.g. DataTransfer-Out-Bytes, NatGateway-Bytes, BoxUsage:g5.xlarge). For resource-level detail, enable Group by: Resource — note it's opt-in and only covers the last 14 days, so turn it on early. Cost allocation tags let you group by team or environment if the resource alone isn't enough.

Azure: filter to the service, then Group by: Meter or Resource. For the offenders that hide inside a resource group, group by Resource group name first, then drill in. Azure Resource Graph is faster than the portal when you already suspect a resource type — one query returns every disk, public IP, or NAT gateway with its SKU.

By the end of this step you should be able to name it: "NAT gateway data-processing in eu-west-1 went from $4/day to $210/day starting the 3rd." That sentence is the whole investigation — the rest is explaining and fixing it.

Step 4 — Identify the cause: the usual suspects

Cost spikes are not infinitely varied. Match your finding to this shortlist and you've almost certainly found it:

Symptom	Likely cause	Check / fix
Data-transfer / egress meter jumped	New cross-AZ, cross-Region, or internet-egress path; a chatty new deployment; data exfiltration	Trace what changed in networking/deploys on that date; look for a new endpoint or replication.
Compute (VM/EC2/GPU) stepped up	Scale-out that didn't scale back; a bigger SKU; a forgotten dev/test or load environment; autoscaler with no max	Check autoscale history and recent deploys; set/verify a max; shut down non-prod out of hours.
Storage or snapshot cost climbing	Log/retention change, snapshot or backup sprawl, orphaned disks/volumes piling up	See orphaned disks (Azure) and unattached EBS (AWS); fix retention.
Log Analytics / CloudWatch spend up	A new verbose log source, debug logging left on, or a retention bump	Find the high-ingest table/log group; cap retention; turn off debug.
AI / token spend jumped	Prompt loop or retry storm, a switch to a pricier model, output bloat, or an idle PTU commitment	Token spend needs its own detectors — see detecting AI cost anomalies.
Brand-new spend nobody owns	Accidental Region, unapproved service — or compromised credentials mining crypto	If no legitimate owner: treat as a security incident — rotate keys, sweep all Regions, involve security.

Security first when spend appears from nowhere. A sudden burst of compute — especially GPU instances, or any spend in a Region you never use — with no owner is the classic signature of leaked access keys. Don't just delete the resources: rotate the exposed credentials, check every Region (attackers spread across them), and loop in security before you clean up the cost. A deleted crypto-miner with live keys comes straight back.

Step 5 — Stop the bleed, then prevent the next one

Fix the immediate cause — delete the orphan, scale back the deployment, cap the retention, rotate the key. Then close the loop so the same class of spike can't run silently for a full billing cycle again:

Turn on the native anomaly alerts (both free). Azure Cost Management anomaly alerts per subscription; AWS Cost Anomaly Detection monitors + an SNS or email subscription. They won't catch everything, but they're the always-on baseline. Walkthroughs: Azure · AWS.
Set a budget with an actionable threshold — a forecasted-to-exceed alert catches a step change before month-end, where a raw anomaly alert might not.
Add a layer that catches what the native tools miss — gradual creep, new spend sources, and a consistent definition across both clouds. That's exactly what the unified methodology behind Cost Anomaly Watch does.
Make the monthly review a habit. A 10-minute pass over daily cost by service, every month, means you find the next creep at $30/day, not $300.

Skip the scavenger hunt next time. The CloudFinOpsKit Azure Tool and AWS Tool ship Cost Anomaly Watch: run it daily, and it isolates the service, the day, the resource, the projected monthly impact, and a plausible-cause hint for you — then pushes High-severity anomalies to Teams or Slack. It's steps 1–4 of this playbook, automated and auditable, on both clouds. Read-only, one-time from $40.

FAQ

Why did my Azure or AWS bill suddenly go up?

Almost always one of: a new or scaled-up resource left running, a data-transfer/egress blow-out, a storage or log-retention change, a forgotten test job, an expired credit or free tier, a commitment purchase (not usage), or compromised credentials. Isolate the single service and the day it started in Cost Explorer or Cost Management, then drill to the resource — the cause is usually obvious once you know which meter moved.

How do I find which service caused the spike?

Open the daily cost view grouped by service (AWS Cost Explorer or Azure Cost analysis), filter to Usage charges, and sort by the change over the spike window rather than the total. A service that doubled off a small base often matters more than your biggest steady line. Then group that service by usage type or meter to pinpoint the exact driver.

Could a bill spike be a security incident?

Yes — brand-new compute spend with no owner, especially GPU usage or spend in an unused Region, is a common signature of leaked keys mining crypto. If a spike is a new spend source nobody claims, treat it as a security incident first: rotate keys, sweep all Regions, involve security, then clean up the cost.

How do I stop this from happening again?

Enable the native anomaly alerts on both clouds, set a forecasted-budget alert, add a layer that catches gradual creep and new spend sources the native tools miss, and run a 10-minute monthly review of daily cost by service. Detection plus a habit is what turns a monthly surprise into a same-day fix.