Cómo configurar Service Discovery en Amazon ECS con AWS Cloud Map

Por

Publicado el

Actualizado el

Revisado el

Service Discovery de Amazon ECS permite que una aplicación encuentre otras tareas por nombre DNS aunque sus direcciones IP cambien al escalar o desplegar. ECS registra las tareas de un servicio en AWS Cloud Map y Route 53 publica los registros DNS. Por ejemplo, una aplicación cliente puede conectarse a orders.apps.internal sin guardar las IP de las tareas en su configuración.

El DNS solo resuelve el nombre. El cliente abre la conexión directamente a la IP privada de una tarea; Service Discovery no transporta el tráfico, no abre puertos en los grupos de seguridad ni sustituye una capa de balanceo. La guía de Service Discovery de Amazon ECS explica esta integración.

Service Discovery, Service Connect o un balanceador

Elige según quién debe encontrar el servicio y cómo quieres encaminar las solicitudes.

Opción Resuelve Úsala cuando
ECS Service Discovery con Cloud Map Nombres DNS y direcciones privadas de las tareas Tus clientes pueden usar DNS normal y conectarse directamente al puerto del servicio.
Amazon ECS Service Connect Nombres cortos y puertos mediante un proxy administrado en las tareas Quieres administrar la comunicación entre servicios de ECS y observar su tráfico desde la configuración de ECS.
Application Load Balancer (ALB) Un punto de entrada HTTP o HTTPS delante de varios destinos Necesitas entrada desde fuera, enrutamiento por host o ruta, comprobaciones del balanceador o distribución de tráfico en la capa HTTP.

Service Discovery puede convivir con un balanceador, pero sus registros apuntan a las tareas, no al ALB. Para comparar las alternativas, consulta la guía de AWS para conectar servicios ECS y la documentación de Amazon ECS Service Connect.

Si quieres practicar una estrategia de despliegue que sí usa un ALB, el laboratorio comunitario ECS Canary in Action incluye un modo local y una opción con Terraform en AWS. Ese ejercicio trata los despliegues canary y el balanceo, no Cloud Map; su opción en AWS crea recursos como ECS, ALB, DynamoDB y alarmas de CloudWatch. Revisa sus instrucciones de limpieza antes de crear esa infraestructura.

Para conocer los fundamentos de ECS en formato charla, mira Containers en AWS: Construyendo el ecosistema de contenedores en ECS, una grabación de AWS User Group Ecuador de 2023. La charla aporta contexto sobre contenedores y ECS; no es una guía de Cloud Map.

Antes de configurarlo

Este recorrido supone que ya tienes una VPC, un clúster, una definición de tarea y una aplicación funcionando en un servicio de ECS.

Si necesitas repasar VPC, subredes y grupos de seguridad, consulta Conceptos básicos y avanzados de Amazon VPC. Para entender clústeres, tareas y servicios antes de seguir, empieza por Amazon ECS: qué es y cómo ejecutar tu primera tarea. Para ampliar los fundamentos de subredes y rutas, el encuentro virtual Amazon VPC Essentials: Fundamentos de Networking está anunciado para el 21 de octubre de 2026; requiere registro y tiene cupos limitados.

Elige el tipo de registro DNS

El modo de red determina qué datos ECS puede registrar:

Modo de red Registros admitidos Qué recibe el cliente
awsvpc A o SRV; también AAAA con subredes dual-stack. En subredes solo IPv6 no se puede crear A. A o AAAA devuelve una IP. SRV devuelve prioridad, peso, puerto y un nombre de destino que se resuelve con A o AAAA.
bridge o host Solo SRV SRV devuelve prioridad, peso, puerto y nombre de destino. La configuración de ECS debe indicar el nombre del contenedor y el puerto de contenedor de la definición de tarea.

Para Fargate con awsvpc y un puerto fijo, A suele ser la elección directa. Elige SRV cuando el cliente necesita obtener también el puerto y el nombre del destino. Una respuesta SRV no incluye la IP literal: el cliente resuelve el nombre de destino por separado. Consulta la configuración de DNS de AWS Cloud Map para ver sus campos.

Configuración con AWS CLI

Los ejemplos suponen que ya tienes una VPC, un clúster ECS y una definición de tarea probada. Crean un namespace y un registro de Cloud Map y luego un servicio ECS nuevo llamado orders. Sustituye los IDs y la región por los de tu cuenta. Si orders ya existe en el clúster, no ejecutes el paso de creación para ese mismo servicio: usa la actualización de servicio que se muestra más abajo. El tutorial oficial de creación, verificación y limpieza de Service Discovery en ECS muestra el flujo completo.

Antes de crear recursos, considera que Cloud Map cobra por registros y operaciones de descubrimiento; el namespace crea una zona privada de Route 53. Las tareas de Fargate y, si las necesitas, las puertas de enlace NAT y el tráfico de salida también pueden generar cargos. Revisa los precios de AWS Cloud Map, Route 53, Amazon ECS/Fargate y Amazon VPC para tu región y uso.

