Private Link

OpenAI Private Link permet aux charges de travail Azure d’accéder 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, configurez la correspondance de son nom d’hôte régional dans le DNS privé et envoyez les requêtes API authentifiées habituelles à ce nom d’hôte.

Utilisez Private Link si votre organisation impose des exigences strictes pour maintenir le trafic sur le réseau privé Azure. Si vous n’avez pas d’exigences en matière de réseau privé, les points de terminaison publics d’OpenAI sont plus simples à configurer et à exploiter. Private Link n’est pas compatible avec les contrôles par liste d’adresses IP autorisées ni avec le TLS mutuel (mTLS) ; contactez OpenAI si vous avez besoin d’aide pour choisir les contrôles réseau adaptés à votre entreprise.

Comprenez le fonctionnement de Private Link

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

Une requête suit ce chemin :

1. Votre application résout un nom d’hôte Private Link régional via votre DNS privé.
2. Le nom d’hôte est résolu vers un point de terminaison privé Azure 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 envoie la requête à la passerelle périphérique privée régionale d’OpenAI.
5. La passerelle achemine la requête vers un cluster sous-jacent de l’API OpenAI prenant en charge les fonctionnalités d’entreprise pour ce circuit régional.

Au sein d’un circuit régional, Private Link peut contourner un cluster sous-jacent indisponible, et OpenAI peut ajouter des clusters sous-jacents sans vous obliger à reconfigurer vos points de terminaison privés. Private Link ne déplace pas automatiquement le trafic du nom d’hôte régional que vous avez sélectionné vers un point de terminaison privé d’une autre région. Ne supposez pas que Private Link reprend le comportement de routage des points de terminaison publics d’OpenAI ; configurez le basculement de votre application entre les régions.

Choisissez les points de terminaison régionaux

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

Le nom d’hôte Spain Central / UE peut acheminer les requêtes vers des clusters sous-jacents situés dans d’autres régions de l’UE, comme North Europe.

Configurez Private Link

1. Fournissez les informations nécessaires à la mise en place

Envoyez à OpenAI :

• Les identifiants des abonnements Azure qui ont besoin d’accéder aux services Private Link d’OpenAI.
• L’identifiant de votre organisation OpenAI.
• Les régions dont vous avez besoin.
• Les contacts opérationnels à informer des opérations de maintenance et des basculements du trafic entre régions.

OpenAI rend les services Private Link régionaux appropriés visibles pour les abonnements et approuve leur accès, puis fournit les alias ou les identifiants de ressources 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 qu’un point de terminaison privé se trouve dans la même région que le réseau virtuel du client. Définissez --location sur cette région, qui peut différer de celle du service Private Link d’OpenAI.

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 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 abonnements figurant sur la liste d’accès peuvent néanmoins bénéficier d’une approbation automatique.

Utilisez un workflow similaire dans le portail Azure ou avec Terraform si votre organisation gère les points de terminaison privés au moyen de l’infrastructure en tant que code.

3. Testez la connectivité avant de modifier le DNS

Une fois le point de terminaison privé approuvé par OpenAI et provisionné par Azure, 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

Une réponse indiquant un bon fonctionnement renvoie le code HTTP 200 avec un message tel que :

{ "message": "Service is up" }

Utilisez le chemin exact du contrôle d’intégrité : /v2/privatelink_healthcheck. Limitez le trafic des contrôles d’intégrité automatisés à 1 QPS au maximum par point de terminaison régional, sauf si OpenAI approuve un autre débit.

4. Configurez le DNS privé

Créez des enregistrements DNS privés afin que chaque nom d’hôte régional OpenAI Private Link soit résolu vers l’adresse IP du point de terminaison privé correspondant au sein de votre réseau :

Vérifiez le 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. Effectuez le basculement entre les régions

Private Link fournit un point d’entrée régional, mais votre trafic reste dirigé vers le nom d’hôte régional que vous sélectionnez. Configurez votre client, votre maillage de services, votre couche DNS ou votre couche d’équilibrage de charge pour assurer le basculement entre les régions.

Comportement recommandé :

• Sondez chaque région configurée avec GET /v2/privatelink_healthcheck.
• Considérez qu’une réponse HTTP 200 indique que la région est disponible.
• Considérez que les réponses 5xx, les erreurs de connexion, les erreurs TLS ou les dépassements répétés du délai d’attente indiquent que la région est indisponible.
• Ne déclenchez le basculement qu’après un petit nombre d’erreurs consécutives afin d’éviter les basculements incessants.
• Continuez à sonder en arrière-plan une région indisponible et rétablissez le routage vers celle-ci conformément à votre politique d’exploitation.

Le contrôle d’intégrité régional reflète l’état des clusters de l’API OpenAI derrière le circuit réseau de périphérie privée. Une région renvoie une erreur si aucun cluster sous-jacent n’est connu, si la configuration du contrôle d’intégrité est manquante ou si le nombre de clusters sous-jacents sains est insuffisant.

Si votre décision de routage dépend d’une API ou d’un modèle spécifique, associez ce contrôle d’intégrité à une requête synthétique envoyée à faible fréquence à cette API et à ce modèle, en empruntant le même chemin réseau.

6. Mettez à jour les URL de base des applications

Utilisez le nom d’hôte régional Private Link comme 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 votre environnement.

Vous pouvez également 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 faites basculer le trafic progressivement.

Vérifiez votre configuration

Utilisez cette liste de vérification lors de la configuration initiale ou de la migration vers Private Link :

• OpenAI a confirmé que vos identifiants d’abonnement Azure permettent d’accéder aux services Private Link régionaux sélectionnés.
• Vous avez créé des points de terminaison privés et OpenAI les a approuvés pour chaque région sélectionnée.
• Vous avez consigné les adresses IP des points de terminaison privés.
• L’appel à /v2/privatelink_healthcheck avec curl --resolve réussit.
• 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.
• La fréquence des contrôles d’intégrité automatisés est limitée. En cas d’erreur, la région, le code d’état et le type d’erreur sont consignés dans les journaux.
• Vous avez testé le basculement de l’application en forçant une région à passer à l’état défaillant 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 suivant reflète la configuration de déploiement actuelle des services derrière les routes d’API publiques répertoriées. Il ne remplace pas les vérifications en conditions réelles dans votre environnement : testez la disponibilité des modèles, les conditions d’accès aux produits, les dépendances en aval, les limites de taille des requêtes, ainsi que le comportement de la diffusion en continu et de WebSocket dans chaque région cible. Yes signifie que chaque cluster sous-jacent du circuit régional dispose de la route ; No signifie que le service sous-jacent est absent de ce circuit.

Questions fréquentes

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

Non. Le circuit régional d’accès privé peut acheminer le trafic vers les différents clusters sous-jacents configurés, mais il ne le transfère pas automatiquement vers un Private Endpoint 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’intégrité dois-je utiliser ?

Utilisez GET /v2/privatelink_healthcheck avec le nom d’hôte régional. Les anciens chemins de contrôle d’intégrité v1 vérifient le circuit de surveillance de l’état des clusters sous-jacents ; ne les utilisez donc pas comme sondes côté client.

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

Utilisez le nom d’hôte régional avec le chemin d’API habituel /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 exécutées dans AWS ou Google Cloud peuvent se connecter uniquement en passant par une infrastructure réseau vers Azure gérée par le client, par exemple un proxy Azure ou une architecture de connectivité privée entre clouds, puis d’Azure à 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 mécanismes habituels 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épend de la disponibilité de l’API sur chacun des clusters sous-jacents du circuit régional sélectionné. Utilisez la matrice de compatibilité comme point de départ, puis testez chaque interface d’API et chaque modèle dont vous avez besoin dans chacune des régions cibles.