API Gateway:VPC-integrated dedicated instance

Cas d'utilisation

Une instance dédiée intégrée au VPC optimise l'architecture réseau entre API Gateway et votre VPC. Ce type d'instance convient aux scénarios suivants :

• Accès à plusieurs ressources au sein d'un VPC — Les API hébergées sur la passerelle utilisent plusieurs ressources du même VPC comme services backend, telles que des instances ECS et SLB. Les scénarios typiques incluent les architectures de microservices et les solutions de découverte de services comme Nacos.

• Réseau cloud hybride — Le service backend nécessite que l'adresse IP de sortie de l'instance de passerelle soit une adresse IP privée dans le VPC lorsque API Gateway transfère les requêtes API. Pour plus d'informations, reportez-vous à Scénario 3 : API Gateway accède à un service backend dans un centre de données sur site via un réseau interne.

  

Comparaison avec les instances dédiées conventionnelles

Le tableau comparatif suivant vous aide à choisir entre une instance dédiée intégrée au VPC et une instance dédiée conventionnelle.

Comment choisir :

• VPC unique avec plusieurs ressources backend — Choisissez une instance dédiée intégrée au VPC. Elle se connecte directement à votre VPC sans autorisation par ressource.

• Plusieurs VPC avec des ressources backend — Choisissez une instance dédiée conventionnelle. Elle prend en charge plusieurs autorisations d'accès au VPC pour les ressources réparties dans différents VPC.

• Intégration avec DataWorks Data Service — Choisissez une instance dédiée conventionnelle. Les instances dédiées intégrées au VPC ne sont pas prises en charge pour ce scénario.* L'adresse IP de sortie d'une instance de passerelle est l'adresse IP source TCP que voit un service backend lorsque API Gateway transfère une requête API vers le service backend.

Pour obtenir des informations sur les autorisations d'accès au VPC utilisées avec les instances dédiées conventionnelles, consultez Utiliser une ressource dans un VPC comme service backend d'une API.

Prérequis

Avant de créer une instance dédiée intégrée au VPC, assurez-vous que les conditions suivantes sont remplies :

• VPC et vSwitch — Un VPC et au moins un vSwitch sont créés. Les ressources de votre VPC qui servent de backends d'API résident dans le bloc CIDR du vSwitch.

• Rôle lié au service — API Gateway nécessite un rôle lié au service pour gérer les interfaces réseau élastiques (ENI) dans votre VPC. Pour plus d'informations, consultez Rôle lié au service pour la connexion d'API Gateway à un VPC utilisateur.

• Planification du bloc CIDR — Le bloc CIDR du vSwitch ne chevauche pas les blocs CIDR des ressources internes utilisés par API Gateway. Pour connaître les blocs CIDR réservés par région, consultez Blocs CIDR réservés des instances dédiées intégrées au VPC par région.

• Règles de groupe de sécurité — Les règles sortantes du groupe de sécurité autorisent le trafic vers les blocs CIDR IP de destination de vos services backend.

Créer une instance

Pour créer une instance dédiée intégrée au VPC, définissez le type d'instance sur VPC integration instance sur la page d'achat.

En plus des paramètres spécifiques au VPC décrits ci-dessous, configurez les paramètres généraux sur la page d'achat : Region and zone (par exemple, China (Hangzhou)), Instance Specifications (par exemple, api.s1.small, qui affiche des paramètres tels que le nombre maximal de requêtes par seconde, le SLA, le nombre maximal de requêtes simultanées et la bande passante sortante), HTTPS Security Policy (par exemple, HTTPS2_TLS1_0), Network billing type (par exemple, paiement à l'utilisation) et Instance Name.

Gérer les blocs CIDR accessibles

Par défaut, une instance dédiée intégrée au VPC ne peut accéder qu'aux services situés dans le bloc CIDR du vSwitch que vous avez spécifié lors de la création de l'instance. Pour afficher les blocs CIDR accessibles par défaut, accédez à la page des détails de l'instance dans la console API Gateway et vérifiez la section Access to Backend Service VPC.

Si d'autres services résident dans différents blocs CIDR au sein de votre VPC et doivent être accessibles par API Gateway, ajoutez manuellement les blocs CIDR.

1. Connectez-vous à la console API Gateway. Dans le volet de navigation de gauche, choisissez Instances.

