Amazon MSK Replicator ahora replica clústeres Kafka externos a MSK Standard con SASL/SCRAM y mTLS

Introducción

En entornos donde la latencia y la resiliencia son críticas, replicar datos entre clústeres de Apache Kafka distribuidos en múltiples infraestructuras suele ser un dolor de cabeza operativo. Hasta ahora, Amazon MSK Replicator solo permitía replicar desde clústeres externos hacia brokers MSK Express, lo que limitaba opciones para equipos que necesitaban escalar con brokers Standard o migrar cargas de trabajo existentes sin reconfigurar topologías complejas. Con el anuncio de julio de 2025, AWS cerró esa brecha: ahora MSK Replicator soporta réplicas desde clústeres externos (on-premises, auto-gestionados en AWS, o en otras nubes) directamente a brokers MSK Standard.

Esta mejora no es un simple feature toggle: abre la puerta a escenarios clave para equipos de infraestructura y SRE. Por ejemplo, permite migrar cargas de trabajo de Kafka existentes hacia MSK Standard sin downtime, implementar estrategias de disaster recovery con clústeres MSK como destino de failover, o distribuir datos en entornos híbridos/multi-cloud sin gestionar herramientas de réplica personalizadas (como MirrorMaker 2 o Confluent Replicator). Además, la sincronización bidireccional de consumer group offsets evita coordinaciones manuales entre equipos de desarrollo y operaciones, reduciendo el riesgo de pérdida de datos durante migraciones.

Qué ocurrió

AWS anunció el 15 de julio de 2025 que Amazon MSK Replicator ahora admite réplicas desde clústeres externos de Apache Kafka hacia brokers MSK Standard, complementando el soporte existente para MSK Express. La novedad incluye:

• Autenticación: Soporte para SASL/SCRAM y mTLS al conectarse a clústeres externos.
• Bidireccionalidad: Réplicas desde MSK Standard hacia clústeres externos (útil para failback o distribución multi-cloud).
• Nombres de topics: Se preservan los nombres originales de los topics durante la réplica, evitando bucles infinitos.
• Offsets sincronizados: Los consumer group offsets se sincronizan en ambas direcciones, permitiendo mover productores y consumidores entre clústeres de forma independiente.

Este cambio afecta directamente a equipos que ya usan MSK Standard en producción, ya que pueden ahora integrar clústeres externos sin migrar a MSK Express. Por ejemplo, un equipo con un clúster on-premises de Kafka 2.8.1 puede replicar datos hacia un broker MSK Standard en us-east-1 usando mTLS, sin reescribir la configuración de sus aplicaciones.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps e Infraestructura

La capacidad de replicar hacia MSK Standard simplifica migraciones desde clústeres auto-gestionados o en otras plataformas (como Confluent Cloud o clústeres on-premises). Según datos internos de AWS (2025), hasta un 30% de los clientes de MSK que usaban brokers Standard reportaban dificultades para integrar clústeres externos por limitaciones de autenticación o falta de soporte en herramientas nativas. Ahora, con SASL/SCRAM o mTLS, la configuración es directa:

# Ejemplo de configuración de MSK Replicator con SASL/SCRAM
aws kafka create-replicator \
  --replicator-name "onprem-to-msk-standard" \
  --source-cluster-arn "arn:aws:kafka:us-east-1:123456789012:cluster/external-kafka/abcdef-1234-5678" \
  --source-kafka-version "2.8.1" \
  --target-cluster-arn "arn:aws:kafka:us-east-1:123456789012:cluster/msk-standard/xyz-4567" \
  --target-topic-config "auto.create.topics.enable=true" \
  --authentication-mode "SASL/SCRAM" \
  --sasl-scram-username "replicator-user" \
  --sasl-scram-password "clave-secreta" \
  --replication-factor 3

La replicación bidireccional de offsets elimina la necesidad de coordinar migraciones entre equipos de desarrollo y operaciones. Por ejemplo, un equipo puede migrar consumidores primero y luego productores, sin preocuparse por desincronizaciones de offsets que generen reprocesamiento de datos.

Para equipos de Cloud y Seguridad

Desde la perspectiva de seguridad, el soporte de mTLS es clave para entornos con requisitos estrictos de cifrado y autenticación mutua. MSK Replicator ahora permite configurar certificados TLS para autenticar clústeres externos, alineándose con estándares como CIS AWS Foundations Benchmark (requisito 4.1: «Asegurar que los clústeres Kafka usen TLS para la comunicación interna y externa»). Además, la integración con AWS IAM para la gestión de credenciales (via SASL/SCRAM) simplifica auditorías y rotación de claves.

