Keep an Eye on Your Cloud Bill: How Denial of Wallet Attacks Affect Cloud Apps

Sometime back, I had a conversation with a colleague about a sudden spike in inbound traffic against one of our systems. Our monitoring and telemetry tools detected and flagged this anomaly. Upon investigation, it turned out to be a legitimate load from an upstream application. Thanks to the serverless architecture and auto-scaling measures, the system scaled up seamlessly and managed the load effortlessly (phew!).

This led us to discuss our preparedness against potential threats associated with inbound traffic. Can we rely solely on scalable architectures and DDoS mitigation tools? Or are there other angles we need to consider?

As architects or software designers, we spend our days designing systems that are scalable, performant, cost-efficient, and easy to maintain. But in the cloud, there’s a new looming threat that can turn our beautifully designed solutions into financial black holes: Denial of Wallet (DoW) attacks.

These aren’t your typical DDoS attacks that scream “disruption!” with overwhelming traffic. No, DoW attacks are the silent assassins of the cloud world, exploiting our architectural decisions to drain our budgets. So, let’s dive into what DoW attacks are, how our design choices make us vulnerable, and the tricky trade-offs we face when balancing DoW risks against the other pillars of good architecture.

Note: The term “wallet” here refers to the financial aspect of cloud services, not cryptocurrency wallets or payment systems.

Photo by Greg Martínez on Unsplash

Intention to Disrupt — From DDoS to DoW

Historically, cyber attackers have loved disrupting services. Take Distributed Denial of Service (DDoS) attacks, one of the most unwanted, yet familiar terms since the late 1990s. In 2023 alone, DDoS attacks worldwide surged by 63% compared to the previous year. These attacks flood systems with traffic, overwhelming infrastructure and knocking services offline.

However, we’ve gotten pretty good at defending against them also — think load balancers, Web Application Firewalls (WAFs), and auto-scaling to absorb the load. But attackers are also evolving, and their motives are shifting.

Enter Denial of Wallet (DoW) attacks — the financial cousin of DDoS. While DDoS aims to disrupt availability, DoW targets your wallet, exploiting the pay-as-you-go model that makes cloud computing so attractive. The goal? Drive up your cloud bill by triggering high-cost operations, leaving you with a financial mess. Attackers might target serverless functions, storage services, data transfers, or even AI/ML services, leveraging the very scalability and flexibility we design into our systems. This forces us to rethink our designs — not just for performance or uptime, but for financial resilience. Because, a system that scales beautifully but bankrupts your company isn’t exactly a win.

Understanding Denial of Wallet (DoW) Attacks

So, how do these DoW attacks work, and why might they keep us up at night? At their core, DoW attacks exploit the pay-as-you-go pricing model of cloud platforms. You know, the one we love because it lets us scale resources dynamically and only pay for what we use. But attackers see it as a golden opportunity to inflate costs without raising obvious red flags.

Here’s how they would exploit it. Attackers target services that scale automatically (like serverless functions, auto-scaling compute instances, or storage buckets) or charge based on usage (API calls, data transfers, or AI/ML inference tasks). They generate artificial demand — flooded with requests, uploads, downloads, or computations — that look legitimate to the system. Since our cloud architectures are designed to handle spikes by scaling up resources, the platform happily complies, spinning up more instances, allocating more storage, or processing more data. Every action adds a few more bucks (or hundreds, or thousands) to your bill.

Animation credit: repello.ai

Take the AWS Lambda or Azure function as an example. An attacker could bombard your Lambda function endpoints with thousands of tiny, seemingly harmless requests. Lambda scales up to handle the load, and you’re charged for every millisecond of execution time and every request processed. Or consider an S3 bucket in AWS, or Storage service in Azure: an attacker uploads massive files to a publicly accessible bucket, then downloads them repeatedly, racking up data transfer fees. These actions exploit the very features we design for — which are auto-scaling, abstraction of infrastructure, and usage-based pricing.

As architects, this is where our design decisions come into play. Did we set up auto-scaling without limits, thinking it would make our system more resilient? Did we leave a storage bucket open to the public to make data sharing easier? Did we choose a serverless-first approach to reduce maintenance overhead, without considering the cost implications of abuse? Every choice we make — whether for scalability, performance, or flexibility — can inadvertently increase our vulnerability to DoW attacks. Not to mention that cloud cost structures are complex, with different rates for compute, storage, data transfer, and regions, making it easy for costs to spiral before we notice.

How Does DoW Differ from DoS/DDoS?

Let’s contrast this with traditional DoS/DDoS attacks to see why DoW is a unique beast. DDoS attacks are loud and chaotic, flooding your servers or network with traffic to disrupt availability. The goal is downtime, and the damage is often reputational (angry customers, lost business, and bad PR). Good architects and designers mitigate this with designs like geo-distributed load balancers, DDoS protection services, and aggressive auto-scaling.

DoW attacks, on the other hand, are sneaky and financial. Attackers don’t care about downtime; they want to drain your budget by generating high-cost operations. This could mean intensive computational tasks, excessive data storage, massive data transfers, or artificially triggering auto-scaling to consume more resources. Unlike DDoS, DoW traffic might not look intrusive — it could be spread out over time, quietly racking up costs over time without crashing your system.

Here’s where architecture matters — a system designed purely for DDoS resilience might scale up aggressively to handle traffic, but in a DoW attack, that scaling becomes a liability, inflating costs. As architects, we need to ask ourselves: Are we over-optimizing for availability at the expense of financial risk? It’s a classic trade-off, and one we’ll explore more later.

Why DoW Attacks Are Harder to Detect?

Detecting DDoS attacks is relatively straightforward — the massive influx of traffic is a dead giveaway. Most monitoring tools, starting from the ones like AWS CloudWatch or Azure Monitor, will scream when request rates skyrocket. Then our WAFs and DDoS mitigation services kick into gear. But DoW attacks? They’re pretty much the ninjas of the cyber world, blending in with legitimate traffic.

Why are they so hard to spot? First, DoW attacks often mimic normal usage patterns. An attacker generating computationally intensive tasks or large data transfers might look like a busy day in your data analytics pipeline. Second, they can be “low and slow,” spreading their activities over days, weeks, or even months, avoiding sudden spikes that trigger alerts. Third, cloud cost structures are complex, with myriad services, regions, and pricing models. Attackers exploit this complexity, making it tough to spot unusual cost patterns until the bill arrives (perhaps not even then).

As architects, this detection challenge forces us to think beyond traditional monitoring. Sure, we can set up alerts for traffic spikes, but what about cost spikes? Are we monitoring usage patterns at a granular level, like per-service or per-region costs? Did our design choices — like abstracting infrastructure management to reduce maintenance overhead — make it harder to spot subtle abuses? For example, serverless architectures, while great for scalability and maintainability, can obscure low-level usage details, making DoW attacks harder to detect. This is another trade-off to consider.

So, Do DoW Attacks Really Happen?

You might be thinking, “This sounds scary, but is it actually happening in the real world?” Absolutely! DoW attacks are not theoretical — they’ve hit real systems, often with alarming consequences. Let’s look at a few examples:

• AWS S3 Bucket exploit: In the article “How an empty S3 bucket can make your AWS bill explode” the author highlights the financial risk associated with AWS S3 buckets. Even an empty, private S3 bucket can lead to unexpected charges if it receives a high volume of unauthorized requests. Each request, even if denied, incurs a cost, which can accumulate rapidly, resulting in a significant increase in your AWS bill.
• This X (twitter) post refers to a 2020 incident where police departments using a poorly designed app on AWS faced massive bills after they were flooded with irrelevant k-pop videos, overwhelming the system during protests following George Floyd’s murder.

• Netlify $104,500 Bill Incident: In February 2024, a Reddit user reported receiving a $104,500 bill from Netlify for their static site, attributing it to an attack that spiked bandwidth usage to 60.7TB in a day. Although Netlify waived the charges, this incident, detailed in a Reddit post, illustrates the potential for DoW-like attacks to cause significant financial strain, especially for small sites on free tiers.
• Prompt Security’s GenAI Pen Test: This tweet shows how a pen test attack targets LLM-based applications, exploiting vulnerabilities to bypass rate limits and jailbreak systems, potentially granting unlimited access to resources like GPT-4, as demonstrated by Prompt Security’s penetration test.

These cases show that DoW attacks are real, and our architectural choices — whether for flexibility, scalability, or ease of use — can make us vulnerable. As architects, we need to ask: Are we designing systems that prioritize user experience or scalability at the expense of financial security?

Designing with DoW in Mind: Trade-Offs and Considerations

If you are wearing an architect’s hat, the job is to balance multiple factors: (including but not limited to) cost, maintainability, scalability, performance, and flexibility. But DoW attacks add a new dimension — financial resilience. Every design decision we make can either mitigate or exacerbate DoW risks, and often, there’s no perfect answer, just trade-offs. Let’s explore some key architectural considerations and the trade-offs involved:

1. Auto-Scaling: Scalability vs. Financial Risk
   Auto-scaling is a cornerstone of cloud architecture, ensuring systems handle traffic spikes without downtime. But in a DoW attack, aggressive scaling becomes a liability, inflating costs. As architects, we need to set hard limits on scaling (for example, capping the number of instances auto scaling can spin up). But there’s a trade-off: if that cap is too tight, you risk downtime during legitimate spikes, hurting performance and user experience. The key is balancing scalability against financial risk, and using tools like budgets to alerts offered by cloud platforms to keep you in the loop if costs exceed a threshold.
2. Serverless Architectures: Maintainability vs. Cost Exposure
   Serverless platforms cut down maintenance overhead (if used correctly ofcourse) — no servers to manage, automatic scaling, and pay-per-use pricing. But this abstraction can make DoW attacks harder to detect and mitigate, as we saw in the Lambda abuse case. As architects, we can mitigate this by implementing rate limiting (e.g: via API gateways) or setting concurrency limits on serverless functions. But the trade-off is complexity — adding these controls increases maintenance overhead, negating some of serverless’s benefits. We need to weigh maintainability against cost exposure.
