La mayoría de los equipos SaaS en AWS que usan Kubernetes recurren a un servicio de Kubernetes administrado, casi siempre Amazon EKS. La palabra “administrado” lleva a muchos fundadores y CTOs a suponer que lo difícil ya está resuelto. No es así. Los servicios de Kubernetes administrado te quitan de encima el plano de control y, en algunos modos, también los nodos, pero el cluster sigue necesitando actualizaciones, add-ons, redes, políticas de seguridad, observabilidad, control de costos y alguien que responda cuando suene la alerta. Este artículo explica qué cubre realmente cada opción, qué trabajo queda pendiente, quién puede hacerlo por ti y cuándo conviene prescindir de Kubernetes por completo.

Qué administra realmente un servicio de Kubernetes administrado

Kubernetes administrado, que a veces se vende como Kubernetes como servicio, significa que un proveedor opera una parte del cluster por ti. Para saber cuál, conviene recordar que un cluster de Kubernetes tiene tres capas de trabajo.

El plano de control: el servidor de API de Kubernetes y la base de datos etcd que guarda el estado del cluster.
El plano de datos: los nodos (instancias EC2 o Fargate) donde corren tus contenedores, más las redes, el almacenamiento y el balanceo de carga que necesitan.
Todo lo que corre encima: tus cargas de trabajo, pipelines de despliegue, ingress, secretos, políticas, monitoreo y los add-ons que mantienen todo unido.

Amazon EKS siempre se encarga de la primera capa. AWS opera el servidor de API y etcd, y cobra US$0.10 por cluster por hora por una versión de Kubernetes en soporte estándar. En el modo predeterminado, la segunda capa es compartida: AWS ofrece grupos de nodos administrados, pero la documentación de EKS es explícita en que esos grupos no se actualizan automáticamente cuando se actualiza el plano de control. La tercera capa es tuya.

EKS Auto Mode traslada a AWS una parte mayor de la segunda capa. AWS asume el aprovisionamiento, el parcheo y el escalado de nodos (con Karpenter), además de la integración con balanceadores de carga, las redes de los pods y los drivers de almacenamiento en bloque. Los nodos usan una imagen basada en Bottlerocket, con acceso restringido, y se reemplazan al menos cada 21 días. Aun así, AWS aclara que los clientes conservan la responsabilidad de “los contenedores de la aplicación, incluidas su disponibilidad, seguridad y monitoreo”, así como de la VPC y la configuración del cluster. Auto Mode agrega una tarifa de administración sobre las instancias EC2 que lanza, y varía según el tipo de instancia.

Así que la respuesta honesta a “¿qué cubre Kubernetes administrado?” es esta: el plano de control siempre, los nodos a veces y tus aplicaciones nunca.

Opción 1: Constrúyelo tú mismo

Puedes correr Kubernetes sobre EC2 con herramientas como kubeadm o kops y ser dueño de todas las capas, incluidos los respaldos de etcd, los certificados del plano de control y la alta disponibilidad entre zonas de disponibilidad.

Para una empresa SaaS en AWS, esto casi nunca tiene sentido. El plano de control es la parte de Kubernetes donde los errores son más difíciles de recuperar, y EKS cobra una tarifa horaria pequeña por quitártelo. Autoadministrarlo solo vale la pena si tienes un requisito estricto que EKS no puede cumplir, un equipo de plataforma con experiencia profunda en Kubernetes y una razón para dedicar su tiempo al plano de control en lugar de a tu producto. La mayoría de los equipos no tiene ninguna de las tres cosas.

Opción 2: Compra Kubernetes administrado en AWS con EKS

EKS es la opción predeterminada para Kubernetes en AWS, y con razón: se integra con IAM, las redes de VPC, los balanceadores de carga y CloudWatch, y elimina el trabajo operativo más riesgoso.

La decisión dentro de esta opción es modo estándar o Auto Mode. El modo estándar te da más control sobre la configuración de los nodos y cuesta menos en tarifas. Auto Mode cuesta más por nodo, pero te quita de la lista el parcheo de nodos, la selección de AMI y el mantenimiento del autoescalador. Para un equipo pequeño sin un ingeniero de plataforma dedicado, Auto Mode suele ser el mejor intercambio. Para un equipo con requisitos específicos de nodos, como ciertas familias de instancias o ajustes del kernel, el modo estándar con grupos de nodos administrados puede encajar mejor.

De cualquier forma, comprar EKS es comprar una base, no un equipo de operaciones.

Administración de clusters de Kubernetes: el trabajo que EKS deja en tus manos

Esta es la lista que sorprende a los equipos después de que su primer cluster entra en producción.

