Azure Container Apps (ACA) séduit de plus en plus les équipes TI grâce à sa simplicité : déployer des containers sans gérer d’infrastructure, profiter de la scalabilité automatique et bénéficier d’une intégration native avec Dapr et le serverless.
Mais dès que les applications deviennent un peu plus sérieuses — sécurité, réseau, intégrations privées — une question revient systématiquement :

Dois-je utiliser le VNET géré d’Azure ou configurer un VNET personnalisé (custom VNET) ?

Dans ce billet, on clarifie vraiment quand utiliser l’un ou l’autre.

1. Les deux modes d’intégration réseau ACA

Option 1 — VNET géré (Azure-managed VNET)

Azure crée automatiquement un VNET interne et deux subnets.
Avantages :

aucune configuration réseau
rapide à mettre en place
idéal pour les POC, labs ou apps publiques simples

Limites :

impossible d’ajouter des NSG, UDR, peering, firewall…
impossible d’accéder à des Private Endpoints
trop restrictif pour les environnements d’entreprise

Option 2 — VNET personnalisé (customer-managed VNET)

L’organisation fournit son propre VNET et ses subnets.

Avantages :

réseau 100% contrôlé
intégration possible dans un hub-spoke
accès sécurisé aux ressources privées
contrôle complet du trafic entrant et sortant

C’est cette option que l’on choisit dès que l’application n’est plus un simple test.

2. Les vraies raisons professionnelles de choisir un custom VNET

Voici les justifications réelles, celles que tu donneras en revue d’architecture ou en comité de sécurité.

1. Accéder à des services PaaS via Private Endpoint

C’est la raison N°1 dans 80% des projets.

Si ton application doit accéder à :

Azure SQL en Private Endpoint
Azure Storage
Azure Service Bus
Cognitive Services / OpenAI
Redis Cache privé
Key Vault privé

Elle doit obligatoirement être dans un VNET.

Le VNET géré ne peut pas être raccordé aux Private Endpoints. Par défaut, Container Apps est intégré au réseau Azure, qui est accessible publiquement sur Internet et ne peut communiquer qu’avec des points de terminaison accessibles à Internet

2. Communication interne privée entre services

Certaines API, microservices ou backends ne doivent jamais sortir sur Internet.

Avec un VNET personnalisé, tu peux utiliser :

NSG (Network Security Groups)
UDR (User-Defined Routes)
Azure Firewall ou une NVA
segmentation frontend/backend
règles Zero Trust

Rien de cela n’est possible avec un VNET géré.

3. Intégration à une architecture hub-spoke d’entreprise

De nombreux clients ont :

un hub réseau central
des appliances réseau (firewall, IDS/IPS)
ExpressRoute vers le datacenter
un DNS interne

Pour participer à ce réseau, ACA doit être dans un custom VNET.

Le VNET géré, isolé et non configurable, ne peut pas s’y intégrer.

4. Interdire ou contrôler la sortie Internet

Certaines organisations doivent :

empêcher toute communication publique
tracer tout le trafic
passer obligatoirement par un firewall

Avec un VNET personnalisé :

✔ Tout sort via un firewall ou une NVA
✔ Tu peux imposer une liste stricte d’egress
✔ Tu peux créer un environnement “air-gapped”

Avec un VNET géré :

Impossible — Azure gère le réseau et des dépendances publiques restent obligatoires.

5. Dapr et microservices internes sur un réseau sécurisé

Si tu utilises Dapr :

sidecars
bindings internes
service-to-service sécurisé
restrictions DNS

Un VNET personnalisé est recommandé pour un modèle Zero Trust interne.

6. Exposer une application ACA via Private Endpoint (Ingress privé)

De plus en plus de clients exigent :

aucune IP publique
accès interne uniquement
architecture Private Link

L’ingress privé des Container Apps nécessite un custom VNET.

Le VNET géré ne peut pas héberger un Private Endpoint pour l’ingress.

7. Conformité, certifications ou sécurité accrue

Pour les environnements :

PCI-DSS
finance
santé
secteur public
données sensibles

La règle est souvent :

« Tous les workloads doivent résider dans un VNET contrôlé par le client. »

Le VNET géré est automatiquement refusé lors des audits réseau et sécurité.

Conclusion : Quand utiliser quoi ?

Besoin	VNET géré	Custom VNET
Déploiement rapide	✅	❌
Tests / POC	✅	❌
Accès Private Endpoint	❌	✅
Architecture hub-spoke	❌	✅
Contrôles réseau (NSG/UDR/Firewall)	❌	✅
Outbound lockdown	❌	✅
Ingress privé	❌	✅
Conformité stricte	❌	✅
Microservices sensibles / Dapr sécurisé	❌	✅

Si ton application touche au réseau de l’entreprise, aux Private Endpoints ou à la sécurité : tu prends un custom VNET. Point final.
Si tu fais un POC ou une app publique simple : VNET géré suffit.

Azure Container Apps : Quand utiliser un VNET personnalisé plutôt que le VNET géré ?