WolfSellers — Adobe Experience Cloud Partner en México

Artículo

Hosting de Adobe Commerce: managed cloud, Commerce on Cloud y self-managed — cómo elegir

Hosting de Adobe Commerce: las tres opciones —Commerce on Cloud, self-managed en AWS y managed hosting con partner—, qué incluye un managed serio y cómo elegir.

Por WolfSellers··9 min de lectura
Hosting de Adobe Commerce: managed cloud, Commerce on Cloud y self-managed — cómo elegir
En esta página

La pregunta del hosting llega tarde casi siempre. En los discoveries que hacemos con marcas nuevas, el equipo decidió la plataforma, definió el catálogo y diseñó el checkout — pero la infraestructura quedó como un detalle de último momento, resuelto por defecto o por precio. Y es justo al revés: en Adobe Commerce (antes Magento), el hosting es parte de la arquitectura. Define el performance que ve el cliente, el alcance del cumplimiento PCI DSS (Payment Card Industry Data Security Standard), la capacidad de aguantar un Buen Fin sin caerse, y buena parte del costo total de propiedad de los próximos tres años.

En WolfSellers operamos tiendas Adobe Commerce sobre las tres rutas posibles de hosting, y la decisión correcta no es la misma para todos. Este artículo explica qué es el hosting de Adobe Commerce y por qué importa, cuáles son las tres opciones reales, qué debe incluir un managed hosting serio, cómo decidir según tu tamaño y equipo, y los errores que vemos repetirse en México y LATAM.

¿Qué es el hosting de Adobe Commerce y por qué importa?

El hosting de Adobe Commerce es el conjunto de infraestructura y servicios gestionados que mantiene tu tienda corriendo: los servidores de aplicación PHP, la base de datos, el motor de búsqueda (OpenSearch/Elasticsearch), la capa de caché (Varnish/Redis), la red de entrega de contenido o CDN (Content Delivery Network), y la operación que monitorea, escala, parcha y respalda todo eso.

A diferencia de un sitio de marketing estático, Adobe Commerce es una aplicación pesada y con estado: cada página de producto puede disparar decenas de queries, el checkout escribe en base de datos en tiempo real, y los indexers reconstruyen catálogo y precios de forma continua. Por eso el hosting no es un commodity intercambiable. Importa por cuatro razones concretas:

  1. Performance. Core Web Vitals — LCP, CLS, INP — dependen directamente de la latencia del servidor, la configuración de Varnish/Fastly y el edge caching. Un hosting mal dimensionado se traduce en PDPs lentas y carritos abandonados, sin importar qué tan bueno sea el frontend.
  2. Cumplimiento PCI DSS. Si procesas tarjeta, el entorno de hosting es parte del alcance de la auditoría. Hardening del sistema operativo, segmentación de red, gestión de parches y logs son requisitos, no opcionales.
  3. Escala. El tráfico de eCommerce en México no es plano: el Buen Fin, Hot Sale y la temporada navideña multiplican la carga. Según la Asociación Mexicana de Venta Online (AMVO), el Hot Sale concentra picos que superan con holgura el tráfico de un día normal. La infraestructura tiene que escalar para esos eventos sin sobre-provisionar el resto del año.
  4. Continuidad. Backups, recuperación ante desastres (DR) y un acuerdo de nivel de servicio (SLA) explícito son lo que separa una caída de minutos de una de días.

¿Cuáles son las opciones de hosting para Adobe Commerce?

Hay tres rutas principales. No son mejores o peores en abstracto — cada una resuelve un perfil distinto de empresa, equipo y compliance.

1. Adobe Commerce on Cloud (la PaaS oficial)

Adobe Commerce on Cloud es la plataforma como servicio (PaaS, Platform as a Service) oficial de Adobe: infraestructura gestionada sobre AWS (Amazon Web Services), con Fastly como CDN y capa de Web Application Firewall (WAF) incluida, New Relic para monitoreo de aplicación e infraestructura, y un pipeline de deploy basado en Git con ambientes de integración, staging y producción. Viene en dos tiers — Pro y Starter — y el modelo es de suscripción anual que empaqueta licencia e infraestructura.

