Introducción
Si administrás un cluster EKS con cargas de Apache Spark que escalan a cientos de executors concurrentes, conocés el dolor de agotar el espacio IPv4. Asignar un CIDR /16 a la VPC, reservar bloques para los pods, calcular cuántas interfaces ENI quedan libres, y aun así topar con el límite de 65.536 direcciones cuando un job de 500 executors levanta múltiples contenedores por nodo. El workaround clásico —CIDR secundarios, prefix delegation en ENIs, o migraciones parciales a dual-stack— introduce complejidad operativa que ningún equipo de plataforma quiere mantener indefinidamente.
AWS resolvió este problema de forma directa: Amazon EMR on EKS ahora soporta ejecución de workloads sobre clusters EKS con stack IPv6 puro. Desde las releases emr-7.14.0 y emr-spark-8.0.0, podés correr Spark, Flink, Livy y Spark Connect sobre una red IPv6 nativa sin reconfigurar los modelos de submission. El soporte está disponible en todas las regiones donde conviven EMR on EKS y clusters EKS IPv6, sin costo adicional.
Qué ocurrió
AWS anunció en septiembre de 2026 la disponibilidad general de soporte IPv6 para Amazon EMR on EKS. Esto significa que los clusters EKS provisionados con ipFamily: ipv6 (o ipFamily: dual-stack donde el pod networking opera sobre IPv6) ahora ejecutan job runs de EMR sin restricciones funcionales respecto a los clusters IPv4.
Los modelos de submission cubiertos incluyen: la API StartJobRun del servicio Virtual Cluster, los endpoints interactivos de Spark Connect, y la integración con Amazon SageMaker Unified Studio. En el plano de operadores, el Flink Operator, el Livy Operator y el Spark Operator de EMR operan correctamente sobre la pila IPv6. No hay configuración extra en el manifest del job ni flags adicionales en el spark-submit; el networking IPv6 es transparente para la capa de aplicación.
La decisión de AWS responde a una presión concreta del mercado: los equipos de data platform que migraron a EKS como plataforma de ejecución unificada se encontraron con que el agotamiento de direcciones IPv4 se convertía en un cuello de botella de escala antes que el cómputo o el almacenamiento. Un cluster con 200 nodos c5.4xlarge, cada uno con capacidad para 29 ENIs y 30 IPs por ENI, ofrece aproximadamente 174.000 direcciones. Para un job Spark con 500 executors donde cada executor consume al menos una IP, más los drivers, sidecars, servicios de Livy y health checks, el espacio se consume rápido.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para los equipos de plataforma que gestionan clusters EKS compartidos por múltiples equipos de data engineering, el soporte IPv6 en EMR on EKS elimina una clase completa de incidentes operativos. Los alertas por «IP exhaustion en subnet», los procesos de solicitud de CIDR secundarios a la red corporativa, y las ventanas de mantenimiento para reasignar bloques de direcciones dejan de ser parte del runbook diario.
En infraestructura, la migración a IPv6 en EKS no es trivial si el cluster ya está en producción. AWS no permite cambiar la ipFamily de un cluster EKS existente: necesitás provisionar un cluster nuevo con ipFamily: ipv6, migrar los workloads, y decomisionar el original. Sin embargo, para clusters nuevos o para equipos que aún no adoptaron EKS como plataforma de analytics, la decisión arquitectónica cambia: podés dimensionar la VPC con un /56 IPv6 y no preocuparte por el crecimiento del plano de pods durante años.
En seguridad, un cluster IPv6 puro elimina la complejidad de reglas de security group y NACLs que manejan simultáneamente tráfico IPv4 e IPv6. Los equipos de seguridad pueden simplificar las políticas de red del plano de data analytics: un único stack, un único conjunto de reglas, un único vector de auditoría. Esto reduce la superficie de error humano en la configuración de firewalls de red.
Para equipos de SRE, la métrica de «available IPs en subnet» deja de ser un KPI de capacity planning. El espacio IPv6 (/64 por subnet, con 2^64 direcciones) hace irrelevante el monitoreo de agotamiento de direcciones en condiciones normales de operación.
Detalles técnicos
Las versiones mínimas que habilitan este soporte son:
- Amazon EMR release: emr-7.14.0 o superior (para Spark 3.x)
- Amazon EMR Spark release: emr-spark-8.0.0 o superior (para Spark 4.x / Spark Connect)
- Amazon EKS: cluster provisionado con ipFamily: ipv6 o ipFamily: dual-stack (donde el pod networking usa IPv6)
- Amazon VPC: subnet con bloque IPv6 asociado (típicamente /64 por subnet)
El networking de pods sobre IPv6 en EKS depende de la CNI plugin. Con Amazon VPC CNI (aws-vpc-cni-k8s), los pods obtienen direcciones IPv6 directamente de la subnet de la VPC. Los job runs de EMR que levantan executors como pods heredan esta asignación sin configuración adicional.
Los operadores soportados y sus funciones:
- Spark Operator: gestiona el ciclo de vida de SparkApplication y SparkSession CRDs sobre IPv6
- Flink Operator: despliega y escala FlinkDeployment y FlinkSessionJob CRDs
- Livy Operator: expone sesiones de Spark interactivas vía REST sobre IPv6
- Spark Connect: endpoints gRPC interactivos que operan sobre la red IPv6 del cluster
Los modelos de submission soportados:
# StartJobRun vía AWS CLI
aws emr-containers start-job-run \
–virtual-cluster-id
–name «ipv6-spark-job» \
–release-label emr-7.14.0 \
–job-driver ‘{«sparkSubmitJobDriver»:{«entryPoint»:»s3://bucket/job.py»}}’ \
–role-arn arn:aws:iam::
–execution-role-arn arn:aws:iam::
No se requiere ningún flag –conf spark.driver.host=… ni ajustes de spark.network.timeout específicos para IPv6. La resolución de nombres entre executors y driver opera sobre DNS IPv6 del cluster.
La disponibilidad es regional: el soporte funciona en todas las regiones AWS donde simultáneamente existe EMR on EKS y clusters EKS con soporte IPv6. Esto incluye las regiones principales (us-east-1, us-west-2, eu-west-1, eu-central-1, ap-southeast-1) y se extiende a las restantes según el calendario de rollout de EKS IPv6.
Qué deberían hacer los administradores y equipos técnicos
Si administrás un cluster EKS nuevo para analytics:
Provisionalo directamente con IPv6. Al crear la VPC, asociá un CIDR IPv6 (AWS asigna un /56 por defecto). Al crear el cluster EKS, especificá la familia de direcciones:
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: analytics-ipv6-cluster
region: us-east-1
version: «1.32»
vpc:
cidr: «10.0.0.0/16»
ipFamily: IPv6
autoAllocateIPv6: true
nodeGroups:
– name: ng-emr-workers
instanceType: m6i.4xlarge
desiredCapacity: 10
Si operás un cluster EKS en producción con IPv4 y cargás EMR jobs:
No podés cambiar la ipFamily in-place. La ruta es: provisionar un cluster IPv6 en paralelo, validar los job runs de EMR con emr-7.14.0 o emr-spark-8.0.0, migrar los workloads por equipos o por línea de negocio, y decomisionar el cluster IPv4 original. Planificá una ventana de 4-8 semanas para la migración completa incluyendo validación de performance.
Si usás Spark Connect o SageMaker Unified Studio:
Actualizá tus endpoints de Spark Connect para apuntar al cluster IPv6. La API de submission no cambia, pero verificá que los clients (PySpark 4.0+, Spark Connect client) resuelvan correctamente los nombres DNS IPv6 del cluster. Si operás detrás de un service mesh (Istio, App Mesh), confirmá que el sidecar soporta tráfico IPv6 en el plano de datos.
Verificá la compatibilidad de tus dependencias:
Auditá que los conectores de Spark (S3A, Delta Lake, Iceberg, Kafka connector) no tengan hardcodeadas direcciones IPv4 en configuraciones de bootstrap o en políticas de red de security groups. Los security groups del cluster deben permitir tráfico IPv6 entre los pods de EMR (puertos 4040 para Spark UI, 7077 para master, 7337 para shuffle).
Conclusión
El soporte IPv6 en Amazon EMR on EKS no es una feature cosmética: elimina la restricción de escala que obligaba a los equipos de data platform a diseñar arquitecturas alrededor de un espacio de direcciones de 32 bits. Para workloads que escalan a cientos de executors concurrentes, la diferencia entre un /16 IPv4 y un /64 IPv6 por subnet es la diferencia entre un incidente de capacidad y un job que simplemente corre. La migración tiene fricción si el cluster ya está en producción, pero para toda nueva implementación de analytics sobre EKS, la decisión técnica es clara: IPv6 desde el día uno, con EMR 7.14.0 o Spark 8.0.0 como base.