Tres formas de conectar sus entornos AWS y Microsoft Azure

En un momento en que las arquitecturas de nube híbrida y multinube se están convirtiendo en la norma de las redes empresariales, analizamos tres formas de conectar las cargas de trabajo de las VPC de AWS con las VNets de Microsoft Azure.

Las arquitecturas de nube híbrida y multinube se han convertido en algo habitual para los departamentos de TI de las empresas que buscan una mayor fiabilidad, seguridad y rentabilidad de la red con el fin de favorecer el rendimiento óptimo de las aplicaciones. A medida que cada vez más cargas de trabajo empresariales migran a la nube, es natural que las organizaciones busquen formas de conectar AWS y Microsoft Azure, los dos principales hiperescaladores, para preparar su red para el futuro y garantizar la mínima latencia entre las cargas de trabajo.

Pongamos que usted es como uno de nuestros clientes, una marca minorista internacional que aloja su comercio electrónico en AWS y Azure, con copias de las aplicaciones desplegadas en ambas nubes. Para cumplir con su política de seguridad, envía por red de retorno o backhaul parte del tráfico a su centro de datos, donde se aplica esta política, pero no todo su tráfico tiene que estar sujeto a ella. Para ahorrar recursos de red en su centro de datos, desea mantener el tráfico restante en el perímetro de cada nube, y disminuir así la latencia entre AWS y Azure.

En este caso, hay tres formas de conectar un entorno de AWS a uno de Microsoft Azure, cada una con sus ventajas e inconvenientes. El túnel VPN es con gran diferencia el método más común, pero como sabrá si lee este blog con regularidad, no es el mejor.

1. Establecer túneles VPN

Hay multitud de recursos en línea en los que se explica cómo establecer un túnel VPN a través de una conexión pública de Internet entre AWS y Microsoft Azure. Es un método tradicional probado para conectar nubes, pero presenta muchos inconvenientes; entre otros, los siguientes:

Inconveniente: rendimiento limitado

Para mayores cargas de trabajo de computación, deberá configurar numerosos túneles para obtener el rendimiento que necesita. También es probable que tenga que dedicar mucho tiempo a gestionar el enrutamiento ECMP multi-path routing,place in routing metric calculations.) (Equal-Cost Multi-Path) o el equilibrio de carga para asegurarse de que el ancho de banda necesario sigue disponible, y de que los túneles VPN no se sobrecargan y fallan.

Inconveniente: enrutamiento impredecible a través de la Internet pública

Cualquiera que se haya conectado alguna vez a su estación de trabajo con un token VPN sabe de primera mano que la transferencia de datos a través de la Internet pública, por un túnel VPN, puede ser problemática. Esto se debe a que los protocolos de enrutamiento en Internet tienen un comportamiento complejo e incoherente, por lo que el control que se tiene sobre las rutas que recorren los paquetes de datos es limitado. Un enrutamiento impredecible implica una mayor latencia, lo que se traduce en un menor rendimiento de las aplicaciones.

He escrito sobre esto con anterioridad para el ONUG, con el fin de abordar el enrutamiento virtual perimetral.

Inconveniente: seguridad comprometida debido al secuestro de rutas BGP

Año tras año, la incidencia de los ciberataques sigue aumentando. Ahora más que nunca, la ciberseguridad es una preocupación que quita el sueño a los directores de TI.

La confianza en la que está basado el funcionamiento del protocolo de puerta de enlace de borde (BGP) es lo que hace que Internet sea tan escalable y, al mismo tiempo, tan vulnerable a los ataques de secuestro de rutas. El BGP cuenta con sistemas automáticos como los ISP para anunciar las rutas a los bloques de direcciones IP. Los ciberdelincuentes pueden secuestrar estos anuncios y redirigir el tráfico a «agujeros negros» o, en el caso del ataque ruso de 2018 al sitio de criptomonedas MyEtherWallet, a un sitio de phishing que recopilaba información de cuentas para robar 152 000 USD.

Inconveniente: costes por transferencia de datos de AWS y Azure

Tal vez, el mayor problema de conectar entornos de nube mediante túneles VPN sean los costes por transferencia de los datos que salen de cada entorno y atraviesan la Internet pública de vuelta a los servidores locales o ubicados en un centro de datos. Esto también se aplica al enrutamiento de datos entre entornos privados en la nube pública, cuando el tráfico fluye de una nube a otra. Los proveedores de nube aplican estas tarifas por GB a la salida.

Encontrará más información sobre los precios de transferencia de AWS y Azure aquí y aquí. AWS ofrece incluso una útil herramienta llamada Cost Explorer con la que puede analizar sus costes por transferencia de datos.