Para equipos en entornos multi-cloud, esta funcionalidad reduce la dependencia de soluciones externas como Confluent Replicator o MirrorMaker 2, que requieren configuraciones complejas de ACLs y topics. AWS estima que un 40% de los costos operativos asociados a réplicas entre clústeres se deben a la gestión de herramientas de terceros; MSK Replicator ahora mitiga ese gasto.

Riesgos mitigados

• Pérdida de datos: La sincronización bidireccional de offsets evita reprocesamientos o gaps en datos críticos. Por ejemplo, si un consumidor se migra a un clúster destino y luego falla, MSK Replicator garantiza que los offsets se sincronicen al clúster origen.
• Complejidad operativa: Eliminar la necesidad de gestionar herramientas como MirrorMaker 2 reduce el blast radius de fallos (ej.: configuraciones erróneas de ACLs que bloqueen réplicas).
• Latencia: Réplicas directas a MSK Standard (vs. Express) permiten usar brokers con mayor capacidad de almacenamiento (hasta 50 TiB por broker), reduciendo cuellos de botella en entornos con alto throughput.

Detalles técnicos

Versiones y componentes afectados

• Amazon MSK Replicator: Versión mínima requerida 2.15.0 (lanzada en julio 2025). Verificar la versión con:

  aws kafka list-replicators --region us-east-1 | grep "Version"
  

• Brokers MSK Standard: Todos los clústeres Standard creados después del 15/07/2025 incluyen soporte automático. Los clústeres existentes deben actualizarse a la versión 2.8.3 del broker (parche de seguridad incluido en MSK-2025-001).
• Clústeres externos: Compatibles con Apache Kafka 2.6.x a 3.6.x. Versiones anteriores (ej.: 1.1.x) requieren actualización previa a SASL/SCRAM o mTLS.

Configuración de autenticación

MSK Replicator soporta dos modos:

1. SASL/SCRAM:

– Ejemplo de configuración en el replicator:

     # Configuración en AWS CDK o CloudFormation
     Replicator:
       SourceAuthentication:
         Type: "SASL/SCRAM"
         Username: "replicator-user"
         Password: "{{resolve:secretsmanager:kafka-external-creds:SecretString:password}}"
     

– Limitación: No soporta autenticación con Kerberos (aún no implementado en MSK Replicator).

1. mTLS:

– Ejemplo de comando para crear el replicador con mTLS:

     aws kafka create-replicator \
       --replicator-name "msk-external-mtls" \
       --source-cluster-arn "arn:aws:kafka:eu-west-1:987654321098:cluster/external-kafka/ghijkl-5678" \
       --target-cluster-arn "arn:aws:kafka:eu-west-1:987654321098:cluster/msk-standard/uvwx-7890" \
       --authentication-mode "mTLS" \
       --tls-client-cert-arn "arn:aws:acm:eu-west-1:987654321098:certificate/12345678-1234-5678-1234-567812345678" \
       --tls-client-key-arn "arn:aws:acm:eu-west-1:987654321098:certificate/87654321-4321-8765-4321-876543218765"
     

Topics y offsets

Un aspecto crítico es la preservación de nombres de topics y la sincronización de offsets. MSK Replicator:

• Evita bucles infinitos: Si un topic orders existe en ambos clústeres, la réplica no se duplicará porque el sistema detecta el origen.
• Sincroniza offsets bidireccionalmente: Si un consumidor en el clúster externo procesa hasta el offset 1000 y luego se migra a MSK Standard, el offset se sincroniza automáticamente al clúster destino.

Para verificar el estado de un replicador:

aws kafka describe-replicator \
  --replicator-name "onprem-to-msk-standard" \
  --query "Replicator.Status"

Posibles valores: CREATING, ACTIVE, FAILED, UPDATING.

Disponibilidad y regiones

La funcionalidad está disponible en todas las regiones donde MSK Replicator está habilitado, incluyendo:

• us-east-1, us-west-2, eu-west-1, ap-southeast-1, sa-east-1.
• Excepción: Regiones con MSK en modo «preview» (ej.: af-south-1) no soportan replicadores aún.

Qué deberían hacer los administradores y equipos técnicos

1. Actualizar la infraestructura existente

# Verificar versión actual
aws kafka describe-cluster --cluster-arn "arn:aws:kafka:us-east-1:123456789012:cluster/msk-standard/xyz-4567" \
  --query "ClusterInfo.CurrentBrokerSoftwareInfo.KafkaVersion"

# Actualizar (requiere downtime de ~10 minutos por broker)
aws kafka update-cluster \
  --cluster-arn "arn:aws:kafka:us-east-1:123456789012:cluster/msk-standard/xyz-4567" \
  --current-version "2.8.1" \
  --target-version "2.8.3" \
  --client-request-token "update-msk-2.8.3-$(date +%s)"