3. Publicly Accessible Resources: Flexibility vs. Security
   Publicly accessible storage buckets or APIs are great for flexibility — think easy data sharing or third-party integrations. But as the above S3 bucket exploitation showed, they’re DoW magnets if not secured. As architects, we can use tools like AWS S3 Block Public Access to enforce private buckets or implement strict IAM policies. But the trade-off is usability — locking down resources might frustrate users or partners who need access. The challenge is balancing flexibility against security, ensuring openness doesn’t come at a financial cost.
4. Monitoring and Detection: Observability vs. Performance & Cost
   To catch DoW attacks early, we need granular monitoring of usage and costs, not just traffic. Tools like AWS CloudWatch, Azure Monitor, or Google Cloud Operations Suite can track per-service usage, while cost management tools like AWS Cost Explorer help spot unusual spending patterns. But here’s the trade-off: aggressive monitoring adds overhead, both in terms of performance (more logging means more compute) and cost (storing and analyzing logs isn’t free). We need to decide how much monitoring is enough, balancing detection against system efficiency.
5. Cost Optimization vs. DoW Resilience
   We often design systems to minimize costs — using spot instances, reserved capacity, or serverless to reduce idle resource expenses. But cost-optimized designs can sometimes increase DoW vulnerability. For example, a system that relies heavily on serverless might save money during normal operation but be more exposed to request-based attacks. An architect would need to consider cost optimization holistically, factoring in not just normal usage but also worst-case attack scenarios. The trade-off here is cost versus resilience, ensuring we don’t penny-pinch ourselves into vulnerability.

Mitigation Strategies

Armed with an understanding of DoW risks and trade-offs, let’s look at some practical mitigation strategies. These are the tools that an architect can resort to designing DoW-resilient systems, while keeping an eye on the bigger picture:

• Set Up Billing Alerts and Budget Caps: Use cloud provider tools like ‘Budgets’ to set spending thresholds and get alerts if costs spike. You can even automate actions, like shutting down resources, if costs go haywire. This is low-hanging fruit, minimal impact on performance or scalability, but a huge win for financial resilience.
• Implement Rate Limiting and Throttling: For serverless functions or APIs, use rate limiting via API gateways to cap request rates. This mitigates DoW attacks but adds complexity, a trade-off against system performance and maintainability.
• Secure Publicly Accessible Resources: Disable public access to cloud services unless absolutely necessary. This reduces flexibility but is critical for security. Regularly audit permissions with cloud platform built-in advisory tools.
• Monitor and Analyze Usage Patterns: Set up granular monitoring with tools like AWS CloudWatch or Azure Monitor to track usage and costs, not just traffic. Consider machine learning-based anomaly detection for subtle “low and slow” attacks. This adds overhead, so balance it against performance and cost.
• Use Web Application Firewalls (WAFs) and Bot Protection: Deploy a WAF, like AWS WAF, Azure WAF or Cloudflare, to filter malicious traffic. Pair it with bot protection (e.g. Cloudflare Bot Management) to block automated scripts. This enhances security but might impact performance, another trade-off to weigh.
• Limit Auto-Scaling and Resource Usage: Set hard limits on auto-scaling to prevent runaway costs, for example, cap the number of instances. This protects against DoW but risks downtime during legitimate spikes, so balance it against scalability needs.
• Educate Your Team on Cost Awareness: Human error, like misconfiguring services, can amplify DoW risks. Train your team to understand cloud cost structures and review usage reports regularly. This is a cultural strategy, not a technical one, but it’s crucial for long-term resilience.

Conclusion

Denial of Wallet attacks are a wake-up call for cloud architects. They remind us that our designs aren’t just about uptime, performance, or scalability — they’re also about financial resilience. As attackers get smarter, leveraging the very features we architect for, we need to think holistically, balancing DoW risks against the other pillars of good architecture.

The trade-offs are real. Aggressive auto-scaling ensures availability but increases financial risk. Serverless reduces maintenance but can obscure cost abuses. Publicly accessible resources enable flexibility but invite attacks. Granular monitoring catches DoW early but adds overhead. As architects, our job is to navigate these trade-offs, making informed decisions that align with our business goals — whether that’s cost efficiency, user experience, or innovation.

The good news? We’re not defenseless. By understanding how DoW attacks exploit our designs, we can build systems that are not only scalable and performant but also financially resilient. As cloud adoption grows, staying vigilant — learning, adapting, and refining our designs — will be key to staying ahead of the game.

So, next time you’re sketching out a cloud architecture, remember: it’s not just about handling traffic or minimizing latency. It’s also about keeping an eye on your cloud bill. Because in the cloud, a well-designed system isn’t just one that scales — it’s one that scales smartly, without breaking the bank.