# Nombre de dominio personalizado para las API de REST públicas en API Gateway
Los*nombres de dominio personalizados* son direcciones URL más sencillas e intuitivas que puede proporcionar a los usuarios de la API.
Después de implementar la API, usted (y sus clientes) puede invocar la API utilizando la URL base predeterminada con el siguiente formato:
```
https://api-id.execute-api.region.amazonaws.com/stage
```
donde *api-id* lo genera API Gateway, *region* es la región de AWS y *stage* lo especifica usted al implementar la API.
La parte del nombre de host de la URL, `api-id.execute-api.region.amazonaws.com`, hace referencia a un punto de conexión de la API. El punto de conexión de la API predeterminado se genera aleatoriamente y no es muy descriptivo.
Con los nombres de dominio personalizados, puede configurar el nombre de host de la API y elegir una ruta base (por ejemplo, `myservice`) para asignarle una URL alternativa. Por ejemplo, una URL base de la API más simple puede ser:
```
https://api.example.com/myservice
```
**nota**
Para obtener más información sobre los nombres de dominio personalizados para API privadas, consulte [Nombres de dominio personalizados para API privadas en API Gateway](apigateway-private-custom-domains.md).
## Consideraciones
Es posible que las siguientes consideraciones afecten al uso de un nombre de dominio personalizado:
+ Puede deshabilitar el punto de conexión predeterminado para la API. Los clientes pueden seguir conectándose al punto de conexión predeterminado, pero recibirán un código de estado `403 Forbidden`.
+ Un nombre de dominio personalizado regional se puede asociar con las API de REST y las API de HTTP. Puede utilizar las [API de API Gateway versión 2](https://docs.aws.amazon.com/apigatewayv2/latest/api-reference/api-reference.html) para crear y administrar nombres de dominio personalizados regionales para las API de REST.
+ Un nombre de dominio personalizado debe ser único en una región en todas las cuentas de AWS.
+ Puede migrar su nombre de dominio personalizado entre puntos de conexión optimizados para bordes y regionales, pero no puede migrar un dominio personalizado público a un nombre de dominio personalizado privado.
+ Debe crear o actualizar el registro de recursos del proveedor de DNS para asignarlo al punto de conexión de la API. Si no se realiza este mapeo, las solicitudes de API vinculadas al nombre de dominio personalizado no pueden llegar a API Gateway.
+ Puede admitir un número casi infinito de nombres de dominio sin exceder el límite predeterminado mediante el uso de un certificado comodín. Para obtener más información, consulte [Nombres de dominio personalizados comodín](#wildcard-custom-domain-names).
+ Puede elegir una política de seguridad para el nombre de dominio personalizado. Para obtener más información, consulte [Elección de una política de seguridad para el dominio personalizado en API Gateway](apigateway-custom-domain-tls-version.md).
+ Para configurar asignaciones de la API con varios niveles, debe usar un nombre de dominio personalizado regional y usar la política de seguridad de TLS 1.2.
## Requisitos previos de los nombres de dominio personalizados
A continuación se enumeran los requisitos previos para crear un nombre de dominio personalizado público o privado. Para obtener más información sobre los nombres de dominio personalizados para API privadas, consulte [Nombres de dominio personalizados para API privadas en API Gateway](apigateway-private-custom-domains.md).
### Registrar un nombre de dominio
Debe disponer de un nombre de dominio de Internet registrado para poder crear nombres de dominio personalizados para sus API. Puede registrar su nombre de dominio de Internet con [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/) o un registrador de dominios de terceros de su elección. Su nombre de dominio personalizado puede ser el nombre de un subdominio o el dominio raíz (lo que recibe el nombre de “vértice de zona”) de un dominio de Internet registrado.
El nombre de dominio debe seguir la especificación [RFC 1035](https://tools.ietf.org/html/rfc1035#section-2.3.4) y puede tener un máximo de 63 octetos por etiqueta y 255 octetos en total.
### Especificación del certificado para el nombre de dominio personalizado
Antes de configurar un nombre de dominio personalizado para una API, debe disponer de un certificado SSL/TLS listo en ACM. Si ACM no está disponible en la región de AWS donde va a crear su nombre de dominio personalizado, debe importar un certificado en API Gateway en esa región.
Para importar un certificado SSL/TLS, debe proporcionar el cuerpo del certificado SSL/TLS con formato PEM, su clave privada y la cadena de certificados para el nombre de dominio personalizado.
Los certificados almacenados en ACM se identifican mediante su ARN. Con los certificados emitidos por ACM no tiene que preocuparse de si se exponen datos del certificado confidenciales, como la clave privada. Para utilizar un certificado administrado por AWS para un nombre de dominio, solo tiene que hacer referencia a su ARN.
Si la aplicación utiliza asignación de certificados, también conocido como asignación SSL, para asignar un certificado de ACM, es posible que la aplicación no se pueda conectar al dominio una vez que AWS renueva el certificado. Para obtener más información, consulte [Problemas de asignación de certificados](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-pinning.html) en la *Guía del usuario de AWS Certificate Manager*.
## Nombres de dominio personalizados comodín
Con los nombres de dominio personalizados comodín, puede admitir un número casi infinito de nombres de dominio sin exceder el [límite predeterminado](limits.md). Por ejemplo, puede dar a cada uno de los clientes su propio nombre de dominio, `customername.example.com`.
Para crear un nombre de dominio personalizado comodín, especifique un comodín (`*`) como primer subdominio de un dominio personalizado que represente todos los subdominios posibles de un dominio raíz.
Por ejemplo, el nombre de dominio personalizado comodín `*.example.com` produce subdominios como `a.example.com`, `b.example.com` y `c.example.com`. Cuando crea el nombre de dominio personalizado comodín, todos los subdominios se enrutan por el modo de enrutamiento del nombre de dominio comodín. Para enrutar subdominios a diferentes API, puede hacer una de las siguientes acciones:
+ Utilizar reglas de enrutamiento para enrutar las solicitudes entrantes a `*.example.com` a diferentes API de REST de destino mediante el encabezado `Host`. Para obtener más información, consulte [Ejemplo 4: reglas de enrutamiento para nombres de dominio comodín](rest-api-routing-rules-examples.md#rest-api-routing-rules-examples-rule-for-wildcard-domains).
+ Crear un nombre de dominio para cualquier subdominio que desee enrutar a un punto de conexión diferente. En una misma cuenta de AWS, puede tener `*.example.com` y `a.example.com`.
Puede utilizar las variables de contexto `$context.domainName` y `$context.domainPrefix` para determinar el nombre de dominio que un cliente utilizó para llamar a la API. Para obtener más información acerca de las variables de contexto, consulte [Variables para transformaciones de datos para API Gateway](api-gateway-mapping-template-reference.md).
Para crear un nombre de dominio personalizado comodín, debe proporcionar un certificado emitido por ACM que se haya validado utilizando el método DNS o de validación de correo electrónico.
**nota**
No se puede crear un nombre de dominio personalizado comodín si una cuenta de AWS diferente ha creado un nombre de dominio personalizado que entra en conflicto con el nombre de dominio personalizado comodín. Por ejemplo, si la cuenta A ha creado `a.example.com`, la cuenta B no puede crear el nombre de dominio personalizado comodín `*.example.com`.
Si la cuenta A y la cuenta B comparten un propietario, puede contactar con el [Centro de soporte de AWS](https://console.aws.amazon.com/support/home#/) para solicitar una excepción.
## Siguientes pasos para nombres de dominio personalizados
A continuación, se muestran los siguientes pasos para los nombres de dominio personalizados.
**Siguientes pasos**
+ Para obtener información sobre cómo configurar su certificado SSL/TLS, consulte [Preparación de certificados en AWS Certificate Manager](how-to-specify-certificate-for-custom-domain-name.md).
+ Para obtener información sobre cómo crear un dominio personalizado regional, consulte [Configuración de un nombre de dominio personalizado regional en API Gateway](apigateway-regional-api-custom-domain-create.md).
+ Para obtener información sobre cómo crear un nombre de dominio personalizado optimizado para la periferia, consulte [Configuración de un nombre de dominio personalizado optimizado para la periferia para en API Gateway](how-to-edge-optimized-custom-domain-name.md).
+ Para obtener información sobre cómo migrar entre nombres de dominio personalizados regionales y optimizados para la periferia, consulte [Migración de un nombre de dominio personalizado a otro tipo punto de conexión de API en API Gateway](apigateway-regional-api-custom-domain-migrate.md).
+ Para obtener información sobre cómo conectar etapas de la API a un nombre de dominio personalizado, consulte [Envío de tráfico a las API a través del nombre de dominio personalizado en API Gateway](rest-api-routing-mode.md).
+ Para obtener información sobre cómo elegir una política de seguridad para el nombre de dominio personalizado, consulte [Elección de una política de seguridad para el dominio personalizado en API Gateway](apigateway-custom-domain-tls-version.md).
+ Para obtener información sobre cómo desactivar el punto de conexión predeterminado para su nombre de dominio personalizado, consulte [Deshabilitación del punto de conexión predeterminado para las API de REST](rest-api-disable-default-endpoint.md).
+ Para obtener información sobre cómo utilizar las comprobaciones de estado de Route 53 para controlar la conmutación por error de DNS desde una API de API Gateway, consulte [Configuración de las comprobaciones de estado personalizadas para la conmutación por error de DNS para una API de API Gateway](dns-failover.md).
Si es la primera vez que crea un nombre de dominio personalizado, le recomendamos que comience con [Preparación de certificados en AWS Certificate Manager](how-to-specify-certificate-for-custom-domain-name.md), para especificar el certificado, y, después, [Configuración de un nombre de dominio personalizado regional en API Gateway](apigateway-regional-api-custom-domain-create.md), para crear un nombre de dominio personalizado regional.
# Preparación de certificados en AWS Certificate Manager
Antes de configurar un nombre de dominio personalizado para una API, debe disponer de un certificado SSL/TLS listo en AWS Certificate Manager. Para obtener más información, consulte la [Guía del usuario de AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/).
## Consideraciones
Las siguientes son consideraciones para su certificado SSL/TLS.
+ Si crea un nombre de dominio personalizado optimizado para la periferia, API Gateway usa CloudFront para admitir certificados para nombres de dominio personalizados. Por tanto, los requisitos y las restricciones del certificado SSL/TLS de un nombre de dominio personalizado los dicta [CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html). Por ejemplo, el tamaño máximo de la clave pública es 2048 y la clave privada puede ser 1024, 2048 y 4096. El tamaño de la clave pública se determina en función de la entidad de certificación que utilice. Pida a su entidad de certificación que devuelva claves de un tamaño diferente de la longitud predeterminada. Para obtener más información, consulte [Proteger el acceso a los objetos](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html) y [Creación de URL y cookies firmadas](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-trusted-signers.html).
+ Si crea un nombre de dominio personalizado regional, el tamaño máximo de la clave pública es 2048.
+ Para usar un certificado de ACM con un nombre de dominio personalizado regional, debe solicitar o importar el certificado en la misma región que la API. El certificado debe cubrir el nombre de dominio personalizado.
+ Si desea utilizar un certificado de ACM con un nombre de dominio personalizado optimizado para la periferia, debe solicitar o importar el certificado en la región Este de EE. UU. (Norte de Virginia) - `us-east-1`.
+ Debe tener un nombre de dominio registrado, como `example.com`. Puede utilizar [Amazon Route 53 ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/) o un registrador de dominios de terceros acreditado. Para obtener una lista de registradores, consulte [Accredited Registrar Directory](https://www.icann.org/en/accredited-registrars) en el sitio web de ICANN.
## Creación o importación de un certificado SSL/TLS en ACM
En los siguientes procedimientos se muestra cómo crear o importar un certificado SSL/TLS para un nombre de dominio.
------
#### [ To request a certificate provided by ACM for a domain name ]
1. Inicie sesión en la [consola de AWS Certificate Manager](https://console.aws.amazon.com/acm).
1. Elija **Request a certificate (Solicitar un certificado)**.
1. En **Tipo de certificado**, elija **Solicitar un certificado público**.
1. Elija **Siguiente**.
1. En **Nombre de dominio completo**, introduzca un nombre de dominio para la API, por ejemplo, `api.example.com`.
1. También puede seleccionar **Add another name to this certificate (Añadir otro nombre a este certificado)**.
1. En **Método de validación**, elija un método para validar la propiedad del dominio.
1. En **Algoritmo clave**, elija un algoritmo de cifrado.
1. Seleccione **Solicitar**.
1. Para que una solicitud sea válida, un propietario registrado del dominio de Internet debe autorizar la solicitud para que ACM emita el certificado. Si utiliza Route 53 para administrar sus registros de DNS públicos, puede actualizar los registros directamente a través de la consola de ACM.
------
#### [ To import into ACM a certificate for a domain name ]
1. Obtenga un certificado SSL/TLS codificado en PEM para su nombre de dominio personalizado de una entidad de certificación. Para obtener una lista parcial de entidades de certificación, consulte [Mozilla Included CA List](https://ccadb.my.salesforce-sites.com/mozilla/IncludedCACertificateReport).
1. Genere una clave privada para el certificado y guarde el resultado en un archivo, utilizando el kit de herramientas de [OpenSSL](https://www.openssl.org) en el sitio web de OpenSSL:
```
openssl genrsa -out private-key-file 2048
```
1. Genere una solicitud de firma de certificado (CSR) con la clave privada generada anteriormente, utilizando OpenSSL:
```
openssl req -new -sha256 -key private-key-file -out CSR-file
```
1. Envíe la CSR a la entidad de certificación y guarde el certificado resultante.
1. Descargue la cadena de certificados de la entidad de certificación.
**nota**
Si obtiene la clave privada de otra forma y la clave está cifrada, puede utilizar el siguiente comando para descifrar la clave antes de enviarla a API Gateway para que configure un nombre de dominio personalizado.
```
openssl pkcs8 -topk8 -inform pem -in MyEncryptedKey.pem -outform pem -nocrypt -out MyDecryptedKey.pem
```
1. Cargue el certificado en AWS Certificate Manager:
1. Inicie sesión en la [consola de AWS Certificate Manager](https://console.aws.amazon.com/acm).
1. Seleccione **Import a certificate**.
1. En **Cuerpo del certificado**, introduzca o pegue el cuerpo del certificado del servidor con formato PEM de su entidad de certificación. A continuación se muestra un ejemplo abreviado de dicho certificado.
```
-----BEGIN CERTIFICATE-----
EXAMPLECA+KgAwIBAgIQJ1XxJ8Pl++gOfQtj0IBoqDANBgkqhkiG9w0BAQUFADBB
...
az8Cg1aicxLBQ7EaWIhhgEXAMPLE
-----END CERTIFICATE-----
```
1. En **Clave privada del certificado**, introduzca o pegue la clave privada del certificado con formato PEM. A continuación se muestra un ejemplo abreviado de dicha clave.
```
-----BEGIN RSA PRIVATE KEY-----
EXAMPLEBAAKCAQEA2Qb3LDHD7StY7Wj6U2/opV6Xu37qUCCkeDWhwpZMYJ9/nETO
...
1qGvJ3u04vdnzaYN5WoyN5LFckrlA71+CszD1CGSqbVDWEXAMPLE
-----END RSA PRIVATE KEY-----
```
1. En **Cadena de certificados**, introduzca o pegue los certificados intermedios con formato PEM y, opcionalmente, el certificado raíz, uno detrás del otro sin líneas en blanco. Si incluye el certificado raíz, la cadena de certificados debe empezar con los certificados intermedios y terminar con el certificado raíz. Utilice los certificados intermedios proporcionados por la entidad de certificación. No incluya certificados intermedios que no estén en la cadena de la ruta de confianza. A continuación se muestra un ejemplo abreviado.
```
-----BEGIN CERTIFICATE-----
EXAMPLECA4ugAwIBAgIQWrYdrB5NogYUx1U9Pamy3DANBgkqhkiG9w0BAQUFADCB
...
8/ifBlIK3se2e4/hEfcEejX/arxbx1BJCHBvlEPNnsdw8EXAMPLE
-----END CERTIFICATE-----
```
Este es otro ejemplo.
```
-----BEGIN CERTIFICATE-----
Intermediate certificate 2
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Intermediate certificate 1
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Optional: Root certificate
-----END CERTIFICATE-----
```
1. Seleccione **Siguiente** y de nuevo **Siguiente**.
------
Una vez que el certificado se haya creado o importado correctamente, anote el ARN del certificado. Lo necesitará cuando configure el nombre de dominio personalizado.
# Configuración de un nombre de dominio personalizado regional en API Gateway
Utilice un nombre de dominio personalizado regional para crear una URL base de la API más descriptiva. Con un nombre de dominio personalizado regional, puede asignar etapas de la API de HTTP y REST al mismo nombre de dominio personalizado y usar la autenticación TLS mutua.
## Consideraciones
A continuación, se muestran consideraciones para el nombre de dominio personalizado regional:
+ Debe proporcionar un certificado de ACM específico de la región. Este certificado debe estar en la misma región que la API. Para obtener más información sobre cómo crear o cargar un certificado de nombre de dominio personalizado, consulte [Preparación de certificados en AWS Certificate Manager](how-to-specify-certificate-for-custom-domain-name.md).
+ Cuando crea un nombre de dominio personalizado regional (o migra uno) con un certificado de ACM, API Gateway crea un rol vinculado al servicio en su cuenta. El rol vinculado al servicio es necesario para asociar el certificado de ACM a su punto de conexión regional. El rol se denomina **AWSServiceRoleForAPIGateway** y llevará asociada la política administrada **APIGatewayServiceRolePolicy**. Para obtener más información acerca de cómo usar el rol vinculado al servicio, consulte [Uso de roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html).
+ Después de crear el nombre de dominio personalizado regional, deberá crear un registro DNS para que el nombre de dominio personalizado apunte al nombre de dominio regional. Esto permite que el tráfico que se dirige al nombre de dominio personalizado se enrute al nombre de host regional de la API.
El registro DNS puede ser el registro CNAME o un registro de alias A. Si utiliza Route 53 como proveedor de DNS, cree un registro de alias A. Si utiliza un proveedor de DNS externo, utilice un registro CNAME. Si utiliza un registro CNAME y crea un punto de conexión de VPC de interfaz de API Gateway con el DNS privado habilitado para una API privada, no podrá resolver el nombre de dominio personalizado en la VPC que aloja la API privada.
## Creación de un nombre de dominio personalizado regional
En el siguiente procedimiento se muestra cómo crear un nombre de dominio personalizado regional. Una vez completado este procedimiento, cree una regla de enrutamiento para enrutar las etapas de la API al nombre de dominio personalizado.
------
#### [ Consola de administración de AWS ]
1. Inicie sesión en la consola de API Gateway en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Elija **Custom domain names (Nombres de dominios personalizados)** en el panel de navegación principal.
1. Seleccione **Create (Crear)**.
1. En **Nombre de dominio**, escriba un nombre de dominio.
1. En **Modo de enrutamiento**, elija **Solo reglas de enrutamiento**.
En este modo de enrutamiento, solo puede enviar tráfico desde el nombre de dominio personalizado a las API mediante reglas de enrutamiento. Para obtener más información, consulte [Envío de tráfico a las API a través del nombre de dominio personalizado en API Gateway](rest-api-routing-mode.md).
1. En **Versión mínima de TLS**, seleccione una versión.
1. En **Configuración de punto de conexión**, para **Tipo de punto de conexión de la API**, elija **Regional**.
1. Elija un certificado de ACM. El certificado debe estar en la misma región que la API.
1. Seleccione **Create (Crear)**.
------
#### [ AWS CLI ]
El siguiente comando [create-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-domain-name.html) permite crear un nombre de dominio personalizado:
```
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
```
El resultado será similar al siguiente:
```
{
"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"
]
}
```
El valor de propiedad `DomainNameConfigurations` devuelve el nombre de host de la API regional. Debe crear un registro DNS para apuntar su nombre de dominio personalizado a este nombre de dominio regional. Esto permite que el tráfico que se dirige al nombre de dominio personalizado se enrute al nombre de host de esta API regional.
------
## Creación de una regla de enrutamiento para el nombre de dominio personalizado regional
Después de crear el nombre de dominio personalizado, configure cómo se enruta el tráfico desde el nombre de dominio personalizado a las API. Dado que establece el modo de enrutamiento en `ROUTING_RULE_ONLY`, utiliza reglas de enrutamiento para enrutar las solicitudes entrantes al nombre de dominio personalizado hacia las API.
En este ejemplo, crea una regla catch-all que enruta todas las solicitudes entrantes al nombre de dominio personalizado a una etapa de la API. También puede configurar reglas de enrutamiento basadas en diferentes condiciones de encabezado y ruta. Para obtener más información, consulte [Reglas de enrutamiento para conectar las etapas de API a un nombre de dominio personalizado para las API de REST](rest-api-routing-rules.md).
------
#### [ Consola de administración de AWS ]
1. Inicie sesión en la consola de API Gateway en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Elija un nombre de dominio personalizado.
1. En la pestaña **Detalles de enrutamiento**, elija **Agregar regla de enrutamiento**.
1. Elija **Agregar una nueva condición** para agregar una nueva condición.
1. Mantenga esta regla sin condiciones. Esto enruta todas las solicitudes al nombre de dominio personalizado a la API de destino y etapa de destino.
1. En **Acción**, utilice la lista desplegable para seleccionar la API de destino y la etapa de destino.
1. Elija **Siguiente**.
1. En el campo de prioridad, introduzca **100**.
API Gateway evalúa las reglas en orden de prioridad, del valor más bajo al más alto. Dado que se trata de una regla catch-all, utilice una prioridad alta para que API Gateway pueda realizar la coincidencia primero con cualquier regla adicional que cree.
1. Elija **Crear regla de enrutamiento**.
------
#### [ AWS CLI ]
El siguiente comando `create-routing-rule` crea una regla de enrutamiento catch-all:
```
aws apigatewayv2 create-routing-rule \
--domain-name 'regional.example.com' \
--priority 100 \
--conditions \
--actions '[{
"InvokeApi": {
"ApiId": "a1b2c3",
"Stage": "prod"
}
}]'
```
------
Puede cambiar el modo de enrutamiento y crear nuevas reglas en cualquier momento. Para obtener más información, consulte [Envío de tráfico a las API a través del nombre de dominio personalizado en API Gateway](rest-api-routing-mode.md).
## Creación de un registro de DNS para el nombre de dominio personalizado regional
Después de crear el nombre de dominio personalizado y las asignaciones de rutas base, debe crear un registro DNS para que el nombre de dominio personalizado apunte al nombre de dominio regional que se acaba de crear.
------
#### [ Consola de administración de AWS ]
Para usar la Consola de administración de AWS, siga la documentación de Route 53 sobre la [configuración de Route 53 para enrutar el tráfico a API Gateway](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-api-gateway.html).
------
#### [ AWS CLI ]
Para configurar sus registros de DNS para asignar el nombre de dominio regional personalizado al nombre de host del ID de zona alojada designado, cree primero un archivo JSON que contenga la configuración a fin de establecer un registro de DNS para el nombre de dominio regional.
En el siguiente `setup-dns-record.json` se muestra cómo crear un registro `A` de DNS para asignar un nombre de dominio personalizado regional (`regional.example.com`) a su nombre de host regional (`d-numh1z56v6.execute-api.us-west-2.amazonaws.com`) aprovisionado como parte de la creación de nombres de dominio personalizados. Las propiedades `DNSName` y `HostedZoneId` de `AliasTarget` pueden tener los valores `regionalDomainName` y `regionalHostedZoneId`, respectivamente, del nombre de dominio personalizado. También puede obtener los ID de zona alojada regionales de Route 53 en [Puntos de conexión y cuotas de Amazon API Gateway](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
}
}
}
]
}
```
El siguiente comando [change-resource-record-sets](https://docs.aws.amazon.com/cli/latest/reference/route53/change-resource-record-sets.html) permite crear un registro de DNS para el nombre de dominio personalizado regional:
```
aws route53 change-resource-record-sets \
--hosted-zone-id Z2OJLYMUO9EFXC \
--change-batch file://path/to/your/setup-dns-record.json
```
Reemplace `hosted-zone-id` por el ID de zona alojada de Route 53 del conjunto de registros de DNS de la cuenta. El valor del parámetro `change-batch` apunta a un archivo JSON (*setup-dns-record.json*) de una carpeta (*ruta/a/su*).
------
# Configuración de un nombre de dominio personalizado optimizado para la periferia para en API Gateway
Cuando crea un nombre de dominio personalizado para una API optimizada para la periferia, API Gateway configura una distribución de Amazon CloudFront y un registro de DNS para asignar el nombre de dominio de API al nombre de dominio de distribución de CloudFront. Las solicitudes para la API se redirigen a API Gateway a través de la distribución de CloudFront asignada. Este mapeo es para solicitudes de API que estén enlazadas para que el nombre de dominio personalizado se dirija a API Gateway a través de la distribución de CloudFront asignada.
## Consideraciones
A continuación, se muestran las siguientes consideraciones para el nombre de dominio personalizado optimizado para la periferia:
+ Para configurar un nombre de dominio personalizado optimizado para bordes o para actualizar su certificado, debe tener permiso para actualizar las distribuciones de CloudFront.
Se requieren los siguientes permisos para actualizar las distribuciones de CloudFront:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCloudFrontUpdateDistribution",
"Effect": "Allow",
"Action": [
"cloudfront:updateDistribution"
],
"Resource": [
"*"
]
}
]
}
```
------
+ Debe solicitar o importar un certificado para su nombre de dominio personalizado optimizado para la periferia en la región Este de EE. UU. (Norte de Virginia) - `us-east-1`.
+ La distribución de CloudFront que ha creado API Gateway es propiedad de un cuenta específica de la región afiliada a API Gateway. Cuando realice un seguimiento de las operaciones para crear y actualizar esta distribución de CloudFront en CloudTrail, deberá utilizar este ID de cuenta de API Gateway. Para obtener más información, consulte [Registro de la creación del nombre de dominio personalizado en CloudTrail](#how-to-custom-domain-log-cloudfront-distribution-update-in-cloudtrail).
+ API Gateway admite nombres de dominio personalizados optimizados para bordes mediante la indicación de nombre de servidor (SNI) en la distribución de CloudFront. Para obtener más información acerca de cómo usar nombres de dominio personalizados en una distribución de CloudFront, incluido el formato de certificado necesario y el tamaño máximo de una longitud de clave de certificado, consulte [Uso de nombres de dominio alternativos y HTTPS](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-alternate-domain-names.html) en la *Guía para desarrolladores de Amazon CloudFront*.
+ Un nombre de dominio personalizado optimizado para la periferia tarda unos 40 minutos en estar listo.
+ Una vez creado su nombre de dominio personalizado optimizado para la periferia, debe crear un registro de DNS para asignar el nombre de dominio personalizado al nombre de distribución de CloudFront.
## Creación de un nombre de dominio personalizado optimizado para la periferia
El siguiente procedimiento describe cómo crear un nombre de dominio personalizado optimizado para la periferia para una API.
------
#### [ Consola de administración de AWS ]
1. Inicie sesión en la consola de API Gateway en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Elija **Custom domain names (Nombres de dominios personalizados)** en el panel de navegación principal.
1. Elija **Agregar nombre de dominio**.
1. En **Nombre de dominio**, escriba un nombre de dominio.
1. En **Modo de enrutamiento**, elija **API\$1MAPPING\$1ONLY**.
1. En **Tipo de punto de conexión de la API**, elija **Optimizado para periferia**.
1. Elija una versión mínima de TLS.
1. Elija un certificado de ACM.
1. Elija **Agregar nombre de dominio**.
------
#### [ REST API ]
1. Llame a [domainname:create](https://docs.aws.amazon.com/apigateway/latest/api/API_CreateDomainName.html), especificando el nombre de dominio personalizado y el ARN de un certificado almacenado en AWS Certificate Manager.
Si la llamada a la API se realiza correctamente, se devuelve una respuesta `201 Created`, la cual contiene el ARN del certificado, así como el nombre de distribución de CloudFront asociado en su carga.
1. Anote el nombre de dominio de distribución de CloudFront que aparece en el resultado. Lo necesitará en el siguiente paso para establecer el destino de alias de registro A del dominio personalizado en el DNS.
Para ver ejemplos de código de esta llamada a la API de REST, consulte [domainname:create](https://docs.aws.amazon.com/apigateway/latest/api/API_CreateDomainName.html).
------
Un nombre de dominio personalizado optimizado para la periferia tarda unos 40 minutos en estar listo, pero la consola mostrará inmediatamente el nombre de dominio de distribución de CloudFront asociado, con el formato `distribution-id.cloudfront.net`, junto con el ARN del certificado. Mientras tanto, puede crear una asignación de ruta base o una regla de enrutamiento y, a continuación, configurar el alias de registro de DNS para asignar el nombre de dominio personalizado al nombre de dominio de distribución de CloudFront asociado.
## Configurar el mapeo de ruta base de una API con un nombre de dominio personalizado como su nombre de host
Debido a que ha establecido el modo de enrutamiento en `API_MAPPING_ONLY`, puede usar la asignación de ruta base para utilizar un único nombre de dominio personalizado como el nombre de host de varias API. De este modo, una API estará accesible a través de la combinación del nombre de dominio personalizado y la ruta base asociada.
Por ejemplo, si en API Gateway creó una API llamada `PetStore` y otra API con el nombre `Dogs`, y configuró un nombre de dominio personalizado de `api.example.com`, puede establecer la URL de la API `PetStore` como `https://api.example.com`.
Esto asocia la API `PetStore` con la ruta base de una cadena vacía. Si establece la URL de la API `PetStore` como `https://api.example.com/PetStore`, se asocia la API `PetStore` a la ruta base de `PetStore`. Puede asignar una ruta base de `MyDogList` para la API `Dogs`. La dirección URL de `https://api.example.com/MyDogList` es entonces la URL raíz de la API `Dogs`.
Para configurar las asignaciones de API en varios niveles, solo puede usar un nombre de dominio personalizado regional. No se admiten los nombres de dominio personalizados optimizados para la periferia. Para obtener más información, consulte [Uso de las asignaciones de API para conectar etapas de API a un nombre de dominio personalizado para las API de REST](rest-api-mappings.md).
El siguiente procedimiento configura asignaciones de API para asignar rutas desde el nombre de dominio personalizado a las etapas de API.
------
#### [ Consola de administración de AWS ]
1. Inicie sesión en la consola de API Gateway, en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Elija **Custom domain names (Nombres de dominio personalizados)** en el panel de navegación principal de la consola de API Gateway.
1. Elija un nombre de dominio personalizado.
1. Elija **Configure API mappings (Configurar asignaciones de API)**.
1. Seleccione **Add new mapping (Agregar nueva asignación)**.
1. Especifique la **API**, **Stage (Etapa)** y **Route (Ruta)** (opcional) para la asignación.
1. Seleccione **Save**.
------
#### [ REST API ]
Llame a [basepathmapping:create](https://docs.aws.amazon.com/apigateway/latest/api/API_CreateBasePathMapping.html) en un nombre de dominio personalizado concreto especificando los elementos `basePath`, `restApiId` y una propiedad `stage` de implementación en la carga de la solicitud.
La llamada a la API, si se realiza correctamente, devuelve una respuesta `201 Created`.
Para ver ejemplos de código de la llamada a la API de REST, consulte [basepathmapping:create](https://docs.aws.amazon.com/apigateway/latest/api/API_CreateBasePathMapping.html).
------
Para obtener mayor flexibilidad sobre cómo enrutar el tráfico a las API, puede cambiar el modo de enrutamiento a `ROUTING_RULE_ONLY` o `ROUTING_RULE_THEN_API_MAPPING` y crear una regla de enrutamiento. Para obtener más información, consulte [Envío de tráfico a las API a través del nombre de dominio personalizado en API Gateway](rest-api-routing-mode.md).
## Creación de un registro de DNS para el nombre de dominio personalizado optimizado para la periferia
Después de iniciar la creación de su nombre de dominio personalizado optimizado para la periferia, configure el alias de registro de DNS.
Le recomendamos que use Route 53 para crear un alias de registro A para su nombre de dominio personalizado y especificar el nombre de dominio de distribución de CloudFront como el alias de destino. Esto significa que Route 53 pueden enrutar su nombre de dominio personalizado aunque se trate de un ápex de zona. Para obtener más información, consulte [Elección entre registros de alias y sin alias](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html) en la *guía para desarrolladores de Amazon Route 53*.
Para obtener instrucciones sobre Amazon Route 53, consulte [Routing traffic to an Amazon API Gateway API by using your domain name](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-api-gateway.html) en la *Guía para desarrolladores de Amazon Route 53*.
## Registro de la creación del nombre de dominio personalizado en CloudTrail
Cuando CloudTrail está habilitado para registrar llamadas de API Gateway realizadas por su cuenta, API Gateway registra las actualizaciones de la distribución de CloudFront asociadas cuando se crea o se actualiza un nombre de dominio personalizado para una API. Estos registros están disponibles en `us-east-1`. Como estas distribuciones de CloudFront son propiedad de API Gateway, cada una de estas distribuciones de CloudFront registradas se identifican mediante uno de los siguientes ID de cuenta de API Gateway específicos de cada región, en lugar de mediante el ID de la cuenta del propietario de la API.
| **Región** | **ID de cuenta** |
| --- | --- |
| 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-east-1 | 174803364771 |
| sa-east-1 | 287228555773 |
| me-south-1 | 855739686837 |
| me-central-1 | 614065512851 |
## Rotación de un certificado importado en ACM
ACM se encarga automáticamente de renovar los certificados que emite. No necesita rotar ningún certificado emitido por ACM para los nombres de dominio personalizados. CloudFront lo gestiona por usted.
No obstante, si importa un certificado en ACM y lo usa para un nombre de dominio personalizado, debe rotar el certificado antes de que venza. Esto implica importar un nuevo certificado de terceros para el nombre de dominio y reemplazar el certificado existente por el nuevo. Necesita repetir el proceso cuando el certificado que acaba de importar venza. De forma alternativa, puede solicitar a ACM que emita un nuevo certificado para el nombre de dominio y reemplazar el existente por el nuevo certificado emitido por ACM. A partir de entonces, puede dejar que ACM y CloudFront se ocupen de administrar la rotación de certificados automáticamente. Para crear o importar un nuevo certificado de ACM, siga los pasos de [Creación o importación de un certificado SSL/TLS en ACM](how-to-specify-certificate-for-custom-domain-name.md#how-to-specify-certificate-for-custom-domain-name-setup).
En el siguiente procedimiento se describe cómo rotar un certificado para un nombre de dominio.
**nota**
Se tarda unos 40 minutos en rotar un certificado importado a ACM.
------
#### [ Consola de administración de AWS ]
1. Solicite o importe un certificado en ACM.
1. Inicie sesión en la consola de API Gateway, en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Elija **Custom domain names (Nombres de dominio personalizados)** en el panel de navegación principal de la consola de API Gateway.
1. Elija un nombre de dominio personalizado optimizado para la periferia.
1. En **Configuración de punto de conexión**, elija **Editar**.
1. En **Certificado de ACM**, seleccione un certificado en la lista desplegable.
1. Elija **Guardar cambios** para empezar a rotar el certificado para el nombre de dominio personalizado.
------
#### [ REST API ]
Llame a la acción [domainname:update](https://docs.aws.amazon.com/apigateway/latest/api/API_UpdateDomainName.html) especificando el ARN del nuevo certificado de ACM para el nombre de dominio especificado.
------
#### [ AWS CLI ]
El siguiente [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-domain-name.html) actualiza el certificado de ACM de un nombre de dominio optimizado para bordes.
```
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'"
```
El siguiente [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-domain-name.html) actualiza el certificado de ACM de un nombre de dominio regional.
```
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'"
```
------
## Llamada a la API con nombres de dominio personalizados cuando utilice una asignación de ruta base
Llamar a una API con un nombre de dominio personalizado es lo mismo que llamar a la API con su nombre de dominio predeterminado, siempre que se use la URL correcta.
En los siguientes ejemplos se compara y se contrasta un conjunto de direcciones URL predeterminadas y las URL personalizadas correspondientes de dos API (`udxjef` y `qf3duz`) en una región especificada (`us-east-1`) y de un nombre de dominio personalizado (`api.example.com`) especificado.
| ID de API | Etapa | URL predeterminada | Ruta base | URL personalizada |
| --- | --- | --- | --- | --- |
| udxjef | prod | https://udxjef.execute-api.us-east-1.amazonaws.com/prod | /petstore | https://api.example.com/petstore |
| udxjef | tst | https://udxjef.execute-api.us-east-1.amazonaws.com/tst | /petdepot | https://api.example.com/petdepot |
| qf3duz | dev | https://qf3duz.execute-api.us-east-1.amazonaws.com/dev | /bookstore | https://api.example.com/bookstore |
| qf3duz | tst | https://qf3duz.execute-api.us-east-1.amazonaws.com/tst | /bookstand | https://api.example.com/bookstand |
Para obtener mayor flexibilidad sobre cómo enrutar el tráfico a las API, puede crear una regla de enrutamiento. Para obtener más información, consulte [Envío de tráfico a las API a través del nombre de dominio personalizado en API Gateway](rest-api-routing-mode.md).
API Gateway admite nombres de dominio personalizados para una API mediante el uso de la [indicación de nombre de servidor (SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication). Puede invocar la API con un nombre de dominio personalizado mediante un navegador o una biblioteca cliente que admita SNI.
API Gateway aplica SNI en la distribución CloudFront. Para obtener información sobre cómo CloudFront utiliza nombres de dominio personalizados, consulte [Certificados SSL personalizados de Amazon CloudFront](https://aws.amazon.com/cloudfront/custom-ssl-domains/).
# Migración de un nombre de dominio personalizado a otro tipo punto de conexión de API en API Gateway
Puede migrar el nombre de dominio personalizado entre puntos de conexión optimizados para bordes y regionales. No es posible migrar un nombre de dominio personalizado público a un nombre de dominio personalizado privado. En primer lugar, debe añadir el nuevo tipo de configuración de punto de conexión a la lista `endpointConfiguration.types` existente para el nombre de dominio personalizado. A continuación, debe configurar un registro DNS para que el nombre de dominio personalizado señale al punto de conexión recién aprovisionado. Por último, debe quitar el punto de conexión de los nombres de dominio personalizados obsoletos.
## Consideraciones
A continuación, se ofrecen algunas consideraciones para migrar el dominio personalizado entre un punto de conexión de API regional y un punto de conexión de API optimizado para la periferia:
+ Un nombre de dominio personalizado optimizado para la periferia requiere un certificado proporcionado por ACM de la región Este de EE. UU. (Norte de Virginia) - `us-east-1`. Este certificado se distribuye a todas las ubicaciones geográficas.
+ Un nombre de dominio personalizado regional requiere un certificado proporcionado por ACM en la misma región que aloja la API. Puede migrar un nombre de dominio personalizado optimizado para la periferia que no se encuentra en la región `us-east-1` a un nombre de dominio personalizado regional mediante la solicitud de un nuevo certificado de ACM desde la región local para la API.
+ Puede tardar hasta 60 segundos en completarse una migración entre un nombre de dominio personalizado optimizado para la periferia y un nombre de dominio personalizado regional. El tiempo de migración también depende de cuándo se actualicen los registros de DNS.
+ Solo puede agregar una configuración de punto de conexión adicional si el modo de acceso de punto de conexión está configurado en `BASIC`. Una vez que tenga dos configuraciones de punto de conexión, no podrá cambiar el modo de acceso de punto de conexión. Para obtener más información, consulte [Modo de acceso de punto de conexión](apigateway-security-policies.md#apigateway-security-policies-endpoint-access-mode).
+ Si el nombre de dominio personalizado usa una política de seguridad que comienza con `SecurityPolicy_`, cuando agrega un nuevo tipo de configuración de punto de conexión, el modo de acceso al punto de conexión es el mismo en ambos tipos de punto de conexión y debe elegir una política de seguridad que comience con `SecurityPolicy_` para el nuevo tipo de configuración de punto de conexión.
## Migración de nombres de dominio personalizados
**nota**
Para completar la migración, asegúrese de eliminar el punto de conexión obsoleto del nombre de dominio personalizado.
En el siguiente procedimiento se muestra cómo migrar un nombre de dominio personalizado optimizado para la periferia a un nombre de dominio personalizado regional.
------
#### [ Consola de administración de AWS ]
1. Inicie sesión en la consola de API Gateway en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Elija **Custom domain names (Nombres de dominios personalizados)** en el panel de navegación principal.
1. Elija un nombre de dominio personalizado optimizado para la periferia.
1. En **Configuración de punto de conexión**, elija **Editar**.
1. Elija **Agregar punto de conexión regional**.
1. En **Certificado de ACM**, elija un certificado.
El certificado regional debe estar en la misma región que la API regional.
1. Seleccione **Save changes (Guardar cambios)**.
1. Configure un registro de DNS para que el nombre de dominio personalizado regional apunte a este nombre de host regional. Para obtener más información, consulte [Configuración de Route 53 para enrutar el tráfico a API Gateway](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-api-gateway.html).
1. Después de confirmar que la configuración de DNS utiliza el punto de conexión correcto, elimine la configuración de punto de conexión optimizado para la periferia. Elija el nombre del dominio personalizado y, después, elija **Eliminar** para **Configuración de punto de conexión (optimizado para bordes)**.
1. Confirme su elección y elimine el punto de conexión.
------
#### [ AWS CLI ]
El siguiente comando [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-domain-name.html) permite migrar el nombre de dominio personalizado optimizado para bordes a un nombre de dominio personalizado regional:
```
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" }
]'
```
El certificado regional debe corresponder a la misma región que la API regional.
El resultado será similar al siguiente:
```
{
"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"
}
```
En el caso del nombre de dominio personalizado regional actualizado, la propiedad resultante `regionalDomainName` devuelve el nombre de host de la API regional. Debe configurar un registro DNS para que el nombre de dominio personalizado regional señale a este nombre de host regional. Esto permite que el tráfico que se dirige al nombre de dominio personalizado sea redirigido al host regional.
Una vez configurado el registro de DNS, puede quitar el nombre de dominio personalizado optimizado para la periferia. El siguiente comando [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-domain-name.html) permite eliminar el nombre de dominio personalizado optimizado para bordes.
```
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"}
]'
```
------
En el siguiente procedimiento se muestra cómo migrar un nombre de dominio personalizado optimizado para bordes que utilice una política de seguridad mejorada a un nombre de dominio personalizado regional que también utilice una política de seguridad mejorada.
------
#### [ Consola de administración de AWS ]
1. Inicie sesión en la consola de API Gateway en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Elija **Custom domain names (Nombres de dominios personalizados)** en el panel de navegación principal.
1. Elija un nombre de dominio personalizado optimizado para la periferia.
1. En **Configuración de punto de conexión**, elija **Editar**.
1. Elija **Agregar punto de conexión regional**.
1. En **Certificado de ACM**, elija un certificado.
El certificado regional debe estar en la misma región que la API regional.
1. Para **Política de seguridad**, elija una política de seguridad que comience con `SecurityPolicy_`.
1. Para **Modo de acceso de punto de conexión**, elija **Básico**.
1. Seleccione **Save changes (Guardar cambios)**.
1. Configure un registro de DNS para que el nombre de dominio personalizado regional apunte a este nombre de host regional. Para obtener más información, consulte [Configuración de Route 53 para enrutar el tráfico a API Gateway](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-api-gateway.html).
1. Después de confirmar que la configuración de DNS utiliza el punto de conexión correcto, elimine la configuración de punto de conexión optimizado para la periferia. Elija el nombre del dominio personalizado y, después, elija **Eliminar** para **Configuración de punto de conexión (optimizado para bordes)**.
1. Confirme su elección y elimine el punto de conexión.
------
#### [ AWS CLI ]
El siguiente comando [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-domain-name.html) permite migrar el nombre de dominio personalizado optimizado para bordes a un nombre de dominio personalizado regional:
```
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" }
]'
```
El certificado regional debe corresponder a la misma región que la API regional.
El resultado será similar al siguiente:
```
{
"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"
}
```
En el caso del nombre de dominio personalizado regional actualizado, la propiedad resultante `regionalDomainName` devuelve el nombre de host de la API regional. Debe configurar un registro DNS para que el nombre de dominio personalizado regional señale a este nombre de host regional. Esto permite que el tráfico que se dirige al nombre de dominio personalizado sea redirigido al host regional.
Una vez configurado el registro de DNS, puede quitar el nombre de dominio personalizado optimizado para la periferia. El siguiente comando [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-domain-name.html) permite eliminar el nombre de dominio personalizado optimizado para bordes.
```
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"}
]'
```
------
En el siguiente procedimiento se muestra cómo migrar un nombre de dominio personalizado regional a un nombre de dominio personalizado optimizado para la periferia.
------
#### [ Consola de administración de AWS ]
1. Inicie sesión en la consola de API Gateway, en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. En el panel de navegación principal, elija **Nombres de dominio personalizados**.
1. Elija un nombre de dominio personalizado regional.
1. En **Configuración de punto de conexión**, elija **Editar**.
1. Elija **Agregar punto de conexión optimizado para la periferia**.
1. En **Certificado de ACM**, elija un certificado.
El certificado del dominio optimizado para sistemas perimetrales debe crearse en la región `us-east-1`.
1. Seleccione **Save**.
1. Configure un registro de DNS para que el nombre de dominio personalizado optimizado para la periferia apunte a este nombre de host optimizado para la periferia. Para obtener más información, consulte [Configuración de Route 53 para enrutar el tráfico a API Gateway](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-api-gateway.html).
1. Después de confirmar que la configuración de DNS utiliza el punto de conexión correcto, elimine la configuración de punto de conexión regional. Elija el nombre del dominio personalizado y, después, elija **Eliminar** para **Configuración de punto de conexión (regional)**.
1. Confirme su elección y elimine el punto de conexión.
------
#### [ AWS CLI ]
El siguiente comando [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-domain-name.html) permite migrar el nombre de dominio personalizado regional a un nombre de dominio personalizado optimizado para bordes:
```
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"}
]'
```
El certificado del dominio optimizado para sistemas perimetrales debe crearse en la región `us-east-1`.
El resultado será similar al siguiente:
```
{
"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"
}
```
Para el nombre de dominio personalizado especificado, API Gateway devuelve el nombre de host de la API optimizada para bordes como el valor de la propiedad `distributionDomainName`. Debe configurar un registro DNS para que el nombre de dominio personalizado optimizado para sistemas perimetrales señale a este nombre de dominio de distribución. Esto permite que el tráfico que se dirige al nombre de dominio personalizado optimizado para sistemas perimetrales sea redirigido al nombre de host de la API optimizada para límites.
Una vez configurado el registro de DNS, puede quitar el tipo de punto de conexión `REGION` del nombre de dominio personalizado. El siguiente comando [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-domain-name.html) permite eliminar el tipo de punto de conexión regional:
```
aws apigateway update-domain-name \
--domain-name api.example.com \
--patch-operations '[
{"op":"remove", "path":"/endpointConfiguration/types", value:"REGIONAL"},
{"op":"remove", "path":"regionalCertificateArn"}
]'
```
El resultado es similar al siguiente:
```
{
"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"
}
}
```
------
# Envío de tráfico a las API a través del nombre de dominio personalizado en API Gateway
Cuando configura el modo de enrutamiento para el nombre de dominio personalizado, establece cómo se dirige el tráfico entrante a las API. Puede enviar tráfico a las API mediante reglas de enrutamiento, asignaciones de API o reglas de enrutamiento y asignaciones de API. En la siguiente sección se explica cuándo utilizar reglas de enrutamiento, cuándo utilizar asignaciones de API y cómo establecer el modo de enrutamiento para el nombre de dominio personalizado.
## Cuándo utilizar reglas de enrutamiento
Cuando utiliza reglas de enrutamiento, dirige las solicitudes entrantes que coinciden con determinadas condiciones a etapas específicas de las API de REST. Por ejemplo, una regla puede enrutar una solicitud a la etapa `production` de la API de REST `users` si contiene el encabezado `version:v1` y la ruta base `/users`. Utilice reglas de enrutamiento para crear topologías avanzadas de enrutamiento dinámico que admitan casos de uso como las pruebas A/B o el aumento del uso de nuevas versiones de las API.
Le recomendamos que, cuando dirija el tráfico a una API de REST, utilice reglas de enrutamiento para el nombre de dominio personalizado. Puede recrear cualquier asignación de API mediante reglas de enrutamiento. Para obtener más información, consulte [Nueva creación de una asignación de API mediante reglas de enrutamiento](rest-api-routing-rules-recreate-api-mapping.md).
En el caso de las API de REST, también puede utilizar conjuntamente reglas de enrutamiento y asignaciones de API. Cuando utiliza reglas de enrutamiento y asignaciones de API de forma conjunta, API Gateway siempre evalúa las reglas de enrutamiento antes de evaluar cualquier asignación de API. Utilice las reglas de enrutamiento y las asignaciones de API conjuntamente para migrar los nombres de dominio personalizados actuales o para explorar las reglas de enrutamiento.
### Consideraciones sobre las reglas de enrutamiento
Las siguientes consideraciones pueden afectar la utilización de las reglas de enrutamiento:
+ Las API de WebSocket o HTTP no son compatibles como API de destino para las reglas de enrutamiento.
+ Si el nombre de dominio personalizado tiene asignaciones de API tanto a las API de REST como de HTTP, no se admiten las reglas de enrutamiento.
+ Puede crear una regla de enrutamiento para un dominio personalizado privado a una API de REST privada. Puede crear una regla de enrutamiento para un dominio personalizado público a una API regional u optimizada para la periferia.
+ No puede crear una regla de enrutamiento para un dominio personalizado público a una API privada. No puede crear una regla de enrutamiento para un dominio personalizado privado a una API pública.
## Elección entre reglas de enrutamiento y asignaciones de API
Le recomendamos que, siempre que sea posible, utilice reglas de enrutamiento. Solo utilice asignaciones de API para enviar tráfico a una API de HTTP o WebSocket.
# Establecimiento del modo de enrutamiento para el nombre de dominio personalizado
Puede elegir qué modo de enrutamiento utiliza API Gateway para enrutar el tráfico a las API. Para obtener más información, consulte [Envío de tráfico a las API a través del nombre de dominio personalizado en API Gateway](rest-api-routing-mode.md). En esta sección se explican los modos de enrutamiento para nombres de dominio personalizados. Debe establecer un modo de enrutamiento para el nombre de dominio personalizado a fin de enrutar el tráfico a las API. Se admiten los siguientes modos de enrutamiento:
+ **ROUTING\$1RULE\$1THEN\$1API\$1MAPPING**: utilice este modo para enviar tráfico a las API tanto con reglas de enrutamiento como con asignaciones de API. En este modo, todas las reglas de enrutamiento tienen prioridad sobre cualquier asignación de API. Para ver un ejemplo de este modo, consulte [Ejemplo 2: reglas de enrutamiento y asignaciones de API](rest-api-routing-rules-examples.md#rest-api-routing-rules-examples-rule-and-mappings).
+ **ROUTING\$1RULE\$1ONLY**: utilice este modo para permitir solo que las reglas de enrutamiento envíen tráfico a las API. Cuando el dominio personalizado utiliza este modo, no puede crear una asignación de API, pero puede utilizar el comando [get-api-mappings](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/get-api-mappings.html) para verlas. Los intermediarios que llaman a la API no pueden utilizar asignaciones de API para acceder a este nombre de dominio.
+ **API\$1MAPPING\$1ONLY**: utilice este modo para permitir solo que las asignaciones de API envíen tráfico a las API. Cuando el nombre de dominio personalizado utiliza este modo, no puede crear una regla de enrutamiento, pero puede utilizar el comando `list-routing-rules` para verlas. Los intermediarios que llaman a la API no pueden utilizar reglas de enrutamiento para acceder a este nombre de dominio.
Este es el modo de enrutamiento predeterminado para todos los nombres de dominio existentes y para cualquier nombre de dominio nuevo que cree.
Cuando crea un nombre de dominio personalizado mediante `apigateway`, `API_MAPPING_ONLY` se llama `BASE_PATH_MAPPING_ONLY` y `ROUTING_RULE_THEN_API_MAPPING` se llama `ROUTING_RULE_THEN_BASE_PATH_MAPPING`. Este comportamiento solo está presente para la AWS CLI, CloudFormation o cualquier SDK, no en la Consola de administración de AWS.
El procedimiento siguiente muestra cómo cambiar el modo de enrutamiento de un nombre de dominio personalizado existente. Cuando cambie el modo de enrutamiento del nombre de dominio personalizado, los intermediarios que llamen a la API no podrán acceder al nombre de dominio con ningún modo de enrutamiento no admitido.
------
#### [ Consola de administración de AWS ]
1. Inicie sesión en la consola de API Gateway en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Elija **Custom domain names (Nombres de dominios personalizados)** en el panel de navegación principal.
1. Elija un nombre de dominio personalizado.
1. En **Detalles del dominio**, elija **Editar**.
1. En **Modo de enrutamiento**, elija **ROUTING\$1RULE\$1THEN\$1API\$1MAPPING**.
1. Seleccione **Save**.
Si cambia el modo de enrutamiento a `ROUTING_RULE_ONLY` o `API_MAPPING_ONLY`, cualquier asignación de API o regla de enrutamiento que haya creado se eliminará de la página de detalles del nombre de dominio de la consola. Si cambia el modo de enrutamiento para que admita reglas de enrutamiento o asignaciones de API, estos recursos volverán a aparecer.
------
#### [ AWS CLI - apigatewayv2 ]
El siguiente comando [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-domain-name.html) actualiza un nombre de dominio para utilizar el modo de enrutamiento `ROUTING_RULE_THEN_API_MAPPING`:
```
aws apigatewayv2 update-domain-name \
--domain-name 'api.example.com' \
--routing-mode "ROUTING_RULE_THEN_API_MAPPING"
```
El resultado será similar al siguiente:
```
{
"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 ]
El siguiente comando [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-domain-name.html) actualiza un nombre de dominio personalizado privado para utilizar el modo de enrutamiento `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'"
```
El resultado será similar al siguiente:
```
{
"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"
}
```
------
# Reglas de enrutamiento para conectar las etapas de API a un nombre de dominio personalizado para las API de REST
Una regla de enrutamiento es un conjunto de condiciones que, cuando coinciden, invocan una acción. Por ejemplo, una regla puede enrutar cualquier solicitud entrante a un nombre de dominio personalizado que contenga el encabezado `Hello:World` y contenga la ruta base `users` a la etapa `production` de una API de REST.
Las reglas se evalúan por orden de prioridad, y si establece el modo de enrutamiento en `ROUTING_RULE_THEN_API_MAPPING`, API Gateway siempre evalúa todas las reglas de enrutamiento antes de evaluar cualquier asignación de API. En la siguiente lista se describe cómo una regla de enrutamiento utiliza condiciones, acciones y prioridades.
**Condiciones**
Cuando se cumplen las condiciones de una regla, se llevan a cabo sus acciones. API Gateway admite hasta dos condiciones de encabezado y una condición de ruta. API Gateway evalúa conjuntamente las condiciones de encabezado y las condiciones de ruta base.
Puede crear una regla sin condiciones. Cuando API Gateway evalúa esta regla, siempre se realiza la acción. Puede crear una regla sin ninguna condición como regla catch-all.
Para obtener más información sobre las condiciones de encabezado, consulte [Condiciones de encabezado de coincidencia](#rest-api-routing-rules-condition-headers). Para obtener más información sobre las condiciones de ruta, consulte [Coincidencia de condiciones de ruta base](#rest-api-routing-rules-condition-path).
**Acciones**
Las acciones son el resultado de la coincidencia de condiciones con una regla de enrutamiento. Actualmente, la única acción admitida es invocar una etapa de una API de REST.
Cada regla puede tener una acción.
**Prioridad**
La prioridad determina en qué orden se evalúan las reglas, del valor más bajo al más alto. Las reglas no pueden tener la misma prioridad.
Puede establecer la prioridad entre 1 y 1 000 000. Si una regla tiene una prioridad de uno, API Gateway la evalúa en primer lugar. Le recomendamos que, cuando cree una regla, agregue espacios en las prioridades. Esto lo ayuda a cambiar la prioridad de las reglas y a agregar nuevas reglas. Para obtener más información, consulte [Cambio de la prioridad de una regla de enrutamiento](apigateway-routing-rules-use.md#rest-api-routing-rules-change-priority).
Para ver ejemplos de cómo API Gateway evalúa las reglas de enrutamiento, consulte [Ejemplos de cómo API Gateway evalúa las reglas de enrutamiento](rest-api-routing-rules-examples.md).
## Tipos de condiciones de las reglas de enrutamiento de API Gateway
En la siguiente sección se describen los tipos de condiciones de las reglas de enrutamiento. API Gateway solo hace coincidir una regla si se cumplen todas las condiciones.
### Condiciones de encabezado de coincidencia
Al crear una condición de encabezado, puede hacer coincidir el nombre del encabezado y el valor glob del encabezado, como `Hello:World`. API Gateway utiliza una coincidencia literal para validar las condiciones de encabezado de coincidencia. La condición puede utilizar hasta dos encabezados con `AND` entre ellos. Por ejemplo, la condición puede coincidir si una solicitud entrante contiene `Hello:World` y `x-version:beta`.
La coincidencia del nombre del encabezado no distingue entre mayúsculas y minúsculas, pero el valor glob del encabezado sí. `Hello:World` coincidirá con `hello:World`, pero no con `Hello:world`.
Para ver una lista de valores de encabezado restringidos, consulte [Restricciones](#rest-api-routing-rules-restrictions).
#### Uso de caracteres comodín con condiciones de encabezado
Solo puede utilizar caracteres comodín en el valor glob del encabezado y el carácter comodín debe ser `*prefix-match`, `suffix-match*` o `*contains*`. En la siguiente tabla se muestran ejemplos de cómo utilizar comodines para la coincidencia de condiciones de encabezado.
| Condiciones de encabezado | Solicitudes que coinciden con la regla de enrutamiento | Solicitudes que no coinciden con la regla de enrutamiento |
| --- | --- | --- |
| `x-version: a*` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apigateway/latest/developerguide/rest-api-routing-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apigateway/latest/developerguide/rest-api-routing-rules.html) |
| `x-version: *a` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apigateway/latest/developerguide/rest-api-routing-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apigateway/latest/developerguide/rest-api-routing-rules.html) |
| `x-version: *a*` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apigateway/latest/developerguide/rest-api-routing-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apigateway/latest/developerguide/rest-api-routing-rules.html) |
| `x-version: *a*` y `x-version: *b*` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apigateway/latest/developerguide/rest-api-routing-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apigateway/latest/developerguide/rest-api-routing-rules.html) |
| `x-version: b*` y `x-version: *a` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apigateway/latest/developerguide/rest-api-routing-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apigateway/latest/developerguide/rest-api-routing-rules.html) |
| `x-version: *` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apigateway/latest/developerguide/rest-api-routing-rules.html) | Ninguno |
Si crea condiciones para varios valores de encabezado, como `Accept:application/json,text/xml`, le recomendamos que utilice `*contains*` para las condiciones de encabezado y evite crear condiciones utilizando el carácter de coma (`,`).
Dado que API Gateway enruta las condiciones de encabezado literalmente, las coincidencias semánticas podrían enrutarse de forma diferente. En la siguiente tabla se muestra la diferencia en los resultados de las reglas de enrutamiento.
| Condiciones de encabezado | Solicitudes que coinciden con la regla de enrutamiento | Solicitudes que no coinciden con la regla de enrutamiento |
| --- | --- | --- |
| `Accept: *json` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apigateway/latest/developerguide/rest-api-routing-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apigateway/latest/developerguide/rest-api-routing-rules.html) |
| `Accept: *json*` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/apigateway/latest/developerguide/rest-api-routing-rules.html) | Ninguno |
### Coincidencia de condiciones de ruta base
Al crear una condición de ruta base, si la solicitud entrante contiene la ruta especificada, la regla coincide. La coincidencia distingue entre mayúsculas y minúsculas, por lo que la ruta `New/Users` no coincidirá con `new/users`.
Puede crear una condición de ruta base solo para una ruta base.
Para obtener una lista de condiciones de ruta base restringidas, [Restricciones](#rest-api-routing-rules-restrictions).
#### Eliminación de la ruta base con condiciones de ruta base
Cuando crea una condición de ruta base, puede elegir eliminar la ruta base. Cuando elimina la ruta base, API Gateway elimina la ruta base coincidente entrante cuando invoca la API de destino. Este es el mismo comportamiento que cuando utiliza una asignación de API. Si no elimina la ruta base, API Gateway reenvía toda la ruta base a la API de destino. Le recomendamos que solo elimine la ruta base cuando vuelva a crear una asignación de API.
En la siguiente tabla se muestran ejemplos de cómo API Gateway evalúa la condición de eliminación de la ruta base.
| Condición | Eliminación de la ruta base | Solicitud entrante | Resultado |
| --- | --- | --- | --- |
| Si la ruta base contiene `PetStoreShopper/dogs` | True | `GET https://example.com/PetStoreShopper/dogs` | API Gateway llama al método `GET` del recurso `/`. |
| Si la ruta base contiene `PetStoreShopper/dogs`. | False | `GET https://example.com/PetStoreShopper/dogs` | API Gateway llama al método `GET` del recurso `PetStoreShopper/dogs`. |
| Si la ruta base contiene `PetStoreShopper` | True | `GET https://example.com/PetStoreShopper/dogs` | API Gateway llama al método `GET` del recurso `dogs`. |
| Si la ruta base contiene `PetStoreShopper` | False | `GET https://example.com/PetStoreShopper/dogs` | API Gateway llama al método `GET` del recurso `PetStoreShopper/dogs`. |
| Si la ruta base contiene `PetStoreShopper` | True | `GET https://example.com/PetStoreShopper?birds=available` | API Gateway llama al método `GET` del recurso `/` con el parámetro de cadena de consulta `birds=available`. |
| Si la ruta base contiene `PetStoreShopper` | False | `GET https://example.com/PetStoreShopper?birds=available` | API Gateway llama al método `GET` del recurso `/PetStoreShopper` con el parámetro de cadena de consulta `birds=available`. |
## Restricciones
+ La API de destino y el nombre de dominio personalizado deben estar en la misma cuenta de AWS.
+ Cada regla puede tener una API de destino.
+ Solo puede crear una regla de enrutamiento para un nombre de dominio personalizado privado hacia una API privada y para un nombre de dominio personalizado público hacia una API pública. No puede mezclar recursos públicos y privados.
+ Si el nombre de dominio personalizado tiene asignaciones de API tanto a las API de REST como de HTTP, no se admiten las reglas de enrutamiento.
+ El número de prioridad máximo es 1 000 000.
+ Restricciones de encabezado:
+ Cada condición `anyOf` solo puede contener un valor de encabezado.
+ Los únicos caracteres permitidos para los nombres de encabezado y los valores glob de encabezado están especificados por [RFC 7230](https://datatracker.ietf.org/doc/html/rfc7230), que son `a-z`, `A-Z`, `0-9` y los siguientes caracteres especiales: `*?-!#$%&'.^_`|~`.
+ Puede utilizar un comodín en el valor glob del encabezado, pero el comodín debe ser `*prefix-match`, `suffix-match*` o `*contains*`. No puede utilizar `*` en medio de un valor glob de encabezado.
+ No se admiten nombres de encabezado con caracteres comodín.
+ El nombre del encabezado debe tener menos de 40 caracteres.
+ El valor glob del encabezado debe tener menos de 128 caracteres.
+ El valor glob del encabezado para una coincidencia de infijo debe tener menos de 40 caracteres.
+ Los siguientes encabezados no se admiten como condiciones:
+ `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`
+ Restricciones de la ruta base:
+ La longitud de la ruta base debe ser inferior a 128 caracteres.
+ La ruta base debe contener solo letras, números y los siguientes caracteres: `$-_.+!*'()/`.
Estos caracteres no se admiten en expresiones regulares (regex).
+ La ruta base no puede empezar ni terminar por el carácter de barra invertida (`\`).
# Ejemplos de cómo API Gateway evalúa las reglas de enrutamiento
A continuación se muestran cuatro ejemplos de cómo API Gateway evalúa las reglas de enrutamiento y las asignaciones de API.
## Ejemplo 1: solo reglas de enrutamiento
En este ejemplo, el nombre de dominio personalizado `https://petstore.example.com` tiene el modo de enrutamiento establecido en `ROUTING_RULE_ONLY` y tiene las siguientes reglas de enrutamiento y prioridades.
| ID de regla | Prioridad | Condiciones | Acción |
| --- | --- | --- | --- |
| `abc123` | 10 | Si la solicitud contiene el encabezado `Hello:World` | API de destino 1 |
| `zzz000` | 50 | Si la solicitud contiene los encabezados `Accept:image/webp` y `Pet:Dog-*` y si la ruta base contiene `PetStoreShopper` | API de destino 2 |
| `efg456` | 100 | Ninguno | API de destino 3 |
En la siguiente tabla se muestra cómo API Gateway aplica las reglas de enrutamiento anteriores a las solicitudes de ejemplo.
| Solicitud | API seleccionada | Explicación |
| --- | --- | --- |
| `https://petstore.example.com -h "Hello:World"` | API de destino 1 | La solicitud coincide con la regla de enrutamiento `abc123`. |
| `https://petstore.example.com/PetStoreShopper -h "Hello:World", "Pet:Dog-Bella", "Accept:image/webp"` | API de destino 1 | API Gateway evalúa todas las reglas de enrutamiento por orden de prioridad. La regla de enrutamiento `abc123` tiene la primera prioridad y las condiciones coinciden, por lo que API Gateway invoca la API de destino 1. Aunque las condiciones de la solicitud también coinciden con la regla de enrutamiento `zzz000`, API Gateway no evalúa ninguna otra regla de enrutamiento después de establecer una coincidencia. |
| `https://petstore.example.com/PetStoreShopper -h "Pet:Dog-Bella", "Accept:image/webp"` | API de destino 2 | La solicitud coincide con la regla de enrutamiento `zzz000`. Esta coincidencia se debe a que la cadena `Pet:Dog-Bella` coincidía con `Pet:Dog-*` |
| `https://petstore.example.com/PetStoreShopper -h "Pet:Dog-Bella"` | API de destino 3 | La solicitud no coincide con la regla de enrutamiento `abc123`. La solicitud no coincide con la regla de enrutamiento `zzz000` porque no están presentes todos los encabezados requeridos. La siguiente regla de prioridad coincide con todas las solicitudes entrantes, por lo que API Gateway invoca la API de destino 3. |
## Ejemplo 2: reglas de enrutamiento y asignaciones de API
En este ejemplo, el nombre de dominio personalizado `https://petstore.diagram.example.com` tiene el modo de enrutamiento establecido en `ROUTING_RULE_THEN_API_MAPPING` y tiene las siguientes reglas de enrutamiento y asignaciones de API.
| ID de regla | Prioridad | Condiciones | Acción |
| --- | --- | --- | --- |
| `abc123` | 1 | Si la base de la solicitud contiene `pets` | Invoque la etapa `Prod` de la API `PetStore`. |
| `000zzz` | 5 | Si la solicitud contiene los encabezados `Cookie`:`*ux=beta*` y si la ruta base contiene `/refunds` | Invoque la etapa `Beta` de la API `Refunds`. |
En la siguiente tabla se muestran las asignaciones de la API para `https://petstore.backup.example.com`.
| Mapeo de API | API seleccionada |
| --- | --- |
| `/refunds` | Invoque la etapa `Prod` de la API `Refunds`. |
| `(none)` | Invoque la etapa `Prod` de la API `Search`. |
En el siguiente diagrama se muestra cómo API Gateway aplica las reglas de enrutamiento anteriores a las solicitudes de ejemplo. Las solicitudes de ejemplo se resumen en la tabla que sigue a este diagrama.
![\[Diagrama de cómo API Gateway aplica las reglas de enrutamiento anteriores y las asignaciones de API.\]](http://docs.aws.amazon.com/es_es/apigateway/latest/developerguide/images/rr-diagram.png)
En la siguiente tabal se muestra cómo API Gateway aplica las reglas de enrutamiento anteriores a las solicitudes de ejemplo.
| Solicitud | API seleccionada | Explicación |
| --- | --- | --- |
| `https://petstore.diagram.com/pets` | La etapa `Prod` de la API `PetStore`. | La solicitud coincide con la regla de enrutamiento `abc123`. |
| `https://petstore.diagram.example.com/refunds -h "Cookie:lang=en-us;ux=beta"` | La etapa `Beta` de la API `Refunds`. | La solicitud coincide con la regla de enrutamiento `000zzz`. El encabezado `Cookie` contiene la coincidencia `*contains*` correcta y la coincidencia de ruta base para esta condición. |
| `https://petstore.diagram.example.com/refunds` | La etapa `Prod` de la API `Refunds`. | La solicitud no tiene los encabezados necesarios para la coincidencia con la regla de enrutamiento `zzz000`. Si API Gateway no puede hacer coincidir correctamente una regla de enrutamiento, recurre a las asignaciones de API. API Gateway puede asignar la ruta base a la etapa `Prod` de la API `Refunds`. |
| `https://petstore.diagram.example.com/` | La etapa `Prod` de la API `Search`. | La solicitud coincide con la asignación de la API a la ruta vacía `(none)`. |
## Ejemplo 3: reglas de enrutamiento y asignaciones de API con varios niveles
En este ejemplo, el nombre de dominio personalizado `https://petstore.backup.example.com` tiene el modo de enrutamiento establecido en `ROUTING_RULE_THEN_API_MAPPING` y tiene las siguientes reglas de enrutamiento y asignaciones de API.
En la siguiente tabla se muestran las reglas de enrutamiento para `https://petstore.backup.example.com`.
| ID de regla | Prioridad | Condiciones | Acción |
| --- | --- | --- | --- |
| `abc123` | 10 | Si la solicitud contiene el encabezado `Hello:World` | API de destino 1 |
| `000zzz` | 50 | Si la solicitud contiene los encabezados `Accept`:`image/webp` y `Pet:Dog-*` y si la ruta base contiene `PetStoreShopper` | API de destino 2 |
En la siguiente tabla se muestran las asignaciones de la API para `https://petstore.backup.example.com`.
| Mapeo de API | API seleccionada |
| --- | --- |
| `PetStoreShopper` | API de destino 3 |
| `PetStoreShopper/cats` | API de destino 4 |
En la siguiente tabal se muestra cómo API Gateway aplica las reglas de enrutamiento anteriores a las solicitudes de ejemplo.
| Solicitud | API seleccionada | Explicación |
| --- | --- | --- |
| `https://petstore.example.com/PetStoreShopper -h "Accept:image/webp", "Pet:Cats" ` | API de destino 3 | La solicitud no tiene los encabezados necesarios para la coincidencia con la regla de enrutamiento `zzz000`. Si API Gateway no puede hacer coincidir correctamente una regla de enrutamiento, recurre a las asignaciones de API. API Gateway puede asignar la ruta base a la API de destino 3. |
| `https://petstore.example.com/PetStoreShopper/cats -h "Hello:World"` | API de destino 1 | La solicitud coincide con la regla de enrutamiento `abc123`. Si el modo de enrutamiento se establece en `ROUTING_RULE_THEN_API_MAPPING`, las reglas de enrutamiento siempre tienen prioridad sobre las asignaciones de API. |
| `https://petstore.example.com/Admin -h "Pet:Dog-Bella"` | Ninguno | La solicitud no coincide con ninguna regla de enrutamiento ni asignación de API. Dado que no hay ninguna regla de enrutamiento predeterminada, API Gateway rechaza la llamada y envía al intermediario un código de estado `403 Forbidden`. |
## Ejemplo 4: reglas de enrutamiento para nombres de dominio comodín
En este ejemplo, el nombre de dominio personalizado `https://*.example.com` es un nombre de dominio comodín. El comodín admite todos los subdominios que enrutan al mismo dominio. Las siguientes reglas de enrutamiento de ejemplo cambian este comportamiento para permitir que los subdominios enruten a diferentes API de destino mediante el encabezado `Host`.
En la siguiente tabla se muestran las reglas de enrutamiento para `https://*.example.com`.
| ID de regla | Prioridad | Condiciones | Acción |
| --- | --- | --- | --- |
| `abc123` | 10 | Si la solicitud contiene el encabezado `Host:a.example.com` | API de destino 1 |
| `000zzz` | 50 | Si la solicitud contiene encabezados `Host:b.example.com` | API de destino 2 |
| `efg456` | 500 | Ninguno | API de destino 3 |
En la siguiente tabla se muestra cómo API Gateway aplica las reglas de enrutamiento anteriores a las solicitudes de ejemplo.
| Solicitud | API seleccionada | Explicación |
| --- | --- | --- |
| `https://a.example.com` | API de destino 1 | El encabezado `Host` es `a.example.com`. Esta solicitud coincide con la regla de enrutamiento `abc123`. |
| `https://b.example.com` | API de destino 2 | El encabezado `Host` es `b.example.com`. Esta solicitud coincide con la regla de enrutamiento `000zzz`. |
| `https://testing.example.com` | API de destino 3 | Coincide con la regla de enrutamiento catch-all `efg456`. |
# Cómo utilizar las reglas de enrutamiento
Puede crear una regla de enrutamiento mediante la Consola de administración de AWS, la AWS CLI o cualquier AWS SDK. Después de crear una regla, puede cambiar la prioridad.
## Creación de una regla de enrutamiento
El siguiente procedimiento muestra cómo crear una regla de enrutamiento para un nombre de dominio personalizado con un modo de enrutamiento establecido en `ROUTING_RULE_THEN_API_MAPPING` o `ROUTING_RULE_ONLY`.
------
#### [ Consola de administración de AWS ]
1. Inicie sesión en la consola de API Gateway en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Elija **Custom domain names (Nombres de dominios personalizados)** en el panel de navegación principal.
1. Elija un nombre de dominio personalizado.
1. En la pestaña **Detalles de enrutamiento**, elija **Agregar regla de enrutamiento**.
1. Elija **Agregar una nueva condición** para agregar una nueva condición.
Puede agregar una condición de encabezado o de ruta base. Para hacer coincidir todas las solicitudes entrantes con el nombre de dominio personalizado, no agregue una condición.
1. En **Acción**, utilice la lista desplegable para seleccionar la API de destino y la etapa de destino.
1. Elija **Siguiente**.
1. En el campo de prioridad, introduzca un número para la prioridad.
API Gateway evalúa las reglas en orden de prioridad, del valor más bajo al más alto.
Si va a crear una regla sin una condición, le recomendamos que utilice un valor de prioridad alto.
1. Elija **Crear regla de enrutamiento**.
------
#### [ AWS CLI ]
El siguiente comando [create-routing-rule](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-routing-rule.html) crea una regla de enrutamiento con una prioridad de 50. En este ejemplo, API Gateway enruta cualquier solicitud entrante que tenga los encabezados `Hello:World` y `x-version:beta` y la ruta base `PetStoreShopper` a la API de destino `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"
}
}
]'
```
El resultado será similar al siguiente.
```
{
"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"
}
```
------
## Cambio de la prioridad de una regla de enrutamiento
Puede cambiar la prioridad de una regla de enrutamiento. Esto tiene efecto inmediato y podría afectar el modo en que los consumidores de API invocan los nombres de dominio personalizados. Le recomendamos que, cuando establezca las prioridades de las reglas de enrutamiento, deje espacios entre las reglas.
Por ejemplo, considere dos reglas de enrutamiento, la regla `abc123` con una prioridad de 50 y la regla `zzz000` con una prioridad de 150. Para cambiar la prioridad de las reglas de modo que API Gateway evalúe primero la regla `zzz000`, puede cambiar la prioridad de la regla `zzz000` a 30.
------
#### [ Consola de administración de AWS ]
1. Inicie sesión en la consola de API Gateway en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Elija **Custom domain names (Nombres de dominios personalizados)** en el panel de navegación principal.
1. Elija un nombre de dominio personalizado.
1. En la pestaña **Detalles de enrutamiento**, elija la regla de enrutamiento y, a continuación, **Editar**.
1. Elija **Siguiente**.
1. Para la prioridad, introduzca la nueva prioridad.
1. Seleccione **Save changes (Guardar cambios)**.
------
#### [ AWS CLI ]
El siguiente comando [put-routing-rule](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/put-routing-rule.html) cambia la prioridad de una regla de enrutamiento `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"
}
}
]'
```
El resultado será similar al siguiente:
```
{
"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"
}
```
------
# Nueva creación de una asignación de API mediante reglas de enrutamiento
Puede volver a crear una asignación de API mediante reglas de enrutamiento. Para volver a crear una asignación de API, asegúrese de activar la separación de rutas base. Esto preserva el comportamiento de las asignaciones de API. Para obtener más información, consulte [Eliminación de la ruta base con condiciones de ruta base](rest-api-routing-rules.md#rest-api-routing-rules-condition-path-split).
En el siguiente tutorial se muestra cómo volver a crear la asignación de API `https:// api.example.com/orders/v2/items/categories/5` como una regla de enrutamiento y cómo actualizar los registros de acceso para registrar el ID de la regla de enrutamiento que API Gateway utiliza para enviar tráfico a la API.
------
#### [ Consola de administración de AWS ]
**Establecimiento del modo de enrutamiento en ROUTING\$1RULE\$1THEN\$1API\$1MAPPING**
1. Inicie sesión en la consola de API Gateway en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Elija **Custom domain names (Nombres de dominios personalizados)** en el panel de navegación principal.
1. Elija el nombre de dominio personalizado.
1. En **Detalles del dominio**, elija **Editar**.
1. En **Modo de enrutamiento**, elija **ROUTING\$1RULE\$1THEN\$1API\$1MAPPING**.
1. Seleccione **Save**.
Una vez establecido el modo de enrutamiento, cree la regla de enrutamiento.
**Creación de la regla de enrutamiento**
1. En la pestaña **Detalles de enrutamiento**, elija **Agregar regla de enrutamiento**.
1. Seleccione **Agregar nueva condición** y, a continuación, elija **Ruta**.
1. En **Ruta**, introduzca **orders/v2/items/categories/5**.
1. En **Eliminar ruta base**, elija **Activa**.
1. En **API de destino**, elija la API de destino.
1. En **Etapa de destino**, elija la etapa de destino.
1. Elija **Siguiente**.
1. Para la prioridad, introduzca una prioridad.
Aunque mantenga la asignación de API existente, API Gateway utilizará siempre la nueva regla de enrutamiento, ya que las reglas de enrutamiento siempre tienen prioridad sobre las asignaciones de API.
1. Seleccione **Save changes (Guardar cambios)**.
Después de crear la regla de enrutamiento, actualice el formato del registro de acceso de la etapa o cree un nuevo registro para confirmar que API Gateway utiliza la regla de enrutamiento para enviar tráfico a la API.
**Actualización de registros de acceso**
1. Inicie sesión en la consola de API Gateway en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Elija la API.
1. En el panel de navegación principal, elija **Etapas**.
1. En **Registros y seguimiento**, elija **Editar**.
Si no dispone de un grupo de registro, consulte [Configuración del registro de CloudWatch para las API de REST en API Gateway](set-up-logging.md).
1. Agregue **\$1context.customDomain.routingRuleIdMatched** al formato de registro.
Este grupo de registro guarda el ID de la regla de enrutamiento que API Gateway utilizó para enviar tráfico a la API. Para obtener más información, consulte [No puedo saber cómo API Gateway ha enviado tráfico a mis API](rest-api-routing-rules-troubleshoot.md#rest-api-routing-rules-logging).
1. Seleccione **Save**.
Después de actualizar los registros de acceso, invoque el nombre de dominio personalizado. El siguiente es un comando curl de ejemplo para invocar el nombre de dominio personalizado `https://api.example.com` con la ruta base `orders/v2/items/categories/5`.
```
curl "https://api.example.com/orders/v2/items/categories/5"
```
Una vez que haya invocado correctamente el nombre de dominio personalizado, confirme que CloudWatch Logs muestra `routingRuleIdMatched`. Para obtener información sobre cómo utilizar la consola de CloudWatch Logs para ver un grupo de registros, consulte [Visualización de eventos de registro de API Gateway en la consola de CloudWatch](view-cloudwatch-log-events-in-cloudwatch-console.md).
------
#### [ AWS CLI ]
1. Utilice el siguiente comando [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/update-domain-name.html) para actualizar el nombre de dominio `api.example.com` y utilizar el modo de enrutamiento `ROUTING_RULE_THEN_API_MAPPING`.
```
aws apigatewayv2 update-domain-name \
--domain-name 'api.example.com' \
--routing-mode ROUTING_RULE_THEN_API_MAPPING
```
1. Utilice el siguiente comando [create-routing-rule](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-routing-rule.html) para crear una nueva regla de enrutamiento para volver a crear la asignación de la API `https://api.example.com/orders/v2/items/categories/5`.
```
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. Utilice el siguiente comando [update-stage](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-stage.html) para actualizar el formato de los registros de acceso e incluir la variable `$context.customDomain.routingRuleIdMatched`. Esta variable registra el ID de la regla de enrutamiento que API Gateway utilizó para enviar tráfico a la API. Utilice este registro para confirmar que API Gateway utiliza la regla de enrutamiento para enviar tráfico a la API. Para obtener más información, consulte [No puedo saber cómo API Gateway ha enviado tráfico a mis API](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 no dispone de un grupo de registro, consulte [Configuración del registro de CloudWatch para las API de REST en API Gateway](set-up-logging.md).
1. Utilice el siguiente comando curl de ejemplo para invocar el nombre de dominio personalizado con la ruta base `orders/v2/items/categories/5`.
```
curl "https://api.example.com/orders/v2/items/categories/5
```
1. Utilice el siguiente comando [filter-log-events](https://docs.aws.amazon.com/cli/latest/reference/logs/filter-log-events.html) para obtener los eventos de registro del grupo de registro `access-log-group-orders` que contengan el ID de regla de enrutamiento `abc123`.
```
aws logs filter-log-events --log-group-name access-log-group-orders --filter-pattern abc123
```
Esto confirma que API Gateway utilizó la regla de enrutamiento para enviar tráfico a la API.
------
# Solución de problemas con las reglas de enrutamiento
La siguiente guía para la solución de problemas puede ayudarlo a resolver problemas con las reglas de enrutamiento.
## No puedo saber cómo API Gateway ha enviado tráfico a mis API
Puede utilizar los registros de acceso de la etapa de API de REST para registrar y solucionar problemas de las reglas de enrutamiento. Puede ver el ID de la regla de enrutamiento que API Gateway utilizó para enviar tráfico a la API mediante la variable `$context.customDomain.routingRuleIdMatched`. Para ver la asignación de API que API Gateway utilizó para enviar tráfico a la API, utilice la variable `$context.customDomain.basePathMatched`.
Para registrar las reglas de enrutamiento, debe configurar un ARN de [rol de CloudWatch Logs apropiado](set-up-logging.md#set-up-access-logging-permissions) para la cuenta y crear un grupo de registro.
El siguiente ejemplo de grupo de registro de acceso puede recuperar la información pertinente para la solución de problemas de reglas de enrutamiento y asignaciones de API. API Gateway solo rellena la variable de contexto para el mecanismo de enrutamiento que utilizó; de lo contrario, la variable de contexto es `-`.
------
#### [ 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
```
------
También le recomendamos que confirme el modo de enrutamiento para el nombre de dominio personalizado. Para obtener más información, consulte [Establecimiento del modo de enrutamiento para el nombre de dominio personalizado](set-routing-mode.md).
## No puedo habilitar las reglas de enrutamiento en mi nombre de dominio personalizado
Es posible que reciba el siguiente error de API Gateway:
```
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.
```
Recibirá este error si tiene o tenía una política de IAM que deniega el acceso a [BasePathMapping](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonapigatewaymanagement.html#amazonapigatewaymanagement-resources-for-iam-policies) o [ApiMapping](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonapigatewaymanagementv2.html#amazonapigatewaymanagementv2-resources-for-iam-policies). Cuando habilite reglas de enrutamiento para un nombre de dominio personalizado, aunque la política seguirá denegando el acceso a `BasePathMapping` o `ApiMapping`, la misma política puede utilizarse para acceder a `RoutingRule`. Esto podría permitir a un usuario cambiar el comportamiento de enrutamiento del nombre de dominio personalizado.
Por ejemplo, si tuviera una política como la siguiente:
```
{
"Sid": "DenyCreatingApiMappings",
"Effect": "Deny",
"Action": "apigateway:POST",
"Resource": [
"arn:aws:apigateway:us-west-2::/domainnames/example.com/apimappings"
]
}
```
Cuando habilite las reglas de enrutamiento para `example.com`, esta política seguirá denegando el acceso a la creación de `ApiMapping` pero no denegará el acceso a la creación de `RoutingRule`.
Le recomendamos que audite las políticas de IAM de la cuenta. La siguiente política de ejemplo denegará el acceso a la creación de `ApiMapping`, `BasePathMapping` y `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/*"
]
}
```
Una vez que haya confirmado que todas las políticas se han actualizado, puede actualizar la configuración de cuenta de la API para habilitar las reglas de enrutamiento para una región.
Utilice el siguiente comando [update-account](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-account.html) para actualizar la configuración de cuenta de la API para una región:
```
aws apigateway update-account --patch-operations 'op=remove,path=/features,value=BlockedForRoutingRules' --region us-west-2
```
Después de actualizar la configuración de cuenta de la API, puede cambiar el modo de enrutamiento del nombre de dominio personalizado. También puede seguir utilizando las políticas de IAM para denegar el acceso a `RoutingRules`, `ApiMapping` o `BasePathMapping`.
# Uso de las asignaciones de API para conectar etapas de API a un nombre de dominio personalizado para las API de REST
Las asignaciones de API se utilizan para conectar etapas de la API a un nombre de dominio personalizado. Esto envía el tráfico a sus API a través de su nombre de dominio personalizado.
Una asignación de API especifica una API, una etapa y, de forma opcional, una ruta que se utilizará para la asignación. Por ejemplo, puede asignar `https://api.example.com/orders` a la etapa `production` de una API.
Puede asignar etapas de API HTTP y de API de REST al mismo nombre de dominio personalizado.
Antes de crear una asignación de API, debe tener una API, una etapa y un nombre de dominio personalizado. Para obtener más información sobre cómo crear un nombre de dominio personalizado, consulte [Configuración de un nombre de dominio personalizado regional en API Gateway](apigateway-regional-api-custom-domain-create.md).
## Solicitudes entrantes para el nombre de dominio personalizado
Cuando asigna un nombre de dominio personalizado a una etapa de la API, API Gateway elimina la ruta base entrante. Esto elimina la ruta base asignada de la invocación a la API. Por ejemplo, si la asignación de ruta base fuera `https://api.example.com/orders/shop/5` para la etapa `test` y utilizara la siguiente solicitud, `https://api.example.com/orders/shop/5/hats`, API Gateway invocaría el recurso `/hats` de la etapa `test` de la API, no el recurso `orders/shop/5/hats`.
## Asignación de solicitudes a la API
A continuación se explica cómo API Gateway evalúa las asignaciones de la API.
Puede crear una asignación de la API mediante asignaciones de un solo nivel, como una asignación de la API desde `orders` a la etapa `beta` de una API y una asignación de la API desde `shipping` a la etapa `alpha` de una API. En el caso de los nombres de dominio personalizados regionales con la política de seguridad TLS 1.2, API Gateway admite asignaciones de la API de varios niveles. Puede crear una asignación de la API de `orders/v1/items` a la etapa `alpha` de una API y de `orders/v2/items` a la etapa `beta` de una API. Cuando crea una asignación con varios niveles, API Gateway envía las solicitudes a la asignación de la API que tenga la ruta de coincidencia más larga.
Puede crear una asignación de la API a la ruta vacía `(none)`. Si ninguna ruta coincide con la solicitud, API Gateway envía la solicitud a la ruta vacía `(none)`.
En este ejemplo, el nombre de dominio personalizado `https://api.example.com` tiene las siguientes asignaciones de la API.
| Asignación de API | API seleccionada |
| --- | --- |
| `(none)` | API 1 |
| `orders` | API 2 |
| `orders/v1/items` | API 3 |
| `orders/v2/items` | API 4 |
| `orders/v1/items/categories` | API 5 |
En la siguiente tabla se muestra cómo API Gateway aplica las asignaciones de API anteriores a las solicitudes de ejemplo.
| Solicitud | API seleccionada | Explicación |
| --- | --- | --- |
| `https://api.example.com/orders` | API 2 | La solicitud coincide exactamente con esta asignación de API. |
| `https://api.example.com/orders/v1/items` | API 3 | La solicitud coincide exactamente con esta asignación de API. |
| `https://api.example.com/orders/v2/items` | API 4 | La solicitud coincide exactamente con esta asignación de API. |
| `https://api.example.com/orders/v1/items/123` | API 3 | API Gateway elige la asignación con la ruta de coincidencia más larga. El `123` al final de la solicitud no afecta a la selección. Consulte [Solicitudes entrantes para el nombre de dominio personalizado](#rest-api-mappings-incoming-requests). |
| `https://api.example.com/orders/v2/items/categories/5` | API 5 | API Gateway elige la asignación con la ruta de coincidencia más larga. |
| `https://api.example.com/customers` | API 1 | API Gateway utiliza la asignación vacía como un catch-all. |
| `https://api.example.com/ordersandmore` | API 2 | API Gateway elige la asignación con el prefijo de coincidencia más largo. En el caso de un nombre de dominio personalizado configurado con asignaciones de un solo nivel, por ejemplo, solo `https://api.example.com/orders` y `https://api.example.com/`, API Gateway elegiría `API 1`, ya que no hay una ruta que coincida con `ordersandmore`. |
## Restricciones
+ En el caso de una asignación de API, el nombre de dominio personalizado y las API asignadas deben pertenecer a la misma cuenta de AWS.
+ Las asignaciones de API deben contener solo letras, números y los siguientes caracteres: `$-_.+!*'()/`.
+ La longitud máxima de la ruta en una asignación de API es de 300 caracteres.
+ Puede tener 200 asignaciones de API con varios niveles para cada nombre de dominio. Este límite no incluye la asignación de la API con niveles únicos, como `/prod`.
+ Solo puede asignar API HTTP a un nombre de dominio regional personalizado con la política de seguridad de TLS 1.2.
+ No puede asignar las API de WebSocket al mismo nombre de dominio personalizado que una API HTTP o API REST.
+ Después de crear sus asignaciones de API, debe crear o actualizar el registro de recursos del proveedor de DNS para asignarlo al punto de conexión de la API.
+ Si crea una asignación de API con varios niveles, API Gateway convierte todos los nombres de encabezado a minúsculas.
## Creación de una asignación de API
Para crear una asignación de API, primero debe crear un nombre de dominio personalizado, una API y una etapa. El nombre de dominio personalizado debe tener un modo de enrutamiento establecido en `ROUTING_RULE_THEN_API_MAPPING` o `API_MAPPING_ONLY`. Para obtener información sobre cómo establecer el modo de enrutamiento, consulte [Establecimiento del modo de enrutamiento para el nombre de dominio personalizado](set-routing-mode.md).
Para ver ejemplos de las plantillas de AWS Serverless Application Model que crean todos los recursos, consulte [Sessions With SAM](https://github.com/aws-samples/sessions-with-aws-sam/tree/master/custom-domains) en GitHub.
------
#### [ Consola de administración de AWS ]
1. Inicie sesión en la consola de API Gateway en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Elija **Custom domain names (Nombres de dominios personalizados)** en el panel de navegación principal.
1. Elija un nombre de dominio personalizado.
1. En la pestaña **Detalles de enrutamiento**, elija **Configurar los mapeos de la API**.
1. Especifique los valores de **API**, **Etapa** y **Ruta** para el mapeo.
1. Seleccione **Save**.
------
#### [ AWS CLI ]
El siguiente comando [create-api-mapping](https://docs.aws.amazon.com/cli/latest/reference/apigatewayv2/create-api-mapping.html) permite crear una asignación de API. En este ejemplo, API Gateway envía solicitudes a `api.example.com/v1/orders` a la API y a la etapa especificadas.
**nota**
Para crear mapeos de la API con varios niveles, debe utilizar `apigatewayv2`.
```
aws apigatewayv2 create-api-mapping \
--domain-name api.example.com \
--api-mapping-key v1/orders \
--api-id a1b2c3d4 \
--stage test
```
------
#### [ CloudFormation ]
El siguiente ejemplo de CloudFormation crea un mapeo de la API.
**nota**
Para crear mapeos de la API con varios niveles, debe utilizar `AWS::ApiGatewayV2`.
```
MyApiMapping:
Type: 'AWS::ApiGatewayV2::ApiMapping'
Properties:
DomainName: api.example.com
ApiMappingKey: 'orders/v2/items'
ApiId: !Ref MyApi
Stage: !Ref MyStage
```
------
# Tipos de direcciones IP para nombres de dominio personalizados para API Gateway
Al crear un nombre de dominio personalizado, se especifica el tipo de direcciones IP que puede invocar el dominio. Puede elegir IPv4 para resolver las direcciones IPv4 para invocar el dominio o puede elegir pila doble para permitir que las direcciones IPv4 e IPv6 invoquen el dominio. Le recomendamos que establezca el tipo de dirección IP en pila doble para mitigar el agotamiento del espacio IP o para mejorar la postura de seguridad. Para obtener más información sobre los beneficios de un tipo de dirección IP de pila doble, consulte [IPv6 en AWS](https://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/internet-protocol-version-6.html).
Puede cambiar el tipo de dirección IP actualizando la configuración de punto de conexión del nombre de dominio.
## Consideraciones para los tipos de direcciones IP
Es posible que las siguientes consideraciones afecten al uso de los tipos de direcciones IP.
+ El tipo de dirección IP predeterminado para los nombres de dominio personalizados de API Gateway para API públicas es IPv4.
+ Los nombres de dominio personalizados privados solo pueden tener un tipo de dirección IP de pila doble.
+ El nombre de dominio personalizado no necesita tener el mismo tipo de dirección IP para todas las API asignadas a él. Si desactiva el punto de conexión de la API predeterminado, esto podría afectar a la forma en que los intermediarios pueden invocar al dominio.
## Cambio del tipo de dirección IP de un nombre de dominio personalizado
Puede cambiar el tipo de dirección IP actualizando la configuración de punto de conexión del nombre de dominio. Puede actualizar la configuración de punto de conexión mediante el uso de la Consola de administración de AWS, la AWS CLI, CloudFormation, o un AWS SDK.
------
#### [ Consola de administración de AWS ]
**Cambio del tipo de dirección IP de un nombre de dominio personalizado**
1. Inicie sesión en la consola de API Gateway, en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Elija un nombre de dominio personalizado público.
1. Elija la **Configuración de punto de conexión**.
1. Para tipo de dirección IP, seleccione **IPv4** o **Pila doble**.
1. Seleccione **Save**.
------
#### [ AWS CLI ]
El siguiente comando [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-domain-name.html) actualiza una API para que tenga un tipo de dirección IP de pila doble:
```
aws apigateway update-domain-name \
--domain-name dualstack.example.com \
--patch-operations "op='replace',path='/endpointConfiguration/ipAddressType',value='dualstack'"
```
El resultado será similar al siguiente:
```
{
"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": {}
}
```
------
# Elección de una política de seguridad para el dominio personalizado en API Gateway
Una *política de seguridad* es una combinación predefinida de versión mínima de TLS y conjuntos de cifrado que ofrece API Gateway. Cuando los clientes realizan un establecimiento de comunicación de TLS en la API o el nombre de dominio personalizado, la política de seguridad aplica la versión de TLS y el conjunto de cifrado aceptado por API Gateway. Las políticas de seguridad protegen las API y los nombres de dominio personalizados de los problemas de seguridad de red como, por ejemplo, la manipulación y el espionaje entre un cliente y el servidor.
API Gateway admite políticas de seguridad heredadas y políticas de seguridad mejoradas. `TLS_1_0` y `TLS_1_2` son políticas de seguridad heredadas. Utilice estas políticas de seguridad para cargas de trabajo generalizadas o para empezar a crear una API. Cualquier política que comience con `SecurityPolicy_` es una política de seguridad mejorada. Utilice estas políticas para cargas de trabajo reguladas, una gobernanza avanzada o para utilizar la criptografía poscuántica. Al utilizar una política de seguridad mejorada, también debe configurar el modo de acceso de punto de conexión para una mayor gobernanza. Para obtener más información, consulte [Modo de acceso de punto de conexión](apigateway-security-policies.md#apigateway-security-policies-endpoint-access-mode).
## Consideraciones
A continuación, se muestran consideraciones sobre las políticas de seguridad de los nombres de dominio personalizados para las API de REST en API Gateway:
+ No puede habilitar el TLS mutuo en un nombre de dominio que utilice una política de seguridad mejorada.
+ No puede asignar una API HTTP a un nombre de dominio que utilice una política de seguridad mejorada.
+ Si habilita la asignación de rutas base de varios niveles a una API de REST que utilice una política de seguridad mejorada, no podrá crear una asignación de ruta base a una API HTTP para el mismo nombre de dominio.
+ La API se puede asignar a un nombre de dominio personalizado con una política de seguridad diferente a la de la API. Al invocar ese nombre de dominio personalizado, API Gateway utiliza la política de seguridad de la API para negociar el establecimiento de comunicación TLS. Si desactiva el punto de conexión de la API predeterminado, esto podría afectar a la forma en que los intermediarios pueden invocar a la API.
+ API Gateway admite políticas de seguridad en todas las API. Sin embargo, solo puede elegir una política de seguridad para las API de REST. API Gateway solo admite la política de seguridad `TLS_1_2` para las API HTTP o de WebSocket.
+ API Gateway no admite la actualización de una política de seguridad para un nombre de dominio con varios tipos de punto de conexión. Si tiene varios tipos de punto de conexión para un nombre de dominio, elimine uno de ellos para actualizar la política de seguridad.
## Cómo aplica API Gateway las políticas de seguridad
El siguiente ejemplo muestra cómo API Gateway aplica las políticas de seguridad mediante la política de seguridad `SecurityPolicy_TLS13_1_3_2025_09` como ejemplo.
La política de seguridad `SecurityPolicy_TLS13_1_3_2025_09` acepta el tráfico de TLS 1.3 y rechaza el tráfico de TLS 1.2 y TLS 1.0. Para el tráfico de TLS 1.3, la política de seguridad acepta los siguientes conjuntos de cifrado:
+ `TLS_AES_128_GCM_SHA256`
+ `TLS_AES_256_GCM_SHA384`
+ `TLS_CHACHA20_POLY1305_SHA256`
API Gateway no acepta ningún otro conjunto de sistemas de cifrado. Por ejemplo, la política de seguridad rechazaría cualquier tráfico de TLS 1.3 que utilice el conjunto de cifrado de `AES128-SHA`.
Para supervisar qué protocolo TLS y qué cifrado utilizan los clientes para acceder a la API Gateway, puede utilizar las variables de contexto `$context.tlsVersion` y `$context.cipherSuite` en los registros de acceso. Para obtener más información, consulte [Supervisión de las API de REST en API Gateway](rest-api-monitor.md).
Para ver las políticas de seguridad predeterminadas de todas las API de REST y los nombres de dominio personalizados, consulte [Políticas de seguridad predeterminadas](apigateway-security-policies-list.md#apigateway-security-policies-default). Para ver las políticas de seguridad aceptadas de todas las API de REST y los nombres de dominio personalizados, consulte [Políticas de seguridad admitidas](apigateway-security-policies-list.md).
## Cambio de la política de seguridad del nombre de dominio personalizado
Si cambia la política de seguridad, esta tardará unos 15 minutos en completarse. Puede supervisar el `lastUpdateStatus` del nombre de dominio personalizado. A medida que el nombre de dominio personalizado se actualice, el `lastUpdateStatus` será `PENDING` y cuando se complete será `AVAILABLE`.
Cuando utilice una política de seguridad que comience por `SecurityPolicy_`, también debe activar el modo de acceso de punto de conexión. Para obtener más información, consulte [Modo de acceso de punto de conexión](apigateway-security-policies.md#apigateway-security-policies-endpoint-access-mode).
------
#### [ Consola de administración de AWS ]
**Cambio de la política de seguridad de un nombre de dominio personalizado**
1. Inicie sesión en la consola de API Gateway, en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Elija un nombre de dominio personalizado que envíe el tráfico a las API de REST.
Asegúrese de que solo haya un tipo de punto de conexión asociado al nombre de dominio personalizado.
1. Elija **Configuración de nombre de dominio personalizado** y, a continuación, elija **Editar**.
1. En **Política de seguridad**, seleccione una nueva política.
1. Para **Modo de acceso de punto de conexión**, elija **Estricto**.
1. Seleccione **Save changes (Guardar cambios)**.
------
#### [ AWS CLI ]
El siguiente comando [update-domain-name](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-domain-name.html) actualiza un nombre de dominio para utilizar la política de seguridad `SecurityPolicy_TLS13_1_3_2025_09`:
```
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"
}
]'
```
El resultado será similar al siguiente:
```
{
"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"
}
```
------
## Información acerca de las API de HTTP y las API de WebSocket
Para obtener más información sobre las API de HTTP y las API de WebSocket, consulte [Política de seguridad de las API de HTTP en API Gateway](http-api-ciphers.md) y [Política de seguridad de las API de WebSocket en API Gateway](websocket-api-ciphers.md).
# Deshabilitación del punto de conexión predeterminado para las API de REST
De forma predeterminada, los clientes pueden invocar su API mediante el punto de conexión `execute-api` que API Gateway genera para ella. Para asegurarse de que los clientes solo puedan acceder a su API mediante un nombre de dominio personalizado, deshabilite el punto de conexión predeterminado `execute-api`. Los clientes pueden seguir conectándose al punto de conexión predeterminado, pero recibirán un código de estado `403 Forbidden`. La desactivación del punto de conexión predeterminado afecta a todas las etapas de la API. Esta configuración se aplica cuando actualiza cualquier configuración en cualquier etapa, como al actualizar la implementación en la etapa.
El siguiente procedimiento muestra cómo deshabilitar el punto de conexión predeterminado para una API de REST.
------
#### [ Consola de administración de AWS ]
1. Inicie sesión en la consola de API Gateway en [https://console.aws.amazon.com/apigateway](https://console.aws.amazon.com/apigateway).
1. Elija una API de REST.
1. En el panel de navegación principal, elija **Configuración de la API**.
1. Elegir una API.
1. En **Detalles de API**, elija **Editar**.
1. En **Punto de conexión predeterminado**, elija **Inactivo**.
1. Seleccione **Save changes (Guardar cambios)**.
1. En el panel de navegación principal, elija **Recursos**.
1. Elija **Implementar API**.
1. Vuelva a implementar la API en una etapa o actualice cualquier configuración en una etapa para que la actualización surta efecto.
------
#### [ AWS CLI ]
El siguiente comando [update-rest-api](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-rest-api.html) permite deshabilitar el punto de conexión predeterminado:
```
aws apigateway update-rest-api \
--rest-api-id abcdef123 \
--patch-operations op=replace,path=/disableExecuteApiEndpoint,value='True'
```
Después de desactivar el punto de conexión predeterminado, debe implementar la API para que el cambio surta efecto.
El siguiente comando [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/apigateway/create-deployment.html) crea una implementación y la asocia a una etapa:
```
aws apigateway create-deployment \
--rest-api-id abcdef123 \
--stage-name dev
```
------
# Configuración de las comprobaciones de estado personalizadas para la conmutación por error de DNS para una API de API Gateway
Puede utilizar las comprobaciones de estado de Amazon Route 53 para controlar la conmutación por error de DNS de una API de API Gateway en una Región de AWS principal a una en una región secundaria. Esto puede ayudar a mitigar los impactos en caso de un problema regional. Si utiliza un dominio personalizado, puede realizar una conmutación por error sin necesidad de que los clientes cambien los puntos de conexión de la API.
Al elegir [Evaluate Target Health](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AliasTarget.html#Route53-Type-AliasTarget-EvaluateTargetHealth>Evaluate Target Health) (Evaluar estado del destino) como registro de alias, esos registros solo producen un error cuando el servicio de API Gateway no está disponible en la región. En algunos casos, las propias API de API Gateway pueden sufrir interrupciones antes de ese momento. Para controlar directamente la conmutación por error de DNS, configure comprobaciones de estado personalizadas de Route 53 para las API de API Gateway. Para este ejemplo, se utiliza una alarma de CloudWatch que ayuda a los operadores a controlar la conmutación por error de DNS. Para obtener más ejemplos y otras consideraciones al configurar la conmutación por error, consulte [Creación de mecanismos de recuperación de desastres mediante Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/) y [Realización de comprobaciones de estado de Route 53 en los recursos privados de una VPC con AWS Lambda y CloudWatch](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/).
**Topics**
+ [
## Requisitos previos
](#dns-failover-prereqs)
+ [
## Paso 1: Configurar recursos
](#dns-failover-intial-setup)
+ [
## Paso 2: Iniciar la conmutación por error a la región secundaria
](#dns-failover-initiate)
+ [
## Paso 3: Probar la conmutación por error
](#dns-failover-test)
+ [
## Paso 4: Volver a la región principal
](#dns-failover-return)
+ [
## Próximos pasos: Personalizar y probar con regularidad
](#dns-failover-next-steps)
## Requisitos previos
Para completar este procedimiento, debe crear y configurar los siguientes recursos:
+ El nombre de un dominio de su propiedad.
+ Un certificado de ACM para ese nombre de dominio en dos Regiones de AWS. Para obtener más información, consulte [Requisitos previos de los nombres de dominio personalizados](how-to-custom-domains.md#how-to-custom-domains-prerequisites).
+ Una zona alojada de Route 53 para el nombre de dominio. Para obtener más información, consulte [Uso de zonas alojadas](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-working-with.html) en la Guía para desarrolladores de Amazon Route 53.
Para obtener más información sobre cómo crear registros de DNS de conmutación por error de Route 53 para los nombres de dominio, consulte [Elegir una política de enrutamiento](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) en la guía para desarrolladores de Amazon Route 53. Para obtener más información sobre cómo monitorear una alarma de CloudWatch, consulte [Monitoreo de una alarma de CloudWatch](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-values.html#health-checks-creating-values-cloudwatch) en la guía para desarrolladores de Amazon Route 53.
## Paso 1: Configurar recursos
En este ejemplo, se crean los siguientes recursos para configurar la conmutación por error de DNS para el nombre de dominio:
+ API de API Gateway en dos Regiones de AWS
+ Nombres de dominio personalizados de API Gateway con el mismo nombre en dos Regiones de AWS
+ Mapeos de API de API Gateway que conectan las API de API Gateway con los nombres de dominio personalizados
+ Registros de DNS de conmutación por error de Route 53 para los nombres de dominio
+ Una alarma de CloudWatch en la región secundaria
+ Una comprobación de estado de Route 53 basada en la alarma de CloudWatch en la región secundaria
En primer lugar, asegúrese de contar con todos los recursos necesarios en las regiones principal y secundaria. La región secundaria debe contener la alarma y la comprobación de estado. De esta forma, no tiene que depender de la región principal para realizar la conmutación por error. Por ejemplo, plantillas de CloudFormation que crean estos recursos, consulte [samples/primary.zip](samples/primary.zip) y [samples/secondary.zip](samples/secondary.zip).
**importante**
Antes de realizar la conmutación por error a la región secundaria, asegúrese de que estén disponibles todos los recursos necesarios. De lo contrario, la API no estará lista para el tráfico de la región secundaria.
## Paso 2: Iniciar la conmutación por error a la región secundaria
En el siguiente ejemplo, la región en espera recibe una métrica de CloudWatch e inicia la conmutación por error. Usamos una métrica personalizada que requiere la intervención del operador para iniciar la conmutación por error.
```
aws cloudwatch put-metric-data \
--metric-name Failover \
--namespace HealthCheck \
--unit Count \
--value 1 \
--region us-west-1
```
Sustituya los datos de las métricas por los datos correspondientes a la alarma de CloudWatch que haya configurado.
## Paso 3: Probar la conmutación por error
Invoque la API y compruebe que recibe una respuesta de la región secundaria. Si usó las plantillas de ejemplo en el paso 1, la respuesta cambia de `{"message": "Hello from the primary Region!"}` a `{"message": "Hello from the secondary Region!"}` después de la conmutación por error.
```
curl https://my-api.example.com
{"message": "Hello from the secondary Region!"}
```
## Paso 4: Volver a la región principal
Para volver a la región principal, envíe una métrica de CloudWatch que haga que se apruebe la comprobación de estado.
```
aws cloudwatch put-metric-data \
--metric-name Failover \
--namespace HealthCheck \
--unit Count \
--value 0 \
--region us-west-1
```
Sustituya los datos de las métricas por los datos correspondientes a la alarma de CloudWatch que haya configurado.
Invoque la API y compruebe que recibe una respuesta de la región principal. Si usó las plantillas de ejemplo en el paso 1, la respuesta cambia de `{"message": "Hello from the secondary Region!"}` a `{"message": "Hello from the primary Region!"}`.
```
curl https://my-api.example.com
{"message": "Hello from the primary Region!"}
```
## Próximos pasos: Personalizar y probar con regularidad
Este ejemplo muestra una forma de configurar la conmutación por error de DNS. Puede utilizar una variedad de métricas o puntos de conexión de HTTP de CloudWatch para las comprobaciones de estado que administran la conmutación por error. Pruebe los mecanismos de conmutación por error con regularidad para asegurarse de que funcionan según lo esperado y de que los operadores están familiarizados con los procedimientos de conmutación por error.