Безопасная диагностика оставшегося Service Association Link в Azure VNet после удаления managed environment: читаем зависимости, delegation и linkedResourceType, не применяя force-delete вслепую.
Определите, что именно блокирует удаление
Не начинайте с повторного Delete. Сохраните точный код операции и прочитайте свойства каждой subnet: delegations, serviceAssociationLinks и linkedResourceType. Azure-сервисы создают SAL, когда разворачивают ресурс в subnet; ссылка может оставаться после удаления видимого объекта и блокировать изменение или удаление сети. Это описание механизма, а не разрешение стереть поле. Запишите также статус удаления managed environment и наличие связанных private endpoints, NAT gateway или других ресурсов, не публикуя resource IDs.
Проверьте живые и скрытые зависимости
Откройте resource group с включённым отображением hidden types и сопоставьте linkedResourceType с фактически существующими ресурсами. Для Container Apps при пользовательской VNet создаются дополнительные managed resources, поэтому пустой список приложений ещё не гарантирует завершённую очистку environment. Проверьте операции развертывания и удаления, но ничего не перемещайте между группами. Если живой ресурс всё ещё использует subnet, сначала завершите его штатный lifecycle. Удаление сети под активной зависимостью не является диагностическим экспериментом.
Дайте платформе завершить штатную очистку
Официальная инструкция по subnet рекомендует после подтверждения отсутствия связанных ресурсов подождать 10–15 минут и повторить операцию, поскольку сервис может убирать SAL асинхронно. Зафиксируйте время завершения удаления environment и время повторной проверки. Не создавайте новый ресурс с тем же именем только ради очистки и не запускайте параллельные delete-запросы. Если link исчезает после ожидания, это штатная последовательность. Если остаётся при статусе удаления Succeeded, переходите к доказательствам для поддержки.
Не применяйте чужой force-delete к Microsoft.App
В документации есть сервис-специфичные способы очистки для ACI или App Service, но они адресуют их собственные linkedResourceType и API. Их нельзя автоматически переносить на связь Microsoft.App от Container Apps. Ручное удаление serviceAssociationLinks или delegations может оставить несогласованное состояние либо затронуть другой ресурс. Безопасная граница — read-only инвентаризация и официальный путь конкретного сервиса. Если Azure предлагает поддерживаемую операцию в сообщении ошибки, проверьте её применимость к точному provider type до выполнения.
Эскалируйте backend-состояние с коротким пакетом
Остановитесь и откройте технический запрос, если managed environment отсутствует или имеет завершённое удаление, других потребителей subnet нет, ожидание прошло, а SAL сохраняется. Передайте subscription и resource IDs только в защищённом канале поддержки, а также region, linkedResourceType, operation IDs, timestamps и JSON свойств subnet после удаления секретов. Не прикладывайте токены или публичный экспорт инфраструктуры. Production-сеть должна оставаться неизменной до подтверждения, что link действительно orphaned и его очистка не затронет живые ресурсы.
Материал подготовлен самостоятельно с автоматизацией и редакционно проверен 30 июля 2026 года по обезличенному публичному сигналу и официальной документации Azure; имена VNet, subnet, подписки и managed environment не использовались.
Источники и проверка
- Microsoft Learn — ошибки удаления и изменения Azure subnet проверено 2026-07-30
- Microsoft Learn — пользовательские VNet для Container Apps проверено 2026-07-30
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.