Este documento ayuda a los arquitectos de la nube y a los profesionales de operaciones a decidir cómo conectarse Google Cloud con otros proveedores de servicios en la nube, como Amazon Web Services (AWS) y Microsoft Azure. En un diseño multicloud, las conexiones entre los CSPs permiten transferir datos entre tus redes virtuales. En este documento también se explica cómo implementar la opción que elijas.
Muchas organizaciones operan en varias plataformas en la nube, ya sea como medida temporal durante una migración o porque la organización tiene una estrategia multinube a largo plazo.
Para intercambiar datos entre Google Cloud y otros proveedores de servicios en la nube, hay varias opciones que se describen en este documento:
- Transferencia de datos a través de direcciones IP públicas por Internet.
- Usar un servicio de VPN gestionado entre Google Cloud y el otro CSP.
- Usar Partner Interconnect en Google Cloud para conectarse a un partner que pueda conectarse directamente con el otro CSP.
- Usar la interconexión dedicada en Google Cloud para transferir datos al otro proveedor de servicios en la nube a través de un punto de presencia (PoP) común.
- Usar Cross-Cloud Interconnect en Google Cloud para establecer una conexión gestionada con otro CSP.
Estas opciones se diferencian en cuanto a velocidad de transferencia, latencia, fiabilidad, acuerdos de nivel de servicio (SLAs), complejidad y costes. En este documento se describe cada opción y sus ventajas y desventajas en detalle, y se termina con una comparación de todas las opciones.
En este documento se describen las transferencias de datos entre máquinas virtuales ubicadas enGoogle Cloud y redes virtuales de otros proveedores de servicios en la nube. Para obtener información sobre los datos almacenados en otros productos, como Cloud Storage y BigQuery, consulta la sección sobre estos productos.Google Cloud
Este documento puede servir de guía para evaluar las opciones de transferencia de datos entre Google Cloud y uno o varios CSPs, en función de sus requisitos y capacidades.
Los conceptos de este documento se aplican en varios casos:
- Cuando tenga previsto transferir grandes cantidades de datos durante un breve periodo, por ejemplo, en un proyecto de migración de datos.
- Si ejecutas transferencias de datos continuas entre varios proveedores de servicios en la nube, por ejemplo, porque tus cargas de trabajo de computación se ejecutan en otro CSP mientras que tus cargas de trabajo de big data usan Google Cloud.
Consideraciones iniciales
Antes de elegir cómo conectar tus entornos de nube, es importante que decidas qué regiones vas a usar en cada entorno y que tengas una estrategia para transferir los datos que no se encuentren en entornos de red virtual.
Elegir regiones de la nube
Si tanto los recursos de Google Cloud como los de otros proveedores de servicios en la nube se encuentran en regiones geográficamente cercanas entre sí, las transferencias de datos entre proveedores de la nube tendrán un coste y una latencia menores.
En el siguiente diagrama se muestra el flujo de datos entre Google Cloudy otros CSPs.
Independientemente del método de transferencia, los datos fluyen de Google Cloud al otro proveedor de servicios en la nube de la siguiente manera:
- Desde la Google Cloud región 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 proveedor de servicios en la nube.
- 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 siguen la misma ruta, pero en la dirección opuesta.
La ruta de extremo a extremo determina la latencia de la transferencia de datos. En algunas soluciones, los costes de red también aumentan cuando los PoPs de extremo de ambos proveedores no se encuentran en la misma zona metropolitana. Los detalles se indican en la sección de precios de cada solución.
Asegúrate de elegir las regiones adecuadas en cada nube que puedan alojar las cargas de trabajo que quieras. Visita la página Ubicaciones de Google Cloud y páginas similares de otros proveedores de servicios en la nube, como la tabla de regiones de AWS o los productos de Azure por región. Para obtener ayuda general sobre cómo seleccionar una o varias ubicaciones en Google Cloud, consulta las prácticas recomendadas para seleccionar la región de Compute Engine.
Transferencia de datos en Cloud Storage y BigQuery
De forma predeterminada, solo los datos que residen en un entorno de Google Cloud VPC pasan por un túnel de Cloud VPN o por una conexión de Cloud Interconnect.
Si quieres transferir datos a y desde otros servicios de Google, puedes usar Private Service Connect y Private Google Access para hosts locales desde el entorno del otro proveedor de servicios en la nube.
Si quieres transferir el almacenamiento de objetos, la base de datos, el almacén de datos u otros productos de otro proveedor de servicios en la nube, consulta su documentación para ver si los datos pueden pasar por su interconexión o su producto de VPN gestionado. De lo contrario, puede que puedas transferir estos datos a través de máquinas virtuales proxy que configures en el entorno del proveedor de servicios en la nube correspondiente para que pasen por la conexión que quieras.
Para transferir datos a Cloud Storage o BigQuery, también puedes usar Servicio de transferencia de Storage o Servicio de transferencia de BigQuery.
Transferencia a través de direcciones IP externas por Internet
La forma más sencilla 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 muestran los elementos de esta solución.
Entre el perímetro de la red de Google y el de la otra CSP, los datos se transfieren a través de Internet o mediante un emparejamiento directo entre Google Cloud y la otra CSP. Los datos solo pueden transferirse entre recursos que tengan asignadas direcciones IP públicas.
Cómo se conecta Google a otras redes
Los PoPs de extremo de Google son los puntos en los que la red de Google se conecta a otras redes que forman Internet. Google tiene presencia en numerosas ubicaciones de todo el mundo.
En Internet, a cada red se le asigna un número de sistema autónomo (ASN) que abarca la infraestructura de red interna y las rutas de la red. El ASN principal de Google es 15169.
Hay dos formas principales en las que una cadena puede enviar o recibir tráfico a Google:
- Contratar un servicio de Internet a un proveedor que ya tenga conectividad con Google (AS15169). Esta opción se conoce generalmente como tránsito de IP y es similar a lo que los consumidores y las empresas compran a los proveedores de acceso en sus casas y negocios.
- Conéctate directamente a Google (AS15169). Esta opción, llamada peering, permite que una red envíe y reciba tráfico directamente a Google (AS15169) sin usar una red de terceros. A gran escala, el peering suele ser preferible al tránsito, ya que los operadores de redes tienen más control sobre cómo y dónde se intercambia el tráfico, lo que permite optimizar el rendimiento y los costes. El peering es un sistema voluntario. Cuando eligen establecer peering, los operadores de redes deciden conjuntamente en qué instalaciones conectarse, cuánto ancho de banda aprovisionar, cómo dividir los costes de infraestructura y cualquier otro detalle necesario para configurar las conexiones. AS15169 tiene una política de peering abierta, lo que significa que, siempre que una red cumpla los requisitos técnicos, Google establecerá peering con ella.
El emparejamiento es un acuerdo privado y mutuamente beneficioso entre dos redes independientes. Por este motivo, las redes no suelen revelar públicamente con quién se emparejan en ubicaciones concretas, cuánto ancho de banda tienen disponible, etc. Sin embargo, debido a la escala y a una política abierta, Google se empareja directamente con casi todos los principales proveedores de servicios de Internet y de servicios en la nube en varias ubicaciones y regiones. El equipo de redes de Google trabaja directamente con sus homólogos de estas redes para proporcionar suficiente capacidad de peering y satisfacer la demanda.
Puedes consultar más información sobre cómo funciona el peering de Internet en The Internet Peering Playbook.
Implementación
En esta configuración, todas las máquinas virtuales que transfieran datos entreGoogle Cloud y otros proveedores de servicios en la nube deben tener una dirección IP pública. Por un lado, el cortafuegos debe abrirse para permitir una conexión desde la dirección IP pública del otro proveedor de nube. No es necesario realizar ningún paso adicional, ya que el intercambio de datos se produce a través de la conectividad a Internet.
Velocidad de transferencia y latencia
Aunque no se garantiza la velocidad ni la latencia en la ruta a través de Internet, normalmente los principales CSPs y Google intercambian datos directamente en varias ubicaciones de 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 la de otras opciones.
Te recomendamos que pruebes la latencia y el ancho de banda entre Google Cloud y los demás CSPs de las regiones que hayas elegido. Puedes hacer una prueba rápida con herramientas como iperf o netperf, o bien realizar una prueba personalizada más completa basada en tu aplicación. Aunque las condiciones pueden cambiar con el tiempo, la prueba puede darte una idea del rendimiento que puedes esperar y de si esta solución satisface tus necesidades. Si necesitas un ancho de banda dedicado entre ambos entornos, debes elegir otra solución.
Tenga en cuenta que los productos de diferentes proveedores pueden tener características de rendimiento que no siempre coincidan. Por ejemplo, la capacidad de VPN IPsec por túnel puede variar de un proveedor a otro.
Seguridad
El tráfico a través de Internet no está cifrado y puede pasar por proveedores de servicios de Internet (ISPs), sistemas autónomos e instalaciones de terceros. Por lo tanto, debe cifrar el tráfico sensible en la capa de aplicación o elegir otra solución.
Fiabilidad y SLA
Google Cloud suele tener varias rutas diversas para la conectividad a Internet desde las regiones, y hay conexiones de peering directas con otros CSPs importantes en varias ubicaciones de todo el mundo.
Sin embargo, Google Cloud no ofrece ningún SLA para la conectividad a otros CSPs a través de Internet. Aunque debes consultar los SLAs de tus otros CSPs, normalmente solo hacen referencia a la conectividad a Internet en general y no a proveedores específicos.
Los proveedores pueden tener políticas de enrutamiento diferentes, lo que puede influir en la disponibilidad. Por ejemplo, en su página de peeringdb, Amazon explica que muchas regiones de AWS solo anuncian rutas locales, ya que las VPCs de AWS son solo regionales (lasGoogle Cloud VPCs son globales). Esto significa que los clientes pueden depender de los enlaces de una sola ubicación de interconexión, ya que el tráfico que sale de Google Cloud solo puede usar esos enlaces para llegar al destino. Esto no supone ningún problema en condiciones normales de funcionamiento, ya que el tráfico se intercambia en la región, pero es recomendable que los clientes diseñen implementaciones multirregión para tolerar los fallos regionales. Esto podría incluir la configuración de túneles y pasarelas adicionales, el emparejamiento de redes virtuales u otras topologías multirregionales en la nube de terceros.
Las aplicaciones también deben diseñarse de forma que se abran en caso de fallo, tal como recomienda el equipo de ingenieros de fiabilidad de sitios de Google en el libro de SRE. Por ejemplo, si creas una aplicación que depende de poder acceder a un servicio de terceros mediante el enrutamiento de Internet, asegúrate de que la aplicación siga funcionando o, al menos, devuelva mensajes de error útiles al usuario en caso de que haya problemas de conectividad.
Cuando se produzcan problemas con el enrutamiento de Internet, el equipo de red de Google intentará restaurar la conectividad con el tercero. Sin embargo, no todos los problemas estarán bajo el control de Google. Por lo tanto, en algunos casos, la reparación puede depender de que un tercero (proveedor de servicios de Internet o proveedor de servicios en la nube) tome medidas para restaurar el servicio. Los clientes son los que más influyen en la forma en que los operadores responden a las interrupciones, así que asegúrate de tener cobertura de asistencia con todos los proveedores y un plan para derivar los problemas si algo va mal. También se deben realizar simulacros periódicos de los procesos de continuidad empresarial para asegurar la resiliencia de las aplicaciones diseñadas en un entorno multinube.
Precios
En el caso de las transferencias de datos a través de Internet, se aplican las tarifas de salida de Internet normales al tráfico saliente de Google Cloud. En los casos en los que la latencia no sea un factor crítico, el nivel de servicio de red estándar ofrece un nivel de precios más bajo.
Los demás CSPs tienen sus propios cargos por las transferencias de datos. En muchos casos, solo cobran por el tráfico que sale de su red. Consulta la lista de precios de tu proveedor de servicios en la nube. Por ejemplo, en AWS, consulta los cargos por transferencia de datos de EC2 y, en Azure, los detalles de los precios del ancho de banda.
VPN gestionada entre proveedores de servicios en la nube
Puedes usar servicios de VPN gestionados de ambos proveedores de servicios en la nube, lo que tiene dos ventajas. Proporciona un canal cifrado entre redes virtuales en ambos entornos de nube y te permite transferir datos mediante direcciones IP privadas. Se trata de una ampliación de la solución anterior de transferencia por Internet sin necesidad de hardware ni partners.
En el siguiente diagrama se muestran los elementos de esta solución.
Con esta solución, los datos se cifran en Google Cloud mediante Cloud VPN y una solución de VPN para el otro CSP. La transferencia de datos entre Google Cloud y el otro proveedor de servicios en la nube usa Internet, como en la solución anterior.
Implementación
Google ofrece VPN de alta disponibilidad como servicio de VPN gestionado para túneles IPsec encriptados, que se pueden usar en el extremo de Google. Otros CSPs ofrecen sus propios productos de VPN gestionada, que puedes usar para crear túneles VPN IPsec entre ambos entornos. Por ejemplo, AWS ofrece VPN de sitio a sitio de AWS y Azure ofrece Azure VPN Gateway. Puedes conectar tus redes virtuales entre los entornos mediante túneles VPN.
Puedes conectarte a otro CSP usando la VPN de alta disponibilidad por sí sola o puedes configurarla como un spoke híbrido de Network Connectivity Center. Network Connectivity Center te permite conectar ubicaciones on-premise, redes de VPC y otras nubes mediante una gestión centralizada.
La VPN de alta disponibilidad no tiene integrada la función de traducción de direcciones de red (NAT). Sin embargo, puedes habilitar NAT híbrido en la conexión.
Con Cloud Router en el modo de enrutamiento dinámico global, puedes acceder a todas las regiones de una red de VPC global usando solo túneles VPN a esa región. En el caso de otros CSPs, es posible que necesites túneles VPN por región. Si tienes varias redes virtuales en un entorno de nube que no están emparejadas, debes conectar todas las redes virtuales que necesiten comunicarse entre sí de forma independiente mediante una VPN.
Google Cloud ofrece guías de interoperabilidad, que incluyen instrucciones paso a paso para configurar túneles VPN con otros proveedores de servicios en la nube importantes:
Velocidad de transferencia y latencia
Cuando usas túneles VPN gestionados, los datos siguen aproximadamente las mismas rutas de Internet que seguirían sin los túneles VPN. La latencia observada debería ser similar a la de la opción anterior, con solo una pequeña sobrecarga de latencia para los túneles VPN. El ancho de banda disponible está limitado por el ancho de banda máximo por túnel de VPN en Google Cloud, el ancho de banda máximo de los túneles de otros CSPs y el ancho de banda disponible en la ruta de Internet.
Para obtener un mayor ancho de banda, puedes implementar túneles adicionales. Para obtener más información sobre cómo implementar una solución de este tipo, consulta Topologías de VPN de alta disponibilidad para aumentar el ancho de banda.
Puedes probar la latencia y el ancho de banda tal como se describe en la última sección, pero las condiciones pueden variar con el tiempo y no hay garantías sobre la latencia ni el ancho de banda.
Seguridad
El tráfico a través de túneles VPN IPsec se cifra mediante cifrados aceptados por ambos CSPs. Para obtener más información, consulta los cifrados IKE compatibles con Cloud VPN, las preguntas frecuentes sobre AWS VPN y los parámetros IPsec/IKE de Azure VPN.
Fiabilidad y SLA
Cloud VPN ofrece un acuerdo de nivel de servicio. Otros proveedores de servicios en la nube ofrecen acuerdos de nivel de servicio en sus productos de VPN gestionados. Por ejemplo, el acuerdo de nivel de servicio de la VPN de sitio a sitio de AWS y el acuerdo de nivel de servicio de la pasarela VPN de Azure. Sin embargo, estos acuerdos de nivel de servicio solo cubren la disponibilidad de las pasarelas VPN y no incluyen la conectividad a otros proveedores de servicios en la nube a través de Internet, por lo que no hay ningún acuerdo de nivel de servicio para la solución integral.
Para aumentar la fiabilidad, puedes usar pasarelas y túneles de VPN adicionales tanto en Google Cloud como en otros proveedores de servicios en la nube.
Precios
El servicio de VPN gestionado tiene un coste. En el caso de Google Cloud, se aplica un cargo por hora. Consulta los precios de Cloud VPN. En el caso de otros CSPs, consulta sus listas de precios. Por ejemplo, consulta los precios de las conexiones VPN de sitio a sitio de AWS o los precios de las pasarelas VPN de Azure.
Además del precio por hora del servicio de VPN, tienes que pagar por los datos transferidos a través de las pasarelas de VPN. Para Google Cloud y muchos CSPs, se aplican los cargos estándar de transferencia de datos de Internet, tal como se detalla en Transferencia a través de direcciones IP externas por Internet. En muchos casos, los cargos por transferencia de datos superan el coste fijo de esta solución.
Partner Interconnect con partners que tienen habilitada la opción multinube
Partner Interconnect te permite conectar una nube privada virtual a las redes virtuales de otro proveedor de servicios en la nube a través de la red de partners seleccionados que ofrecen soluciones multinube directas. Para conectarte, debes implementar una o varias instancias de enrutamiento virtual que se encarguen de la configuración necesaria del protocolo de puerta de enlace de frontera (BGP).
En el siguiente diagrama se muestra una configuración redundante con dos conexiones de Partner Interconnect.
Las rutas se intercambian entre Cloud Router y la pasarela del otro proveedor de servicios en la nube a través de una instancia de enrutamiento virtual gestionada por el partner que proporciona la interconexión. El tráfico fluye a través de la red del partner entreGoogle Cloud y el otro CSP.
Implementación
Para usar esta solución, debes configurar varios componentes:
- En el lado de Google Cloud , configura Partner Interconnect con un proveedor de servicios de interconexión que dé servicio a tus regiones de Google Cloud y ofrezca conectividad multicloud al otro CSP.
- En la otra CSP, debes usar su producto de interconexión para conectarte al mismo partner. Por ejemplo, en AWS puedes usar Direct Connect y en Azure, ExpressRoute.
- Por parte del partner proveedor de servicios, debes configurar el equipo de enrutamiento virtual que proporciona las sesiones de BGP a Google Cloud y al otro CSP.
Puedes conectarte usando Partner Interconnect por sí solo o configurar Partner Interconnect como un radio híbrido de Network Connectivity Center. Network Connectivity Center te permite conectar ubicaciones on-premise, redes de VPC y otras nubes mediante una gestión centralizada.
Si el espacio de direcciones IP de ambos entornos de CSP se solapa, puedes habilitar Hybrid NAT en la conexión.
Velocidad de transferencia y latencia
Esta solución ofrece capacidad dedicada entre Google Cloud y otros proveedores de servicios en la nube. La capacidad de los archivos adjuntos disponibles puede variar en función del partner y del otro proveedor de servicios en la nube. Por otro lado, Google Cloud Partner Interconnect está disponible con una capacidad de vinculación de entre 50 Mbps y 50 Gbps.
La latencia de esta solución es la suma de los siguientes elementos:
- Latencia entre la región en la que se alojan tus recursos enGoogle Cloud y la ubicación de interconexión en la que se conecta el partner a Google Cloud.
- Latencia en la red de partners hacia, desde y a través de la instancia de enrutamiento virtual hacia el otro CSP.
- Latencia desde la ubicación perimetral del otro CSP en la que se produce la interconexión con el partner hasta la región en la que se alojan los recursos en el CSP.
Para conseguir la latencia más baja posible, las ubicaciones perimetrales de Google Cloud y del otro proveedor de servicios en la nube deben estar en la misma zona metropolitana, junto con la instancia de enrutamiento virtual. Por ejemplo, puedes tener una conexión de baja latencia si las regiones en la nube del proveedor de servicios en la nube, el PoP perimetral y la instancia de enrutamiento virtual se encuentran en la zona de Ashburn (Virginia).
Aunque Google Cloud y muchos otros CSPs no ofrecen garantías de latencia para el tráfico hacia el perímetro de su red, como hay una ruta y una capacidad dedicadas a través del partner, normalmente la latencia de esta solución es menos variable que si usas direcciones IP externas o una solución de VPN.
Seguridad
El tráfico a través de Partner Interconnect no se cifra de forma predeterminada. Para proteger tu tráfico, puedes implementar VPN de alta disponibilidad mediante Cloud Interconnect en el lado Google Cloud de la conexión. Otros CSPs te permiten usar su servicio de VPN gestionado a través de una interconexión. Por ejemplo, AWS Site-to-Site VPN se puede usar a través de AWS Direct Interconnect. También puede usar un dispositivo virtual que cifre el tráfico en el lado del otro proveedor de servicios en la nube.
Otra opción es cifrar el tráfico en la capa de aplicación en lugar de usar una VPN.
Fiabilidad y SLA
Esta solución incluye tres acuerdos de nivel de servicio diferentes: uno de Google, otro del partner de interconexión y otro del otro proveedor de servicios en la nube.
Cuando se usa Partner Interconnect de forma redundante, Google ofrece acuerdos de nivel de servicio mensuales del 99,9 % al 99,99% en función de la topología elegida. No hay ningún SLA en una sola conexión de interconexión de partner.
Consulta la documentación del otro CSP para ver el SLA de su producto de interconexión. Por ejemplo, el SLA de AWS Direct Connect o el SLA de ExpressRoute en Azure.
Consulta la documentación o los términos del proveedor de servicios del partner para Partner Interconnect y su acuerdo de nivel de servicio sobre la disponibilidad de la conectividad y la instancia de enrutamiento virtual. Por ejemplo, consulta el acuerdo de servicios globales de Megaport.
Precios
Por otro lado, se aplica una cuota mensual por cada vinculación de Interconnect de socio, en función del ancho de banda. Google Cloud El tráfico de salida a través de Partner Interconnect se cobra a una tarifa inferior a la del tráfico de Internet. Para obtener más información, consulta la página de precios de Partner Interconnect.
Consulta la página de precios del producto de interconexión del otro proveedor de servicios en la nube. Por ejemplo, precios de AWS Direct Connect o precios de Azure ExpressRoute. Por lo general, los precios también incluyen un cargo mensual por la interconexión y cargos por transferencia de datos a través de la interconexión a una tarifa inferior a la de Internet.
El partner cobra por los servicios de interconexión según sus propios precios, que se pueden consultar en su sitio web o solicitando un presupuesto a su equipo de ventas. Por lo general, si todas las transferencias de datos se producen en la misma zona metropolitana, los cargos son mucho más bajos que si los datos tienen que recorrer una distancia mayor en una red de partners.
Cuando los datos se transfieren con regularidad y en volúmenes suficientemente altos, esta solución puede ofrecer el coste total más bajo en función de los precios del otro proveedor de servicios en la nube, debido a las tarifas de salida con descuento. Incluso si se añaden los costes mensuales de la interconexión de Partner Interconnect, el otro proveedor de servicios en la nube y el partner proveedor de servicios, usar esta solución puede suponer un ahorro considerable. Como los precios de los partners y otros proveedores de servicios en la nube pueden cambiar sin previo aviso, haz tu propia comparación con las cotizaciones actualizadas de todas las partes implicadas.
Interconexión dedicada a través de un PoP común
Si usas uno o varios dispositivos de enrutamiento físicos en una instalación de interconexión común entre Google Cloud y el otro proveedor de servicios en la nube, puedes conectar ambos proveedores de servicios en la nube mediante una interconexión dedicada en el lado deGoogle Cloud y un producto equivalente en el otro proveedor de servicios en la nube. La ubicación de la interconexión no tiene por qué ser la misma que la de la región en la que se encuentran tus recursos.
En el siguiente diagrama se muestra una configuración redundante con dos conexiones de interconexión dedicada:
Las rutas se intercambian entre Cloud Router y la pasarela del otro proveedor de servicios en la nube a través de un router físico que colocas en una instalación de interconexión común. El tráfico fluye a través de este router entre Google Cloud y el otro CSP.
Implementación
Esta solución requiere que alojes y mantengas dispositivos de enrutamiento físicos en un centro de colocación donde estén presentes Google y el proveedor de servicios en la nube al que quieras conectarte. Desde este dispositivo de enrutamiento, solicita dos conexiones físicas con la instalación: una hacia Google Cloud mediante Interconexión dedicada y otra hacia el otro proveedor de servicios mediante un producto equivalente, como AWS Direct Connect o Azure ExpressRoute. En tu dispositivo de enrutamiento, debes configurar el BGP para permitir el intercambio de rutas entre los dos entornos de nube.
Consulta la lista de ubicaciones de las instalaciones de colocación Google Cloud y tu otro proveedor de servicios en la nube, por ejemplo, las ubicaciones de AWS Direct Connect o las ubicaciones de emparejamiento de Azure ExpressRoute, para identificar las ubicaciones adecuadas para esta configuración.
Puedes conectarte usando una interconexión dedicada o configurarla como un radio híbrido de Network Connectivity Center. Network Connectivity Center te permite conectar ubicaciones on-premise, redes de VPC y otras nubes mediante una gestión centralizada.
Si el espacio de direcciones IP de ambos entornos de CSP se solapa, puedes habilitar Hybrid NAT en la conexión.
Esta solución es eficaz si utilizas la conectividad dedicada para conectarte también a tu entorno local, además de a otro proveedor de servicios en la nube.
En otros casos, esta solución es compleja porque requiere que tengas y mantengas equipos físicos, así como un contrato con un centro de colocación. Solo recomendamos esta solución si se cumple al menos una de las siguientes condiciones:
- Ya tienes equipos en unas instalaciones adecuadas para otro fin y un contrato con esas instalaciones.
- Transfiere grandes cantidades de datos con regularidad, por lo que esta opción es rentable, o bien tiene requisitos de ancho de banda que los partners no pueden cumplir.
Velocidad de transferencia y latencia
Esta solución ofrece capacidad dedicada entre Google Cloud y otro proveedor de servicios en la nube. Por otro lado, la interconexión dedicada está disponible mediante una o varias conexiones físicas de 10 o 100 Gbps. Google Cloud
La latencia de esta solución es la suma de los siguientes elementos:
- Latencia entre la región en la que se alojan tus recursos enGoogle Cloud y la ubicación de interconexión en la que te interconectas conGoogle Cloud.
- Latencia a través de las instalaciones y tu equipo físico, que suele ser insignificante en comparación con la latencia debida a la longitud de la fibra.
- 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 del CSP.
Aunque no se ofrecen garantías de latencia, esta solución suele permitir 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 a través de la interconexión dedicada no se cifra de forma predeterminada. Para proteger tu tráfico, puedes implementar VPN de alta disponibilidad mediante Cloud Interconnect en el lado de Google Cloud de la conexión. Otros CSPs te permiten usar su servicio de VPN gestionado a través de una interconexión. Por ejemplo, AWS Site-to-Site VPN se puede usar a través de AWS Direct Interconnect. También puede usar un dispositivo virtual que cifre el tráfico en el lado del otro proveedor de servicios en la nube.
Otra opción es cifrar el tráfico en la capa de aplicación en lugar de usar una VPN.
Fiabilidad y SLA
Cuando se usa la interconexión dedicada de forma redundante, Google ofrece acuerdos de nivel de servicio mensuales del 99,9 % al 99,99% en función de la topología elegida. No hay ningún SLA para una sola conexión de interconexión dedicada.
Para obtener más información, consulta la documentación del otro proveedor de servicios de configuración sobre el acuerdo de nivel de servicio de su producto de interconexión. Por ejemplo, el acuerdo de nivel de servicio de AWS Direct Connect o el acuerdo de nivel de servicio de Azure para ExpressRoute.
El centro de colocación o el proveedor de hardware del equipo de enrutamiento físico también pueden ofrecer acuerdos de nivel de servicio en sus servicios.
Precios
Por otro lado, se cobra una cuota mensual por cada puerto de Interconexión Dedicada, así como por cada vinculación de VLAN que se conecte a un entorno de VPC. Google Cloud El tráfico de salida a través de Dedicated Interconnect se cobra a una tarifa inferior a la del tráfico de Internet. Para obtener más información, consulta la página de precios de Dedicated Interconnect.
Consulta la página de precios del producto de interconexión del otro proveedor de servicios en la nube. Por ejemplo, precios de AWS Direct Connect o precios de Azure ExpressRoute. Por lo general, los precios también incluyen un cargo mensual por la interconexión y cargos por transferencia de datos a través de la interconexión a una tarifa inferior a la de Internet.
Además, debes tener en cuenta los cargos por los servicios de las instalaciones de colocación que proporcionan espacio, energía eléctrica y conexiones físicas a ambos entornos de nube, así como los costes y los contratos de servicios continuos con el proveedor del equipo de enrutamiento físico. Si la conexión entre ambos CSPs no se puede realizar en la misma instalación y necesitas adquirir conectividad entre instalaciones, los precios de estos servicios pueden ser mucho más altos.
Conexiones gestionadas de Cross-Cloud Interconnect
Puedes conectar tus Google Cloud redes de VPC a tus redes virtuales de otro proveedor de servicios en la nube a través de la estructura de red de Google. En cierto modo, esta configuración funciona como Partner Interconnect, pero con el SLA de Google que cubre tanto las redes de Google como las interconexiones.
En el siguiente diagrama se muestra una configuración de Cross-Cloud Interconnect con el número mínimo de conexiones.
Las rutas se intercambian entre Cloud Router y la pasarela del otro proveedor de servicios en la nube a través de la estructura de 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 emparejar tu red de nube privada virtual (VPC) con una red alojada por un proveedor de servicios en la nube compatible. Google Cloud
Una vez que hayas aprovisionado la conexión, Google la admitirá hasta que llegue 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 todo el servicio y te avisará si tienes que abrir un caso de asistencia con el otro CSP.
Para aplicar esta solución, debes seguir el proceso de configuración de la otra CSP, lo que incluye elegir dónde se van a interconectar las dos redes. Solo se admiten determinados CSPs.
Puedes conectarte mediante Cross-Cloud Interconnect por sí solo o configurarlo como un radio híbrido de Network Connectivity Center. Network Connectivity Center te permite conectar ubicaciones on-premise, redes de VPC y otras nubes mediante una gestión centralizada.
Si el espacio de direcciones IP de ambos entornos de CSP se solapa, puedes habilitar Hybrid NAT en la conexión.
Velocidad de transferencia y latencia
Esta solución ofrece capacidad dedicada entre Google Cloud y otro proveedor de servicios en la nube. Por parte de Google Cloud , la interconexión dedicada está disponible mediante el uso de uno o varios pares de conexiones físicas de 10 o 100 Gbps.
La latencia de esta solución es la suma de los siguientes elementos:
- Latencia entre la región en la que se alojan tus recursos en Google Cloud y la ubicación multicloud.
- Latencia entre la ubicación perimetral de Google y la ubicación perimetral del otro proveedor de servicios en la nube (a menudo en la misma instalación)
- Latencia desde la ubicación perimetral del otro CSP en la que se ha desplegado Cross-Cloud Interconnect hasta la región en la que se alojan los recursos en el CSP.
Aunque no se ofrecen garantías de latencia, esta solución suele permitir la latencia más baja posible y las velocidades de transferencia más altas posibles entreGoogle Cloud y otros entornos de nube a través de direcciones IP privadas.
Seguridad
Como el tráfico a través de Cross-Cloud Interconnect no está cifrado, te recomendamos que uses el cifrado de la capa de aplicación para el tráfico sensible.
Si todo el tráfico debe cifrarse, los dispositivos virtuales que ofrecen los Google Cloud partners en Cloud Marketplace pueden proporcionar soluciones para cifrar el tráfico al entorno de otro CSP.
Fiabilidad y SLA
Cross-Cloud Interconnect usa el SLA de Cloud Interconnect. Para cumplir los requisitos del ANS, tu configuración de Cross-Cloud Interconnect debe usar uno o varios pares de conexiones, tal como se describe en la sección Acuerdo de nivel de servicio del artículo de descripción general de Cross-Cloud Interconnect.
El SLA cubre todo lo que se encuentra en el lado de Google hasta el límite de la red del otro proveedor de servicios en la nube. No cubre la red del otro proveedor de servicios en la nube. Para obtener más información, consulta la documentación del otro CSP sobre el acuerdo de nivel de servicio de su producto de interconexión. Por ejemplo, el acuerdo de nivel de servicio de AWS Direct Connect o el acuerdo de nivel de servicio de Azure para ExpressRoute.
Precios
Se aplica una tarifa por hora por cada conexión de Cross-Cloud Interconnect, así como por cada vinculación 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 inferior a la del tráfico de Internet. Para obtener más información, consulta los precios de Cross-Cloud Interconnect.
Consulta la página de precios del producto de interconexión del otro proveedor de servicios en la nube. Por ejemplo, precios de AWS Direct Connect o precios de Azure ExpressRoute. Normalmente, la interconexión tiene un coste mensual. Los cargos por transferencia de datos a través de la interconexión suelen ser inferiores a los cargos por transferencia de datos a través de Internet.
No hay costes independientes para las ubicaciones de interconexión ni para el equipo.
Comparación de opciones
Las opciones presentadas varían en cuanto a velocidad, disponibilidad, complejidad, seguridad y precios. Debe evaluar todas las opciones detenidamente según sus necesidades.
En el siguiente diagrama de flujo se muestra el proceso para elegir una de las soluciones mencionadas en este documento.
Normalmente, podemos recomendar las siguientes opciones:
- En muchos casos en los que los datos se intercambian de forma ocasional o en volúmenes bajos y las transferencias no son críticas, transferir datos a través de Internet es la opción más sencilla y sigue ofreciendo una latencia relativamente baja y un ancho de banda alto.
- Si se requiere el cifrado o la transferencia de cantidades más pequeñas de datos mediante direcciones IP privadas, considera la posibilidad de usar Cloud VPN y un servicio de VPN gestionado en el otro CSP.
- Si transfieres grandes cantidades de datos, usar Partner Interconnect con un partner multicloud te ofrece varias ventajas: capacidad dedicada, menor coste de las transferencias de datos y, en función de la topología, un SLA para cada parte de la solución. La capacidad de Partner Interconnect suele ser inferior a 10 Gbps por conexión.
- Si conectas tu equipo local a varias nubes, una opción habitual es usar Interconexión dedicada a través de un PoP común. Esto conlleva una mayor complejidad a la hora de gestionar tu propio hardware y las relaciones con un centro de colocación. A menos que ya tengas la infraestructura necesaria, esta solución solo se puede aplicar en los casos en los que las velocidades de transferencia de datos típicas sean de 10 Gbps o más.
- Si no quieres tener que gestionar las interconexiones y los equipos de enrutamiento en los PoPs remotos, Cross-Cloud Interconnect te ofrece una solución gestionada en la que Google se encarga de todo.
Siguientes pasos
- Consulta la serie sobre patrones y prácticas de nube híbrida y multinube.
- Consulta arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Centro de arquitectura de Cloud.