A customer called us on a Friday. Their signup page was being hammered by bots. Hundreds of fake accounts were being created every hour, each one using a real person’s email address. Their system was dutifully sending welcome emails to all of them.
The result? Their email sender reputation was tanking. Fast. They were days away from getting their domain blacklisted and their AWS SES access suspended. That’s not a theoretical risk, SES will shut you down if your bounce and complaint rates cross the threshold.
They needed it stopped, Now!
The problem with traditional defences
The obvious first move is IP-based blocking. Identify the suspicious sources, block them, move on. Simple.
Except some of these bots were routing through the Tor network. Every request came from a different exit node. Block one IP, another one takes its place seconds later. It’s a game you can’t win with rate limiting and IP blacklists alone.
The bots weren’t sophisticated in what they did:
- create account,
- trigger email,
- repeat
but they were very effective at hiding where they came from. Traditional IP-based controls were useless.
Why this was more dangerous than it looked
On the surface, fake signups sound like a nuisance. Annoying, sure. But dangerous?
Yes. Here’s why.
Email sender reputation is fragile. When your domain sends hundreds of emails to addresses whose owners never signed up, those people mark them as spam. Mailbox providers notice. Your domain reputation score drops. Legitimate emails, order confirmations, password resets, invoices, start landing in spam folders. Or get blocked entirely.
AWS SES has hard limits. Amazon monitors your bounce rate, complaint rate, and sending patterns. Cross the line and SES puts your account under review. Cross it further and they suspend sending entirely. For a business that depends on transactional email, that’s an outage.
It escalates quickly. Bot attacks don’t taper off. They accelerate. Every hour of inaction means more fake accounts, more bounced emails, and more reputation damage to undo. Recovery from a blacklisted domain takes weeks. Sometimes months.
AWS WAF: the right tool for the job
We deployed AWS WAF in front of their application. WAF sits at the edge, inspecting HTTP requests before they reach your backend. It’s native AWS, integrates with CloudFront, ALB, and API Gateway, and gives you granular control over what traffic gets through.
For this engagement, we focused on three things:
Managed rule groups. AWS WAF comes with curated rule sets maintained by AWS and vetted third parties. These include rules specifically designed to identify and block known bad actors, including traffic originating from anonymising networks. We activated the relevant managed rules and immediately started filtering the most obvious bot traffic.
Behavioural pattern matching. Beyond known-bad IPs, we configured rules to detect the patterns these bots exhibited. The signup requests had characteristics that distinguished them from legitimate user behaviour. WAF let us define rules that matched those patterns without disrupting real users.
Rate-based rules. Even with Tor, the volume of requests from individual exit nodes exceeded what any legitimate user would generate. Rate-based rules added another layer, automatically blocking sources that exceeded reasonable thresholds within a given time window.
The combination worked. Within hours, fake signups dropped to near zero.
The outcome
| Metric | Before | After |
|---|---|---|
| Fake signups per hour | Hundreds | Near zero |
| SES bounce rate | Dangerously high | Within safe thresholds |
| Email sender reputation | Degrading rapidly | Stabilised and recovering |
| Legitimate user impact | None | None |
The customer’s email flow was restored. SES stayed active. Real users never noticed a thing.
Beyond the immediate fix
Stopping the attack was step one. But bot attacks don’t happen once. They come back. Often smarter.
AWS WAF isn’t a set-and-forget tool. It needs monitoring and tuning. We configured logging via WAF’s integration with CloudWatch to track blocked requests, identify new patterns, and adjust rules as attacker behaviour evolves.
For broader security visibility, we also recommended the customer integrate GuardDuty and Security Hub into their monitoring stack. GuardDuty catches unusual activity at the infrastructure level, compromised instances, anomalous API calls, reconnaissance patterns. Security Hub aggregates findings from WAF, GuardDuty, and other sources into a single compliance-aware dashboard.
Together, these three services create a layered defence:
| Layer | Service | What it covers |
|---|---|---|
| Edge protection | AWS WAF | HTTP-level filtering, bot mitigation, rate limiting |
| Threat detection | GuardDuty | Infrastructure threats, anomalous behaviour |
| Posture management | Security Hub | Aggregated findings, compliance dashboards |
No single tool covers everything. But stacked correctly, they cover each other’s blind spots.
The NIS2 angle
If you’re operating in the EU, bot mitigation isn’t just good practice. It’s becoming a compliance requirement.
NIS2, the EU’s updated directive on network and information security, mandates that organisations in essential and important sectors implement appropriate measures against cyber threats. Bot attacks that compromise email infrastructure, create fraudulent accounts, or disrupt service availability fall squarely within that scope.
Having a documented, automated response capability (like WAF with managed rules and monitoring) demonstrates the kind of “appropriate technical measures” NIS2 expects. It’s not the whole compliance picture, but it’s a meaningful part of it.
When things go wrong, speed matters
This engagement reinforced something we see again and again: the difference between a minor incident and a serious one is response time.
The customer’s email reputation was already damaged when they called us. Another week of inaction and they’d have been looking at a blacklisted domain and suspended SES access, with cascading effects on their entire business communication.
We had WAF deployed and filtering traffic within hours. Not because the technology is magic, but because we’ve done this before. We knew which rules to activate, how to configure them without blocking legitimate users, and how to validate the results under pressure.
That’s what you get from a team that lives in AWS every day.
Don’t wait for the attack
Most organisations think about bot protection after the bots arrive. By then, the damage is already accumulating. WAF rules that take an hour to configure during normal operations take the same hour during an incident, but with a lot more stress and a lot less margin for error.
If you’re running signup flows, payment forms, or any publicly exposed application on AWS, the question isn’t whether bots will find it. It’s when.
We help you respond to threats fast and prevent the next one.
Talk to us about securing your AWS environment →
Forrict
AWS expert and consultant at Forrict, specializing in cloud architecture and AWS best practices for Dutch businesses.
