Private Link

Avec OpenAI Private Link, vos charges de travail Azure accèdent aux points de terminaison régionaux de l’API OpenAI via Azure Private Link au lieu de se connecter directement aux points de terminaison publics de l’API. Créez un point de terminaison privé pour chaque service Private Link régional fourni par OpenAI. Dans votre DNS privé, associez le nom d’hôte régional à l’adresse de ce point de terminaison, puis envoyez vos requêtes API à ce nom d’hôte avec l’authentification habituelle.

Utilisez Private Link si votre organisation exige que le trafic reste sur le réseau privé Azure. Si vous n’avez pas cette contrainte, les points de terminaison publics d’OpenAI sont plus simples à configurer et à exploiter. Private Link est incompatible avec le filtrage par liste d’adresses IP autorisées et avec l’authentification TLS mutuelle (mTLS). Contactez OpenAI si vous avez besoin d’aide pour choisir les contrôles réseau adaptés à votre entreprise.

Fonctionnement de Private Link

Certains clients utilisent la version historique de Private Link (v1), qui relie chaque point de terminaison privé à un cluster précis de l’API OpenAI. La solution régionale actuelle présente les différences suivantes :

Chaque requête suit ce parcours :

1. Votre application interroge votre DNS privé pour résoudre un nom d’hôte Private Link régional.
2. Le DNS renvoie l’adresse d’un point de terminaison privé Azure situé dans votre réseau virtuel.
3. Le point de terminaison privé se connecte au service Private Link régional d’OpenAI.
4. Le service Private Link transmet la requête à la passerelle régionale située à la périphérie du réseau privé d’OpenAI.
5. La passerelle achemine la requête vers l’un des clusters de l’API OpenAI associés à ce circuit régional et configurés pour les entreprises.

Au sein d’un même circuit régional, Private Link peut rediriger les requêtes vers un autre cluster si l’un d’eux est indisponible. OpenAI peut également ajouter des clusters sans que vous ayez à reconfigurer vos points de terminaison privés. Private Link ne redirige pas automatiquement le trafic destiné au nom d’hôte régional que vous avez choisi vers un point de terminaison privé d’une autre région. Ne partez pas du principe que Private Link applique les mêmes règles de routage que les points de terminaison publics d’OpenAI. Configurez le basculement de votre application entre les régions.

Choisissez vos points de terminaison régionaux

Lors de la mise en service, OpenAI vous fournit l’alias ou l’identifiant de ressource exact du service Private Link. Les noms d’hôte régionaux actuellement utilisés en production sont les suivants :

Les requêtes envoyées au nom d’hôte Centre de l’Espagne / UE peuvent être acheminées vers des clusters situés dans d’autres régions de l’UE, comme Europe Nord.

Configurez Private Link

1. Transmettez les informations nécessaires à la mise en service

Communiquez à OpenAI :

• Les identifiants des abonnements Azure qui doivent accéder aux services Private Link d’OpenAI.
• Votre identifiant d’organisation OpenAI.
• Les régions dont vous avez besoin.
• Les coordonnées des responsables d’exploitation à prévenir en cas de maintenance ou de basculement du trafic entre régions.

OpenAI autorise ces abonnements à voir les services Private Link régionaux concernés et à s’y connecter, puis vous fournit les alias ou les identifiants de ressource de ces services.

2. Créez les points de terminaison privés

Créez un point de terminaison privé pour chaque région sélectionnée. Azure exige que le point de terminaison privé se trouve dans la même région que votre réseau virtuel. Indiquez cette région dans --location, même si le service Private Link d’OpenAI se trouve dans une autre région.

La commande suivante utilise un identifiant de ressource de service Private Link fourni par OpenAI :

12345678az network private-endpoint create \
  --name openai-privatelink-southcentralus \
  --resource-group <customer-resource-group> \
  --location <customer-vnet-region> \
  --vnet-name <customer-vnet> \
  --subnet <customer-private-endpoint-subnet> \
  --private-connection-resource-id <openai-provided-pls-resource-id> \
  --connection-name openai-privatelink-southcentralus

