En este documento, se ayuda a los profesionales de operaciones y arquitectos de la nube a decidir cómo conectar Google Cloud con otros proveedores de servicios en la nube (CSP), como Amazon Web Services (AWS) y Microsoft Azure. En un diseño de múltiples nubes, las conexiones entre CSPs permiten transferencias de datos entre tus redes virtuales. En este documento, también se proporciona información sobre cómo implementar la opción que elijas.
Muchas organizaciones operan en múltiples plataformas en la nube, ya sea como una medida temporal durante una migración o porque la organización tiene una estrategia de múltiples nubes a largo plazo.
Para el intercambio de datos entre Google Cloud y otros CSP, existen varias opciones que se analizan en este documento:
- Transferencia de datos mediante direcciones IP públicas a través de Internet
- Uso de un servicio de VPN administrado entre Google Cloud y el otro CSP
- Uso de la interconexión de socio en Google Cloud para conectarse a un socio que puede conectarse directamente con el otro CSP
- Uso de la interconexión dedicada en Google Cloud para transferir datos al otro CSP mediante un punto de presencia (POP) común
- Uso de la interconexión cruzada en Google Cloud para una conexión administrada a otro CSP
Estas opciones difieren en cuanto a la velocidad de transferencia, la latencia, la confiabilidad, los Acuerdos de Nivel de Servicio (ANS), la complejidad y los costos. En este documento, se describen en detalle cada opción y sus ventajas y desventajas. En el final del documento, se comparan todas las opciones.
También se describen las transferencias de datos entre las máquinas virtuales que residen en Google Cloud y las redes virtuales de otros CSP. Para obtener información sobre los datos almacenados en otros productos de Google Cloud, como Cloud Storage y BigQuery, consulta la sección sobre estos productos.
Este documento puede considerarse una guía para evaluar las opciones de transferencia de datos entre Google Cloud y uno o más de los otros CSP, según tus requisitos y capacidades.
Los conceptos en este documento se aplican en múltiples casos:
- Cuando planeas transferir grandes cantidades de datos durante un período corto, por ejemplo, para un proyecto de migración de datos.
- Si ejecutas transferencias de datos continuas entre varios proveedores de servicios en la nube, por ejemplo, porque las cargas de trabajo de procesamiento se ejecutan en otro CSP mientras que las cargas de trabajo de macrodatos usan Google Cloud.
Consideraciones iniciales
Antes de que elijas cómo conectar tus entornos de nube, es importante que observes qué regiones eliges en cada entorno y que tengas una estrategia para la transferencia de datos que no residen en entornos de redes virtuales.
Elige regiones de nube
Si los recursos de Google Cloud y de otros CSP se encuentran en regiones geográficamente cercanas, existe una ventaja de costo y latencia para las transferencias de datos entre los proveedores de servicios en la nube.
En el siguiente diagrama, se ilustra el flujo de datos entre Google Cloud y otros CSP. 
Sin importar el método de transferencia, los datos fluyen desde Google Cloud al otro CSP de la siguiente manera:
- Desde la región de Google Cloud en la que se alojan los recursos hasta el POP perimetral de Google.
- A través de una instalación de terceros entre Google Cloud y el otro CSP
- Desde el POP perimetral del otro CSP hasta la región en la que se encuentran los recursos dentro de la red del otro CSP
Los datos que fluyen del otro CSP a Google Cloud viajan en la misma ruta, pero en la dirección opuesta.
La ruta de extremo a extremo determina la latencia de la transferencia de datos. Para algunas soluciones, los costos de la red también aumentan cuando los POP de ambos proveedores no se encuentran en un área metropolitana. Los detalles se enumeran en la siguiente sección de precios de cada solución.
Asegúrate de elegir regiones adecuadas en cada nube que puedan alojar tus cargas de trabajo previstas. Consulta la página Ubicaciones de Google Cloud y páginas similares de otros CSPs, como la tabla de regiones de AWS o los productos de Azure por región. Si deseas obtener ayuda general a fin de seleccionar una o varias ubicaciones en Google Cloud, consulta Prácticas recomendadas para seleccionar regiones de Compute Engine.
Transferencia de datos en Cloud Storage y BigQuery
Solo los datos que residen en un entorno de VPC de Google Cloud pasan un túnel de Cloud VPN o una conexión de Cloud Interconnect de forma predeterminada.
Si deseas transferir datos desde y hacia otros servicios de Google, puedes usar Private Service Connect y Acceso privado a Google para los hosts locales desde el entorno del otro CSP.
Si deseas transferir el almacenamiento de objetos, la base de datos, el almacén de datos o cualquier otro producto de otro CSP, consulta su documentación para comprobar si los datos pueden pasar a través de su producto VPN de interconexión o administrado. De lo contrario, puedes pasar estos datos mediante las máquinas virtuales proxy que configuraste en el entorno del CSP de modo que pasen a través de la conexión que deseas.
Para transferir datos a Cloud Storage o BigQuery, también puedes usar el Servicio de transferencia de almacenamiento o el servicio de transferencia de BigQuery.
Transferencia mediante direcciones IP externas a través de Internet
La forma más fácil de transferir datos entre Google Cloud y otro CSP es usar Internet y transferir los datos mediante direcciones IP externas.
En el siguiente diagrama, se ilustran los elementos para esta solución.
Entre el perímetro de red de Google y el del otro CSP, los datos pasan a través de Internet o usan un intercambio de tráfico directo entre Google Cloud y el otro CSP. Los datos solo pueden pasar entre los recursos que tienen asignadas direcciones IP públicas.
Cómo se conecta Google a otras redes
Los POP perimetrales de Google son la ubicación en la que la red de Google se conecta a otras redes que, en conjunto, forman la Internet. Google está presente en varias ubicaciones de todo el mundo.
En Internet, a cada red se le asigna un número de sistema autónomo (ASN) que abarca las rutas y la infraestructura de red interna de la red. El ASN principal de Google es 15,169.
Existen dos formas principales en que una red puede enviar o recibir tráfico desde o hacia Google:
- Adquiere un servicio de Internet de un proveedor de servicios de Internet (ISP) que ya tenga conectividad con Google (AS15169). Por lo general, a esta opción se la conoce como tránsito de IP y es similar a lo que los consumidores y las empresas compran a los proveedores de acceso en sus hogares y sus empresas.
- Conéctate directamente a Google (AS15169): Esta opción, llamada intercambio de tráfico, permite que una red envíe tráfico a Google (AS15169) y reciba tráfico desde Google directamente, sin usar una red de terceros. A gran escala, el intercambio de tráfico se suele preferir por sobre el tránsito, ya que los operadores de redes tienen un mayor control sobre cómo se intercambia el tráfico y en qué ubicaciones, lo que permite optimizar el rendimiento y los costos. El intercambio de tráfico es un sistema voluntario. Cuando se decide intercambiar tráfico, los operadores de redes deciden de forma conjunta en qué instalaciones conectarse, cuánto ancho de banda aprovisionar, cómo dividir los costos de infraestructura y cualquier otro detalle necesario para configurar las conexiones. AS15169 tiene una política de intercambio de tráfico abierto, lo que significa que, siempre que la red cumpla con los requisitos técnicos, Google intercambiará tráfico con ella.
El intercambio de tráfico es un acuerdo privado entre dos redes independientes que resulta beneficioso para ambas. Por esto, las redes, no suelen divulgan de forma pública con quién intercambian tráfico en ubicaciones específicas, cuánto ancho de banda hay disponible y demás aspectos. Sin embargo, debido al escalamiento y a una política abierta, Google intercambia tráfico directamente con casi todos los principales ISP y proveedores de servicios en la nube en varias ubicaciones y en distintas regiones. El equipo de redes de Google trabaja directamente con sus contrapartes en estas redes para proporcionar suficiente capacidad de intercambio de tráfico con el fin de satisfacer la demanda.
Puedes obtener más información sobre el funcionamiento del intercambio de tráfico en Internet en The Internet Peering Playbook (Guía del intercambio de tráfico en Internet).
Implementación
En esta configuración, todas las máquinas virtuales que transfieren datos entre Google Cloud y otros proveedores de servicios en la nube deben tener una dirección IP pública. En un extremo, el firewall debe estar abierto para permitir una conexión desde la dirección IP pública del otro proveedor de servicios en la nube. No se necesitan pasos adicionales porque el intercambio de datos se realiza a través de la conectividad de Internet existente.
Latencia y velocidad de las transferencias
Si bien no hay una velocidad y una latencia garantizada en la ruta a través de Internet, por lo general, los principales CSP y Google intercambian datos directamente en múltiples ubicaciones en todo el mundo. La capacidad se comparte con otros clientes y servicios, pero, a menudo, debido a la conexión directa entre ambos proveedores, la latencia es similar o inferior a otras opciones.
Recomendamos que pruebes la latencia y el ancho de banda entre Google Cloud y los otros CSP en las regiones que hayas elegido. Puedes realizar una comparativa rápida mediante herramientas como iperf o netperf, o ejecutar una comparativa personalizada más completa basada en tu app. Si bien las condiciones pueden cambiar con el tiempo, la comparativa puede proporcionar una indicación del rendimiento esperable y demostrar si esta solución satisface tus necesidades. Si necesitas un ancho de banda dedicado entre ambos entornos, debes elegir otra solución.
Ten en cuenta que los productos de proveedores diferentes pueden tener características de rendimiento que pueden no siempre estar en consonancia. Por ejemplo, la capacidad de VPN con IPsec por túnel puede variar de un proveedor a otro.
Seguridad
El tráfico a través de Internet no está encriptado y puede pasar a través de proveedores de servicios de Internet (ISP), instalaciones y sistemas autónomos de terceros. Por lo tanto, debes encriptar el tráfico sensible en la capa de aplicación o elegir otra solución.
Confiabilidad y ANS
En general, Google Cloud tiene varias rutas diversas para la conectividad a Internet desde regiones, y existen conexiones de intercambio de tráfico directo con otros CSP importantes en múltiples ubicaciones de todo el mundo.
Sin embargo, Google Cloud no proporciona ningún ANS para la conectividad con otros CSP a través de Internet. Si bien debes verificar los ANS de tus otros CSP, solo suelen hacer referencia a la conectividad a Internet en conjunto y no a proveedores específicos.
Es posible que los proveedores tengan diferentes políticas de enrutamiento, lo que puede afectar la disponibilidad. Por ejemplo, en su página peeringdb, Amazon explica que muchas regiones de AWS solo anuncian rutas locales, ya que las VPC de AWS son solo regionales (las VPC de Google Cloud son globales). Esto significa que puede que los clientes dependan de los vínculos en una sola ubicación de intercambio de tráfico, ya que el tráfico que sale de Google Cloud solo puede usar esos vínculos para llegar al destino. Esto no es un problema en condiciones de funcionamiento normales en las que el tráfico se intercambia dentro de la región, pero se recomienda que los clientes diseñen la arquitectura para implementaciones multirregionales con el fin de que se toleren las fallas regionales. Esto podría incluir la configuración de puertas de enlace adicionales, VPN con alta disponibilidad, el intercambio de tráfico entre redes virtulaes u otras topologías multirregionales en la nube de terceros.
Las aplicaciones también se deben compilar de modo que sean de tipo “fail open”, como recomienda la SRE de Google en el libro sobre SRE. Por ejemplo, si compilas una aplicación que depende de poder acceder a un servicio de terceros a través del enrutamiento de Internet, asegúrate de que, en caso de que haya problemas de conectividad, la aplicación siga funcionando o que, al menos, muestre mensajes de error útiles al usuario.
Cuando surgen problemas con el enrutamiento de Internet, el equipo de redes de Google intentará restablecer la conectividad con el tercero. Sin embargo, no todos los problemas estarán bajo el control de Google. Por lo tanto, en algunos casos, puede que la reparación dependa de que un tercero (un ISP o un proveedor de servicios en la nube) realice acciones de restauración. Los clientes son los que más influyen en la forma en que los operadores responden a las interrupciones, por lo que debes asegurarte de contar con cobertura de asistencia de todos los proveedores y un plan para derivar los problemas si algo sale mal. También debes realizar simulacros periódicos de BCP (proceso de continuidad empresarial) para garantizar la resiliencia de las aplicaciones diseñadas en múltiples nubes.
Precios
En el caso de las transferencias de datos a través de Internet, se aplican las tarifas de salida de Internet normales para el tráfico que sale de Google Cloud. En los casos en que la latencia no es crítica, el uso del nivel de servicio de red estándar proporciona un nivel de precios más bajo.
Los otros CSP tienen sus propios precios de transferencias de datos. En muchos casos, solo cobran por el tráfico que sale de su red. Consulta la lista de precios de tu CSP. Por ejemplo, para AWS, consulta los Cargos por transferencia de datos de EC2 y, para Azure, consulta los Detalles de precios de ancho de banda.
VPN administrada entre proveedores de servicios en la nube
Puedes usar servicios administrados de VPN desde ambos proveedores de servicios en la nube, que tienen dos beneficios. Proporciona un canal encriptado entre redes virtuales en ambos entornos de nube y te permite transferir datos mediante direcciones IP privadas. Esta es una extensión de la solución anterior de transferencia a través de Internet sin necesidad de hardware o socios.
En el siguiente diagrama, se ilustran los elementos para esta solución.
Cuando se usa esta solución, los datos se encriptan en Google Cloud mediante el uso de Cloud VPN y de una solución de VPN para el otro CSP. En la transferencia de datos entre Google Cloud y el otro CSP, se usa Internet como en la solución anterior.
Implementación
Google ofrece Cloud VPN como un servicio de VPN administrada para túneles IPsec encriptados, que se pueden usar en el extremo de Google. Otros CSP ofrecen sus propios productos de VPN administrada, que puedes usar para compilar túneles VPN IPsec entre ambos entornos. Por ejemplo, AWS ofrece la VPN de sitio a sitio de AWS y Azure ofrece la puerta de enlace de la VPN de Azure. Puedes conectar tus redes virtuales entre los entornos mediante túneles VPN.
Las direcciones IP en los dos entornos no deben superponerse porque no hay ninguna función de traducción de direcciones de red (NAT) disponible en Cloud VPN. En Cloud Router, las rutas superpuestas pueden quitarse del intercambio entre entornos, pero entonces no será posible la comunicación entre los servicios que usan estas direcciones IP.
Con Cloud Router en el modo de enrutamiento dinámico global, puedes llegar a todas las regiones en una red de VPC global mediante el uso de túneles VPN para esa región solo. Para otros CSP, es posible que necesites túneles VPN por región. Si tiene varias redes virtuales en un entorno de nube que no intercambian tráfico, debes conectar todas las redes virtuales que necesitan comunicarse entre sí de forma independiente con una VPN.
Google Cloud ofrece guías de interoperabilidad, que tienen instrucciones paso a paso para configurar túneles VPN a otros proveedores importantes de servicios en la nube:
- Alibaba Cloud VPN Gateway sin redundancia: Solo admite rutas estáticas.
- Alibaba Cloud VPN Gateway con redundancia: Solo admite rutas estáticas.
- AWS: admite el enrutamiento dinámico con Cloud Router.
- Microsoft Azure: admite el enrutamiento dinámico con Cloud Router.
Velocidad de transferencia y latencia
Cuando usas túneles VPN administrados, los datos siguen la misma ruta de Internet que si se intercambiaran directamente mediante direcciones IP públicas. La latencia observada debe ser similar a la de la opción anterior, con solo una pequeña sobrecarga para el túnel VPN. El ancho de banda disponible está limitado por el ancho de banda máximo por túnel VPN en Google Cloud, el ancho de banda máximo de los túneles del otro CSP y el ancho de banda disponible en la ruta de Internet.
Para obtener un mayor ancho de banda, puedes implementar varios túneles en paralelo. Para obtener más información sobre cómo implementar una solución de este tipo, consulta Compila una VPN de alta capacidad de procesamiento.
Puedes probar la latencia y el ancho de banda como se describe en la sección anterior, pero las condiciones pueden variar con el tiempo y no hay garantías de latencia o ancho de banda.
Seguridad
El tráfico en túneles VPN IPsec se encripta mediante cifrados aceptados por ambos CSP. Para obtener más información, consulta los Algoritmos de cifrado de IKE compatibles con Cloud VPN, las Preguntas frecuentes acerca de la VPN de AWS y los Parámetros de IPsec/IKE de VPN de Azure.
Confiabilidad y ANS
Cloud VPN ofrece un ANS de entre el 99.9% y el 99.99%, según si se selecciona una VPN clásica o de alta disponibilidad. A veces, otros CSP ofrecen ANS en sus productos de VPN administrada, por ejemplo, el ANS de VPN de sitio a sitio de AWS y el ANS de Azure para la puerta de enlace de VPN. Sin embargo, estos ANS solo cubren la disponibilidad de las puertas de enlace de VPN y no incluyen la conectividad a otros CSP a través de Internet, por lo que no hay un ANS en la solución de extremo a extremo.
Para aumentar la confiabilidad, se recomienda usar múltiples puertas de enlace y túneles VPN en Google Cloud y los otros CSP.
Precios
Se aplican cargos para el servicio de VPN administrada. En Google Cloud, se aplica un cargo por hora. Para obtener más información, consulta los precios de Cloud VPN. Para otros CSP, consulta sus listas de precios. Por ejemplo, consulta los precios de la conexión de VPN de sitio a sitio de AWS o los precios de la puerta de enlace de la VPN de Azure.
Además de los precios por hora del servicio de VPN, debes pagar por los datos transferidos a través de las puertas de enlace de VPN. En Google Cloud y muchos CSP, se aplican los cargos estándar de transferencia de datos por Internet, como se detalla en Transferencia a través de direcciones IP externas a través de Internet. En muchos casos, los cargos por transferencia de datos exceden el costo fijo para esta solución.
Interconexión de socio con socios que usan múltiples nubes
La interconexión de socio te permite conectar una nube privada virtual a redes virtuales de otro CSP mediante la red de socios selectos que ofrecen soluciones directas de múltiples nubes. Debes conectarte mediante la implementación de una o más instancias de enrutamiento virtual que se encarguen de la configuración necesaria del protocolo de puerta de enlace fronteriza (BGP).
En el siguiente diagrama, se muestra una configuración redundante que usa dos conexiones de interconexión de socio.
Las rutas se intercambian entre Cloud Router y la puerta de enlace del otro CSP mediante una instancia de enrutamiento virtual administrada por el socio que proporciona la interconexión. El tráfico fluye a través de la red del socio entre Google Cloud y el otro CSP.
Implementación
Esta solución requiere que configures múltiples componentes:
- En Google Cloud, debes configurar la interconexión de socio mediante un proveedor de servicios de interconexión que entregue datos en las regiones de Google Cloud y ofrezca conectividad de múltiples nubes con el otro CSP.
- En el otro CSP, debes usar su producto de interconexión para conectarte al mismo socio. Por ejemplo, en AWS puedes usar Direct Connect, y en Azure, ExpressRoute.
- En el lado del socio del proveedor de servicios, debes configurar el equipo de enrutamiento virtual que proporciona las sesiones de BGP a Google Cloud y al otro CSP.
Si el espacio de direcciones IP entre ambos entornos CSP se superpone, tu socio puede ofrecer funcionalidad NAT para el equipo de enrutamiento virtual. Consulta la documentación de los socios para obtener más información.
Velocidad de transferencia y latencia
Esta solución ofrece capacidad dedicada entre Google Cloud y otros CSP. Según el socio y el otro CSP, la capacidad del adjunto disponible puede variar. En Google Cloud, la interconexión de socio está disponible con una capacidad del adjunto entre 50 Mbps y 50 Gbps.
La latencia para esta solución es la suma de los siguientes puntos:
- La latencia entre la región en la que se alojan los recursos en Google Cloud y la ubicación de la interconexión en la que el socio se conecta a Google Cloud
- La latencia en la red de socios a la instancia de enrutamiento virtual, desde ella y a través de ella, hacia el otro CSP
- La latencia desde la ubicación perimetral del otro CSP en la que se realiza la interconexión con el socio a la región en la que se alojan los recursos en el CSP
Para obtener la menor latencia posible, las ubicaciones perimetrales de Google Cloud y del otro CSP deben estar en la misma área metropolitana, junto con la instancia de enrutamiento virtual. Por ejemplo, es posible que tengas una conexión de baja latencia si las regiones de la nube de CSP, el POP perimetral y la instancia de enrutamiento virtual se encuentran en el área de Ashburn, Virginia.
Si bien Google Cloud y muchos otros CSP no ofrecen garantías de latencia para el tráfico hacia su perímetro de red, debido a que hay una ruta y una capacidad dedicadas a través del socio, la latencia en esta solución suele ser menos variable que si Usas direcciones IP externas o una solución de VPN.
Seguridad
El tráfico que pasa a través de la interconexión de socio no está encriptado de forma predeterminada. Para ayudar a proteger tu tráfico, puedes implementar VPN con alta disponibilidad en Cloud Interconnect en el lado de Google Cloud de la conexión. Algunos otros CSP te permiten usar su servicio VPN administrada a través de una interconexión; por ejemplo, la VPN de sitio a sitio de AWS se puede usar a través de AWS Direct Interconnect. Como alternativa, también puedes usar un dispositivo virtual que encripte el tráfico del lado del otro CSP.
Otra opción es encriptar el tráfico en la capa de la aplicación, en lugar de usar una VPN.
Confiabilidad y ANS
Esta solución implica tres ANS diferentes: uno de Google, uno del socio de interconexión y otro del CSP.
Cuando se usa la interconexión de socio de forma redundante, Google ofrece ANS mensuales del 99.9% al 99.99% según la topología elegida. No hay un ANS en una conexión de interconexión de socio única.
Consulta la documentación de los otros CSP si deseas obtener el ANS de sus productos de interconexión, por ejemplo, el ANS de AWS Direct Connect o, en Azure, el ANS para ExpressRoute.
Consulta la documentación o los términos del proveedor de servicios de la interconexión de socio para conocer su ANS sobre la disponibilidad de la conectividad y la instancia de enrutamiento virtual. Por ejemplo, consulta el Acuerdo de servicios globales de Megaport.
Precios
En Google Cloud, hay una tarifa mensual por cada adjunto de interconexión de socio, según el ancho de banda. El tráfico que sale a través de la interconexión de socio se cobra a una tarifa más baja que el tráfico de Internet. Para obtener más información, consulta la página de precios de la interconexión de socio.
Consulta la página de precios de los otros CSP para obtener información sobre sus productos de interconexión, por ejemplo, los precios de AWS Direct Connect o los precios de Azure ExpressRoute. Por lo general, los precios también tienen un cargo mensual por los cargos de interconexión y transferencia de datos a través de la interconexión a una tarifa más baja que a través de Internet.
El socio establece cargos por servicios de interconexión según su propio precio, que se puede encontrar en su sitio web o si consultas con su equipo de ventas para obtener una cotización. Por lo general, si todas las transferencias de datos se realizan en la misma área metropolitana, los cargos son mucho menores que si los datos tuvieran que recorrer una distancia más larga en una red de socios.
Cuando los datos se transfieren con regularidad a volúmenes suficientemente altos, según los precios del otro CSP, esta solución a veces puede ofrecer el costo total más bajo debido a las tasas de salida con descuento. Incluso cuando se agregan los costos mensuales para la interconexión de interconexión de socio, el otro CSP y el socio proveedor de servicios, el uso de esta solución puede proporcionar ahorros significativos. Como los precios de los socios y otros CSP pueden cambiar sin previo aviso, haz tu propia comparación con cotizaciones actualizadas de todas las partes involucradas.
Interconexión dedicada a través de un POP común
Cuando se usan uno o más dispositivos de enrutamiento físicos en una instalación de interconexión común entre Google Cloud y el otro CSP, puedes conectar ambos proveedores de servicios en la nube mediante el uso de una interconexión dedicada en Google Cloud y un producto equivalente en el otro CSP. No es necesario que la ubicación de la interconexión sea la misma que la región en la que se encuentran los recursos.
En el siguiente diagrama, se muestra una configuración redundante que usa dos conexiones de interconexión dedicada:
Las rutas se intercambian entre Cloud Router y la puerta de enlace del lado del otro CSP mediante un enrutador físico que se coloca en una instalación de interconexión común. El tráfico fluye a través de este enrutador entre Google Cloud y el otro CSP.
Implementación
Esta solución requiere que alojes y mantengas los dispositivos de enrutamiento físico en una instalación de colocación en la que estén presentes Google y el CSP al que deseas conectarte. Desde este dispositivo de enrutamiento, debes solicitar dos conexiones físicas con la instalación: una hacia Google Cloud mediante la interconexión dedicada y otra hacia el otro proveedor de servicios mediante un producto equivalente; por ejemplo, la AWS Direct Connect o Azure ExpressRoute. En tu dispositivo de enrutamiento, debes configurar BGP para permitir el intercambio de rutas entre los dos entornos de nube.
Verifica la lista de ubicaciones de instalaciones de colocación de Google Cloud y el otro CSP, por ejemplo, las ubicaciones de AWS Direct Connect o las ubicaciones de intercambio de tráfico de Azure ExpressRoute, a fin de identificar las ubicaciones adecuadas para esta configuración.
Los rangos de direcciones IP entre tus redes virtuales no deben superponerse, a menos que tu dispositivo de enrutamiento físico sea capaz de realizar NAT entre los entornos o que restrinjas algunos intercambios de rutas entre los entornos.
Esta solución es efectiva si usas la conectividad dedicada para también conectarte a tu entorno local, además de a otro CSP.
En otros casos, esta solución es compleja porque requiere que poseas y mantengas equipos físicos y un contrato con una instalación de colocación. Solo recomendamos esta solución si se cumple al menos uno de los siguientes casos:
- Ya tienes equipos en una instalación adecuada para otro propósito y un contrato existente con la instalación.
- Transfieres grandes cantidades de datos con regularidad, por lo que esta es una opción rentable, o tienes requisitos de ancho de banda que los socios no pueden cumplir.
Velocidad de transferencia y latencia
Esta solución ofrece una capacidad dedicada entre Google Cloud y otro CSP. En Google Cloud, la interconexión dedicada está disponible a través de una o varias conexiones físicas de 10 o 100 Gbps.
La latencia para esta solución es una suma de lo siguiente:
- La latencia entre la región en la que se alojan los recursos en Google Cloud y la ubicación de la interconexión en la que te interconectas con Google Cloud
- La latencia en la instalación y el equipo físico, que no suele tener importancia en comparación con cualquier latencia debido a la longitud de la fibra
- La latencia desde la ubicación de la interconexión a través de la red del otro CSP hasta la región en la que se alojan los recursos en el CSP
Si bien no se ofrecen garantías de latencia, esta solución suele proporcionar la latencia más baja y las velocidades de transferencia más altas entre Google Cloud y otros entornos de nube a través de direcciones IP privadas.
Seguridad
El tráfico que pasa a través de la interconexión dedicada no está encriptado de forma predeterminada. Para ayudar a proteger tu tráfico, puedes implementar VPN con alta disponibilidad en Cloud Interconnect en el lado de Google Cloud de la conexión. Algunos otros CSP te permiten usar su servicio VPN administrada a través de una interconexión; por ejemplo, la VPN de sitio a sitio de AWS se puede usar a través de AWS Direct Interconnect. Como alternativa, también puedes usar un dispositivo virtual que encripte el tráfico del lado del otro CSP.
Otra opción es encriptar el tráfico en la capa de la aplicación, en lugar de usar una VPN.
Confiabilidad y ANS
Cuando se usa la interconexión dedicada de forma redundante, Google ofrece ANS mensuales del 99.9% al 99.99% según la topología elegida. No hay un ANS en una sola conexión de interconexión dedicada.
Si deseas obtener más información, consulta la documentación de los otros CSP sobre el ANS de sus productos de interconexión, por ejemplo, el ANS de AWS Direct Connect o el ANS de Azure para ExpressRoute.
La instalación de colocación o el proveedor de hardware para el equipo de enrutamiento físico también pueden ofrecer ANS en sus servicios.
Precios
En Google Cloud, hay una tarifa mensual por cada puerto de interconexión dedicada, así como por cada adjunto de VLAN que tenga una conexión a un entorno de VPC. El tráfico que sale a través de la interconexión dedicada se cobra a una tarifa más baja que el tráfico de Internet. Para obtener más información, consulta la página de precios de la interconexión dedicada.
Consulta la página de precios de los otros CSP para obtener información sobre sus productos de interconexión, por ejemplo, los precios de AWS Direct Connect o los precios de Azure ExpressRoute. Por lo general, los precios también tienen un cargo mensual por los cargos de interconexión y transferencia de datos a través de la interconexión a una tarifa más baja que a través de Internet.
Además, debes tener en cuenta los cargos por los servicios de instalación de colocación que proporcionan espacio, energía eléctrica y conexiones físicas a ambos entornos de nube y cualquier costo y contrato de servicio actual con el proveedor del equipo de enrutamiento físico. Si la conexión entre ambos CSP no se puede establecer en la misma instalación y necesitas obtener conectividad entre las instalaciones, los precios podrían ser mucho más altos para estos servicios.
Conexiones administradas de Cross-Cloud Interconnect
Puedes conectar tus redes de VPC de Google Cloud a tus redes virtuales en otro CSP mediante la estructura de la red de Google. En cierto sentido, esta configuración funciona como Partner Interconnect, pero con el ANS de Google que abarca las dos redes de Google y las propias interconexiones.
En el siguiente diagrama, se muestra una configuración de Cloud Interconnect con la cantidad mínima de conexiones.
Las rutas se intercambian entre Cloud Router y la puerta de enlace del otro CSP sobre la estructura de la red de Google. El tráfico fluye a través de esta estructura entre Google Cloud y el otro CSP.
Implementación
Cuando compras Cross-Cloud Interconnect, Google aprovisiona una conexión física dedicada entre la red de Google y la de otro proveedor de servicios en la nube. Puedes usar esta conexión para intercambiar tráfico con tu red de nube privada virtual (VPC) de Google Cloud por una red alojada por un proveedor de servicios en la nube compatible.
Después de aprovisionar la conexión, Google admite la conexión hasta el punto en que llega a la red del otro proveedor de servicios en la nube. Google no garantiza el tiempo de actividad del otro proveedor de servicios en la nube. Sin embargo, Google sigue siendo el punto de contacto principal para el servicio completo y te notificará si necesitas abrir un caso de ayuda con el otro CSP.
Esta solución requiere que sigas el proceso de configuración para el otro CSP, que incluye elegir dónde se interconectarán las dos redes. Solo se admiten ciertos CSP.
Velocidad de transferencia y latencia
Esta solución ofrece una capacidad dedicada entre Google Cloud y otro CSP. En Google Cloud, la interconexión dedicada está disponible a través de uno o varios pares de conexiones físicas de 10 Gbps o 100 Gbps.
La latencia para esta solución es una suma de lo siguiente:
- La latencia entre la región en la que se alojan los recursos en Google Cloud y la ubicación entre nubes.
- La latencia entre la ubicación perimetral de Google y la ubicación perimetral del otro CSP (a menudo, en la misma instalación)
- La latencia desde la ubicación perimetral del otro CSP en la que se implementa Cross-Cloud Interconnect en la región en la que se alojan los recursos en el CSP
Si bien no se ofrecen garantías de latencia, esta solución suele proporcionar la latencia más baja posible y las velocidades de transferencia más altas posibles entre Google Cloud y otros entornos de nube a través de direcciones IP privadas.
Seguridad
Debido a que el tráfico a través de Cross-Cloud Interconnect no está encriptado, recomendamos el uso de la encriptación de la capa de aplicación para el tráfico sensible.
Si se debe encriptar todo el tráfico, los dispositivos virtuales que están disponibles en los socios de Google Cloud en Cloud Marketplace puede proporcionar soluciones para la encriptación del tráfico en el entorno del otro CSP.
Confiabilidad y ANS
Cross-Cloud Interconnect usa el ANS de Cloud Interconnect. Para calificar en el ANS, la configuración de Cloud Interconnect debe usar uno o más pares de conexiones, como se describe en la sección Acuerdo de Nivel de Servicio de Cross- Descripción general de Cross-Cloud Interconnect
El ANS cubre todo en el lado de Google hasta el perímetro de la red del otro proveedor de servicios en la nube. No abarca la red del otro CSP. Si deseas obtener más información, consulta la documentación de los otros CSP sobre el ANS de sus productos de interconexión; por ejemplo, el ANS de AWS Direct Connect o el ANS de Azure para ExpressRoute.
Precios
Hay una tarifa por hora por cada conexión de Cross‐Cloud Interconnect y por cada adjunto de VLAN que se conecte a un entorno de VPC. El tráfico que sale a través de Cross-Cloud Interconnect se cobra a una tarifa más baja que el tráfico de Internet. Para obtener más información, consulta Precios de Cross-Cloud Interconnect.
Consulta la página de precios de los otros CSP para obtener información sobre sus productos de interconexión, por ejemplo, los precios de AWS Direct Connect o los precios de Azure ExpressRoute. Por lo general, se cobra un cargo mensual por la interconexión. Los cargos por la transferencia de datos a través de la interconexión suelen ser más bajos que los cargos por la transferencia de datos a través de Internet.
No se aplican costos adicionales por los equipos o las ubicaciones de interconexión.
Comparación de opciones
Las opciones presentadas varían en velocidad, disponibilidad, complejidad, seguridad y precios. Debes evaluar todas las opciones detenidamente según tus necesidades.
El siguiente diagrama de flujo sirve como guía para seleccionar una de las soluciones mencionadas en este documento.
Por lo general, podemos recomendar las siguientes opciones:
- Para muchas situaciones en las que los datos se intercambian de forma ocasional o con un volumen bajo y las transferencias no son críticas, la transferencia de datos a través de Internet es la opción más simple y aun así ofrece una latencia relativamente baja y un ancho de banda alto.
- Si se requiere la encriptación o la transferencia de pequeñas cantidades de datos mediante direcciones IP privadas, considera usar Cloud VPN y un servicio de VPN administrado en el lado del otro CSP.
- Si transfieres grandes cantidades de datos, el uso de la interconexión de socio con un socio habilitado para múltiples nubes proporciona múltiples beneficios: capacidad dedicada, menor costo para las transferencias de datos y, según la topología, un ANS para cada parte de la solución. La capacidad de interconexión de socio suele ser inferior a 10 Gbps por conexión.
- Si conectas tu equipo local a varias nubes, una opción común es el uso de una interconexión dedicada a través de un POP común. Esta opción agrega la complejidad adicional de administrar tu propio hardware y las relaciones con una instalación de colocación. A menos que ya cuentes con la infraestructura, esta solución está reservada para los casos en los que las tasas de transferencia de datos típicas son de 10 Gbps o más.
- Si no quieres la sobrecarga de administrar conexiones cruzadas y equipos de enrutamiento en POP remotos, Cross-Cloud Interconnect proporciona una solución administrada en la que Google se encarga de todo eso.
¿Qué sigue?
- Revisa la serie sobre patrones y prácticas híbridas y de múltiples nubes.
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.