Abres Salesforce y una función funciona con lentitud, no está disponible o devuelve un error. Al mismo tiempo, ves informes de un problema con AWS. Es tentador concluir que «Salesforce se ejecuta en AWS, así que AWS debe ser la causa». A veces, esta conclusión puede ser correcta, pero la dependencia real es más compleja. Salesforce utiliza AWS de forma extensiva, especialmente a través de Hyperforce , mientras que algunos entornos y servicios de Salesforce utilizan otra infraestructura. Por lo tanto, un incidente de AWS puede afectar a algunas cargas de trabajo de Salesforce sin que necesariamente afecte a todos los clientes o productos de Salesforce.
La cuestión práctica no es simplemente si Salesforce usa AWS. Sí, lo usa. La pregunta clave es qué parte de su servicio de Salesforce está alojada dónde, de qué región o servicio de AWS depende, y si el problema reside en Salesforce, AWS, su propia integración o la ruta de red entre ellos . Esta guía explica esa dependencia, desde las comprobaciones más sencillas hasta los detalles arquitectónicos más complejos, y luego muestra cómo verificar su propia situación.
Hyperforce es la arquitectura de infraestructura de nube pública de Salesforce para ofrecer aplicaciones de Salesforce en entornos de nube regionales. Salesforce describe Hyperforce como la infraestructura que respalda Customer 360 y utiliza proveedores de nube pública para ampliar la disponibilidad regional, la residencia de datos, los controles de seguridad y la escalabilidad.
Según Salesforce, a partir de septiembre de 2026, Hyperforce estará disponible en Amazon Web Services en varios países y también se está expandiendo a Google Cloud Platform. Esta distinción es importante: si bien es cierto que Salesforce utiliza AWS, no lo es que todas las organizaciones de Salesforce operen exclusivamente en AWS. Salesforce aún gestiona parte de su infraestructura propia, y algunos servicios individuales pueden ejecutarse en infraestructuras independientes de la organización principal.
La guía actual de Salesforce sobre la ubicación de la infraestructura está disponible en la Ayuda de Salesforce: ¿Dónde se encuentra mi instancia de Salesforce? Salesforce también explica su modelo Hyperforce más amplio en la información general y las preguntas frecuentes de Hyperforce de Salesforce .
La dependencia es sustancial pero compleja. AWS ha sido un importante proveedor estratégico de servicios en la nube para Salesforce durante años, y AWS describe a ambas compañías como una alianza estratégica global. Salesforce utiliza la infraestructura de AWS para las implementaciones de Hyperforce y también ha integrado sus productos con servicios de AWS como Amazon Connect y Amazon Bedrock.
Para un cliente, ayuda separar la relación en tres niveles:
| Capa | ¿Qué depende de AWS? | Qué significa operativamente |
|---|---|---|
| capa de alojamiento de Salesforce | Una organización o servicio de Salesforce puede ejecutarse en Hyperforce alojado en una región de AWS. | Un problema regional o de infraestructura subyacente de AWS puede afectar la disponibilidad de Salesforce para esa carga de trabajo alojada. |
| capa de productos y servicios de Salesforce | Algunos complementos o servicios de soporte de Salesforce pueden ejecutarse en AWS de forma independiente de la organización principal de Salesforce. | Una función puede fallar incluso cuando el sistema CRM principal funciona correctamente. |
| capa de integración del cliente | Su empresa puede conectar Salesforce a sus propias cargas de trabajo de AWS, API, Amazon Connect, canalizaciones de datos o redes privadas. | El problema puede estar en su cuenta de AWS o en la ruta de red, incluso cuando Salesforce esté funcionando con normalidad. |
Este modelo por capas es clave para la resolución de problemas. Una página de estado que indica "Salesforce está operativo" no demuestra que su integración alojada en AWS funcione correctamente. Del mismo modo, un evento general de AWS no demuestra que su instancia particular de Salesforce esté afectada.
Salesforce afirma que las instancias de Hyperforce utilizan un modelo activo/activo distribuido en tres zonas de disponibilidad dentro de la región correspondiente. Una zona de disponibilidad (AZ) es una ubicación aislada dentro de una región de AWS. En un diseño activo/activo, la capacidad de la aplicación opera en varias zonas en lugar de mantener una zona inactiva como reserva en frío. Salesforce indica que el tráfico se distribuye entre los servidores de aplicaciones activos en las tres zonas y que la replicación de la base de datos mantiene la coherencia entre ellas.
Esta arquitectura tiene como objetivo reducir la dependencia de una única zona de disponibilidad. Si una zona de disponibilidad presenta un problema localizado, el diseño puede ayudar a que el servicio continúe funcionando en las demás zonas. Sin embargo, una arquitectura multi-zona de disponibilidad no elimina todos los posibles modos de fallo. Un problema de servicio a nivel regional, un fallo en el plano de control, una interrupción de la red, un fallo de software, un fallo de dependencia o un incidente a nivel de aplicación aún pueden afectar la disponibilidad.
Por lo tanto, el modelo mental correcto es: Salesforce en AWS está diseñado para ser resiliente dentro de una región de AWS, pero aún tiene dependencias de infraestructura que pueden importar durante eventos más grandes de AWS .
Aquí es donde muchas investigaciones de incidentes fallan. Salesforce indica explícitamente que ciertos servicios pueden ejecutarse en una infraestructura independiente mientras se integran con la organización del cliente. Por ejemplo, la documentación de Salesforce para Sales Engagement, Einstein Activity Capture, Salesforce Inbox y Einstein Conversation Insights establece que estos servicios se alojan en una infraestructura de AWS separada de la infraestructura principal de Salesforce de la organización.
Eso significa que un usuario podría ver una situación como la siguiente:
Salesforce documenta esta separación en su guía de migración de Hyperforce para Sales Engagement, Einstein Activity Capture, Salesforce Inbox y Einstein Conversation Insights .
Comience con la información oficial de estado y confianza de Salesforce. Averigüe el estado de su instancia específica de Salesforce en lugar de confiar en informes genéricos que indican que "Salesforce no está disponible". Salesforce explica cómo identificar la instancia de una organización en Ver información de instancia para su organización de Salesforce .
En la configuración de Salesforce, utilice el cuadro de búsqueda rápida para localizar la información de la empresa y, a continuación, busque el campo Instancia . Salesforce indica que los prefijos de instancia de dos letras, como AP0, indican infraestructura propia gestionada por Salesforce, mientras que los prefijos de tres letras, como GBR10, indican infraestructura Hyperforce.
Una instancia de Hyperforce no implica necesariamente que esté disponible en AWS para siempre. Salesforce afirma que Hyperforce está disponible en AWS y que se está expandiendo a Google Cloud Platform. Su documentación recomienda a los clientes que necesiten determinar si una instancia específica de Hyperforce se encuentra en AWS o GCP que se pongan en contacto con el servicio de atención al cliente de Salesforce.
Esto cobra cada vez más importancia para la correlación de incidentes. No se debe asociar "Hyperforce" con "AWS" basándose únicamente en la palabra en sí.
Si ha confirmado que su organización o el servicio de Salesforce afectado se ejecuta en AWS, identifique la región. La documentación de ubicación actual de Salesforce enumera las regiones de Hyperforce y su proveedor de nube pública. Por ejemplo, Salesforce enumera las regiones de Hyperforce respaldadas por AWS en ubicaciones como Sídney, Bombay, Tokio, Singapur, Londres, Fráncfort, Canadá Central y varias regiones de EE. UU.
Luego, compare el incidente de Salesforce con la información oficial de AWS Health relevante para esa región y servicio. Evite considerar un problema en una región de AWS como evidencia de un problema en una región de Salesforce que no guarda relación.
Si Salesforce funciona correctamente, revise su ruta de integración. Las dependencias típicas del lado del cliente incluyen puertas de enlace de API, funciones Lambda, Amazon Connect, bases de datos, colas, puntos de conexión privados, VPN, DNS y controles de red corporativos. Un fallo en alguno de estos componentes puede parecer a los usuarios un «problema de Salesforce» porque el error se produce dentro de un flujo de trabajo de Salesforce.
Una prueba útil consiste en preguntarse: ¿Puede la misma operación de Salesforce tener éxito sin llamar a nuestro servicio de AWS? Si la respuesta es afirmativa, es posible que la organización principal funcione correctamente, aunque la ruta de integración esté fallando.
Algunas organizaciones utilizan AWS Direct Connect , una conexión de red privada a AWS, para satisfacer los requisitos de red de Hyperforce en AWS. Salesforce documenta un caso de uso para enrutar cierto tráfico de correo electrónico de Hyperforce a través de AWS Direct Connect para organizaciones con requisitos de conectividad privada, cumplimiento normativo o residencia de datos.
Esto crea otra capa de dependencia. Cuando se utiliza conectividad privada, un incidente puede ocurrir entre el usuario y Salesforce, en lugar de dentro de Salesforce. La documentación relevante de Salesforce es " Enrutar correo electrónico a través de AWS Direct Connect para Hyperforce" .
Salesforce describe Hyperforce como una solución diseñada para operar en múltiples proveedores de nube pública. Esto reduce la suposición arquitectónica de que un único proveedor de hiperescalador deba ser la base permanente para todas las cargas de trabajo de Salesforce. La documentación de Salesforce de 2026 indica que Hyperforce está disponible en AWS y que la compatibilidad con Google Cloud Platform se está implementando en regiones seleccionadas, según lo que Salesforce publique en su hoja de ruta.
Para los clientes, esto no significa que una organización de Salesforce existente cambie automáticamente de AWS a Google Cloud durante una interrupción del servicio de AWS. La compatibilidad con múltiples nubes se refiere principalmente a dónde puede Salesforce implementar y operar su plataforma. No debe asumir que la conmutación por error entre proveedores se realizará a menos que Salesforce lo documente explícitamente para el servicio que utiliza.
La relación va más allá del simple alojamiento de infraestructura. AWS y Salesforce describen una alianza estratégica más amplia centrada en datos, IA, capacidades de centro de contacto, integración y adquisiciones. La página oficial de la alianza de AWS destaca las integraciones que involucran productos de Salesforce y tecnologías de AWS, incluyendo IA generativa y capacidades de gestión de datos. Puede consultar esta relación en la página oficial de la alianza entre AWS y Salesforce .
Esto es importante durante las revisiones de arquitectura porque hay dos preguntas de dependencia diferentes:
Esas dos dependencias tienen propietarios, rutas de monitorización, procedimientos de recuperación y equipos de soporte diferentes.
Cuando los usuarios informen que Salesforce no está disponible o presenta fallas parciales, siga estos pasos en orden:
Sabrás que tu diagnóstico se está fortaleciendo cuando la evidencia coincida en todos los niveles. Si Salesforce Trust informa un incidente para tu instancia específica y la función afectada coincide con los síntomas, Salesforce está fuertemente implicado. Si Salesforce funciona correctamente, pero las pruebas de integración de AWS fallan en el mismo período, la dependencia de AWS del cliente es una pista más clara. Si solo un complemento de Salesforce se ve afectado, mientras que las funciones principales de CRM permanecen normales, investiga la infraestructura y el estado de ese servicio por separado.
No te conformes con "AWS sufrió una interrupción" o "Salesforce estuvo caído". La respuesta fiable se obtiene al identificar tu instancia, tu producto, tu región y tu ruta de integración .
Salesforce depende en gran medida de AWS, especialmente porque muchas implementaciones de Hyperforce y servicios de soporte se ejecutan en la infraestructura de AWS. Sin embargo, esta dependencia no es universal ni unidimensional. Salesforce también opera infraestructura propia, está expandiendo Hyperforce a través de múltiples proveedores de nube pública y puede alojar servicios individuales de forma independiente de la organización principal del cliente.
Para los equipos de operaciones, la mejor estrategia es tratar Salesforce y AWS como un gráfico de dependencias en lugar de una única pila. Identifique dónde se ejecuta la organización principal, asigne los servicios de Salesforce alojados por separado, documente cada integración de AWS administrada por el cliente y supervise cada capa de forma independiente. Esto le permitirá pasar mucho más rápido de un problema con Salesforce a identificar el componente específico que realmente necesita atención.
Una guía práctica para 2026 sobre inteligencia artificial, sensores para hogares inteligentes, monitorización remota, seguridad contra caídas, privacidad y cómo la tecnología puede facilitar el envejecimiento en el hogar sin sustituir la atención médica.
Descubre cómo las ciudades pueden transformar los datos sobre movilidad, uso del suelo, clima y comunidad en barrios más seguros, más ecológicos y más transitables a pie, sin anteponer la tecnología a las personas.
Compara los principales programas de ingeniería aeroespacial y de vehículos aéreos no tripulados (UAV) en las áreas de drones, autonomía, sistemas de control, operaciones con sistemas aéreos no tripulados (UAS) e investigación de posgrado, con actualizaciones verificadas hasta 2026.
A practical guide to AI-powered surgical robotics: current capabilities, levels of autonomy, precision benefits, limits, regulation, and evaluation criteria.
La inversión en CCUS está en aumento, pero ¿puede la captura de carbono revertir las emisiones globales? Descubra dónde funciona, qué limita su escala y qué evidencia es relevante.
Compare siete programas globales para cadenas de suministro digitales, logística, análisis, comercio global y operaciones, con orientación práctica para elegir el más adecuado.
Descubre cómo las interfaces cerebro-computadora decodifican las señales neuronales para restaurar la comunicación y el movimiento, qué han logrado los estudios recientes y qué limita aún el uso de las interfaces cerebro-computadora.
Descubre cómo los drones comerciales combinan sensores, IA en el borde, baterías, comunicaciones y software de control de vuelo, y dónde la autonomía aún depende de la misión y la normativa.
Compare siete opciones destacadas de fabricantes líderes en baterías y almacenamiento de energía, teniendo en cuenta los materiales, los sistemas, la investigación, la experiencia en la industria, la flexibilidad, el idioma y la relación costo-beneficio.
Aprenda cómo la masa de la carga útil, los límites de la batería, las condiciones meteorológicas, la eficiencia de la propulsión y la arquitectura de la aeronave influyen en la autonomía de los UAV industriales, y cómo mejorarla.
