EKS local clusters en Outposts ahora con instance store
AWS habilitó el soporte de EC2 instance store en los EKS clusters locales AWS Outposts, según el anuncio oficial de junio de 2026. Ahora podés correr el control plane y los nodos de Kubernetes íntegramente en tu Outpost, con almacenamiento local NVMe de baja latencia para cargas efímeras.
Un EKS local cluster en AWS Outposts es una configuración de Amazon EKS donde el control plane completo de Kubernetes (API server y etcd) y los worker nodes se ejecutan dentro del Outpost, en tu propio datacenter. A diferencia del modo extendido, sigue funcionando aunque se corte el enlace con la región de AWS. El soporte de EC2 instance store agrega discos NVMe locales para datos temporales.
En 30 segundos
- Qué cambió: EKS local clusters en Outposts ahora soportan EC2 instance store, el disco NVMe efímero que viene en instancias de la familia “d” (C5d, M5d, R5d, entre otras).
- Para qué sirve: almacenamiento local con latencia ultra-baja e IOPS parejos, sin costo de transferencia de datos, ideal para cachés, buffers y procesamiento temporal.
- Diferencia clave: en un cluster local el control plane vive en tu Outpost; en uno extendido vive en la región y solo bajan los worker nodes.
- Ojo con esto: el instance store es efímero. Si la instancia se detiene o falla, esos datos desaparecen. Para datos persistentes seguís necesitando EBS.
- Disponibilidad: requiere capacidad de cómputo y EBS provisionada en el Outpost; en Outposts solo hay volúmenes EBS gp2.
¿Por qué AWS sumó el instance store a los clusters locales?
Ponele que tenés una planta de manufactura corriendo Kubernetes on-premise con EKS en un Outpost. Hasta ahora, cada pod que necesitaba disco rápido para datos temporales tiraba sobre EBS. Funcionaba, sí. Pero el EBS en Outposts tiene su techo de rendimiento, y para cargas que escriben y borran todo el tiempo (logs, buffers de streaming, shuffles de procesamiento) ese ida y vuelta se nota.
El instance store cambia eso. Son discos NVMe físicamente pegados a la instancia EC2, sin red de por medio. Complementá con pipelines de CI/CD en Kubernetes.
¿El resultado? Latencias por debajo de las de EBS e IOPS que no se mueven tanto bajo carga. Eso sí: nada es gratis. Lo que ganás en velocidad lo pagás en persistencia, porque el instance store es efímero por diseño.
Diferencias entre clusters locales y clusters extendidos en Outposts
Acá viene lo bueno, porque mucha gente los confunde y elige mal. La diferencia de fondo es dónde corre el control plane y qué pasa cuando se cae el enlace con la región de AWS.
| Característica | Cluster local | Cluster extendido |
|---|---|---|
| Dónde corre el control plane | En el Outpost | En la región de AWS |
| Resiliencia ante desconexión de red | Sigue operando local | Pierde acceso al control plane |
| Latencia control plane ↔ nodos | Mínima (todo local) | Depende del enlace a la región |
| Capacidad requerida en el Outpost | Mayor (control plane + nodos) | Menor (solo worker nodes) |
| Caso típico | Sitios desconectados o de baja conectividad | Extender un cluster regional al borde |
Si tu sitio puede quedar incomunicado de AWS y aun así tiene que seguir orquestando contenedores, el cluster local es el camino. Si lo único que querés es estirar un cluster que ya vive en la región hacia el borde, el extendido te alcanza y te pide menos hardware en el Outpost. Ya lo cubrimos antes en herramientas de automatización de despliegues.
¿Qué requisitos técnicos y de almacenamiento tiene un EKS local cluster?
Antes de tirar el primer eksctl, conviene revisar la documentación de EKS en Outposts. Hay piezas que tienen que estar sí o sí.
- EBS para etcd: el control plane local reserva almacenamiento EBS dedicado para etcd, el cerebro de Kubernetes. Es un requisito fijo, no opcional.
- Solo EBS gp2 en Outposts: los Outposts no traen toda la familia de volúmenes EBS. El tipo disponible es gp2, así que dimensioná IOPS pensando en eso.
- Instancias con instance store: para usar disco NVMe local necesitás familias que lo incluyan, como C5d, M5d, R5d, G4dn o I3en. Las instancias sin la “d” no traen instance store.
- Capacidad de cómputo provisionada: el cluster local mete el control plane adentro del Outpost, así que reservá CPU y memoria de más respecto a un esquema extendido.
Subís el cluster, lo probás en local, todo anda, lo llevás a una carga real y de golpe el etcd empieza a sufrir porque dimensionaste el EBS pensando en un blog y no en un sistema de control plane que escribe sin parar, y ahí te das cuenta de que el almacenamiento no era el lugar para ahorrar.
Casos de uso reales del almacenamiento local en EKS Outposts
IoT y manufactura
Monitoreo en tiempo real de líneas de producción y mantenimiento predictivo. Acá la latencia manda: un pod que procesa señales de sensores no puede esperar a un disco lento. El instance store le da el buffer rápido que esas cargas necesitan, y el cluster local garantiza que la fábrica siga operando aunque se corte internet.
Procesamiento de datos en el borde
Pipelines de transformación que generan archivos intermedios pesados (los famosos shuffles de Spark, por ejemplo). Como esos datos son descartables, el instance store es ideal: velocidad alta y cero costo de transferencia hacia la región. Te puede servir nuestra cobertura de ejecutar cargas en infraestructura local.
Residencia de datos y baja latencia
Aplicaciones que por regulación tienen que mantener los datos dentro del país o del edificio. El cluster local resuelve el dónde, y el instance store resuelve el cuán rápido. Si además manejás infraestructura web propia para esos servicios, vale comparar opciones de donweb.com para el alojamiento regional en Argentina.
Cómo optimizar el almacenamiento en EKS Outposts
La regla mental es simple: efímero al instance store, persistente al EBS. El error es querer usar uno para todo.
- Elegí el CSI driver correcto: para volúmenes persistentes va el EBS CSI driver; para aprovechar el disco local efímero, configurá los pods contra el instance store de la instancia.
- Monitoreá IOPS de verdad: no asumas que el gp2 te alcanza. Medí con CloudWatch antes de declarar victoria.
- Separá cargas por tipo: bases de datos y estado de la app a EBS; cachés, colas y temporales al instance store.
- Acordate del ciclo de vida: si una instancia con instance store se detiene, esos datos no vuelven. Diseñá pensando en que pueden desaparecer.
Primeros pasos para desplegar un EKS local cluster en Outposts
La herramienta recomendada sigue siendo eksctl, que tiene soporte para Outposts. El flujo, a grandes rasgos:
- Verificá capacidad: confirmá que tu Outpost tiene el cómputo y el EBS gp2 libres para el control plane más los nodos.
- Definí la config del cluster: en el archivo de
eksctlindicá el ARN del Outpost y las instancias con instance store que vas a usar. - Creá el cluster local:
eksctllevanta el control plane dentro del Outpost, no en la región. - Probá la resiliencia: simulá un corte del enlace a la región y verificá que el cluster sigue respondiendo. Si no lo probás, no lo sabés.
Los detalles finos de cada flag están en la guía de clusters locales de AWS. Conviene leerla entera antes, no a mitad de un deploy.
Errores comunes al usar instance store en EKS Outposts
- Guardar datos críticos en instance store: es el clásico. Alguien pone una base ahí “porque vuela” y a la primera detención de instancia pierde todo. El instance store es para datos descartables, punto.
- Subdimensionar el EBS del etcd: el control plane local escribe en etcd sin parar. Si escatimás IOPS ahí, todo el cluster se vuelve lento y cuesta diagnosticar por qué.
- Elegir instancias sin la “d”: pedís instance store y arrancás con un tipo de instancia que no lo trae. No hay disco local que configurar y te enterás tarde.
- Confundir local con extendido: esperar resiliencia ante desconexión en un cluster extendido. No la vas a tener: el control plane está en la región.
Preguntas Frecuentes
¿Qué es un EKS local cluster en AWS Outposts?
Es una configuración de Amazon EKS donde el control plane de Kubernetes y los worker nodes corren íntegramente dentro del Outpost, en tu datacenter. Sigue operando aunque se pierda la conexión con la región de AWS. Relacionado: cargas de trabajo especializadas en GPU.
¿En qué se diferencia un cluster local de uno extendido?
En el cluster local el control plane vive en el Outpost; en el extendido vive en la región de AWS y solo los worker nodes están en el borde. Por eso solo el local resiste cortes de red con la región.
¿Los datos del EC2 instance store son permanentes?
No. El instance store es almacenamiento efímero: si la instancia se detiene o falla, los datos se pierden. Sirve para cachés, buffers y temporales, no para información que tengas que conservar.
¿Qué tipo de volúmenes EBS hay disponibles en Outposts?
En AWS Outposts el tipo de volumen EBS disponible es gp2. Dimensioná el rendimiento de tu control plane y tus cargas persistentes teniendo eso en cuenta, según la documentación de AWS.
¿Qué instancias permiten usar instance store con EKS?
Las familias que incluyen disco NVMe local, como C5d, M5d, R5d, G4dn e I3en. Las variantes sin la letra “d” no traen instance store, así que no vas a poder configurarlo en ellas.
Conclusión
El soporte de EC2 instance store en los EKS local clusters de Outposts cierra un hueco real: hasta ahora, las cargas efímeras de baja latencia en el borde dependían de EBS gp2 y su techo de rendimiento. Con el disco NVMe local ganás velocidad e IOPS parejos para cachés, buffers y procesamiento temporal, sin costos de transferencia.
El criterio para no equivocarte es claro. Efímero al instance store, persistente al EBS, y elegí cluster local solo si necesitás operar desconectado de la región. Si tu caso es IoT, manufactura o procesamiento de datos en sitio, esto te conviene revisarlo ya. Empezá verificando capacidad en el Outpost y leyendo la doc oficial antes del primer deploy.
