Comparación de AWS, Azure y GCP (II): Redes
Publicado por Jose Antonio Navarro Fuentes el
Arquitectura de SolucionesAtlassian CloudAmazon AWSAzureGCPRedesSubredes
Este segundo artículo de la serie que comenzó con
Se va a centrar en un aspecto fundamental a la hora de definir correctamente la transformación a la nube, es el uso y gestión de las herramientas que permiten la correcta administración de las redes.
De una forma muy simplificada podemos entender las redes como la forma en que los recursos y los servicios se comunican entre sí.
Y de forma más ampliada los servicios de red definen la estructura interna de las plataformas cloud y conectan todos sus recursos y servicios entre sí además de proteger, entregar y supervisar las aplicaciones.
El cambio principal que observamos con respecto al modelo de red tradicional es que las plataformas cloud se sustentan en una red virtual. Es esta red virtual a la que los servicios se conectan y usan para comunicarse entre sí.
- En Azure esta red se llama VNet (Red Virtual-Virtual Network).
- En AWS y GCP esta red se llama VPC (Nube Privada Virtual-Virtual Private Cloud).
En los tres casos contienen una o más subredes que permiten la comunicación entre recursos y otras subredes.
Para definir correctamente la organización de red se debe conocer la organización de redes-subredes, la forma de comunicación existente dentro de una red, y entre diferentes redes dentro y fuera del ámbito de la plataforma cloud y como asegurar esta comunicación.
Analizaremos el concepto de emparejamiento de redes, y el de tabla de rutas, donde una ruta es un mapeo de un rango de IP a un destino, que permiten definir una secuencia de saltos sucesivos para canalizar la comunicación.
Para facilitar el análisis los diferentes recursos de redes ofrecidos pueden clasificarse en dos categorías.
- Servicios de red y conectividad.
- Servicios de seguridad.
Servicios de red y conectividad
Tal como comenté en el artículo anterior Comparación de AWS, Azure y GCP (I): Conceptos generales, las tres nubes manejan los conceptos de región y zona de disponibilidad, la forma en que los servicios de red utilizan las regiones son similares entre Azure y AWS, y diferente en GCP.
AWS
AWS, crea una VPC en una región. Una VPC es una red virtual lógicamente aislada que se crea en una región de AWS y abarca todas las zonas de disponibilidad de la región, existen subredes dentro de estas zonas de disponibilidad.
En una AWS VPC hay dos tipos de subredes, una subred pública que tiene acceso a internet y una subred privada que no lo tiene.
De forma predeterminada, todos los recursos o instancias conectadas a una VPC pueden comunicarse dentro de la VPC.
Hay dos tipos de VPC en AWS:
La VPC "predeterminada" es una red que se crea automáticamente la primera vez que se aprovisionan los recursos de la cuenta. Tiene una dirección IP pública (acceso a Internet) por defecto y se utiliza para el aprovisionamiento rápido de los servicios. Solo es posible una VPC "predeterminada".
La VPC "no predeterminada" viene solo con una dirección IP privada, la crea el cliente, y debe configurarse antes de poder usar. Se permiten 5 redes de tipo "no predeterminada" por región.
AWS ofrece subredes mínimas de tipo /28 y máximas de tipo /16 para IPv4 y subredes fijas /64 para IPv6. AWS se reserva las cuatro primeras direcciones IP y la última de cada subred.
Azure
Con Azure, la red virtual o VNet existe en una región. Las subredes se agregan a la red virtual y los recursos se asignan a la subred, todos los recursos en una red virtual pueden comunicarse entre sí de forma predeterminada, incluidos los recursos en diferentes subredes. Cada red virtual tiene un intervalo de direcciones IP que se especifica cuando se crea la red virtual. Azure ofrece un único tipo de red virtual.
La VNet tiene acceso a Internet por defecto. Un recurso debe estar en la misma región que la red virtual para conectar a esa subred. Si se requiere redundancia para alta disponibilidad, se implementa otra red virtual en una región diferente.
El alcance de la subred puede abarcar toda la región al igual que la red virtual y las direcciones IP indicadas para la subred deben ser un subconjunto del rango de direcciones IP definidas para la red virtual.
El tamaño mínimo de la subred es /29 mientras que el máximo es /8 para IPv4 mientras que tienen una subred fija de /64 para IPv6. Azure reserva 5 direcciones IP (las primeras 4 y la última) en cada subred para sus propias operaciones.
GCP
Adopta un enfoque diferente para las redes con una implementación de VPC global, abarcando varias regiones y no está asociada con ninguna región específica. Cuando se crea una red de VPC global, se crean subredes por el sistema en cada región de GCP. Las subredes son específicas de la región.
GCP ofrece dos tipos de redes de VPC, determinadas por su modo de creación de subred:
Con el modo automático, GCP asignará automáticamente las direcciones IP para las subredes en cada región, mientras que la VPC personalizada permitirá que el usuario elija las IP para cada subred. El inconveniente del modo automático es que, si se tienen varias VPC y se necesita emparejarlas, no será posible ya que tendrán los mismos rangos de direcciones IP en las diferentes subredes.
Los rangos de direcciones IP no están definidos en el nivel de VPC, cada subred puede tener asignado cualquier rango de direcciones IP.
La subred mínima admitida por GCP es /29 mientras que la máxima es /8 teniendo una subred fija de /64 para IPv6. GCP reserva 4 direcciones IP (las dos primeras y las dos últimas) en cada subred.
Intercambio de tráfico y puertas de enlace (gateways)
Ahora que comprendemos las redes y subredes de cada proveedor, veamos cómo podemos conectarlas para poder comunicar los servicios entre las diferentes VPC y VNets. Después de todo, los servicios en la nube no son útiles si no podemos comunicarnos con y entre ellos.
Los tres proveedores ofrecen el emparejamiento entre redes virtuales, lo que permite que las redes virtuales emparejadas se comuniquen. Ninguna de las tres nubes permite emparejamiento transitivo, es decir, si la red1 se empareja con la red2 y red2 con red3, la red1 y la red3 no podrán comunicarse. Si se necesita esta comunicación es necesario emparejar red1 y red3.
Este modo de llevar a cabo los emparejamientos no escala bien, si se agrega otra red, se necesitan tres emparejamientos mas, lo cual es difícil de gestionar. Una posible solución es hub-and-spoke (ver ejemplo en https://cloud.google.com/architecture/deploy-hub-spoke-vpc-network-topology) que permite conectar múltiples redes mediante el uso de los diferentes tipos de puertas de enlace (Gateways) existentes.
Para aclarar los servicios necesarios para el intercambio de tráfico, me voy a basar en un diseño de tipo hub and spoke e identificar en cada una de las plataformas como se lleva a cabo. En este tipo de diseño de red los recursos que necesitan aislamiento a nivel de red usan redes de VPC-VNet de spoke separadas. Cada spoke en esta arquitectura tiene un emparejamiento de red con el hub central. Cada red spoke que necesite acceso a Internet deberá de tener un gateway que permita hacer NAT.
AWS
Con AWS, se utiliza AWS Transit Gateway para conectar varias VPC. AWS Transit Gateway se conecta a la VPC dentro de una región y permite que el tráfico fluya entre ellas. La siguiente imagen muestra un diseño Hub and Spoke típico.
Imagen tomada de https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/transit-gateway.html
Si hay varias regiones involucradas, AWS Transit Gateway ahora admite la capacidad para definir interconexiones entre Transit Gateway en diferentes regiones.
La conectividad a una red local remota puede tener lugar a través de una VPN con el uso de AWS Virtual Private Gateway .
Para una conexión dedicada, el gateway de AWS Direct Connect se utiliza para proporcionar una conexión privada dedicada de gran ancho de banda entre una red local y la VPC. En este escenario, se requiere un proveedor externo para la conectividad entre el centro de datos y AWS. Estos proveedores están ubicados cerca del centro de datos de AWS, lo que proporciona una conexión privada y confiable entre una red local y AWS.
Cada VPC tiene un enrutador implícito y utiliza tablas de enrutamiento para controlar hacia dónde se dirige el tráfico de red. Hay dos tipos de tabla de rutas en AWS:
- Tabla de rutas de subred
- Tabla de ruta principal
- Tabla de rutas personalizada
- Tabla de rutas de gateway
Cada subred en su VPC debe estar asociada con una tabla de rutas.
La tabla de rutas principal viene automáticamente con la VPC. Controla el enrutamiento de todas las subredes que no están asociadas con ninguna otra tabla de rutas. Una subred solo se puede asociar con una tabla de rutas a la vez. Por defecto, cuando se crea una VPC no predeterminada, la tabla de rutas principal contiene solo una ruta local, ya que las VPC no predeterminadas no tienen conectividad a Internet.
Por defecto, una tabla de rutas personalizada está vacía y se puede completar según sea necesario. Pudiendo agregar, quitar y modificar rutas. Esta tabla de rutas solo se puede eliminar si no tiene asociaciones.
Se puede asociar una tabla de rutas con un Internet Gateway o un Virtual Private Gateway. Cuando una tabla de rutas está asociada con un gateway, se denomina tabla de rutas de gateway.
Azure
Azure permite implementar un patrón de hub and spoke con componentes de infraestructura gestionados por el cliente, o bien crear una solución administrada por Microsoft con Virtual WAN, ver Topología de red en estrella tipo hub and spoke con Azure Virtual WAN . Este segundo caso es de utilidad para escenarios de uso en el que se requiere un gran escalado y actualmente solo ofrece IPv4 por lo que para homogeneizar la comparativa con el resto de plataformas me voy a centrar en la primera opción.
La siguiente imagen muestra la Arquitectura de Referencia de Hub and Spoke propuesta por Azure.
Imagen tomada de https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/hybrid-networking/hub-spoke
En Azure, un gateway admite la conectividad entre las redes virtuales y fuera de Azure. En Azure existen dos tipos de Gateway.
- Un Azure VPN Gateway admite una conexión VPN entre el gateway y un endpoint de VPN, permitiendo conectividad a un red local. Antes de crear un gateway de VPN se debe crear una subred de gateway. Para que la subred de gateway funcione correctamente, su nombre tiene que ser “GatewaySubnet”.
- Un Azure ExpressRoute gateway admite la conectividad entre Azure y una red local con una conexión ExpressRoute privada. Una conexión ExpressRoute es una conexión segura y redundante a través de una red de terceros.
Azure tiene dos tipos diferentes de rutas:
Azure crea automáticamente una tabla de rutas del sistema para cada subred dentro de una VNet de Azure y agrega rutas predeterminadas a la tabla. Se pueden anular algunas de las rutas del sistema de Azure con rutas personalizadas. Azure enruta automáticamente el tráfico entre subredes mediante las rutas creadas para cada intervalo de direcciones y no es necesario definir gateways para que Azure enrute el tráfico entre subredes.
La ruta predeterminada del sistema especifica el prefijo de dirección 0.0.0.0/0. A menos que se anule, Azure enruta el tráfico para cualquier dirección no especificada por un rango de direcciones dentro de una VNet a Internet, con la excepción de la dirección de destino de los servicios de Azure que Azure enruta a través de la red troncal de Azure.
Las rutas personalizadas se crean creando rutas definidas por el usuario o intercambiando rutas del protocolo de Gateway de frontera (BGP) entre gateway de red local y un gateway de red virtual de Azure.
El uso de BGP con un gateway de VNet de Azure depende del tipo que se seleccionó cuando se creó el gateway. Debe usar BGP con el servicio ExpressRoute, mientras que es opcional usar BGP con el servicio VPN.
El algoritmo de selección de ruta en Azure prefiere una ruta con la coincidencia de prefijo más larga. Si varias rutas contienen el mismo prefijo, la ruta definida por el usuario (estática) tiene la prioridad más alta, seguida de las rutas BGP y las rutas del sistema.
GCP
Una VPC en GCP es global y todas las subredes pueden comunicarse de manera preestablecida. Dentro de GCP se tiene en consideración el concepto de proyecto, (ver artículo anterior de esta serie). Una VPC es parte de un proyecto, las subredes internas de la VPC pueden comunicarse, pero no pueden comunicarse con una VPC en otro proyecto. Para que dos VPC se comuniquen, debemos agregar interconexión de VPC.
Al igual que Azure y AWS, la interconexión en GCP no es transitiva. Es decir, si agregamos un tercer proyecto y una VPC y emparejamos con la VPC y el Proyecto 2, el Proyecto 1 y el 2 pueden comunicarse, el Proyecto 2 y el 3 pueden comunicarse, pero el Proyecto 1 y el Proyecto 3 no pueden comunicarse a menos que agreguemos otra relación de interconexión.
GCP tiene otra característica llamada VPC compartida. Esto proporciona flexibilidad al permitir que múltiples proyectos aprovechen una VPC central donde la conectividad se puede controlar y administrar de forma centralizada.
La siguiente imagen muestra un ejemplo de topología hub-and-spoke en GCP
Imagen tomada de https://cloud.google.com/architecture/deploy-hub-spoke-vpc-network-topology
La escalabilidad de una topología de hub and spoke que usa intercambio de tráfico entre redes de VPC está sujeta a los límites de intercambio de tráfico entre redes de VPC. Como se dijo antes, las conexiones de intercambio de tráfico entre redes de VPC no permiten el tráfico transitivo. Para ello se usa Cloud VPN para superar las limitaciones del intercambio de tráfico entre redes de VPC.
Para la decisión de usar emparejamiento de redes o Cloud VPN se debe tener en consideración lo siguiente:
- El emparejamiento entre redes de VPC no tiene restricción de transitividad, pero admite el ancho de banda completo permitido.
- Cloud VPN permite el enrutamiento transitivo, pero el ancho de banda total (entrada y salida) de cada túnel VPN se limita a 3 Gbps.
GCP también ofrece un servicio de interconexión en la nube. Esto, como Azure ExpressRoute y la conexión virtual privada de AWS, proporciona una conexión segura a través de un circuito privado dedicado.
Todos los servicios utilizan el protocolo de gateway de frontera o BGP para administrar el enrutamiento entre las diferentes redes locales y en la nube. No puede haber subredes superpuestas si se prevé utilizar el emparejamiento o conectar a una red local. Por lo tanto, es importante planificar los espacios de direcciones IP.
Las rutas de Google Cloud definen el camino que toma el tráfico hacia los destinos. Estos destinos pueden estar dentro o fuera de tu red de VPC. Existen diferentes tipos de rutas en GCP:
- Rutas generadas por el sistema
- Rutas personalizadas
- Rutas de intercambio de tráfico
- Rutas basadas en políticas
En cada VPC nueva hay dos tipos de rutas que genera el sistema :
- Ruta predeterminada , la cual se puede quitar o reemplazar.
- Ruta de subred para cada una de las subredes. No se puede quitar una ruta de subred, a menos que se borre la subred correspondiente.
La ruta predeterminada se crea cuando crea una VPC. Se crea con baja prioridad (1000) y se puede reemplazar con una ruta personalizada con mayor prioridad. Las rutas de subred son rutas generadas por el sistema que define rutas a cada subred en la red de VPC.
Las rutas personalizadas pueden anular las rutas de subred, ya que siempre tendrán mayor prioridad. Las rutas personalizadas se pueden dividir en:
- Rutas estáticas , pueden usar cualquier salto estático siguiente.
- Rutas dinámicas , sus destinos siempre representan rangos de IP fuera de la VPC, y sus próximos saltos siempre son un par de una sesión de BGP en un Cloud Router .
Las rutas de intercambio de tráfico permiten gestionar el tráfico entre VPC emparejadas pueden ser:
Las rutas basadas en políticas permiten enrutar paquetes a un siguiente salto de balanceador de cargas TCP/UDP interno .
Servicios de seguridad
En este apartado voy a explicar los diferentes mecanismos ofrecidos por los tres proveedores para controlar el tráfico existente.
De forma general al ser las redes servicios administrados, están protegidos por la seguridad de red global de la plataforma Cloud.
Además, las redes están aisladas lógicamente. Es recomendable usar redes separadas para aislar la infraestructura por carga de trabajo o unidad organizativa.
Una subred es un rango de direcciones IP de una VPC. Al lanzar una instancia, la lanza a una subred en una VPC. Se deben utilizar subredes para aislar los niveles de la aplicación (por ejemplo, web, aplicación y base de datos) en una VPC individual. Se deben utilizar subredes privadas para las instancias si no se debe acceder a ellas directamente desde Internet.
Dentro de la arquitectura de red se define el control de tráfico que se realiza mediante los elementos ofrecidos por cada una de las plataformas.
AWS
El tráfico entrante y saliente se puede controlar mediante dos mecanismos diferentes:
Un grupo de seguridad actúa como un cortafuegos con estado virtual para que la instancia controle el tráfico entrante y saliente. Los grupos de seguridad actúan a nivel de instancia y están asociados con las interfaces de red, no con el nivel de subred. Para cada grupo de seguridad, se pueden agregar reglas que controlen el tráfico entrante a las instancias y un conjunto separado de reglas que controlen el tráfico saliente. Se pueden especificar reglas de permiso, pero no reglas de denegación. De forma predeterminada, los grupos de seguridad niegan todo el tráfico entrante y permiten todo el tráfico saliente.
Una lista de control de acceso a la red (ACL) es una capa opcional de seguridad para la VPC que actúa como un firewall para controlar el tráfico de entrada y salida de una o más subredes. De manera predeterminada, ACL permite todo el tráfico IPv4 e IPv6 entrante y saliente. Cada subred en la VPC debe estar asociada con una ACL de red. Si no se asocia una subred con una ACL de red, la subred se asocia automáticamente con la ACL de red preestablecida.
La siguiente tabla resume las diferencias básicas entre grupos de seguridad y ACL de red.
| Security group (Grupo de seguridad) | ACL de red |
|---|---|
| Opera en el nivel de la instancia | Opera en el nivel de la subred |
| Se aplica a una instancia solo si está asociada a la instancia | Se aplica a todas las instancias implementadas en la subred asociada (proporciona una capa de defensa adicional si las reglas del grupo de seguridad son demasiado permisivas) |
| Solo admite reglas de permiso | Admite reglas de permiso y de denegación |
| Evalúa todas las normas antes de decidir si permitir el tráfico | Evalúa las reglas en orden, a partir de la regla numerada más baja, al decidir si permitir el tráfico |
| Con estado: el tráfico de retorno se permite de manera automática, independientemente de las reglas | Sin estado: las reglas deben permitir de forma explícita el tráfico de retorno |
El siguiente diagrama muestra las capas de seguridad proporcionadas por los grupos de seguridad y las ACL de red.
Imagen tomada de https://docs.aws.amazon.com/es_es/vpc/latest/userguide/infrastructure-security.html
AWS también admite el filtrado de red mediante AWS Network Firewall , servicio de detección y prevención de intrusiones con estado.
Además existe la posibilidad de realizar conexión privada entre VPCs.
Azure
Azure ofrece dos componentes para proteger el tráfico dentro de la red virtual:
Un grupo de seguridad de red contiene reglas de seguridad que permiten o deniegan el tráfico de red entrante o el tráfico de red saliente desde varios tipos de recursos de Azure. De forma predeterminada, se permite toda la comunicación entrante dentro de las subredes de la red virtual, así como cualquier tráfico procedente de Azure Load Balancer, mientras que el resto del tráfico entrante está bloqueado. Las reglas de seguridad se evalúan y aplican en función de la información de cinco tuplas (origen, puerto de origen, destino, puerto de destino y protocolo).
Las reglas de seguridad aumentadas simplifican la definición de seguridad para las redes virtuales, lo que le permite combinar etiquetas de servicio o grupos de seguridad de aplicaciones. Para el tráfico entrante, Azure procesa primero las reglas en un grupo de seguridad de red asociado a una subred y luego las reglas en un grupo de seguridad de red asociado a la interfaz de red. Para el tráfico saliente, Azure procesa primero las reglas en un grupo de seguridad de red asociado a una interfaz de red y luego las reglas en un grupo de seguridad de red asociado a la subred.
Los grupos de seguridad de aplicaciones permiten configurar la seguridad de red como una extensión natural de la estructura de una aplicación, lo que permite agrupar máquinas virtuales y directivas de seguridad de red basadas en esos grupos.
Azure permite usar etiquetas de servicio en direcciones IP específicas cuando se crean reglas de seguridad y rutas, o se configura Azure Firewall.
En la siguiente imagen se muestra una combinación de NSG y ASG para filtrar el tráfico en una aplicación.
Imagen tomada de https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/n-tier/high-security-iaas
Azure ofrece más mecanismos para controlar el tráfico por ejemplo Azure Firewall y la capacidad WAF de Application Gateway .
Azure Firewall complementa la funcionalidad del grupo de seguridad de red. Juntos garantizan una mejor seguridad de red de "defensa en profundidad". Es un firewall de red centralizado como servicio con estado completo que proporciona protección a nivel de red y de aplicación en todas las distintas suscripciones y redes virtuales.
Firewall de aplicaciones web (WAF) es una característica de Application Gateway que proporciona a las aplicaciones una protección de entrada centralizada contra ataques y puntos vulnerables comunes. Azure Firewall proporciona protección de entrada para protocolos no HTTP/S (como RDP, SSH y FTP), protección de salida a nivel de red para todos los puertos y protocolos, y protección a nivel de aplicación para las salidas HTTP/S.
Azure también proporciona la posibilidad de acceso privado a los servicios alojados en la plataforma Azure, manteniendo sus datos en la red de Microsoft, mediante los private link a través de los private endpoint.
GCP
Cada red viene con un firewall que se puede configurar con reglas para controlar el tráfico que acepta un recurso o conjunto de recursos dentro de la red. Cada regla (ACL) define el tráfico permitido según IP de origen, IP de destino, puertos y protocolo. También es posible etiquetar recursos específicos y definir reglas usando estas etiquetas. Si bien las reglas del firewall se definen a nivel de red, las conexiones se permiten o deniegan por instancia. Cada regla de firewall se aplica al tráfico entrante o saliente, no a ambos. Después de que se ha establecido una sesión, las reglas de firewall permiten la comunicación bidireccional. Cada red de VPC tiene dos reglas de firewall aplicables:
- Permitir regla de salida
- Denegar la regla de entrada
La regla de permiso de salida requiere la prioridad más baja (65535) y permite todo el tráfico a todos los destinos, excepto el tráfico bloqueado por GCP (GRE, SMTP en el puerto 25, etc.). Se puede utilizar una regla de mayor prioridad para cambiar el comportamiento predeterminado.
La regla de denegación de entrada también está configurada con la prioridad más baja posible (65535) y bloquea todo el tráfico entrante excepto parte del tráfico (icmp, ssh, rdp) que está permitido, pero esas reglas se pueden eliminar o modificar.
Además de las listas de control de acceso de firewall integrados, los dispositivos de firewall de terceros se pueden configurar para interceptar el tráfico entrante y saliente. Las opciones de control de tráfico existentes en GCP son limitadas en comparación con Azure y AWS.
GCP permite la conexión privada a la VM ya los servicios compatibles.
Comparación
En la siguiente tabla muestro de forma resumida una comparación de los diversos conceptos vistos a lo largo del artículo.
| AWS | Azure | GCP | |
|---|---|---|---|
| Servicios de red y conectividad | |||
| Red virtual | VPC (Nube privada virtual) | VNet (Red virtual) | VPC (Nube privada virtual) |
| Ámbito de la red virtual | Regional | Regional | Global |
| Tipos de redes | Predeterminada No predeterminada |
Un solo tipo | Modo automático Personalizada |
| Ámbito de la subred | Zona de disponibilidad | Región | Región |
| Tamaño de la subred | IPv4: min /28, max /16 IPv6: /64 |
IPv4: min /29, max /8 IPv6: /64 |
IPv4: min /29, max /8 IPv6: /64 |
| Rango de IPs de la subred | Dentro del rango de la VPC | Dentro del rango de direcciones de la VNet | Cualquier rango de red |
| Enrutamiento del tráfico | Tabla de rutas de subred (principal, personalizada) Tabla de rutas de gateway |
Rutas del sistema Rutas personalizadas |
Ruta generada por el sistema Ruta personalizada |
| IPs reservadas en cada subred | 5 (4 primeras y última) | 5 (4 primeras y última) | 4 (2 primeras y 2 últimas) |
| Conexión con otras redes | VPC Peering AWS Direct Connect |
VNet Peering | VPC Network Peering |
| Conexión con on-prem | AWS site-to-site VPN AWS Direct Connect AWS Transit Gateway AWS VPN CloudHub |
VPN Gateway Express Route |
Cloud VPN Cloud Interconnect Direct Peering |
| Servicios de seguridad | |||
| Control de tráfico entrante/saliente | Network Access Control Lists Security Groups |
Network Security Groups Application Security Groups |
Firewall |
| Filtrado de red | AWS Network Firewall | Azure Firewall WAF de Application Gateway |
Firewall de terceros |
| Conexión privada | AWS PrivateLink | Azure private link Azure private endpoint |
Private Google Access |
Conclusión
A lo largo de este artículo he explicado los temas más importantes relacionados con redes y servicios asociados, la descripción ha comenzado con la descripción de las redes y sus subredes, a continuación he comentado la forma de comunicar diversas redes entre sí y con contenido fuera de las mismas, y la forma de comunicar las subredes dentro de una red. Y he finalizado explicando las diferentes opciones dadas para controlar el tráfico existente.
De estos elementos podemos ver que el funcionamiento de Azure y AWS tiene una cierta similitud tanto en el funcionamiento de las redes como en el control del tráfico. GCP ofrece un funcionamiento diferente y con menos opciones a la hora del control de tráfico, si con lo ofrecido por GCP es suficiente para las necesidades requeridas es una opción perfecta, si se prevé que se necesitan más capacidades recomendamos optar por Azure o AWS.