La ventaja es que Adobe asume la responsabilidad de la plataforma base: el cliente no administra los servidores directamente. La contraparte es menos control de bajo nivel sobre el sistema operativo y la topología, y un modelo de costos que requiere dimensionar bien el tier desde el principio. Es la ruta que Adobe recomienda por defecto y la que mejor se integra con el resto de Adobe Experience Cloud.

2. Self-managed (on-premise o cloud propio en AWS)

Aquí la marca licencia Adobe Commerce (en su edición que permite hosting propio) y opera la infraestructura por su cuenta — típicamente en su propia cuenta de AWS, a veces en otro proveedor cloud, raramente on-premise hoy. El equipo de la empresa, o un partner, diseña la arquitectura: balanceadores, autoscaling, RDS o Aurora para base de datos, ElastiCache para Redis, OpenSearch gestionado, CloudFront o Fastly como CDN.

Da el máximo control y permite optimizar el costo de infraestructura a detalle (instancias reservadas, savings plans, arquitecturas a medida). El precio es la responsabilidad operativa completa: tú parchas, tú escalas, tú respondes a las 3am cuando el indexer bloquea el admin durante el Buen Fin. Solo tiene sentido con un equipo de DevOps maduro o un partner de operación dedicado.

3. Managed hosting a través de un partner

Una vía intermedia: la infraestructura vive en un cloud (AWS, casi siempre) pero la diseña y opera un partner especializado en Adobe Commerce, no la marca. El partner aporta la arquitectura de referencia, el monitoreo, el escalado, los parches de seguridad, el cumplimiento y el SLA — y el cliente conserva visibilidad y, según el modelo, co-propiedad de la cuenta cloud.

Combina el control del self-managed con la tranquilidad operativa de la PaaS. Es la opción que más recomendamos en WolfSellers para empresas medianas y grandes en México que no quieren montar un equipo de DevOps Adobe-específico interno, pero sí quieren transparencia de costos y arquitectura.

¿Qué incluye un managed hosting serio para Adobe Commerce?

"Managed hosting" se usa para cosas muy distintas. Un hosting genérico que solo te da un servidor con acceso SSH no es managed hosting para Adobe Commerce. Esto es lo que evaluamos — y entregamos — como parte de una operación seria:

Componente Qué debe incluir Por qué importa
Infraestructura Arquitectura multi-AZ en AWS, autoscaling de servidores de aplicación, base de datos gestionada (RDS/Aurora) Alta disponibilidad y elasticidad para picos como Buen Fin/Hot Sale
CDN + edge Fastly o CloudFront con Varnish bien configurado, WAF en el edge Core Web Vitals, protección DDoS y descarga de origen
Monitoreo New Relic (APM + infra), alertas proactivas, dashboards de negocio Detectar degradación antes de que la vea el cliente
Escalado Plan de capacidad para eventos, autoscaling probado con load testing Aguantar campañas sin sobre-provisionar todo el año
Parches de seguridad Aplicación de security patches de Adobe y del SO en ventanas controladas CVEs sin parchar son el vector #1 de compromiso en Magento
Cumplimiento PCI DSS Hardening, segmentación, gestión de logs, soporte a la auditoría Requisito si procesas tarjeta
Backups + DR Respaldos automatizados, retención definida, RPO/RTO acordados y probados La diferencia entre minutos y días de caída
SLA Disponibilidad comprometida por contrato, tiempos de respuesta y escalamiento Responsabilidad clara cuando algo falla

Si una propuesta de hosting no cubre explícitamente backups con objetivo de punto de recuperación (RPO) y tiempo de recuperación (RTO) probados, monitoreo de aplicación y un SLA por escrito, no es managed hosting de nivel enterprise — es alojamiento con otro nombre.

¿Cómo elegir entre las tres opciones?

La decisión se cruza con tres variables: tamaño y criticidad de la operación, madurez del equipo técnico interno, y requisitos de compliance. Esta tabla resume cuándo conviene cada ruta:

Criterio Commerce on Cloud Self-managed (AWS propio) Managed con partner
Control de infraestructura Medio Total Alto
Carga operativa para tu equipo Baja Alta Baja
DevOps interno requerido Mínimo Maduro y dedicado Mínimo
Flexibilidad de costo de infra Baja (tier fijo) Alta Alta
Integración Adobe Experience Cloud Nativa Manual Alta
Mejor para Quien quiere que Adobe opere la base Equipos cloud maduros que optimizan a detalle Mid-market/enterprise sin DevOps Adobe interno

Las preguntas que hacemos en un discovery para inclinar la decisión:

  1. ¿Tienes un equipo de DevOps con experiencia específica en Adobe Commerce? Si no, self-managed puro es un riesgo: el conocimiento operativo de Magento (indexers, cron, Varnish, deploy mode) no es trivial.
  2. ¿Qué tan crítico es el control de costos de infraestructura? Si la elasticidad fina y los savings plans importan mucho, self-managed o managed con partner ganan sobre el tier fijo de la PaaS.
  3. ¿Cuál es tu perfil de tráfico? Picos extremos y estacionales premian arquitecturas con autoscaling probado; tráfico estable tolera setups más simples.
  4. ¿Qué exige tu compliance? PCI DSS, LFPDPPP (Ley Federal de Protección de Datos Personales en México) e ISO 27001 son más fáciles de evidenciar con una operación gestionada y auditable.
  5. ¿Vas a usar más Adobe Experience Cloud? Si el roadmap incluye Adobe Experience Manager o Adobe Experience Platform, la integración nativa de Commerce on Cloud pesa.

No hay una respuesta universal. Una marca mid-market mexicana sin equipo cloud propio suele estar mejor con managed (PaaS o partner); una empresa con DevOps maduro que ya vive en AWS puede extraer más valor del self-managed.

Errores comunes en el hosting de Adobe Commerce

Patrones que vemos repetirse — y que cuestan caro — en proyectos Adobe Commerce y Magento en México y LATAM:

  • Elegir hosting por precio mensual, no por costo total. Un hosting barato sin monitoreo, sin SLA y sin escalado probado sale más caro la primera vez que la tienda se cae en pleno Buen Fin.
  • Subdimensionar para los picos. Configurar la infraestructura para el tráfico promedio y descubrir en el Hot Sale que no escala. El autoscaling tiene que estar probado con load testing antes del evento, no improvisado durante.
  • Confundir hosting genérico con managed para Adobe Commerce. Un VPS con SSH no administra indexers, deploy mode, Varnish ni los security patches de Adobe. Magento tiene necesidades operativas específicas.
  • No probar los backups. Tener backups que nunca se restauraron es no tener backups. RPO y RTO se acuerdan y se prueban.
  • Tratar PCI DSS como algo del checkout. El alcance del cumplimiento incluye la infraestructura: hardening, segmentación de red y gestión de logs son parte del hosting, no solo del gateway de pago.
  • Dejar de aplicar security patches. Las vulnerabilidades sin parchar son el vector de compromiso más común en tiendas Magento. La cadencia de parches es parte del servicio, no un extra.
  • No tener observabilidad. Sin APM (Application Performance Monitoring) ni alertas, la primera persona que detecta la degradación es el cliente que abandona el carrito.

La mayoría no son problemas técnicos difíciles — son decisiones tomadas sin entender que en Adobe Commerce la infraestructura es parte del producto.

Cómo te ayudamos

En WolfSellers somos Adobe Gold Partner con más de 10 años en LATAM, 40 specialists certificados en Adobe Commerce y 3 AWS Solutions Architect Associate en el equipo. Operamos tiendas Adobe Commerce sobre las tres rutas: Adobe Commerce Cloud (la PaaS oficial), hosting y cloud optimizado en AWS gestionado por nosotros, y arquitecturas de infraestructura cloud a medida con monitoreo, escalado, parches y cumplimiento PCI DSS. Si estás eligiendo entre Commerce on Cloud, self-managed o managed hosting — o si tu tienda actual sufre de performance o caídas — podemos hacer un discovery de infraestructura y proponerte la ruta correcta para tu tamaño y tu equipo. Hablemos.

Servicios relacionados

Si este tema es relevante para tu negocio, estos servicios de WolfSellers pueden ayudarte a implementarlo: