Measuring latencies for the new region of AWS Spain (eu-south-2)
Tags: directconnect, aws, networking, spain
Published: 2023-04-03 21:53:01

Some months ago, I was at the AWS re-cap event in Madrid to view all the Highlights from the re:Invent 2022 and the presentation of the new region of AWS Spain in Zaragoza. 

In the Q&A session, I asked a question regarding latencies.

Before deeping dive, what is **latency**?

Latency is a term used to describe a **time delay in a transmission medium**.  _In free space, light travels at 299,792,458 meters per second.  This equates to 299.792 meters per microsecond (µs) or 3.34µs per kilometer._ 

_I wanted to know what the latency is for a Spanish customer using Direct Connect to get transported from the_ [DX locations](https://aws.amazon.com/directconnect/locations/) located in Madrid _(located either in Interxion or Equinix) to Zaragoza, to the new cluster in Spain._

Considering a straight line, Zaragoza is around 320 km away from Madrid. It is not in the same metropolitan area

![Distance from Zaragoza to Madrid](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k3wq4rv9ubo555oefc3g.png)
 
What I asked is a tricky question, because it's not just about the distance of the various fiber routes with the travel speed of light, but also the number of network devices the data stream must pass through to the cloud of AWS Spain.

I got as an answer **an estimation of less than 10ms**.

After many months, I decided to resolve this equation and do this measurement; **we are engineers and like precision ;)**. I will try to keep the solution simple; let´s get started:
 
To perform this measurement, I created the following infrastructure in AWS:

![Architecture](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k0w7m3rn3iyjj8vb0t92.png)

The idea behind this infrastructure is to access my Private Host 1 in the private subnet via SSH from the bastion host, which is available from the internet.

![console from the ec2 instance](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/j0qx2yvp3g45ogw7kvme.png) 

_Looks easy, right?_

Imagine replicating the same infrastructure using a different IP space but keeping the same configuration.
 
![Replicated Architecture with a different IP Space](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t8qjmspm26uy3hserhhy.png)

Now that we have these two infrastructures in place, how can we interconnect them for performing this measurement?

![AWS DX Service](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tqfjhz7x4b8h50ejpv9j.png)

Using the [Direct connect Service (DX)](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html), with the help of an interconnection partner. This is the list of [partners](https://aws.amazon.com/directconnect/partners/?partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-location=*all); for this lab, I will use DE-CIX.

_We will interconnect the VPC1 with a DX connection to a location where AWS and the partner are present → Interxion MAD2, in Madrid._

_We will do the same with the VPC2 using another DX connection ending in the same DC._

_Once they are interconnected, we will ping from Private Host 1, to Private Host 2 for measuring the path until Madrid from Zaragoza._

**_Maybe you will be asking, how will you interconnect one DXcon with the other DXcon?_ _Do you have a rack there for routing and doing measurements?_**

The answer to the last question is yes and no; we will use the DE-CIX CloudROUTER to interconnect the two AWS Direct Connections in Interxion. 

This Cloud Router is a VRF (Virtual Routing & Forwarding) instance executed in carrier-grade networking gear. It extends where it is needed, in this case, to the Interxion MAD2 location where the partner and AWS are present.

![Final architecture with the CloudRouter](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2e9tospdko966l77o9xk.png)

**Note**: If we want to interconnect two instances in different VPCs, we use a VPC Peering connection in AWS.
 
For this exercise, because we want to measure the path until Madrid, we do this architecture using the DE-CIX services.

![Final architecture seen from the map](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/h31q49cekj8t3s8uw2gn.png)

If we send a ping from Private Host 1 to Private Host 2, the ping flows from Zaragoza to Madrid and from Madrid to Zaragoza, ending in Private Host 2 and returning to Private Host 1.

Because we want to get the latency of half path (from Zaragoza to Madrid only), we must divide it by two if we perform a ping.

**Measurements**

I´ve done two ping runs with different window sizes to perform the measurements. As you can see, the latency can vary a little bit. This depends on the route AWS is taking inside its backbone. It seems there are two different ways to reach the destiny, one with less latency than the other. 

Also, because there are different availability zones (AZs), the latency can vary depending on where our resources are located.

**Window size 128K – Run 1**

![Window size 128K – Run 1](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jdmanchnppiuaam0tsha.png)Avg = 11.934 / 2 = **5.967 ms**

**Window size 128K – Run 2**

![Window size 128K – Run 2](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t9rxyujbkzj1dy821bv5.png) Avg= 16.441 / 2 = **8.2205 ms**

**Window size 256K – Run 1**

![Window size 256K – Run 1](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vxyxm7yfsvvcnftyzy5n.png) Avg = 11.928 / 2 = **5.964 ms**

**Window size 256K – Run 2**

![Window size 256K – Run 2](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kfw7bbqccglnnwbn2y78.png) Avg = 16.451 / 2 = **8.2255 ms**

**Window size 512K – Run 1**

![Window size 512K – Run 1](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/64u5f03y5x9byn1hop4s.png) Avg = 11.946 / 2 = **5.973 ms**

**Window size 512K – Run 2**

![Window size 512K – Run 2](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9gho55w815s8uqzuapu0.png) Avg = 16.452 / 2 = **8.226 ms**

**Window size 1024K – Run 1**

![Window size 1024K – Run 1](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7pzzh0u1deu3ur4g8czz.png) Avg = 11.975 / 2 = **5.9875 ms**

**Window size 1024K – Run 2**

![Window size 1024K – Run 2](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5pp710olfeypen80x3kd.png)![Window size 1024K – Run 2](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/06ykkrhqub3brmgpyxsa.png) Avg = 16.492 / 2 = **8.246 ms**

**Average of the taken samples:**
_Run 1 ≈ **5.97 ms**_
_Run 2 ≈ **8.23 ms**_

**Conclusion**

The answer to my question **depends**; _it depends on which internal path of the AWS backbone you land and where your resources are;_ **you will get either 6 or 8 ms (approx.) to reach the cloud from Madrid to Zaragoza.**

**Personal thoughts** 

This mini-lab was fun to do; _having the opportunity to integrate cloud connections with this technology is a grand experiment **that everyone should try.**_

_In the future, I could prepare another lab for migrating from one cloud to AWS using high bandwidth DX Connections in combination with the Cloud Router and measuring the throughput._ **What do you think?**

I read you in the comments :D