Actualizaciones de versión con un calendario fijo. Kubernetes publica una nueva versión menor aproximadamente cada cuatro meses, según la documentación del ciclo de vida de versiones de EKS. EKS da a cada versión 14 meses de soporte estándar y luego 12 meses de soporte extendido a US$0.60 por cluster por hora, seis veces la tarifa estándar. Cuando termina el soporte extendido, EKS actualiza el plano de control automáticamente, en un momento que no anuncia con anticipación, y tú todavía tienes que actualizar los add-ons y los nodos que Auto Mode no administra. En la práctica, alguien tiene que planificar y probar una actualización varias veces al año, incluida la revisión de APIs obsoletas en tus manifiestos y Helm charts.

Add-ons. El VPC CNI, CoreDNS, kube-proxy, el driver EBS CSI, un controlador de ingress o de balanceadores de carga, cert-manager, external-dns, una integración de secretos y un pipeline de métricas tienen cada uno sus propias versiones y reglas de compatibilidad. Auto Mode absorbe algunos. El resto es tuyo.

Identidad y acceso. Mapear IAM a RBAC de Kubernetes, dar a los pods permisos de AWS acotados y evitar que las personas usen cluster-admin.

Redes. Planificación de direcciones IP para los pods, grupos de seguridad, políticas de red, reglas de ingress y los costos de NAT y de transferencia de datos que crecen sin hacer ruido.

Despliegues. Un proceso de despliegue basado en GitOps o en pipelines, para que nadie ejecute kubectl apply desde una laptop contra producción.

Observabilidad y guardia. Métricas, logs y trazas del cluster y de las cargas de trabajo, alertas con runbooks y una persona que responda por la noche.

Costos. Requests y límites que reflejen el uso real, consolidación de nodos, Spot donde sea seguro y entornos inactivos apagados.

Seguridad. Escaneo de imágenes, políticas de admisión, manejo de secretos y parcheo de las propias cargas de trabajo.

Nada de esto es exótico. Simplemente es continuo, y recae en quien sea dueño del cluster.

Opción 3: Terceriza la operación

La tercera vía es un servicio de administración de Kubernetes: un equipo externo que opera el cluster y la ruta de entrega que corre encima de EKS. Fíjate en la diferencia con las dos primeras opciones. Sigues comprándole EKS a AWS. Lo que tercerizas es el trabajo de la sección anterior.

Esto encaja con equipos que necesitan Kubernetes pero no pueden justificar un ingeniero de plataforma dedicado, o que tienen a un solo ingeniero cargando con todo. Los proveedores de Kubernetes administrado de este tipo difieren mucho en alcance, así que pregunta:

¿Se encargan de las actualizaciones de versión de principio a fin? Incluidos los add-ons, las APIs obsoletas y las pruebas previas en staging.
¿Todo está en código, en nuestros repositorios? La configuración del cluster, los Helm charts o manifiestos y los pipelines deben vivir en tu Git, no en el del proveedor.
¿Quién está de guardia y cuál es el proceso de respuesta? Pide detalles concretos.
¿Cómo llegan los cambios a producción? Busca pull requests, revisión y un pipeline automatizado.
¿Qué pasa si nos vamos? Debes poder entregarle el cluster a otro equipo con su documentación intacta.

Cuándo no necesitas Kubernetes en absoluto

Muchos equipos SaaS usan Kubernetes porque es lo habitual, no porque lo necesiten. En AWS hay un camino más simple que cubre una buena parte de las aplicaciones web y las APIs.

Amazon ECS es el orquestador de contenedores propio de AWS. No hay cargo adicional por la orquestación de ECS; pagas por el cómputo que ejecuta. Con Fargate no hay nodos que parchear ni actualizaciones de versión de cluster, al estilo de Kubernetes, que programar. ECS Express Mode va más lejos: tú aportas una imagen de contenedor y dos roles de IAM, y ECS configura un servicio en Fargate, un balanceador de carga con TLS, escalado automático y redes.

AWS App Runner era la otra opción sencilla, pero AWS cerró App Runner a nuevos clientes. Los clientes actuales pueden seguir usándolo, y AWS recomienda ECS Express Mode para las migraciones. Si empiezas hoy, apuesta por ECS.

Kubernetes empieza a justificar su costo operativo cuando:

Corres muchos servicios con necesidades de escalado y de scheduling distintas, y el equipo quiere una plataforma consistente para todos.
Necesitas específicamente el ecosistema de Kubernetes: operadores para sistemas con estado, un service mesh o herramientas que solo se distribuyen como Helm charts.
Necesitas portabilidad entre nubes o hacia los entornos de tus clientes, por ejemplo un producto que los clientes instalan en sus propios clusters.
Ya tienes ingenieros que conocen bien Kubernetes y serían más lentos con cualquier otra cosa.