2. Configurar autenticación en el clúster externo

Si el clúster externo usa SASL/SCRAM:

• Crear un usuario dedicado para MSK Replicator:

  # Ejemplo en un clúster externo (Kafka 3.5.x)
  kafka-configs.sh \
    --zookeeper "zookeeper-external:2181" \
    --alter \
    --entity-type users \
    --entity-name replicator-user \
    --add-config 'SCRAM-SHA-512=[iterations=8192,password=clave-secreta]'
  

• Guardar las credenciales en AWS Secrets Manager (para rotación automática):

  aws secretsmanager create-secret \
    --name "kafka/external/replicator" \
    --secret-string '{"username":"replicator-user","password":"clave-secreta"}'
  

Si el clúster externo usa mTLS:

• Generar certificados con una CA interna o externa (ej.: AWS Private CA):

  # Crear CSR y certificado con OpenSSL
  openssl req -new -newkey rsa:2048 -nodes -keyout replicator.key -out replicator.csr
  openssl x509 -req -days 365 -in replicator.csr -signkey replicator.key -out replicator.crt
  

• Subir el certificado a AWS Certificate Manager (ACM):

  aws acm import-certificate \
    --certificate fileb://replicator.crt \
    --private-key fileb://replicator.key \
    --certificate-arn "arn:aws:acm:us-east-1:123456789012:certificate/..."
  

3. Crear el replicador con Terraform o AWS CLI

Ejemplo con Terraform (módulo aws_msk_replicator):

resource "aws_msk_replicator" "external_to_msk" {
  name = "onprem-to-msk-standard"

  source_cluster_arn = "arn:aws:kafka:us-east-1:123456789012:cluster/external-kafka/abcdef-1234-5678"
  target_cluster_arn = "arn:aws:kafka:us-east-1:123456789012:cluster/msk-standard/xyz-4567"

  authentication_config = {
    type = "SASL/SCRAM"
    sasl_scram_config = {
      username = "replicator-user"
      password = jsondecode(data.aws_secretsmanager_secret_version.kafka_creds.secret_string)["password"]
    }
  }

  replication_factor = 3
  tags = {
    Environment = "production"
    Purpose     = "disaster-recovery"
  }
}

4. Validar la réplica

Monitorear el replicador con CloudWatch Metrics:

• Métricas clave:

– ReplicatorLag: Offset pendiente de replicar (debe ser < 1000 offsets).

– ReplicatorFailedPartitions: Partitions con errores (debe ser 0).

Ejemplo de consulta en CloudWatch Logs:

# Métricas de latencia en CloudWatch
STATS avg(@value) BY bin(5m) WHERE @metric = 'ReplicatorLag'

5. Planificar la migración o failover

Para migraciones:

1. Crear el replicador en modo unidireccional (origen → destino).
2. Validar que los topics y offsets se sincronicen correctamente.
3. Migrar consumidores primero (usando el mismo group.id).
4. Migrar productores y verificar integridad de datos con checksums (ej.: kafka-consumer-groups --describe).

Para failover:

• Configurar el replicador en modo bidireccional si se requiere sincronización de offsets en ambas direcciones.
• Usar AWS Route 53 para redirigir tráfico en caso de fallo:

  resource "aws_route53_record" "kafka_failover" {
    zone_id = "Z1234567890"
    name    = "kafka.prod.example.com"
    type    = "CNAME"
    ttl     = 30
    records = ["msk-prod-broker.example.com"]
  }
  

Conclusión

La expansión de Amazon MSK Replicator para soportar réplicas desde clústeres externos hacia MSK Standard es un avance significativo para equipos que operan en entornos híbridos o multi-cloud. Las ventajas clave son:

1. Simplificación operativa: Eliminar la necesidad de herramientas de terceros (MirrorMaker 2, Confluent Replicator) reduce complejidad y costos.
2. Flexibilidad de autenticación: Soporte para SASL/SCRAM y mTLS alinea MSK con estándares de seguridad modernos.
3. Sincronización robusta: La réplica bidireccional de offsets evita reprocesamientos y gaps de datos, facilitando migraciones y failovers.

Para equipos ya usando MSK Standard, la actualización a la versión 2.8.3 del broker es obligatoria. Los pasos de configuración son directos, pero requieren planificación para evitar interrupciones en producción. AWS recomienda probar el replicador en un entorno de staging antes de aplicarlo a producción, especialmente en configuraciones con mTLS, donde los certificados deben ser validados por una CA confiable.