Compara el servicio necesario, no una factura cloud con un servidor vacío. Incluye personas, recuperación y salida antes de elegir hosting gestionado, repatriación o híbrido.
Autor
Anichur Rahaman
La propietaria ve subir la factura cloud; el ingeniero encuentra un servidor de alquiler mucho más barato. Las dos cifras pueden ser correctas y el ahorro propuesto, falso. Alguien debe parchear la base, recuperar registros, atender llamadas nocturnas y sobrevivir al siguiente fallo físico.
Esta comparación didáctica pregunta qué necesita mantener funcionando el negocio, quién lo operará y cuánto cuesta el cambio completo. Repatriar puede ser sacar solo algunas cargas de un gran proveedor público; no obliga a comprar un rack ni moverlo todo. Incluye nube regional, hosting gestionado e híbridos.
Empieza con disponibilidad, capacidad probada en pico/fallo, pérdida tolerable, recuperación, soporte, ubicación y responsabilidades de seguridad. Dos máquinas en el mismo dominio de fallo no equivalen automáticamente a un servicio multizona probado. Incluye reposición, reserva y escalado; no borres resiliencia para abaratar el alquiler.
El modelo compartido de AWS ilustra responsabilidades según servicio. Gestionado no elimina las obligaciones de datos/seguridad del cliente; autogestionado no exige operar un edificio. Asigna parches, credenciales, recuperación, backup, monitoreo y guardias en cada opción.
Demanda estable puede favorecer capacidad fija, pero ni estabilidad ni una factura sobre un umbral mágico garantizan ahorro. Picos, GPU, crecimiento y capacidad del proveedor afectan ambos modelos. Separar app y base entre proveedores puede añadir latencia, transferencia y otro fallo. Prueba el recorrido completo, no solo el nodo barato.
La tabla es hipotética, en una unidad monetaria; no son cotizaciones ni precios StoreConsole. Cada candidato debe superar antes la misma aceptación funcional, de recuperación y rendimiento. La tabla no acredita topología ni SLA. Cuenta soporte/trabajo una vez y usa la misma base de impuestos/descuentos. Solo se omiten licencias comunes de aplicación si son iguales; añade las diferencias.
| Asignación mensual | Servicios gestionados | Host autogestionado |
|---|---|---|
| Runtime app/workers | 400 | 250 |
| Capacidad/recuperación de base | 700 | 300 |
| Caché/colas | 150 | 100 |
| Almacenamiento, copia y red | 200 | 200 |
| Monitoreo/seguridad | 100 | 150 |
| Subtotal infraestructura | 1,550 | 1,000 |
| Operación: 20 h /40 h a 40 | 800 | 1,600 |
| Total mensual | 2,350 | 2,600 |
Infraestructura gestionada suma 1,550 frente a 1,000 autogestionada: ahorro aparente 550. A 40 por hora operativa, veinte horas añaden 800 al gestionado y cuarenta añaden 1,600 al propio. Totales 2,350 frente a 2,600: la infraestructura barata cuesta 250 más al mes incluyendo operaciones.
Con el resto fijo, equilibrio operativo propio: (2,350−1,000)÷40=33.75 horas/mes. No es estándar de plantilla ni recomendación de trabajar gratis. Presupuesta ausencias, incidentes y capacidades; el tiempo de un empleado existente tiene coste de oportunidad.
En una sensibilidad separada, 25 horas propias cuestan 1,000, total 2,000, ahorro 350 mensual. Una migración inicial 6,000 tardaría unos 17.1 meses en recuperarse con ese ahorro constante, antes de solapamiento, financiación, impuestos o riesgo. En el caso original de 40 horas no hay ahorro positivo: coste incremental primer año 12×250+6,000=9,000 antes de solapamiento. No mezcles hipótesis favorables entre escenarios.
Atribuye costes a cargas: capacidad ociosa, snapshots, logs, réplica, operaciones de almacenamiento, NAT, zonas/regiones e internet. Compara ajustar tamaño, limpiar ciclos de vida y compromisos adecuados antes de migrar. Un compromiso baja tarifa y puede mantener deuda de salida. Una CDN modifica tráfico al origen, no garantiza coste total menor.
Consulta términos actuales por servicio/región/cuenta. La referencia EC 2 de AWS distingue categorías y elegibilidad; un precio anunciado por GB no vale para todo. El alquiler también tiene límites, uso razonable y excesos. No hay ingreso universal gratuito, 20 TB siempre incluidos ni ahorro fijo de egress.
El programa de salida AWS tiene elegibilidad, aviso y procedimiento: no es entrega diaria gratis. Obtén términos antes de presupuestar la exención. En cambios sujetos al Data Act de la UE, los cargos de cambio, incluido egress pertinente a ese cambio, terminan el 12 de enero de 2027. Verifica ámbito/excepciones; no apliques la fecha a cualquier tráfico ni supongas elegibilidad de todo contrato por tener un cliente europeo.
Mapea residencia completa: primario, réplicas, copias, logs, soporte y subencargados. Ubicación sola no acredita seguridad, acceso legal ni cumplimiento. Confirma obligaciones/contrato con responsable. Contenedores ayudan a portabilidad, pero colas, identidad, secretos, red y formatos pueden exigir mucho trabajo. No prometas migrar “en una tarde”.
Inventaría dependencias y elige transferencia compatible con versiones. Construye destino, restaura copia y comprueba RPO/RTO acordados; PostgreSQL sobre archivo continuo es una referencia. Revisa roles, extensiones, codificación, jobs, archivos y secretos además de filas. Conteos/checksums no prueban por sí solos un sistema de negocio operativo.
Las restricciones de replicación lógica PostgreSQL incluyen esquema/DDL y secuencias: copiar filas no prepara automáticamente al suscriptor para escribir. Verifica versiones, identidad de réplica y objetos no tabulares. Standby físico y suscriptor lógico difieren; replicación inversa no es rollback automático.
Antes del cambio, bloquea todos los escritores antiguos: web, workers, programadores, imports y callbacks mediante plan ensayado. Alcanza origen, concilia aceptados, cambia autoridad de escritura, valida y reanuda deliberadamente. Coordina colas, idempotencia y efectos de pago/envío: dos copias no cumplen independientemente la misma obligación.
Reducir TTL DNS influye en refresco, pero no cierra conexiones ni mueve instantáneamente todos los clientes. El cliente atrasado no debe seguir escribiendo en la base antigua. Define vuelta antes/después de la primera escritura nueva; después, volver a copia anterior puede perder pedidos. Necesitas reconciliación/reversión probada, o recuperación hacia adelante.
El piloto debe aportar aceptación y soporte medido. Mantén solapamiento según recuperación/contrato, no 30 días o 13 semanas universales. Conserva copias protegidas y registros exigidos. Retira recursos solo después de comprobar dependencias y fechas de parada, incluidos compromisos de facturación.
| Requisito | Evidencia que conservar |
|---|---|
| Servicio comparable | Pico/fallo, RPO/RTO y control de acceso |
| Coste completo | Personas, soporte, solapamiento, compromisos y salida |
| Preparación del cambio | Restauración; esquema/estado compatible; un escritor |
| Tras el cambio | Pedidos/jobs/pagos conciliados; soporte medido |
Revisa coste por unidad útil, horas, parches críticos pendientes, incidentes, ensayos de recuperación y latencia en regiones de clientes. Edad del parche es cuánto lleva pendiente una corrección necesaria, no cuánto pasó desde instalar la última. Si soporte, exactitud o recuperación fallan, cambia el plan aunque el alquiler sea barato.
La propietaria necesita una factura y un modelo operativo explicables. Puede ser quedarse, mover una carga, contratar soporte gestionado o repatriar más. La elección correcta paga por el servicio necesario, incluidas las personas que lo mantienen funcionando.
Revisado el 6 de noviembre de 2026. Anichur Rahaman, creador de StoreConsole. Presupuesto y recuperación son ejemplos, no cotizaciones, ahorros observados ni previsiones.
Sobre el autor
Anichur Rahaman
Seguir Leyendo
