PerfectScale

Precios de Amazon EKS: costos ocultos y 6 formas de reducir tu factura

Esta página también está disponible en English, Deutsch, Français, Italiano, 日本語 y Português.

Josh Palmer
By Josh Palmer
Aug 20, 202614 min read

¿Qué es el modelo de precios de Amazon EKS?

Amazon EKS cobra una cuota fija de $0.10 por hora por el plano de control de cada clúster (aprox. $72/mes). Además, pagas por los recursos de AWS subyacentes (instancias EC2, Fargate, volúmenes EBS, balanceadores de carga) que se utilizan para ejecutar tus nodos worker y tu aplicación. El soporte extendido para versiones antiguas de Kubernetes cuesta $0.60 por hora.

Entender los precios de EKS es fundamental para que las organizaciones estimen sus gastos en la nube con precisión y eviten costos inesperados. AWS ofrece varios modos operativos para EKS, cada uno con su propia estructura de costos. Es necesario evaluar las implicaciones de costo de usar clústeres estándar, grupos de nodos administrados, opciones de auto scaling y complementos opcionales. Analizar estos componentes desde el principio permite planificar el presupuesto de forma efectiva y optimizar los costos.

Este artículo forma parte de una serie sobre los precios de Kubernetes.

En este artículo:

Componentes de los precios de AWS EKS

Repasemos los principales componentes de costo de los clústeres de Amazon EKS.

Precios de los clústeres de Amazon EKS

Amazon EKS cobra una cuota por hora por cada clúster de EKS. El precio depende del nivel de soporte de la versión de Kubernetes que utiliza el clúster:

  • Los clústeres que ejecutan una versión de Kubernetes con soporte estándar cuestan $0.10 por clúster por hora.
  • Una versión de Kubernetes permanece en soporte estándar durante los primeros 14 meses después de su lanzamiento en Amazon EKS.
  • Cuando termina el soporte estándar, la versión entra en soporte extendido durante los siguientes 12 meses.
  • El soporte extendido cuesta $0.60 por clúster por hora. Esto incluye la cuota estándar de $0.10 por hora más $0.50 adicionales por clúster por hora.

Estos precios aplican al clúster de EKS en sí. Los recursos de AWS que utilizan tus workloads, como instancias EC2, volúmenes EBS, direcciones IPv4 públicas o cómputo de Fargate, se pagan por separado.

Precios de Amazon EKS Provisioned Control Plane

Amazon EKS Provisioned Control Plane permite reservar una cantidad definida de capacidad del plano de control para un clúster. Esta opción está pensada para workloads que necesitan un rendimiento estable del plano de control, una respuesta más rápida ante picos de tráfico o soporte para operaciones de Kubernetes a mayor escala.

El precio se basa en el nivel de escalado del plano de control seleccionado. El cargo es por hora y se suma a la cuota estándar del clúster de EKS. No hay pagos iniciales ni commitments a largo plazo:

  • El nivel XL cuesta $1.65 por clúster por hora.
  • El nivel 2XL cuesta $3.40 por clúster por hora.
  • El nivel 4XL cuesta $6.90 por clúster por hora.
  • El nivel 8XL cuesta $13.90 por clúster por hora.

Es posible cambiar entre niveles de escalado o volver al plano de control estándar. Para niveles superiores a 8XL, AWS requiere contactar al equipo de cuenta para conocer los precios.

Amazon EKS Auto Mode

Los precios de Amazon EKS Auto Mode aplican a los clústeres donde EKS Auto Mode está habilitado. El cargo se basa en el tipo y la duración de las instancias de Amazon EC2 que EKS Auto Mode lanza y administra. Esta cuota es independiente del precio de la instancia EC2. Pagas el costo normal de EC2 por las instancias subyacentes, mientras que EKS Auto Mode agrega su propio cargo de administración.

