AWS Primeros Pasos
Administración de operaciones

El mecanismo de sincronización horaria interna de AWS - Amazon Time Sync Service y el diseño de smearing de segundos intercalares

Explicamos el mecanismo de Amazon Time Sync Service operado de forma independiente por AWS, la fuente de tiempo de alta precisión con GPS y relojes atómicos, la decisión de diseño de absorber los segundos intercalares mediante smearing y la importancia de la sincronización horaria en sistemas distribuidos.

Unos 12 min de lecturaRedacción y edición: Awashiro (あわしろ)

Por qué la sincronización horaria es importante en la nube

En los sistemas distribuidos, la sincronización horaria precisa es más importante de lo que se imagina. Los registros de CloudTrail, las métricas de CloudWatch, las escrituras condicionales de DynamoDB, el versionado de objetos de S3 y la verificación de validez de certificados TLS son ejemplos de que prácticamente todos los servicios de AWS dependen de un tiempo preciso. Si el reloj se desfasa, la cronología de los registros se desordena y la investigación de incidentes se vuelve difícil. La verificación de validez de certificados TLS puede funcionar incorrectamente, juzgando como inválido un certificado que es válido. La autenticación Kerberos (Active Directory) rechaza la autenticación si la diferencia horaria entre cliente y servidor supera los 5 minutos. En bases de datos distribuidas, el desfase horario afecta directamente la consistencia de los datos. La razón por la que la base de datos Spanner de Google proporciona la API TrueTime usando relojes atómicos y GPS es para garantizar la consistencia de las transacciones distribuidas mediante la precisión del tiempo. AWS también ofrece su propia solución para este desafío: Amazon Time Sync Service.

Mecanismo de Amazon Time Sync Service

Amazon Time Sync Service es una fuente de tiempo de alta precisión ubicada en cada región de AWS. Desde las instancias EC2 se puede acceder al servidor NTP (Network Time Protocol) a través de la dirección link-local 169.254.169.123. Esta dirección, al igual que la 169.254.169.254 del servicio de metadatos, es link-local, no depende de la configuración de red y está disponible inmediatamente después del inicio de la instancia. En IPv6, solo en las instancias basadas en Nitro System, se dispone de un endpoint link-local fd00:ec2::123 (a fecha de agosto de 2026; según la documentación oficial). Ninguna de estas rutas pasa por un internet gateway ni por NAT, por lo que la sincronización horaria se completa incluso en instancias sin ruta de comunicación saliente. La fuente de tiempo del Time Sync Service son relojes de referencia conectados por satélite y relojes atómicos desplegados de forma redundante en cada región. La fuente de tiempo del lado del satélite también es un reloj atómico, y AWS combina el tiempo recibido de los satélites con los relojes atómicos locales para poder continuar la distribución de UTC (Tiempo Universal Coordinado) aunque la señal satelital se interrumpa temporalmente. Además, si se crea un grupo de ubicación (placement group) de EC2 con la estrategia precision-time y se lanza un tipo de instancia compatible, se habilita la versión ampliada de Amazon Time Sync Service. En esta configuración, el controlador ENA expone un reloj de hardware PTP (PHC) como dispositivo, lo que permite consultar directamente el reloj de hardware sin pasar por NTP. La sincronización a través del PHC ofrece precisión de microsegundos, no tiene coste adicional y está disponible en todas las regiones comerciales de AWS (el único sistema operativo compatible es Linux; a fecha de agosto de 2026; según la documentación oficial). La diferencia respecto a una configuración que usa servidores NTP públicos de Internet (pool.ntp.org, etc.) está en que la ruta se completa dentro de la VPC y en que este PHC permite consultar directamente el reloj de hardware.

Smearing de segundos intercalares - Un diseño que no crea las 23:59:60

