

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Elección de una política de enrutado
<a name="routing-policy"></a>

Al crear un registro, puede seleccionar una política de direccionamiento, que determina cómo Amazon Route 53 responde a las consultas: 
+ **Política de direccionamiento simple**: se utiliza para un único recurso que realiza una función determinada para su dominio; por ejemplo, un servidor web que ofrece contenido para el sitio web example.com. Puede usar el enrutamiento simple para crear registros en una zona alojada privada.
+ **Política de direccionamiento de conmutación por error**: se utiliza si desea configurar la conmutación por error activa-pasiva. Puede usar el enrutamiento de conmutación por error para crear registros en una zona alojada privada.
+ **Política de direccionamiento de geolocalización**: se utiliza si desea dirigir el tráfico en función de la ubicación de los usuarios. Puede usar el enrutamiento por geolocalización para crear registros en una zona alojada privada.
+ **Política de enrutamiento de geoproximidad**: se utiliza si desea dirigir el tráfico en función de la ubicación de los recursos y, opcionalmente, desviar el tráfico desde los recursos de una ubicación a los de otra. Puede usar el enrutamiento por geoproximidad para crear registros en una zona alojada privada.
+ **Política de enrutamiento de latencia**: utilícela cuando tenga varios recursos Regiones de AWS y desee enrutar el tráfico a la región que proporciona la mejor latencia. Puede usar el enrutamiento de latencia para crear registros en una zona alojada privada.
+ **Política de direccionamiento basada en IP**: se usa cuando se quiere enrutar el tráfico en función de la ubicación de los usuarios, y tener las direcciones IP de las que se origina el tráfico.
+ **Política de direccionamiento de respuesta con varios valores**: se utiliza si desea que Route 53 responda a consultas de DNS con hasta ocho registros de estado seleccionados al azar. Puede usar el enrutamiento de respuesta multivalor para crear registros en una zona alojada privada.
+ **Política de direccionamiento ponderada**: se utiliza para dirigir el tráfico a varios recursos en las proporciones que especifique. Puede usar el enrutamiento ponderado para crear registros en una zona alojada privada.

**Topics**
+ [Direccionamiento simple](routing-policy-simple.md)
+ [Enrutado de conmutación por error](routing-policy-failover.md)
+ [Enrutado de geolocalización](routing-policy-geo.md)
+ [Enrutamiento por geoproximidad](routing-policy-geoproximity.md)
+ [Enrutado basado en latencia](routing-policy-latency.md)
+ [Direccionamiento basado en IP](routing-policy-ipbased.md)
+ [Direccionamiento de respuesta con varios valores](routing-policy-multivalue.md)
+ [Direccionamiento ponderado](routing-policy-weighted.md)
+ [Cómo utiliza Amazon Route 53 EDNS0 para estimar la ubicación de un usuario](routing-policy-edns0.md)

# Direccionamiento simple
<a name="routing-policy-simple"></a>

El direccionamiento simple le permite configurar registros DNS estándar, sin direccionamiento de Route 53 especial, como ponderado o de latencia. Con el direccionamiento simple, el tráfico se dirige normalmente a un único recurso, como un servidor web de su sitio web. 

Puede utilizar una política de enrutamiento sencillo para los registros de una zona alojada privada.

Si elige la política de direccionamiento simple en la consola de Route 53, no puede crear varios registros que tengan el mismo nombre y tipo, pero puede especificar varios valores en el mismo registro, como varias direcciones IP. (Si elige la política de enrutamiento simple para un registro de alias, puede especificar solo un AWS recurso o un registro en la zona alojada actual). Si especifica varios valores en un registro, Route 53 devuelve todos los valores al servicio de resolución de nombres recursivo en orden aleatorio y el servicio devuelve los valores al cliente (como un navegador web) que envió la consulta de DNS. A continuación, el cliente elige un valor y vuelve a enviar la consulta. Con una política de enrutamiento sencillo, si bien puede especificar varias direcciones IP, no se puede comprobar el estado de estas direcciones.

Para obtener información acerca de los valores que especifica cuando se utiliza la política de direccionamiento simple para crear registros, consulte los siguientes temas:
+ [Valores específicos para registros simples](resource-record-sets-values-basic.md)
+ [Valores específicos para registros de alias simples](resource-record-sets-values-alias.md)
+ [Valores comunes a todas las políticas de enrutamiento](resource-record-sets-values-shared.md)
+ [Valores comunes de registros de alias para todas las políticas de enrutamiento](resource-record-sets-values-alias-common.md)

# Enrutado de conmutación por error
<a name="routing-policy-failover"></a>