EKS Auto Mode se factura por segundo, con un mínimo de un minuto. El cargo es independiente de la opción de compra de EC2, por lo que aplica ya sea que las instancias usen precios On-Demand, Reserved Instances, Compute Savings Plans o instancias Spot. Las organizaciones que planean usar EKS Auto Mode con más de 150 nodos deben contactar a su equipo de cuenta de AWS para obtener información de precios.

Precios de Amazon EKS Capabilities

Los precios de Amazon EKS Capabilities aplican cuando se habilitan capacidades específicas en un clúster de EKS. El precio tiene dos partes por hora: un cargo base por cada capacidad habilitada y un cargo por uso según la cantidad de recursos administrados por esa capacidad:

  • Para Argo CD en US East (Ohio), el cargo base es de $0.02771 por hora de capacidad de Argo CD. El cargo por uso es de $0.00136 por hora de aplicación de Argo CD. Cada aplicación se cuenta por cada despliegue en un clúster de destino, por lo que una aplicación desplegada en cinco clústeres cuenta como cinco aplicaciones.
  • Para AWS Controllers for Kubernetes (ACK), el cargo base es de $0.004482 por hora de capacidad de ACK. El cargo por uso es de $0.000045 por hora de recurso de ACK.
  • Para Kubernetes Resource Orchestrator (KRO), el cargo base es de $0.004482 por hora de capacidad de KRO. El cargo por uso es de $0.000045 por hora de instancia RGD de KRO.
  • Todos los cargos de EKS capabilities se facturan por hora. No hay pagos iniciales ni commitments mínimos.

Precios de Amazon EKS Hybrid Nodes

Amazon EKS Hybrid Nodes permite conectar infraestructura on-premises o de edge a clústeres de Amazon EKS. Esto hace posible que los workloads de Kubernetes usen infraestructura fuera de AWS mientras la administración del clúster permanece en Amazon EKS.

El precio se basa en las vCPU-hora reportadas a Kubernetes:

  • La facturación comienza cuando un nodo híbrido se une al clúster y se detiene cuando el nodo se elimina.
  • En entornos bare metal con hyperthreading habilitado, cada núcleo físico de CPU reporta dos vCPU a Kubernetes, y la facturación usa el conteo de vCPU reportado.

Los precios de Hybrid Nodes están escalonados según el uso mensual agregado de vCPU-hora en la misma región de AWS:

  • Las primeras 576,000 vCPU-hora mensuales cuestan $0.020 por vCPU-hora.
  • Las siguientes 576,000 cuestan $0.014 por vCPU-hora.
  • Las siguientes 4,608,000 vCPU-hora mensuales cuestan $0.010 por vCPU-hora.
  • Las siguientes 5,760,000 cuestan $0.008 por vCPU-hora.
  • El uso por encima de 11,520,000 vCPU-hora mensuales cuesta $0.006 por vCPU-hora.

Si se utiliza facturación consolidada a través de AWS Organizations, estos niveles aplican entre las cuentas de la organización para la misma región. Quienes planeen ejecutar nodos híbridos en máquinas con más de 32 vCPU cada una deben contactar a su equipo de cuenta de AWS.

Precios de EKS Anywhere

Amazon EKS Anywhere es software de código abierto que ejecuta clústeres de Kubernetes en hardware dentro de un centro de datos o un entorno de edge. El software en sí está disponible como código abierto, pero AWS vende Enterprise Subscriptions para soporte y capacidades adicionales:

  • Una Amazon EKS Anywhere Enterprise Subscription brinda soporte para clústeres de EKS Anywhere con licencia. También da acceso a los EKS Anywhere Curated Packages, que agregan funciones como balanceo de carga, observabilidad y auto scaling.
  • Se requiere AWS Enterprise Support o AWS Enterprise On-Ramp Support antes de comprar una EKS Anywhere Enterprise Subscription.
  • Las suscripciones pueden comprarse a través de la consola de Amazon EKS, la API o la AWS CLI.
  • El precio es fijo por clúster y no depende del tamaño del clúster. Un plazo de un año cuesta $24,000 por clúster, facturado a $2,000 por mes. Un plazo de tres años cuesta $18,000 por clúster al año, facturado a $1,500 por mes.
  • Es posible incluir una o más licencias de clúster de EKS Anywhere en una sola compra de suscripción.
  • Las suscripciones pueden configurarse para renovarse automáticamente y pueden cancelarse sin cargo dentro de los primeros siete días.