El segundo intercalar es un mecanismo que inserta 1 segundo en UTC (Tiempo Universal Coordinado) para compensar las variaciones en la velocidad de rotación de la Tierra. Cuando se inserta un segundo intercalar, después de las 23:59:59 aparece las 23:59:60, un tiempo que normalmente no existe. Estas 23:59:60 son un valor inesperado para muchos programas y en el pasado han sido el detonante de múltiples incidentes a gran escala. En la inserción del segundo intercalar de 2012, un defecto del kernel de Linux se convirtió en un problema, y se conocen casos en los que los servidores que recibieron ese tiempo sufrieron picos de carga de CPU o se colgaron. La ruta NTP de Amazon Time Sync Service procesa los segundos intercalares mediante "smearing". A lo largo de las 24 horas que rodean el segundo intercalar (12 horas antes y 12 después), distribuye uniformemente 1 segundo y entrega cada segundo como 1 + 1/86400 segundos (aproximadamente 11.6 microsegundos más largo de lo normal). Por lo tanto, el tiempo 23:59:60 nunca aparece; en su lugar, solo durante esas 24 horas los relojes de AWS se desvían hasta 0.5 segundos del tiempo civil estándar (a fecha de agosto de 2026; según la explicación oficial). Lo importante es que este tratamiento difiere según la ruta que se utilice. Los endpoints NTP link-local (169.254.169.123 / fd00:ec2::123) y el endpoint público time.aws.com devuelven un tiempo con smearing, mientras que la ruta del reloj de hardware PTP (PHC) no aplica smearing e inserta el segundo intercalar tal cual, como establece UTC. AWS no recomienda mezclar fuentes de tiempo con smearing y sin smearing en la misma configuración del cliente de tiempo durante un evento de segundo intercalar. Los servidores NTP públicos de otros proveedores también pueden adoptar smearing, pero la forma de distribuir ese segundo no es necesariamente la misma, por lo que mezclar fuentes de tiempo con métodos distintos puede provocar inconsistencias horarias. Cabe señalar que la abolición del propio segundo intercalar para 2035 ya fue decidida por la 27.ª Conferencia General de Pesas y Medidas, y AWS indica expresamente en su documentación oficial que apoya plenamente esta decisión (a fecha de agosto de 2026). Tras la abolición, el propio concepto de smearing dejará de ser necesario, pero hasta entonces es necesario saber si la fuente de tiempo que se utiliza es una ruta que aplica smearing.

ClockBound - Visualización de la incertidumbre del tiempo

ClockBound, publicado como código abierto por AWS, es un daemon y una biblioteca para manejar el "rango de incertidumbre" del tiempo actual. El tiempo sincronizado por NTP contiene errores debidos a la latencia de red y la deriva del reloj. ClockBound calcula los límites superior e inferior de este error (el clock error bound) y proporciona a las aplicaciones la información de que "el tiempo verdadero actual está en el rango de X ± Y". Esta información puede usarse para el ordenamiento de transacciones en bases de datos distribuidas. Si la diferencia de timestamps entre dos eventos está dentro del rango de incertidumbre, no se puede determinar cuál ocurrió primero. Si excede el rango de incertidumbre, se puede determinar el orden. Un punto a tener en cuenta: en una configuración que se sincroniza directamente con el reloj de hardware PTP, el daemon de sincronización horaria chrony asume que el error del reloj de referencia es cero, por lo que el rango de error se estima menor de lo que realmente es. Por ello, Nitro System expone el límite de error del PHC como phc_error_bound (en nanosegundos) en /sys/bus/pci/devices/<PCI_SLOT_NAME>/phc_error_bound, y ClockBound incorpora este valor para calcular un rango de error razonable (el único sistema operativo compatible es Linux; a fecha de agosto de 2026; según la documentación oficial). Es un concepto similar a la API TrueTime de Google Spanner, pero ClockBound es de código abierto y puede usarse en entornos fuera de AWS. Cuando se usan servicios gestionados como DynamoDB y Aurora, el tratamiento de la consistencia derivada del tiempo queda cerrado del lado del servicio. En cambio, cuando los usuarios construyen sus propios sistemas distribuidos, pueden prevenir inconsistencias de datos causadas por el tiempo aprovechando ClockBound.

Problemas reales causados por fallos en la sincronización horaria

Los problemas de sincronización horaria tienen síntomas difíciles de identificar y causas difíciles de determinar. Presentamos algunos patrones de problemas que ocurren en la práctica. Primero, el fallo de verificación de certificados TLS. Si el reloj de la instancia se adelanta al futuro, un certificado aún válido se juzga como "expirado". Si se atrasa al pasado, se juzga como "aún no ha entrado en su período de validez". Cuando las comunicaciones HTTPS comienzan a fallar repentinamente, el desfase horario puede ser la causa. Segundo, el fallo de autenticación de la API de AWS. La firma SigV4 incluye un timestamp, y si el reloj de la instancia se desvía del tiempo de AWS más allá de cierto margen, la solicitud es rechazada por quedar fuera del período de validez de la firma. Como el margen de desviación tolerado varía según el servicio y la forma de pasar la firma (firma en la cabecera Authorization o URL prefirmada), la premisa es mantener la propia sincronización horaria siempre en buen estado, en lugar de operar asumiendo un número concreto de minutos. Tercero, el desorden cronológico de los registros. Al agregar registros de múltiples instancias, los registros de instancias con desfase horario no se ordenan cronológicamente, dificultando la investigación de incidentes. Como medida, configure chrony (cliente NTP) en todas las instancias EC2 y use Amazon Time Sync Service (169.254.169.123 o fd00:ec2::123) como fuente de tiempo. En Amazon Linux 2023 y las versiones recientes de Amazon Linux 2, la configuración que usa el endpoint IPv4 está habilitada por defecto (a fecha de agosto de 2026; según la documentación oficial). Para cargas de trabajo que requieren precisión de microsegundos, considere combinar un grupo de ubicación precision-time con el reloj de hardware PTP. No obstante, es necesario decidir de antemano la configuración de las fuentes de tiempo para no mezclar la ruta NTP con smearing y la ruta PHC sin smearing durante un evento de segundo intercalar.

Referencias (recursos oficiales de AWS)

Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.

Si esta página y la documentación oficial difieren, prevalece la documentación oficial.

Servicios relacionados

Amazon CloudWatch EsencialUn servicio que proporciona monitoreo, gestión de logs y alarmas para recursos AWS y aplicacionesAWS CloudTrail EsencialUn servicio que registra y monitorea la actividad de API en cuentas AWS

Artículos relacionados

La cultura de excelencia operativa de AWS - Calidad operativa respaldada por GameDay, Wheel of Fortune y Ops as CodeExplicamos las prácticas de GameDay (simulación de fallos), Wheel of Fortune (inyección aleatoria de fallos) y Ops as Code que AWS implementa organizacionalmente para elevar la calidad operativa, comparándolas con los enfoques operativos de Azure y GCP.Lecciones de sistemas distribuidos de los informes de incidentes (COE) de AWS - Principios de diseño que cambiaron las grandes interrupciones del pasadoA partir de los Correction of Errors (COE) e informes de incidentes publicados por AWS, explicamos las causas raíz de grandes incidentes pasados como la interrupción de S3, la interrupción de DNS en us-east-1 y la interrupción de Kinesis, y cómo cambiaron los principios de diseño de AWS.Por qué DynamoDB garantiza milisegundos de un dígito - Estructura interna del particionamiento y el router de solicitudesExplicamos el mecanismo por el cual DynamoDB mantiene latencia de milisegundos de un dígito independientemente de la escala, desde la arquitectura de 3 capas: algoritmo de particionamiento, router de solicitudes y nodos de almacenamiento.

Más sobre este tema

