Passerelle API régionale / optimisée Edge Nom de domaine personnalisé régional / optimisé Edge
Cela n'a aucun sens pour moi du tout. Lorsque vous créez une nouvelle passerelle API, vous pouvez spécifier si elle doit être optimisée au niveau régional ou Edge. Mais encore une fois, lorsque vous créez un nom de domaine personnalisé pour API Gateway, vous pouvez choisir entre les deux.
Le pire de tout, vous pouvez les mélanger et les assortir !!! Vous pouvez avoir un nom de domaine personnalisé régional pour une passerelle d'API optimisée pour Edge et cela n'a absolument aucun sens pour moi!
Pourquoi ces deux peuvent être régionaux/optimisés Edge séparément? Et quand est-ce que je veux que chacun d'eux soit régional/optimisé Edge?
Pourquoi ces deux peuvent être régionaux/optimisés Edge séparément?
Regional et Edge-Optimized sont des options de déploiement. Aucune de ces options ne modifie en rien le traitement de l'API par l'infrastructure AWS: la requête arrive au cœur du service API Gateway ou la manière dont les services situés derrière API Gateway sont finalement utilisés - quels sont les changements comment les demandes arrivent initialement à AWS et sont remises au noyau API Gateway pour exécution. Plus à ce sujet, ci-dessous.
Lorsque vous utilisez un nom de domaine personnalisé, l'étape d'API sélectionnée est déployée une deuxième fois, sur un deuxième noeud final. C'est pourquoi vous devez effectuer une deuxième sélection du type de déploiement.
Chaque terminal a les caractéristiques de son type de déploiement, qu'il soit régional ou optimisé pour Edge. Le type de déploiement d'origine de l'API elle-même n'a pas d'incidence sur le comportement de l'API s'il est déployé avec un nom de domaine personnalisé et qu'il est ensuite utilisé via ce nom de domaine personnalisé: ils sont indépendants.
Généralement, si vous déployez votre API avec un nom de domaine personnalisé, vous ne continuerez pas à utiliser le noeud final de déploiement créé pour l'API principale (par exemple, xxxx.execute-api.{region}.amazonaws.com), la sélection initiale ne devrait donc pas avoir d’importance.
Et quand est-ce que je veux que chacun d'entre eux soit régional/optimisé?
Si vous utilisez un nom de domaine personnalisé, alors, comme indiqué ci-dessus, votre sélection de déploiement d'origine pour l'API dans son ensemble n'a aucun impact supplémentaire lorsque vous utilisez le domaine personnalisé.
Les terminaux optimisés pour Edge étaient à l’origine la seule option disponible. Si vous ne disposez d'aucun élément sur lequel baser votre sélection, ce choix est généralement raisonnable.
Cette option achemine les demandes entrantes via le "réseau Edge" AWS, qui est le réseau CloudFront, avec plus de 100 emplacements Edge globaux. Cela ne change pas le lieu où le cœur de la passerelle API traite vos demandes - elles le sont toujours dans la même région - mais les demandes sont acheminées du monde entier vers le AWS Edge le plus proche, puis sont acheminées sur des réseaux exploités AWS pour arriver dans la région où vous avez déployé votre API.
Si les clients de votre étape API Gateway sont dispersés dans le monde entier et que vous ne déployez votre API que dans une seule région, vous souhaiterez probablement un déploiement optimisé pour Edge.
La configuration optimisée Edge a tendance à vous donner une meilleure réactivité globale, car elle tend à réduire l'impact des allers-retours sur le réseau et la qualité du transport n'est pas sujette aux aléas de l'Internet public, car la demande couvre moins distance possible avant de sauter d’Internet et sur le réseau AWS. Le protocole de négociation TCP et TLS sont négociés avec le navigateur/client qui se connecte sur une courte distance (du client à Edge) et le réseau Edge maintient des connexions persistantes qui peuvent être réutilisées, le tout ce qui fonctionne généralement en votre faveur ... mais cette optimisation devient un inconvénient relatif lorsque vos clients appellent toujours (ou généralement) l'API depuis l'infrastructure AWS, au sein de la même région, car les demandes doivent basculer vers le réseau Edge. puis de nouveau dans le réseau régional principal.
Si les clients de votre étape API Gateway se trouvent dans AWS et dans la même région que celle où vous avez déployé l'API (par exemple, lorsque l'API est appelée par d'autres systèmes EC2 de la région), vous souhaiterez probablement un point de terminaison régional. Les points de terminaison régionaux acheminent les demandes via moins d'infrastructure AWS, garantissant ainsi une latence minimale et une gigue réduite lorsque les demandes proviennent d'EC2 au sein de la même région.
En outre, les noeuds finaux optimisés pour Edge fournissent des en-têtes de requête supplémentaires pouvant vous être utiles, tels que CloudFront-Viewer-Country: XX qui tente d'identifier le code de pays à deux chiffres de l'emplacement géographique du client à l'origine de la demande d'API. Les points de terminaison régionaux n'ont pas ces en-têtes.
En règle générale, optez pour l'optimisation Edge à moins de trouver une raison de ne pas le faire.
Quelles seraient certaines raisons de ne pas? Comme indiqué ci-dessus, si vous (ou d'autres personnes) appelez l'API depuis la même région AWS, vous souhaitez probablement un point de terminaison régional. Les points de terminaison optimisés pour Edge peuvent introduire des effets secondaires dans des configurations plus avancées ou complexes, en raison de la manière dont ils s'intègrent au reste de l'infrastructure. Il y a des choses que vous ne pouvez pas faire avec un déploiement optimisé Edge, ou qui ne sont pas optimales si vous le faites:
si vous utilisez CloudFront pour d'autres sites, sans lien avec API Gateway et si CloudFront est configuré pour un nom de domaine alternatif générique, tel que
*.example.com, vous ne pouvez pas utiliser un sous-domaine de ce domaine générique, tel queapi.example.com, sur un point de terminaison optimisé pour Edge avec un nom de domaine personnalisé, car API Gateway envoie une demande au réseau Edge en votre nom pour réclamer toutes les demandes de ce sous-domaine lorsqu’elles arrivent via CloudFront, et CloudFront rejette cette demande car elle représente une configuration non prise en charge lorsqu'elle est utilisée avec API Gateway, même si CloudFront la prend en charge dans d'autres circonstances.si vous souhaitez fournir des API redondantes répondant au même nom de domaine personnalisé dans plusieurs régions et utiliser le routage basé sur le temps de route 53 pour acheminer des requêtes à la région la plus proche du demandeur, vous ne pouvez pas le faire avec une personnalisation optimisée pour Edge. domaine, car la deuxième région de passerelle d’API ne pourra pas réclamer le trafic de ce sous-domaine sur le réseau Edge, car le réseau Edge requiert exactement 1 cible pour un nom de domaine donné (sous-domaine). Cette configuration peut être réalisée à l'aide de points de terminaison régionaux et de Route 53 LBR, ou en exploitant le réseau Edge à l'aide de votre propre distribution CloudFront, Lambda @ Edge pour sélectionner le point de terminaison cible en fonction de l'emplacement de l'appelant et les déploiements régionaux API Gateway. Notez que cela ne peut être réalisé d'aucune façon si vous devez prendre en charge l'authentification IAM de l'appelant, car l'appelant doit connaître la région cible avant de signer et de soumettre la demande.
si vous souhaitez utiliser votre API dans le cadre d'un site plus vaste intégrant plusieurs ressources, déployé derrière CloudFront et utilisant le chemin d'accès pour atteindre différents services, par exemple
/images/*pourrait s’acheminer vers un compartiment S3,/api/*peut être acheminé vers votre étape API Gateway et*(tout le reste) peut être acheminé vers un équilibreur de charge élastique dans EC2. Dans ce cas, vous ne souhaitez pas utiliser une API optimisée pour Edge, car vos demandes traversent le réseau Edge deux fois (augmentation de la latence) et les valeurs d'en-tête à perdre. Cette configuration ne casse pas, mais elle n'est pas optimale. Pour cela, un point final régional est souhaitable.