Si nada de esto aplica, ECS sobre Fargate suele dar menos trabajo para el mismo resultado. Un equipo de ocho ingenieros que corre un puñado de servicios en ECS no va atrasado; tiene más tiempo para trabajar en su producto.

Cómo se comparan las opciones

	Autoadministrado en EC2	EKS (estándar)	EKS Auto Mode	ECS sobre Fargate
Plano de control	Tú	AWS	AWS	AWS (sin costo)
Nodos y parcheo	Tú	Tú, con grupos de nodos administrados	AWS	AWS (Fargate)
Actualizaciones de versión	Tú	Tú las planificas; AWS las impone al terminar el soporte	Tú las planificas; los nodos se actualizan solos	No hay versiones de Kubernetes
Add-ons e ingress	Tú	Tú	En parte AWS	No aplica
Cargas de trabajo, despliegues, guardia	Tú	Tú	Tú	Tú
Buen encaje	Raro, equipos especializados	Equipos que necesitan control de los nodos	Equipos pequeños que necesitan Kubernetes	La mayoría de las apps web y APIs

La fila de “cargas de trabajo, despliegues, guardia” es la que importa: en todas las opciones, alguien sigue siendo responsable de tus cargas de trabajo, tus despliegues y la guardia. Elegir un servicio de Kubernetes administrado define cuánta infraestructura más tiene que cargar esa persona.

Para una visión más amplia de lo que AWS opera por ti frente a lo que hace un proveedor de DevOps, lee nuestro artículo sobre los servicios administrados de AWS y el DevOps administrado.

Preguntas frecuentes

¿Sigue siendo relevante Kubernetes en 2026?

Sí, para los equipos que necesitan lo que ofrece: muchos servicios con necesidades de escalado distintas, el ecosistema de operadores y Helm charts de Kubernetes, o portabilidad entre nubes y entornos de clientes. Lo que cambió es que ya no es la elección automática. En AWS, ECS sobre Fargate cubre muchas apps web y APIs con menos trabajo operativo.

¿Cuáles son las desventajas de usar Kubernetes?

La principal desventaja es el trabajo operativo continuo. Incluso con un servicio administrado, alguien tiene que planificar las actualizaciones de versión varias veces al año, mantener los add-ons compatibles, gestionar la identidad, las redes y los costos, y responder cuando suena la alerta. Además, el soporte extendido de EKS cuesta seis veces la tarifa estándar del plano de control si las actualizaciones se atrasan.

¿Cuáles son los cuatro tipos de servicios en Kubernetes?

Kubernetes define cuatro tipos de Service: ClusterIP, el predeterminado, que expone un servicio solo dentro del cluster; NodePort, que lo expone en un puerto estático de cada nodo; LoadBalancer, que usa el balanceador de carga del proveedor de nube para exponerlo hacia afuera; y ExternalName, que asigna el servicio a un nombre DNS externo. En EKS, los servicios LoadBalancer suelen estar respaldados por balanceadores de carga de AWS.

Dónde encaja Webera

Webera es una suscripción de DevOps para equipos SaaS en AWS, con ingenieros senior que trabajan junto a nueve agentes de IA. Los agentes vigilan, enrutan y hacen el primer análisis las 24 horas; los ingenieros toman las decisiones y entregan las correcciones. Ya sea que uses EKS, ECS o estés decidiendo entre ambos, el trabajo de este artículo entra en la misma cola de solicitudes, con monitoreo 24/7 y respuesta a incidentes en todos los planes.

Pro, US$4,999 al mes: solicitudes ilimitadas, con dos en curso a la vez y un tiempo de entrega promedio de 36 horas.
Elite, US$9,999 al mes: un ingeniero asignado, un gerente de éxito del cliente, un concierge de cumplimiento normativo para SOC 2, HIPAA y PCI, y un tiempo de entrega promedio de 24 horas.
Platform, US$14,999 al mes: un equipo que trabaja dentro de tus sprints, con operación multicuenta y de Kubernetes, y transferencia de conocimiento a tus ingenieros.

Todos los planes tienen un mínimo de tres meses, facturado mensualmente, y después continúan mes a mes; todo el código es tuyo. Si operar Kubernetes le quita a tu equipo más tiempo que tu producto, compara los planes en nuestra página de precios.

Servicios de Kubernetes administrado: constrúyelo, cómpralo o terceriza su operación