1. Crea un namespace privado

aws servicediscovery create-private-dns-namespace \
  --name apps.internal \
  --vpc vpc-0123456789abcdef0 \
  --region us-east-1

La respuesta incluye un OperationId: la creación es asíncrona. Consulta aws servicediscovery get-operation –operation-id <operation-id> –region us-east-1 hasta que Status sea SUCCESS y guarda el valor de Targets.NAMESPACE. Ese es el ID que usarás como namespace. Un namespace privado limita la resolución a las VPC asociadas y evita publicar los nombres internos en DNS público.

2. Crea el servicio DNS de Cloud Map

Este ejemplo registra direcciones IPv4 con política multivalue y TTL de 60 segundos:

aws servicediscovery create-service \
  --name orders \
  --dns-config "NamespaceId=ns-0123456789abcdef0,RoutingPolicy=MULTIVALUE,DnsRecords=[{Type=A,TTL=60}]" \
  --health-check-custom-config FailureThreshold=1 \
  --region us-east-1

Guarda Service.Arn de la respuesta para asociarlo al servicio de ECS. Si elegiste SRV, configura ese tipo de registro y los campos containerName y containerPort de la definición del servicio ECS. Para usar IPv6, elige AAAA o A y AAAA según el modo de red y las subredes.

El TTL define por cuánto tiempo los resolutores DNS pueden guardar una respuesta. El valor 60 es un ejemplo, no un valor obligatorio: un TTL menor permite que los cambios se reflejen antes, pero aumenta las consultas; un TTL mayor reduce consultas y puede dejar a los clientes usando una IP anterior durante más tiempo. Además, una aplicación puede mantener su propia caché DNS o conexiones abiertas, así que debe tolerar reintentos y reemplazos de tareas. Lee las recomendaciones de AWS para TTL de DNS.

3. Asocia el registro al servicio ECS

En el objeto de creación del servicio ECS, agrega el ARN de Cloud Map en serviceRegistries. El ejemplo supone que la definición orders:1 usa awsvpc, contiene el contenedor orders que escucha en el puerto 8080 y que la VPC, las subredes y el grupo de seguridad corresponden al namespace:

{
  "cluster": "tutorial",
  "serviceName": "orders",
  "taskDefinition": "orders:1",
  "desiredCount": 2,
  "launchType": "FARGATE",
  "platformVersion": "LATEST",
  "serviceRegistries": [
    {
      "registryArn": "arn:aws:servicediscovery:us-east-1:123456789012:service/srv-0123456789abcdef0"
    }
  ],
  "networkConfiguration": {
    "awsvpcConfiguration": {
      "subnets": ["subnet-0123456789abcdef0"],
      "securityGroups": ["sg-0123456789abcdef0"],
      "assignPublicIp": "DISABLED"
    }
  }
}

Guarda el contenido como ecs-service-discovery.json y crea el servicio:

aws ecs create-service \
  --cli-input-json file://ecs-service-discovery.json \
  --region us-east-1

Para un servicio ECS existente con despliegues rolling, asocia el registro con update-service. Con el registro A de este ejemplo, la actualización queda así:

aws ecs update-service \
  --cluster tutorial \
  --service orders \
  --service-registries "registryArn=arn:aws:servicediscovery:us-east-1:123456789012:service/srv-0123456789abcdef0" \
  --region us-east-1

Cambiar serviceRegistries inicia un nuevo despliegue: ECS arranca tareas con la configuración nueva y luego detiene las anteriores. La actualización requiere el rol vinculado al servicio de ECS. Para SRV agrega containerName y containerPort cuando el modo de red sea bridge o host; con awsvpc y SRV puedes indicar ese par o el campo port. Revisa la documentación actual de update-service.

Configura el grupo de seguridad de las tareas para aceptar el puerto 8080 desde el grupo de seguridad de los clientes. No abras ese puerto a todo Internet para que funcione la resolución interna. El ejemplo deshabilita la IP pública; si ejecutas las tareas en subredes privadas, asegúrate de que tengan salida al registro de imágenes y a los servicios necesarios al iniciar contenedores o enviar logs. Puedes usar NAT o los endpoints correspondientes; por ejemplo, ECR y S3 para imágenes privadas en ECR y CloudWatch Logs si usas awslogs. Para otros registros, configura la salida que requieran. Consulta las opciones de red para tareas Fargate.

4. Comprueba DNS y conectividad

Ejecuta las consultas desde una tarea cliente o una instancia dentro de una VPC asociada al namespace:

dig +short A orders.apps.internal
dig +short AAAA orders.apps.internal
dig +short SRV orders.apps.internal

