El coste del ancho de banda en Azure, un pequeño desconocido

El otro día, en una conversación interna, saltaron unas cuántas dudas de qué tráfico se cobraba o no en Azure según el origen, el destino y el tipo de conectividad de la que se disponía. Inicialmente pensé que era algo que tenía bastante claro pero tras ver el resumen que hizo mi compañero José Guardia (@msjosegm) creo que tiene mucho más detrás de lo que inicialmente pensaba.

A continuación, tenéis un listado de todos los puntos que tenéis que tener en cuenta cuando tengáis que realizar una estimación de los costes de ancho de banda en Azure:

  • Tráfico que sea de ingreso a Azure desde Internet, una conexión VPN, una conexión ExpressRoute u otro servicio de Azure: gratuito.
  • Tráfico que sea entre recursos conectados dentro de la misma red virtual: gratuito
  • Tráfico que fluya entre un VNet Peering ya sea regional o entre diferentes regiones: tiene coste tanto de salida como de entrada.
  • Tráfico que sea saliente de la red virtual hacia Internet: tiene coste de salida
  • Tráfico que sea saliente de la red virtual hacia una IP pública de la misma región de Azure: gratuito
  • Tráfico que sea saliente de la red virtual hacia una IP pública de otra región de Azure: tiene coste de salida
  • Tráfico que sea saliente de la red virtual a través de una conexión VPN: tiene coste de salida
  • Tráfico que sea saliente de la red virtual a través de una conexión de ExpressRoute en su categoría metered: tiene coste de salida
  • Tráfico que sea saliente de la red virtual a través de una conexión de ExpressRoute en su categoría unmetered: gratuito
  • Tráfico entre servicios de Azure dentro de la misma región: gratuito
  • Tráfico entre servicios de Azure en diferentes regiones: tiene coste de salida
  • Tráfico entre servicios de Azure desplegados en Availability Zone en una red virtual: dentro de la misma AZ es gratuito pero entre AZ tiene coste de entrada y salida.

Como veis, no tan sencillo como inicialmente parecía. Si seguía la máxima de todo lo entrante es gratuito y solo se factura lo saliente, recordad las excepciones a la regla que en este caso son varias.

Sincronizando cambios de red en Web Apps con conexión a una VNET

Una de las funcionalidades de la parte de Web Apps dentro del App Service es la capacidad de conectarse a una red privada para que nuestras aplicaciones puedan acceder a información que no esté pública en la red. El proceso de creación está perfectamente detallado paso por paso en la documentación.

Durante el proceso inicial de establecimiento de la conexión se realizan una serie de pasos como la generación de los certificados de la conexión punto a sitio o se propaga la información del enrutado, de los DNS y de otra información necesaria para que la conectividad sea exitosa. Sin embargo, es posible que por algún motivo a lo largo del tiempo de vida de la aplicación, esta información de red se vea modificada y sea necesario actualizarla.

Para ello, no es necesario recrear la conexión entre la Web App y la red, simplemente será necesario acceder a la pestaña de Virtual Network y en la parte superior veremos el botón de Sync Network . Con ello, se cargará la nueva información y aplicando los cambios que se hayan realizado a nivel de la red virtual a la que está enlazada. ¡Ojo! Provocará un corte breve en la conectividad por lo que durante unos instantes la aplicación podría dejar de funcionar correctamente.

Sincronizar cambios de red en Web Apps
Sincronizar cambios de red en Web Apps

En mi caso, el cambio fue relacionado con los DNS. Una vez iniciada la sincronización, al cabo de unos instantes estaban ya los nuevos DNS propagados.