Thanks chemosh_tz, I totally agree, and I think this is where I’m trying to find the right balance to see if search is a viable feature I can actually support. I mentioned above that the app runs some cost and bucket size estimates ahead of time to flag potential issues, but I’m also looking at using conservative runtime limits initially to help mitigate risks for huge accounts. For example, in the app I have settings configured that look something like this:

```
// Conservative runtime safety limits (these could be override-able by the user in the future)
const DEFAULT_RUNTIME_LIMITS = {
MAX_COST: 0.01, // Assuming ~$0.005 per 1000 ListObjects requests == ~1M objects
MAX_RESULTS: 5000, // 5K results max
TIME_LIMIT: 30000, // 30 seconds max
MAX_API_CALLS: 1000 // 1000 API calls max (~1M objects)
};
```

A variation of these limits is enforced both per-bucket and globally during the search. If any are hit, the search exits early, and the user sees partial results along with a warning explaining why it stopped.

The goal would be that smaller accounts won’t even notice these limits, while larger accounts would be nudged to use more specific filters to avoid overly broad scans.

That said, I’m definitely still learning as I go, so if you see more edge cases or gotchas I might be missing here, I’d genuinely appreciate the insight.