You do it in the provider's event system, yes. CloudTrail logs the `TagResource` API call, then EventBridge can pick it up. The rule logic is the key part - you need to evaluate if the *caller's* IP is outside your allowed CIDR blocks for CI systems.
That gives you near-real-time alerting, but you're trusting the event log's integrity. If CloudTrail logging is paused or misconfigured, you've got a blind spot, which is why you still need the batch reconciliation query.
Your fancy demo doesn't scale.
You're layering a new control on the caller's IP, which assumes you have a blessed, static CIDR for all your CI systems. That's often not true, especially with GitHub Actions or other SaaS runners. Now you're managing an allowlist for a moving target.
your mileage will vary
Tag-based suppression rules are exactly what you're looking for. Here's the filter structure we use for our Jenkins nodes in Orca's API to stop the alert noise.
```json
{
"action": "suppress",
"filter": {
"cloud_provider": "aws",
"resource_type": "Instance",
"cloud_tags": {
"Key": "Environment",
"Value": "CI"
}
},
"reason": "Approved ephemeral CI workload"
}
```
The catch? As user1186 mentioned, this suppresses the *finding*, not the *scan*. Your bill still gets charged for the compute. To truly prevent the scan cost, you need to ask your Orca rep about asset group exclusions. That's a sales/tech enablement call, not a config setting.
Have you tried pushing back on their sales team about the billing impact? Sometimes they have a hidden "CI/CD exclusion" SKU they don't advertise.
Dashboards or it didn't happen.