Costos ocultos y adicionales de Amazon EKS

Más allá de los componentes básicos, existen costos adicionales que quizá no tengas en el radar y que también están relacionados con tus clústeres de EKS.

Costos de almacenamiento

Ejecutar workloads en Amazon EKS suele requerir almacenamiento persistente, lo que conlleva costos adicionales. Estos costos surgen típicamente del uso de volúmenes de Amazon EBS, Amazon EFS (Elastic File System) o buckets de S3 para almacenamiento de objetos. El precio de estos servicios de almacenamiento se basa en la cantidad de almacenamiento aprovisionado, el tipo de almacenamiento (por ejemplo, SSD vs. HDD) y los requisitos de IOPS. Si los workloads requieren almacenamiento de alto rendimiento o grandes capacidades, los costos de almacenamiento pueden superar la cuota base del clúster de EKS.

Los costos de almacenamiento también incluyen cargos por respaldos, snapshots y transferencia de datos. Por ejemplo, crear snapshots de EBS de forma regular para recuperación ante desastres o cumplimiento normativo puede generar cargos mensuales adicionales. Conviene monitorear el uso de almacenamiento, eliminar volúmenes sin usar y ajustar el tamaño de las clases de almacenamiento para evitar gastos innecesarios. Comprender el alcance completo de los costos de almacenamiento ayuda a prevenir desviaciones de presupuesto en entornos de EKS.

Costos de transferencia de datos

Los costos de transferencia de datos en Amazon EKS suelen pasarse por alto, pero pueden impactar tu factura total de AWS. AWS cobra por los datos transferidos desde los clústeres de EKS hacia internet, entre zonas de disponibilidad y, en algunos casos, entre servicios de AWS en distintas regiones. Para aplicaciones con alto tráfico saliente o comunicación entre zonas, estas cuotas pueden acumularse y convertirse en una parte significativa del costo total.

Diseña la arquitectura de tus workloads de EKS para minimizar la transferencia de datos innecesaria. Por ejemplo, mantén el tráfico dentro de la misma zona de disponibilidad cuando sea posible, o usa AWS PrivateLink para la comunicación entre servicios y así reducir costos. Revisa con frecuencia los patrones de transferencia de datos y ajusta la topología de red para controlar estos gastos en tus despliegues de EKS.

Costos de NAT Gateway

Los clústeres de Amazon EKS que necesitan acceso a internet desde subredes privadas suelen usar NAT Gateways. AWS cobra tanto por el uso por hora de cada NAT Gateway como por la cantidad de datos procesados a través de ellos. En entornos de alto tráfico o clústeres con múltiples subredes privadas, los cargos de NAT Gateway pueden acumularse rápidamente.

Para reducir los costos de NAT Gateway, considera consolidar el tráfico en menos gateways o usar instancias NAT cuando los requisitos de rendimiento sean menores. Monitorea el uso de los NAT Gateways y revisa la arquitectura de red para identificar oportunidades de ahorro. Como los cargos de NAT Gateway no están incluidos en los precios del plano de control ni de los nodos de EKS, inclúyelos en los cálculos del costo total de propiedad de EKS.

Registro y monitoreo con CloudWatch

Amazon CloudWatch se usa habitualmente para el registro y monitoreo de clústeres de EKS, pero sus costos son independientes de los precios de EKS. Los cargos de CloudWatch se basan en el volumen de logs ingeridos, las métricas almacenadas y los dashboards creados. El registro de alta frecuencia, los logs de aplicación demasiado detallados o las métricas personalizadas extensas pueden aumentar los costos, especialmente en entornos de EKS grandes o dinámicos.

