Skip to main content
language

English

arrow
arrow Menu
    Cloud

    Cloud Connect: cómo conectar la empresa a AWS, Azure y Google

    Cloud Connect: how to link your business to AWS, Azure and Google

    Cloud Connect es el conjunto de servicios de interconexión privada que permite unir la infraestructura de una empresa con una nube pública sin pasar por internet. La decisión de adoptarlo aparece casi siempre en el mismo punto del recorrido: las cargas críticas ya están en la nube, el tráfico entre el centro de datos propio y el proveedor creció, y la variabilidad de latencia o la factura de salida de datos empezaron a doler.

    La discusión importa porque el escenario real de las empresas no es la nube pura. El informe anual de Flexera correspondiente a 2026 encontró que el 73% de las organizaciones opera nube híbrida y que apenas el 14% funciona exclusivamente en multinube sin nube privada. En las grandes empresas, el 54% de las cargas está en nube pública, lo que significa que casi la mitad sigue fuera y necesita conectarse. Esta guía compara los modelos de conexión disponibles, revisa lo que ofrece cada hiperescalador y precisa dónde termina la responsabilidad del proveedor de nube y dónde empieza la del operador de red.

    ¿Qué es Cloud Connect y qué problema resuelve?

    Los tres grandes proveedores de nube ubican sus routers de borde en instalaciones de colocación específicas, que llaman ubicaciones de peering o de interconexión. Para establecer un enlace privado, la red de la empresa tiene que llegar físicamente a una de esas instalaciones. Como la mayoría de las organizaciones no tiene presencia allí, un operador de telecomunicaciones transporta el circuito desde la sede o el centro de datos del cliente hasta ese punto y realiza la conexión cruzada. Ese trayecto es la última milla, y es exactamente lo que resuelve un servicio de Cloud Connect.

    El resultado es un enlace dedicado, con ancho de banda determinístico, que no atraviesa internet. Microsoft lo formula sin rodeos en su documentación: las conexiones de ExpressRoute no van por internet público y ofrecen mayor seguridad, confiabilidad y velocidad, con latencias más bajas y consistentes que una conexión típica por internet. AWS describe el beneficio en los mismos términos, señalando que el tráfico permanece en su red global y nunca toca internet, lo que reduce la probabilidad de encontrar cuellos de botella o incrementos inesperados de latencia.

    Interconexión privada o VPN sobre internet

    Antes de comparar proveedores conviene resolver la decisión de fondo, porque una VPN sobre internet sigue siendo una opción legítima para muchos casos de uso.

    VPN sobre internet público

    Es rápida de aprovisionar, no requiere presencia física en ninguna instalación y trae cifrado incorporado por diseño. Un dato que suele sorprender: la VPN de alta disponibilidad de Google publica un acuerdo de nivel de servicio de 99,99% o 99,9% según la configuración, de modo que el diferencial de la interconexión privada no está en el número de disponibilidad. Su límite real es otro: el camino que recorre el tráfico es internet, con la variabilidad de latencia y de rendimiento que eso implica, y el ancho de banda queda acotado por la capacidad del túnel y del equipo que lo termina.

    Interconexión privada dedicada

    Entrega capacidad garantizada, latencia consistente y aislamiento del camino de red. A cambio exige presencia en una ubicación de interconexión (propia o a través de un socio), un plazo de aprovisionamiento mayor y un compromiso de puerto. Hay un matiz técnico que conviene tratar con honestidad: la interconexión privada no viene cifrada por defecto. Su argumento de seguridad es el aislamiento del camino, no el cifrado automático. Quien necesite cifrado tiene que sumarlo de forma explícita, con MACsec en el caso de AWS o desplegando una VPN de alta disponibilidad sobre Cloud Interconnect en el caso de Google.

    El factor que suele decidir: el costo de salida de datos

    Aquí la diferencia es cuantificable y Google la declara de forma explícita en su documentación de precios: la transferencia de datos desde una red virtual a través de conexiones de Cloud Interconnect tiene un descuento frente al precio general de red. La tarifa de salida por interconexión arranca en 0,020 dólares por gibibyte, mientras la salida a internet en su nivel premium hacia Sudamérica va de 0,15 a 0,19 dólares por gibibyte según el volumen. En Azure, la salida medida de ExpressRoute empieza en 0,025 dólares por gigabyte y existe un plan de datos ilimitados con una tarifa mensual fija de puerto que incluye toda la transferencia entrante y saliente, frente a 0,181 dólares por gigabyte de salida a internet desde Sudamérica en el tramo de los siguientes 10 terabytes mensuales. En AWS, la transferencia de datos de salida sobre Direct Connect arranca en 0,02 dólares por gigabyte según la geografía.

    Para una carga que mueve decenas de terabytes al mes, esa brecha por unidad transforma el análisis: el costo del puerto dedicado se recupera con el ahorro en salida de datos, y la latencia consistente pasa a ser un beneficio adicional en lugar del argumento principal.

    Cómo funciona en cada nube

    AWS Direct Connect

    Ofrece dos modalidades. La conexión dedicada es un enlace Ethernet físico asociado a un solo cliente, que se solicita directamente desde la consola o la interfaz de programación, con velocidades de 1, 10, 100 y 400 gigabits por segundo. La conexión hospedada la aprovisiona un socio del programa en nombre del cliente y cubre el rango de 50 megabits a 25 gigabits por segundo, lo que la vuelve la vía natural cuando no se necesita un puerto completo.

    Sobre la conexión física se configuran interfaces virtuales de tres tipos: privada para acceder a una nube privada virtual con direcciones IP privadas, pública para alcanzar los servicios públicos de AWS a nivel global, y de tránsito para conectar con pasarelas de tránsito. El acuerdo de nivel de servicio merece atención especial, porque no es un número único: 99,99% para un despliegue redundante en múltiples sitios, 99,9% para uno no redundante en múltiples sitios y 95% para una conexión única. AWS recomienda de forma explícita no usar ningún otro esquema que los dos primeros para cargas productivas.

    Azure ExpressRoute

    Trabaja con circuitos de 50 megabits a 10 gigabits por segundo y tiene una particularidad valiosa: cada circuito incluye redundancia integrada con conexiones primaria y secundaria hacia dos routers de borde de Microsoft, cada una al ancho de banda contratado. El ancho de banda se puede aumentar de forma dinámica sin desmontar las conexiones. Es conectividad de capa 3 con BGP y admite dos dominios de enrutamiento en circuitos nuevos: peering privado para redes virtuales y peering de Microsoft para servicios de productividad y plataforma.

    Una precisión de arquitectura que evita errores de diseño: la ubicación del circuito no necesita coincidir con la región de Azure donde viven los recursos. Para quien requiere aislamiento físico o ingesta masiva de datos existe ExpressRoute Direct, que conecta directamente con la red global de Microsoft mediante pares de puertos de 10, 100 o 400 gigabits por segundo, sin proveedor intermediario. El acuerdo de nivel de servicio publicado garantiza un mínimo de 99,95% de disponibilidad del circuito dedicado.

    Google Cloud Interconnect

    Distingue entre Dedicated Interconnect, una conexión física directa con la red de Google, y Partner Interconnect, que llega a través de un proveedor de servicio compatible. La modalidad dedicada escala de una a ocho conexiones, lo que permite agregados de hasta 800 gigabits por segundo con enlaces de 100 gigabits y hasta 3.200 con enlaces de 400. La modalidad de socio ofrece adjuntos de red virtual de 50 megabits a 50 gigabits por segundo.

    Su modelo de socio incorpora una distinción que conviene conocer al comparar propuestas. En capa 2, el cliente configura y establece las sesiones BGP entre sus routers en la nube y sus equipos locales. En capa 3, es el proveedor el que establece esa sesión, con la configuración automatizada, lo que reduce el trabajo del equipo de red y permite preactivar conexiones. El acuerdo de nivel de servicio es escalonado y exigente en topología: 99,99% requiere al menos cuatro conexiones distribuidas en dos áreas metropolitanas distintas, 99,9% admite dos conexiones en la misma área metropolitana pero en dominios de disponibilidad separados, y una sola conexión no tiene acuerdo de nivel de servicio.

    Criterio AWS Direct Connect Azure ExpressRoute Google Cloud Interconnect
    Capacidad con puerto propio 1, 10, 100 y 400 Gbps Pares de 10, 100 o 400 Gbps con ExpressRoute Direct Hasta 8 enlaces: 800 Gbps con 100 G y 3.200 Gbps con 400 G
    Capacidad vía socio 50 Mbps a 25 Gbps (conexión hospedada) Circuitos de 50 Mbps a 10 Gbps Adjuntos de 50 Mbps a 50 Gbps
    Disponibilidad máxima publicada 99,99% con despliegue redundante en múltiples sitios 99,95% del circuito dedicado 99,99% con cuatro conexiones en dos áreas metropolitanas
    Con una sola conexión 95% Redundancia dual incluida en cada circuito Sin acuerdo de nivel de servicio
    Salida de datos Desde 0,02 USD por GB Desde 0,025 USD por GB, o plan ilimitado con tarifa fija de puerto Desde 0,020 USD por GiB, con descuento declarado frente a internet
    Cifrado Opcional, con MACsec en ubicaciones habilitadas Opcional, sobre el circuito Opcional, con VPN de alta disponibilidad sobre la interconexión

    Fuente: documentación oficial y páginas de precios y acuerdos de nivel de servicio de AWS, Microsoft y Google Cloud, consultadas en julio de 2026. 

    Dónde termina el acuerdo del hiperescalador

    Este es el punto que más se pasa por alto en una evaluación y el que más impacto tiene en la operación real. Google lo dice de forma literal en su documentación de acuerdos de nivel de servicio para Partner Interconnect: la garantía aplica únicamente a la conectividad entre la red virtual del cliente y la red del proveedor de servicio, y no incluye la conectividad entre la red del cliente y la red del proveedor.

    Traducido a la práctica: el hiperescalador responde por su tramo, no por el trayecto que va desde la sede o el centro de datos del cliente hasta la ubicación de interconexión. Ese tramo, su redundancia, su monitoreo y su acuerdo de nivel de servicio son del operador. Por eso la pregunta relevante al evaluar un servicio de Cloud Connect no es qué disponibilidad publica el proveedor de nube, sino qué disponibilidad de punta a punta queda comprometida por contrato una vez sumados los dos tramos.

    Los tres proveedores estructuran esto mediante programas de socios de conectividad con requisitos formales. En el caso de AWS, los socios habilitados para entrega deben aprobar una validación adicional, contar con monitoreo de la interconexión y estar autorizados a aprovisionar capacidades superiores a 500 megabits por segundo. En Liberty Networks operamos como socio con certificación de entrega de Direct Connect y ofrecemos servicios gestionados de AWS que integran nuestros centros de datos con esa conexión directa, además de servicios gestionados de Azure para entornos de Microsoft.

    Qué evaluar antes de contratar

    Cinco criterios ordenan la decisión y permiten comparar propuestas que a primera vista parecen equivalentes.

    • Topología, no solo capacidad. Los acuerdos de nivel de servicio altos dependen de la redundancia, no del tamaño del puerto. Una sola conexión de 10 gigabits por segundo tiene menos garantía que dos de 1 gigabit bien distribuidas.
    • Perfil de tráfico saliente. Estimar el volumen mensual de salida de datos convierte la comparación de tarifas en una cifra concreta y suele ser el argumento que financia el proyecto.
    • Cobertura de la última milla. Verificar que el operador llegue con fibra propia a las sedes relevantes y a la ubicación de interconexión, y con qué diversidad de rutas.
    • Modelo de gestión de BGP. Definir si el equipo interno administrará el enrutamiento o si prefiere que el proveedor lo establezca y lo automatice, tal como permite el modelo de capa 3.
    • Estrategia multinube. Si hay más de una nube en el horizonte, conviene una arquitectura que agregue las conexiones en un punto común en lugar de replicar enlaces aislados por proveedor.

    La conectividad a nube como decisión de arquitectura

    El mercado empuja en esta dirección con fuerza. El gasto empresarial en servicios de infraestructura en la nube alcanzó 129.000 millones de dólares en el primer trimestre de 2026, un alza del 35% interanual y la mayor tasa de crecimiento desde finales de 2021, con Amazon, Microsoft y Google concentrando el 63% del mercado. Es decir: casi dos de cada tres dólares de nube empresarial van a los tres proveedores a los que se refiere este artículo.

    Al mismo tiempo, el 93% de las organizaciones opera estrategias de nube híbrida multinube según el informe anual de F5, y más de nueve de cada diez trabajan con al menos dos de estos tres entornos: nube pública, nube privada y colocación. La conclusión de arquitectura es que la conexión a la nube dejó de ser un enlace más para convertirse en un componente estructural del diseño de red, con las mismas exigencias de redundancia y de acuerdo de nivel de servicio que se aplican a un enlace MPLS o a un centro de datos. Nuestro portafolio de soluciones ICT aborda ese conjunto de forma integrada, con la infraestructura propia y la conectividad regional como base. Para quien esté diseñando un entorno con más de un proveedor de nube, la conversación siguiente es la de arquitectura multinube, que merece su propio tratamiento.

    Sources

    Volver arriba

    ¿Listo para escalar?

    Hable con un arquitecto de soluciones para sus necesidades de conectividad regional.