Application inference profiles no request has routed through in a month
What does ZopNight detect here?
An application inference profile is a routing and attribution wrapper: per-token billing happens only when requests flow through it, so 30 days of zero invocations means $0 spent and $0 recoverable. ZopNight surfaces the unused profile because dead profiles corrupt the cost-attribution story they exist to provide.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1633 |
| Category | advisory |
| Severity | low |
| Metric | none — pure configuration read |
| Source | bedrock_inference_profile_unused.go |
Where it applies
What an inference profile is actually for
Application inference profiles exist so organisations can slice on-demand Bedrock usage: tag a profile per team or workload, route each application’s calls through its own profile, and the token bill becomes attributable. The profile itself is pure configuration: it holds no capacity, reserves nothing, and bills nothing until a request passes through it. That makes its idle economics trivial (zero either way) and its governance role the entire point.
Why a free object still earns a finding
Cost tooling and tag-based reports treat profiles as the unit of attribution. A profile with no traffic is either an application that was decommissioned without its plumbing, or an attribution scheme half-rolled-out, and both states mislead whoever reads the cost breakdown next quarter. ZopNight files this as advisory with an explicit $0: the action (delete the profile, or finish wiring the application to it) is concrete even though the invoice impact is nil.
Detection and its guards
Zero-invocation Bedrock resources emit no Invocations series at all, a consequence of the way Bedrock reports counts to CloudWatch, so the rule reads a missing series (against an org metrics fetch that returned data) as the unused signal, while any present series with activity suppresses it. The one org-wide failure mode, a metrics fetch that returned nothing for anyone, is guarded separately: an empty metrics map abstains entirely rather than mass-firing delete suggestions across every profile in the account.
Check a profile’s traffic
aws cloudwatch get-metric-statistics \ --namespace AWS/Bedrock --metric-name Invocations \ --dimensions Name=ModelId,Value=<inference-profile-arn> \ --start-time "$(date -u -v-30d +%Y-%m-%dT%H:%M:%SZ)" \ --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \ --period 86400 --statistics Sumaws bedrock list-inference-profiles --type-equals APPLICATION enumerates the candidates.
Cleanup order of operations
Confirm no application config still references the profile ARN. A deleted profile turns those calls into errors, which is the one way this $0 cleanup can cost something. Check whether any cost-allocation reporting keys on its tags, then delete. Recreating a profile later is a single API call, so the reversible-decision bar is low; the unrecoverable asset is only the historical attribution, which is already in your cost reports.