El placement de cargas es la decisión de en qué nube, región o entorno corre cada aplicación, y en la mayoría de las empresas no se toma: se hereda. La encuesta 2026 de Flexera a 753 decisores estima que 29% del gasto en nube se desperdicia, la primera alza en cinco años, y describe un multi-cloud que crece a menudo sin estrategia deliberada. Este artículo propone cinco criterios para el placement de cargas y un protocolo de 30 días para medir el TCO de cada una.
Lo esencial
- 29% del gasto cloud se desperdicia según Flexera 2026, y el multi-cloud crece a menudo sin plan.
- El placement de cargas se decide con cinco criterios: data gravity, residencia, latencia, descuentos por compromiso y costo operativo.
- El TCO por carga se compara con datos FOCUS de cada proveedor, no con promedios de mercado.
Por qué el placement de cargas se hereda y no se decide
Flexera, que también vende herramientas FinOps, sugiere que el avance del multi-cloud responde a fusiones, equipos aislados y arquitecturas heredadas más que a una estrategia, según su análisis del informe 2026. El resultado es un inventario donde cada carga vive donde la dejó alguien, no donde conviene.
La gobernanza tampoco lo corrige sola. En la misma encuesta, 71% de las organizaciones opera un Cloud Center of Excellence y 63% tiene equipo FinOps, según el comunicado de Flexera, y aun así el desperdicio subió. Mi lectura: sin una regla explícita de placement de cargas, FinOps mide el gasto, pero no puede decidir dónde debería vivir cada carga.
Multi-cloud no falla por tener varias nubes. Falla cuando nadie decidió qué carga vive en cuál, ni por qué.
Cinco criterios para el placement de cargas
1. Data gravity y costo de egress
El dato es lo más caro de mover. AWS, por ejemplo, incluye 100 GB mensuales de salida gratuita a internet y cobra el resto por volumen, según su página de precios de EC2. Regla de partida: el cómputo va donde vive el dato, salvo que el volumen sea pequeño o el ahorro supere la transferencia recurrente.
2. Residencia y regulación
Si la carga toca datos regulados, la región deja de ser una preferencia de costo y pasa a ser una restricción. Ya lo desarrollamos en soberanía de datos y arquitectura en LATAM; aquí basta tratarlo como filtro previo al precio.
3. Latencia medida, no supuesta
Mida el percentil 95 desde sus sedes y usuarios hacia cada región candidata: la más cercana en el mapa no siempre es la más rápida.
4. Descuentos por compromiso
Savings Plans, reservas y compromisos de uso se contratan por proveedor. Repartir cargas estables entre tres nubes diluye la cobertura de cada compromiso. Regla de partida: concentre lo estable donde ya hay compromiso y deje la segunda nube para lo que la justifique.
5. Costo operativo de la segunda nube
Cada nube adicional duplica modelos de identidad, runbooks, observabilidad y habilidades del equipo. Ese costo son horas de personas: no aparece en la factura del proveedor, pero sí en el TCO.
Punto clave
En el placement de cargas, una carga solo cambia de nube si el ahorro recurrente supera el egress, la migración y el costo operativo de mantener otra nube. Si no, se queda donde está y se gobierna.
Si este análisis te resulta útil, recíbelo cada semana: 👉 Suscríbete al newsletter de DacmosGroup
Cómo medir el TCO del placement de cargas en multi-cloud
Comparar facturas de tres proveedores exige un idioma común. FOCUS, la especificación abierta de la FinOps Foundation, normaliza los datos de costo y uso entre proveedores, y su sitio oficial lista exportaciones en versión 1.2 para AWS, Microsoft Azure y Google Cloud. Con esos datos en un solo almacén, compare el costo efectivo (EffectiveCost, que amortiza descuentos) por carga, no por cuenta.
| Tipo de carga | Criterio dominante | Regla de partida |
|---|---|---|
| Base transaccional con datos regulados | Residencia y data gravity | Región única; DR en el mismo marco regulatorio |
| Analítica sobre datos ya alojados | Data gravity | Misma nube que los datos |
| Entrenamiento o inferencia de IA | Capacidad de GPU y costo | Nube con capacidad; copiar solo lo necesario |
| ERP o SaaS corporativo | Costo de migración | No mover; gobernar |
El protocolo de placement de cargas cabe en un mes: inventario con dueño y ubicación de datos (semana 1), exportación FOCUS consolidada (semana 2), puntuación de cada carga contra los cinco criterios (semana 3) y nube por defecto con proceso de excepción (semana 4). Si el resultado dice que una carga vive en la nube equivocada, la repatriación de cargas es el movimiento inverso.
Preguntas frecuentes
¿Cuándo tiene sentido multi-cloud en una PyME?
Cuando una carga tiene una restricción que la primera nube no resuelve: residencia, capacidad de GPU o un SaaS ya alojado en otra. Sin esa razón, la segunda nube suma costo operativo y diluye descuentos.
¿Cómo se calcula el TCO real de una carga con placement de cargas multi-cloud?
Sume cómputo y almacenamiento con descuentos amortizados, egress, replicación, licencias y horas de operación. Exporte los costos en formato FOCUS y asigne cada línea a una carga, no a una cuenta.
El framework de placement de cargas no elimina el multi-cloud: le pone precio. Cuando una carga justifica su segunda nube con un criterio explícito, deja de ser deuda heredada y pasa a ser una decisión de arquitectura con dueño. Para ver cómo cambia este cálculo si Panamá se consolida como hub, revise multi-cloud y el hub digital de Panamá.
¿Sabe hoy en qué nube corre cada una de sus cargas críticas, y por qué corre ahí?
Cuéntenos en los comentarios cuál fue la decisión de placement de cargas que más caro le salió.
Cada martes y jueves publicamos un análisis como este. Reciba el resumen semanal en su correo.