Comience por su carga de trabajo, no por un plan de alojamiento
Liste los recorridos que generan valor o riesgo: primera visita, búsqueda, inicio de sesión, detalle de producto, envío de formularios, pago, actualización en el editor o llamada API. Para cada uno, registre picos de solicitudes o usuarios concurrentes, tamaño de la carga, personalización, dependencias y regiones de los visitantes. Incluya trabajo programado y administrativo porque consumen los mismos recursos.
Convierta la lista en medidas de aceptación. Largest Contentful Paint, o LCP, mide la carga del contenido principal; Interaction to Next Paint, o INP, la capacidad de respuesta; y Cumulative Layout Shift, o CLS, los movimientos inesperados. Google describe objetivos buenos como LCP dentro de 2,5 segundos, INP por debajo de 200 milisegundos y CLS por debajo de 0,1. Añada objetivos de finalización de ruta, tiempo de respuesta del servidor y tasa de errores.
No permita que una página rápida y cacheada sustituya a una transacción autenticada o respaldada por base de datos.
Defina periodo pico, crecimiento esperado, picos por campañas y trabajo por lotes solapado.
Marque si el cuello de botella probable lo controla el proveedor, su equipo o un tercero.
Compare capacidad, límites y comportamiento de escalado
Solicite los límites que hay detrás de la oferta: cómputo y memoria, rendimiento de almacenamiento, conexiones de base de datos, límites de workers, cargos de red, controles de petición y restricciones por vecinos compartidos. “Ancho de banda ilimitado” no muestra si la aplicación puede realizar suficiente trabajo no cacheado en un pico. Pregunte qué métricas son visibles y durante cuánto tiempo están disponibles.
El escalado importa solo cuando se conocen su desencadenante, demora, techo y precio. Confirme si es automático, si las sesiones y los trabajos permanecen a salvo y qué ocurre al alcanzar el techo. Prefiera una prueba al pico esperado y más allá a una afirmación teórica de capacidad. El margen de maniobra (headroom) es una decisión de negocio, no un porcentaje universal.
Compare tiempo de respuesta p95 o p99, no solo una media.
Recolecte tiempos de base de datos, colas y API aguas arriba durante la prueba.
Estime costes de escalado, entrega, copias de seguridad y segunda región antes de comprometerse.
Ubique el origen deliberadamente y valide la entrega
Elija una región de origen según la localización de la audiencia, dependencias de la aplicación, necesidades de localización de datos y acceso operativo. Pruebe desde geografías y condiciones de red representativas. Una red de distribución de contenidos, o CDN, es una caché distribuida que puede servir activos elegibles más cerca de los visitantes y reducir trabajo en el origen; no sustituye un origen, base de datos o aplicación saludables.
Inspeccione cabeceras y comportamiento, no solo una configuración del panel. Los activos estáticos versionados pueden tener normalmente vidas útiles más largas porque una actualización tiene una URL nueva. Las respuestas dinámicas y personalizadas necesitan reglas explícitas. HTTP distingue cachés compartidas de privadas; los datos de cuenta no deben volverse reutilizables por otro cliente. Ensaye una purga de caché y una reversión.
Capture una primera visita y una visita de retorno porque los estados de caché difieren.
Verifique las cabeceras Cache-Control y las claves de caché para páginas, activos, cookies, parámetros y localización.
Documente cómo el personal autorizado desactiva una regla dañina sin exponer contenido sensible.
Trate la evidencia de recuperación como un requisito de rendimiento
Pregunte qué se respalda, dónde viven las copias, retención, autoridad de restauración y si las copias cubren bases de datos, cargas, código, configuración e infraestructura. Defina el recovery point objective, o RPO, como la pérdida de datos aceptable en tiempo, y el recovery time objective, o RTO, como el tiempo de restauración aceptable. Establezca ambos según las consecuencias para el negocio, no por un valor predeterminado del paquete.
Una copia de seguridad exitosa no es prueba de recuperación. CISA recomienda pruebas de recuperación programadas, y AWS dice que la recuperación ante desastres debe evaluarse y probarse. Restaure una copia reciente en aislamiento, verifique registros y medios importantes, use la secuencia documentada y registre el tiempo transcurrido. Una región alternativa puede reducir algunos riesgos pero añade coste y complejidad.
Recupere un archivo o registro sin sobrescribir los datos actuales.
Limite el acceso a restauraciones y mantenga credenciales y runbooks de recuperación disponibles para respondedores autorizados.
Un snapshot de base de datos puede no recrear ajustes, versiones de aplicación o reglas de entrega.
Evalúe el soporte y la responsabilidad compartida antes de necesitarlos
Compare alcance del soporte, horario, canales, escalado y la diferencia entre incidentes de plataforma y resolución de problemas de aplicación. Obtenga por escrito la responsabilidad de parches, bases de datos gestionadas, TLS, reglas de firewall, copias de seguridad y restauración. Una promesa de soporte es útil cuando nombra al responsable y la siguiente acción en un escenario realista.
Revise roles de acceso, autenticación multifactor, registros de auditoría, manejo de secretos y aislamiento de cuentas. Para tarjetas de pago o datos regulados sensibles, las características del alojamiento por sí solas no establecen cumplimiento. Use esta comparación como insumo técnico y obtenga revisión calificada de seguridad, legal o cumplimiento de la arquitectura de pagos y obligaciones aplicables.
Pregunte cómo el proveedor maneja una restauración fallida, base de datos saturada o una regla de caché dañina.
Compruebe quién puede cambiar producción, leer copias de seguridad, ver registros y crear credenciales.
Créditos de servicio y cobertura gestionada pueden tener condiciones materiales.
Realice pruebas comparativas realistas y seguras y mantenga la hoja de evaluación
Use la misma versión, intención de configuración y script de prueba para cada candidato. Ejecute una línea base, el pico esperado, un pico corto, un periodo sostenido y un ejercicio seguro de recuperación o despliegue. AWS recomienda entornos similares a producción, escenarios definidos, monitorización en toda la arquitectura, datos saneados o sintéticos y retesteos regulares. Obtenga aprobación del proveedor y siga su política de pruebas.
Combine pruebas de laboratorio controladas con datos de campo tras el lanzamiento. Las pruebas de laboratorio son repetibles para depuración; los datos de campo reflejan dispositivos reales, redes, geografía, estado de caché y comportamiento. Revise la hoja de evaluación después de lanzamientos importantes o cambios en dependencias. SIU (Status Is UP) puede convertir hallazgos en endurecimiento previo al lanzamiento, remediación asignada a propietarios y mejoras listas para reversión.
Mantenga consistentes ubicaciones, concurrencia, estado de caché y cargas.
Guarde tiempos de rutas, errores, métricas de recursos, versiones, costes y observaciones.
Seleccione la opción que cumpla necesidades documentadas a un coste operativo sostenible.