Escalado en la nube para plataformas: cuellos de botella y costes

El escalado en la nube funciona con un orden fijo: medir el cuello de botella, optimizar la base de datos y sus consultas, introducir caché y procesamiento en segundo plano y solo después subir y bajar instancias automáticamente. Servidores más grandes o adicionales solo ayudan si la capacidad de cálculo es de verdad el cuello de botella; en las plataformas web suele estar mucho más a menudo en la base de datos, en consultas lentas o en tareas que se ejecutan de forma síncrona aunque podrían hacerse en segundo plano.

Para las pymes, escalar rara vez significa “lo más grande posible”, sino “fiable, asequible y manejable por el propio equipo”. Este artículo muestra el orden correcto de las medidas, la observabilidad necesaria, las principales palancas de costes y qué tener en cuenta en cuanto a resiliencia, seguridad y elección del proveedor (a octubre de 2026).

Escalar en el orden correcto

Ante problemas de carga, lo más tentador es recurrir a una instancia más grande. Pero es la medida más cara y a menudo la menos eficaz. Es mejor accionar primero las palancas baratas y eficaces. El resumen relaciona los síntomas típicos con sus causas y con la primera medida adecuada.

Síntoma	Causa habitual	Primera medida	Esfuerzo
Las páginas se ralentizan con carga y los servidores web apenas trabajan	consultas lentas, índices ausentes, consultas N+1	analizar consultas, crear índices, agrupar consultas	bajo
Los mismos datos se recalculan constantemente	falta de caché	caché para consultas frecuentes, caché HTTP, CDN para contenido estático	bajo a medio
Informes, importaciones o envíos de correo frenan las peticiones de los usuarios	el trabajo se ejecuta de forma síncrona dentro de la petición	cola con procesos worker en segundo plano	medio
Las lecturas sobrecargan la base de datos	todas las consultas se ejecutan en la instancia principal	réplicas de lectura, caché de resultados de lectura	medio
CPU de los servidores de aplicación constantemente alta	demanda real de cálculo	instancias sin estado tras un balanceador de carga, autoescalado	medio
La carga de escritura de la base de datos llega al límite	base de datos principal agotada	revisar el modelo de datos, instancia mayor, particionado; sharding solo como último paso	alto

Cuanto más abajo en la tabla, mayor es la iniciativa. Las medidas de arriba suelen poder aplicarse con un esfuerzo moderado y a menudo logran el mayor efecto. Las de abajo son proyectos en sí mismos que solo conviene abordar cuando la medición los justifica.

¿Escalar en vertical o en horizontal?

• El escalado vertical consiste en dar más CPU y memoria a una instancia. Es sencillo y no requiere reformas, pero tiene límites y mantiene un único punto de fallo.
• El escalado horizontal consiste en varias instancias idénticas tras un balanceador de carga. Es más robusto y más fácil de ajustar, pero exige una aplicación sin estado.

Sin estado significa: las sesiones residen en un almacén externo como Redis o en la base de datos, los archivos subidos en un almacenamiento de objetos y la configuración en variables de entorno. Si una instancia solo funciona con estado local, no se puede añadir ni quitar a voluntad, y el autoescalado se queda en teoría.

El cuello de botella tras el servidor web: la base de datos

Cada instancia adicional de la aplicación abre más conexiones con la base de datos. Si solo escala la aplicación, la carga de la base de datos crece con ella y el cuello de botella se traslada allí. Por eso, el pool de conexiones, las réplicas de lectura y una revisión de las consultas más costosas van antes de cada nivel de escalado. Las tareas pesadas, como informes, procesamiento de imágenes o envíos masivos de correo, pertenecen a colas, para que la aplicación siga respondiendo con rapidez aunque en segundo plano ocurra mucho.

¿Qué modelo de operación encaja con su plataforma?

El escalado también depende de cómo opere la plataforma. Más automatización suele significar más comodidad bajo carga, pero también más conocimientos de operación y costes base más altos.

