Cómo elegir el tipo de instancia EC2 de AWS: guía práctica 2026

En corto: casi todas las cargas de trabajo deberían empezar en una instancia de la familia t o m y pasar a c, r o g solo cuando aparece un cuello de botella real. AWS EC2 lista cientos de tipos de instancia, pero en la práctica tocas apenas un puñado de familias en el día a día. No te obsesiones con elegir el tipo perfecto de entrada. Empieza pequeño, mira tus métricas en CloudWatch y muévete hacia el recurso que de verdad se te agota. En mi caso, lanzo todo servicio nuevo en t4g (Graviton), lo observo un mes y después decido.

Después de pagar personalmente varios años de estas facturas, te lo digo claro: los errores caros casi nunca vienen de no conocer las familias. Vienen de elegir un tipo una vez y olvidar que existe. Abajo repaso las letras de familia, cómo elegir según la carga, y las tres palancas que de verdad mueven la factura: Savings Plans, Spot y Graviton.

¿En qué se diferencian las familias? (t, m, c, r, i, g)

Un nombre como m7g.large se lee así: familia (propósito) + generación + g de Graviton (arm) + tamaño. Aprende a leer la letra y ya llevas la mitad.

Familia	Carácter	vCPU:memoria	Uso típico
t	Burstable, propósito general	1:2–1:4	Servidores web, APIs, dev/test, servicios chicos con picos
m	Propósito general equilibrado	1:4	Web apps de carga estable, backends medianos
c	Optimizada para cómputo	1:2	Procesos por lotes, servidores de juegos, codificación, APIs de alto tráfico
r	Optimizada para memoria	1:8	Cachés en memoria, bases de datos grandes, Redis/Elasticsearch
x	Memoria extra grande	1:16+	SAP HANA, bases de datos en memoria enormes
i	Optimizada para almacenamiento (NVMe)	—	Bases de datos con mucho IO, procesamiento de logs
g / p	GPU	—	Entrenamiento/inferencia de ML, transcodificación de video

La relación lo es todo. La familia c te da relativamente más CPU; la r te da más memoria. Elige la familia que se incline hacia el recurso que tu app agota primero. Si ya elegiste proveedor de nube y quieres el panorama AWS vs GCP vs Azure, lo cubrí en la comparación de hosting en la nube; aquí me quedo dentro de AWS.

Burstable (t) vs. rendimiento fijo (m): ¿dónde está la trampa?

La familia t confunde justamente por esa palabra, burstable. Una instancia t corre a una base (digamos 20-40%) de sus vCPUs y acumula el resto como créditos de CPU. Cuando el tráfico sube, quema créditos para acercarse al 100%.

La trampa aparece cuando los créditos se acaban. Si no estás en modo Unlimited, se limita a la base, y se da la escena rara de un CPU al 40% con el servicio arrastrándose. La regla de decisión es simple:

• El CPU sube y baja como sierra → gana la familia t.
• El CPU se mantiene arriba del 60% de forma constante → gana la familia m (correr t en modo Unlimited todo el día sale más caro).

Entornos de desarrollo, herramientas internas, blogs y landing pages con tráfico irregular son un caso de libro para t. Intentar sostener una API de pagos siempre ocupada con una instancia t es el error clásico.

¿Qué elijo para mi carga de trabajo?

Así lo mapearía yo. Tómalo como punto de partida y ajusta tras dos semanas de métricas.

Carga de trabajo	Primera opción	Por qué
Servicio web / API nuevo	t4g	Barato, burstable, fácil de migrar
Backend de carga estable	m7g	Equilibrado, rendimiento predecible
Lotes / codificación / servidor de juegos	c7g	Intensivo en cómputo, importa por núcleo
Caché / búsqueda / BD grande	r7g	Margen de memoria, evita OOM
Runners de CI / renderizado	c (Spot)	Tolera interrupciones, muy paralelo
Inferencia de ML	g (Spot/horario)	Necesita GPU, desperdicio si está siempre prendida
BD de logs / series temporales	i	Rendimiento de NVMe local

Corre siempre la generación más nueva. m7 suele ganarle a m6 al mismo precio; t4g le gana a t3. Dejar launch templates viejos es la fuga silenciosa número uno. Si estás armando un equipo que necesita entender todo esto, vale la pena verificar si las bases están de verdad; entré en esa cuestión de habilidades en el artículo sobre el retorno de un bootcamp de programación.

¿Cambiar a Graviton (arm) de verdad lo hace más barato?

Sí, y hoy es la victoria más segura en optimización de costos de EC2. Graviton es el procesador arm propio de AWS, marcado con el sufijo g (t4g, m7g, c7g, r7g). Espera cerca de 20% mejor relación precio-rendimiento que el x86 equivalente. Cambiar una letra del tipo de instancia baja la factura: un almuerzo gratis, y eso es raro.

