I was conducting a routine review of our Trend Micro Cloud One - File Storage Security audit logs in our SIEM when I noticed repeated scan events for a specific set of Amazon S3 buckets that I was certain contained only static, public website assets. This seemed like an unnecessary consumption of our scanning quota and added noise to our compliance reporting. Upon digging into the documentation and opening a support ticket, I discovered a highly useful, albeit not prominently featured, capability: you can exclude S3 buckets from scans using AWS resource tags.
The mechanism is straightforward. Within the File Storage Security workload, under the "Accounts" section where your AWS accounts are linked, you can define exclusion rules. The key is to use the `s3:ResourceTag/` condition in a scannable path rule with a "Skip" action. This allows for granular control without having to manipulate entire account or region scan settings.
Here is a JSON example of the policy configuration I applied to our staging account to skip buckets tagged with `Scan: false`:
```json
{
"scannablePaths": [
{
"bucketNamePattern": "*",
"conditions": [
{
"conditionType": "awsResourceTag",
"key": "Scan",
"value": "false"
}
],
"action": "skip"
}
]
}
```
The operational and compliance benefits are significant:
* **Cost Optimization:** It prevents the consumption of scan units on buckets that contain only non-executable files (e.g., log archives, static media, pre-scanned vendor data). This directly impacts the operational cost of the service.
* **Audit Clarity:** It reduces noise in the File Storage Security findings console and, more importantly, in the aggregated audit logs we ship to Splunk. Our SOC team's alert fatigue for low-priority buckets is reduced.
* **Granular Control:** It offers a more precise method than excluding entire accounts or regions, which is crucial for organizations with complex, multi-purpose AWS environments. You can tag buckets used for sensitive data (like PII in a landing zone) to ensure they are *always* scanned, while excluding others.
* **Automation Friendly:** Since it's tag-based, it integrates seamlessly with existing AWS provisioning workflows (e.g., Terraform, CloudFormation) where tags are already a standard control mechanism.
From a SOX and GDPR perspective, this is a double-edged sword that requires diligent log review. You must ensure that your tag governance is strict and that the exclusion logic is explicitly documented in your control narratives. The Cloud One audit logs will still record the "skip" evaluation, which is vital. I now have a scheduled search in our Splunk that looks for any create/update events on these exclusion rules and correlates them with changes to the `Scan` tag on high-criticality buckets, providing an essential detective control.
Logs don't lie.
Nice find! That's super relevant to my usual rant about tagging discipline in IaC. If you're defining buckets with Terraform or CloudFormation, you can embed that `Scan: false` tag right in the module/resource. Makes the exclusion automatic the moment the bucket is created.
One caveat though: watch out for tag propagation delays. I've seen cases where a bucket is scanned once before the tag-based exclusion rule picks it up, especially if your scanning cycle is frequent. Maybe add a naming pattern as a secondary rule for brand-new buckets?
git push and pray
Absolutely, the IaC angle is the right way to enforce this. I'd add that you should formalize the tag key-value pair as a variable in your Terraform module, with a sensible default like `scan_enabled = true`. That way, teams have to explicitly opt-out for special buckets, which drives better auditability than letting them set arbitrary tag values.
Regarding propagation delays, that's a solid observation. In my tests, using an S3 event notification to trigger the scan (common for compliance setups) means the scan can fire literally seconds after bucket creation, easily beating tag rule evaluation. A naming convention fallback, like `-public` or `-static`, is a pragmatic backup.
-- bb42
You've both hit on a key operational detail with the propagation delays. That's a scenario where the default of `scan_enabled = true` actually works against you, if a compliance scan fires on creation before the tag is seen.
One approach we've used is to stage the bucket creation and the scan policy activation as separate, sequential Terraform applies in the pipeline. It adds a step but eliminates that race condition entirely.
— isabel
Thanks for sharing that JSON snippet, it really clarifies the syntax. Setting the bucketNamePattern to "*" and then using the condition to filter is the perfect approach for a broad rule. I'm curious, did you find the tag evaluation happens at the scan scheduling time, or is it checked in real-time as each object is scanned? That could matter for buckets where tags might change after the initial scan is queued.
still learning
Staging the Terraform applies is a clever, if manual, workaround. It does shift the burden from runtime race conditions to pipeline discipline.
It reminds me of a pattern some teams use for security group rules: create the resource first with a "safe" default state, then apply the permissive rules in a second pass. Same concept, different resource.
Have you found the extra pipeline step causes any friction or delays in your deployment timelines?
Stay curious, stay critical.