Consulta solo el tipo que configuraste. Con A espera una o más IP privadas. Con SRV, espera respuestas con prioridad, peso, puerto y nombre de destino; resuelve ese nombre con dig +short A <nombre-de-destino> (o AAAA en IPv6) para obtener la IP. Luego prueba el protocolo y puerto reales, por ejemplo:

curl --connect-timeout 2 http://orders.apps.internal:8080/health

Cambia /health por una ruta que exista en tu aplicación. Una respuesta DNS correcta prueba la resolución, pero no la conectividad ni la salud de la aplicación. También puedes revisar las instancias registradas con aws servicediscovery list-instances –service-id <service-id> –region us-east-1 y consultar eventos, tareas y salud del servicio en ECS.

Salud, límites y decisiones operativas

Las comprobaciones del contenedor informan la salud del endpoint a ECS, que actualiza el estado en Cloud Map; no detienen por sí solas la tarea. Al iniciar, las tareas y sus instancias de descubrimiento pueden figurar como no saludables hasta que la comprobación devuelve un resultado: ese estado no significa que la tarea se haya detenido ni que la instancia ya se haya desregistrado. Si falla la comprobación del contenedor, ECS retira el endpoint del enrutamiento DNS y desregistra la instancia de Cloud Map; el scheduler decide por separado cuándo detener o reemplazar la tarea. En un namespace privado no puedes configurar comprobaciones de Route 53 que sondeen tareas desde Internet. Para registros que siguen registrados pero están marcados como no saludables, Route 53 puede devolver hasta ocho si todos están no saludables y la política es multivalue; una respuesta DNS no garantiza que la aplicación acepte la conexión. La documentación de Service Discovery en ECS y de salud de AWS Cloud Map explica los estados y las comprobaciones.

Ten en cuenta estos límites al diseñar los clientes:

Si creaste el servicio ECS nuevo del tutorial, reduce su capacidad a cero y elimina ese servicio; espera a que se detengan las tareas y desaparezcan sus instancias de Cloud Map. Después elimina el servicio Cloud Map y, cuando el namespace ya no tenga servicios, elimina el namespace. Si solo agregaste el registro a un servicio ECS que ya existía, no elimines ese servicio: restaura su configuración previa de serviceRegistries. Si antes no tenía registros, retíralos con aws ecs update-service –cluster tutorial –service orders –service-registries '[]' –region us-east-1 y espera a que termine el despliegue antes de eliminar el servicio y el namespace Cloud Map creados solo para la prueba. Si el servicio ya tenía otra configuración de descubrimiento, consérvala y no elimines sus recursos. ECS administra el registro de sus tareas; los recursos Cloud Map que creaste quedan a tu cargo. Si creaste un clúster o una VPC solo para la prueba, elimínalos cuando ya no haya recursos que los usen. El tutorial oficial de ECS detalla la limpieza; la referencia de update-service confirma que una lista vacía retira serviceRegistries y activa un despliegue.

Qué revisar si algo no funciona

Síntoma Revisa
NXDOMAIN o no hay respuestas Nombre completo (servicio.namespace), ID y estado del namespace, nombre del servicio Cloud Map, instancias registradas y que la consulta salga de una VPC asociada con DNS habilitado.
Hay respuesta DNS, pero la conexión vence Puerto del contenedor, regla de entrada del grupo de seguridad del servicio, rutas entre VPC y que la aplicación escuche en la interfaz de red correcta.
El nombre resuelve con un tipo, pero no con otro Consulta el tipo que declaraste: A, AAAA o SRV. AAAA requiere IPv6 y SRV incluye el puerto.
Aparece una IP anterior después de un despliegue TTL del registro, caché DNS de la aplicación, conexiones reutilizadas y tiempos de apagado de las tareas antiguas.
Una tarea defectuosa sigue apareciendo Comprueba que la definición de tarea declare una health check y que ECS la reporte; inspecciona las instancias de Cloud Map y los eventos del servicio ECS.

Para errores de permisos, revisa la identidad que crea los recursos y el rol vinculado al servicio de ECS, AWSServiceRoleForECS. ECS usa ese rol para administrar Cloud Map y Route 53; la aplicación no necesita permisos de Cloud Map para resolver nombres DNS. Consulta cómo ECS usa sus roles vinculados a servicios y aplica permisos de mínimo privilegio al operador.

Sigue practicando y comparte dudas

Estos materiales dan contexto de ECS y contenedores, aunque no configuran Cloud Map:

Eventos anunciados al 6 de octubre de 2026:

Las fechas y condiciones de los eventos pueden cambiar; revisa la fuente antes de registrarte. Explora más comunidades de AWS y eventos de la comunidad en el directorio.

Tres módulos abstractos enlazados por estaciones de un camino azul y un punto naranja.

Amazon ECS: qué es y cómo ejecutar tu primera tarea

Un libro abierto junto a un camino azul con estaciones y un punto naranja.

Amazon VPC: subredes, rutas, NAT y seguridad en AWS