AWS Primeros Pasos
IdiomaEspañol

Amazon MSK

Servicio de streaming completamente administrado que proporciona construcción y operación de clústeres Apache Kafka, permitiendo utilizar directamente la API compatible con Kafka

Unos 4 min de lectura

Descripción general

Amazon MSK (Managed Streaming for Apache Kafka) es un servicio completamente administrado que facilita la construcción y operación de clústeres Apache Kafka en AWS. Reduce la complejidad operativa de gestionar brokers Kafka, ZooKeeper, almacenamiento y seguridad, mientras mantiene compatibilidad con la API de Kafka. Las aplicaciones existentes que utilizan productores y consumidores Kafka pueden migrar a MSK sin cambios de código. Soporta tanto clústeres provisionados como MSK Serverless para diferentes patrones de carga.

Diseño de brokers y estrategia de particiones

El diseño de un clúster MSK comienza con la selección del número de brokers y tipo de instancia. MSK distribuye brokers uniformemente entre las zonas de disponibilidad seleccionadas (mínimo 2, recomendado 3 para producción). El número de particiones por topic determina el paralelismo máximo de consumidores: un topic con 12 particiones permite hasta 12 consumidores procesando en paralelo. La estrategia de particionamiento debe considerar el throughput esperado, el orden de mensajes (garantizado solo dentro de una partición) y la distribución uniforme de datos. El factor de replicación (la guía de prácticas recomendadas para brokers Standard aconseja al menos 3) determina cuántas copias de cada partición se mantienen en diferentes brokers, proporcionando tolerancia a fallos. Con brokers Standard, el almacenamiento utiliza EBS; con brokers Express no es necesario aprovisionar ni gestionar el almacenamiento de datos, según la guía para desarrolladores. AWS indica en la guía para desarrolladores que MSK admite el modo KRaft, que sustituye a ZooKeeper en la gestión de metadatos, que los clústeres basados en ZooKeeper con Kafka 3.9.x tienen un procedimiento de migración a KRaft sin mover datos y que los clústeres con una versión de Kafka que ha superado su fecha de fin de soporte se actualizan automáticamente a la versión recomendada (a octubre de 2026).

Reducción de carga operativa con MSK Serverless y MSK Connect

MSK Serverless permite ejecutar Apache Kafka sin gestionar ni escalar la capacidad del clúster: no se seleccionan tipos de instancia ni número de brokers. El servicio aprovisiona y escala la capacidad automáticamente. La guía para desarrolladores sugiere considerarlo cuando las aplicaciones necesitan capacidad de streaming bajo demanda que escala automáticamente. MSK Connect es un servicio complementario que ejecuta conectores Kafka Connect de forma administrada, permitiendo ingerir datos desde fuentes externas (bases de datos, S3, APIs) y exportar a destinos (S3, OpenSearch, Redshift) sin código personalizado. Los conectores de la comunidad Kafka (Debezium para CDC, S3 Sink, Elasticsearch Sink, etc.) se despliegan como plugins, y MSK Connect gestiona el escalado y la tolerancia a fallos de los workers.

Criterios de selección frente a Kinesis Data Streams

MSK y Kinesis Data Streams son servicios de streaming pero con filosofías diferentes. MSK es una opción cuando: se tiene experiencia existente con Kafka, se necesita compatibilidad con el ecosistema Kafka (Kafka Streams, ksqlDB, Schema Registry, Connect), se requiere una retención de datos más allá del máximo de 365 días de Kinesis Data Streams (con tiered storage, el almacenamiento de MSK escala de forma prácticamente ilimitada según la guía para desarrolladores), o se migra una aplicación Kafka existente. Kinesis es una opción cuando: se busca integración nativa con servicios AWS (Lambda triggers, Firehose, Analytics) o el equipo no tiene experiencia con Kafka. Los modelos de precios de ambos servicios son distintos y se describen en la página de precios de cada uno. La función de tiered storage de MSK permite retener datos históricos en S3 a bajo costo mientras mantiene datos recientes en brokers para acceso de baja latencia.

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.

Compartir

Términos relacionados

Amazon KinesisAWS LambdaAmazon S3Amazon EventBridgeAmazon Redshift

Servicios relacionados

Amazon KinesisAWS LambdaAmazon S3Amazon EventBridge

Artículos relacionados

Construcción de un pipeline de datos en tiempo real con Amazon Kinesis - Cómo elegir entre Data Streams y Data FirehoseLos datos en tiempo real se ingieren con Data Streams y se entregan automáticamente a S3 / Redshift / OpenSearch con Data Firehose. Este artículo explica cómo construir un pipeline de streaming mediante el diseño de shards y la elección de cuándo usar el modo bajo demanda.Diseño del procesamiento de datos en streaming - Construcción de pipelines de datos en tiempo real con KinesisSe explican las técnicas de diseño del procesamiento de datos en streaming que aprovecha Amazon Kinesis Data Streams y Amazon Data Firehose (antes Kinesis Data Firehose), y se presenta cómo construir pipelines de datos en tiempo real mediante la integración con Lambda.Integración de datos SaaS con Amazon AppFlow - Integración con Salesforce, Slack y Google AnalyticsSincroniza datos de Salesforce y Slack a S3 y Redshift sin código. Presenta triggers basados en eventos, enmascaramiento de PII y transferencia segura mediante PrivateLink.Leyendo el futuro de AWS a 3 años desde los anuncios de re:Invent - El ciclo de vida de los servicios y las leyes de la discontinuaciónEnfrentamos el hecho de que los servicios de AWS también tienen vida útil, como la suspensión de nuevas inscripciones de CodeCommit y el fin de facto de SimpleDB, proporcionando una perspectiva de selección tecnológica para analizar el ciclo de vida de los servicios e identificar los servicios que no desaparecerán.El origen de los nombres de servicios AWS y las reglas de nomenclatura - Por qué S3 tiene 3 SProfundizamos en el origen de los nombres de servicios principales como S3, EC2, Lambda y Aurora, explicando de forma anecdótica los patrones ocultos en las reglas de nomenclatura de AWS, los ejemplos de nombres fallidos y la historia de rebranding.

Términos y artículos similares

Construcción de una plataforma de streaming Apache Kafka con Amazon MSK - Diseño y operación de clústeresSe diseñan clústeres gestionados de Apache Kafka y se presentan la elección entre estos y MSK Serverless y los patrones de integración de datos con MSK Connect.Streaming de Kafka administrado - Pipelines de datos en tiempo real a gran escala con Amazon MSKEste artículo explica cómo construir clústeres de Kafka totalmente administrados con Amazon MSK (Managed Streaming for Apache Kafka) y cuándo usarlo en lugar de Kinesis. También presenta patrones de diseño para plataformas de streaming de datos en tiempo real a gran escala.Amazon MSKServicio Apache Kafka totalmente administrado para procesamiento de datos de streaming en tiempo realPrimeros pasos con event streaming en Amazon MSK Serverless - Construcción de un entorno Kafka sin operacionesSe presenta un método para construir con autenticación de IAM un entorno Kafka que no requiere gestión de clústeres y simplificar el event streaming mediante la integración con EventBridge Pipes.Amazon Managed Service for Apache FlinkServicio que ejecuta Apache Flink de forma completamente administrada, procesando datos de streaming en tiempo real desde Kinesis Data Streams o MSK con baja latencia