2. Recherchez l'instance dédiée intégrée au VPC et cliquez sur Add dans la colonne Access Allowed From.

3. Ajoutez un bloc CIDR en utilisant l'une des méthodes suivantes : Select from list ou Enter manually.

   Si vous saisissez manuellement un bloc CIDR, assurez-vous que le bloc CIDR réside dans le VPC que vous avez spécifié lors de la création de l'instance, ou qu'il est connecté à ce VPC.

   Après l'ajout du bloc CIDR, vérifiez qu'il apparaît dans la liste sur la page des détails de l'instance.

Utiliser une autorisation d'accès au VPC comme service backend

Une instance dédiée intégrée au VPC peut utiliser une autorisation d'accès au VPC comme service backend. L'instance utilise les ENI de votre VPC pour accéder directement aux services définis dans l'autorisation d'accès au VPC.

Avant de configurer une autorisation d'accès au VPC pour une API ou un plug-in sur une instance dédiée intégrée au VPC, assurez-vous que les conditions suivantes sont remplies :

• L'ID VPC dans l'autorisation d'accès au VPC est identique à l'ID of the VPC connected to the instance.

• L'private IP address du service dans l'autorisation d'accès au VPC réside dans le accessible CIDR block de l'instance dédiée intégrée au VPC. Si API Gateway renvoie une erreur similaire à « instance cannot connect to the backend xxx.xxx.xxx.xxx » lorsque vous publiez une API ou modifiez un plug-in, vérifiez si l'adresse IP privée indiquée dans le message d'erreur réside dans le accessible CIDR block de l'instance.

Migrer des groupes d'API vers une instance dédiée intégrée au VPC

Modify Instance for API Group Deployment Pour migrer vos charges de travail vers une instance dédiée intégrée au VPC, vous pouvez changer l'instance de déploiement d'un groupe d'API d'une instance serverless ou d'une instance dédiée conventionnelle vers une instance dédiée intégrée au VPC.

1. Connectez-vous à la console API Gateway. Dans le volet de navigation de gauche, choisissez API Groups.

2. Recherchez le groupe d'API et cliquez sur le nom du groupe pour accéder à la page des détails du groupe.

3. Cliquez sur Modify Instance for API Group Deployment et sélectionnez l'instance dédiée intégrée au VPC cible.

4. API Gateway valide les autorisations d'accès au VPC utilisées par les API et les plug-ins associés dans le groupe d'origine. Si la validation réussit, la migration est terminée. Si la validation échoue, la migration échoue et la raison est affichée.

Conditions de validation

Avant la migration, les mêmes conditions répertoriées dans Utiliser une autorisation d'accès au VPC comme service backend doivent être remplies pour tous les services basés sur le VPC, y compris les API et les plug-ins. De plus, les conditions spécifiques à la migration suivantes s'appliquent :

• Si votre groupe d'API utilise une autorisation d'accès au VPC, assurez-vous que le Security Group du service ECS ou SLB dans l'autorisation est identique au Security Group que vous avez spécifié lors de la création de l'instance dédiée intégrée au VPC.

Considérations post-migration

Après la migration, l'adresse IP de sortie interne change pour devenir l'adresse IP de sortie de l'instance cible. Si votre service backend utilise une liste d'autorisation, ajoutez la nouvelle adresse à la liste d'autorisation avant la migration pour éviter les échecs d'accès après la migration.

Une fois la migration terminée, appelez vos API pour vérifier que les services backend sont accessibles via la nouvelle instance.

Blocs CIDR réservés des instances dédiées intégrées au VPC par région

Les tableaux suivants répertorient les blocs CIDR réservés pour les ressources internes d'API Gateway dans chaque région. Assurez-vous que le vSwitch que vous spécifiez ne chevauche pas ces blocs CIDR.

Hangzhou

Shanghai

Shanghai Finance Cloud

Beijing

Beijing Finance Cloud

Shenzhen

Shenzhen Finance Cloud

Heyuan ACDR Auto

Zhangjiakou

Chengdu

Qingdao

Hong Kong

Singapore

Indonesia (Jakarta)

Malaysia (Kuala Lumpur)

Japan (Tokyo)

South Korea (Seoul)

Germany (Frankfurt)

UK (London)

US (Silicon Valley)

US (Virginia)

UAE (Dubai)

Saudi Arabia (Riyadh)