Managed Instance sur App Service passe en GA : sortir vos .NET Framework 4.8 des VM IIS sans réécrire — scripts d'install, adaptateurs de registre, NAT Gateway

Pendant quinze ans, la réponse d’Azure aux applications ASP.NET Web Forms et MVC 5 tournant sur des VM Windows Server a été binaire : soit vous acceptiez le carcan du sandbox App Service (pas de COM, pas de registre, pas d’installeur), soit vous restiez en IaaS avec la charge de patch qui va avec. Managed Instance on Azure App Service casse cette dichotomie. Avec le passage en disponibilité générale, c’est le premier chemin App Service qui accepte les composants COM, l’écriture dans le registre, l’exécution de MSI et l’ouverture d’une session RDP sur les instances de votre plan.

L’intérêt n’est pas théorique : les parcs de VM IIS 2012 R2 et 2016 sont hors support ou en fin de course, et le budget d’une réécriture vers .NET 8 dépasse souvent la valeur métier résiduelle de l’application. Voici comment évaluer, configurer et exploiter cette option sans se créer une nouvelle dette.

Avertissement de méthode : la documentation Learn est encore partiellement estampillée « preview » sur plusieurs pages, et la liste des régions ainsi que les noms exacts de propriétés ARM/CLI évoluent. Traitez les extraits ci-dessous comme des patrons à recouper avec la documentation du jour avant tout engagement contractuel.

Ce que la GA change réellement (et ce qu’elle ne change pas)

Premier point d’architecture souvent mal compris : Managed Instance n’est pas une nouvelle offre IaaS, ni une variante d’App Service Environment. C’est une option activée au niveau de l’App Service Plan (plan-scoped). Vous continuez à déployer des Web Apps, des slots, des règles de scale-out ; ce qui change, c’est…