Conviene implementar políticas de retención de logs, filtrar los logs innecesarios y agregar las métricas para controlar los gastos de CloudWatch. Usar muestreo de logs o soluciones de registro de terceros también puede reducir costos. Revisa el uso de CloudWatch con frecuencia y optimiza la recopilación de logs y métricas para evitar cargos inesperados sin perder la observabilidad que tus workloads de EKS necesitan.

Ejemplos de precios de Amazon EKS

Ejemplo 1: precios de un clúster de EKS con soporte estándar y extendido

Un clúster de EKS ejecuta la misma versión de Kubernetes durante 26 meses sin actualizar el plano de control. Durante los primeros 14 meses, la versión está bajo soporte estándar, con un costo de $0.10 por clúster por hora. Después, entra en soporte extendido durante 12 meses a $0.60 por clúster por hora.

Para ver la diferencia de costo en concreto: durante los 14 meses de soporte estándar, el clúster cuesta aproximadamente $1,022 en cuotas totales de clúster (14 × 730 horas × $0.10). Durante los 12 meses de soporte extendido, esa cifra sube a $5,256 (12 × 730 horas × $0.60), más de cinco veces el costo pese a durar dos meses menos. En promedio, a lo largo de los 26 meses completos, el precio efectivo es de $0.33 por clúster por hora.

Ejemplo 2: precios de EKS Hybrid Nodes para varias unidades de negocio

Tres unidades de negocio usan EKS Hybrid Nodes, cada una en un clúster de EKS dedicado con soporte estándar de la versión de Kubernetes, lo que da a cada una un cargo mensual de clúster de $73 (730 horas × $0.10).

La Unidad de Negocio 1 ejecuta 8 nodos de 8 vCPU cada uno, lo que genera 46,720 vCPU-hora y un cargo por nodos de $934.40. La Unidad de Negocio 2 ejecuta 4 nodos de 16 vCPU cada uno, lo que genera 46,720 vCPU-hora y un cargo por nodos de $934.40. La Unidad de Negocio 3 ejecuta 6 nodos de 4 vCPU cada uno, lo que genera 17,520 vCPU-hora y un cargo por nodos de $350.40.

En conjunto, las tres unidades consumen 110,960 vCPU-hora en el mes. Como esto está muy por debajo del límite del primer nivel de 576,000 vCPU-hora mensuales, todo el uso se factura a $0.02 por vCPU-hora. La factura mensual total de EKS es de $2,438.20, compuesta por $219 en cargos de clúster y $2,219.20 en cargos de nodos.

Ejemplo 3: ejemplo de precios de Amazon EKS Auto Mode

Una aplicación en contenedores se ejecuta en Amazon EKS Auto Mode en la región US West (Oregon). La aplicación tiene pods de frontend, pods de backend y pods de procesamiento por lotes. EKS Auto Mode selecciona una combinación de instancias EC2 para cumplir con los requisitos de estos workloads.

Las instancias seleccionadas son c6a.2xlarge, c6a.4xlarge, m5a.2xlarge y m5a.xlarge. Su costo combinado de EC2 es de $1.434 por hora. EKS Auto Mode agrega una cuota de administración adicional de $0.17208 por hora por esas instancias.

En un mes, esto equivale a $1,046.82 en costos de instancias EC2 y $125.62 en cuotas de EKS Auto Mode. Este ejemplo muestra que los precios de EKS Auto Mode se suman al costo subyacente de EC2 en lugar de reemplazarlo.

6 formas de reducir y optimizar los costos de Amazon EKS

1. Ajusta el tamaño de los nodos worker y de las solicitudes de los pods

