Hey folks, I've been living in the iboss dashboards for the past few weeks, trying to get a clean signal on our web traffic patterns. One thing that was driving me absolutely *nuts* was the sheer volume of "noise" from AWS health checks. Our infrastructure is ELB-heavy, and those constant pings to our instances were completely muddying the waters in the **Web Activity** and **Threat Dashboard** views. Every other entry seemed to be from an AWS IP checking `/health` or `/ping`.
After a deep dive into support docs and some trial-and-error, I finally cracked the code for a clean filter. It's not a single checkbox, but a combination of a custom policy and a dashboard filter. Here's my step-by-step.
### Step 1: Create an Allow Policy for AWS Health Check IPs
The goal here isn't to block them (they need to succeed), but to isolate them so they can be filtered out of threat and activity reporting. You create a very specific Allow policy.
1. Navigate to **Policies > Web**.
2. Click **Add Policy**.
3. Set a clear name, like `"ALLOW - AWS Health Checks"`.
4. Under **Sources**, add the AWS IP ranges. You can get these from the [AWS IP Ranges JSON]( https://ip-ranges.amazonaws.com/ip-ranges.json). Look for the `prefixes` where `"service": "EC2_INSTANCE_CONNECT"` isn't the right one; you want the general EC2 ranges, often tagged `"service": "EC2"` or `"service": "AMAZON"`. I used the `us-east-1` and `us-west-2` ranges relevant to us.
5. Under **Destinations**, specify your internal health check endpoints if you want to be extra tight (e.g., `*.yourdomain.com/health*`).
6. Set **Action** to `Allow`.
7. **This is the key part:** Go to the **Advanced** tab. Find the setting for **Logging** or **Send to Threat Dashboard**. You need to **DISABLE** logging for this policy. In my version, it's a checkbox labeled *"Send to Threat Dashboard"* and *"Log this transaction"*. Uncheck both.
*This prevents these allowed requests from ever hitting the threat logs.*
**Why this works:** By allowing the traffic but disabling logging, the requests pass through silently without generating a log entry. They're effectively invisible to the reporting engine.
### Step 2: Create a Dashboard Filter (For Historical Data & Other Policies)
The policy above handles *new* traffic. But you might have historical data, or health checks that hit other endpoints. For that, you can create a reusable dashboard filter to exclude the AWS IP ranges from any view.
1. In your dashboard (e.g., **Web Activity**), click the filter icon.
2. Choose **Edit Filters** or **Manage Saved Filters**.
3. Create a new filter with a name like `"Exclude AWS Health IPs"`.
4. Set the condition to `Source IP` `is not in` `[List of AWS CIDR blocks]`.
You'll need to paste in those same CIDR blocks (e.g., `192.0.2.0/24`, `203.0.113.0/24`). It's a bit tedious, but you only do it once.
Now, applying this saved filter to any dashboard view instantly cleans out the AWS health check noise. The difference is night and day.
**Before:** Pages of entries from `10.0.0.0/16` to our `/health` endpoint, drowning out actual user activity.
**After:** A clean view of actual user traffic and legitimate threats.
It's a simple two-prong approach: a non-logging Allow policy for the future, and a saved filter to clean up the past. This has made my dashboard monitoring so much more actionable. Has anyone else found a different or more elegant way to handle this kind of infrastructure noise? I'm curious if there's a way to do it purely at the filter level without needing the policy.
Glad you found a solution, but I've always wondered why we accept this architectural tax in the first place. You're spending cycles on custom policies and dashboard filters just to see your own data because AWS decided the only way to know if an instance is alive is to hammer it from their public IP space. For smaller services, have you considered moving to a simpler setup, like a single Application Load Balancer with target groups that use private VPC endpoints for health checks? It's a bit more work initially, but it eliminates the whole "noise in the dashboard" problem because the checks never hit your public-facing logs.
keep it simple