- La interconectividad privada entre grandes nubes (AWS, OCI, Google Cloud, Azure) se consolida como capa estructural del multicloud.
- La soberanía del dato y el cumplimiento normativo exigen combinar conectividad estandarizada con buen gobierno, auditoría y gestión del riesgo.
- La IA generativa y las arquitecturas split‑stack dependen de un flujo de datos seguro y eficiente entre nubes para ser rentables.
- Servicios gestionados como Cloud NGFW para AWS y perfiles centrados en fundamentos cloud impulsan un modelo real de “cloud sin muros”.
La expresión “cloud sin muros” ha pasado de ser un eslogan simpático a describir una realidad muy concreta: las grandes empresas ya no quieren ni pueden vivir encerradas en una sola nube. Sus datos, sus aplicaciones y sus cargas de trabajo se mueven entre varios proveedores, y eso obliga a repensar por completo cómo diseñamos redes, seguridad y gobierno del dato.
En este nuevo escenario, la clave ya no es tanto elegir la “mejor” nube, sino construir una interconectividad sólida, predecible y segura entre plataformas que históricamente competían entre sí. Desde alianzas estratégicas como la de Oracle y AWS, hasta servicios avanzados de firewall gestionado en AWS o el debate sobre certificaciones cloud y perfiles profesionales, todo apunta en la misma dirección: derribar muros y reducir fricciones entre entornos cloud muy diversos. Esto obliga a replantear aspectos como redes, seguridad y gobierno del dato de forma coherente.
Qué significa realmente un “cloud sin muros”
Cuando se habla de “cloud sin muros” no se trata de una nube única y universal, sino de una arquitectura multicloud interconectada donde varias plataformas (AWS, Google Cloud, Azure, Oracle Cloud Infrastructure, etc.) se comunican entre sí de forma privada, gestionada y estable. El objetivo no es fusionarlo todo, sino disminuir la complejidad y la fricción que históricamente ha existido al unir nubes diferentes.
En la práctica, esto implica que en lugar de conectar entornos mediante configuraciones manuales complejas, hardware dedicado fragmentado y una ristra de terceros, las empresas empiezan a apoyarse en servicios de interconexión privados y nativos que proporcionan los propios hyperscalers. Esto permite que el tráfico entre nubes viaje por caminos más previsibles, con menos exposición a Internet pública y una latencia mucho más estable.
Hasta hace poco, la integración entre grandes nubes se resolvía a base de “proyectos de ingeniería de red” ad hoc: múltiples proveedores de red, túneles VPN encadenados, routers físicos, reglas de firewall manuales y un sinfín de scripts. Ese enfoque sufría dos problemas claros: una complejidad operativa altísima y el famoso fenómeno de la data gravity, es decir, la tendencia de los datos a quedarse donde ya están porque moverlos sale caro, es lento o arriesgado.
El avance hacia un cloud sin muros no elimina de golpe esa data gravity, pero sí ayuda a que el movimiento controlado de datos entre nubes sea más asumible: menos latencia variable, mejores garantías de disponibilidad, más automatización y, sobre todo, menos dependencia de configuraciones artesanales difíciles de mantener en el tiempo.
AWS Interconnect y la nueva capa estructural del multicloud
La disponibilidad general de AWS Interconnect es uno de los hitos que mejor ilustran esta tendencia. Amazon Web Services presenta este servicio como una ruta gestionada para conectar su nube con otros proveedores: de entrada con Google Cloud y, en la hoja de ruta, con Azure. Lejos de ser un simple “enlace”, se está planteando como una pieza estructural de la arquitectura multicloud moderna.
Este tipo de interconexión se apoya en conectividad privada y dedicada entre las nubes, con la intención de ofrecer latencias más predecibles, mayor seguridad en tránsito y menos dependencia de la Internet pública. En lugar de montar un puzle de enlaces, túneles y appliances, las empresas tienen una opción más estandarizada y soportada directamente por los grandes proveedores.
El movimiento de AWS no se entiende en solitario: Oracle lleva tiempo construyendo su propia visión de multicloud, y ha situado su integración con Oracle Cloud Infrastructure (OCI) y AWS como una extensión natural de esa estrategia. La interconexión entre Oracle y Amazon no es una rareza puntual, sino un síntoma de algo más profundo: incluso rivales históricos han asumido que los clientes ya operan en modo multicloud y que hay negocio en facilitarles ese camino.
Conviene subrayar que esta conectividad no supone el “fin total de los silos”, pero sí un paso muy relevante para reducir fricciones entre plataformas. La promesa no es una nube única, sino una red de nubes mejor conectadas, con menos sorpresas, menos latencia impredecible y un modelo de operación más cercano a un servicio estándar y no a un proyecto de ingeniería artesanal.
Desde el punto de vista de costes, el impacto sobre el TCO es matizable: la conectividad dedicada puede simplificar mucho la operación frente a redes híbridas caóticas, pero el ahorro real dependerá del volumen de tráfico, el diseño de la arquitectura y las condiciones comerciales negociadas con cada proveedor. Por eso es peligroso lanzar cifras genéricas de ahorro sin aportar referencias públicas y verificables.
OCI + AWS: interconexión como estándar del cloud sin muros
La conexión planificada entre Oracle Cloud Infrastructure (OCI) y AWS se enmarca plenamente en esta lógica de cloud sin muros. No es una excepción caprichosa, sino un ejemplo muy visible de hasta qué punto la conectividad privada entre nubes grandes está empezando a estandarizarse como una capa más de la infraestructura empresarial.
Gracias a este tipo de acuerdos, las empresas pueden diseñar despliegues multicloud más limpios, donde ciertas cargas viven en Oracle (por ejemplo, bases de datos críticas) y otras en AWS (aplicaciones, microservicios, modelos de IA, etc.) sin que el tráfico entre ambas se convierta en un embudo lleno de latencia variable y problemas de seguridad.
Eso sí, esta interconexión no implica por arte de magia la desaparición universal de los costes de salida de datos ni de las restricciones de cada proveedor. Siguen existiendo políticas comerciales y técnicas propias de cada nube, y las empresas deben hacer números finos a la hora de decidir qué datos se mueven, con qué frecuencia y bajo qué condiciones.
Lo más interesante es el cambio de enfoque: la red deja de verse solo como un dolor de cabeza técnico (VPNs, tablas de rutas, ACLs) para convertirse en una pieza estratégica de diseño de infraestructura. La forma en que se interconectan las nubes condiciona directamente la velocidad de despliegue, el nivel de resiliencia, la postura de seguridad y, en última instancia, el retorno de la inversión.
Este enfoque encaja muy bien con modelos de gobierno de TI maduros, donde la infraestructura no se improvisa, sino que se planifica con visión de negocio. En un cloud sin muros, decidir cómo se enlazan OCI y AWS es casi tan importante como decidir qué servicio PaaS se utiliza en cada lado.
Soberanía del dato y cumplimiento: DORA, NIS2 y más allá
La cuestión de la soberanía del dato y el cumplimiento normativo se ha vuelto crítica, especialmente en Europa. Normativas como DORA (en el sector financiero) o NIS2 (seguridad de redes y sistemas de información) obligan a las organizaciones a tomarse muy en serio dónde residen sus datos, cómo se mueven y qué trazabilidad tienen.
La interconexión privada estandarizada entre nubes puede resultar de gran ayuda. Al reforzar la trazabilidad del dato en tránsito y reducir la exposición a redes públicas, se gana visibilidad y control, algo muy valorado por los reguladores. Además, estos enlaces suelen incorporar cifrado a nivel físico y mecanismos reforzados de resiliencia, que aportan un plus de confianza en sectores regulados.
Sin embargo, conviene no engañarse: por muy robusta que sea la conectividad, no garantiza por sí sola el cumplimiento de DORA, NIS2 ni de otras normas. El cumplimiento sigue dependiendo de controles organizativos y de gobierno: auditoría, gestión del riesgo, políticas de acceso, acuerdos contractuales, planes de continuidad de negocio, etc. La infraestructura es una pieza más del puzle, pero no lo resuelve todo.
Marcos de gestión como ITIL 4 pueden aportar orden al diseño y operación de estos entornos multicloud. ITIL ayuda a encajar la infraestructura de red, los procesos de cambio, la gestión de incidentes y la continuidad del servicio dentro de un marco coherente. Eso sí, ITIL no sustituye a los requisitos regulatorios; simplemente ofrece una forma estructurada de operar dentro de ellos.
Otro aspecto clave es la expansión física de los hyperscalers. El hecho de que Oracle, por ejemplo, despliegue una tercera región cloud en España tiene implicaciones directas para la residencia del dato, la latencia y la soberanía. Tener más regiones locales permite a las organizaciones cumplir exigencias de ubicación geográfica de los datos, siempre que esa ventaja se acompañe de una configuración y una gobernanza bien pensadas.
Cloud sin muros e IA generativa: arquitecturas split‑stack
La explosión de la IA generativa ha llevado a muchas empresas a adoptar arquitecturas llamadas split‑stack, donde cada nube se usa para lo que mejor se le da. Es muy habitual encontrar bases de datos empresariales y sistemas core en Oracle, mientras que el entrenamiento o la inferencia de modelos de IA se ejecutan en AWS, o al revés.
En este contexto, una conectividad privada bien diseñada no busca eliminar la latencia por completo (algo irreal), sino reducir su variabilidad y simplificar la integración. Al tener enlaces más predecibles entre nubes, se hace mucho más viable mover conjuntos de datos, replicar información o sincronizar resultados de modelos sin que cada transferencia se convierta en una aventura.
El gran desafío de la IA ya no es solo disponer de GPUs o TPUs suficientes. El cuello de botella está, cada vez más, en el flujo seguro y eficiente de datos entre entornos heterogéneos: desde data lakes en una nube hasta pipelines de entrenamiento en otra, pasando por sistemas transaccionales on‑prem o en un tercer proveedor.
La interconexión privada influye de forma directa en el retorno de la inversión en IA: una arquitectura de datos bien pensada, con rutas de red optimizadas y políticas claras de movimiento de la información, puede acortar drásticamente los tiempos de entrenamiento, reducir riesgos de fuga de datos y mejorar la resiliencia de los servicios basados en modelos.
Además, la alianza entre Oracle y AWS no solo abre la puerta a nuevos despliegues de IA, sino también a escenarios avanzados de resiliencia y recuperación entre nubes. Copias de seguridad en un proveedor, planes de disaster recovery en otro, o incluso estrategias de conmutación por error entre plataformas, son cada vez más realistas gracias a estas conexiones privadas más maduras.
Seguridad en un cloud sin muros: el caso de Palo Alto Networks Cloud NGFW para AWS
El concepto de cloud sin muros también tiene un impacto directo en cómo se entiende la seguridad de red en la nube. Un ejemplo muy claro es el lanzamiento de Palo Alto Networks Cloud NGFW, un servicio de firewall de nueva generación, nativo de AWS y totalmente gestionado, diseñado precisamente para simplificar la protección de despliegues cloud en Amazon.
Este servicio busca eliminar muchas de las complicaciones tradicionales asociadas a securizar arquitecturas en AWS. En lugar de que el cliente se encargue de desplegar appliances virtuales, mantenerlos, actualizarlos y escalarlos, Palo Alto Networks asume la gestión integral de la infraestructura del firewall. La empresa usuaria se centra en sus aplicaciones y políticas, y deja la parte pesada de infraestructura a un proveedor experto.
Cloud NGFW incorpora capacidades avanzadas como el filtrado de URL y el uso de deep learning para detectar y bloquear amenazas web de tipo zero‑day en tiempo real. Esto permite frenar ataques desconocidos mientras se sigue permitiendo el acceso a servicios legítimos basados en la web. Además, incluye un sistema de prevención de amenazas para detener exploits de vulnerabilidades conocidas, malware y comunicaciones de comando y control.
Otro de sus pilares es App‑ID, una tecnología que clasifica el tráfico en capa 7 para poder aplicar políticas basadas en el tipo real de aplicación, y no solo en puertos o direcciones IP. De este modo, resulta más sencillo reducir la superficie de ataque y controlar de forma granular qué aplicaciones pueden comunicarse y bajo qué condiciones.
A nivel operativo, uno de los grandes atractivos de Cloud NGFW para AWS es su facilidad de uso. El servicio se puede adquirir desde AWS Marketplace y configurarse de manera bastante rápida, integrándose con los servicios de Amazon en cuestión de minutos y unos pocos clics. Como es un servicio completamente gestionado, las organizaciones no tienen que preocuparse de desplegar, actualizar ni operar infraestructura de firewall propia.
El servicio también aprovecha el AWS Gateway Load Balancer para lograr alta disponibilidad y escalado elástico bajo demanda. Esto resulta especialmente útil en entornos donde los picos de tráfico son impredecibles. El firewall se integra con AWS Firewall Manager, facilitando la gestión centralizada de políticas de seguridad en múltiples cuentas de AWS y diferentes VPC.
Por último, su compatibilidad con plantillas de API, CloudFormation y Terraform permite automatizar flujos de trabajo de seguridad end‑to‑end, encajando con prácticas de infraestructura como código. Esto es clave en un escenario cloud sin muros, donde las políticas de seguridad deben acompañar a las cargas de trabajo a medida que se desplazan o se replican entre nubes.
Certificaciones cloud, perfiles profesionales y el valor de los fundamentos
Mientras la tecnología avanza hacia un cloud sin muros, el mercado laboral vive su propia transformación. Durante años se ha vendido la idea de que un “experto en AWS” y un “experto en GCP” hablan idiomas radicalmente distintos, como si cada nube fuera un universo sin puntos en común. Las certificaciones han reforzado esa percepción, segmentando perfiles de forma muy rígida.
La realidad es bastante distinta. Los nombres de los servicios cambian, las consolas tienen otro aspecto, los modelos de facturación se organizan de forma diferente… pero el modo de pensar sobre el procesamiento de datos es, en esencia, el mismo. Las bases conceptuales que hay detrás de un data lake, un clúster de cómputo distribuido o un orquestador de pipelines no dependen del logo de la nube.
Cuando alguien interioriza bien conceptos como el particionamiento de datos, los motores distribuidos, los patrones de orquestación o el diseño de pipelines robustos, el salto entre nubes deja de ser tan dramático. Azure deja de parecer un monstruo nuevo y se convierte en la misma película, pero con otra interfaz y otros nombres para los servicios.
Por eso muchos profesionales están empezando a cuestionar si tiene sentido obsesionarse con ser ultraespecialista en una sola nube, en lugar de consolidar fundamentos sólidos de arquitectura y datos que permitan moverse con soltura en entornos multicloud. En un mundo de cloud sin muros, el valor diferencial está cada vez más en entender la lógica profunda de los sistemas, no solo en conocer de memoria dónde está cada botón en una consola concreta.
Desde la perspectiva de las empresas, esto plantea una pregunta muy relevante: ¿es más valioso un perfil que domina a la perfección un proveedor concreto, o aquel que entiende a fondo los principios comunes de cualquier arquitectura cloud y puede adaptarse con rapidez a varios entornos? En un escenario multicloud cada vez más extendido, el segundo tipo de perfil gana enteros, aunque siga habiendo espacio para especialistas profundos en un proveedor cuando la escala lo justifica.
En definitiva, el auténtico profesional del cloud sin muros es quien sabe combinar conocimiento transversal de fundamentos (datos, redes, seguridad, automatización) con una experiencia práctica suficiente en varias nubes como para no bloquearse cuando cambia el logo de la consola.
Todo este movimiento hacia un cloud sin muros, con conexiones privadas estandarizadas, servicios de seguridad gestionados en AWS, estrategias multicloud bien pensadas y profesionales centrados en fundamentos, está redefiniendo el mapa de la infraestructura digital: las empresas dejan de construir castillos aislados en una única nube y pasan a diseñar ecosistemas conectados donde la interconectividad, la soberanía del dato, la seguridad y la flexibilidad pesan tanto como la elección del proveedor, y donde saber moverse con soltura entre varios entornos se convierte en una habilidad tan crítica como dominar cualquiera de las nubes por separado.
Tabla de Contenidos
- Qué significa realmente un “cloud sin muros”
- AWS Interconnect y la nueva capa estructural del multicloud
- OCI + AWS: interconexión como estándar del cloud sin muros
- Soberanía del dato y cumplimiento: DORA, NIS2 y más allá
- Cloud sin muros e IA generativa: arquitecturas split‑stack
- Seguridad en un cloud sin muros: el caso de Palo Alto Networks Cloud NGFW para AWS
- Certificaciones cloud, perfiles profesionales y el valor de los fundamentos