Estos precios pueden ser prohibitivos; en el caso de uno de nuestros clientes, los costes potenciales de salida ascendían a 43 000 USD al mes antes de contar con Megaport.

Más información sobre la reducción de costes con AWS.

2. Establecer líneas privadas

La segunda forma de conectar sus entornos AWS y Azure es establecer líneas privadas para conectarse a los dos hiperescaladores comprando circuitos específicos a su proveedor de telecomunicaciones. Estos circuitos proporcionan una conexión privada a los proveedores de nube de modo que el tráfico no se enrute a través de la impredecible y vulnerable Internet pública.

Pero este enfoque también presenta muchas desventajas:

Inconveniente: más costoso con contratos a largo plazo

Probablemente su empresa de telecomunicaciones le exigirá firmar contratos de 18 a 24 meses para los circuitos específicos, con plazos de instalación de 45 a 90 días. Por tanto, si quisiera aumentar la capacidad de ancho de banda, podría tardar meses, y si quisiera reducirla, tendría que vivir con circuitos sin usar debido a estos contratos a largo plazo.

Al final, el establecimiento de redes privadas es probablemente la opción más costosa para conectar AWS y Microsoft Azure.

Inconveniente: la latencia sigue siendo un problema debido al tráfico de backhaul

Incluso con circuitos privados a cada nube, tendrá que enviar el tráfico por backhaul a su centro de datos o al equipo de enrutamiento local. En otras palabras, sus datos tendrán que salir de AWS para recorrer su conexión privada de vuelta a su entorno local o de coubicación, y después recorrer de nuevo su otra conexión privada a su entorno de Microsoft Azure, si quiere que las cargas de trabajo de ambos entornos intercambien datos. En consecuencia, la latencia seguirá suponiendo un problema, aunque es probable que sus circuitos privados a AWS y Microsoft Azure le ofrezcan más fiabilidad que un túnel VPN.

Inconveniente: gastos de capital adicionales por la capacidad WAN

Incluso con sus propias conexiones privadas a los hiperescaladores, seguirá necesitando una infraestructura local o una presencia de coubicación considerable, lo que por supuesto se traduce en más gastos de capital que contabilizar en el presupuesto anual.

3. Establecer una conectividad privada con un enrutador virtual (como Megaport Cloud Router)

Aunque la forma más habitual de conectar las cargas de trabajo a diferentes entornos de nube es establecer un túnel VPN, una forma cada vez más común es establecer una conectividad privada con un enrutador virtual, como Megaport Cloud Router (MCR).

Con MCR, disfrutará de una conectividad privada con la seguridad, fiabilidad y menores costes que conlleva no tener que enviar datos a través de la Internet pública. Además, no tendrá que:

• desviar el tráfico de vuelta a su entorno local;
• firmar contratos a largo plazo con su proveedor de telecomunicaciones;
• añadir equipo adicional para mejorar la conectividad; ni
• pagar elevados costes por la transferencia de datos desde AWS y Azure que atraviesan Internet.

Si quiere aumentar su ancho de banda, puede hacerlo con solo unos clics en la red definida por software (SDN) a la carta global de Megaport, o incluso automatizar cambios de capacidad en nuestra API. MCR se instala en la ubicación física donde residen los perímetros de AWS y Microsoft Azure. En algunos casos, MCR y ambos proveedores de servicios en la nube están disponibles en el mismo campus de centro de datos.

Volvamos a suponer que es usted una marca minorista internacional cliente nuestra. Su tienda de comercio electrónico está alojada en AWS en la región de EE. UU. Este (Norte de Virginia), con aplicaciones en Azure en la región de EE. UU. Este. Desea enrutar datos directamente entre las dos nubes, pero también conservar la capacidad de gestionar un par primario y secundario de vuelta a su centro de datos del área de Washington D. C. con el fin de gestionar su política de seguridad.

MCR simplifica este enrutamiento del tráfico de vuelta al centro de datos para la comprobación de seguridad; puede mantener un único par entre su centro de datos y MCR. No necesita más pares en el centro de datos para añadir más enlaces de nube porque puede gestionar fácilmente estos pares en sus MCR.

Además, la latencia entre los dos entornos de nube, entre los que existe una conexión privada gracias a nuestro enrutador virtual, es de solo tres o cuatro milisegundos de ida y vuelta. Esta ruta de mínima latencia entre AWS y Azure, habilitada por la conexión directa de MCR, se traduce en un rendimiento óptimo de las aplicaciones.

Para obtener más información sobre cómo Megaport Cloud Router puede ayudarle a conectar AWS y Azure, haga clic aquí.