• Plataforma de aplicaciones gestionada (PaaS): usted aporta código o contenedores y el proveedor se encarga de servidores, actualizaciones y autoescalado. Para muchas aplicaciones web es la opción más rentable, con menos control sobre los detalles.
• Servidores virtuales (IaaS): control total y buena previsibilidad de costes, pero la aplicación de parches, el refuerzo de seguridad y el escalado corren de su cuenta; solo tiene sentido con infraestructura como código.
• Kubernetes: potente con muchos servicios y varios equipos, pero exigente en operación. Para un solo producto suele ser más de lo necesario.
• Serverless: pago por uso y sin operar servidores. Encaja con cargas variables y procesamiento de eventos; con carga alta constante puede salir más caro y hay que tener en cuenta los límites de ejecución y del proveedor.

Observabi­lidad: ver lo que ocurre

Sin mediciones, toda optimización es a ciegas. Tres fuentes de datos deben ir juntas, y OpenTelemetry ofrece un estándar neutral respecto a los fabricantes para recogerlas desde la aplicación:

• Registros (logs): ¿qué ha pasado? Mensajes de error, peticiones, eventos.
• Métricas: ¿cómo se comporta el sistema a lo largo del tiempo? Tiempos de respuesta, utilización, tasas de error.
• Trazas (traces): ¿dónde pasa su tiempo una petición concreta: en el código, en la base de datos o en un servicio externo?

Alertas ligadas a la experiencia del usuario

Muchos equipos alertan por umbrales técnicos como una CPU muy ocupada, y les despiertan de noche aunque ningún usuario note nada. Más reveladores son los objetivos de nivel de servicio (SLO). Un ejemplo: “La búsqueda de productos responde en menos de un segundo en el 99 % de las peticiones”. Si no se cumple, es un problema real, con independencia de lo ocupado que esté un servidor concreto. Vincule además las alertas con el impacto en el negocio: ¿afecta la incidencia al pago, al inicio de sesión o solo a un informe interno?

Pruebas de carga antes del momento crítico

No debería descubrir el mismo día si una plataforma aguanta una campaña, el inicio de una temporada o una aparición en los medios. Con herramientas como k6, Locust o JMeter se simulan muchos usuarios simultáneos, idealmente en un entorno similar a producción y con un volumen de datos realista. La prueba muestra dónde cede primero el sistema y ofrece una afirmación sólida: hasta esta carga, el tiempo de respuesta se mantiene dentro del objetivo. Con ese conocimiento se puede mejorar con calma en lugar de bajo presión.

Controlar los costes de la nube

La nube facilita escalar y, con ello, también gastar. Sin un control periódico, los costes suelen crecer más rápido que el uso. Bajo el nombre de FinOps se ha consolidado una práctica para ello: hacer visibles los costes, nombrar responsables y optimizar con regularidad. Las palancas principales:

• Ajuste de tamaño (rightsizing): adaptar instancias y bases de datos a la demanda real en lugar de pagar siempre por la carga máxima.
• Autoescalado con límites: un mínimo para la disponibilidad y un máximo contra disparos de costes por errores de configuración o ataques.
• Reservas para la carga base: para los recursos necesarios de forma permanente, las reservas o los savings plans salen más baratos que el pago bajo demanda; los trabajos interrumpibles se ejecutan en capacidad spot más económica.
• Limpieza: apagar los entornos de prueba fuera del horario laboral y eliminar instantáneas antiguas, volúmenes sin uso y balanceadores de carga.
• Asignar costes: etiquetar los recursos por proyecto y entorno y dotar los presupuestos de alertas.
• Limitar el volumen de registros: fijar plazos de conservación y nivel de detalle; en muchas plataformas los registros son una partida de coste subestimada.

Algunos costes proceden de decisiones de arquitectura: transferencia de datos entre regiones y hacia internet, muchos servicios pequeños con su propia carga base o bases de datos dimensionadas de forma permanente para picos poco frecuentes. Si hacen falta de verdad tantos servicios pequeños se aclara en el artículo Microservicios o monolito.

Seguridad y resiliencia

Con la plataforma crece la responsabilidad. En la nube rige el modelo de responsabilidad compartida: el proveedor protege la infraestructura, mientras que usted sigue siendo responsable de la configuración, los accesos, los datos y su aplicación. Los servicios gestionados le quitan trabajo, pero no la responsabilidad.