Centralización de registros de auditoría SaaS con AWS AppFabric - Estandarización OCSF e integración con Security LakeExplicamos la recopilación de registros de auditoría de aplicaciones SaaS con AppFabric, la estandarización al formato OCSF y la construcción de pipelines de análisis.Implementación de Feature Flags con AWS AppConfig - Despliegue seguro de configuración y rollbackDespliega cambios de configuración de forma independiente al código mediante estrategias Linear y Exponential. Garantiza la seguridad con rollback automático activado por alarmas de CloudWatch.Revisión de arquitectura - Evaluación sistemática de cargas de trabajo con AWS Well-Architected ToolExplica la revisión de arquitectura de cargas de trabajo usando AWS Well-Architected Tool. Presenta la evaluación basada en 6 pilares, la elaboración de planes de mejora y el uso de lentes personalizados.Diseño y operación de logs de auditoría - Registro completo de actividad API con CloudTrailExplica las técnicas de diseño de logs de auditoría con AWS CloudTrail, el registro de actividad API, el almacenamiento a largo plazo en S3 y la respuesta de cumplimiento mediante integración con Config.Lecciones de sistemas distribuidos de los informes de incidentes (COE) de AWS - Principios de diseño que cambiaron las grandes interrupciones del pasadoA partir de los Correction of Errors (COE) e informes de incidentes publicados por AWS, explicamos las causas raíz de grandes incidentes pasados como la interrupción de S3, la interrupción de DNS en us-east-1 y la interrupción de Kinesis, y cómo cambiaron los principios de diseño de AWS.El diseño de tags determina las operaciones - Curiosidades y reglas de nomenclatura prácticas de la estrategia de tags de recursos AWSExplicamos por qué los tags de recursos AWS no son simples etiquetas sino la base de la asignación de costos, control de acceso y automatización, las reglas de nomenclatura de claves de tags, cómo usar el límite de 50 tags y la gobernanza mediante políticas de tags.Por qué existen las cuotas de servicio de AWS - Diseño multitenant que protege la infraestructura compartidaExplicamos que las cuotas de servicio de AWS (antes límites de servicio) no son simples restricciones sino un diseño para proteger a otros clientes en un entorno multitenant, desde el problema del vecino ruidoso, la diferencia entre límites soft y hard, y el trasfondo de las solicitudes de aumento.Gestion centralizada de backups con AWS Backup - Planes de backup y proteccion cross-regionGestione backups de EC2, RDS, DynamoDB y mas bajo una politica unificada. Cubre la proteccion WORM con Vault Lock y la automatizacion de pruebas de restauracion.

Artículos y servicios similares

Amazon AuroraBase de datos relacional nativa de la nube de AWS que ofrece hasta 5 veces el rendimiento de MySQL y hasta 3 veces el de PostgreSQLVentaja del primer movedor y economías de escala de AWS - Lo que significan 18 años de acumulación desde 2006Comparamos la ventaja del primer movedor que AWS ha construido desde que creó el mercado de nube pública en 2006, desde las perspectivas de amplitud y profundidad de los servicios, compatibilidad retroactiva de las APIs y profundidad del ecosistema, frente a Azure y GCP.AWS SignerServicio que aplica firmas digitales a código e imágenes de contenedores, verificando firmas en el despliegue para garantizar la integridad de la cadena de suministro de softwareEl mecanismo de throttling de las API de AWS - El algoritmo Token Bucket y la verdad detrás del error 429Explicamos cómo el rate limiting de las API de AWS se implementa con el algoritmo Token Bucket, el concepto de burst capacity, las diferencias en los límites según el servicio, y las medidas prácticas para evitar el throttling.Firma de código con AWS Signer - Garantizando la confianza en funciones Lambda e imágenes de contenedorAplicamos firma de código a funciones Lambda e imágenes de contenedor, imponemos la verificación de firmas en el despliegue e integramos con pipelines CI/CD.