Si OpenAI vous fournit un alias, utilisez-le et ajoutez --manual-request true :

123456789az network private-endpoint create \
  --name openai-privatelink-southcentralus \
  --resource-group <customer-resource-group> \
  --location <customer-vnet-region> \
  --vnet-name <customer-vnet> \
  --subnet <customer-private-endpoint-subnet> \
  --private-connection-resource-id <openai-provided-pls-alias> \
  --connection-name openai-privatelink-southcentralus \
  --manual-request true

Azure exige --manual-request true pour les connexions par alias. Les demandes de connexion des abonnements figurant sur la liste d’accès peuvent tout de même être approuvées automatiquement.

Suivez une procédure équivalente dans le portail Azure ou avec Terraform si votre organisation gère ses points de terminaison privés selon les principes de l’infrastructure as code.

3. Testez la connectivité avant de modifier le DNS

Une fois qu’OpenAI a approuvé le point de terminaison privé et qu’Azure l’a provisionné, relevez son adresse IP privée. Utilisez curl --resolve pour tester le nom d’hôte régional sans modifier la configuration DNS globale :

123curl -v \
  --resolve southcentralus.privatelink.api.openai.com:443:<PRIVATE_ENDPOINT_IP> \
  https://southcentralus.privatelink.api.openai.com/v2/privatelink_healthcheck

Si le service fonctionne, il renvoie le code HTTP 200 accompagné d’un message comme celui-ci :

{ "message": "Service is up" }

Utilisez le chemin exact du contrôle d’état : /v2/privatelink_healthcheck. Pour les contrôles d’état automatisés, envoyez au maximum une requête par seconde et par point de terminaison régional, sauf si OpenAI approuve une autre fréquence.

4. Configurez le DNS privé

Créez des enregistrements DNS privés pour que, depuis votre réseau, chaque nom d’hôte Private Link régional d’OpenAI se résolve en l’adresse IP du point de terminaison privé correspondant :

Vérifiez la résolution DNS et la connectivité en empruntant le même chemin réseau que votre application :

nslookup southcentralus.privatelink.api.openai.com
curl -v https://southcentralus.privatelink.api.openai.com/v2/privatelink_healthcheck

5. Configurez le basculement entre régions

Private Link fournit un point d’entrée régional. Votre trafic reste destiné au nom d’hôte régional que vous sélectionnez. Configurez votre client, votre maillage de services, votre DNS ou votre système d’équilibrage de charge pour assurer le basculement entre régions.

Pour gérer le basculement, suivez ces recommandations :

• Sondez chaque région configurée avec GET /v2/privatelink_healthcheck.
• Considérez la région comme disponible si elle renvoie le code HTTP 200.
• Considérez la région comme indisponible en cas de réponse 5xx, d’erreur de connexion, d’erreur TLS ou de dépassements répétés du délai d’attente.
• Ne basculez qu’après quelques erreurs consécutives pour éviter les allers-retours entre régions.
• Continuez à sonder la région indisponible en arrière-plan et rétablissez le trafic vers cette région conformément à vos règles d’exploitation.

Le contrôle d’état régional reflète l’état des clusters de l’API OpenAI desservis par le circuit privé régional. Une région renvoie une erreur si aucun cluster ne lui est associé à la connaissance du service, si le contrôle d’état n’est pas configuré ou si le nombre de clusters en bon état est insuffisant.

Si votre décision de routage dépend d’une API ou d’un modèle en particulier, complétez ce contrôle d’état en envoyant à faible fréquence une requête de test à cette API avec ce modèle, par le même chemin réseau.

6. Mettez à jour les URL de base de votre application

Utilisez le nom d’hôte Private Link régional dans l’URL de base de l’API OpenAI :

1
2
3
4
5from openai import OpenAI

client = OpenAI(
    base_url="https://southcentralus.privatelink.api.openai.com/v1",
)

1
2
3client = OpenAI::Client.new(
  base_url: "https://southcentralus.privatelink.api.openai.com/v1"
)