El direccionamiento de conmutación por error permite redirigir el tráfico a un recurso cuando este está en buen estado o a uno diferente cuando el primer recurso no está en buen estado. Los registros primarios y secundarios pueden dirigir el tráfico a cualquier elemento desde un bucket de Amazon S3 configurado como un sitio web a un árbol complejo de registros. Para obtener más información, consulte [Conmutación por error activa-pasiva](dns-failover-types.md#dns-failover-types-active-passive).

Puede utilizar una política de enrutamiento de conmutación por error para los registros de una zona alojada privada.

Para obtener información acerca de los valores que especifica cuando se utiliza la política de direccionamiento de conmutación por error para crear registros, consulte los siguientes temas:
+ [Valores específicos de registros de conmutación por error](resource-record-sets-values-failover.md)
+ [Valores específicos de registros de alias de conmutación por error](resource-record-sets-values-failover-alias.md)
+ [Valores comunes a todas las políticas de enrutamiento](resource-record-sets-values-shared.md)
+ [Valores comunes de registros de alias para todas las políticas de enrutamiento](resource-record-sets-values-alias-common.md)

# Enrutado de geolocalización
<a name="routing-policy-geo"></a>

El direccionamiento de geolocalización permite elegir los recursos que dan servicio al tráfico en función de la ubicación geográfica de los usuarios, es decir, la procedencia de las consultas de DNS. Por ejemplo, puede hacer que todas las consultas de Europa se enruten a un equilibrador de carga elástico de la región de Fráncfort. 

Cuando usa el direccionamiento de geolocalización, puede localizar su contenido y presentar todo su sitio web o parte de este en el idioma de sus usuarios. También puede utilizar el direccionamiento de geolocalización para restringir la distribución de contenido solo a los lugares para los que tiene derechos de distribución. Otro posible uso es equilibrar la carga entre los puntos finales de forma predecible, de easy-to-manage modo que la ubicación de cada usuario se dirija de forma coherente al mismo punto final. 

Puede especificar ubicaciones geográficas por continente, por país o por estado en Estados Unidos. Si crea registros independientes para superponer regiones geográficas (por ejemplo, un registro para América del Norte y otro para Canadá), la región geográfica más pequeña recibirá la mayor prioridad. De esta manera, puede redirigir algunas consultas de un continente a un recurso y las consultas de países seleccionados de dicho continente a otro recurso. (Para ver una lista de los países de cada continente, consulte [Ubicación](resource-record-sets-values-geo.md#rrsets-values-geo-location)).

La geolocalización funciona mediante el mapeo de direcciones IP a ubicaciones. No obstante, algunas direcciones IP no se mapean a ubicaciones geográficas por lo que, aunque cree conjuntos de registros de geolocalización que abarquen los siete continentes, Amazon Route 53 recibirá algunas consultas de DNS de ubicaciones que no puede identificar. Puede crear un registro predeterminado que administre tanto las consultas de direcciones IP no mapeadas a ninguna ubicación como las que procedan de ubicaciones para las que no haya creado registros de geolocalización. Si no crea un registro predeterminado, Route 53 devuelve un mensaje de tipo “sin respuesta” a las consultas de esas ubicaciones.

Se puede utilizar el enrutamiento de geolocalización para los registros de zonas alojadas privadas y públicas.

Para obtener más información, consulte [Cómo utiliza Amazon Route 53 EDNS0 para estimar la ubicación de un usuario](routing-policy-edns0.md).

Para obtener información acerca de los valores que especifica cuando se utiliza la política de direccionamiento de geolocalización para crear registros, consulte los siguientes temas:
+ [Valores específicos de registros de geolocalización](resource-record-sets-values-geo.md)
+ [Valores específicos de registros de alias de geolocalización](resource-record-sets-values-geo-alias.md)
+ [Valores comunes a todas las políticas de enrutamiento](resource-record-sets-values-shared.md)
+ [Valores comunes de registros de alias para todas las políticas de enrutamiento](resource-record-sets-values-alias-common.md)

# Enrutado de geolocalización en zonas alojadas privadas
<a name="routing-policy-geo-phz"></a>

En el caso de las zonas alojadas privadas, Route 53 responde a las consultas de DNS en función Región de AWS de la VPC de la que se originó la consulta. Para ver la lista Regiones de AWS, consulte [Regiones y zonas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) en la guía del *usuario de Amazon EC2*.

Si la consulta de DNS se origina en una parte en las instalaciones de una red híbrida, se considerará que se originó en la Región de AWS en la que se encuentra la VPC.

Si incluye comprobaciones de estado, puede crear registros predeterminados para:
+ Direcciones IP que no están asignadas a ubicaciones geográficas.
+ Consultas de DNS que provienen de ubicaciones para las que no ha creado registros de geolocalización.

Si el registro de geolocalización de la región de la consulta de DNS no está en buen estado, se devolverá el registro predeterminado (si está en buen estado).

En la configuración de ejemplo de la siguiente figura, las consultas de DNS procedentes de un Región de AWS us-east-1 (Virginia) se enrutarán al punto final 1.1.1.1.

![\[Una captura de pantalla que muestra un registro de geolocalización de una zona alojada privada.\]](http://docs.aws.amazon.com/es_es/Route53/latest/DeveloperGuide/images/geolocation-phz.png)


# Enrutamiento por geoproximidad
<a name="routing-policy-geoproximity"></a>

El direccionamiento de geoproximidad permite a Amazon Route 53 dirigir el tráfico a sus recursos en función de la ubicación geográfica de sus usuarios y recursos. Enruta el tráfico al recurso más cercano disponible. También puede optar por enrutar más o menos tráfico a un determinado recurso especificando un valor, conocido como *sesgo*. Un sesgo expande o reduce el tamaño de la región geográfica desde la que se direcciona el tráfico a un recurso.

Puede crear reglas de geoproximidad para sus recursos y especificar uno de los siguientes valores para cada regla:
+ Si utiliza AWS recursos, especifique el grupo de zonas locales Región de AWS o el grupo de zonas en el que creó el recurso.
+ Si utiliza recursos que no son AWS recursos, especifique la latitud y la longitud del recurso.

Para usar las Zonas AWS Locales, primero debe habilitarlas. Para obtener más información, consulte la sección [Introducción al uso de zonas locales](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html), en la *AWS Guía del usuario de zonas locales*.

Para obtener más información sobre las diferencias entre las Zonas Locales Regiones de AWS y las Zonas, consulte [Regiones y zonas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) en la Guía del *usuario de Amazon EC2*.

Para cambiar opcionalmente el tamaño de la región geográfica en la que Route 53 dirige el tráfico a un recurso, especifique el valor aplicable para el sesgo:
+ Para ampliar el tamaño de la región geográfica en la que Route 53 dirige el tráfico a un recurso, especifique un número entero positivo de 1 a 99 para el sesgo. Route 53 reduce el tamaño de las regiones adyacentes. 
+ Para contraer el tamaño de la región geográfica en la que Route 53 dirige el tráfico a un recurso, especifique un sesgo negativo de -1 a -99. Route 53 expande el tamaño de las regiones adyacentes. 

**nota**  
Estamos actualizando la consola de Flujo de tráfico para Route 53. Durante el periodo de transición, puede seguir utilizando la consola anterior.

Seleccione la pestaña de la consola que esté utilizando.
+ [Nueva consola](#traffic-flow-geoprox-routing-map-new)
+ [Consola antigua](#traffic-flow-geoprox-routing-map-old)

------
#### [ New console ]

El siguiente mapa muestra cuatro Regiones de AWS (numeradas del 1 al 5):

1. Oeste de EE. UU. (Oregón)

1. Europa (Fráncfort)

1. Asia-Pacífico (Tokio)

1. África (Ciudad del Cabo)

1. Middle East (Bahrain)

**nota**  
Los mapas solo están disponibles con el Flujo de tráfico.

![\[Un mapa del mundo donde se muestra cómo se enruta el tráfico cuando se tienen registros de geoproximidad para recursos en las Regiones de AWS de Oeste de EE. UU. (Oregón), Europa (Fráncfort), Asia Pacífico (Tokio), África (Ciudad del Cabo) y Medio Oriente (Baréin).\]](http://docs.aws.amazon.com/es_es/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-no-bias-new.png)


En el siguiente mapa se muestra lo que sucede si agrega un sesgo de \$125 para la región Oeste de EE. UU. (Oregón) (número **1** en el mapa). El tráfico se enruta al recurso de esa región desde una parte mayor de Norteamérica que antes y desde toda Sudamérica.

![\[Un mapa del mundo que muestra cómo se dirige el tráfico cuando se agrega un sesgo de +25 en la región EE. UU. Este (Norte de Virginia).\]](http://docs.aws.amazon.com/es_es/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-plus25-new.png)


En el siguiente mapa se muestra lo que sucede si cambia el sesgo a -25 para la región Oeste de EE. UU. (Oregón). **El tráfico se enruta al recurso de esa región desde partes más pequeñas de Norteamérica y Sudamérica que antes, y se dirige más tráfico a los recursos de las regiones **2**, **3** y 4 adyacentes.** 

![\[Un mapa del mundo donde se muestra cómo se enruta el tráfico cuando se agrega un sesgo de -25 en la región Oeste de EE. UU. (Oregón).\]](http://docs.aws.amazon.com/es_es/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-minus25-new.png)


------
#### [ Old console ]

El siguiente mapa muestra cuatro Regiones de AWS (numerados del 1 al 4) y una ubicación en Johannesburgo (Sudáfrica) que se especifica por latitud y longitud (5).

**nota**  
Los mapas solo están disponibles con el Flujo de tráfico.

![\[Un mapa del mundo que muestra cómo se enruta el tráfico cuando tiene registros de geoproximidad de recursos en EE. UU. Oeste (Oregón), EE. UU. Este (Virginia del Norte), Europa (París) y Asia Pacífico (Tokio), y tiene un registro para una organización sin fines de lucro en Johannesburgo (Sudáfrica). Regiones de AWS AWS\]](http://docs.aws.amazon.com/es_es/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-no-bias.png)


El siguiente mapa muestra lo que sucede si agrega un sesgo de \$125 para la región Este de EE. UU. (Norte de Virginia) (número **2** en el mapa). El tráfico se direcciona al recurso de esa región desde una parte mayor de Norteamérica que antes y desde toda Sudamérica.

![\[Un mapa del mundo que muestra cómo se dirige el tráfico cuando se agrega un sesgo de +25 en la región EE. UU. Este (Norte de Virginia).\]](http://docs.aws.amazon.com/es_es/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-plus-25.png)


El siguiente mapa muestra lo que sucede si cambia el sesgo a -25 para la región Este de EE. UU. (Norte de Virginia). El tráfico se direcciona al recurso de esa región desde partes más pequeñas de América del Norte y del Sur que antes, y más tráfico se direcciona a los recursos de las regiones adyacentes **1**, **3** y **5**. 

![\[Un mapa del mundo que muestra cómo se enruta el tráfico cuando se agrega un sesgo de -25 en la región Este de EE. UU. (Norte de Virginia).\]](http://docs.aws.amazon.com/es_es/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-minus-25.png)


------

El efecto de cambiar el sesgo de sus recursos depende de una serie de factores, entre los que se incluyen los siguientes:
+ El número de recursos de los que dispone.
+ Lo cercanos que están los recursos están entre si.
+ El número de usuarios que haya cerca de la zona fronteriza entre regiones geográficas. Por ejemplo, supongamos que tiene recursos en Regiones de AWS EE.UU. Este (Norte de Virginia) y EE.UU. Oeste (Oregón), y tiene muchos usuarios en Dallas, Austin y San Antonio, Texas, EE. UU. Esas ciudades están aproximadamente a la misma distancia entre sus recursos, por lo que un pequeño cambio en el sesgo podría provocar un gran cambio en el tráfico de los recursos de una Región de AWS a otra.

Le recomendamos que cambie el sesgo en incrementos pequeños para evitar desbordar los recursos debido a una oscilación no prevista en el tráfico.

Para obtener más información, consulte [Cómo utiliza Amazon Route 53 EDNS0 para estimar la ubicación de un usuario](routing-policy-edns0.md).

## Cómo utiliza Amazon Route 53 el sesgo para dirigir el tráfico
<a name="routing-policy-geoproximity-bias"></a>

Esta es la fórmula que Amazon Route 53 utiliza para determinar cómo dirigir el tráfico:

**Sesgo**  
`Biased distance = actual distance * [1 - (bias/100)]`

Cuando el valor del sesgo es positivo, Route 53 trata el origen de una consulta de DNS y el recurso que especifique en un registro de geoproximidad (como una instancia de EC2 en un registro Región de AWS) como si estuvieran más cerca de lo que realmente están. Suponga, por ejemplo, que tiene los siguientes registros de geoproximidad:
+ Un registro para el servidor web A, que tiene un sesgo positivo de 50.
+ Un registro para el servidor web B, que no tiene sesgos.

Cuando un registro de geoproximidad tiene un sesgo positivo de 50, Route 53 recorta a la mitad la distancia entre el origen de una consulta y el recurso para el registro. A continuación, Route 53 calcula qué recurso está más cerca del origen de la consulta. Supongamos que un servidor web A está a 150 kilómetros del origen de la consulta y que el servidor web B está a 100 kilómetros de dicho origen. Si ningún registro tiene un sesgo, Route 53 dirigirá la consulta al servidor web B porque está más cerca. No obstante, dado que el registro del servidor web A tiene un sesgo positivo de 50, Route 53 considera al servidor web A como si estuviera a 75 kilómetros del origen de la consulta. Como resultado, Route 53 dirige la consulta al servidor web A. 

Este es el cálculo de un sesgo positivo de 50:

```
Bias = 50
Biased distance = actual distance * [1 - (bias/100)]

Biased distance = 150 kilometers * [1 - (50/100)]
Biased distance = 150 kilometers * (1 - .50)
Biased distance = 150 kilometers * (.50)
Biased distance = 75 kilometers
```

# Enrutado basado en latencia
<a name="routing-policy-latency"></a>

Si la aplicación está alojada en varios servidores Regiones de AWS, puede mejorar el rendimiento de los usuarios atendiendo sus solicitudes desde el Región de AWS que ofrezca la latencia más baja. 

**nota**  
Los datos sobre la latencia entre los usuarios y sus recursos se basan totalmente en el tráfico entre los usuarios y los centros de datos de AWS . Si no utilizas los recursos en una Región de AWS, la latencia real entre tus usuarios y tus recursos puede variar considerablemente de los datos de AWS latencia. Esto es así aunque sus recursos se encuentren en la misma ciudad que una región de Región de AWS.

Para utilizar el enrutamiento basado en la latencia, debe crear registros de latencia para los recursos en varias Regiones de AWS. Cuando recibe una consulta de DNS para su dominio o subdominio (ejemplo.com o acme.ejemplo.com), Route 53 determina para qué Regiones de AWS usted ha creado registros de latencia, decide qué región ofrece a los usuarios la menor latencia y, finalmente, selecciona un registro de latencia para dicha región. Route 53 responde con el valor del registro seleccionado, como la dirección IP de un servidor web. 

Por ejemplo, suponga que tiene equilibradores de carga elásticos en la región Oeste de EE. UU. (Oregón) y en la región Asia-Pacífico (Singapur). Crea un registro de latencia para cada equilibrador de carga. Esto es lo que ocurre cuando un usuario en Londres escribe el nombre de su dominio en un navegador:

1. DNS dirige la consulta a un servidor de nombres de Route 53.

1. Route 53 consulta los datos sobre latencia entre Londres y la región de Singapur, y entre Londres y la región de Oregón. 

1. Si la latencia es menor entre las regiones de Londres y Oregón, Route 53 responde a la consulta con la dirección IP del equilibrador de carga de Oregón. Si la latencia es menor entre las regiones de Londres y Singapur, Route 53 responde a la consulta con la dirección IP del equilibrador de carga de Singapur. 

La latencia entre hosts en Internet puede cambiar con el tiempo como consecuencia de los cambios en la conectividad de la red y el direccionamiento. El enrutamiento basado en la latencia se fundamenta en mediciones de latencia realizadas durante un periodo, y estas mediciones reflejan estos cambios. Una solicitud que se direccionó a la región de Oregón esta semana puede enrutarse a la región de Singapur la próxima semana.

**nota**  
Cuando un navegador u otro visor utiliza una resolución de DNS que admite la edns-client-subnet extensión de EDNS0, la resolución de DNS envía a Route 53 una versión truncada de la dirección IP del usuario. Si configura el direccionamiento basado en la latencia, Route 53 considera este valor al dirigir el tráfico a sus recursos. Para obtener más información, consulte [Cómo utiliza Amazon Route 53 EDNS0 para estimar la ubicación de un usuario](routing-policy-edns0.md).

Puede utilizar una política de enrutamiento de latencia para los registros de una zona alojada privada.

Para obtener información acerca de los valores que especifica cuando se utiliza la política de direccionamiento de latencia para crear registros, consulte los siguientes temas:
+ [Valores específicos de registros de latencia](resource-record-sets-values-latency.md)
+ [Valores específicos de registros de alias de latencia](resource-record-sets-values-latency-alias.md)
+ [Valores comunes a todas las políticas de enrutamiento](resource-record-sets-values-shared.md)
+ [Valores comunes de registros de alias para todas las políticas de enrutamiento](resource-record-sets-values-alias-common.md)

# Enrutado basado en latencia en zonas alojadas privadas
<a name="routing-policy-latency-phz"></a>

En el caso de las zonas alojadas privadas, Route 53 responde a las consultas de DNS con un punto final que se encuentra en el mismo Región de AWS punto final de la VPC Región de AWS de la que se originó la consulta o que está más cerca en cuanto a la distancia de la misma.

**nota**  
Si se reenvía un punto de conexión saliente a un punto de conexión entrante, el registro se resolverá en función de dónde se encuentre el punto de conexión entrante, no el punto de conexión saliente.

Si incluye comprobaciones de estado y el registro con la latencia más baja hasta el origen de la consulta no está en buen estado, se devuelve un punto de conexión en buen estado con la siguiente latencia más baja.

En la configuración de ejemplo de la siguiente figura, las consultas de DNS procedentes de un Región de AWS us-east-1, o el más cercano a él, se enrutarán al punto final 1.1.1.1. Las consultas de DNS de us-west-2, o las más cercanas a esa región, se enrutarán al punto de conexión 2.2.2.2.

![\[Una captura de pantalla que muestra dos registros de latencia para una zona alojada privada.\]](http://docs.aws.amazon.com/es_es/Route53/latest/DeveloperGuide/images/latency-phz.png)


# Direccionamiento basado en IP
<a name="routing-policy-ipbased"></a>

Con el enrutamiento basado en IP en Amazon Route 53, puede ajustar su enrutamiento DNS usando lo que sabe acerca de su red, aplicaciones y clientes para tomar las mejores decisiones de enrutamiento DNS para sus usuarios finales. El enrutamiento basado en IP le brinda un control detallado para optimizar el rendimiento o reducir los costos de la red al cargar sus datos a Route 53 en forma de mapeos. user-IP-to-endpoint

El enrutamiento basado en la geolocalización y la latencia se basa en los datos que Route 53 recopila y mantiene actualizados. Este enfoque funciona bien para la mayoría de los clientes, pero el enrutamiento basado en IP le ofrece la capacidad adicional de optimizar el enrutamiento en función del conocimiento específico de su base de clientes. Por ejemplo, un proveedor de contenidos global de video puede querer enrutar a los usuarios finales de un determinado proveedor de servicio de Internet (ISP).

Algunos casos de usos comunes para el enrutamiento basado en IP son los siguientes:
+ Desea dirigir a los usuarios finales desde determinados puntos finales a puntos finales específicos ISPs para poder optimizar los costos o el rendimiento del tránsito de la red.
+ Desea agregar anulaciones a los tipos de enrutamiento de Route 53 existentes, como el enrutamiento de geolocalización basado en su conocimiento de las ubicaciones físicas de sus clientes.

**Administrar los rangos de IP y asociarlos a un conjunto de registros de recursos () RRSet**  
 Para IPv4, puede usar bloques CIDR de entre 1 y 24 bits de longitud, ambos inclusive, mientras que paraIPv6, puede usar bloques CIDR de entre 1 y 48 bits de longitud, ambos inclusive. Para definir un bloque de CIDR de cero bits (0.0.0.0/0 o: ::/0), utilice la ubicación predeterminada (“\$1”).

Para consultas DNS con un CIDR más largo que el especificado en la colección CIDR, Route 53 las asociará con el CIDR más corto. Por ejemplo, si especificas 2001:0DB8: :/32 como bloque CIDR de tu colección CIDR y una consulta se origina en DB8 2001:0:0000:1234: :/48, coincidirá. Si, por otro lado, especifica 2001:0DB8: 0000:1234: :/48 en su colección CIDR y una consulta se origina en 2001:0DB8: :/32, no coincidirá y Route 53 responderá con el registro de la ubicación predeterminada («\$1»).

Puede agrupar conjuntos de bloques CIDR (o rangos de IP) en ubicaciones CIDR, que a su vez se agrupan en entidades reutilizables llamadas colecciones CIDR:

**Bloque CIDR**  
Un rango de IP en notación CIDR, por ejemplo, 192.0.2.0/24 o 2001:: :/32. DB8

**Ubicación CIDR**  
Una lista con nombre de bloques CIDR. Por ejemplo, example-isp-seattle = [192.0.2.0/24, 203.0.113.0/22, 198.51.100.0/24, 2001: :/32]. DB8 Los bloques de una lista de localización CIDR no tienen por qué ser adyacentes o del mismo rango.   
Una única ubicación puede tener IPv6 bloques IPv4 y, y esta ubicación se puede asociar a los conjuntos de registros A y AAAA, respectivamente.   
El nombre de la ubicación suele ser un lugar por convención, pero puede ser cualquier cadena, por ejemplo *Compañía-A*.

**Colección CIDR**  
Una colección de ubicaciones con nombre. Por ejemplo, mycollection = [example-isp-seattle, example-isp-tokyo].  
Los conjuntos de registros de recursos de enrutamiento basados en IP hacen referencia a una ubicación en una colección, y todos los conjuntos de registros de recursos para el mismo nombre y tipo de conjunto de registros deben hacer referencia a la misma colección. Por ejemplo, si crea sitios web en dos regiones y desea dirigir las consultas de DNS desde dos ubicaciones CIDR diferentes a un sitio web específico en función de las direcciones IP de origen, entonces ambas ubicaciones deben figurar en la misma colección CIDR.

No puede utilizar una política de enrutamiento basado en IP para los registros de una zona alojada privada.

Para obtener información sobre los valores que se especifican cuando se usa la política de enrutamiento basada en IP para crear registros, consulte los siguientes temas:
+ [Valores específicos para los registros basados en IP](resource-record-sets-values-ipbased.md)
+ [Valores específicos para los registros de alias basados en IP](resource-record-sets-values-ipbased-alias.md)
+ [Valores comunes a todas las políticas de enrutamiento](resource-record-sets-values-shared.md)
+ [Valores comunes de registros de alias para todas las políticas de enrutamiento](resource-record-sets-values-alias-common.md)

**Topics**
+ [Creación de una colección de CIDR con ubicaciones y bloques CIDR](resource-record-sets-creating-cidr-collection.md)
+ [Trabajo con ubicaciones y bloques CIDR](resource-record-sets-working-with-cidr-locations.md)
+ [Eliminar una colección CIDR](resource-record-sets-delete-cidr-collection.md)
+ [Mover una geolocalización a un enrutamiento basado en IP](resource-record-sets-move-geolocation-to-cidr.md)

# Creación de una colección de CIDR con ubicaciones y bloques CIDR
<a name="resource-record-sets-creating-cidr-collection"></a>



Para empezar, cree una colección de CIDR y agregue a ella bloques y ubicaciones CIDR.<a name="CIDR-collection-creating-procedure"></a>

**Para crear una colección de CIDR mediante la consola de Route 53**

1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. En el panel de navegación, elija **IP-based routing** (Enrutamiento basado en IP) y, luego, **CIDR collections** (Recopilaciones de CIDR).

1. Seleccione **Create CIDR collection** (Crear una colección de CIDR).

1. En el panel **Create CIDR collection** en **Details** (Detalles), ingrese un nombre para la colección.

1. Elija **Create collection** (Crear colección) para crear una colección vacía.

   -o bien-

   En la sección **Crear ubicaciones del CIDR**, introduzca un nombre para la ubicación del CIDR en el cuadro de **Ubicación del CIDR**. El nombre de la ubicación puede ser cualquier cadena identificativa, por ejemplo **company 1**, o bien **Seattle**. No tiene por qué ser una ubicación geográfica real.
**importante**  
El nombre de la ubicación del CIDR tiene una longitud máxima de 16 caracteres.

   Introduzca los bloques del CIDR en el cuadro **Bloques del CIDR**, uno por línea. Pueden ser IPv6 direcciones IPv4 o direcciones comprendidas entre /0 y /24 y entre /0 IPv4 y /48. IPv6

1. Una vez ingresados los bloques CIDR, elija **Create CIDR collection**, o bien **Add another location** (Agregar otra ubicación) ingresando ubicaciones y bloque CIDR. Puede introducir varias ubicaciones CIDR por colección.

1. Una vez ingresadas las ubicaciones CIDR, seleccione **Create CIDR collection**.

# Trabajo con ubicaciones y bloques CIDR
<a name="resource-record-sets-working-with-cidr-locations"></a>

<a name="CIDR-locations-work-with-procedure"></a>

**Para trabajar con ubicaciones CIDR mediante la consola de Route 53**

1. Inicie sesión en la consola de Route Consola de administración de AWS 53 y ábrala en. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)

1. En el panel de navegación, seleccione **Enrutamiento basado en IP**, **Recopilaciones de CIDR** y, a continuación, en la sección **Recopilaciones de CIDR**, haga clic en un enlace a una recopilación de CIDR en la lista **Nombre de la recopilación**.

   En la página **CIDR locations** (Ubicaciones CIDR), puede crear una ubicación CIDR, eliminarla o editar una ubicación y sus bloques.
   + Para crear una ubicación, seleccione **Create CIDR location** (Crear ubicación CIDR). 
   + En el panel **Create CIDR location**, ingrese un nombre para la ubicación, los bloques CIDR asociados con la ubicación y, luego, seleccione **Create** (Crear).
   + Para ver una ubicación CIDR y los bloques que contiene, elija el botón de opción situado junto a una ubicación para mostrar su nombre y los bloques CIDR en el panel de ubicación.

     En este panel, también puede elegir **Editar** para actualizar el nombre de la ubicación o sus bloques CIDR. Cuando haya terminado de editar, elija **Save** (Guardar).
   + Para eliminar una ubicación CIDR y los bloques de su interior, seleccione el botón de opción situado junto a la ubicación que desea eliminar y, a continuación, seleccione **Delete** (Borrar). Para confirmar la eliminación, escriba el nombre de la ubicación en el campo de entrada de texto y elija **Delete** de nuevo.
**importante**  
No se puede deshacer la eliminación de una ubicación CIDR. Si tiene algún registro DNS asociado a la ubicación, es posible que no se pueda acceder a su dominio.

# Eliminar una colección CIDR
<a name="resource-record-sets-delete-cidr-collection"></a>

<a name="CIDR-collection-delete-procedure"></a>

**Para eliminar una colección CIDR, sus ubicaciones y bloques mediante la consola de Route 53**

1. Inicie sesión en la consola de Route 53 Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).

1. En el panel de navegación, elija **IP-based routing** (Enrutamiento basado en IP) y, luego, **CIDR collections** (Recopilaciones de CIDR).

1. En la sección **CIDR collections**, haga clic en el nombre vinculado de la colección que desea eliminar.

1. En la página **CIDR locations** (Ubicaciones CIDR), seleccione cada ubicación de una en una, elija **Delete** (Eliminar), ingrese su nombre en el cuadro de diálogo y luego elija **Delete**. Debe eliminar cada ubicación asociada a una colección CIDR para poder eliminar la colección.

1. Una vez finalizada la eliminación de cada ubicación CIDR, en la página **CIDR locations**, elija el botón de opción junto a la colección que desea eliminar y, a continuación, elija **Delete**.

# Mover una geolocalización a un enrutamiento basado en IP
<a name="resource-record-sets-move-geolocation-to-cidr"></a>

Si usa políticas de enrutamiento de geolocalización o geoproximidad, y ve constantemente clientes específicos enrutados a un punto de conexión que no es óptimo basado en su ubicación física o topología de red, puede orientar mejor los rangos de IP pública de estos clientes mediante el enrutamiento basado en IP.

La siguiente tabla contiene un ejemplo de configuración de geolocalización para un enrutamiento de geolocalización existente que afinaremos para los rangos IP de California.


| Nombre del conjunto de registros | Política de enrutamiento y origen | Dirección IP del punto de conexión de la aplicación  | 
| --- | --- | --- | 
|  example.com  |  Enrutamiento de geolocalización (EE. UU.)  |  `198.51.100.1`  | 
|  example.com  |  Enrutamiento de geolocalización (UE)   |  `198.51.100.2`  | 

Para anular los rangos de IP de California para ir a un nuevo punto de conexión de la aplicación, primero vuelva a crear el enrutamiento de geolocalización bajo un nuevo nombre de conjunto de registros.


| Nombre del conjunto de registros | Política de enrutamiento y origen | Dirección IP del punto de conexión de la aplicación  | 
| --- | --- | --- | 
|  geo.ejemplo.com  |  Enrutamiento de geolocalización (EE.UU.)  |  `198.51.100.1`  | 
|  geo.ejemplo.com  |  Enrutamiento de geolocalización (UE)   |  `198.51.100.2`  | 

Luego, cree registros de enrutamiento basados en IP y un registro por defecto que apunte a su conjunto de registros de enrutamiento de geolocalización recientemente recreado. 


| Nombre del conjunto de registros | Política de enrutamiento y origen | Dirección IP del punto de conexión de la aplicación  | 
| --- | --- | --- | 
|  example.com  |  Enrutamiento basado en IP (predeterminado)   |  Registro de alias del punto de conexión de la aplicación geo.example.com que desea que sea el predeterminado. Por ejemplo, `198.51.100.1`.  | 
|  example.com  |  Enrutamiento basado en IP (rangos IP de California)   |  `198.51.100.3`  | 

# Direccionamiento de respuesta con varios valores
<a name="routing-policy-multivalue"></a>

El direccionamiento de respuesta con varios valores permite configurar Amazon Route 53 para devolver varios valores, como direcciones IP a los servidores web, en respuesta a las consultas de DNS. Puede especificar varios valores para casi cualquier registro, pero este direccionamiento también permite verificar el estado de cada recurso, por lo que Route 53 devuelve los valores únicamente para los recursos en buen estado. No es sustituto de un balanceador de carga, pero la capacidad de devolver varias direcciones IP (cuyo estado sea comprobable) constituye una forma de usar el DNS para mejorar la disponibilidad y el equilibrio de la carga.

Para dirigir el tráfico de forma aproximativa aleatoriamente a varios recursos, como servidores web, cree un registro de respuesta con varios valores para cada recurso y, de manera opcional, asocie una comprobación de estado de Route 53 a cada registro. Route 53 responde a las consultas de DNS con hasta ocho registros en buen estado y da diferentes respuestas a distintos solucionadores de DNS. Si un servidor web deja de estar disponible después de que un solucionador almacene una respuesta en memoria caché, el software de cliente puede intentar utilizar otra dirección IP en la respuesta.

Tenga en cuenta lo siguiente:
+ Si asocia una comprobación de estado a un registro de respuesta con varios valores, Route 53 responde a las consultas de DNS con la correspondiente dirección IP solo si se verifica que está en buen estado.
+ Si no asocia ninguna comprobación de estado a un registro de respuesta con varios valores, Route 53 siempre considera que el registro está en buen estado.
+ Si tiene ocho registros o menos en buen estado, Route 53 responde a todas las consultas de DNS con todos los registros en buen estado.
+ Cuando todos los registros están en mal estado, Route 53 responde a las consultas de DNS con hasta ocho registros en mal estado.

Puede utilizar una política de enrutamiento de respuesta con varios valores para los registros de una zona alojada privada.

Para obtener más información acerca de los valores que especifica cuando se utiliza la política de enrutamiento de respuesta multivalor para crear registros, consulte [Valores específicos de registros de respuesta de varios valores](resource-record-sets-values-multivalue.md) y [Valores comunes a todas las políticas de enrutamiento](resource-record-sets-values-shared.md).

# Direccionamiento ponderado
<a name="routing-policy-weighted"></a>

El direccionamiento ponderado permite asociar varios recursos a un solo nombre de dominio (example.com) o nombre de subdominio (acme.example.com) y elegir cuánto tráfico se redirige a cada recurso. Esto puede resultar útil para distintos fines, entre otros, equilibrar la carga y probar nuevas versiones de software.

Para configurar el direccionamiento ponderado, debe crear registros que tengan el mismo nombre y tipo para cada uno de sus recursos. Asigne a cada registro un peso relativo que se corresponda con la cantidad de tráfico que desea enviar a cada recurso. Amazon Route 53 envía el tráfico a un recurso en función del peso que se asigna al registro, como una proporción del peso total de todos los registros del grupo: 

![\[Fórmula para determinar cuánto tráfico se dirige a un recurso determinado: ponderación de un registro especificado/suma de las ponderaciones de todos los registros.\]](http://docs.aws.amazon.com/es_es/Route53/latest/DeveloperGuide/images/WRR_calculation.png)


Por ejemplo, si desea enviar una pequeña parte del tráfico a un recurso y el resto a otro recurso, puede especificar pesos de 1 y 255. El recurso con un peso de 1 se lleva una fracción de 1/256 del tráfico (1/(1\$1255)), y el otro recurso, 255/256 (255/(1\$1255)). Para modificar gradualmente el equilibrio puede cambiar los pesos. Si desea detener el envío de tráfico a un recurso, puede cambiar por 0 el peso de ese registro.

Para obtener información acerca de los valores que especifica cuando se utiliza la política de direccionamiento ponderado para crear registros, consulte los siguientes temas:
+ [Valores específicos de registros ponderados](resource-record-sets-values-weighted.md)
+ [Valores específicos de registros de alias ponderados](resource-record-sets-values-weighted-alias.md)
+ [Valores comunes a todas las políticas de enrutamiento](resource-record-sets-values-shared.md)
+ [Valores comunes de registros de alias para todas las políticas de enrutamiento](resource-record-sets-values-alias-common.md)

Puede utilizar una política de enrutamiento ponderado para los registros de una zona alojada privada.

## Comprobaciones de estado y enrutamiento ponderado
<a name="routing-policy-weighted-healthchecks"></a>

Si agrega comprobaciones de estado a todos los registros de un grupo de registros ponderados, pero asigna ponderaciones distintas de cero a algunos registros y ponderaciones cero a otros, las comprobaciones de estado funcionan igual que si todos los registros tuvieran ponderaciones distintas de cero con las excepciones siguientes:
+ Route 53 tiene en cuenta inicialmente solo los registros con ponderación distinta de cero, si los hubiera.
+ Si todos los registros con una ponderación mayor que 0 tienen un estado incorrecto, Route 53 tiene en cuenta los registros con ponderación cero.

En la siguiente tabla, se detalla el comportamiento cuando el registro de ponderación 0 incluye una comprobación de estado:


|   | Registro 1 | Registro 2 | Registro 3 | 
| --- |--- |--- |--- |
|  Peso  |  1  |  1  |  0  | 
|  ¿Incluye comprobación de estado?  |  Sí  |  Sí  |  Sí  | 
|  | 
| --- |
|  Health check status (Estado de la comprobación de estado)  |  Mal estado  |  Mal estado  |  Buen estado  | 
|  ¿Consulta de DNS respondida?  |  No  |  No  |  Sí  | 
|  | 
| --- |
|  Health check status (Estado de la comprobación de estado)  |  Mal estado  |  Mal estado  |  Mal estado  | 
| ¿Consulta de DNS respondida? |  Sí  |  Sí  |  No  | 
|  | 
| --- |
|  Health check status (Estado de la comprobación de estado)  |  Mal estado  |  Buen estado  |  Mal estado  | 
|  ¿Consulta de DNS respondida?  |  No  |  Sí  |  No  | 
|  | 
| --- |
|  Health check status (Estado de la comprobación de estado)  |  Buen estado  |  Buen estado  |  Mal estado  | 
|  ¿Consulta de DNS respondida?  |  Sí  |  Sí  |  No  | 
|  | 
| --- |
|  Health check status (Estado de la comprobación de estado)  |  Buen estado  |  Buen estado  |  Buen estado  | 
|  ¿Consulta de DNS respondida?  |  Sí  |  Sí  |  No  | 

En la siguiente tabla, se detalla el comportamiento cuando el registro de ponderación 0 no incluye una comprobación de estado:


|   | Registro 1 | Registro 2 | Registro 3 | 
| --- |--- |--- |--- |
|  Peso  |  1  |  1  |  0  | 
|  ¿Incluye comprobación de estado?  |  Sí  |  Sí  |  No  | 
|  | 
| --- |
|  Health check status (Estado de la comprobación de estado)  |  Buen estado  |  Buen estado  | N/A | 
| ¿Consulta de DNS respondida? | Sí |  Sí  | No | 
|  | 
| --- |
|  Health check status (Estado de la comprobación de estado)  |  Mal estado  |  Mal estado  |  N/A  | 
|  ¿Consulta de DNS respondida?  |  No  |  No  |  Sí  | 
|  | 
| --- |
|  Health check status (Estado de la comprobación de estado)  |  Mal estado  |  Buen estado  |  N/A  | 
| ¿Consulta de DNS respondida? |  No  |  Sí  |  No  | 

# Cómo utiliza Amazon Route 53 EDNS0 para estimar la ubicación de un usuario
<a name="routing-policy-edns0"></a>

Para mejorar la precisión de la geolocalización, la geoproximidad, el enrutamiento basado en IP y la latencia, Amazon Route 53 admite la extensión de. edns-client-subnet EDNS0 (EDNS0 añade varias extensiones opcionales al protocolo DNS). Route 53 edns-client-subnet solo se puede usar cuando los resolutores de DNS lo admiten:
+ Cuando un navegador u otro visor usa una resolución de DNS que no es compatible edns-client-subnet, Route 53 usa la dirección IP de origen de la resolución de DNS para aproximar la ubicación del usuario y responde a las consultas de geolocalización con el registro DNS de la ubicación de la resolución.
+ Cuando un navegador u otro visor utiliza una resolución de DNS compatible edns-client-subnet, la resolución de DNS envía a Route 53 una versión truncada de la dirección IP del usuario. Route 53 determina la ubicación del usuario a través de la dirección IP truncada, en lugar de hacerlo mediante la dirección IP de origen del solucionador de DNS; este método suele proporcionar una estimación más precisa de la ubicación del usuario. Después, Route 53 responde a las consultas de geolocalización con el registro de DNS de la ubicación del usuario.
+ EDNS0 no se aplica a las zonas alojadas privadas. En el caso de las zonas alojadas privadas, Route 53 utiliza los datos de los solucionadores de VPC en los Región de AWS que se encuentra la zona alojada privada para tomar decisiones de geolocalización y enrutamiento de latencia.

[Para obtener más información edns-client-subnet, consulte el RFC de la subred del cliente de EDNS y la subred del cliente en las solicitudes de DNS.](https://www.rfc-editor.org/rfc/rfc7871)