Midiendo la latencia hacia la nueva región de AWS España (eu-south-2 en Zaragoza)
Tags: directconnect, networking, español, aws
Published: 2023-09-12 08:14:05

A principios de año, me encontraba en el AWS re-cap en Madrid para conocer las novedades del re:Invent del 2022 y para ver de primera mano la presentación de la nueva región de AWS de España en Zaragoza.

En la sesión de preguntas, hice una pregunta acerca de las latencias desde Madrid hasta Zaragoza.

Antes de meternos y profundizar un poco... ¿qué es la **latencia**?

La latencia es un término utilizado para describir **el retardo de tiempo en un medio de transmisión**.  

En el vacío, la luz viaja a 299.792.458 metros por segundo.  Esto equivale a 299,792 metros por microsegundo (µs) o 3,34µs por kilómetro.

En la fibra óptica, la luz viaja más despacio por la refracción. Lo que nos da una medición aproximada de 5µs por kilómetro.

Quería saber cuál es la latencia (RTT --> De ida y vuelta) para un cliente en España que quiera utilizar el servicio de [Direct Connect](https://aws.amazon.com/es/directconnect/) desde [Interxion MAD](https://aws.amazon.com/directconnect/locations/), hasta Zaragoza, al nuevo clúster de AWS.

Zaragoza está a unos 320 km de Madrid (aproximadamente), el clúster no está en la misma área metropolitana, como se puede observar.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/w8zrm85yyrlukuyusnbs.png)

Mi pregunta tiene un poco de mala leche, porque no se tratan de los km de fibra que tiene que atravesar la luz, sino también del número de dispositivos de red por los que debe pasar el flujo de datos hasta llegar al destino.

Se me dijo "**aproximadamente menos de 10ms**" como respuesta.

Después de muchos meses, decidí resolver la ecuación y hacer esta medición; somos ingenieros y nos gusta la precisión ;)

Intentaré que la solución sea sencilla y que lo podamos entender; empecemos:

Para realizar esta medición, he creado la siguiente infraestructura en AWS:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/j1nzoezw68gn8d5li2ua.png)

La idea detrás de este diseño es poder acceder a mi Host Privado 1 en la subred privada vía SSH desde el bastión, que está accesible en desde internet, en la subnet pública. 

(También podría haber usado una [IP elástica](https://docs.aws.amazon.com/es_es/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html) directamente para el Host Privado, simplificando el diseño, sin tener que crear un bastion host ni dos subnets distintas...)


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qsa6w05925dw36mefq8l.png)

Visto así, parece fácil, ¿verdad?

Ahora imagina replicar la misma infraestructura utilizando una dirección de red diferente pero manteniendo la misma configuración.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/j0os3kuiazy8wz4bh4jy.png)

Ahora que tenemos estas dos infraestructuras, ¿cómo podemos interconectarlas?


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/40hn9crnyfzk8xv2k6mg.png)

Utilizando el [Servicio de Direct Connect (DX)](https://aws.amazon.com/es/directconnect/) y con la ayuda de un [socio/partner](https://aws.amazon.com/es/directconnect/partners/?partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-location=*all) de interconexión. Para este laboratorio, utilizaré a DE-CIX.

Interconectaremos el VPC1 con una conexión DX hosteada, en una ubicación donde AWS y el partner están presentes → en Interxion Madrid.

Haremos lo mismo con la VPC2 utilizando otra conexión DX que termine en el mismo DC (en Interxion MAD).

Una vez interconectados, haremos un ping desde el Host Privado 1, al Host Privado 2 para medir el camino hasta Madrid desde Zaragoza.

**Quizás os preguntaréis, ¿cómo vais a interconectar las dos  DXcon? ¿Tienes allí un rack con dispositivos de networking para enrutar y hacer mediciones?**

La respuesta a la última pregunta es sí y no; utilizaremos el [Cloud Router](https://www.de-cix.net/en/about-de-cix/news/de-cix-cloudrouter-interconnection-made-easy) de DE-CIX para interconectar las dos Conexiones de AWS en Interxion.

El Cloud Router es una instancia VRF (Virtual Routing & Forwarding) ejecutada en un equipo de red de grado carrier. 


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mxpj0qqieevtfld7dd3g.png)

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yhi7h0n81qw17bqppsxq.png)

Si enviamos un ping desde el Host Privado 1 al Host Privado 2, el ping fluye de Zaragoza a Madrid y de Madrid a Zaragoza, terminando en el Host Privado 2 y volviendo al Host Privado 1.

Como queremos obtener la latencia de medio camino (sólo de Zaragoza a Madrid), debemos dividirla por dos si realizamos un ping. 

**Medidas**

He realizado dos ejecuciones de ping con diferentes tamaños de ventana para realizar las mediciones. Como podéis ver, la latencia puede variar un poco. Esto depende de la ruta que esté tomando AWS dentro de su backbone. Parece que hay dos formas diferentes de llegar al destino, una con menos latencia que la otra.

También, debido a que hay diferentes zonas de disponibilidad (AZs), la latencia puede variar dependiendo de donde se encuentren nuestros recursos.

**Tamaño de ventana 128K - Ejecución 1**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5mg91tvqq7w463i5jikb.png)

Avg = 11,934 / 2 = **5,967 ms**

**Tamaño de ventana 128K - Ejecución 2**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dewrrdlliyhpp1y0cai4.png)

Avg= 16.441 / 2 = **8.2205 ms**

**Tamaño de ventana 256K - Ejecución 1**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7mgv1yc6gasrp71z5r2n.png)

Promedio = 11.928 / 2 = **5.964 ms**

**Tamaño de ventana 256K - Ejecución 2**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/amxvo3u1pxf9xavyr4q6.png)

Promedio = 16.451 / 2 = **8.2255 ms**

**Tamaño de ventana 512K - Ejecución 1**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6blns52zfmbhn579khuo.png)

Promedio = 11.946 / 2 = **5.973 ms**

**Tamaño de ventana 512K - Ejecución 2**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/plmpyeyo5ujhfb59mcfj.png)

 Promedio = 16,452 / 2 = **8,226 ms**

**Tamaño de ventana 1024K - Ejecución 1**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7xeslnwru6xwag16w7bs.png)

Promedio = 11.975 / 2 = **5.9875 ms**

**Tamaño de ventana 1024K - Ejecución 2**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zgospjz0lvk91gnkhqo6.png)

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jqy4ir2teusl0vufoskh.png)

Promedio = 16,492 / 2 = **8,246 ms**

**Media de las muestras tomadas:**
Ejecución 1 ≈ **5,97 ms**
Ejecución 2 ≈ **8,23 ms**

**Conclusión**

La respuesta a mi pregunta **varía y depende**; depende por la ruta interna del backbone de AWS pase y dónde estén tus recursos; pero **objetivamente no son 10ms, son 6 u 8 ms (aprox.) para llegar a la nube desde Madrid a Zaragoza.**