What it is
A route table whose subnets array is empty. User-defined routes only take effect once the table is associated with a subnet, so an unattached one influences nothing. It is a free resource, which is exactly why it tends to stay.
Why it happens
Route tables get detached during network redesigns: a subnet is rebuilt, a UDR strategy is replaced, a hub-and-spoke topology is reworked. Azure leaves the old route table in place, and with no charge attached, no cost review ever surfaces it.
The subtle problem is that its routes still read like they matter. Someone auditing traffic flow sees rt-spoke-legacy with a 0.0.0.0/0 route to a firewall appliance and reasonably assumes it is in force, when in fact no subnet points at it. Detached route tables make the real routing picture harder to trust.
What it costs / blast radius
Nothing on the bill. The harm is governance: an unattached route table is inert configuration that clutters inventory and can mislead anyone tracing how traffic is supposed to move through the network. A route defined here changes no packet's path until the table is associated, so it is easy to misread as active policy. (Authored assessment of Azure behavior, not a measured statistic.)
See it
Resources
| where type =~ 'microsoft.network/routeTables'
| where array_length(coalesce(properties.subnets, dynamic([]))) == 0
| project name, resourceGroup, subscriptionId, location,
routeCount = array_length(properties.routes)// An empty subnets array means the routes apply to nothing.
az network route-table show --name rt-spoke-legacy --resource-group rg-net \
--query "subnets"
az network route-table delete --name rt-spoke-legacy --resource-group rg-netHow StratoLens helps
StratoLens inventories every route table across every subscription in your own tenant and flags the ones associated with no subnet, so stale user-defined routes stop clouding your view of how traffic actually flows. Continuously and automatically, across the whole estate.