Descubrimiento de servicios con AWS Cloud Map - Resolución dinámica de nombres para microservicios

Descubra dinámicamente endpoints de microservicios usando enfoques basados en DNS y API. Aprenda cómo automatizar el registro y desregistro de servicios mediante integración con ECS y EKS.

Unos 8 min de lecturaÚltima actualización: 2026-10-31

Descripción general de Cloud Map

Cloud Map es un servicio que proporciona descubrimiento de servicios para los recursos de las aplicaciones. En una arquitectura de microservicios, cuando el servicio A llama al servicio B, el endpoint del servicio B no se codifica de forma fija, sino que se consulta a Cloud Map para resolverlo de forma dinámica. Ofrece dos tipos de métodos de descubrimiento, basado en DNS y basado en API, y se integra con ECS y EKS para automatizar el registro y desregistro de los servicios.

Descubrimiento DNS y API

Un espacio de nombres DNS registra los servicios como registros DNS y los resuelve con nombres DNS como service-b.my-namespace.local. Las aplicaciones existentes pueden descubrir los servicios mediante consultas DNS, sin necesidad de cambiar el código. Un espacio de nombres HTTP obtiene las instancias de servicio con la API DiscoverInstances y permite filtrar por atributos personalizados (version=v2, environment=prod). El descubrimiento de servicios de ECS registra automáticamente las instancias en Cloud Map cuando se inician las tareas y las desregistra automáticamente cuando se detienen. Los health checks de Route 53 detectan las instancias anómalas y las excluyen de los resultados del descubrimiento.

Integración con ECS y EKS

Al habilitar Cloud Map en un servicio de ECS, las instancias de servicio se registran y desregistran automáticamente en función del inicio y la detención de las tareas. En el descubrimiento basado en DNS se crean registros SRV o A en Route 53, y los clientes resuelven los servicios por su nombre DNS. En el descubrimiento basado en API se obtiene con la API DiscoverInstances la lista de instancias que han pasado el health check, y el balanceo de carga se implementa en el lado del cliente. En EKS se puede usar AWS Cloud Map MCS Controller para sincronizar automáticamente los Kubernetes Service con Cloud Map. Para los health checks se puede elegir entre los health checks de Route 53 y los health checks personalizados (un método en el que la aplicación llama a la API UpdateInstanceCustomHealthStatus).

Precios y operación de Cloud Map

El precio de Cloud Map se determina por el número de recursos registrados y el número de llamadas a la API. A las consultas DNS se les aplica la tarifa estándar de Route 53, y la API DiscoverInstances cuesta 1 USD por cada millón de solicitudes (a fecha de agosto de 2026). En los entornos de escalado automático, donde el registro y el desregistro de instancias se producen con frecuencia, aumenta el número de llamadas a la API, por lo que se implementa una caché en el lado del cliente para contener los costos. En el diseño de los espacios de nombres, se separa un espacio de nombres por entorno (dev/staging/prod) y se unifican los nombres de los servicios entre entornos, con lo que se elimina la dependencia del entorno en el código de la aplicación. Con las métricas de CloudWatch se monitorean el número de llamadas y la latencia de DiscoverInstances para detectar aumentos anómalos.

El papel como registro de servicios

Cloud Map funciona como un registro que anota qué servicios se ejecutan y dónde. En una configuración de microservicios, las instancias de los servicios aumentan y disminuyen, y su ubicación también cambia de forma dinámica, por lo que no se pueden dar por supuestos endpoints fijos. Si se registran en Cloud Map las instancias que están en funcionamiento, quien llama puede consultar y resolver siempre la ubicación más reciente. También cuando se combina con un mecanismo de nivel superior como una malla de servicios, este registro sirve de base. Al gestionar de forma centralizada la ubicación de los servicios, se consiguen llamadas estables incluso en entornos dinámicos.

Diseño de los health checks

Si en los resultados del descubrimiento se mezclan instancias anómalas, las llamadas acaban fallando. Cloud Map funciona junto con los health checks y se puede diseñar para que devuelva solo las instancias saludables. Existen un método que comprueba el estado a través de la red y otro en el que la propia aplicación informa de su estado de salud, y se elige según los requisitos. En los entornos de contenedores, el registro y el desregistro se automatizan en función del inicio y la detención de las tareas, por lo que se pueden evitar incidentes de envío a instancias detenidas. Los criterios de evaluación del estado y el intervalo de comprobación se configuran de forma adecuada para poder aislarlas rápidamente cuando se produce un fallo.

Uso fuera de los contenedores y en entornos híbridos