Los nodos worker sobredimensionados y las solicitudes de recursos infladas en los pods son fuentes comunes de pérdida en el gasto de EKS. Kubernetes programa los pods según la CPU y la memoria solicitadas, no según el uso real. Si las solicitudes están configuradas demasiado altas, los clústeres pueden escalar innecesariamente, dejando grandes porciones de la capacidad de los nodos sin usar mientras siguen generando costos de EC2.

Los equipos deben analizar con regularidad el consumo real de recursos y ajustar las solicitudes y los límites en consecuencia. Herramientas como el metrics server de Kubernetes, Prometheus, Vertical Pod Autoscaler (VPA), KEDA y Goldilocks pueden ayudar a identificar asignaciones ineficientes. Usar tipos de instancia más pequeños, grupos de instancias mixtos o instancias basadas en Graviton también puede mejorar la eficiencia de costos.

El autoescalado del clúster debe configurarse para eliminar automáticamente los nodos sin usar. Combinar un dimensionamiento preciso de los pods con el autoescalado reduce la infraestructura ociosa y mantiene una mejor densidad de workloads en todo el clúster.

2. Usa instancias Spot para workloads tolerantes a fallos

Las instancias Spot de Amazon EC2 pueden reducir los costos de cómputo de EKS porque usan capacidad sobrante de AWS a precios con descuento. Los precios de Spot suelen ser entre un 70% y un 90% más bajos que los precios estándar On-Demand, lo que las hace adecuadas para workloads que pueden tolerar interrupciones.

Las aplicaciones sin estado, los trabajos por lotes, los pipelines de CI/CD, los workers en segundo plano y las tareas de procesamiento de datos son buenos candidatos para usar Spot. Los grupos de nodos de Kubernetes pueden combinar instancias Spot y On-Demand para que los workloads críticos se mantengan estables mientras los tolerantes a fallos usan capacidad de menor costo.

Para mejorar la confiabilidad, usa múltiples tipos de instancia y zonas de disponibilidad en los grupos de nodos Spot. Funcionalidades de Kubernetes como los Pod Disruption Budgets y el Cluster Autoscaler ayudan a que los workloads se recuperen automáticamente cuando ocurren interrupciones de Spot.

3. Optimiza los balanceadores de carga y el ingress

Cada servicio de Kubernetes de tipo LoadBalancer en EKS suele aprovisionar un balanceador de carga de AWS dedicado. En entornos grandes, los balanceadores de carga innecesarios o duplicados pueden generar costos mensuales considerables, especialmente al usar Application Load Balancers o Network Load Balancers.

Usar un controlador de ingress centralizado permite que varias aplicaciones compartan un solo balanceador de carga en lugar de aprovisionar uno por servicio. El AWS Load Balancer Controller admite el enrutamiento de múltiples aplicaciones a través de balanceadores compartidos mediante reglas basadas en host o en ruta.

Elimina los balanceadores de carga sin usar y revisa con regularidad los recursos de ingress inactivos. Los servicios de uso interno deben evitar balanceadores expuestos a internet a menos que se requiera acceso externo. Optimizar la arquitectura de ingress reduce tanto los cargos de balanceadores como los costos de transferencia de datos relacionados.

4. Identifica recursos ociosos e infrautilizados

Los recursos de Kubernetes sin usar suelen seguir generando cargos de AWS incluso cuando las aplicaciones ya no están activas. Los nodos EC2 ociosos, los volúmenes EBS sin adjuntar, los balanceadores de carga huérfanos, las Elastic IPs sin usar y los namespaces inactivos son ejemplos comunes de pérdida en entornos de EKS.

Las revisiones periódicas de costos y utilización ayudan a identificar recursos que se pueden eliminar o consolidar. AWS Cost Explorer, AWS Compute Optimizer, Kubecost y las herramientas de monitoreo de Kubernetes pueden rastrear el uso ineficiente de recursos en los clústeres.

Automatizar los procesos de limpieza mejora el control de costos. Las organizaciones pueden usar políticas de ciclo de vida, apagados programados para entornos que no son de producción y reglas de expiración de namespaces para reducir el gasto innecesario. El monitoreo continuo es importante porque los entornos de Kubernetes cambian con frecuencia a medida que los workloads escalan y los equipos despliegan nuevos servicios.