El único obstáculo es la compatibilidad de arquitectura. La mayoría de los intérpretes y runtimes (Node, Python, Go, Java, Ruby) y las imágenes Docker oficiales ya traen arm64. Verifica estas tres cosas:

• ¿Tu imagen de contenedor construye una variante multiarquitectura linux/arm64?
• ¿Tus extensiones nativas (paquetes de Python con extensiones en C, por ejemplo) traen wheels arm?
• ¿Tus agentes comerciales de monitoreo/seguridad soportan arm?

Si pasas esas tres, la mayoría de las migraciones son tranquilas. Las herramientas de IA para programar reducen muchísimo el trabajo pesado de Dockerfiles multiarquitectura y scripts de migración; cuáles valen la pena en el día a día está en mi comparación de Cursor vs. Copilot.

¿Cuánto se ahorra? (Savings Plans, Spot, On-Demand)

El modelo de compra importa tanto como el tipo. La misma c7g puede costar 3-4 veces más o menos según cómo la compres.

Modelo de compra	Descuento	Flexibilidad	Riesgo	Ideal para
On-Demand	Ninguno (base)	Máxima	Ninguno	Corto, irregular, pruebas
Compute Savings Plans	Grande (1/3 años)	Alta (cambias familia/región)	Penalidad por subuso	Base siempre encendida
EC2 Instance Savings Plans	Mayor	Baja (familia fija)	Menos flexible	Núcleo totalmente fijo
Spot	Hasta 70-90%	Baja	Reclamo en 2 min	Trabajo que tolera interrupciones

La estrategia real es por capas. Compromete tu base siempre encendida a un Savings Plan por el descuento, monta el tráfico variable en On-Demand, y llena el hueco tolerante a interrupciones con Spot. La Mixed Instances Policy de un Auto Scaling group te deja fijar por política la proporción On-Demand/Spot. Empieza conservador: comprométete quizá a un 70% de cobertura según la recomendación de Savings Plans en Cost Explorer, y ajusta después. En términos de LatAm y España, recuerda que la factura de AWS llega en dólares aunque tu presupuesto esté en pesos o euros, así que el tipo de cambio es parte del costo. Trata el gasto de nube como un costo operativo fijo en dólares y métele en la revisión financiera mensual, no solo en el canal de ingeniería.

¿Cuáles son los errores comunes? (un caso de fracaso)

Junto las minas típicas en una sola historia.

El caso: una startup que se asustó con la factura. Un equipo corría producción en cuatro m5.2xlarge On-Demand. El tráfico solo subía en horario laboral, pero las cuatro corrían toda la noche a un 15% de CPU promedio. Encima, sus runners de CI eran máquinas On-Demand aparte, siempre encendidas. Desglosado:

1. Sobredimensionado — 15% de CPU significa que podían bajar dos tamaños. Compute Optimizer ya recomendaba m7g.large.
2. Sin Spot — los runners de CI pueden reiniciarse si se interrumpen, y aun así quemaban dinero en On-Demand.
3. Generación vieja, x86 por inercia — pasar de m5 (x86) a m7g (Graviton) ya ahorraba casi un 20%.
4. Sin compromiso — una base encendida todo el año sin ningún Savings Plan asociado.

Corregir esos cuatro puntos bajó la factura mensual a menos de la mitad. Nada de magia, solo las bases: última generación, Graviton, tamaño correcto, comprometer la base, Spot para el excedente variable. Si tu equipo opera infraestructura en remoto, mete esta revisión de costos en una rutina periódica; la cadencia operativa que describí en la guía de trabajo remoto aplica directo.

Qué revisar cada mes

El tipo de instancia no es una decisión de configurar y olvidar. Esto reviso cada mes:

• Recomendaciones de Compute Optimizer — la lista de sobre/subdimensionadas.
• Cobertura y uso de Savings Plans — ¿hay algún compromiso ocioso?
• Tasa de interrupción de Spot — si un tipo es reclamado seguido, amplía tus tipos candidatos.
• Renovación de generación — cuando llega una nueva, mídela y evalúa el cambio.
• Ubicación de región — ¿alguna carga insensible a latencia quedó atrapada en una región cara?

El gasto en infraestructura de nube termina pareciéndose mucho a gestionar una cartera. Fijas la base con un compromiso como quien mantiene una posición de largo plazo, y tomas la exposición variable con flexibilidad vía Spot. Esa mentalidad de asignación rima sorprendentemente bien con la lógica de cartera que expuse en la guía de inversión en acciones de IA.

En resumen: empieza pequeño, mira las métricas y acciona las tres palancas —Graviton, Savings Plans, Spot— en ese orden. Ese solo hábito cambia tu factura de EC2 más que cualquier otra cosa.

Este artículo tiene fines únicamente informativos y no recomienda ninguna arquitectura ni modelo de compra en particular. Los precios y especificaciones de AWS cambian con frecuencia, así que confirma siempre los costos reales en la página oficial de precios de AWS y en el Cost Explorer de tu propia cuenta.