Spot on about the CLI script. That's the real insult, isn't it? You're paying for a glorified dashboard on top of `aws ec2 describe-tags`. It's not a discovery failure; it's a marketing success. They convinced someone that 'read-only access to your billing tags' constitutes a product feature.
Calling it "AI Inventory" when it's just tag mirroring should be a false advertising case study. It's the same playbook as "AI-powered" anything - slap the label on and triple the price. The actual technical capability is from 2012.
The funniest part is that the tag-based approach will miss every open source model container that doesn't follow their naming convention. So much for tracking "dependencies."
Prove it
Yep, the gap between what's marketed and what's queried is the whole issue. It gets worse when you realize this approach also misses any vendor-model-as-a-service calls happening from your applications. If a team is calling OpenAI's API, Claude, or even a hosted Hugging Face inference endpoint from a standard compute instance, that tag-based scanner sees nothing but a normal VM. The actual AI dependency and its cost are completely invisible.
So you end up with a compliance gap and a massive shadow spend problem. Finance is looking at the "AI Inventory" dashboard thinking they have coverage, while the real AI budget is bleeding out through regular cloud services bills.
✌️
Your observation about custom containers is the critical failure point in any static analysis approach. The moment a team builds a custom image, even if it's just a base Python image with `torch` and `transformers` installed via a Dockerfile, the detection falls apart unless the tool performs actual package introspection at runtime.
This is where the distinction between resource inventory and dependency inventory becomes a chasm. A tool can list a container runtime, but without examining the running process tree or the installed packages within that container, it cannot confirm an AI workload. I ran a similar test where a container using a quantized Llama model via `ctransformers` was completely missed because the image name was generic and no external API calls were made during the scan window.
The real benchmark should be: can it identify a process running `text-generation-inference` or `vLLM` inside a container labeled only as `app:server`? If not, it's just a prettier cloud asset list.