Le SDK lit OPENAI_API_KEY dans les variables d’environnement.

Vous pouvez aussi appeler directement le point de terminaison régional :

1
2
3
4
5
6
7curl https://southcentralus.privatelink.api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-astra",
    "input": "Say hello from Private Link."
  }'

Commencez dans un environnement de développement ou de préproduction, puis basculez progressivement le trafic de production.

Vérifiez votre configuration

Lors de la mise en service de Private Link ou de la migration vers ce service, vérifiez les points suivants :

• OpenAI a confirmé que les abonnements Azure dont vous avez fourni les identifiants peuvent accéder aux services Private Link régionaux sélectionnés.
• Vous avez créé un point de terminaison privé pour chaque région sélectionnée et OpenAI a approuvé chacun d’eux.
• Vous avez relevé les adresses IP des points de terminaison privés.
• La commande curl --resolve aboutit sur le chemin /v2/privatelink_healthcheck.
• Depuis le réseau de l’application, le DNS privé résout les noms d’hôte régionaux en adresses IP des points de terminaison privés.
• L’application peut appeler un point de terminaison représentatif de l’API /v1 via le nom d’hôte régional.
• Les contrôles d’état automatisés respectent une limite de débit et consignent la région, le code d’état et le type d’erreur en cas d’échec.
• Vous avez testé le basculement de l’application en simulant l’indisponibilité d’une région dans un environnement contrôlé.
• Votre documentation d’exploitation précise qui peut modifier le DNS, la configuration des points de terminaison privés et le routage régional de l’application.

Vérifiez la compatibilité des points de terminaison

Le tableau ci-dessous reflète la configuration de déploiement actuelle des services qui traitent les requêtes sur les routes publiques de l’API indiquées. Vérifiez également le fonctionnement en conditions réelles dans chaque région cible. Testez la disponibilité des modèles, les conditions d’accès aux fonctionnalités du produit, les dépendances en aval, les limites de taille des requêtes ainsi que le comportement du streaming et des connexions WebSocket. Yes indique que la route est disponible sur tous les clusters du circuit régional. No indique que le service correspondant est absent de ce circuit.

Questions fréquentes

Private Link bascule-t-il automatiquement d’une région à une autre ?

Non. Le circuit privé régional peut répartir les requêtes entre les clusters configurés pour ce circuit, mais il ne redirige pas automatiquement votre trafic vers le point de terminaison privé d’une autre région. Configurez votre application pour qu’elle puisse basculer entre les points de terminaison régionaux que vous utilisez.

Quel contrôle d’état utiliser ?

Utilisez GET /v2/privatelink_healthcheck sur le nom d’hôte régional. Les anciens chemins de contrôle d’état de la v1 interrogent le circuit de surveillance des clusters sous-jacents. Ne les utilisez pas pour vos sondes côté client.

Quel nom d’hôte les applications doivent-elles utiliser pour l’API ?

Utilisez le nom d’hôte régional avec le chemin habituel de l’API, /v1, par exemple https://southcentralus.privatelink.api.openai.com/v1.

Les charges de travail AWS ou Google Cloud peuvent-elles se connecter via Private Link ?

Pas directement. La connectivité Private Link est propre à Azure. Les charges de travail AWS ou Google Cloud doivent d’abord accéder à Azure via une connexion réseau que vous gérez, par exemple un proxy dans Azure ou une interconnexion privée entre clouds. Depuis Azure, elles peuvent ensuite joindre OpenAI via Azure Private Link.

Private Link modifie-t-il l’authentification ?

Non. Private Link modifie uniquement le chemin réseau. Les requêtes restent soumises aux exigences habituelles d’authentification et d’autorisation de l’API OpenAI.

Private Link prend-il en charge toutes les API OpenAI ?

Non. La prise en charge d’une API dépend de sa disponibilité sur chacun des clusters qui desservent le circuit régional sélectionné. Consultez d’abord le tableau de compatibilité, puis testez toutes les interfaces d’API et tous les modèles dont vous avez besoin dans chaque région cible.