• Conceder accesos según el principio de mínimos privilegios, crear roles separados para personas y servicios y exigir autenticación multifactor a todos los administradores
• Guardar secretos como contraseñas y claves de API en un almacén de secretos, no en el código fuente
• Planificar de forma fija las actualizaciones de sistemas operativos, entornos de ejecución y dependencias
• Guardar las copias de seguridad separadas del sistema productivo, por ejemplo en otra cuenta u otra región, y practicar la restauración con regularidad

Fije dos valores objetivo para cada aplicación: el tiempo de recuperación (RTO) indica cuánto puede durar como máximo una caída y el punto de recuperación (RPO), cuántos datos pueden perderse como máximo. De ahí se deduce lo elaborada que debe ser la recuperación ante desastres. También la disponibilidad es una cuestión de costes:

Objetivo de disponibilidad	Caída al año (cálculo)	Caída al mes (cálculo)
99 %	aprox. 3,65 días	aprox. 7,3 horas
99,9 %	aprox. 8,8 horas	aprox. 43,8 minutos
99,95 %	aprox. 4,4 horas	aprox. 21,9 minutos
99,99 %	aprox. 53 minutos	aprox. 4,4 minutos

Cada nueve adicional exige redundancia en varias zonas de disponibilidad o regiones, conmutación automática y procedimientos ensayados, y cuesta en consecuencia. Por eso, pregúntese para cada sistema cuánto cuesta realmente una hora de caída y elija el objetivo en función de ello.

Elección del proveedor, protección de datos y dependencia

Antes de migrar, compruebe en qué región se almacenan los datos, si existe un contrato de encargo de tratamiento y con qué base jurídica se transfieren datos a proveedores fuera de la UE. El Reglamento de Datos de la UE (Data Act) se aplica desde el 12 de septiembre de 2025 y refuerza el derecho a cambiar de proveedor: los proveedores de nube deben hacer posible el cambio y los cargos por el cambio en sí desaparecen a partir del 12 de enero de 2027. Los costes corrientes de transferencia de datos en el funcionamiento normal no se ven afectados. Técnicamente, la dependencia del proveedor se limita con contenedores, infraestructura como código y estándares abiertos; los servicios propietarios especializados conviene usarlos de forma deliberada. Este artículo no sustituye el asesoramiento jurídico.

Ejemplo práctico: un portal B2B antes de la temporada

Supongamos que un mayorista opera un portal B2B y espera muchos más pedidos simultáneos por una acción de catálogo. La prueba de carga muestra que, a partir de cierta carga, los tiempos de respuesta aumentan aunque los servidores web apenas trabajan. Las trazas revelan que un cálculo de precios pasa la mayor parte del tiempo en la base de datos. Un índice adicional y una caché para las listas de precios eliminan el cuello de botella, y la exportación de listas de pedidos grandes pasa a una cola. Solo entonces se activa el autoescalado con límites superior e inferior, complementado con un presupuesto con alerta. La segunda prueba de carga confirma que se cumple el objetivo de tiempo de respuesta, sin pagar servidores permanentemente más grandes.

Lista de comprobación: ¿está su plataforma preparada para crecer?

• Los cuellos de botella están medidos, no supuestos
• Las consultas más frecuentes están revisadas y los índices y la caché están bien aplicados
• La aplicación no tiene estado, o hay un plan para lograrlo
• Las tareas pesadas se ejecutan en segundo plano mediante colas
• Registros, métricas y trazas se reúnen en un único lugar
• Las alertas se basan en objetivos relevantes para el usuario (SLO)
• Se hicieron pruebas de carga antes de eventos importantes
• Los costes se revisan cada mes, los recursos están asignados a proyectos y los presupuestos activan alertas
• Los derechos de acceso siguen el principio de mínimos privilegios y los secretos están en un almacén de secretos
• RTO y RPO están definidos y la restauración se ha probado con éxito, no solo la creación de la copia
• Los despliegues son automáticos y trazables, como se describe en el artículo DevOps y GitOps

Cómo le ayuda Nano Concepts

Nano Concepts le acompaña en arquitectura, bases de datos y nube y en DevOps y CI/CD, desde el análisis de los cuellos de botella existentes hasta la operación continua. Si se plantea una migración, encontrará el procedimiento en migración a la nube. En la primera consulta gratuita aclaramos en qué punto está hoy su plataforma y qué pasos tienen sentido a continuación.