5. Actualiza las versiones de Kubernetes antes del soporte extendido

Amazon EKS aumenta el precio del clúster una vez que una versión de Kubernetes pasa del soporte estándar al soporte extendido. La cuota por hora del clúster sube de $0.10 a $0.60 por hora de clúster, lo que puede incrementar los costos en múltiples clústeres.

Las actualizaciones regulares de Kubernetes ayudan a las organizaciones a evitar estos cargos adicionales, además de mejorar la seguridad, la estabilidad y la disponibilidad de funcionalidades. Establecer un calendario de actualizaciones predecible reduce el riesgo de que los clústeres permanezcan en versiones sin soporte durante largos períodos.

Prueba las actualizaciones en entornos de staging antes de pasarlas a producción para reducir el riesgo operativo. Los equipos también deben seguir el calendario de lanzamientos de Amazon EKS y planificar las actualizaciones con suficiente anticipación para evitar migraciones apresuradas cerca de las fechas límite de soporte.

6. Usa Karpenter para un aprovisionamiento de nodos más inteligente

Karpenter puede ayudar a reducir los costos de Amazon EKS al aprovisionar capacidad de cómputo según los requisitos reales de los pods, en lugar de depender únicamente de grupos de nodos predefinidos. Evalúa los pods pendientes y lanza instancias EC2 del tamaño adecuado para las necesidades de los workloads, lo que puede mejorar el empaquetado (bin packing), reducir la capacidad ociosa y acelerar el escalado.

A diferencia de las configuraciones tradicionales del Cluster Autoscaler, que dependen en gran medida de los Auto Scaling Groups, Karpenter puede elegir entre una gama más amplia de tipos de instancia, tamaños, zonas de disponibilidad, arquitecturas y tipos de capacidad. Esta flexibilidad permite a los equipos usar una combinación más diversa de instancias On-Demand, Spot y basadas en Graviton sin comprometer la disponibilidad de las aplicaciones.

Karpenter es especialmente útil para workloads dinámicos o variables porque puede agregar capacidad rápidamente cuando los pods no pueden programarse y consolidar los nodos infrautilizados cuando la demanda baja. Los equipos deben configurar los NodePools con requisitos de instancia adecuados, controles de disrupción, políticas de consolidación y restricciones de workloads para equilibrar el ahorro de costos con la confiabilidad.

Optimiza los costos de EKS con PerfectScale

EKS te ofrece una plataforma potente para ejecutar workloads en contenedores, pero su modelo de precios hace que las configuraciones de recursos ineficientes se traduzcan directamente en facturas más altas. Las solicitudes de CPU y memoria sobredimensionadas hacen que los clústeres escalen más de lo necesario, manteniendo nodos EC2 en funcionamiento con baja utilización mientras los costos se acumulan. PerfectScale by DoiT elimina esta pérdida al analizar continuamente el consumo real de los workloads en tus clústeres de EKS y aplicar right-sizing de forma autónoma a las solicitudes y los límites de CPU y memoria, sin necesidad de ajustes manuales ni tiempo de tus Engineers.

A diferencia de las herramientas que solo proponen recomendaciones que los equipos rara vez tienen capacidad de aplicar, PerfectScale ejecuta las optimizaciones de forma automática, manteniendo salvaguardas para proteger el rendimiento y la disponibilidad. Detecta y corrige en tiempo real riesgos de resiliencia como OOM kills, throttling de CPU y desalojos de pods, de modo que el ahorro de costos no se logra a expensas de la estabilidad. El resultado es un clúster más compacto y mejor utilizado, que gasta menos en capacidad EC2 innecesaria mientras mantiene la confiabilidad que tus workloads requieren.

Descubre cómo PerfectScale reduce los costos de EKS de forma autónoma