La migración de recursos TI a la nube pública es una decisión estratégica para las empresas hoy en día. En la mayoría de los casos no se migran todos los recursos de TI (servidores, almacenamiento, aplicaciones, etc.), es decir, algunos permanecen en las instalaciones (en un centro de datos de la empresa, en una nube privada o en un hosting).
En muchos casos, puede ser necesario conectar los recursos trasladados a la nube pública con los que permanecen en las instalaciones y existen muchas opciones según el proveedor de la nube y la tecnología existente.
- El panorama
La necesidad de tener aplicaciones/soluciones que tengan componentes interactivos en las instalaciones (es decir, el centro de datos) y en las nubes públicas (es decir, AWS) brinda a las empresas una gran flexibilidad y opciones de implementación de datos. Este enfoque híbrido aporta beneficios, pero también presenta desafíos técnicos, comerciales y de gestión. Los aspectos clave que deben considerarse incluyen la seguridad y una “conexión” de red sólida porque los componentes de las aplicaciones deben poder comunicarse entre sí a través de un canal confiable, rápido y seguro. En algunos casos, existen requisitos estrictos en términos de latencia, seguridad, etc.
Esta “conexión” generalmente se realiza mediante una ruta segura a través de Internet, como se muestra en la figura 1. Como se ve, los datos entre la “puerta de enlace VPN” en la nube y el enrutador prometido están cifrados, pero el enlace no está dedicado. Es decir, se utiliza Internet, que a veces se queda corto en términos de velocidad, latencia, seguridad y manejabilidad.
La buena noticia es que los proveedores de nube pública (como AWS, Azure y GCP) ofrecen la posibilidad de establecer una conexión de red dedicada y resistente entre sus recursos locales y en la nube mediante enlaces WAN privados, como se muestra en la Figura 2. Es decir, la nube El proveedor “extiende” su alcance a los clientes al tener un punto de presencia (POP), generalmente ubicado en el centro de datos de un ISP. AWS lo llama Direct Connect (DX), Azure lo llama ExpressRoute y GCP de Google lo llama Dedicated Interconnect.
- Conexión a recursos en AWS - Direct Connect
AWS Direct Connect (DX) permite establecer un enlace de red dedicado entre sus recursos locales (en la oficina corporativa o el centro de datos) y los recursos en la nube de AWS.
En este caso, se conecta a una ubicación de socio de Direct Connect, generalmente un proveedor de servicios de Internet (ISP) donde AWS tiene recursos, y obtiene acceso a la nube de AWS dentro de esa región geográfica específica de AWS. La conexión se realiza mediante un troncal 802.1q entre su centro de datos y el ISP, lo que permite utilizar VLAN para tener una separación lógica entre los recursos de la nube pública y privada. Hay dos sabores de DX:
- Dedicado: pedido directamente desde AWS, con velocidades de 1 Gbps o 10 Gbps
- Alojado: pedido a un socio de AWS DX, con velocidades de 50 M a 10 Gbps.
- Microsoft Azure ExpressRoute
ExpressRoute de Microsoft funciona como una extensión de una red privada para cualquiera de los servicios en la nube de Microsoft, incluidos Azure y Office365.
De manera similar a AWS, se conecta a una ubicación de emparejamiento (peering) de ExpressRoute mediante una conexión redundante de capa 3 (a diferencia de la capa 2). También utiliza BGP para intercambiar rutas entre Azure y la red del cliente. Las opciones de ancho de banda admitidas son similares a las de AWS. Con ExpressRoute Premium puede extender la conectividad a toda una frontera geopolítica, como América del Norte, y no solo a una región.
- Google Dedicated Interconnect
La interconexión dedicada a la nube GCP de Google está disponible en muchas ubicaciones globales y admite velocidades desde 10 Gbps hasta 100 Gbps. Por defecto permite el acceso a toda la red global de la nube. Para el aprovisionamiento, conecta su enrutador “cliente” a un Google Cloud Router en una instalación de colocación común y configura BGP para intercambiar información de enrutamiento.
- Escenario de la vida real con Direct Connect de AWS
Para ilustrar el uso de Direct Connect, usemos un escenario de la vida real que tuvimos recientemente con uno de nuestros clientes:
Resumen de requisitos:
- El cliente tiene cargas de trabajo en EE. UU. en una región de AWS específica. Estas cargas de trabajo se ejecutan en servidores virtuales (EC2) y EKS (servicio Kubernetes administrado por AWS para contenedores).
- El cliente tiene operaciones en Europa, donde tiene un pequeño centro de datos.
- Las aplicaciones que se ejecutan en EC2 y EKS en EE. UU. necesitaban comunicarse con las aplicaciones que se ejecutan en servidores remotos en Europa (diferente región de AWS).
- El cliente quería tener una conectividad segura, resistente y de 200 Mbps entre los recursos de AWS en EE. UU. y el centro de datos en Europa. El ISP local en Europa es socio de AWS que proporciona servicio DX alojado con esta velocidad, así como conectividad desde sus instalaciones hasta el datacenter del cliente mediante una red MPLS.
- El tráfico debía cifrarse mediante una opción de túnel VPN específica implementada en los enrutadores Cisco.
- Las máquinas EKS (workers) utilizaban direccionamiento privado.
Direct Connect se puede utilizar con múltiples casos de uso.
- Descripción general de la solución
Para cumplir con los estrictos requisitos de conectividad entre ubicaciones, era necesario tener una conexión de red dedicada desde el punto de presencia (POP) de AWS y el centro de datos del cliente en Europa. Es decir, un circuito privado del ISP local (AWS Direct Connect POP) y el sitio de nuestro cliente. Se ordenó un Hosted DX con 200 Mbps para cumplir con los requisitos.
On the other hand, in order to comply with specific traffic encryption requirements, it was necessary to implement a VPN using a virtual Cisco Router (CSR) on AWS. On this virtual device terminated the VPN tunnels established between AWS and the remote datacenter. The details are covered later.
Finally, the private addressing used by EKS’ workers, required to implement NAT and other advanced networking functionality available on AWS. This machines had private addressing but also needed to communicate to the internet for specific functionality related to EKS, outside of the scope of this article.
- Detalles de Direct Connect (DX)
Para que DX funcione, se establece un enlace de Capa 2 (utilizando un troncal 802.1q) entre su centro de datos y un punto final de AWS (también conocido como enrutador DX) ubicado junto al ISP. Este tronco puede tener múltiples VLAN, lo que permite usar la misma conexión para acceder a recursos públicos (es decir, Amazon S3, Glacier) utilizando el espacio de direcciones IP públicas y recursos privados (es decir, instancias EC2, EKS, etc.) que se ejecutan dentro de una nube privada virtual de Amazon ( VPC) utilizando espacio IP privado, manteniendo al mismo tiempo la separación de la red entre los entornos público y privado. El siguiente diagrama muestra estos componentes:
Estas VLAN terminan en interfaces virtuales (VIF) en el enrutador DX ubicado junto al ISP. Hay una VIF para cada VLAN. Dado que nuestro cliente solo necesitaba servidores remotos para acceder a los dispositivos dentro de la VPC (direccionamiento IP privado), solo se necesitaba el VIF privado.
BGP es el protocolo utilizado para intercambiar rutas entre DX y el centro de datos del cliente. Específicamente, se configuró una sesión BGP externa (eBGP) (utilizando AWS VIF y la IP del enrutador del cliente), para intercambiar rutas entre los Sistemas Autónomos (AS) de AWS y los AS de la red del Cliente.
Como se mencionó anteriormente, existen dos tipos de DX: dedicado y alojado que permiten tener varias combinaciones que incluyen:
Dedicado: Solicitado directamente desde AWS, con velocidades de 1 Gbps o 10 Gbps y compatibilidad con múltiples interfaces virtuales
Puede agrupar varios puertos 1G o 10G en una única conexión administrada llamada LAG (agregación de enlaces) que equilibrará la carga del tráfico a través de los enlaces, por flujo. Puede tener hasta 4 enlaces en un LAG.
Alojado: Proporcionado por un socio de AWS (ISP). El ISP solicita una conexión de 1G o 10G a AWS y luego puede ofrecerla a múltiples clientes finales, asignando fragmentos de 50M a 10Gbps.
Soporta una única interfaz virtual.
Debido a los requisitos, se utilizó un DX alojado. Dado que esto se solicitó a un ISP, se debía seguir un procedimiento específico. El procedimiento se trata en: https://docs.aws.amazon.com/directconnect/latest/UserGuide/WorkingWithConnections.html
Tenga en cuenta que existen múltiples opciones para la conectividad física al servicio DX:
- Presencia del cliente en la misma ubicación de DX
- Circuito entre el centro de datos del cliente y la ubicación DX
- Red de proveedores de servicios que se extiende hasta la ubicación DX
Para nuestro caso particular, el proveedor de servicios amplió su red utilizando MPLS. En estos casos, el ISP suele encargarse de esta configuración porque es un servicio alojado en DX.
El procedimiento para solicitar y configurar Direct Connect, así como para configurar el enrutador en el centro de datos del Cliente, fue sencillo y está bien cubierto en la documentación de AWS que se encuentra en: https://docs.aws.amazon.com/directconnect/
- VPN para cifrado de datos
AWS ofrece la posibilidad de configurar una Red Privada Virtual (VPN) de sitio a sitio utilizando el protocolo IPSEC. Esta VPN permite conectar de forma segura la red local o el sitio de la sucursal a su Amazon Virtual Private Cloud (Amazon VPC).
Para terminar los túneles VPN en AWS, normalmente se utiliza una puerta de enlace privada virtual de AWS, un dispositivo virtual de borde distribuido, lógico y totalmente redundante que se encuentra en el borde de su VPC. Como es capaz de terminar conexiones VPN desde sus entornos locales o de cliente, el VPG es el concentrador de VPN en el lado de Amazon de la conexión VPN de sitio a sitio.
También tiene la opción de terminar el túnel VPN en un dispositivo virtual en AWS como el Cisco Cloud Services Router (CSR) 1000V. Este es un enrutador que se ejecuta en una máquina virtual (EC2) y está configurado de manera similar a como configura un enrutador físico de Cisco. El rendimiento del CSR1000V depende del tamaño de la máquina EC2 que utilice.
Para nuestro escenario específico, fue necesario implementar una solución VPN IPSEC redundante compuesta por dos túneles (para mayor confiabilidad) entre el centro de datos en Europa y la ubicación de DX. Requisitos específicos del cliente y del proveedor de servicios determinados a utilizar un Cisco Cloud Service Router (CSR) 1000V.
- Consideraciones adicionales sobre redes en la nube
La combinación de múltiples funcionalidades como soporte VPN con CSR1000V, EKS con direccionamiento privado, etc. implica tener una VPC con subredes públicas y privadas y acceso VPN de sitio a sitio de AWS, e implementar funciones de red avanzadas disponibles en AWS como NAT y tablas de rutas personalizadas. , Listas de Acceso y seguridad. Estos temas se tratarán en otro artículo.
- Conclusión
Los proveedores de la nube han “extendido” sus redes a centros de datos de ISP específicos desde donde es posible tener enlaces dedicados que ofrecen una comunicación confiable, rápida y segura a la nube. La implementación de un enfoque de nube híbrida podría requerir el uso de estos enlaces para cumplir con los requisitos del cliente. Este servicio puede tener un nombre diferente según el proveedor de la nube: Direct Connect de AWS, ExpressRoute de Azure y Dedicated Interconnect de Google GCP. Su implementación abre la puerta a múltiples opciones y características de seguridad, alta disponibilidad y implementación de redes avanzadas.
Necesita ayuda con las redes de nube híbrida?
Póngase en contacto con nosotros hoy para una consulta gratuita.
