Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Nom de domaine personnalisé pour le REST public APIs dans API Gateway
Les *noms de domaine personnalisés* sont plus simples et plus intuitifs URLs et vous pouvez les fournir aux utilisateurs de votre API.
Après avoir déployé votre API, vous (et vos clients) pouvez appeler cette API à l’aide de l’URL de base par défaut au format suivant :
```
https://api-id.execute-api.region.amazonaws.com/stage
```
où *api-id* est généré par API Gateway, *region* est la AWS région et *stage* est spécifiée par vous lors du déploiement de l'API.
La partie nom d’hôte de l’URL, `api-id.execute-api.region.amazonaws.com`, fait référence à un point de terminaison de l’API. Le nom par défaut du point de terminaison de l’API est généré de manière aléatoire, difficile à mémoriser et peu convivial.
Avec des noms de domaine personnalisés, vous pouvez configurer le nom d’hôte de votre API et choisir un chemin de base (par exemple, `myservice`) pour mapper l’URL alternative à votre API. Par exemple, une URL de base de l’API plus conviviale peut devenir :
```
https://api.example.com/myservice
```
**Note**
Pour plus d'informations sur les noms de domaine personnalisés pour le secteur privé APIs, consultez[Noms de domaine personnalisés pour le privé APIs dans API Gateway](apigateway-private-custom-domains.md).
## Considérations
Les considérations suivantes peuvent avoir une incidence sur votre utilisation des noms de domaine personnalisés :
+ Vous pouvez désactiver le point de terminaison par défaut de votre API. Les clients peuvent toujours se connecter à votre point de terminaison par défaut, mais ils recevront un code de statut `403 Forbidden`.
+ Un nom de domaine personnalisé régional peut être associé à REST APIs et HTTP APIs. Vous pouvez utiliser l'[API Gateway version 2 APIs](https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/api-reference.html) pour créer et gérer des noms de domaine personnalisés régionaux pour REST APIs.
+ Un nom de domaine personnalisé doit être unique au sein d'une région pour tous les AWS comptes.
+ Vous pouvez migrer votre nom de domaine personnalisé entre des points de terminaison optimisés pour la périphérie et des points de terminaison régionaux, mais vous ne pouvez pas migrer un domaine personnalisé public vers un nom de domaine personnalisé privé.
+ Vous devez créer ou mettre à jour l’enregistrement de ressource de votre fournisseur DNS pour le mapper au point de terminaison de votre API. Sans ce mappage, les demandes d’API destinées au nom de domaine personnalisé ne peuvent pas atteindre API Gateway.
+ Vous pouvez prendre en charge un nombre presque infini de noms de domaine sans dépasser le quota par défaut en utilisant un certificat générique. Pour de plus amples informations, veuillez consulter [Noms de domaine personnalisés génériques](#wildcard-custom-domain-names).
+ Vous pouvez choisir une politique de sécurité pour votre nom de domaine personnalisé. Pour de plus amples informations, veuillez consulter [Choisissez une politique de sécurité pour votre domaine personnalisé dans API Gateway](apigateway-custom-domain-tls-version.md).
+ Pour configurer des mappages d’API à plusieurs niveaux, vous devez utiliser un nom de domaine personnalisé régional et la politique de sécurité TLS 1.2.
## Prérequis concernant les noms de domaine personnalisés
Les conditions suivantes sont requises pour créer un nom de domaine personnalisé public ou privé. Pour plus d'informations sur les noms de domaine personnalisés pour le secteur privé APIs, consultez[Noms de domaine personnalisés pour le privé APIs dans API Gateway](apigateway-private-custom-domains.md).
### Enregistrement d’un nom de domaine
Vous devez avoir un nom de domaine Internet enregistré afin de configurer des noms de domaine personnalisés pour votre APIs. Vous pouvez enregistrer votre nom de domaine Internet avec [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/) ou utiliser un bureau d’enregistrement de domaine tiers de votre choix. Votre nom de domaine personnalisé peut être le nom d’un sous-domaine ou le domaine racine (également nommé « zone apex ») d’un domaine Internet enregistré.
Votre nom de domaine doit respecter la spécification [RFC 1035](https://tools.ietf.org/html/rfc1035#section-2.3.4) et peut comporter un maximum de 63 octets par étiquette et 255 octets au total.
### Spécification du certificat pour votre nom de domaine personnalisé
Avant de configurer un nom de domaine personnalisé pour une API, vous devez disposer d'un SSL/TLS certificat dans ACM. Si ACM n'est pas disponible dans la AWS région où vous créez votre nom de domaine personnalisé, vous devez importer un certificat dans API Gateway dans cette région.
Pour importer un SSL/TLS certificat, vous devez fournir le corps du SSL/TLS certificat au format PEM, sa clé privée et la chaîne de certificats pour le nom de domaine personnalisé.
Chaque certificat stocké dans ACM est identifié par son ARN. Avec les certificats émis par ACM, vous n’avez pas à vous inquiéter d’une éventuelle exposition des informations sensibles du certificat, par exemple sa clé privée. Pour utiliser un certificat AWS géré pour un nom de domaine, il suffit de référencer son ARN.
Si votre application utilise l'épinglage de certificat, parfois appelé épinglage SSL, pour épingler un certificat ACM, il est possible que l'application ne puisse pas se connecter à votre domaine après le AWS renouvellement du certificat. Pour plus d’informations, consultez la section [Problèmes d’épinglage de certificat](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-pinning.html) dans le *Guide de l’utilisateur AWS Certificate Manager *.
## Noms de domaine personnalisés génériques
Avec les noms de domaine personnalisés génériques, vous pouvez prendre en charge un nombre presque infini de noms de domaine sans dépasser le [quota par défaut](limits.md). Par exemple, vous pouvez donner à chacun de vos clients son propre nom de domaine, `customername.example.com`.
Pour créer un nom de domaine personnalisé générique, vous pouvez spécifier un caractère générique (`*`) comme premier sous-domaine d’un domaine personnalisé qui représente tous les sous-domaines possibles d’un domaine racine.
Par exemple, le nom de domaine personnalisé générique `*.example.com` donne lieu à des sous-domaines comme `a.example.com`, `b.example.com` et `c.example.com`. Lorsque vous créez le nom de domaine personnalisé générique, tous ses sous-domaines sont acheminés par le mode de routage du nom de domaine générique. Pour acheminer des sous-domaines vers différents APIs, vous pouvez effectuer l'une des opérations suivantes :
+ Utilisez les règles de routage pour acheminer les demandes entrantes `*.example.com` vers différents REST cibles à APIs l'aide de l'`Host`en-tête. Pour de plus amples informations, veuillez consulter [Exemple 4 : règles de routage pour les noms de domaine génériques](rest-api-routing-rules-examples.md#rest-api-routing-rules-examples-rule-for-wildcard-domains).
+ Créer un nom de domaine pour tous les sous-domaines que vous souhaitez acheminer vers un autre point de terminaison. Dans un seul AWS compte, vous pouvez avoir les deux `*.example.com` et`a.example.com`.
Vous pouvez utiliser les variables de contexte `$context.domainName` et `$context.domainPrefix` pour déterminer le nom de domaine utilisé par un client pour appeler votre API. Pour en savoir plus sur les variables de contexte, consultez [Variables pour les transformations de données pour API Gateway](api-gateway-mapping-template-reference.md).
Pour créer un nom de domaine personnalisé générique, vous devez fournir un certificat émis par ACM qui a été validé à l’aide du DNS ou de la méthode de validation par e-mail.
**Note**
Vous ne pouvez pas créer un nom de domaine personnalisé avec caractère générique si un autre AWS compte a créé un nom de domaine personnalisé en conflit avec le nom de domaine personnalisé avec caractère générique. Par exemple, si le compte A a créé `a.example.com`, le compte B ne peut pas créer le nom de domaine personnalisé générique `*.example.com`.
Si les comptes A et B ont le même propriétaire, vous pouvez contacter le [AWS Centre de support](https://console.aws.amazon.com/support/home#/) pour demander une exception.
## Étapes suivantes pour les noms de domaine personnalisés
Les étapes suivantes pour les noms de domaine personnalisés sont présentées ci-dessous.
**Étapes suivantes**
+ Pour savoir comment configurer votre SSL/TLS certificat, consultez[Préparez les certificats dans AWS Certificate Manager](how-to-specify-certificate-for-custom-domain-name.md).
+ Pour apprendre à créer un nom de domaine personnalisé régional, consultez [Configuration d’un nom de domaine personnalisé régional dans API Gateway](apigateway-regional-api-custom-domain-create.md).
+ Pour apprendre à créer un nom de domaine personnalisé optimisé pour la périphérie, consultez [Configuration d’un nom de domaine personnalisé optimisé pour la périphérie dans API Gateway](how-to-edge-optimized-custom-domain-name.md).
+ Pour apprendre à migrer des noms de domaine personnalisés régionaux et des noms de domaine personnalisés optimisés pour la périphérie, consultez [Migration d’un nom de domaine personnalisé vers un autre type de point de terminaison d’API dans API Gateway](apigateway-regional-api-custom-domain-migrate.md).
+ Pour apprendre à connecter des étapes d’API à un nom de domaine personnalisé, consultez [Envoyez du trafic vers vous APIs via votre nom de domaine personnalisé dans API Gateway](rest-api-routing-mode.md).
+ Pour apprendre à choisir une politique de sécurité pour votre nom de domaine personnalisé, consultez [Choisissez une politique de sécurité pour votre domaine personnalisé dans API Gateway](apigateway-custom-domain-tls-version.md).
+ Pour apprendre à désactiver le point de terminaison par défaut de votre nom de domaine personnalisé, consultez [Désactiver le point de terminaison par défaut pour REST APIs](rest-api-disable-default-endpoint.md).
+ Pour apprendre à utiliser les surveillances de l’état de Route 53 pour contrôler le basculement DNS d’une API API Gateway, consultez [Configuration de surveillances de l’état personnalisées pour le basculement DNS d’une API API Gateway](dns-failover.md).
Si c’est la première fois que vous créez un nom de domaine personnalisé, nous vous recommandons de commencer par la section [Préparez les certificats dans AWS Certificate Manager](how-to-specify-certificate-for-custom-domain-name.md) pour spécifier votre certificat, puis la section [Configuration d’un nom de domaine personnalisé régional dans API Gateway](apigateway-regional-api-custom-domain-create.md) pour créer un nom de domaine personnalisé régional.
# Préparez les certificats dans AWS Certificate Manager
Avant de configurer un nom de domaine personnalisé pour une API, vous devez préparer un certificat SSL/TLS dans AWS Certificate Manager. Pour plus d’informations, consultez le [Guide de l’utilisateur AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/).
## Considérations
Voici quelques points à prendre en compte pour votre SSL/TLS certificat.
+ Si vous créez un nom de domaine personnalisé optimisé pour les périphériques, API Gateway s'en sert pour prendre en charge les CloudFront certificats pour les noms de domaine personnalisés. Ainsi, les exigences et les contraintes d'un SSL/TLS certificat de nom de domaine personnalisé sont dictées par [CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html). Par exemple, la taille maximale de la clé publique est 2 048 bits et la taille de la clé privée peut être 1 024, 2 048 ou 4 096 bits. La taille de la clé publique est déterminée par l’autorité de certification (CA) que vous utilisez. Demandez à votre autorité de certification de renvoyer des clés d’une taille différente de la longueur par défaut. Pour plus d'informations, voir [Accès sécurisé à vos objets](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html) et [Création de cookies signés URLs et signés](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-trusted-signers.html).
+ Si vous créez un nom de domaine personnalisé régional, la taille maximale de la clé publique est de 2048.
+ Pour utiliser un certificat ACM avec un nom de domaine personnalisé régional, vous devez demander ou importer le certificat dans la même région que votre API. Le certificat doit couvrir le nom de domaine personnalisé.
+ Pour utiliser un certificat ACM avec un nom de domaine personnalisé optimisé pour la périphérie, vous devez demander ou importer le certificat dans la région `us-east-1` – USA Est (Virginie du Nord).
+ Vous devez disposer d’un nom de domaine enregistré, par exemple `example.com`. Vous pouvez utiliser [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/) ou un bureau d’enregistrement accrédité tiers. Pour une liste de ces bureaux, consultez la page [Accredited Registrar Directory](https://www.icann.org/en/accredited-registrars) sur le site Web de l’ICANN.
## Pour créer ou importer un SSL/TLS certificat dans ACM
Les procédures suivantes indiquent comment créer ou importer un SSL/TLS certificat pour un nom de domaine.
------
#### [ To request a certificate provided by ACM for a domain name ]
1. Connectez-vous à la console [AWS Certificate Manager](https://console.aws.amazon.com/acm).
1. Choisissez **Request a certificate**.
1. Pour **Type de certificat**, choisissez **Demander un certificat public**.
1. Choisissez **Suivant**.
1. Pour **Nom de domaine complet**, saisissez un nom de domaine personnalisé pour votre API, par exemple, `api.example.com`.
1. Vous pouvez également choisir **Ajouter un autre nom à ce certificat**.
1. Pour **Méthode de validation**, choisissez une méthode pour valider la propriété du domaine.
1. Pour **Algorithme de la clé**, choisissez un algorithme de chiffrement.
1. Cliquez sur **Demander**.
1. Pour que la demande soit valide et qu’ACM puisse émettre le certificat, le propriétaire inscrit du domaine Internet doit préalablement approuver cette demande. Si vous utilisez Route 53 pour gérer vos enregistrements DNS publics, vous pouvez mettre à jour vos enregistrements directement via la console ACM.
------
#### [ To import into ACM a certificate for a domain name ]
1. Obtenez un SSL/TLS certificat codé PEM pour votre nom de domaine personnalisé auprès d'une autorité de certification. Pour une liste partielle de ces entités CAs, consultez la [liste des CA incluses par Mozilla](https://ccadb.my.salesforce-sites.com/mozilla/IncludedCACertificateReport).
1. Générez une clé privée pour le certificat et enregistrez la sortie dans un fichier en utilisant la boîte à outils [OpenSSL](https://www.openssl.org) sur le site Web OpenSSL :
```
openssl genrsa -out private-key-file 2048
```
1. Générez une demande de signature de certificat (CSR) avec la clé privée générée précédemment, à l’aide d’OpenSSL :
```
openssl req -new -sha256 -key private-key-file -out CSR-file
```
1. Envoyez cette CSR à l’autorité de certification et enregistrez le certificat obtenu.
1. Téléchargez la chaîne de certificats de l’autorité de certification.
**Note**
Si vous obtenez la clé privée d’une autre manière et que cette clé est chiffrée, vous pouvez utiliser la commande suivante pour déchiffrer la clé avant de l’envoyer à API Gateway pour configurer un nom de domaine personnalisé.
```
openssl pkcs8 -topk8 -inform pem -in MyEncryptedKey.pem -outform pem -nocrypt -out MyDecryptedKey.pem
```
1. Téléchargez le certificat sur AWS Certificate Manager :
1. Connectez-vous à la console [AWS Certificate Manager](https://console.aws.amazon.com/acm).
1. Choisissez **Import a certificate**.
1. Dans le champ **Corps du certificat**, saisissez le corps du certificat de serveur au format PEM de votre autorité de certification. Voici un exemple de certificat abrégé :
```
-----BEGIN CERTIFICATE-----
EXAMPLECA+KgAwIBAgIQJ1XxJ8Pl++gOfQtj0IBoqDANBgkqhkiG9w0BAQUFADBB
...
az8Cg1aicxLBQ7EaWIhhgEXAMPLE
-----END CERTIFICATE-----
```
1. Pour **Clé privée du certificat**, saisissez la clé privée de votre certificat au format PEM. Voici un exemple de clé abrégé :
```
-----BEGIN RSA PRIVATE KEY-----
EXAMPLEBAAKCAQEA2Qb3LDHD7StY7Wj6U2/opV6Xu37qUCCkeDWhwpZMYJ9/nETO
...
1qGvJ3u04vdnzaYN5WoyN5LFckrlA71+CszD1CGSqbVDWEXAMPLE
-----END RSA PRIVATE KEY-----
```
1. Pour **Chaîne de certificats**, saisissez les certificats intermédiaires au format PEM et, éventuellement, le certificat racine, l’un après l’autre sans ligne vide. Si vous incluez le certificat racine, votre chaîne de certificats doit commencer par les certificats intermédiaires et se terminer par le certificat racine. Utilisez les certificats intermédiaires fournis par l’autorité de certification. N’incluez aucun certificat intermédiaire non approuvé. Voici un exemple abrégé :
```
-----BEGIN CERTIFICATE-----
EXAMPLECA4ugAwIBAgIQWrYdrB5NogYUx1U9Pamy3DANBgkqhkiG9w0BAQUFADCB
...
8/ifBlIK3se2e4/hEfcEejX/arxbx1BJCHBvlEPNnsdw8EXAMPLE
-----END CERTIFICATE-----
```
Voici un autre exemple :
```
-----BEGIN CERTIFICATE-----
Intermediate certificate 2
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Intermediate certificate 1
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Optional: Root certificate
-----END CERTIFICATE-----
```
1. Choisissez **Suivant**, puis **Suivant**.
------
Une fois que le certificat a été créé ou importé, notez son ARN. Vous en aurez besoin pour configurer le nom de domaine personnalisé.
# Configuration d’un nom de domaine personnalisé régional dans API Gateway
Utilisez un nom de domaine personnalisé régional pour créer une URL de base d’API conviviale. Avec un nom de domaine personnalisé régional, vous pouvez mapper les étapes d’API HTTP et REST au même nom de domaine personnalisé et utiliser l’authentification TLS mutuelle.
## Considérations
Voici quelques points à prendre en compte pour votre nom de domaine personnalisé régional :
+ Vous devez fournir un certificat ACM spécifique à la région. Ce certificat doit se trouver dans la même région que votre API. Pour plus d’informations sur la création ou le chargement d’un certificat de nom de domaine personnalisé, consultez [Préparez les certificats dans AWS Certificate Manager](how-to-specify-certificate-for-custom-domain-name.md).
+ Lorsque vous créez un nom de domaine personnalisé régional (ou que vous en migrez un) avec un certificat ACM, API Gateway crée un rôle lié à un service dans votre compte. Le rôle lié à un service est requis pour attacher votre certificat ACM à votre point de terminaison régional. Le rôle est nommé **AWSServiceRoleForAPIGateway** et la politique gérée **APIGatewayServiceRolePolicy** lui est attachée. Pour plus d’informations sur l’utilisation du rôle lié à un service, consultez [Utilisation des rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html).
+ Après avoir créé votre nom de domaine personnalisé régional, vous devez créer un enregistrement DNS pour pointer le nom de domaine personnalisé vers le domaine régional. Cela permet au trafic lié au nom de domaine personnalisé d’être acheminé vers le nom d’hôte régional de l’API.
L’enregistrement DNS peut être un enregistrement CNAME ou A Alias. Si vous utilisez Route 53 comme fournisseur DNS, créez un enregistrement A Alias. Si vous utilisez un fournisseur DNS tiers, utilisez un enregistrement CNAME. Si vous utilisez un enregistrement CNAME et créez un point de terminaison de VPC d’interface API Gateway avec le DNS privé activé pour une API privée, vous ne pouvez pas résoudre le nom de domaine personnalisé dans le VPC qui héberge votre API privée.
## Création d’un nom de domaine personnalisé régional
La procédure suivante montre comment créer un nom de domaine personnalisé régional. Après avoir effectué cette procédure, vous allez créer une règle de routage pour acheminer les étapes de votre API vers votre nom de domaine personnalisé.
------
#### [ AWS Management Console ]
1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway)
1. Sélectionnez **Noms de domaine personnalisés** dans le volet de navigation principal.
1. Choisissez **Créer**.
1. Pour **Nom de domaine**, entrez un nom de domaine.
1. Pour **Mode de routage**, choisissez **Règles de routage uniquement**.
Dans ce mode de routage, vous pouvez uniquement envoyer du trafic depuis votre nom de domaine personnalisé vers votre APIs en utilisant des règles de routage. Pour de plus amples informations, veuillez consulter [Envoyez du trafic vers vous APIs via votre nom de domaine personnalisé dans API Gateway](rest-api-routing-mode.md).
1. Pour **Version TLS minimale**, sélectionnez une version.
1. Sous **Configuration du point de terminaison**, pour **Type de point de terminaison d’API**, choisissez **Régional**.
1. Choisissez un certificat ACM. Le certificat doit se trouver dans la même région que l’API.
1. Choisissez **Créer**.
------
#### [ AWS CLI ]
La [create-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-domain-name.html)commande suivante crée un nom de domaine personnalisé :
```
aws apigatewayv2 create-domain-name \
--domain-name 'regional.example.com' \
--domain-name-configurations CertificateArn=arn:aws:acm:us-west-2:123456789012:certificate/123456789012-1234-1234-1234-12345678 \
--routing-mode ROUTING_RULE_ONLY
```
Le résultat se présente comme suit :
```
{
"ApiMappingSelectionExpression": "$request.basepath",
"DomainName": "regional.example.com",
"DomainNameConfigurations": [
{
"ApiGatewayDomainName": "d-numh1z56v6.execute-api.us-west-2.amazonaws.com",
"CertificateArn": "arn:aws:acm:us-west-2:123456789012:certificate/123456789012-1234-1234-1234-12345678",
"DomainNameStatus": "AVAILABLE",
"EndpointType": "REGIONAL",
"HostedZoneId": "Z2OJLYMUO9EFXC",
"SecurityPolicy": "TLS_1_2"
}
"RoutingMode": "ROUTING_RULE_ONLY"
]
}
```
La valeur de la propriété `DomainNameConfigurations` renvoie le nom d’hôte de l’API régionale. Vous devez créer un enregistrement DNS pour pointer votre nom de domaine personnalisé vers ce nom de domaine régional. Cela permet au trafic lié au nom de domaine personnalisé d’être acheminé vers le nom d’hôte de cette API régionale.
------
## Création d’une règle de routage pour votre nom de domaine personnalisé régional
Après avoir créé votre nom de domaine personnalisé, vous configurez la manière dont le trafic est acheminé de votre nom de domaine personnalisé vers votre APIs. Comme vous avez défini le mode de routage sur`ROUTING_RULE_ONLY`, vous utilisez des règles de routage pour acheminer les demandes entrantes vers votre nom de domaine personnalisé vers votre APIs.
Dans cet exemple, vous allez créer une règle fourre-tout qui achemine toutes les demandes entrantes de votre nom de domaine personnalisé vers une étape de votre API. Vous pouvez également configurer des règles de routage en fonction de différentes conditions d’en-tête et de chemin. Pour de plus amples informations, veuillez consulter [Règles de routage pour connecter les étapes de l'API à un nom de domaine personnalisé pour REST APIs](rest-api-routing-rules.md).
------
#### [ AWS Management Console ]
1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway)
1. Choisissez un nom de domaine personnalisé.
1. Dans l’onglet **Détails du routage**, choisissez **Ajouter une règle de routage**.
1. Choisissez **Ajouter une nouvelle condition** pour ajouter une nouvelle condition.
1. Conservez cette règle sans condition. Cette opération achemine toutes les demandes de votre nom de domaine personnalisé vers votre API et votre étape cibles.
1. Sous **Action**, utilisez le menu déroulant pour sélectionner votre API et votre étape cibles.
1. Choisissez **Suivant**.
1. Dans le champ Priorité, saisissez **100**.
API Gateway évalue les règles par ordre de priorité, de la valeur la plus basse à la valeur la plus élevée. Comme il s’agit d’une règle fourre-tout, utilisez une priorité élevée afin qu’API Gateway puisse faire correspondre toutes les règles supplémentaires créées en premier.
1. Choisissez **Créer une règle de routage**.
------
#### [ AWS CLI ]
La commande `create-routing-rule` suivante crée une règle de routage fourre-tout :
```
aws apigatewayv2 create-routing-rule \
--domain-name 'regional.example.com' \
--priority 100 \
--conditions \
--actions '[{
"InvokeApi": {
"ApiId": "a1b2c3",
"Stage": "prod"
}
}]'
```
------
Vous pouvez modifier le mode de routage et créer de nouvelles règles à tout moment. Pour de plus amples informations, veuillez consulter [Envoyez du trafic vers vous APIs via votre nom de domaine personnalisé dans API Gateway](rest-api-routing-mode.md).
## Création d’un enregistrement DNS pour votre nom de domaine personnalisé régional
Après avoir créé votre nom de domaine personnalisé et créé les mappages de chemins de base, vous allez créer un enregistrement DNS pour pointer votre nom de domaine personnalisé vers le nom de domaine régional que vous venez de créer.
------
#### [ AWS Management Console ]
Pour utiliser le AWS Management Console, suivez la documentation de Route 53 sur la [configuration de Route 53 pour acheminer le trafic vers API Gateway](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-api-gateway.html).
------
#### [ AWS CLI ]
Pour configurer vos enregistrements DNS de manière à mapper le nom de domaine personnalisé régional au nom d’hôte de l’ID de la zone hébergée, commencez par créer un fichier JSON qui contient la configuration pour créer un enregistrement DNS pour le nom de domaine régional.
L’exemple `setup-dns-record.json` suivant montre comment créer un enregistrement DNS `A` afin de mapper un nom de domaine personnalisé régional (`regional.example.com`) à son nom d’hôte régional (`d-numh1z56v6.execute-api.us-west-2.amazonaws.com`) configuré dans le cadre de la création du nom de domaine personnalisé. Les propriétés `DNSName` et `HostedZoneId` d’`AliasTarget` peuvent prendre respectivement les valeurs `regionalDomainName` et `regionalHostedZoneId` du nom de domaine personnalisé. Vous pouvez également obtenir la zone hébergée régionale Route 53 IDs dans [Amazon API Gateway Endpoints and Quotas](https://docs.aws.amazon.com/general/latest/gr/apigateway.html).
```
{
"Changes": [
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "regional.example.com",
"Type": "A",
"AliasTarget": {
"DNSName": "d-numh1z56v6.execute-api.us-west-2.amazonaws.com",
"HostedZoneId": "Z2OJLYMUO9EFXC",
"EvaluateTargetHealth": false
}
}
}
]
}
```
Ce qui suit [change-resource-record-sets](https://docs.aws.amazon.com/cli/latest/reference/route53/change-resource-record-sets.html)crée un enregistrement DNS pour votre nom de domaine personnalisé régional :
```
aws route53 change-resource-record-sets \
--hosted-zone-id Z2OJLYMUO9EFXC \
--change-batch file://path/to/your/setup-dns-record.json
```
Remplacez `hosted-zone-id` par l’ID de la zone hébergée Route 53 du jeu d’enregistrements DNS de votre compte. La valeur du paramètre `change-batch` pointe vers un fichier JSON (*setup-dns-record.json*) dans un dossier (*path/to/your*).
------
# Configuration d’un nom de domaine personnalisé optimisé pour la périphérie dans API Gateway
Lorsque vous créez un nom de domaine personnalisé pour une API optimisée pour les périphériques, API Gateway configure une CloudFront distribution et un enregistrement DNS pour mapper le nom de domaine de l'API au nom de domaine de CloudFront distribution. Les demandes relatives à l'API sont ensuite acheminées vers API Gateway via la distribution mappée CloudFront . Ce mappage concerne les demandes d'API liées au nom de domaine personnalisé à acheminer vers API Gateway via la distribution mappée CloudFront .
## Considérations
Voici quelques points à prendre en compte pour votre nom de domaine personnalisé optimisé pour la périphérie :
+ Pour configurer un nom de domaine personnalisé optimisé pour les périphériques ou pour mettre à jour son certificat, vous devez être autorisé à mettre à jour CloudFront les distributions.
Les autorisations suivantes sont requises pour mettre à jour CloudFront les distributions :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCloudFrontUpdateDistribution",
"Effect": "Allow",
"Action": [
"cloudfront:updateDistribution"
],
"Resource": [
"*"
]
}
]
}
```
------
+ Vous devez demander ou importer un certificat pour votre nom de domaine personnalisé optimisé pour la périphérie dans la région `us-east-1` USA Est (Virginie du Nord).
+ La CloudFront distribution créée par API Gateway appartient à un compte spécifique à la région affilié à API Gateway. Lors du suivi des opérations visant à créer et à mettre à jour une telle CloudFront distribution CloudTrail, vous devez utiliser cet ID de compte API Gateway. Pour de plus amples informations, veuillez consulter [Enregistrez la création d'un nom de domaine personnalisé dans CloudTrail](#how-to-custom-domain-log-cloudfront-distribution-update-in-cloudtrail).
+ API Gateway prend en charge les noms de domaine personnalisés optimisés pour les périphériques en tirant parti de l'indication du nom du serveur (SNI) sur la distribution. CloudFront Pour plus d'informations sur l'utilisation de noms de domaine personnalisés sur une CloudFront distribution, notamment sur le format de certificat requis et la taille maximale de la longueur d'une clé de certificat, consultez la section [Utilisation de noms de domaine alternatifs et HTTPS](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-alternate-domain-names.html) dans le manuel *Amazon CloudFront Developer Guide*
+ Il faut compter environ 40 minutes pour qu’un nom de domaine personnalisé optimisé pour la périphérie soit prêt.
+ Après avoir créé votre nom de domaine personnalisé optimisé pour les périphériques, vous devez créer un enregistrement DNS pour mapper le nom de domaine personnalisé au nom de CloudFront distribution.
## Création d’un nom de domaine personnalisé optimisé pour la périphérie
La procédure suivante décrit comment créer un nom de domaine personnalisé optimisé pour la périphérie pour une API.
------
#### [ AWS Management Console ]
1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway)
1. Sélectionnez **Noms de domaine personnalisés** dans le volet de navigation principal.
1. Choisissez **Ajouter un nom de domaine**.
1. Pour **Nom de domaine**, entrez un nom de domaine.
1. Pour le **mode de routage**, choisissez **API\$1MAPPING\$1ONLY**.
1. Pour **Type de point de terminaison d’API**, choisissez **Optimisé pour la périphérie**.
1. Choisissez une version TLS minimale.
1. Choisissez un certificat ACM.
1. Choisissez **Ajouter un nom de domaine**.
------
#### [ REST API ]
1. Appelez [domainname:create](https://docs.aws.amazon.com/apigateway/latest/api/API_CreateDomainName.html), en spécifiant le nom de domaine personnalisé et l’ARN d’un certificat stocké dans AWS Certificate Manager.
L'appel d'API réussi renvoie une `201 Created` réponse contenant l'ARN du certificat ainsi que le nom de CloudFront distribution associé dans sa charge utile.
1. Notez le nom CloudFront de domaine de distribution affiché dans le résultat. Vous en aurez besoin à l’étape suivante pour définir la cible de l’alias d’enregistrement A du domaine personnalisé dans votre DNS.
Pour des exemples de code de cet appel d’API REST, consultez [domainname:create](https://docs.aws.amazon.com/apigateway/latest/api/API_CreateDomainName.html).
------
Il faut environ 40 minutes pour qu'un nom de domaine personnalisé optimisé pour les périphériques soit prêt, mais la console affiche immédiatement le nom de domaine de CloudFront distribution associé, sous la forme de`distribution-id.cloudfront.net`, ainsi que l'ARN du certificat. En attendant, vous pouvez créer un mappage de chemin de base ou une règle de routage, puis configurer l'alias d'enregistrement DNS pour mapper le nom de domaine personnalisé au nom de domaine de CloudFront distribution associé.
## Configuration du mappage de chemin de base d’une API à l’aide d’un nom de domaine personnalisé servant de nom d’hôte
Comme vous avez défini le mode de routage sur`API_MAPPING_ONLY`, vous pouvez utiliser le mappage de chemins de base pour utiliser un seul nom de domaine personnalisé comme nom d'hôte de plusieurs APIs. Le mappage de chemin de base rend une API accessible par la combinaison du nom de domaine personnalisé et du chemin de base associé.
Par exemple, si vous avez créé dans API Gateway une API nommée `PetStore` et une autre nommée `Dogs` et que vous avez configuré un nom de domaine personnalisé `api.example.com`, vous pouvez définir l’URL de l’API `PetStore` comme `https://api.example.com`.
Cette opération associe l’API `PetStore` au chemin de base d’une chaîne vide. Si vous définissez l’URL de l’API `PetStore` comme `https://api.example.com/PetStore`, l’API `PetStore` est associée au chemin de base `PetStore`. Vous pouvez affecter un chemin de base `MyDogList` pour l’API `Dogs`. L’URL de `https://api.example.com/MyDogList` est alors l’URL racine de l’API `Dogs`.
Pour configurer des mappages d’API à plusieurs niveaux, vous ne pouvez utiliser qu’un nom de domaine personnalisé régional. Les noms de domaine personnalisés optimisés pour la périphérie ne sont pas pris en charge. Pour de plus amples informations, veuillez consulter [Utilisez les mappages d'API pour connecter les étapes d'API à un nom de domaine personnalisé pour REST APIs](rest-api-mappings.md).
La procédure suivante configure les mappages d’API pour mapper les chemins de votre nom de domaine personnalisé à vos étapes d’API.
------
#### [ AWS Management Console ]
1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway)
1. Sélectionnez **Custom Domain Names** dans le panneau de navigation principal de la console API Gateway.
1. Choisissez un nom de domaine personnalisé.
1. Choisissez **Configurer les mappages d’API**.
1. Choisissez **Ajouter un nouveau mappage**.
1. Spécifiez l’**API**, l’**étape**, et **le chemin** (facultatif) pour le mappage.
1. Choisissez **Enregistrer**.
------
#### [ REST API ]
Appelez [basepathmapping:create](https://docs.aws.amazon.com/apigateway/latest/api/API_CreateBasePathMapping.html) sur un nom de domaine personnalisé donné, en spécifiant le `basePath`, `restApiId` et une propriété `stage` de déploiement dans la charge utile de la demande.
Si l’appel d’API aboutit, il renvoie le code de réponse `201 Created`.
Pour des exemples de code de l’appel d’API REST, consultez [basepathmapping:create](https://docs.aws.amazon.com/apigateway/latest/api/API_CreateBasePathMapping.html).
------
Pour plus de flexibilité quant à la manière dont vous acheminez le trafic vers votre APIs, vous pouvez modifier le mode de routage en `ROUTING_RULE_ONLY` ou `ROUTING_RULE_THEN_API_MAPPING` créer une règle de routage. Pour de plus amples informations, veuillez consulter [Envoyez du trafic vers vous APIs via votre nom de domaine personnalisé dans API Gateway](rest-api-routing-mode.md).
## Création d’un enregistrement DNS pour votre nom de domaine personnalisé optimisé pour la périphérie
Après avoir créé votre nom de domaine personnalisé optimisé pour la périphérie, configurez l’alias de l’enregistrement DNS.
Nous vous recommandons d'utiliser Route 53 pour créer un alias d'enregistrement A pour votre nom de domaine personnalisé et de spécifier le nom de domaine de CloudFront distribution comme cible de l'alias. Cela signifie que Route 53 peut acheminer votre nom de domaine personnalisé, même s’il s’agit d’une zone apex. Pour plus d’informations, consultez [Choix entre des jeux d’enregistrements de ressources avec ou sans alias](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html) dans le *guide du développeur Amazon Route 53*.
Pour obtenir des instructions sur Amazon Route 53, consultez [Acheminement du trafic vers Amazon API Gateway à l’aide de votre nom de domaine](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-api-gateway.html) dans le *Manuel du développeur Amazon Route 53*.
## Enregistrez la création d'un nom de domaine personnalisé dans CloudTrail
Lorsque cette option CloudTrail est activée pour enregistrer les appels API Gateway effectués par votre compte, API Gateway enregistre les mises à jour de CloudFront distribution associées lorsqu'un nom de domaine personnalisé est créé ou mis à jour pour une API. Ces journaux sont disponibles dans `us-east-1`. Ces CloudFront distributions étant détenues par API Gateway, chacune des CloudFront distributions signalées est identifiée par l'un des comptes API Gateway spécifiques à la région suivants IDs, au lieu de l'ID de compte du propriétaire de l'API.
| **Région** | **ID de compte** |
| --- | --- |
| us-east-1 | 392220576650 |
| us-east-2 | 718770453195 |
| us-west-1 | 968246515281 |
| us-west-2 | 109351309407 |
| ca-central-1 | 796887884028 |
| eu-west-1 | 631144002099 |
| eu-west-2 | 544388816663 |
| eu-west-3 | 061510835048 |
| eu-central-1 | 474240146802 |
| eu-central-2 | 166639821150 |
| eu-north-1 | 394634713161 |
| eu-south-1 | 753362059629 |
| eu-south-2 | 359345898052 |
| ap-northeast-1 | 969236854626 |
| ap-northeast-2 | 020402002396 |
| ap-northeast-3 | 360671645888 |
| ap-southeast-1 | 195145609632 |
| ap-southeast-2 | 798376113853 |
| ap-southeast-3 | 652364314486 |
| ap-southeast-4 | 849137399833 |
| ap-south-1 | 507069717855 |
| ap-south-2 | 644042651268 |
| ap us-east-1 | 174803364771 |
| sa-east-1 | 287228555773 |
| me-south-1 | 855739686837 |
| me-central-1 | 614065512851 |
## Rotation d’un certificat importé dans ACM
ACM gère automatiquement le renouvellement des certificats qu’il émet. Il n'est pas nécessaire de faire alterner les certificats émis par ACM pour vos noms de domaine personnalisés. CloudFront s'en charge en votre nom.
Toutefois, si vous importez un certificat dans ACM et que vous l’utilisez pour un nom de domaine personnalisé, vous devez effectuer la rotation de ce certificat avant qu’il n’arrive à expiration. Cela implique d’importer un nouveau certificat tiers pour le nom de domaine et d’effectuer la rotation du certificat existant vers le nouveau. Vous devez répéter ce processus lorsque le certificat nouvellement importé arrive à expiration. Sinon, vous pouvez demander à ACM d’émettre un nouveau certificat pour le nom de domaine et d’effectuer la rotation du certificat existant vers le nouveau certificat émis par ACM. Ensuite, vous pouvez quitter ACM et CloudFront gérer automatiquement la rotation des certificats. Pour créer ou importer un nouveau certificat ACM, suivez les étapes décrites dans [Pour créer ou importer un SSL/TLS certificat dans ACM](how-to-specify-certificate-for-custom-domain-name.md#how-to-specify-certificate-for-custom-domain-name-setup).
La procédure suivante explique comment effectuer la rotation d’un certificat pour un nom de domaine.
**Note**
Il faut compter environ 40 minutes pour effectuer la rotation d’un certificat importé dans ACM.
------
#### [ AWS Management Console ]
1. Demandez ou importez un certificat dans ACM.
1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway)
1. Sélectionnez **Custom Domain Names** dans le panneau de navigation principal de la console API Gateway.
1. Choisissez un nom de domaine personnalisé optimisé pour la périphérie.
1. Pour **Configuration du point de terminaison**, choisissez **Modifier**.
1. Pour **Certificat ACM**, choisissez un certificat dans la liste déroulante.
1. Sélectionnez **Enregistrer les modifications** pour commencer la rotation du certificat pour le nom de domaine personnalisé.
------
#### [ REST API ]
Appelez l’action [domainname:update](https://docs.aws.amazon.com/apigateway/latest/api/API_UpdateDomainName.html), en spécifiant l’ARN du nouveau certificat ACM pour le nom de domaine personnalisé spécifié.
------
#### [ AWS CLI ]
Ce qui suit [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-domain-name.html)met à jour le certificat ACM pour un nom de domaine optimisé pour les périphériques.
```
aws apigateway update-domain-name \
--domain-name edge.example.com \
--patch-operations "op='replace',path='/certificateArn',value='arn:aws:acm:us-east-2:111122223333:certificate/CERTEXAMPLE123EXAMPLE'"
```
Ce qui suit [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-domain-name.html)met à jour le certificat ACM pour un nom de domaine régional.
```
aws apigateway update-domain-name \
--domain-name regional.example.com \
--patch-operations "op='replace',path='/regionalCertificateArn',value='arn:aws:acm:us-east-2:111122223333:certificate/CERTEXAMPLE123EXAMPLE'"
```
------
## Appel de votre API avec des noms de domaine personnalisés lorsque vous utilisez un mappage de chemin de base
L’appel d’une API avec un nom de domaine personnalisé est identique à l’appel de l’API avec son nom de domaine par défaut, sous réserve que l’URL correcte soit utilisée.
Les exemples suivants comparent et contrastent un ensemble de valeurs par défaut URLs et URLs de personnalisation correspondantes de deux APIs (`udxjef`et`qf3duz`) dans une région spécifiée (`us-east-1`), et d'un nom de domaine personnalisé donné (`api.example.com`).
| ID d’API | Étape | URL par défaut | Chemin de base | URL personnalisé |
| --- | --- | --- | --- | --- |
| udxjef | prod | https://udxjef.execute-api.us-east-1.amazonaws.com/produit | /petstore | https://api.example.com/animalerie |
| udxjef | tst | https://udxjef.execute-api.us-east-1.amazonaws.com/tst | /petdepot | https://api.example.com/dépôt pour animaux |
| qf3duz | dev | https://qf3duz.execute-api.us-east-1.amazonaws.com/dev | /bookstore | https://api.example.com/librairie |
| qf3duz | tst | https://qf3duz.execute-api.us-east-1.amazonaws.com/tst | /bookstand | https://api.example.com/kiosque |
Pour plus de flexibilité quant à la manière dont vous acheminez le trafic vers votre APIs, vous pouvez créer une règle de routage. Pour de plus amples informations, veuillez consulter [Envoyez du trafic vers vous APIs via votre nom de domaine personnalisé dans API Gateway](rest-api-routing-mode.md).
API Gateway prend en charge les noms de domaine personnalisés pour une API à l’aide de [Server Name Indication (SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication). Vous pouvez appeler l’API avec un nom de domaine personnalisé en utilisant un navigateur ou une bibliothèque client prenant en charge SNI.
API Gateway applique le SNI à la CloudFront distribution. Pour plus d'informations sur l' CloudFront utilisation des noms de domaine personnalisés, consultez [Amazon CloudFront Custom SSL](https://aws.amazon.com/cloudfront/custom-ssl-domains/).
# Migration d’un nom de domaine personnalisé vers un autre type de point de terminaison d’API dans API Gateway
Vous pouvez migrer votre nom de domaine personnalisé entre des points de terminaison optimisés pour la périphérie et régionaux. Vous ne pouvez pas migrer un nom de domaine personnalisé public vers un nom de domaine personnalisé privé. Vous ajoutez d’abord le nouveau type de configuration de point de terminaison à la liste `endpointConfiguration.types` existante pour le nom de domaine personnalisé. Ensuite, vous configurez un enregistrement DNS pour pointer le nom de domaine personnalisé vers le point de terminaison récemment configuré. Enfin, vous supprimez le point de terminaison obsolète du nom de domaine personnalisé.
## Considérations
Voici les points à prendre en compte pour la migration de votre domaine personnalisé entre un point de terminaison d’API régional et un point de terminaison d’API optimisé pour la périphérie :
+ Un nom de domaine personnalisé optimisé pour la périphérie nécessite un certificat fourni par ACM de la région `us-east-1` - USA Est (Virginie du Nord). Ce certificat est distribué à tous les emplacements géographiques.
+ Un nom de domaine personnalisé régional nécessite un certificat fourni par ACM de la même région qui héberge l’API. Vous pouvez migrer un nom de domaine personnalisé optimisé pour la périphérie qui ne se trouve pas dans la région `us-east-1` vers un nom de domaine personnalisé régional en demandant un nouveau certificat ACM de la région locale de l’API.
+ La migration entre un nom de domaine personnalisé optimisé pour la périphérie et un nom de domaine personnalisé régional peut prendre jusqu’à 60 secondes. Le délai de migration dépend également du moment où vous mettez à jour vos enregistrements DNS.
+ Vous ne pouvez ajouter une configuration de point de terminaison supplémentaire que si le mode d'accès au point de terminaison est défini sur`BASIC`. Une fois que vous avez deux configurations de point de terminaison, vous ne pouvez pas modifier le mode d'accès au point de terminaison. Pour de plus amples informations, veuillez consulter [Mode d’accès au point de terminaison](apigateway-security-policies.md#apigateway-security-policies-endpoint-access-mode).
+ Si votre nom de domaine personnalisé utilise une politique de sécurité qui commence par`SecurityPolicy_`, lorsque vous ajoutez un nouveau type de configuration de point de terminaison, le mode d'accès au point de terminaison est le même pour les deux types de point de terminaison, et vous devez choisir une politique de sécurité commençant par `SecurityPolicy_` pour le nouveau type de configuration de point de terminaison.
## Migration de noms de domaine personnalisés
**Note**
Pour effectuer la migration, veillez à supprimer le point de terminaison obsolète de votre nom de domaine personnalisé.
La procédure suivante explique comment migrer un nom de domaine personnalisé optimisé pour la périphérie vers un nom de domaine personnalisé régional.
------
#### [ AWS Management Console ]
1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway)
1. Sélectionnez **Noms de domaine personnalisés** dans le volet de navigation principal.
1. Choisissez un nom de domaine personnalisé optimisé pour la périphérie.
1. Pour **Configuration du point de terminaison**, choisissez **Modifier**.
1. Choisissez **Ajouter un point de terminaison régional**.
1. Pour **Certificat ACM**, choisissez un certificat.
Le certificat régional doit se situer dans la même région que l’API régionale.
1. Sélectionnez **Enregistrer les modifications**.
1. Configurez un enregistrement DNS pour pointer le nom de domaine personnalisé régional vers ce nom d’hôte régional. Pour plus d’informations, consultez [Configuring Route 53 to route traffic to API Gateway](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-api-gateway.html).
1. Après avoir vérifié que votre configuration DNS utilise le bon point de terminaison, vous allez supprimer la configuration du point de terminaison optimisé pour la périphérie. Choisissez votre nom de domaine personnalisé et, pour **Configuration du point de terminaison optimisé pour la périphérie**, choisissez **Supprimer**.
1. Confirmez votre choix et supprimez le point de terminaison.
------
#### [ AWS CLI ]
La [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-domain-name.html)commande suivante fait migrer un nom de domaine personnalisé optimisé pour les périphériques vers un nom de domaine personnalisé régional :
```
aws apigateway update-domain-name \
--domain-name 'api.example.com' \
--patch-operations '[
{ "op":"add", "path": "/endpointConfiguration/types","value": "REGIONAL" },
{ "op":"add", "path": "/regionalCertificateArn", "value": "arn:aws:acm:us-west-2:123456789012:certificate/cd833b28-58d2-407e-83e9-dce3fd852149" }
]'
```
Le certificat régional doit se situer dans la même région que l’API régionale.
Le résultat se présente comme suit :
```
{
"certificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/34a95aa1-77fa-427c-aa07-3a88bd9f3c0a",
"certificateName": "edge-cert",
"certificateUploadDate": "2017-10-16T23:22:57Z",
"distributionDomainName": "d1frvgze7vy1bf.cloudfront.net",
"domainName": "api.example.com",
"endpointConfiguration": {
"types": [
"EDGE",
"REGIONAL"
]
},
"regionalCertificateArn": "arn:aws:acm:us-west-2:123456789012:certificate/cd833b28-58d2-407e-83e9-dce3fd852149",
"regionalDomainName": "d-fdisjghyn6.execute-api.us-west-2.amazonaws.com"
}
```
Pour le nom de domaine personnalisé régional migré, la propriété `regionalDomainName` résultante renvoie le nom d’hôte de l’API régionale. Vous devez configurer un enregistrement DNS pour pointer le nom de domaine personnalisé régional vers ce nom d’hôte régional. Cela permet au trafic lié au nom de domaine personnalisé d’être acheminé vers le nom d’hôte régional.
Une fois l’enregistrement DNS défini, vous pouvez supprimer le nom de domaine personnalisé optimisé pour la périphérie. La [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-domain-name.html)commande suivante supprime le nom de domaine personnalisé optimisé pour les périphériques :
```
aws apigateway update-domain-name \
--domain-name api.example.com \
--patch-operations '[
{"op":"remove", "path":"/endpointConfiguration/types", "value":"EDGE"},
{"op":"remove", "path":"certificateName"},
{"op":"remove", "path":"certificateArn"}
]'
```
------
La procédure suivante explique comment migrer un nom de domaine personnalisé optimisé pour les périphériques qui utilise une politique de sécurité améliorée vers un nom de domaine personnalisé régional qui utilise également une stratégie de sécurité améliorée.
------
#### [ AWS Management Console ]
1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway)
1. Sélectionnez **Noms de domaine personnalisés** dans le volet de navigation principal.
1. Choisissez un nom de domaine personnalisé optimisé pour la périphérie.
1. Pour **Configuration du point de terminaison**, choisissez **Modifier**.
1. Choisissez **Ajouter un point de terminaison régional**.
1. Pour **Certificat ACM**, choisissez un certificat.
Le certificat régional doit se situer dans la même région que l’API régionale.
1. Pour **Politique de sécurité**, choisissez une stratégie de sécurité commençant par`SecurityPolicy_`.
1. Pour le **mode d'accès aux terminaux**, choisissez **Basic**.
1. Sélectionnez **Enregistrer les modifications**.
1. Configurez un enregistrement DNS pour pointer le nom de domaine personnalisé régional vers ce nom d’hôte régional. Pour plus d’informations, consultez [Configuring Route 53 to route traffic to API Gateway](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-api-gateway.html).
1. Après avoir vérifié que votre configuration DNS utilise le bon point de terminaison, vous allez supprimer la configuration du point de terminaison optimisé pour la périphérie. Choisissez votre nom de domaine personnalisé et, pour **Configuration du point de terminaison optimisé pour la périphérie**, choisissez **Supprimer**.
1. Confirmez votre choix et supprimez le point de terminaison.
------
#### [ AWS CLI ]
La [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-domain-name.html)commande suivante fait migrer un nom de domaine personnalisé optimisé pour les périphériques vers un nom de domaine personnalisé régional :
```
aws apigateway update-domain-name \
--domain-name 'api.example.com' \
--patch-operations '[
{ "op":"add", "path": "/endpointConfiguration/types","value": "REGIONAL" },
{ "op":"replace", "path": "/securityPolicy", "value":"SecurityPolicy_TLS13_1_3_2025_09"},
{ "op":"add", "path": "/regionalCertificateArn", "value": "arn:aws:acm:us-west-2:123456789012:certificate/cd833b28-58d2-407e-83e9-dce3fd852149" }
]'
```
Le certificat régional doit se situer dans la même région que l’API régionale.
Le résultat se présente comme suit :
```
{
"certificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/34a95aa1-77fa-427c-aa07-3a88bd9f3c0a",
"certificateName": "edge-cert",
"certificateUploadDate": "2017-10-16T23:22:57Z",
"distributionDomainName": "d1frvgze7vy1bf.cloudfront.net",
"domainName": "api.example.com",
"endpointConfiguration": {
"types": [
"EDGE",
"REGIONAL"
]
},
"securityPolicy": "SecurityPolicy_TLS13_1_3_2025_09",
"endpointAccessMode": "BASIC",
"regionalCertificateArn": "arn:aws:acm:us-west-2:123456789012:certificate/cd833b28-58d2-407e-83e9-dce3fd852149",
"regionalDomainName": "d-fdisjghyn6.execute-api.us-west-2.amazonaws.com"
}
```
Pour le nom de domaine personnalisé régional migré, la propriété `regionalDomainName` résultante renvoie le nom d’hôte de l’API régionale. Vous devez configurer un enregistrement DNS pour pointer le nom de domaine personnalisé régional vers ce nom d’hôte régional. Cela permet au trafic lié au nom de domaine personnalisé d’être acheminé vers le nom d’hôte régional.
Une fois l’enregistrement DNS défini, vous pouvez supprimer le nom de domaine personnalisé optimisé pour la périphérie. La [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-domain-name.html)commande suivante supprime le nom de domaine personnalisé optimisé pour les périphériques :
```
aws apigateway update-domain-name \
--domain-name api.example.com \
--patch-operations '[
{"op":"remove", "path":"/endpointConfiguration/types", "value":"EDGE"},
{"op":"remove", "path":"certificateName"},
{"op":"remove", "path":"certificateArn"}
]'
```
------
La procédure suivante montre comment migrer un nom de domaine personnalisé régional vers un nom de domaine personnalisé optimisé pour la périphérie.
------
#### [ AWS Management Console ]
1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway)
1. Dans le panneau de navigation, sélectionnez **Noms de domaine personnalisés**.
1. Choisissez un nom de domaine personnalisé régional.
1. Pour **Configuration du point de terminaison**, choisissez **Modifier**.
1. Choisissez **Ajouter un point de terminaison optimisé pour les périphéries**.
1. Pour **Certificat ACM**, choisissez un certificat.
Le certificat du domaine optimisé pour la périphérie doit être créé dans la région `us-east-1`.
1. Choisissez **Enregistrer**.
1. Configurez un enregistrement DNS pour pointer le nom de domaine personnalisé optimisé pour la périphérie vers ce nom d’hôte optimisé pour la périphérie. Pour plus d’informations, consultez [Configuring Route 53 to route traffic to API Gateway](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-api-gateway.html).
1. Après avoir vérifié que votre configuration DNS utilise le bon point de terminaison, vous allez supprimer la configuration du point de terminaison régional. Choisissez votre nom de domaine personnalisé, puis pour **Configuration du point de terminaison régional**, choisissez **Supprimer**.
1. Confirmez votre choix et supprimez le point de terminaison.
------
#### [ AWS CLI ]
La [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-domain-name.html)commande suivante fait migrer votre nom de domaine personnalisé régional vers un nom de domaine personnalisé optimisé pour les périphériques :
```
aws apigateway update-domain-name \
--domain-name 'api.example.com' \
--patch-operations '[
{ "op":"add", "path": "/endpointConfiguration/types","value": "EDGE" },
{ "op":"add", "path": "/certificateName", "value": "edge-cert" },
{"op":"add", "path": "/certificateArn", "value": "arn:aws:acm:us-east-1:738575810317:certificate/34a95aa1-77fa-427c-aa07-3a88bd9f3c0a"}
]'
```
Le certificat du domaine optimisé pour la périphérie doit être créé dans la région `us-east-1`.
Le résultat se présente comme suit :
```
{
"certificateArn": "arn:aws:acm:us-east-1:738575810317:certificate/34a95aa1-77fa-427c-aa07-3a88bd9f3c0a",
"certificateName": "edge-cert",
"certificateUploadDate": "2017-10-16T23:22:57Z",
"distributionDomainName": "d1frvgze7vy1bf.cloudfront.net",
"domainName": "api.example.com",
"endpointConfiguration": {
"types": [
"EDGE",
"REGIONAL"
]
},
"regionalCertificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/3d881b54-851a-478a-a887-f6502760461d",
"regionalDomainName": "d-cgkq2qwgzf.execute-api.us-east-1.amazonaws.com"
}
```
Pour le nom de domaine personnalisé spécifié, API Gateway renvoie le nom d’hôte de l’API optimisée pour la périphérie en tant que valeur de propriété `distributionDomainName`. Vous devez définir un enregistrement DNS pour pointer le nom de domaine personnalisé optimisé pour la périphérie vers ce nom de domaine de distribution. Cela permet au trafic lié au nom de domaine personnalisé optimisé pour la périphérie d’être acheminé vers le nom d’hôte d’API optimisé pour la périphérie.
Une fois l’enregistrement DNS défini, vous pouvez supprimer le type de point de terminaison `REGION` du nom de domaine personnalisé. La [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-domain-name.html)commande suivante supprime le type de point de terminaison régional :
```
aws apigateway update-domain-name \
--domain-name api.example.com \
--patch-operations '[
{"op":"remove", "path":"/endpointConfiguration/types", value:"REGIONAL"},
{"op":"remove", "path":"regionalCertificateArn"}
]'
```
Le résultat se présente comme suit :
```
{
"certificateArn": "arn:aws:acm:us-east-1:738575810317:certificate/34a95aa1-77fa-427c-aa07-3a88bd9f3c0a",
"certificateName": "edge-cert",
"certificateUploadDate": "2017-10-16T23:22:57Z",
"distributionDomainName": "d1frvgze7vy1bf.cloudfront.net",
"domainName": "api.example.com",
"endpointConfiguration": {
"types": "EDGE"
}
}
```
------
# Envoyez du trafic vers vous APIs via votre nom de domaine personnalisé dans API Gateway
Lorsque vous configurez le mode de routage pour votre nom de domaine personnalisé, vous définissez la manière dont le trafic entrant est dirigé vers votre APIs. Vous envoyez du trafic à votre adresse à APIs l'aide de règles de routage, de mappages d'API ou de règles de routage et de mappages d'API. La section suivante explique quand utiliser des règles de routage et des mappages d’API, et comment définir le mode de routage de votre nom de domaine personnalisé.
## Quand utiliser des règles de routage
Lorsque vous utilisez des règles de routage, vous dirigez les demandes entrantes répondant à certaines conditions vers des APIs étapes REST spécifiques. Par exemple, une règle peut acheminer une demande vers l’étape `production` de votre API REST `users` si elle contient l’en-tête `version:v1` et le chemin de base `/users`. Utilisez les règles de routage pour créer des topologies de routage dynamiques avancées qui prennent en charge des cas d'utilisation tels que le A/B test ou l'augmentation de l'utilisation des nouvelles versions de votre APIs.
Lorsque vous acheminez le trafic vers une API REST, nous vous recommandons d’utiliser des règles de routage pour votre nom de domaine personnalisé. Vous pouvez recréer n’importe quel mappage d’API à l’aide de règles de routage. Pour de plus amples informations, veuillez consulter [Recréation d’un mappage d’API à l’aide de règles de routage](rest-api-routing-rules-recreate-api-mapping.md).
Pour REST APIs, vous pouvez également utiliser conjointement des règles de routage et des mappages d'API. Le cas échéant, API Gateway évalue toujours les règles de routage avant les mappages d’API. Utilisez conjointement des règles de routage et des mappages d’API pour migrer vos noms de domaine personnalisés actuels ou pour explorer les règles de routage.
### Considérations relatives aux règles de routage
Les considérations suivantes peuvent avoir un impact sur votre utilisation des règles de routage :
+ WebSocket ou le protocole HTTP APIs ne sont pas pris en charge comme cible APIs pour les règles de routage.
+ Si votre nom de domaine personnalisé comporte des mappages d'API à la fois vers REST et HTTP APIs, les règles de routage ne sont pas prises en charge.
+ Pour un domaine personnalisé privé, vous pouvez créer une règle de routage vers une API REST privée. Pour un domaine public personnalisé, vous pouvez créer une règle de routage vers une API régionale ou optimisée pour la périphérie.
+ Pour un domaine personnalisé privé, vous ne pouvez pas créer de règle de routage vers une API privée. Pour un nom de domaine personnalisé privé, vous ne pouvez pas créer de règle de routage vers une API publique.
## Choix entre les règles de routage et les mappages d’API
Nous vous recommandons d’utiliser les règles de routage dans la mesure du possible. Utilisez uniquement les mappages d'API pour envoyer du trafic vers un HTTP ou une WebSocket API.
# Définition du mode de routage de votre nom de domaine personnalisé
Vous pouvez choisir le mode de routage qu'API Gateway utilise pour acheminer le trafic vers votre APIs. Pour de plus amples informations, veuillez consulter [Envoyez du trafic vers vous APIs via votre nom de domaine personnalisé dans API Gateway](rest-api-routing-mode.md). Cette section décrit les modes de routage des noms de domaine personnalisés. Vous devez définir un mode de routage pour votre nom de domaine personnalisé afin d'acheminer le trafic vers votre APIs. Les modèles de routage pris en charge sont les suivants :
+ **ROUTING\$1RULE\$1THEN\$1 API\$1MAPPING** — Utilisez ce mode pour envoyer du trafic vers vous APIs avec des règles de routage et des mappages d'API. Dans ce mode, toutes les règles de routage ont la priorité sur les mappages d’API. Pour voir un exemple de ce mode, consultez [Exemple 2 : règles de routage et mappages d’API](rest-api-routing-rules-examples.md#rest-api-routing-rules-examples-rule-and-mappings).
+ **ROUTING\$1RULE\$1ONLY — Utilisez ce mode pour autoriser uniquement** les règles de routage à envoyer du trafic vers votre. APIs Lorsque votre nom de domaine personnalisé utilise ce mode, vous ne pouvez pas créer de mappage d'API, mais vous pouvez utiliser la [get-api-mappings](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/get-api-mappings.html)commande pour les afficher. Les appelants de l’API ne peuvent pas utiliser de mappages d’API pour accéder à ce nom de domaine.
+ **API\$1MAPPING\$1ONLY** — Utilisez ce mode pour autoriser uniquement les mappages d'API à envoyer du trafic vers votre. APIs Si votre nom de domaine personnalisé utilise ce mode, vous ne pouvez pas créer de règles de routage, mais vous pouvez utiliser la commande `list-routing-rules` pour les afficher. Les appelants de l’API ne peuvent pas utiliser de règles de routage pour accéder à ce nom de domaine.
Il s’agit du mode de routage par défaut pour tous vos noms de domaine existants et pour tous les nouveaux noms de domaine que vous créez.
Lorsque vous créez un nom de domaine personnalisé avec `apigateway`, `API_MAPPING_ONLY` est appelé `BASE_PATH_MAPPING_ONLY` et `ROUTING_RULE_THEN_API_MAPPING` est appelé `ROUTING_RULE_THEN_BASE_PATH_MAPPING`. Ce comportement n'est présent que pour AWS CLI CloudFormation, ou aucun SDKs, pas dans le AWS Management Console.
La procédure suivante montre comment modifier le mode de routage d’un nom de domaine personnalisé existant. Lorsque vous modifiez le mode de routage de votre nom de domaine personnalisé, les appelants de l’API ne peuvent pas accéder à votre nom de domaine en utilisant des modes de routage non pris en charge.
------
#### [ AWS Management Console ]
1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway)
1. Sélectionnez **Noms de domaine personnalisés** dans le volet de navigation principal.
1. Choisissez un nom de domaine personnalisé.
1. Sous **Détails du domaine**, choisissez **Modifier**.
1. Pour le **mode de routage**, choisissez **API\$1MAPPINGROUTING\$1RULE\$1THEN\$1**.
1. Choisissez **Enregistrer**.
Si vous remplacez le mode de routage par `ROUTING_RULE_ONLY` ou `API_MAPPING_ONLY`, les mappages d’API ou les règles de routage que vous avez créés sont supprimés de la page Informations de nom de domaine de la console. Si vous modifiez le mode de routage pour prendre en charge soit des règles de routage soit des mappages d’API, ces ressources seront renvoyées.
------
#### [ AWS CLI - apigatewayv2 ]
La [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-domain-name.html)commande suivante met à jour un nom de domaine pour utiliser le mode de routage `ROUTING_RULE_THEN_API_MAPPING` :
```
aws apigatewayv2 update-domain-name \
--domain-name 'api.example.com' \
--routing-mode "ROUTING_RULE_THEN_API_MAPPING"
```
Le résultat se présente comme suit :
```
{
"ApiMappingSelectionExpression": "$request.basepath",
"DomainName": "api.example.com",
"DomainNameArn": "arn:aws:apigateway:us-west-2::/domainnames/api.example.com",
"DomainNameConfigurations": [
{
"ApiGatewayDomainName": "d-abcdefg.execute-api.us-west-2.amazonaws.com",
"CertificateArn": "arn:aws:acm:us-west-2:111122223333:certificate/abcdefg-123456-abcdefg",
"DomainNameStatus": "AVAILABLE",
"EndpointType": "REGIONAL",
"HostedZoneId": "Z2OJLYMUO9EFXC",
"SecurityPolicy": "TLS_1_2"
}
],
"RoutingMode": "ROUTING_RULE_THEN_API_MAPPING",
"Tags": {}
}
```
------
#### [ AWS CLI - apigateway ]
La [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-domain-name.html)commande suivante met à jour un nom de domaine personnalisé privé pour utiliser le mode de routage `ROUTING_RULE_THEN_BASE_PATH_MAPPING` :
```
aws apigateway update-domain-name \
--domain-name 'private.example.com' \
--patch-operations "op='replace',path='/routingMode',value='ROUTING_RULE_THEN_BASE_PATH_MAPPING'"
```
Le résultat se présente comme suit :
```
{
"domainName": "private.example.com",
"domainNameId": "abcd1234",
"domainNameArn": "arn:aws:apigateway:us-west-2:111122223333:/domainnames/private.example.com+abcd1234",
"certificateArn": "arn:aws:acm:us-west-2:111122223333:certificate/a1b2c3d4-5678-90ab-cdef",
"certificateUploadDate": "2024-09-10T10:31:20-07:00",
"endpointConfiguration": {
"types": [
"PRIVATE"
],
"ipAddressType": "dualstack"
},
"domainNameStatus": "AVAILABLE",
"securityPolicy": "TLS_1_2",
"policy": "...",
"routingMode" : "ROUTING_RULE_THEN_BASE_PATH_MAPPING"
}
```
------
# Règles de routage pour connecter les étapes de l'API à un nom de domaine personnalisé pour REST APIs
Une règle de routage est un ensemble de conditions qui invoquent une action lorsqu’elles sont réunies. Par exemple, une règle peut acheminer une demande entrante d’un nom de domaine personnalisé qui contient l’en-tête `Hello:World` et le chemin de base `users` vers l’étape `production` d’une API REST.
Les règles sont évaluées par ordre de priorité. Si vous définissez le mode de routage sur `ROUTING_RULE_THEN_API_MAPPING`, API Gateway évalue toujours toutes les règles de routage avant de passer aux mappages d’API. La liste suivante décrit les conditions, les actions et les priorités d’une règle de routage.
**Conditions**
Lorsque les conditions d'une règle sont satisfaites, ses actions sont effectuées. API Gateway prend en charge jusqu’à deux conditions d’en-tête et une condition de chemin. API Gateway évalue conjointement les conditions d’en-tête et les conditions de chemin de base.
Vous pouvez créer une règle sans condition. Lorsqu’API Gateway évalue cette règle, l’action est toujours exécutée. Vous pouvez créer une règle sans condition comme règle fourre-tout.
Pour plus d’informations sur les conditions d’en-tête, consultez [Correspondance des conditions d’en-tête](#rest-api-routing-rules-condition-headers). Pour plus d’informations sur les conditions de chemin, consultez [Correspondance des conditions de chemin de base](#rest-api-routing-rules-condition-path).
**Actions**
Les actions sont le résultat de la correspondance entre les conditions et la règle de routage. Actuellement, la seule action prise en charge consiste à invoquer une étape d’une API REST.
Chaque règle peut comporter une action.
**Priority**
La priorité détermine l’ordre d’évaluation des règles, de la valeur la plus basse à la valeur la plus élevée. Les règles ne peuvent pas avoir la même priorité.
Vous pouvez définir la priorité entre 1 et 1 000 000. Si une règle a une priorité de 1, API Gateway l’évalue en premier. Lorsque vous créez une règle, nous vous recommandons d’ajouter des espaces entre les priorités. Vous pourrez ainsi modifier la priorité des règles et en ajouter de nouvelles. Pour de plus amples informations, veuillez consulter [Modification de la priorité d’une règle de routage](apigateway-routing-rules-use.md#rest-api-routing-rules-change-priority).
Pour voir des exemples d’évaluation des règles de routage par API Gateway, consultez [Exemples d’évaluation de règles de routage par API Gateway](rest-api-routing-rules-examples.md).
## Types de conditions des règles de routage API Gateway
La section suivante décrit les types de conditions des règles de routage. API Gateway applique une règle que si toutes les conditions sont réunies.
### Correspondance des conditions d’en-tête
Lorsque vous créez une condition d’en-tête, vous pouvez faire correspondre le nom de l’en-tête et la valeur globale de l’en-tête, par exemple `Hello:World`. API Gateway utilise une correspondance littérale pour valider les conditions de correspondance des en-têtes. Votre condition peut utiliser jusqu’à deux en-têtes, séparés par `AND`. Par exemple, votre condition peut être remplie si une demande entrante comprend `Hello:World` et `x-version:beta`.
La correspondance du nom de l’en-tête n’est pas sensible à la casse, mais la valeur globale de l’en-tête l’est. `Hello:World` correspond à `hello:World`, mais pas `Hello:world`.
Pour connaître la liste des valeurs d’en-tête restreintes, consultez [Restrictions](#rest-api-routing-rules-restrictions).
#### Utilisation de caractères génériques avec des conditions d’en-tête
Les caractères génériques ne peuvent être utilisés que dans la valeur globale de l’en-tête, et doivent être `*prefix-match`, `suffix-match*` ou `*contains*`. Le tableau suivant présente des exemples d’utilisation des caractères génériques pour la correspondance des conditions d’en-tête.
| Conditions d’en-tête | Demandes conformes à la règle de routage | Demandes non conformes à la règle de routage |
| --- | --- | --- |
| `x-version: a*` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/rest-api-routing-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/rest-api-routing-rules.html) |
| `x-version: *a` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/rest-api-routing-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/rest-api-routing-rules.html) |
| `x-version: *a*` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/rest-api-routing-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/rest-api-routing-rules.html) |
| `x-version: *a*` et `x-version: *b*` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/rest-api-routing-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/rest-api-routing-rules.html) |
| `x-version: b*` et `x-version: *a` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/rest-api-routing-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/rest-api-routing-rules.html) |
| `x-version: *` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/rest-api-routing-rules.html) | Aucune |
Si vous créez des conditions pour plusieurs valeurs d’en-tête, par exemple `Accept:application/json,text/xml`, nous vous recommandons d’utiliser `*contains*` pour vos conditions d’en-tête et d’éviter de créer des conditions à l’aide de la virgule (`,`).
Étant donné qu’API Gateway fait correspondre littéralement les conditions d’en-tête, les correspondances sémantiques peuvent être acheminées différemment. Le tableau suivant montre les différence de résultat des règles de routage.
| Conditions d’en-tête | Demandes conformes à la règle de routage | Demandes non conformes à la règle de routage |
| --- | --- | --- |
| `Accept: *json` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/rest-api-routing-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/rest-api-routing-rules.html) |
| `Accept: *json*` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/rest-api-routing-rules.html) | Aucune |
### Correspondance des conditions de chemin de base
Lorsque vous créez une condition de chemin de base, si la demande entrante contient le chemin que vous avez spécifié, la règle correspond. La correspondance étant sensible à la casse, le chemin `New/Users` ne correspondra pas à `new/users`.
Vous ne pouvez créer une condition de chemin de base que pour un seul chemin de base.
Pour obtenir la liste des restrictions des conditions de chemin de base, consultez [Restrictions](#rest-api-routing-rules-restrictions).
#### Suppression du chemin de base avec les conditions du chemin de base
Lorsque vous créez une condition de trajectoire de base, vous pouvez choisir de supprimer la trajectoire de base. Lorsque vous supprimez le chemin de base, API Gateway supprime le chemin de base entrant correspondant lorsqu’il invoque l’API cible. C’est le même comportement que lorsque vous utilisez un mappage d’API. Si vous ne supprimez pas le chemin de base, API Gateway transmet l’intégralité du chemin de base à l’API cible. Nous vous recommandons de supprimer le chemin de base uniquement lorsque vous recréez un mappage d’API.
Le tableau suivant présente des exemples d’évaluation de la condition de suppression du chemin de base par API Gateway.
| Condition | Suppression du chemin de base | Demande entrante | Résultat |
| --- | --- | --- | --- |
| Si le chemin de base contient `PetStoreShopper/dogs` | True | `GET https://example.com/PetStoreShopper/dogs` | API Gateway appelle la méthode `GET` de la ressource `/`. |
| Si le chemin de base contient `PetStoreShopper/dogs`. | False | `GET https://example.com/PetStoreShopper/dogs` | API Gateway appelle la méthode `GET` de la ressource `PetStoreShopper/dogs`. |
| Si le chemin de base contient `PetStoreShopper` | True | `GET https://example.com/PetStoreShopper/dogs` | API Gateway appelle la méthode `GET` de la ressource `dogs`. |
| Si le chemin de base contient `PetStoreShopper` | False | `GET https://example.com/PetStoreShopper/dogs` | API Gateway appelle la méthode `GET` de la ressource `PetStoreShopper/dogs`. |
| Si le chemin de base contient `PetStoreShopper` | True | `GET https://example.com/PetStoreShopper?birds=available` | API Gateway appelle la méthode `GET` de la ressource `/` avec le paramètre de chaîne de requête `birds=available`. |
| Si le chemin de base contient `PetStoreShopper` | False | `GET https://example.com/PetStoreShopper?birds=available` | API Gateway appelle la méthode `GET` de la ressource `/PetStoreShopper` avec le paramètre de chaîne de requête `birds=available`. |
## Restrictions
+ L'API cible et le nom de domaine personnalisé doivent se trouver dans le même AWS compte.
+ Chaque règle peut comporter une API cible.
+ Pour un nom de domaine personnalisé privé, vous ne pouvez créer une règle de routage que vers une API privée. Pour un nom de domaine personnalisé public, vous ne pouvez créer une règle de routage que vers une API publique. Vous ne pouvez pas mélanger des ressources publiques et privées.
+ Si votre nom de domaine personnalisé comporte des mappages d'API à la fois vers REST et HTTP APIs, les règles de routage ne sont pas prises en charge.
+ La priorité maximale est de 1 000 000.
+ Restrictions applicables aux en-têtes :
+ Chaque condition `anyOf` ne peut contenir qu’une seule valeur d’en-tête.
+ Les seuls caractères autorisés pour les noms d’en-tête et les valeurs globales des en-têtes sont spécifiés par [RFC 7230](https://datatracker.ietf.org/doc/html/rfc7230), à savoir `a-z`, `A-Z`, `0-9` et les caractères spéciaux suivants : `*?-!#$%&'.^_`|~`.
+ Vous pouvez utiliser un caractère générique dans la valeur globale de l’en-tête, mais celui-ci doit être `*prefix-match`, `suffix-match*` ou `*contains*`. Vous ne pouvez pas utiliser `*` au milieu d’une valeur globale d’en-tête.
+ Les noms d’en-tête génériques ne sont pas pris en charge.
+ Le nom de l’en-tête doit contenir moins de 40 caractères.
+ La valeur globale de l’en-tête doit être inférieure à 128 caractères.
+ La valeur globale de l’en-tête pour une correspondance infixe doit être inférieure à 40 caractères.
+ Les en-têtes suivants ne sont pas pris en charge en tant que conditions :
+ `access-control-*`
+ `apigw-*`
+ `Authorization`
+ `Connection`
+ `Content-Encoding`
+ `Content-Length`
+ `Content-Location`
+ `Forwarded`
+ `Keep-Alive`
+ `Origin`
+ `Proxy-Authenticate`
+ `Proxy-Authorization`
+ `TE`
+ `Trailers`
+ `Transfer-Encoding`
+ `Upgrade`
+ `x-amz-*`
+ `x-amzn-*`
+ `x-apigw-api-id`
+ `X-Forwarded-For`
+ `X-Forwarded-Host`
+ `X-Forwarded-Proto`
+ `x-restAPI`
+ `Via`
+ Restrictions applicables aux chemins de base :
+ Le nom du chemin de base doit contenir moins de 128 caractères.
+ Le chemin de base ne doit contenir que des lettres, des chiffres et les caractères suivants : `$-_.+!*'()/`.
Ces caractères ne sont pas pris en charge pour les expressions régulières.
+ Le chemin de base ne peut ni commencer ni se terminer par une barre oblique inversée (`\`).
# Exemples d’évaluation de règles de routage par API Gateway
La section suivante présente quatre exemples d’évaluation de règles de routage et de mappages d’API par API Gateway.
## Exemple 1 : règles de routage uniquement
Dans cet exemple, le mode de routage du nom de domaine personnalisé `https://petstore.example.com` est défini sur `ROUTING_RULE_ONLY`, et ce dernier possède les règles et priorités de routage suivantes.
| ID de la règle | Priority | Conditions | Action |
| --- | --- | --- | --- |
| `abc123` | 10 | Si la demande contient l’en-tête `Hello:World` | API cible 1 |
| `zzz000` | 50 | Si la demande contient les en-têtes `Accept:image/webp` et `Pet:Dog-*`, et si le chemin de base contient `PetStoreShopper` | API cible 2 |
| `efg456` | 100 | Aucune | API cible 3 |
Le tableau suivant montre comment API Gateway applique les règles de routage précédentes à des exemples de demande.
| Requête | API sélectionnée | Explication |
| --- | --- | --- |
| `https://petstore.example.com -h "Hello:World"` | API cible 1 | La demande correspond à la règle de routage `abc123`. |
| `https://petstore.example.com/PetStoreShopper -h "Hello:World", "Pet:Dog-Bella", "Accept:image/webp"` | API cible 1 | API Gateway évalue toutes les règles de routage par ordre de priorité. La règle de routage `abc123` a la priorité la plus élevée et les conditions correspondent. API Gateway invoque donc l’API cible 1. Bien que les conditions de la demande correspondent également à la règle de routage `zzz000`, API Gateway n’évalue aucune autre règle de routage après avoir identifié une correspondance. |
| `https://petstore.example.com/PetStoreShopper -h "Pet:Dog-Bella", "Accept:image/webp"` | API cible 2 | La demande correspond à la règle de routage `zzz000`. Il y a correspondance, car `Pet:Dog-Bella` correspond à la chaîne `Pet:Dog-*` |
| `https://petstore.example.com/PetStoreShopper -h "Pet:Dog-Bella"` | API cible 3 | La demande ne correspond pas à la règle de routage `abc123`. La demande ne correspond pas à la règle de routage `zzz000`, car tous les en-têtes requis ne sont pas présents. La règle de priorité suivante correspond à toutes les demandes entrantes. API Gateway invoque donc l’API cible 3. |
## Exemple 2 : règles de routage et mappages d’API
Dans cet exemple, le mode de routage du nom de domaine personnalisé `https://petstore.diagram.example.com` est défini sur `ROUTING_RULE_THEN_API_MAPPING`, et ce dernier possède les règles de routage et mappages d’API suivants.
| ID de la règle | Priority | Conditions | Action |
| --- | --- | --- | --- |
| `abc123` | 1 | Si la demande contient `pets` | Invoquer l’étape `Prod` de l’API `PetStore`. |
| `000zzz` | 5 | Si la demande contient l’en-tête `Cookie`:`*ux=beta*` et si le chemin de base contient `/refunds` | Invoquer l’étape `Beta` de l’API `Refunds`. |
Le tableau suivant présente les mappages d’API pour `https://petstore.backup.example.com`.
| Mappage d’API | API sélectionnée |
| --- | --- |
| `/refunds` | Invoquer l’étape `Prod` de l’API `Refunds`. |
| `(none)` | Invoquer l’étape `Prod` de l’API `Search`. |
Le schéma suivant montre comment API Gateway applique les règles de routage et les mappages d’API précédents à des exemples de demande. Ces exemples sont résumés dans le tableau qui suit ce schéma.
![\[Schéma d’application des règles de routage et des mappages d’API précédents par API Gateway.\]](http://docs.aws.amazon.com/fr_fr/apigateway/latest/developerguide/images/rr-diagram.png)
Le tableau suivant montre comment API Gateway applique les règles de routage et les mappages d’API précédents à des exemples de demande.
| Requête | API sélectionnée | Explication |
| --- | --- | --- |
| `https://petstore.diagram.com/pets` | Étape `Prod` de l’API `PetStore`. | La demande correspond à la règle de routage `abc123`. |
| `https://petstore.diagram.example.com/refunds -h "Cookie:lang=en-us;ux=beta"` | Étape `Beta` de l’API `Refunds`. | La demande correspond à la règle de routage `000zzz`. L’en-tête `Cookie` contient la bonne correspondance `*contains*` et le bon chemin de base pour cette condition. |
| `https://petstore.diagram.example.com/refunds` | Étape `Prod` de l’API `Refunds`. | La demande ne possède pas les en-têtes requis pour correspondre à la règle de routage `zzz000`. Si API Gateway ne parvient pas à identifier de correspondance avec la règle de routage, il passe aux mappages d’API. API Gateway peut mapper le chemin de base à l’étape `Prod` de l’API `Refunds`. |
| `https://petstore.diagram.example.com/` | Étape `Prod` de l’API `Search`. | La demande correspond au mappage de l’API vers le chemin vide `(none)`. |
## Exemple 3 : règles de routage et mappages d’API à plusieurs niveaux
Dans cet exemple, le mode de routage du nom de domaine personnalisé `https://petstore.backup.example.com` est défini sur `ROUTING_RULE_THEN_API_MAPPING`, et ce dernier possède les règles de routage et mappages d’API suivants.
Le tableau suivant présente les règles de routage pour `https://petstore.backup.example.com`.
| ID de la règle | Priority | Conditions | Action |
| --- | --- | --- | --- |
| `abc123` | 10 | Si la demande contient l’en-tête `Hello:World` | API cible 1 |
| `000zzz` | 50 | Si la demande contient les en-têtes `Accept`:`image/webp` et `Pet:Dog-*`, et si le chemin de base contient `PetStoreShopper` | API cible 2 |
Le tableau suivant présente les mappages d’API pour `https://petstore.backup.example.com`.
| Mappage d’API | API sélectionnée |
| --- | --- |
| `PetStoreShopper` | API cible 3 |
| `PetStoreShopper/cats` | API cible 4 |
Le tableau suivant montre comment API Gateway applique les règles de routage et les mappages d’API précédents à des exemples de demande.
| Requête | API sélectionnée | Explication |
| --- | --- | --- |
| `https://petstore.example.com/PetStoreShopper -h "Accept:image/webp", "Pet:Cats" ` | API cible 3 | La demande ne possède pas les en-têtes requis pour correspondre à la règle de routage `zzz000`. Si API Gateway ne parvient pas à identifier de correspondance avec la règle de routage, il passe aux mappages d’API. API Gateway peut mapper le chemin de base à l’API cible 3. |
| `https://petstore.example.com/PetStoreShopper/cats -h "Hello:World"` | API cible 1 | La demande correspond à la règle de routage `abc123`. Si le mode de routage est défini sur `ROUTING_RULE_THEN_API_MAPPING`, les règles de routage ont toujours la priorité sur les mappages d’API. |
| `https://petstore.example.com/Admin -h "Pet:Dog-Bella"` | Aucune | La demande ne correspond à aucune règle de routage ni à aucun mappage d’API. En l’absence de règle de routage par défaut, API Gateway rejette l’appel et envoie à l’appelant le code d’état `403 Forbidden`. |
## Exemple 4 : règles de routage pour les noms de domaine génériques
Dans cet exemple, le nom de domaine personnalisé `https://*.example.com` est un nom de domaine générique. Le caractère générique prend en charge tous les sous-domaines renvoyant vers le même domaine. Les exemples de règles de routage suivants modifient ce comportement pour permettre aux sous-domaines d'être acheminés vers une cible différente à l'aide APIs de l'`Host`en-tête.
Le tableau suivant présente les règles de routage pour `https://*.example.com`.
| ID de la règle | Priority | Conditions | Action |
| --- | --- | --- | --- |
| `abc123` | 10 | Si la demande contient l’en-tête `Host:a.example.com` | API cible 1 |
| `000zzz` | 50 | Si la demande contient l’en-tête `Host:b.example.com` | API cible 2 |
| `efg456` | 500 | Aucune | API cible 3 |
Le tableau suivant montre comment API Gateway applique les règles de routage précédentes à des exemples de demande.
| Requête | API sélectionnée | Explication |
| --- | --- | --- |
| `https://a.example.com` | API cible 1 | L’en-tête `Host` est `a.example.com`. Cette demande correspond à la règle de routage `abc123`. |
| `https://b.example.com` | API cible 2 | L’en-tête `Host` est `b.example.com`. Cette demande correspond à la règle de routage `000zzz`. |
| `https://testing.example.com` | API cible 3 | Cette demande correspond à la règle de routage fourre-tout `efg456`. |
# Méthodes d’utilisation des règles de routage
Vous pouvez créer une règle de routage à l'aide du AWS Management Console SDK ou de n'importe quel autre AWS SDK. AWS CLI Après avoir créé une règle, vous pouvez modifier sa priorité.
## Création d’une règle de routage
La procédure suivante explique comment créer une règle de routage pour un nom de domaine personnalisé avec un mode de routage défini sur `ROUTING_RULE_THEN_API_MAPPING` ou `ROUTING_RULE_ONLY`.
------
#### [ AWS Management Console ]
1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway)
1. Sélectionnez **Noms de domaine personnalisés** dans le volet de navigation principal.
1. Choisissez un nom de domaine personnalisé.
1. Dans l’onglet **Détails du routage**, choisissez **Ajouter une règle de routage**.
1. Choisissez **Ajouter une nouvelle condition** pour ajouter une nouvelle condition.
Vous pouvez ajouter une condition d’en-tête ou de chemin de base. Pour faire correspondre toutes les demandes entrantes à votre nom de domaine personnalisé, n’ajoutez pas de condition.
1. Sous **Action**, utilisez le menu déroulant pour sélectionner votre API et votre étape cibles.
1. Choisissez **Suivant**.
1. Dans le champ Priorité, saisissez un nombre pour votre priorité.
API Gateway évalue les règles par ordre de priorité, de la valeur la plus basse à la valeur la plus élevée.
Si vous créez une règle sans condition, nous vous recommandons d’utiliser une priorité élevée.
1. Choisissez **Créer une règle de routage**.
------
#### [ AWS CLI ]
La [create-routing-rule](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-routing-rule.html)commande suivante crée une règle de routage avec une priorité de 50. Dans cet exemple, API Gateway achemine toutes les demandes entrantes contenant les en-têtes `Hello:World` et `x-version:beta`, ainsi que le chemin de base `PetStoreShopper` vers l’API cible `a1b2c3`.
```
aws apigatewayv2 create-routing-rule \
--domain-name 'api.example.com' \
--priority 50 \
--conditions '[
{
"MatchHeaders": {
"AnyOf": [
{
"Header": "Hello",
"ValueGlob": "World"
}
]
}
},
{
"MatchHeaders": {
"AnyOf": [
{
"Header": "x-version",
"ValueGlob": "beta"
}
]
}
},
{
"MatchBasePaths": {
"AnyOf": [
"PetStoreShopper"
]
}
}
]'\
--actions '[
{
"InvokeApi": {
"ApiId": "a1b2c3",
"Stage": "prod"
}
}
]'
```
Le résultat se présente comme suit :
```
{
"Actions": [
{
"InvokeApi": {
"ApiId": "a1b2c3",
"Stage": "prod",
"StripBasePath": false
}
}
],
"Conditions": [
{
"MatchHeaders": {
"AnyOf": [
{
"Header": "Hello",
"ValueGlob": "World"
}
]
}
},
{
"MatchHeaders": {
"AnyOf": [
{
"Header": "x-version",
"ValueGlob": "beta"
}
]
}
},
{
"MatchBasePaths": {
"AnyOf": [
"PetStoreShopper"
]
}
}
],
"Priority": 50,
"RoutingRuleArn": "arn:aws:apigateway:us-west-2:111122223333:/domainnames/api.example.com/routingrules/abc123",
"RoutingRuleId": "abc123"
}
```
------
## Modification de la priorité d’une règle de routage
Vous pouvez modifier la priorité d’une règle de routage. Cette modification prend effet immédiatement et peut avoir un impact sur la manière dont les utilisateurs d’API invoquent vos noms de domaine personnalisés. Lorsque vous définissez les priorités de vos règles de routage, nous vous recommandons de laisser des espaces entre les règles.
Par exemple, imaginons que vous définissiez deux règles de routage, une règle `abc123` avec une priorité de 50 et une règle `zzz000` avec une priorité de 150. Pour modifier leur priorité des règle afin qu’API Gateway évalue la règle `zzz000` en premier, vous pouvez définir la priorité de la règle `zzz000` sur 30.
------
#### [ AWS Management Console ]
1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway)
1. Sélectionnez **Noms de domaine personnalisés** dans le volet de navigation principal.
1. Choisissez un nom de domaine personnalisé.
1. Sous l’onglet **Détails du routage**, choisissez votre règle de routage, puis sélectionnez **Modifier**.
1. Choisissez **Suivant**.
1. Sous Priorité, saisissez la nouvelle priorité.
1. Sélectionnez **Enregistrer les modifications**.
------
#### [ AWS CLI ]
La [put-routing-rule](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/put-routing-rule.html)commande suivante modifie la priorité d'une règle de routage`abc123`.
```
aws apigatewayv2 put-routing-rule \
--domain-name 'api.example.com' \
--priority 30 \
--routing-rule-id abc123 \
--conditions '[
{
"MatchHeaders": {
"AnyOf": [
{
"Header": "Hello",
"ValueGlob": "World"
}
]
}
},
{
"MatchHeaders": {
"AnyOf": [
{
"Header": "x-version",
"ValueGlob": "beta"
}
]
}
},
{
"MatchBasePaths": {
"AnyOf": [
"PetStoreShopper"
]
}
}
]'\
--actions '[
{
"InvokeApi": {
"ApiId": "a1b2c3",
"Stage": "prod"
}
}
]'
```
Le résultat se présente comme suit :
```
{
"Actions": [
{
"InvokeApi": {
"ApiId": "a1b2c3",
"Stage": "prod",
"StripBasePath": false
}
}
],
"Conditions": [
{
"MatchHeaders": {
"AnyOf": [
{
"Header": "Hello",
"ValueGlob": "World"
}
]
}
},
{
"MatchHeaders": {
"AnyOf": [
{
"Header": "x-version",
"ValueGlob": "beta"
}
]
}
},
{
"MatchBasePaths": {
"AnyOf": [
"PetStoreShopper"
]
}
}
],
"Priority": 38,
"RoutingRuleArn": "arn:aws:apigateway:us-west-2:111122223333:/domainnames/api.example.com/routingrules/abc123",
"RoutingRuleId": "abc123"
}
```
------
# Recréation d’un mappage d’API à l’aide de règles de routage
Vous pouvez recréer un mappage d’API à l’aide de règles de routage. Pour recréer un mappage d’API, assurez-vous d’activer la suppression du chemin de base. Cela préserve le comportement des mappages d’API. Pour de plus amples informations, veuillez consulter [Suppression du chemin de base avec les conditions du chemin de base](rest-api-routing-rules.md#rest-api-routing-rules-condition-path-split).
Le tutoriel suivant explique comment recréer le mappage d’API `https:// api.example.com/orders/v2/items/categories/5` en tant que règle de routage, et comment mettre à jour vos journaux d’accès pour enregistrer l’ID de la règle de routage utilisée par API Gateway pour envoyer le trafic à votre API.
------
#### [ AWS Management Console ]
**Pour définir le mode de routage sur ROUTING\$1RULE\$1THEN\$1 API\$1MAPPING**
1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway)
1. Sélectionnez **Noms de domaine personnalisés** dans le volet de navigation principal.
1. Choisissez votre nom de domaine personnalisé.
1. Sous **Détails du domaine**, choisissez **Modifier**.
1. Pour le **mode de routage**, choisissez **API\$1MAPPINGROUTING\$1RULE\$1THEN\$1**.
1. Choisissez **Enregistrer**.
Après avoir défini le mode de routage, vous allez créer la règle de routage.
**Pour créer la règle de routage**
1. Dans l’onglet **Détails du routage**, choisissez **Ajouter une règle de routage**.
1. Choisissez **Ajouter une condition**, puis **Chemin**.
1. Sous **Chemin**, saisissez **orders/v2/items/categories/5**.
1. Sous **Chemin de base de la bande**, choisissez **Actif**.
1. Sous **API cible**, choisissez votre API cible.
1. Sous **Étape cible**, choisissez votre étape cible.
1. Choisissez **Suivant**.
1. Sous Priorité, saisissez une priorité.
Même si vous conservez votre mappage d’API, API Gateway utilisera toujours la nouvelle règle de routage, car les règles de routage ont toujours la priorité sur les mappages d’API.
1. Sélectionnez **Enregistrer les modifications**.
Après avoir créé la règle de routage, mettez à jour le format du journal d’accès pour votre étape, ou créez un journal afin de vérifier qu’API Gateway utilise votre règle de routage pour envoyer le trafic à votre API.
**Pour mettre à jour vos journaux d’accès**
1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway)
1. Choisissez votre API.
1. Dans le volet de navigation principal, choisissez **Étapes**.
1. Sous **Journaux et traçage**, choisissez **Modifier**.
Si vous n’avez pas de groupe de journaux, consultez [Configuration de la CloudWatch journalisation pour REST APIs dans API Gateway](set-up-logging.md).
1. Ajoutez **\$1context.customDomain.routingRuleIdMatched** à votre format de journal.
Ce groupe de journaux enregistre l’ID de la règle de routage utilisée par API Gateway pour envoyer le trafic à votre API. Pour de plus amples informations, veuillez consulter [Je ne peux pas dire comment API Gateway a envoyé du trafic à mon APIs](rest-api-routing-rules-troubleshoot.md#rest-api-routing-rules-logging).
1. Choisissez **Enregistrer**.
Après avoir mis à jour vos journaux d’accès, invoquez votre nom de domaine personnalisé. Voici un exemple de commande curl permettant d’invoquer le nom de domaine personnalisé `https://api.example.com` avec le chemin de base `orders/v2/items/categories/5`.
```
curl "https://api.example.com/orders/v2/items/categories/5"
```
Après avoir invoqué avec succès votre nom de domaine personnalisé, vérifiez que CloudWatch Logs affiche le`routingRuleIdMatched`. Pour savoir comment utiliser la console CloudWatch Logs pour afficher un groupe de journaux, consultez[Afficher les événements du journal d'API Gateway dans la CloudWatch console](view-cloudwatch-log-events-in-cloudwatch-console.md).
------
#### [ AWS CLI ]
1. Utilisez la [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-domain-name.html)commande suivante pour mettre à jour le nom de domaine `api.example.com` afin d'utiliser le mode de routage`ROUTING_RULE_THEN_API_MAPPING`.
```
aws apigatewayv2 update-domain-name \
--domain-name 'api.example.com' \
--routing-mode ROUTING_RULE_THEN_API_MAPPING
```
1. Utilisez la [create-routing-rule](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-routing-rule.html)commande suivante pour créer une nouvelle règle de routage afin de recréer le mappage `https://api.example.com/orders/v2/items/categories/5` d'API.
```
aws apigatewayv2 create-routing-rule \
--domain-name 'api.example.com' \
--priority 50 \
--conditions '[
{
"MatchBasePaths": {
"AnyOf": [
"orders/v2/items/categories/5"
]
}
}
]' \
--actions '[
{
"InvokeApi": {
"ApiId": "a1b2c3",
"Stage": "prod",
"StripBasePath": true
}
}
]'
```
1. Utilisez la commande [update-stage](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-stage.html) suivante pour mettre à jour le format des journaux d’accès afin qu’il inclut la variable `$context.customDomain.routingRuleIdMatched`. Cette variable enregistre l’ID de la règle de routage utilisée par API Gateway pour envoyer le trafic à votre API. Vous allez utilisez ce journal pour vérifier qu’API Gateway utilise votre règle de routage pour envoyer le trafic à votre API. Pour de plus amples informations, veuillez consulter [Je ne peux pas dire comment API Gateway a envoyé du trafic à mon APIs](rest-api-routing-rules-troubleshoot.md#rest-api-routing-rules-logging).
```
aws apigateway update-stage \
--rest-api-id a1bc2c3 \
--stage-name prod \
--patch-operations "op=replace,path=/accessLogSettings/format,value='\$context.path \$context.customDomain.routingRuleIdMatched \$context.requestId \$context.extendedRequestId'"
```
Si vous n’avez pas de groupe de journaux, consultez [Configuration de la CloudWatch journalisation pour REST APIs dans API Gateway](set-up-logging.md).
1. Utilisez l’exemple de commande curl suivant pour invoquer votre nom de domaine personnalisé à l’aide du chemin de base `orders/v2/items/categories/5`.
```
curl "https://api.example.com/orders/v2/items/categories/5
```
1. Utilisez la [filter-log-events](https://docs.aws.amazon.com/cli/latest/reference/logs/filter-log-events.html)commande suivante pour obtenir les événements du journal à partir du groupe de journaux `access-log-group-orders` contenant l'ID de règle de routage`abc123`.
```
aws logs filter-log-events --log-group-name access-log-group-orders --filter-pattern abc123
```
Vous avez la confirmation qu’API Gateway a utilisé la règle de routage pour envoyer le trafic à votre API.
------
# Résolution des problèmes liés aux règles de routage
Les conseils suivants peuvent vous aider à résoudre les problèmes liés à votre règles de routage.
## Je ne peux pas dire comment API Gateway a envoyé du trafic à mon APIs
Vous pouvez utiliser les journaux d’accès de l’étape de votre API REST afin d’enregistrer et de résoudre les problèmes liés à vos règles de routage. Vous pouvez consulter l’ID de la règle de routage utilisée par API Gateway pour envoyer le trafic à votre API à l’aide de la variable `$context.customDomain.routingRuleIdMatched`. Pour afficher le mappage d’API utilisé par API Gateway pour envoyer le trafic à votre API, utilisez la variable `$context.customDomain.basePathMatched`.
Pour enregistrer vos règles de routage, vous devez configurer [un ARN de rôle CloudWatch Logs approprié](set-up-logging.md#set-up-access-logging-permissions) pour votre compte et créer un groupe de journaux.
L’exemple de groupe de journaux d’accès suivant récupère les informations pertinentes pour résoudre les problèmes liés aux règles de routage et aux mappages d’API. API Gateway renseigne uniquement la variable context correspondant au mécanisme de routage utilisé. Sinon, la variable context est `-`.
------
#### [ CLF ]
```
$context.path $context.customDomain.routingRuleIdMatched $context.customDomain.basePathMatched $context.requestId $context.extendedRequestId
```
------
#### [ JSON ]
```
{"requestPath": "$context.path", "routingRuleId" : "$context.customDomain.routingRuleIdMatched", "API mapping" : "$context.customDomain.basePathMatched", "requestId":"$context.requestId", "extendedRequestId":"$context.extendedRequestId"}
```
------
#### [ XML ]
```
$context.path $context.customDomain.routingRuleIdMatched $context.customDomain.basePathMatched $context.extendedRequestId
```
------
#### [ CSV ]
```
$context.path,$context.customDomain.routingRuleIdMatched,$context.customDomain.basePathMatched,$context.requestId,$context.extendedRequestId
```
------
Nous vous recommandons également de vérifier le mode de routage de votre nom de domaine personnalisé. Pour de plus amples informations, veuillez consulter [Définition du mode de routage de votre nom de domaine personnalisé](set-routing-mode.md).
## Je ne parviens pas à activer les règles de routage de mon nom de domaine personnalisé
API Gateway peut vous envoyer l’erreur suivante :
```
Your account doesn’t have permission to use RoutingRules.
This might be caused by an IAM policy in your account with a deny statement on BasePathMapping or ApiMapping.
To grant permission for this account to use RoutingRules, use the UpdateAccount API.
This will impact any existing IAM policies that deny access to BasePathMapping or ApiMapping.
See API Gateway documentation for further details.
```
Vous recevrez cette erreur si vous avez ou avez eu une politique IAM qui refuse l'accès à [BasePathMapping](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonapigatewaymanagement.html#amazonapigatewaymanagement-resources-for-iam-policies)ou [ApiMapping](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonapigatewaymanagementv2.html#amazonapigatewaymanagementv2-resources-for-iam-policies). Lorsque vous activez les règles de routage d’un nom de domaine personnalisé, même si votre politique continue de refuser l’accès à `BasePathMapping` ou `ApiMapping`, celle-ci peut être utilisée pour accéder à `RoutingRule`. L’utilisateur peut ainsi modifier le comportement de routage de votre nom de domaine personnalisé.
Par exemple, si vous aviez une politique comme suit :
```
{
"Sid": "DenyCreatingApiMappings",
"Effect": "Deny",
"Action": "apigateway:POST",
"Resource": [
"arn:aws:apigateway:us-west-2::/domainnames/example.com/apimappings"
]
}
```
Si vous activez les règles de routage pour `example.com`, cette politique continuera à refuser l’accès à la création d’un `ApiMapping`, mais ne refusera pas l’accès à la création d’une `RoutingRule`.
Nous vous recommandons d’auditer les politiques IAM de votre compte. L’exemple de politique suivant refuse l’accès à la création d’un `ApiMapping`, d’un `BasePathMapping` et d’une `RoutingRule` :
```
{
"Sid": "DenyCreatingBasePathMappingsApiMappings",
"Effect": "Deny",
"Action": "apigateway:POST",
"Resource": [
"arn:aws:apigateway:us-west-2::/domainnames/example.com/basepathmappings",
"arn:aws:apigateway:us-west-2::/domainnames/example.com/apimappings"
]
},
{
"Sid": "DenyCreatingRoutingRules",
"Effect": "Deny",
"Action": "apigateway:CreateRoutingRule",
"Resource": [
"arn:aws:apigateway:us-west-2:111122223333:/domainnames/example.com/routingrules/*"
]
}
```
Après avoir vérifié que toutes vos politiques ont été mises à jour, vous pouvez mettre à jour les paramètres au niveau du compte de votre API afin d’activer les règles de routage pour une région.
Utilisez la commande [update-account](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-account.html) suivante pour mettre à jour les paramètres au niveau du compte de votre API pour une région :
```
aws apigateway update-account --patch-operations 'op=remove,path=/features,value=BlockedForRoutingRules' --region us-west-2
```
Après avoir mis à jour les paramètres au niveau du compte de votre API, vous pouvez modifier le mode de routage de votre nom de domaine personnalisé. Vous pouvez également continuer à utiliser des politiques IAM pour refuser l’accès aux `RoutingRules`, au `ApiMapping` ou au `BasePathMapping`.
# Utilisez les mappages d'API pour connecter les étapes d'API à un nom de domaine personnalisé pour REST APIs
Les mappages d’API vous permettent de connecter des étapes d’API à un nom de domaine personnalisé. Cela vous envoie du trafic APIs via votre nom de domaine personnalisé.
Un mappage d’API spécifie une API, une étape et éventuellement un chemin à utiliser pour le mappage. Par exemple, vous pouvez `https://api.example.com/orders` mapper le `production` stade d'une API.
Vous pouvez mapper les étapes d’API HTTP et REST au même nom de domaine personnalisé.
Avant de créer un mappage d’API, vous devez disposer d’une API, d’une étape et d’un nom de domaine personnalisé. Pour plus d’informations sur la création d’un nom de domaine personnalisé, consultez [Configuration d’un nom de domaine personnalisé régional dans API Gateway](apigateway-regional-api-custom-domain-create.md).
## Demandes entrantes adressées à votre nom de domaine personnalisé
Lorsque vous mappez un nom de domaine personnalisé à une étape de votre API, API Gateway supprime le chemin de base entrant. Cela supprime le chemin de base mappé depuis l'appel vers l'API. Par exemple, si votre mappage de chemin de base était destiné `https://api.example.com/orders/shop/5` à l'`test`étape et que vous utilisiez la requête suivante`https://api.example.com/orders/shop/5/hats`, API Gateway invoquerait la `/hats` ressource de l'`test`étape de votre API, et non la `orders/shop/5/hats` ressource.
## Mappage des demandes d'API
Ce qui suit explique comment API Gateway évalue les mappages d'API.
Vous pouvez créer un mappage d'API à l'aide de mappages à un seul niveau, tels qu'un mappage `orders` d'API depuis le `beta` stade d'une API et un mappage d'API depuis `shipping` le `alpha` stade d'une API. Pour les noms de domaine personnalisés régionaux dotés de la politique de sécurité TLS 1.2, API Gateway prend en charge les mappages d'API à plusieurs niveaux. Vous pouvez créer un mappage `orders/v1/items` d'API depuis le `alpha` stade d'une API et `orders/v2/items` vers le `beta` stade d'une API. Lorsque vous créez un mappage à plusieurs niveaux, API Gateway envoie des demandes au mappage d'API dont le chemin correspondant est le plus long.
Vous pouvez créer un mappage d'API vers le chemin vide`(none)`. Si aucun chemin ne correspond à la demande, API Gateway envoie la demande au chemin vide`(none)`.
Dans cet exemple, le nom de domaine personnalisé `https://api.example.com` possède les mappages d'API suivants.
| Cartographie des API | API sélectionnée |
| --- | --- |
| `(none)` | API 1 |
| `orders` | API 2 |
| `orders/v1/items` | API 3 |
| `orders/v2/items` | API 4 |
| `orders/v1/items/categories` | API 5 |
Le tableau suivant montre comment API Gateway applique les mappages d'API précédents à des exemples de demandes.
| Requête | API sélectionnée | Explication |
| --- | --- | --- |
| `https://api.example.com/orders` | API 2 | La demande correspond exactement à ce mappage d’API. |
| `https://api.example.com/orders/v1/items` | API 3 | La demande correspond exactement à ce mappage d’API. |
| `https://api.example.com/orders/v2/items` | API 4 | La demande correspond exactement à ce mappage d’API. |
| `https://api.example.com/orders/v1/items/123` | API 3 | API Gateway choisit le mappage d’API dont le chemin d’accès est le plus long. La présence de `123` à la fin de la demande n’affecte pas la sélection. Consultez [Demandes entrantes adressées à votre nom de domaine personnalisé](#rest-api-mappings-incoming-requests). |
| `https://api.example.com/orders/v2/items/categories/5` | API 5 | API Gateway choisit le mappage d’API dont le chemin d’accès est le plus long. |
| `https://api.example.com/customers` | API 1 | API Gateway utilise le mappage vide comme fourre-tout. |
| `https://api.example.com/ordersandmore` | API 2 | API Gateway choisit le mappage d’API doté du préfixe correspondant le plus long. Pour un nom de domaine personnalisé configuré avec des mappages à un seul niveau, tels que `https://api.example.com/orders` et `https://api.example.com/` uniquement, API Gateway choisirait `API 1`, car il n’y a pas de chemin correspondant avec `ordersandmore`. |
## Restrictions
+ Dans un mappage d'API, le nom de domaine personnalisé et le nom de domaine mappé APIs doivent se trouver dans le même AWS compte.
+ Les mappages d’API ne doivent contenir que des lettres, des chiffres et les caractères suivants : `$-_.+!*'()/`.
+ La longueur maximale du chemin d’un mappage d’API est de 300 caractères.
+ Vous pouvez disposer de 200 mappages d’API à plusieurs niveaux pour chaque nom de domaine. Cette limite n'inclut pas le mappage d'API avec des niveaux uniques, tels que`/prod`.
+ Vous ne pouvez APIs mapper HTTP à un nom de domaine personnalisé régional qu'avec la politique de sécurité TLS 1.2.
+ Vous ne pouvez pas WebSocket APIs mapper vers le même nom de domaine personnalisé qu'une API HTTP ou une API REST.
+ Après avoir créé vos mappages d’API, vous devez créer ou mettre à jour l’enregistrement de ressource de votre fournisseur DNS pour le mapper au point de terminaison de votre API.
+ Si vous créez un mappage d’API à plusieurs niveaux, API Gateway convertit tous les noms d’en-tête en minuscules.
## Création d’un mappage d’API
Pour créer un mappage d’API, vous devez d’abord créer un nom de domaine personnalisé, une API et une étape. Le mode de routage de votre nom de domaine personnalisé doit être défini sur `ROUTING_RULE_THEN_API_MAPPING` ou`API_MAPPING_ONLY`. Pour plus d'informations sur la façon de définir le mode de routage, consultez[Définition du mode de routage de votre nom de domaine personnalisé](set-routing-mode.md).
Pour des exemples AWS Serverless Application Model de modèles qui créent toutes les ressources, voir [Sessions avec SAM](https://github.com/aws-samples/sessions-with-aws-sam/tree/master/custom-domains) activé GitHub.
------
#### [ AWS Management Console ]
1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway)
1. Sélectionnez **Noms de domaine personnalisés** dans le volet de navigation principal.
1. Choisissez un nom de domaine personnalisé.
1. Dans l'onglet **Détails du routage**, choisissez **Configurer les mappages d'API**.
1. Saisissez l’**API**, l’**étape** et le **chemin** du mappage.
1. Choisissez **Enregistrer**.
------
#### [ AWS CLI ]
La commande suivante de la [create-api-mapping](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-api-mapping.html) crée un mappage d’API. Dans cet exemple, API Gateway envoie des demandes `api.example.com/v1/orders` à l’API et à l’étape spécifiés.
**Note**
Pour créer des mappages d’API à plusieurs niveaux, vous devez utiliser `apigatewayv2`.
```
aws apigatewayv2 create-api-mapping \
--domain-name api.example.com \
--api-mapping-key v1/orders \
--api-id a1b2c3d4 \
--stage test
```
------
#### [ CloudFormation ]
L' CloudFormation exemple suivant crée un mappage d'API.
**Note**
Pour créer des mappages d’API à plusieurs niveaux, vous devez utiliser `AWS::ApiGatewayV2`.
```
MyApiMapping:
Type: 'AWS::ApiGatewayV2::ApiMapping'
Properties:
DomainName: api.example.com
ApiMappingKey: 'orders/v2/items'
ApiId: !Ref MyApi
Stage: !Ref MyStage
```
------
# Types d'adresses IP pour les noms de domaine personnalisés dans API Gateway
Lorsque vous créez un nom de domaine personnalisé, vous spécifiez le type d'adresses IP qui peuvent appeler votre domaine. Vous pouvez choisir IPv4 de résoudre IPv4 les adresses pour appeler votre domaine, ou vous pouvez choisir DualStack pour autoriser IPv4 les deux IPv6 adresses à appeler votre domaine. Nous vous recommandons de définir le type d'adresse IP sur dualstack pour éviter l'épuisement de l'espace IP ou pour améliorer votre niveau de sécurité. [Pour plus d'informations sur les avantages d'un type d'adresse IP à double pile, reportez-vous IPv6 à la section suivante. AWS](https://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/internet-protocol-version-6.html)
Vous pouvez modifier le type d'adresse IP en mettant à jour la configuration du point de terminaison de votre nom de domaine.
## Considérations relatives aux types d'adresses IP
Les considérations suivantes peuvent avoir un impact sur votre utilisation des types d'adresses IP.
+ Le type d'adresse IP par défaut pour les noms de domaine personnalisés API Gateway destinés au public APIs est IPv4.
+ Les noms de domaine personnalisés privés ne peuvent avoir qu'un type d'adresse IP à double pile.
+ Il n'est pas nécessaire que le même type d'adresse IP soit associé à votre nom de domaine personnalisé pour tous APIs . Si vous désactivez votre point de terminaison d'API par défaut, cela peut affecter la manière dont les appelants peuvent appeler votre domaine.
## Modifier le type d'adresse IP d'un nom de domaine personnalisé
Vous pouvez modifier le type d'adresse IP en mettant à jour la configuration du point de terminaison du nom de domaine. Vous pouvez mettre à jour la configuration du point de terminaison à l'aide du AWS Management Console AWS CLI, du CloudFormation, ou d'un AWS SDK.
------
#### [ AWS Management Console ]
**Pour modifier le type d'adresse IP d'un nom de domaine personnalisé**
1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway)
1. Choisissez un nom de domaine public personnalisé.
1. Choisissez **Configuration du point de terminaison**.
1. Pour le type d'adresse IP, sélectionnez Dualstack **IPv4**ou **Dualstack**.
1. Choisissez **Enregistrer**.
------
#### [ AWS CLI ]
La [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-domain-name.html)commande suivante met à jour une API pour qu'elle ait un type d'adresse IP dualstack :
```
aws apigateway update-domain-name \
--domain-name dualstack.example.com \
--patch-operations "op='replace',path='/endpointConfiguration/ipAddressType',value='dualstack'"
```
Le résultat se présente comme suit :
```
{
"domainName": "dualstack.example.com",
"certificateUploadDate": "2025-02-04T14:46:10-08:00",
"regionalDomainName": "d-abcd1234.execute-api.us-east-1.amazonaws.com",
"regionalHostedZoneId": "Z3LQWSYCGH4ADY",
"regionalCertificateArn": "arn:aws:acm:us-east-1:111122223333:certificate/a1b2c3d4-5678-90ab-cdef",
"endpointConfiguration": {
"types": [
"REGIONAL"
],
"ipAddressType": "dualstack"
},
"domainNameStatus": "AVAILABLE",
"securityPolicy": "TLS_1_2",
"tags": {}
}
```
------
# Choisissez une politique de sécurité pour votre domaine personnalisé dans API Gateway
Une *politique de sécurité* est une combinaison prédéfinie d’une version minimale du protocole TLS et de suites de chiffrement offertes par API Gateway. Lorsque vos clients établissent une liaison TLS vers votre API ou nom de domaine personnalisé, la politique de sécurité applique la version TLS et la suite de chiffrement acceptées par API Gateway. Les politiques de sécurité protègent votre nom de domaine APIs et celui de vos noms de domaine personnalisés contre les problèmes de sécurité du réseau tels que la falsification et l'écoute entre un client et un serveur.
API Gateway prend en charge les politiques de sécurité existantes et les politiques de sécurité améliorées. `TLS_1_0`et `TLS_1_2` sont des politiques de sécurité héritées. Utilisez ces politiques de sécurité pour les charges de travail généralisées ou pour commencer à créer une API. Toute politique qui commence par `SecurityPolicy_` est une politique de sécurité renforcée. Utilisez-les pour les charges de travail régulées, la gouvernance avancée ou pour utiliser la cryptographie post-quantique. Lorsque vous utilisez une politique de sécurité améliorée, vous devez également définir le mode d’accès aux points de terminaison pour une meilleure gouvernance. Pour de plus amples informations, veuillez consulter [Mode d’accès au point de terminaison](apigateway-security-policies.md#apigateway-security-policies-endpoint-access-mode).
## Considérations
Voici quelques considérations relatives aux politiques de sécurité relatives aux noms de domaine personnalisés pour REST APIs dans API Gateway :
+ Vous ne pouvez pas activer le protocole TLS mutuel sur un nom de domaine qui utilise une politique de sécurité renforcée.
+ Vous ne pouvez pas associer une API HTTP à un nom de domaine qui utilise une politique de sécurité renforcée.
+ Si vous activez le mappage de chemins de base à plusieurs niveaux vers une API REST qui utilise une politique de sécurité renforcée, vous ne pouvez pas créer de mappage de chemin de base vers une API HTTP pour le même nom de domaine.
+ Votre API peut être mappée à un nom de domaine personnalisé avec une politique de sécurité différente de celle de votre API. Lorsque vous invoquez ce nom de domaine personnalisé, API Gateway utilise la politique de sécurité de l'API pour négocier le handshake TLS. La désactivation du point de terminaison de votre API par défaut peut avoir une incidence sur la manière dont les appelants peuvent invoquer votre API.
+ API Gateway prend en charge les politiques de sécurité pour tous APIs. Toutefois, vous ne pouvez choisir qu'une politique de sécurité pour REST APIs. API Gateway prend uniquement en charge la politique de `TLS_1_2` sécurité pour HTTP ou WebSocket APIs.
+ API Gateway ne prend pas en charge la mise à jour d'une politique de sécurité pour un nom de domaine comportant plusieurs types de points de terminaison. Si vous avez plusieurs types de point de terminaison pour un nom de domaine, supprimez l'un d'entre eux pour mettre à jour la politique de sécurité.
## Comment API Gateway applique les politiques de sécurité
L'exemple suivant montre comment API Gateway applique les politiques de sécurité en utilisant la politique de `SecurityPolicy_TLS13_1_3_2025_09` sécurité comme exemple.
La politique `SecurityPolicy_TLS13_1_3_2025_09` de sécurité accepte le trafic TLS 1.3 et rejette le trafic TLS 1.2 et TLS 1.0. Pour le trafic TLS 1.3, la politique de sécurité accepte les suites de chiffrement suivantes :
+ `TLS_AES_128_GCM_SHA256`
+ `TLS_AES_256_GCM_SHA384`
+ `TLS_CHACHA20_POLY1305_SHA256`
API Gateway n'accepte aucune autre suite de chiffrement. Par exemple, la politique de sécurité rejetterait tout trafic TLS 1.3 utilisant la suite de `AES128-SHA` chiffrement.
Pour contrôler le protocole TLS et les chiffrements utilisés par les clients pour accéder à votre API Gateway, vous pouvez utiliser les variables de `$context.cipherSuite` contexte `$context.tlsVersion` et dans vos journaux d'accès. Pour de plus amples informations, veuillez consulter [Surveillance des API REST dans API Gateway](rest-api-monitor.md).
Pour connaître les politiques de sécurité par défaut pour tous les noms de domaine REST APIs et personnalisés, voir[Politiques de sécurité par défaut](apigateway-security-policies-list.md#apigateway-security-policies-default). Pour connaître les politiques de sécurité prises en charge pour tous les noms de domaine REST APIs et personnalisés, consultez[Politiques de sécurité prises en charge](apigateway-security-policies-list.md).
## Modifier la politique de sécurité de votre nom de domaine personnalisé
Si vous modifiez votre politique de sécurité, la mise à jour prend environ 15 minutes. Vous pouvez surveiller votre nom `lastUpdateStatus` de domaine personnalisé. Au fur et à mesure que votre nom de domaine personnalisé `lastUpdateStatus` est mis à jour, il est `PENDING` et une fois terminé, il le sera`AVAILABLE`.
Lorsque vous utilisez une politique de sécurité commençant par`SecurityPolicy_`, vous devez également activer le mode d'accès aux terminaux. Pour de plus amples informations, veuillez consulter [Mode d’accès au point de terminaison](apigateway-security-policies.md#apigateway-security-policies-endpoint-access-mode).
------
#### [ AWS Management Console ]
**Pour modifier la politique de sécurité d'un nom de domaine personnalisé**
1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway)
1. Choisissez un nom de domaine personnalisé qui envoie le trafic vers REST APIs.
Assurez-vous qu'un seul type de point de terminaison est associé à votre nom de domaine personnalisé.
1. Choisissez **Paramètres de nom de domaine personnalisés**, puis sélectionnez **Modifier**.
1. Pour **Politique de sécurité**, sélectionnez une nouvelle stratégie.
1. Pour le **mode d'accès aux terminaux**, choisissez **Strict**.
1. Sélectionnez **Enregistrer les modifications**.
------
#### [ AWS CLI ]
La [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-domain-name.html)commande suivante met à jour un nom de domaine afin d'utiliser la politique `SecurityPolicy_TLS13_1_3_2025_09` de sécurité :
```
aws apigateway update-domain-name \
--domain-name example.com \
--patch-operations '[
{
"op": "replace",
"path": "/securityPolicy",
"value": "SecurityPolicy_TLS13_1_3_2025_09"
},
{
"op": "replace",
"path": "/endpointAccessMode",
"value": "STRICT"
}
]'
```
Le résultat se présente comme suit :
```
{
"domainName": "example.com",
"endpointConfiguration": {
"types": [ "REGIONAL" ],
"ipAddressType": "dualstack"
},
"regionalCertificateArn": "arn:aws:acm:us-west-2:111122223333:certificate/a1b2c3d4-5678-90ab-cdef",
"securityPolicy": "SecurityPolicy_TLS13_1_3_2025_09",
"endpointAccessMode": "STRICT"
}
```
------
## Informations sur HTTP APIs et WebSocket APIs
Pour plus d'informations sur le protocole HTTP APIs et WebSocket APIs, consultez [Politique de sécurité pour le protocole HTTP APIs dans API Gateway](http-api-ciphers.md) et[Politique de sécurité pour WebSocket APIs in API Gateway](websocket-api-ciphers.md).
# Désactiver le point de terminaison par défaut pour REST APIs
Par défaut, les clients peuvent appeler votre API en utilisant le point de terminaison `execute-api` généré par API Gateway pour votre API. Pour vous assurer que les clients peuvent accéder à votre API en utilisant uniquement un nom de domaine personnalisé, désactivez le point de terminaison par défaut `execute-api`. Les clients peuvent toujours se connecter à votre point de terminaison par défaut, mais ils recevront un code de statut `403 Forbidden`. La désactivation du point de terminaison par défaut affecte toutes les étapes de l’API. Ce paramètre prend effet lorsque vous mettez à jour un paramètre d’une étape, par exemple lorsque vous mettez à jour le déploiement de l’étape.
La procédure suivante explique comment désactiver le point de terminaison par défaut pour une API REST.
------
#### [ AWS Management Console ]
1. Connectez-vous à la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway.](https://console.aws.amazon.com/apigateway)
1. Choisissez une API REST.
1. Dans le panneau de navigation principal, choisissez **Paramètres de l’API**.
1. Choisissez une API.
1. Dans l’onglet **Détails de l’API**, choisissez **Modifier**.
1. Pour **Point de terminaison par défaut**, sélectionnez **Inactif**.
1. Sélectionnez **Enregistrer les modifications**.
1. Dans le volet de navigation principal, choisissez **Ressources**.
1. Sélectionnez **Deploy API (Déployer une API)**.
1. Redéployez votre API sur une étape ou mettez à jour un paramètre d’une étape pour que la mise à jour prenne effet.
------
#### [ AWS CLI ]
La [update-rest-api](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-rest-api.html)commande suivante désactive le point de terminaison par défaut :
```
aws apigateway update-rest-api \
--rest-api-id abcdef123 \
--patch-operations op=replace,path=/disableExecuteApiEndpoint,value='True'
```
Après avoir désactivé le point de terminaison par défaut, vous devez déployer votre API pour que la modification prenne effet.
La commande [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-deployment.html) suivante crée un déploiement et l’associe à une étape :
```
aws apigateway create-deployment \
--rest-api-id abcdef123 \
--stage-name dev
```
------
# Configuration de surveillances de l’état personnalisées pour le basculement DNS d’une API API Gateway
Vous pouvez utiliser les contrôles de santé d'Amazon Route 53 pour contrôler le basculement du DNS entre une API API Gateway située dans une région principale Région AWS et une API située dans une région secondaire. Cela peut aider à atténuer les impacts en cas de problème régional. Si vous utilisez un domaine personnalisé, vous pouvez effectuer un basculement sans demander aux clients de changer de point de terminaison d’API.
Lorsque vous choisissez [Evaluate Target Health](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AliasTarget.html#Route53-Type-AliasTarget-EvaluateTargetHealth>Evaluate Target Health) (Évaluer l’intégrité de la cible) pour un enregistrement d’alias, ces enregistrements échouent uniquement lorsque le service API Gateway est indisponible dans la région. Dans certains cas, votre propre API Gateway APIs peut être interrompue avant cette date. Pour contrôler directement le basculement du DNS, configurez des contrôles de santé Route 53 personnalisés pour votre API Gateway APIs. Dans cet exemple, vous utilisez une CloudWatch alarme qui aide les opérateurs à contrôler le basculement du DNS. Pour plus d'exemples et d'autres considérations lors de la configuration du basculement, consultez les sections [Création de mécanismes de reprise après sinistre à l'aide de Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/) et [Réalisation de contrôles de santé de Route 53 sur des ressources privées dans un VPC AWS Lambda](https://aws.amazon.com/blogs/networking-and-content-delivery/performing-route-53-health-checks-on-private-resources-in-a-vpc-with-aws-lambda-and-amazon-cloudwatch/) avec et. CloudWatch
**Topics**
+ [
## Prérequis
](#dns-failover-prereqs)
+ [
## Étape 1 : configurer les ressources
](#dns-failover-intial-setup)
+ [
## Étape 2 : initier le basculement vers la région secondaire
](#dns-failover-initiate)
+ [
## Étape 3 : tester le basculement
](#dns-failover-test)
+ [
## Étape 4 : retourner à la région principale
](#dns-failover-return)
+ [
## Prochaines étapes : personnalisez et testez régulièrement
](#dns-failover-next-steps)
## Prérequis
Pour effectuer cette procédure, vous devez créer et configurer les ressources suivantes :
+ Nom de domaine qui vous appartient.
+ Un certificat ACM pour ce nom de domaine en deux Régions AWS. Pour plus d’informations, consultez [Prérequis concernant les noms de domaine personnalisés](how-to-custom-domains.md#how-to-custom-domains-prerequisites).
+ Zone hébergée Route 53 pour votre nom de domaine. Pour obtenir plus d’informations, consultez [Working with hosted zones](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-working-with.html) (Utiliser des zones hébergées) dans le Guide du développeur Amazon Route 53.
Pour plus d’informations sur la manière de créer des enregistrements DNS de basculement Route 53 pour les noms de domaine, consultez [Choix d’une politique de routage](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) dans le Guide du développeur Amazon Route 53. Pour plus d'informations sur la surveillance d'une CloudWatch alarme, consultez la section [Surveillance CloudWatch d'une alarme](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-values.html#health-checks-creating-values-cloudwatch) dans le manuel Amazon Route 53 Developer Guide.
## Étape 1 : configurer les ressources
Dans cet exemple, vous créez les ressources suivantes pour configurer le basculement DNS pour votre nom de domaine :
+ API Gateway APIs en deux Régions AWS
+ Noms de domaine personnalisés API Gateway portant le même nom sur deux Régions AWS
+ Mappages d'API Gateway qui connectent votre API Gateway APIs aux noms de domaine personnalisés
+ Enregistrements DNS de basculement de Route 53 pour les noms de domaine
+ Une CloudWatch alarme dans la région secondaire
+ Un bilan de santé de la Route 53 basé sur l' CloudWatch alarme de la région secondaire
Tout d’abord, vérifiez que vous disposez de toutes les ressources nécessaires dans les régions principale et secondaire. La région secondaire doit contenir l’alarme et la surveillance de l’état. De cette façon, vous ne dépendez pas de la région principale pour effectuer le basculement. Pour des exemples CloudFormation de modèles qui créent ces ressources, voir [samples/primary.zip](samples/primary.zip)et [samples/secondary.zip](samples/secondary.zip).
**Important**
Avant le basculement vers la région secondaire, vérifiiez que toutes les ressources nécessaires sont disponibles. Sinon, votre API ne sera pas prête pour le trafic dans la région secondaire.
## Étape 2 : initier le basculement vers la région secondaire
Dans l'exemple suivant, la région de secours reçoit une CloudWatch métrique et initie le basculement. Nous utilisons une métrique personnalisée qui nécessite l’intervention de l’opérateur pour déclencher le basculement.
```
aws cloudwatch put-metric-data \
--metric-name Failover \
--namespace HealthCheck \
--unit Count \
--value 1 \
--region us-west-1
```
Remplacez les données métriques par les données correspondantes pour l' CloudWatch alarme que vous avez configurée.
## Étape 3 : tester le basculement
Appelez votre API et vérifiez que vous obtenez une réponse de la région secondaire. Si vous avez utilisé les modèles d’exemple à l’étape 1, la réponse passe de `{"message": "Hello from the primary Region!"}` à `{"message": "Hello from the secondary Region!"}` après le basculement.
```
curl https://my-api.example.com
{"message": "Hello from the secondary Region!"}
```
## Étape 4 : retourner à la région principale
Pour revenir à la région principale, envoyez une CloudWatch métrique qui permet de valider le bilan de santé.
```
aws cloudwatch put-metric-data \
--metric-name Failover \
--namespace HealthCheck \
--unit Count \
--value 0 \
--region us-west-1
```
Remplacez les données métriques par les données correspondantes pour l' CloudWatch alarme que vous avez configurée.
Appelez votre API et vérifiez que vous obtenez une réponse de la région principale. Si vous avez utilisé les modèles d’exemple à l’étape 1, la réponse passe de `{"message": "Hello from the secondary Region!"}` à `{"message": "Hello from the primary Region!"}`.
```
curl https://my-api.example.com
{"message": "Hello from the primary Region!"}
```
## Prochaines étapes : personnalisez et testez régulièrement
Cet exemple montre une façon de configurer le basculement DNS. Vous pouvez utiliser une variété de CloudWatch métriques ou de points de terminaison HTTP pour les contrôles de santé qui gèrent le basculement. Testez régulièrement vos mécanismes de basculement pour vous assurer qu’ils fonctionnent comme prévu et que les opérateurs sont familiarisés avec vos procédures de basculement.