Comprobaciones de estado y conmutación por error de DNS

Las comprobaciones de estado de Route 53 supervisan continuamente el estado de sus endpoints (servidores web, balanceadores de carga o cualquier endpoint HTTP/HTTPS/TCP accesible desde Internet). Según los resultados de las comprobaciones de estado, Route 53 puede actualizar automáticamente el enrutamiento de DNS para evitar enviar tráfico a recursos en mal estado.

Las comprobaciones de estado se facturan por comprobación y por mes. Los comprobadores de estado globales de Route 53, ubicados en varias regiones, sondean su endpoint simultáneamente, lo que proporciona redundancia en el propio proceso de comprobación. Un endpoint se considera en mal estado únicamente cuando un número mínimo de comprobadores coincide en que ha fallado.

Las comprobaciones de estado de endpoints supervisan una dirección IP o un nombre de dominio específicos mediante el protocolo que usted elija (HTTP, HTTPS o TCP), el puerto y una ruta opcional. En las comprobaciones HTTP/HTTPS, Route 53 verifica que el endpoint devuelva un código de estado HTTP 2xx o 3xx dentro del periodo de tiempo de espera. En las comprobaciones HTTPS, también puede validar el certificado TLS de forma opcional.

Opciones de configuración principales: intervalo de solicitud (10 o 30 segundos; 10 segundos permite detectar los fallos más rápido, pero tiene un coste mayor), umbral de fallos (de 1 a 10 fallos consecutivos antes de marcar el endpoint como no saludable) y coincidencia de cadenas (permite verificar que el cuerpo de la respuesta contenga una cadena específica).

Las comprobaciones de estado calculadas combinan los resultados de varias comprobaciones de estado secundarias mediante lógica booleana (AND, OR, NOT). Esto permite definir el estado de una aplicación basándose en varias señales sin crear cadenas de enrutamiento complejas.

Ejemplo: una aplicación web está saludable únicamente si pasan tanto la comprobación del servidor de API como la comprobación de la base de datos. Cree una comprobación de estado calculada de tipo AND que haga referencia a ambas comprobaciones de endpoints. Si alguna falla, la comprobación de estado calculada falla y Route 53 elimina de las respuestas el registro de DNS asociado.

Las comprobaciones de estado basadas en alarmas de CloudWatch vinculan una comprobación de estado de Route 53 al estado de una alarma de CloudWatch. Si la alarma se encuentra en estado ALARM, la comprobación de estado se marca como no saludable; si está en estado OK o INSUFFICIENT_DATA, se marca como saludable.

Este patrón resulta especialmente útil para endpoints dentro de una VPC, a los que no pueden acceder los comprobadores de estado externos de Route 53. En lugar de sondear el endpoint privado, cree métricas y alarmas de CloudWatch para él y, después, base la comprobación de estado de Route 53 en el estado de la alarma. Esto también permite realizar comprobaciones de estado basadas en métricas empresariales, como la tasa de errores o la profundidad de una cola.

Los comprobadores de estado de Route 53 son servidores administrados por AWS ubicados fuera de su VPC que acceden a los endpoints a través de Internet público. Los recursos de las subredes privadas no son accesibles mediante las comprobaciones de estado de endpoints estándar. Para los endpoints privados, utilice uno de estos enfoques:

• Publique una métrica personalizada de CloudWatch desde dentro de la VPC (por ejemplo, una señal de éxito o fallo de la aplicación), cree una alarma y utilice una comprobación de estado basada en una alarma de CloudWatch
• Utilice una alarma compuesta de CloudWatch que agregue métricas de ELB, RDS o de la aplicación dentro de la VPC

Este patrón es fundamental para bases de datos en subredes privadas, balanceadores de carga internos y servicios backend.

Puede consultar el estado de las comprobaciones de estado en la consola de Route 53, en Health Checks, o mediante la API. Route 53 publica métricas de comprobaciones de estado en CloudWatch, en el espacio de nombres AWS/Route53, incluidas HealthCheckStatus (1 = saludable, 0 = no saludable) y HealthCheckPercentageHealthy (porcentaje de comprobadores de Route 53 que informan de que el endpoint está saludable).

Configure alarmas de CloudWatch para HealthCheckStatus a fin de recibir notificaciones de SNS cuando un endpoint deje de estar saludable. Así tendrá visibilidad antes de que su equipo de guardia detecte que ya se ha producido la conmutación por error de DNS.

Cuando Route 53 detecta que ha fallado la comprobación de estado de un registro primario, elimina el primario de las respuestas DNS y devuelve la dirección del secundario. Esto se denomina conmutación por error de DNS. El cambio se produce dentro del periodo de evaluación (número de fallos de los comprobadores de estado × intervalo de solicitud), más el TTL del registro.

Ejemplo: intervalo de solicitud = 30 s, umbral de fallos = 3, TTL = 60 s. El tiempo máximo de conmutación por error es aproximadamente 3 × 30 + 60 = 150 segundos. Establecer un TTL menor (por ejemplo, 10 segundos) y un intervalo de comprobación de estado más rápido (10 s) puede reducirlo a 3 × 10 + 10 = 40 segundos.

Las comprobaciones de estado también pueden asociarse a registros ponderados y de latencia, no solo a registros de conmutación por error. Cuando falla la comprobación de estado de un registro ponderado, Route 53 redistribuye proporcionalmente el peso del tráfico de ese registro entre los registros ponderados saludables. Cuando falla la comprobación de estado de un registro de latencia, Route 53 dirige las consultas al siguiente registro saludable con menor latencia.

Esto hace que las políticas de enrutamiento ponderado y de latencia sean resistentes a los fallos de los endpoints sin necesidad de crear registros de conmutación por error explícitos. Es un patrón habitual de SAA-C03: el enrutamiento por latencia entre regiones, combinado con comprobaciones de estado, proporciona optimización del rendimiento y recuperación automática ante desastres.

Un patrón resistente activo-activo entre varias regiones mediante Route 53:

1. Cree registros de latencia para cada región (us-east-1, eu-west-1, ap-southeast-1), cada uno con una comprobación de estado
2. Cuando todas las regiones están saludables, los usuarios se dirigen a la región con menor latencia
3. Si falla la comprobación de estado de una región (porque la aplicación está caída o no responde), Route 53 la elimina automáticamente de las respuestas DNS y dirige las consultas a la siguiente región saludable más adecuada
4. Cuando la región afectada se recupera, la comprobación de estado vuelve a pasar y Route 53 la incorpora de nuevo a la rotación

Esto proporciona conmutación por error global automática con optimización del rendimiento, sin necesidad de intervención manual.

Los comprobadores de estado de Route 53 se originan en un conjunto de rangos de IP publicados en la sección ROUTE53_HEALTHCHECKS del archivo JSON de rangos de IP de AWS. Si su endpoint está protegido por un firewall o un grupo de seguridad que restringe el acceso entrante, debe permitir el tráfico procedente de estos rangos de IP para que las comprobaciones de estado se realicen correctamente.

Como alternativa, utilice un endpoint público que actúe como proxy hacia su backend privado (por ejemplo, un ALB) para realizar las comprobaciones de estado. El grupo de seguridad del ALB solo debe permitir los rangos de IP de Route 53, mientras que el grupo de seguridad del backend solo debe permitir el grupo de seguridad del ALB, manteniendo así un enfoque de defensa en profundidad.

Prácticas recomendadas para las comprobaciones de estado de Route 53:

• Cree un endpoint /health dedicado que compruebe todas las dependencias críticas (conectividad con la base de datos y accesibilidad de la caché) y devuelva 200 únicamente cuando todo funcione correctamente
• Utilice un intervalo de solicitud de 10 segundos para los endpoints críticos de producción, a fin de detectar los fallos más rápidamente
• Supervise HealthCheckPercentageHealthy en CloudWatch; un fallo parcial (cuando fallan algunos, pero no todos, los comprobadores de Route 53) puede indicar un problema de red regional o intermitente
• Para los recursos privados de una VPC, utilice comprobaciones de estado basadas en alarmas de CloudWatch y métricas de la aplicación
• Pruebe la conmutación por error en entornos que no sean de producción antes de depender de ella en producción

Compruebe sus conocimientos sobre los conceptos de AWS Solutions Architect (SAA-C03) tratados en esta lección.

En esta lección ha aprendido lo siguiente: las comprobaciones de estado de endpoints realizan sondeos HTTP/HTTPS/TCP desde comprobadores externos de Route 53; las comprobaciones de estado basadas en alarmas de CloudWatch permiten supervisar recursos privados de la VPC; y las comprobaciones de estado calculadas combinan varias señales mediante lógica booleana. La velocidad de la conmutación por error de DNS depende del intervalo de comprobación de estado, el umbral de fallos y el TTL. A continuación, analizaremos las distribuciones y los orígenes de CloudFront.