Cloud Map se integra fácilmente con ECS y EKS, pero también se pueden registrar otros recursos. Con la API se pueden registrar de forma manual o desde un programa instancias EC2, servidores on-premises y endpoints externos, y convertirlos en objetivos de la resolución de nombres con el mismo mecanismo. De este modo, incluso en entornos en los que conviven contenedores y servidores tradicionales, la ubicación de los servicios se puede tratar de forma centralizada. Poder descubrir de forma unificada los componentes nuevos y antiguos en sistemas en fase de migración o en aplicaciones con configuración híbrida ayuda a avanzar en una modernización gradual.

Comportamiento ante fallos y consideraciones de diseño

Al usar el descubrimiento de servicios, se presta atención al equilibrio entre la caché de los resultados de resolución y su actualidad. Al resolver con DNS, si el TTL es demasiado largo, permanece información antigua de las instancias y existe el riesgo de intentar conectarse a destinos ya detenidos. Por el contrario, si es demasiado corto, aumentan las consultas, lo que afecta al costo y a la latencia. El punto clave es un diseño que almacene en caché de forma adecuada en el lado del cliente y, al mismo tiempo, excluya rápidamente las anomalías con los health checks. En los entornos de escalado automático, donde el registro y el desregistro son frecuentes, aumentan las llamadas a la API, por lo que se ajusta la estrategia de caché para contener la carga y el costo y mantener una comunicación estable entre servicios.

Resumen

La vía de entrada más cómoda para introducir Cloud Map es la integración con el descubrimiento de servicios de ECS. Con solo habilitar Cloud Map en un servicio de ECS, se automatiza el registro de servicios vinculado al inicio y la detención de las tareas. Si las aplicaciones existentes resuelven nombres mediante DNS, se elige un espacio de nombres DNS; si se necesita filtrar por atributos personalizados, se elige un espacio de nombres HTTP. En el diseño de los espacios de nombres, se recomienda separarlos por entorno (dev/staging/prod) y unificar los nombres de los servicios entre entornos.

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.

Construcción de service mesh con AWS App Mesh - Control de comunicación entre microservicios y observabilidadPresentamos cómo configurar de forma declarativa despliegues canary con sidecar Envoy, políticas de reintento y cifrado mTLS, y cómo visualizar las dependencias entre servicios con la integración de X-Ray (AWS dejó de dar soporte a App Mesh el 30 de septiembre de 2026).Cómo funciona la selección de PoP de CloudFront - El enrutamiento DNS y la jerarquía de cachéExplicamos el mecanismo de enrutamiento basado en DNS con el que CloudFront dirige las solicitudes de los usuarios al PoP más cercano, la estructura de caché de varias capas formada por las ubicaciones de borde y las cachés de borde regionales, y los factores de diseño que determinan la tasa de aciertos de caché.Diseño de conexión dedicada - Conexión de red privada estable con Direct ConnectSe explican los métodos de diseño de conexiones de línea dedicada con AWS Direct Connect y se presenta cómo lograr una conexión de red privada estable mediante la elección entre conexión dedicada y conexión hospedada, la configuración redundante y la integración con VPC.Conexión dedicada con AWS Direct Connect - Configuración redundante y control de tráficoDiseñe configuraciones redundantes de conexión dedicada y conéctese a VPCs de múltiples regiones con Direct Connect Gateway. También presentamos la agregación de ancho de banda con LAG y el cifrado MACsec.Gestión y diseño de Elastic IP - Uso de IP estáticas y optimización de costosExplicamos la asignación de Elastic IP, la asociación con EC2, el impacto en costos de EIP no utilizadas y la consideración de alternativas.Por qué ELB se divide en 4 tipos - Detrás de las decisiones de diseño de ALB / NLB / GWLB / CLBSe explica por qué los 4 tipos de balanceadores de carga, ALB, NLB, GWLB y CLB (Classic), coexisten sin unificarse, a partir de las capas del modelo de referencia OSI, las características de rendimiento y la evolución histórica.Optimización de red global con AWS Global Accelerator - Entrega de baja latencia y failoverAprende a enrutar tráfico hacia la red global de AWS usando IPs Anycast, diseñar grupos de endpoints y lograr failover mediante health checks.Aceleración de red global - Entrega de baja latencia con AWS Global Accelerator y CloudFrontEnruta el tráfico hacia la red global de AWS tempranamente usando IPs Anycast para dirigir a los clientes a la ubicación de borde más cercana. Esta guía cubre la integración con ALB/NLB y el diseño de failover.