DA - ну не надо изврата )

Закопайте уже бедную стюардессу. Он сколько лет уже deprecated.

я с DA накушался в своё время, мне хватило )

работает збс :)

на скоко клиентов ? )

дык оно предок не?

Идеологически да, технически не совсем. Можно грубо сказать, что AoV "наследник" DA, но если ты использовал DA и хочешь просто (!! боже, как я ненавижу это слово) смигрировать на AoV, типа как на DA v2.0, то ответ будет - НЕ ДЕЛАЙ ЭТОГО. Использование ванильных VPN-решений, хоть от кого, в 2020 году это очень, очень хреновая идея.

Нифига вы тут нафигачили. Но я начну отсюда, где остановились.
Почему? By design. Потому что Azure AD - это неотчуждаемый публичный облачный сервис, то есть такая штука, которая размещается, обслуживается и развивается его разработчиком. Вы же не спрашиваете, почему нельзя разместить Google Apps в AWS? Потому что. Кроме того, есть и несколько чисто технических моментов. Во-первых, минимальный штамп, в который AAD - теоретически! - могла бы влезть, это порядка тысячи физических серваков, будет очень дорого и сложно. Во-вторых, весь смысл его в его централизованности и нахождении в облаке. Фактически, инфраструктура AAD это один большой распределенный сенсор, который позволяет обеспечивать ту самую "киберустойчивость" - возможность противостоять современным атакам. Например, "с земли" вы не увидите атаку password spray никак, а AAD отловит ее на изи.
Теперь вопрос второй: а нахрена вам это собственно надо? Возможный ответ: ну, мне нравится как AAD работает, нравится Conditional Access, я хочу его использовать для входа в Google Apps/AWS/you name it. Ответ: не вопрос, вы можете это сделать. В AAD есть прямо каталог веб-приложений с уже настроенным SSO, и их там что-то очень много, тысячи три было когда я последний раз смотрел. Больше того, вы можете интегрироваться со всем, что понимает стандартные протоколы веб-аутентификации (SAML, OAuth...), либо вообще просто имеет форму логина и кнопку "войти". Если это ваше собственное приложение - есть SDK (MAL, Microsoft Authentication Library, aka ADAL), который можно туда интегрировать.
Либо вот: я странный парень, я хочу чтобы точка аутентификации пользователя при использовании AAD находилась непременно в AWS. Не вопрос: поднимаем там контроллер домена (новый, или в существующем лесу) и настраиваем аутентификацию через ADFS или PTA.
Можно еще повысасывать из пальца. Потеря сетевой связности - не ваша проблема, кроме того у МС собственная глобальная сеть передачи данных, если не крупнейшая, то точно в топ-3. Если ее положат, недоступность AAD будет не самой большой из проблем всего мира. Санкции! В этом случае сервис перестанет для вас работать независимо от его гео-расположения. Напоминаю, SAP "Силовых машин" был в датацентре Ростелекома, где успешно превратился в тыкву.
На этом у меня фантазия заканчивается, если у вас есть сценарий, который прямо вот требует развернуть AAD где-то еще, не там где она развернута, то выкладывайте его сюда.

>Напоминаю, SAP "Силовых машин" был в датацентре Ростелекома, где успешно превратился в тыкву.
И недавно я видел новость об "успешном внедрении" пересборки CentOS от РЕД СОФТ у Ростелекома
Совпадение? Не думаю.
>Потому что Azure AD - это неотчуждаемый публичный облачный сервис
Я могу понять, почему не отчуждаемый. Но учитывая усиленную интеграцию в ОС, самой распространённой в мире, не могу не видеть в Azure AD клон G Suite.
Просто, ну очень похоже.
В том же Chrome OS тоже можно зайти в УЗ G Suite напрямую.
Теперь в Windows можно зайти в корпоративный MSA сразу после установки.
И завидно и страшно одновременно.