In cloud, “handling traffic” does not always mean “being safe”. The elasticity that allows you to absorb spikes also allows an attacker to turn your account into a budget-burning machine. This is often called Denial of Wallet (Denial of Wallet, DoW): the goal is cost, not availability.
In companies it shows up with repeated patterns: cryptomining deployed with leaked credentials, autoscaling induced by artificial traffic, abusive use of managed services (egress, logs, queues, functions), and DDoS that, even if it does not “take down” the system, forces an increase in resources and consumption. The FinOps discipline helps, but if it is not integrated with security (FinOps Security), you arrive late: the spend already happened.
What went wrong in Denial of Wallet incidents: elasticity as a weapon
The typical mistake is not “not having a WAF” or “not having autoscaling”; it is having them without limits and without an economic reading of risk. In real cryptomining cases, the attacker does not need to touch your application: it is enough to obtain an access key (for example, in a repository or on a compromised endpoint) and launch expensive and persistent resources. If there are also broad permissions, they can spin up GPU instances, managed clusters, or container farms billed per minute.
In other scenarios, the abuse comes through the service layer: artificial traffic against endpoints that trigger serverless functions, queues, databases, or logging. The platform scales “correctly” from an SRE point of view, but the marginal cost per request makes the attack profitable for the adversary. Sometimes the attacker is not even seeking persistence: just generating the maximum spend in a few hours before anyone reacts.
The business consequence is concrete: saturation of the monthly budget, internal blocks for exceeding spend limits, interruption of projects (because the finance area freezes the account), and weeks of work investigating consumption to justify it. This is not an isolated “technical incident”; it is a financial risk incident with technical traceability.
Early signals that distinguish a legitimate spike from a cost-oriented attack
The first signals rarely appear in the latency monitor; they appear in the spend curve and in “boring” metrics: egress, logs, invocations, messages, compute metrics by AZ or region. A frequent pattern is spend shifting to a non-core service (for example, logs, NAT/egress, or functions) while the business metric (sales, users, conversions) does not follow.
Another useful signal is the distribution change: suddenly, a non-production environment consumes like production, or a region that is not used starts to have activity. In cryptomining, CPU/GPU consumption spikes with low external traffic, and new images/artifacts appear in repositories or clusters. In induced massive scaling attacks, you see request spikes that do not translate into real sessions (weird ratios between requests and authentications, or between requests and application events).
- Spend per service misaligned with the business: for example, NAT Gateway/egress or CloudWatch Logs go up with no increase in users. This usually reveals artificial traffic or induced excessive logging.
- New resources outside the operational pattern: instances with unusual types, new regions enabled, changes in minimum/maximum scaling. In mature companies, the “inventory” changes slowly; abrupt changes are usually suspicious.
- Unusual API activity: spikes in calls to provisioning APIs (create instances, nodes, functions, rules) from identities or IP ranges that are not usual.
Each of these points is validated by cross-checking signals: cost + inventory + audit events. If you only look at one dimension, it will mislead you: a spike can be a legitimate campaign; three aligned dimensions usually indicate abuse.
How to do it in practice: anomaly alerts, budgets, and quotas that stop the damage
An effective operational response combines early alerts with brakes. “Fixed threshold” alerts fail because the business changes; anomaly alerts by service, account/project, and region work better. In parallel, you need technical limits: service quotas, autoscaling limits, and controls to prevent someone (or something) from deploying resources outside your guardrail.
In AWS, a practical baseline usually includes: AWS Budgets (cost/forecast alerts), Cost Anomaly Detection (anomalies by service or tag), and CloudWatch alarms for metrics that correlate with cost (egress, invocations, errors that trigger retries). The important thing is not “receiving an email”; it is that the alert reaches the on-call channel and has context (service, region, tags, likely resource) to act within minutes.
- Configure anomaly alerts by service and by tag: create anomaly monitors for services with high economic risk (egress/NAT, functions, logs, compute). Pair it with a minimum tagging policy; without tags, triage becomes slow and expensive.
- Apply quotas and scaling limits: request/set reasonable service quotas and set Auto Scaling maximums (and minimums that do not shoot up). The goal is not to prevent growth, but to avoid unlimited growth without approval.
- Automate controlled “kill switches”: prepare runbooks to pause scaling, disable non-critical endpoints, or temporarily limit egress. This requires agreeing on it beforehand with product and operations so you do not improvise under pressure.
To validate that this is well implemented, review two things: that the alert fires with “simulated” data (for example, cost variation in a sandbox or by reviewing historical behavior) and that the on-call can identify the suspicious resource without opening ten consoles. If triage takes more than 20–30 minutes, the economic damage is already scaling.
Containment during the incident: cut spend without destroying evidence
When spend is rising, the temptation is to “shut everything down”. In corporate environments that usually makes it worse: you cut evidence, break critical services, and generate a larger incident. Containment in DoW must be selective: stop the cost source and preserve traceability to understand the vector (credential, endpoint, scaling abuse, misconfiguration).
In cryptomining, effective containment is to isolate: stop suspicious instances, block outbound routes if applicable (without taking down critical integrations), and revoke compromised credentials. In attacks that force scaling, it is often more effective to impose temporary limits (max desired capacity), enable WAF/rate limiting rules, or close secondary endpoints that are being exploited.
There is a very common anti-pattern: reacting only with layer 7 measures (WAF) when the cost comes from egress, logs, or internal retries. If the application enters a retry loop due to induced timeouts, you may be paying double: for compute and for associated services. That is why, during containment, it is advisable to check whether there is a retry storm, 5xx errors, and queues growing without being consumed.
Realistic prevention: minimum viable IAM, controlled regions, and “finite capacity” by design
Prevention in DoW is not a checklist; it is designing so that cost has a ceiling. That is achieved by combining restrictive IAM, deployment controls, and capacity limits. If an identity can “create anything in any region”, the attacker only needs a leak to monetize your account.
A practical control is to reduce surface area: block unused regions, require MFA where applicable, and limit provisioning actions (run instances, create cluster, create function) to CI/CD roles or to identities with approval. At the organization level, separating accounts by environment/project limits the financial blast radius: a compromised development account should not be able to consume the production budget.
Example of a technical control (AWS IAM) to prevent a role from creating large instances or instances outside allowed regions. It is not “the” definitive policy, but it illustrates the kind of guardrail that reduces DoW from malicious provisioning:
- Restrict regions: deny actions if
aws:RequestedRegionis not in the allowed list. This stops deployments in “forgotten” regions where nobody watches costs. - Limit instance types: allow only approved families/sizes (for example, deny GPU if it is not essential). In cryptomining incidents, this control reduces impact drastically.
- Separate operations and provisioning roles: a role that operates should not create base infrastructure. If the attacker steals an operational token, it is harder to turn it into spend.
The validation should not be theoretical: check in CloudTrail (or your audit system) that the denied actions are effectively recorded, and run controlled tests trying to deploy outside the region or with a disallowed type. If you do not test it, on the day of the incident you will discover “exceptions” that nullify the guardrail.
Recommendations for corporate environments
Denial of Wallet works because it mixes two realities: security (abuse) and FinOps (consumption). In companies, effective defense appears when spend is treated as an incident symptom, with defined detection, triage, and containment, not as an end-of-month report.
Prioritize anomaly alerts with context (by service, region, and tags), and pair them with brakes: quotas, scaling maximums, and IAM controls that put a ceiling on cost. Operationally, prepare runbooks to cut spend selectively without losing evidence, and periodically validate that those guardrails work with controlled tests.
Interested in Cloud Security?
Technical analysis, hands-on labs and real-world cloud security insights.