DEV Community: Luis Horvath

¡Vamos a bichear! - Dashboard de Ping

Luis Horvath — Wed, 12 Mar 2025 21:07:46 +0000

Pequeño repaso arquitecturil:

Me gustaría repasar algunos conceptos primero:

¿Qué es una Zona de Disponibilidad aka (AZ: Availability Zone)?

Una AZ en AWS es un centro de datos (o un grupo de centros de datos) físicamente separado e independiente dentro de una Región. Las regiones de AWS cuentan con múltiples AZs, con un mínimo de 3 por región.

Cada AZ dispone de electricidad, refrigeración y redes independientes, lo que garantiza alta disponibilidad y tolerancia a fallos.

¿Puede una subnet formar parte de distintas AZs?
No, por defecto, cada subnet o subred, tiene que estar vinculada a una zona de disponibilidad, no se puede expandir una misma subnet entre varias AZs a la vez.

Si se desea, se pueden desplegar varias subnets (por servicio) y asignarlas a distintas AZs.

¿Por qué se debe de usar distintas subnets en distintas AZs?

Al diseñar arquitecturas que son altamente disponibles, es una buena práctica distribuir las cargas de trabajo segmentando los distintos servicios en diferentes subnets y desplegar estas subnets en distintas AZs para así garantizar la resiliencia.

Por ejemplo:

Una base de datos debería ubicarse dentro una subnet en una AZ. Si se quiere hacer una arquitectura multi-AZ, habría que utilizar más subnets y desplegar los servicios de las DB, dentro de estas subredes, en otras AZs.
Si a nuestro ejemplo añadimos un frontend, este debería de estar desplegado en una subnet distinta a la de la base de datos.
Además tendría que estar desplegado en diferentes AZs, en distintas subnets si se quisiera hacer una arquitectura resiliente multi-AZ.

Siguiendo este principio, mejoramos la seguridad, aumentamos la escalabilidad y aprovechamos las capacidades de resiliencia de AWS.

Subnets públicas vs privadas

Subnet pública: tiene una ruta directa a Internet.

Ejemplo: Un servidor web se ubica en la subnet pública y está expuesto directamente a Internet. El servidor tiene IP Pública y privada

Subnet privada: No tiene una ruta directa a Internet.

Ejemplo: Una base de datos se ubica en una subnet privada y no necesita estar expuesta a Internet. La base de datos solo tiene IP Privada

Es posible permitir que los recursos dentro de una subnet privada se comuniquen con Internet sin que haya acceso desde fuera manteniendo la IP Privada. Para ello, hay que desplegar algunos servicios de red adicionales.

Hace unos meses, un amigo me lanzó un reto, el de diseñar la arquitectura de una aplicación. Podría ser la que quisiera...

Le empecé a dar un par de vueltas para ver cómo se podría arquitecturizar. Lo que empezó como un pequeño proyecto terminó escalando bastante, y esa es la razón por la que estás leyendo este artículo.

¿Cómo crearías un dashboard de ping?

¡Gracias Batman!, Exacto, ¡la P*** red!

No se puede empezar a construir la aplicación sin considerar primero la red. Para hacer esto, me miré ante el espejo y y me pregunté cómo sería la arquitectura a nivel de red:

Quiero crear un dashboard de ping resiliente en múltiples AZs, 
con servicios expuestos tanto en subnets públicas como privadas. 
En el futuro, quiero extender algunas partes de la aplicación a
diferentes regiones para expandir las mediciones.

Una vez entendido cómo iba a ser la estructura a nivel de red, es hora de entrar a la de la aplicación:

El dashboard de ping contará con un servidor web accesible desde    
Internet en una subnet pública, el cual mostrará datos de 
latencia obtenidos desde varias máquinas virtuales ubicadas en 
subnets privadas y utilizadas como sondas (probes).

Funcionamiento de la aplicación:

Las sondas realizarán mediciones de ping a un objetivo específico  
(una URL o una dirección IP) que será enviado por el servidor  
web.

Se registrará el tiempo de respuesta desde AWS hasta el destino 
indicado.

Los datos de latencia serán almacenados en una base de datos.
El servidor web consultará la base de datos y expondrá la 
información a los usuarios finales en un dashboard accesible 
desde la subnet pública.

Con este diseño, garantizamos resiliencia, escalabilidad y la posibilidad de expansión a otras regiones en el futuro.

Estructura del VPC (Virtual Private Cloud // La red)

He seleccionado la región eu-south-2 (España) y la red IPv4 10.0.0.0/24.

Dado que no necesito tantas IPs (una /24 contiene 256 IPs), quiero segmentar esta red en subnets más pequeñas y distribuir los servicios en diferentes AZs.

Hora del Subnetting!.

Voy a dividir la /24 en /28, lo que nos dará 16 subnets de 16 hosts cada una (11 utilizables, ya que AWS reserva 5)

Asignación de subnets por AZ

AZ A → Rango: 10.0.0.0/28 - 10.0.0.64/28
    10.0.0.0/28
    10.0.0.16/28
    10.0.0.32/28
    10.0.0.48/28
    10.0.0.64/28

AZ B → Rango: 10.0.0.80/28 - 10.0.0.144/28
    10.0.0.80/28
    10.0.0.96/28
    10.0.0.112/28
    10.0.0.128/28
    10.0.0.144/28

AZ C → Rango: 10.0.0.160/28 - 10.0.0.240/28
    10.0.0.160/28
    10.0.0.176/28
    10.0.0.192/28
    10.0.0.208/28
    10.0.0.224/28
    10.0.0.240/28

Basándonos en los requerimientos, necesitamos:

Una base de datos en una subnet privada
Una sonda en una subnet privada
Un servidor web en una subnet pública

Lo que vendría a ser 3 redes por AZ de la lista de arriba

¿Por qué no colocar todo en la misma subnet?

Por seguridad. Cada componente debe estar aislado para minimizar el impacto en caso de brecha de seguridad.

La segmentación en subnets, combinada con reglas de firewall, restringe el acceso de red entre servicios.

Dibujo de nuestra arquitectura

Elementos de red esenciales

Internet Gateway
    Necesario para que el servidor web tenga acceso a Internet.
    Se despliega a nivel del VPC, no llega a estar ubicado en una subnet.

NAT Gateway
    Permite que las instancias en subnets privadas accedan a 
    Internet sin exponerse directamente.

    Se despliega en una subnet pública y funciona en combinación     
    con el Internet Gateway.

    Se ha colocado un NAT Gateway por AZ (esto lo podremos  
    optimizar en siguientes iteraciones).

Con el cómputo nos hemos topado: EC2

Selección de instancias

Probes (sondas) → t3.micro
Servidores web → t3.micro
Load Balancer → Network Load Balancer (NLB)

En lugar de un solo servidor web, usaremos dos, bajo un NLB, para redistribuir el tráfico entre AZs.

¿Por qué no tres servidores web?

Los servidores webs están incluidos dentro de un 
AutoScaling Group (ASG) que se expande entre 
las distintas AZs.

Si el NLB detecta fallos en los healthchecks de 
la aplicación, el ASG redepliega la instancia en la 
misma, o en otra Zona de disponibilidad.

Si una AZ falla, el NLB dejará de enrutar tráfico 
a la AZ caída y el ASG reubicará la carga en otra AZ 
y el NLB apuntará a esta nueva instancia

Las sondas no son críticas, pero la aplicación sí 
lo es, es por eso que podemos permitirnos fallos al 
nivel de las sondas.

El NLB usará una Elastic IP.

Añadiendo la base de Datos

Se ha seleccionado RDS Multi-AZ (MySQL) con:

  Nodo principal
  Réplicas en standby

  Si la DB primaria falla, se activa automáticamente 
  una réplica para hacer el failover.

  Instancia utilizada: db.t3.micro

Expansión a otras regiones

Siguiendo el mismo principio, podemos expandir la solución a Frankfurt:

Nueva VPC (10.1.0.0/24)
Subnets públicas y privadas
Probes en cada AZ
NAT Gateway en cada AZ
Internet Gateway
VPC Peering para interconectar ambas regiones

Medidas de Seguridad

Session Manager
    Eliminamos puertos abiertos desde el exterior para reducir 
    la superficie de ataque. Nos conectaremos a las instancias,   
    de manera segura, a través de la interfaz web usando 
    session manager. 

Security Groups (SGs) por servicio
    SG del Servidor Web: Acepta tráfico solo desde el NLB.
    SG del NLB: Acepta tráfico de Internet.
    SG de la Base de Datos: Solo acepta tráfico del Servidor
    Web y las Probes.
    SG de las Sondas: Permite tráfico ICMP desde 
    cualquier origen (0.0.0.0/0).

Costes Aproximados por mes

8 instancias EC2 t3.micro (encendidas 24h // On Demand) 
= 8 x 8.32 USD = 66.56 USD

2 Internet Gateway = GRATIS
6 NAT Gateways (1 GB de tráfico mensual) 
= 6 x 35.09 USD = 210.54 USD

VPC Peering entre España y Alemania - Cada sonda genera   
aproximadamente 6 MB por día = 180 MB por mes x 6 sondas ≈ 1GB de 
tráfico = 0.04 USD

Network Load Balancer ≈ 20 USD
Elastic IP = 3.65 USD por IP
RDS Multi-AZ (db.t3.micro) = 77.13 USD

Total: 377.92 USD - Factura mensual

Huella de Carbono estimada
40 KgCO₂eq (Entre EC2 y el RDS)

Vamos a echarle mano a la red:

Podemos eliminar los NAT Gateways que no son indispensables, reduciendo drásticamente los costes. Se puede colocar un solo NAT Gateway en una AZ, permitiendo el acceso a Internet de las instancias en otras zonas de disponibilidad.

Si este NAT Gateway fallase por cualquier motivo, ninguna instancia dentro de las subredes privadas podrá acceder a Internet hasta que AWS lo recree.

Dado que el NAT Gateway es un servicio administrado por AWS, si falla, se volverá a desplegar automáticamente, pero el proceso puede tardar hasta 15 minutos.

Una buena estrategia sería crear una función de failover automatizada (usando AWS Lambda) que verifique el estado del Nat Gateway actual y actualice las rutas hacia el otro disponible si comienza a fallar.

He mantenido dos NAT Gateways en España para garantizar alta disponibilidad.
En Alemania he dejado solo uno, ya que no es crítico.
- Si el NAT Gateway fallase en este caso, habría que esperar a que se vuelva a desplegar.

Vamos a por las Bases de datos:

Al eliminar la arquitectura Multi-AZ, ahorraremos más dinero al final del mes. Pero, ¿qué sacrificamos?

Usando la RDS en modo single-AZ, perdemos el SLA del 99.95%.
Cambia el paradigma para recuperar la base de datos si existe algun fallo.
- Para los fallos "recuperables" como problemas en la instancia RDS, el RTO (Recovery Time Objective) será inferior a 30 minutos (esto puede variar según el tamaño de la instancia).
Para los fallos no recuperables, como fallos en el volumen de datos EBS:
- El RTO dependerá del tiempo necesario para iniciar una nueva instancia de RDS y aplicar todos los cambios desde la última copia de seguridad.
- Este proceso debe iniciarse manualmente o automatizarse con un script en Lambda.
Los fallos en la Zona de Disponibilidad requieren una recuperación manual o automatizada mediante restauración en un punto en el tiempo en otra AZ.

Vamos a por las instancias EC2:

Vamos a cambiar el enfoque en nuestra aplicación

Nos hemos cargado el load balancer y la instancia EC2 del servidor web en la AZ B. La IP del NLB ahora la tiene el servidor web.

¿Cuál es la desventaja de hacer esto?

Amazon supervisa la salud del hardware que contiene la aplicación, pero no vigila si la aplicación está funcionando o no, como lo hacía el Load Balancer.
Para poder supervisar si la aplicación está levantada y funciona correctamente, tendríamos que usar los health checks de Route53 y funciones de lambda para detectar posibles fallos y automáticamente borrar esa instancia y así poder degradarla y para que el Autoscaling Group la recree de nuevo.

Pero hay una cosita más... 🤔

¿Qué pasaría si el servidor web automatizase el proceso de encendido de las sondas bajo petición de un usuario a través de la aplicación o en intervalos de tiempo para tomar mediciones y luego las apagase automáticamente?

Podriamos reducir mucho dinero con este scheduler...

Costes aproximados por mes

Probes: 6 instancias EC2 t3.micro (Operando 1 hora 
por día) = 6 VMs x 0.34 USD (30 horas en el mes) 
= 2.04 USD

Servidor Web: 1 instancia EC2 t3.micro (Operando 24h 
al día) = 8.32 USD

2 Internet Gateways: GRATIS
3 NAT Gateways (2 GB de tráfico mensual) = 105.42 USD
VPC Peering entre España y Alemania:
    Cada probe genera 6 MB por día → 180 MB/mes 
    por probe → 1GB de tráfico total = 0.04 USD
Elastic IP: 3.65 USD por IP
RDS Single-AZ (t3.micro): 50.66 USD

Total: 170.13 USD - Factura mensual // 2.22 veces menos

Huella de carbono estimada

8.991 KgCO₂eq (Entre EC2 y RDS) // 4.45 veces menos

Tercera iteración: Sujétame el cubata

Usemos ARM:

Cambiando el tipo de instancia de x86 a ARM Graviton, reduciremos costes, mejoraremos la eficiencia eléctrica y térmica y reduciremos aproximadamente en un 40% la huella de carbono.

Las instancias t3.micro y db.t3.micro se han cambiado a la familia t4g.micro

Nota: En algunos casos, el uso de arquitectura ARM requiere la recompilación de la aplicación. Antes de hacer el cambio y migrar, hay que asegurarse de que es compatible.

¿Qué le habéis hecho a la red?

Es posible bajar la factura a nivel de red, haciendo unos simples cambios, pasando del servicio gestionado del NAT gateway, a NAT instances. (Que son instancias EC2 configuradas para enrutar el tráfico hacia el exterior)

Como comentaba, estamos pasando de un servicio gestionado a construirlo nosotros mismos, puede que esto no sea la mejor opción, ni sea la más eficiente, pero creo que merece la pena mostrar esta posibilidad.

Ventajas:

Ahorro de costes
En combinación con Route53 y un AutoScaling group, podemos crear failover automático, creando un sistema resiliente

Desventajas:

El máximo throughput es de 5Gbps, tendríamos que monitorear este parámetro para asegurarnos de que no llegamos al límite y empezamos a tirar paquetes. En comparación, los NAT Gateways pueden llegar hasta 100Gbps sin despeinarse.
Este diseño implica utilizar una Elastic IP por NAT Instance
No escala por defecto, es necesario gestión manual del servicio.

Este es el tutorial de AWS sobre cómo configurarlo.

En nuestro caso, si la NAT instance fallase en España o Alemania, el tiempo de caída, sería el tiempo que se necesite en volver a desplegarse la instancia de EC2. Este es el sacrificio que tengo que hacer para ahorrar costes.

Costes aproximados por mes

Sondas: 6 instancias EC2 t4g.micro (Funcionando 1 
hora al día) = 6 VMs x 0.28 USD (30 horas al mes) 
= 1.68 USD

Servidor web: 1 instancia EC2 t4g.micro (Funcionando 
24h al día) = 6.72 USD
Instancias NAT: 2 instancias EC2 t4g.micro (Funcionando 
24h al día) = 13.44 USD

2 Internet Gateway = GRATIS
VPC Peering entre España y Alemania - Cada sonda 
generará aproximadamente 6 MB por día = 180 MB 
al mes x 6 sondas = 1GB de tráfico = 0.04 USD

Elastic IP = 3.65 USD por IP x 3 (2 Instancias NAT 
+ Servidor Web) = 10.95 USD
RDS Single-AZ (db.t4g.micro) = 49.20 USD

Total: 8*2.03 USD - Factura mensual // 4.6 veces menos*

Huella de carbono estimada

5.293 KgCO₂eq (Entre EC2 y RDS) // 7.56 veces menos

Conclusión

Esta es la arquitectura más optimizada en cuanto a recursos, siendo la más eficiente y barata. No ha sido nada fácil de visualizar, pero todo empezó a coger forma cuando empecé a dibujar el problema con papel y boli ;)

Este ha sido mi aproximación ante este problema, pero seguro que hay muchos más. ¿Qué hubieras hecho diferente?
Te leo en los comentarios

Let's Architect! - Ping Dashboard

Luis Horvath — Tue, 11 Feb 2025 15:01:01 +0000

Small Architecture Re-cap:

Before jumping to the article, I would like to re-cap some concepts:

What is an Availability Zone (AZ)?

An AZ in AWS is a physically separate and isolated data center (or a group of data centers) within a Region. AWS Regions consist of multiple AZs, with a minimum of 3 AZs per region.

Each AZ has independent power, cooling, and networking, ensuring high availability and fault tolerance.

Why Is It Best Practice to Use Different Subnets in Different AZs for Resiliency?

When designing highly available architectures in AWS, it is considered best practice to distribute workloads across multiple Availability Zones while segmenting different services into different subnets.

For example:

A Database should be on a subnet and in multiple AZs
The frontend should be on a different subnet than the Database and also deployed in different AZs

Following this principle, we enhance the security, improve the scalability, and leverage the security

Public vs Private Subnets

A public subnet has a direct route to the internet.

EG: A web server will be located in the public subnet and will be directly exposed to the internet

A private subnet does not have a direct route to the Internet.

EG: A database will be located in a private subnet and won´t have to be exposed to the internet

It is possible to allow communication from the resources inside of a private subnet to the Internet, but not the other way around. To achieve this, some additional networking services have to be deployed.

Now, yes, let´s jump to it!

Some months ago, a friend challenged me to architect an application.

I selected the topic and started to think about how I could create it, thinking as a solutions architect. The small project escalated, and this is the main reason why you are reading me.

How would you create a ping dashboard?

Thank you, Batman! Exactly, the network!

You can't start building the application without considering the Network scope. I looked at myself in the mirror and started designing how the application would be:

I want to create a Multi-AZ resilient ping dashboard with services exposed to public and private subnets. In the future, I want to extend some parts of my Application to different regions expanding the measurements.

Now that I know which type of structure the network will have, let's deep dive into the Application scope:

The ping dashboard will have a web server accessible via the Internet in a public subnet and display latency data from several virtual machines used as probes from different private subnets.

These probes will take ping measurements to a specific target (URL or IP) sent by the webserver to understand and measure how long it takes from AWS to reach that destination.

The probes will write the data to a database, which will be used by the webserver to expose the data to the end user

VPC Structure

I have selected the eu-south-2 region (Spain) and the IPv4 network 10.0.0.0/24.

Because I don't need so many IPs (a /24 contains 256 IPs), I want to segregate this network into smaller subnets and place different components inside each AZ (in different subnets.)

Let's do some subnetting.

We will pass from /24 to /28; this means that we will have 16 new networks of 16 hosts each (11 usable because AWS reserves 5 IPs).

I have grouped the networks I will use in the different AZs.

AZ A - Networks from the 10.0.0.0/28 - 10.0.0.64/28

There are 5 available networks in this range;
- 10.0.0.0/28
- 10.0.0.16/28
- 10.0.0.32/28
- 10.0.0.48/28
- 10.0.0.64/28

AZ B - Networks from the 10.0.0.80/28 - 10.0.0.144/28

There are 5 available networks in this range;
- 10.0.0.80/28
- 10.0.0.96/28
- 10.0.0.112/28
- 10.0.0.128/28
- 10.0.0.144/28

AZ C - Networks from the 10.0.0.160/28 - 10.0.0.240/28

There are 6 available networks in this range;
- 10.0.0.160/28
- 10.0.0.176/28
- 10.0.0.192/28
- 10.0.0.208/28
- 10.0.0.224/28
- 10.0.0.240/28

Ok, what are we going to build on these networks?

Based on the specifications, we need:

A DB in a private subnet
A probe in a private subnet
A Web Server in a public subnet

In other words, for each AZ, we only need three subnets.

Why don't you put everything in the same subnet?

For security reasons, each component should be isolated from the other. If there is a breach, the network and our firewall rules will limit access to resources from network to network.

Drawing of our design

I have selected 3 networks for the different AZs of the list from above.

Looks sexy, isn't it? Let's continue.

If the application needs to be accessed from the Internet, we must deploy an Internet Gateway. The Internet Gateway is a networking component placed in the VPC that grants access to the Internet to the web server; it does not have to be in any subnet.
The probes need internet access, and we want to restrict external services from reaching them; using a NAT gateway will be the solution. The NAT gateway must be placed in the public subnet, and in combination with the Internet Gateway, it will grant the Internet flow only from the inside to the outside. A NAT gateway will be placed in each AZ.

Is placing one NAT Gateway per AZ necessary?
We will answer this question in the second and third iterations 🌚.

Let's add some EC2 instances!

I have selected the t3.micro for the probes and the web servers.
Yes, web servers, we will allocate two web servers under a Network Load Balancer, which will redistribute the traffic between the AZs. Why not three web servers?
- We will build the web servers inside an AutoScaling group that expands in different AZs.
- If the ELB detects a failure in the application's health checks, the AutoScaling Group will deploy the web server in the same or in another AZ.
- If the AZ fails, the ELB will stop sending the traffic to that instance, and the AutoScaling Group will automatically re-deploy it to another AZ.
The networking probes are not crucial; we can afford failure in them, but not in the application itself.
We will use an Elastic IP to bind the NLB.

Let's add the DBs!

I have chosen an RDS Multi-AZ MySQL architecture with a master database and two DBs on standby.
The Master DB updates the replicas automatically.
If the master DB fails, one of the DBs in Standby will take over.
The Family of the DB for this simple design is the DB.t3.micro

Let's expand our network!

Following the same principle and because we want to extend to other regions for taking measurements, we can create the following services:

A new VPC using the 10.1.0.0/24 in Frankfurt, for example
A public and private subnet for the probe in each AZ
A NAT gateway in each AZ
An Internet Gateway
The probes
VPC peering for interconnecting the new region with the main one

Security Measures

Session Manager will be used to connect to the web server and the probes. Eliminating any possible attack surface. SSH is disabled by default
There will be a Security Group (SG) per service.
- The Web Server SG will allow connections from the NLB
- The NLB will allow connections from the internet
- The Database SG will allow connections coming from the Web Server SG and from the Probes SG
- The Probes SG will allow to send and receive ICMP traffic from everywhere (0.0.0.0) and traffic from the Web Server SG

Approximate costs per month

8 EC2 t3.micro instances (On for 24h // On Demand) = 8 x 8.32USD = 66.56 USD
2 Internet Gateway = FREE
6 NAT Gateways (1 GB of monthly traffic) = 6 x 35.09 USD = 210.54 USD
VPC Peering between Spain and Germany - Each probe will generate about 6 MB per day = 180 MB per month x 6 probes ≈ 1GB of traffic = 0.04$ USD
Network Load Balancer ≈ 20 USD
Elastic IP = 3.65 USD per IP
RDS Multi-AZ (db.t3.micro) = 77.13 USD

Total: 377.92 USD - Monthly invoice

Estimated Carbon footprint
40 KgCO₂eq (Between EC2 and RDS instances)

Second Iteration: Searching for savings

How could we save some money?
What are the tradeoffs we must make to make this possible?

Let's start with the network:

We can eliminate the NAT Gateways that are not indispensable, drastically reducing costs. The NAT Gateway can be placed in one AZ, allowing access to the instances from other AZs.

If this NAT gateway fails for any reason, no instance inside the private subnets can access the Internet until AWS redeploys it.

Because the NAT Gateway is an AWS self-managed service, if it fails, it will be redeployed, but it will take up to 15 minutes to create.

A good approach would be to create an automated failover function (using lambda) that checks the health of the current NAT Gateway and updates the routes to a healthy one if that starts to fail.

I have kept two NAT Gateways in Spain to ensure high availability.
I have left one in the German region because it is not critical.
- If the NAT Fails, in this case, I will have to wait until it redeploys

Let's continue with the DB!:

By removing the Multi-AZ approach, we will save more money at the end of the month. But what are our tradeoffs?

RDS Single-AZ does not have the RDS SLA: 99.95%
Recoverable failures, such as failures with the DB instance.
- Are automatically handled within the same AZ, with RTO under 30 minutes (this can vary depending on the instance size).
Unrecoverable failures, such as the EBS volume.
- The RTO would be the time it takes to start up a new RDS instance and then apply all the changes since the last backup.
- This has to be manually triggered or automated via a lambda script
Availability Zone failures require manual or scripted recovery via point-in-time restoration in another AZ.

Let's end with the EC2:

This will be a paradigm change in our approach.

We have killed the Load balancer and the Web Server instance in the AZ-B. The elastic IP of the NLB has now been delegated to the Webserver

What is the tradeoff of doing this?

AWS monitors the health of the hardware but does not keep track of the health of our application as the Load Balancer did.
- For this case, we should use Route53 health checks and lambda functions to detect failures in the app by automatically deleting the unhealthy instance and replicating it through the Autoscaling Group.

But there is one more thing...

What if the web server automates the process by turning the probes on only when a user requests it through the web interface or at set time intervals to take measurements and then switches them off again afterward?

We could reduce a lot of money with this automated scheduler...

Approximate costs per month

Probes: 6 EC2 t3.micro instances (Working for 1 hour per day) = 6 VMs x 0.34 USD (30 hours in a month) = 2.04 USD
Web Server: 1 EC2 t3.micro instance (Working for 24h per day) = 8.32 USD
2 Internet Gateway = FREE
3 NAT Gateways (2 GB of monthly traffic) = 105.42 USD
VPC Peering between Spain and Germany - Each probe will generate about 6 MB per day = 180 MB per month x 6 probes = 1GB of traffic = 0.04$ USD
Elastic IP = 3.65 USD per IP
RDS Single-AZ (t3.micro) = 50.66 USD

Total: 170.13 USD - Monthly invoice // 2.22 times less

Estimated Carbon footprint
8.991 KgCO₂eq (Between EC2 and RDS instances) // 4.45 times less

Third Iteration: Hold my Beer

Let's swap to ARM:

By changing the EC2 instance type from x86 to ARM Graviton, we will reduce costs, increase electrical efficiency, and reduce the carbon footprint by about 40% compared to the x86 family.

Therefore, the t3.micro and db.t3.micro have been swapped to the t4g.micro family.

Note: In some cases, the use of ARM architecture requires re-compilation of some workloads. Before migrating, make sure the whole application is compatible.

What have you done to the network?

For the sake of saving more money, there is a way to achieve some extra savings by getting rid of the NAT Gateways, but at the cost of adding more overhead to the solution, using NAT Instances instead.

We are moving from having a managed service to building it ourselves, and maybe this is not the best approach, but it is worth pointing out that this possibility exists.

Advantages:

Cheaper price
In combination with an AutoScaling group and Route53, we can create automatic failover, building a resilient system.

Disadvantages:

The maximum throughput is 5Gbps, so we should monitor this parameter to ensure that it does not hit the limit and drop traffic. In comparison, NAT gateways can go up to 100Gbps of throughput.
This design requires an extra Elastic IP per NAT instance.
Manual management of the instance; it does not scale by default

This is the AWS Tutorial on how to configure it.

In our case, if the NAT instance fails either in Spain or Germany, the downtime will be the time to redeploy it. This is the tradeoff I have chosen.

Approximate costs per month

Probes: 6 EC2 t4g.micro instances (Working for 1 hour per day) = 6 VMs x 0.28 USD (30 hours in a month) = 1.68 USD
Web Server: 1 EC2 t4g.micro instance (Working for 24h per day) = 6.72 USD
Nat Instances: 2 EC2 t4g.micro (Working for 24 hours per day) = 13.44 USD
2 Internet Gateway = FREE
VPC Peering between Spain and Germany - Each probe will generate about 6 MB per day = 180 MB per month x 6 probes = 1GB of traffic = 0.04$ USD
Elastic IP = 3.65 USD per IP x 3 (2 NAT Instances + Web Server) = 10.95 USD
RDS Single-AZ (db.t4g.micro) = 49.20 USD

Total: 82.03 USD - Monthly invoice // 4.6 times less

Estimated Carbon footprint

5.293 KgCO₂eq (Between EC2 and RDS instances) // 7.56 times less

Conclusion

This is the most optimized architecture regarding resources, being the most efficient and cheapest. It was not easy to visualize, but everything started to become smooth when I started drawing the problem with paper and a pen.

This is my approach to this problem, but there are plenty of solutions. What would you have done differently? I read you in the comments.

PS: Should AWS promote this type of exercise for the community and hold architecture contests?

¿Qué es MACsec, y por qué es importante?

Luis Horvath — Thu, 16 Jan 2025 16:47:40 +0000

El mes pasado aprobé la certificación de AWS Advanced Networking. Y sí, hay que llevar vaselina, no porque los temas sean muy amplios, si no por la profundidad de lo que se te pregunta.

Uno de los temas a evaluar, es MACsec en distintos escenarios. Pero, ¿qué es MACsec?

Antes de hablar sobre ello, primero deberíamos entender qué es el servicio Direct Connect, también conocido como DX. Pero antes, veamos un par de ejemplos 👀.

¿A cuántos os ha pasado esto en el pasado? 😂

Imagina que eres el arquitecto de redes responsable de la noche de ventas del Black Friday para una empresa online con muchos 0s en ventas.

Tienes cargas de trabajo repartidas entre tu infraestructura de on-premises y AWS.

Tu aplicación depende de conectividad VPN.

Las rebajas empiezan, pero algunos sistemas empiezan a fallar por timeouts; poco a poco, nada funciona, y los clientes no pueden navegar ni comprar...

Ahora imagínate la cantidad de pasta que la empresa va a perder por un segundo si los sistemas fallan en medio de una campaña grande de ventas. Estamos hablando de millones de euros o dólares en beneficios...

Tu jefe tendrá este temazo en la cabeza, para tu último 1&1.

El servicio de Direct Connect crea conexiones de red dedicadas entre la infraestructura on-premises de los clientes en los centros de datos y AWS, evitando el uso de la internet pública.

Este servicio nació en 2011 para solucionar la falta de control y transparencia en las cargas de trabajo híbridas que surgía al usar VPN a través del internet público.

Imagina que vas por una autopista privada donde tu información se mueve sin atascos, a la velocidad que tu elijas. Técnicamente hablando, te estarías conectando directamente hacia AWS mediante fibra óptica. Ya no dependes del internet público, y además cuentas con un SLA.

He preparado una pequeña comparación con los pros y contras de cada servicio.

VPN Por internet

En un escenario híbrido en la nube, el VPN es la forma más rápida de lograr conectarnos, pero tiene algunos inconvenientes:

La conexión está Cifrada, pero no es privada; fluye a través de internet
No hay SLAs de extremo a extremo
Riesgo de DDoS
Latencia impredecible: No hay control sobre el enrutamiento; esto impacta la latencia
Ancho de banda limitado: hasta 1.25 Gbps por flow (Puede escalar con el uso de un transit gateway y ECMP)
Barato de configurar, pero caro de usar. El tráfico de descarga se encarece mucho después de cierto volumen de datos

AWS Direct Connect

Esta solución no es la más rápida ni la más barata de desplegar; es más complicada de diseñar, pero ofrece algunas ventajas como:

La conexión está libre de ataques DDoS, está fuera del internet público
La conexión es privada, pero no está cifrada por defecto (posibilidad de cifrado con MACsec 👀 o IPsec)
Latencia predecible y estable
Alto ancho de banda – desde 50 Mbps hasta 400 Gbps Puedes usar LACP para crear un LAG y agrupar enlaces juntos trabajando como uno solo (hasta 4 veces 10GE y 2 veces 100GE)
Solución rentable después de cierto volumen de datos descargados ya que el tráfico es más barato
Se pueden lograr arquitecturas resilientes avanzadas (con un diseño adecuado)
Conexión respaldada por un SLA de nivel empresarial

¿Qué elegir: VPN o Direct Connect?

Esto dependerá de las necesidades de la empresa; normalmente el SLA, la latencia, el ancho de banda y el tiempo de implementación son algunos de los factores que te pueden ayudar a tomar la decisión final.

La resiliencia y el SLA son factores críticos en nuestro ejemplo. Así que está clarísimo por qué tendríamos que haber tenido este Direct Connect en lugar de depender del VPN.

El servicio de Direct Connect viene en dos versiones: Hosteada o Dedicada.

Conexiones Hosteadas: es una VLAN proporcionada por un partner de conectividad de AWS. El partner al tener los puertos contra AWS levantados, vende la "capacidad" en base a las necesidades del cliente. Estas VLANs empiezan desde 50Mbps hasta 25 Gbps. Permite mucha más flexibilidad que una conexión dedicada en cuanto a anchos de banda
Conexiones dedicadas: es un puerto físico entero para el cliente contra AWS. Requiere que el cliente esté físicamente en un centro de datos donde AWS ofrezca el servicio de Direct Connect. Los anchos de banda disponibles son 1, 10, 100 y 400 GE.

Ok, ¿pero qué coj**** es MACsec?

MACsec (802.1AE) significa Media Access Control Security.
Es un cifrado punto a punto de Capa 2, que añade una capa de seguridad extra en los Direct Connects Dedicados (no hosteados).

MACsec está disponible en algunas localizaciones, pero no todas están soportados. Este cifrado está disponible únicamente para puertos de 10, 100 y 400GE.

MACsec da:

Confidencialidad: cifrando la información que se envía (el payload se cifra).
Integridad de los datos: añadiendo mecanismos adicionales para asegurar que los datos no puedan ser modificados durante el tránsito sin ser detectados.
Autenticidad del origen de los datos: ambas partes pueden ver que los frames han sido enviados por el otro dispositivo y verificarlo.
Replay protection: los atacantes no pueden capturar y reenviar frames antiguos para engañar al sistema.
Super alta velocidad: está diseñado para funcionar a lo que de el puerto

Conceptos de MACsec:

El MACsec Key Agreement Protocol (MKA) gestiona el descubrimiento de sistemas, la autenticación y la generación de claves de cifrado

Ambos routers deben estar asociados con una Connectivity Association Key (CAK) y un Connection Key Name (CKN). La CAK es una clave secreta compartida, mientras que el CKN es un identificador para la CAK. La misma CAK/CKN debe configurarse en ambos dispositivos.
Secure Association Key (SAK): Esta es la clave generada por el MKA utilizando el par CKN/CAK proporcionado. La SAK generada cifra el payload del frame.

Secure Channel: Cada router crea un Canal Seguro para enviar tráfico al otro participante. Dado que son unidireccionales, un canal se usa para enviar y el otro para recibir. Los Canales Seguros se asignan un Identificador, el Secure Channel Identifier (SCI).

¿Cómo MACsec encapsula un frame?

MACsec modifica los Ethernet frames, insertando un Security Tag (SecTAG) y un Integrity Check Value (ICV). El Ethertype y el Payload se encapsulan y cifran mediante la SAK.

El SecTAG contiene información sobre el Número de Paquete (Packet Number), el Secure Channel Identifier (SCI) utilizado para enviar tráfico entre los dispositivos, y otros flags de control.

El ICV permite al dispositivo receptor verificar la integridad y autenticidad del frame. Si, por alguna razón, se recibe un valor diferente al esperado, el frame será descartado.

La información (Payload) no puede ser descifrada sin la SAK, y con todos estos mecanismos, el intercambio de información es seguro.

¿Cómo funciona?

MACsec realiza tres fases :

Negociación de sesión: Ambos routers usarán MKA y generarán la misma SAK para cifrar la información. Huawei tiene una excelente guía en cómo se negocia la sesión en este paso: MACsec Key System
Comunicación segura: El emisor usa la SAK para cifrar los datos, y el receptor la usa para descifrarlos. Si el frame ha sido alterado, o el número del paquete es repetido o incorrecto, el frame será descartado.
Mantenimiento de la sesión: El protocolo MKA define un temporizador de sesión (session keepalive). Si, después del límite, no hay comunicación entre los dispositivos, la sesión se declarará insegura y el proceso de negociación comenzará de nuevo.

¿Cómo se configura?

Tan fácil como seguir la guía de 5 pasos de AWS.

¿A quién le puede interesar esto?

Las empresas que manejan información sensible o confidencial requieren cifrado punto a punto para evitar la interceptación de datos y asegurar la integridad de la información durante su transmisión.

¿Cuales son los pros comparado con VPN IPsec?

Debido a que la información está cifrada en Capa 2, MACsec escala desde megabits hasta terabits por segundo. Con MACsec, podemos alcanzar velocidades cercanas al ancho de banda total del puerto.
MACsec es más fácil de configurar y gestionar que un VPN IPsec.
MACsec funciona en la Capa 2, siendo agnóstico a los protocolos de capas superiores. Las aplicaciones y configuraciones de red no necesitan estar al tanto de MACsec.

¿Y las contras?

MACsec requiere Direct Connect Dedicado, que tiene costos iniciales más altos que usar una VPN por internet.
Dado que MACsec solo está disponible en DX Dedicados, debes de encontrarte en un PoP (Punto de Presencia) de AWS para el servicio de Direct Connect. También puedes depender de un partner de conectividad capaz de extender los frames MACsec desde tu PoP hasta AWS, como DE-CIX. Esto limita la flexibilidad en comparación con IPsec, que funciona sobre cualquier conexión a internet.
Aunque MACsec sea un estándar, no todos los dispositivos de red lo soportan. Esto puede incluir en costes para adquirir nuevos equipos que sean compatibles.
MACsec es un cifrado punto a punto que solo protege el enlace entre dos dispositivos. Si tus datos viajan más allá del Direct Connect, MACsec no puede asegurarlos.

En conclusión, MACsec proporciona la seguridad que le faltaba al servicio de Direct Connect, cifrando en Capa 2 y garantizando la integridad y privacidad de los datos a través de conexiones dedicadas a toda velocidad.

Es la alternativa perfecta al VPN para conexiones de alto ancho de banda.

Ahora que sabes cómo asegurar tus cargas de trabajo híbridas, evita hacer esto en tu aplicación 🌚

Si te gustó este artículo, dale ❤️ y asegúrate de seguirme en dev.to, ¡nos vemos en mi próxima ida de olla!

What is MACsec, and why is it important?

Luis Horvath — Thu, 16 Jan 2025 16:47:38 +0000

Last month, I cleared up the AWS Advanced Networking certification.
It was a challenging exam, where the topics were not too broad but too deep.

Diving through the Direct Connect service, you will be asked about MACsec in different scenarios. But what is MACsec?

Before discussing it, we should understand the Direct Connect service, aka the DX service. But first, let's go through a couple of examples 👀

How many of you have experienced this in the past? 😂

Imagine you are the networking architect responsible for Black Friday's sales night of an important e-commerce.

You have workloads between your on-premises and AWS, and your app relies on VPN Connectivity. The sales are starting, and some systems are failing because of timeouts; slowly, nothing is working, and the customers can't navigate through the website...

Imagine for one second the amount of money big e-commerce companies can lose if their systems fail during sales time. We are speaking about millions of dollars/euros of lost revenue, and your boss will have this banger in the head for your last 1&1.

The Direct Connect service creates dedicated network connections between customers on-premises in a Data Center and AWS, outside the public internet.

It was born in 2011 to end the lack of control and transparency of hybrid workloads caused by using VPN through the public internet.

Imagine having a private highway where your information flows and where there are no traffic jams. Technically speaking, you are directly connected from your router to the edge router of AWS using fiber. You no longer rely on the public internet to connect there, and you have SLA.

I have crafted a small comparison of the pros and cons of each service.

VPN Over the Internet

In a hybrid-cloud scenario, VPN is the fastest way to achieve the goal, but there are some downsides if you have to rely on the solution:

The connection is Encrypted, but it is not private; it flows through the internet
No end-to-end SLAs
DDoS risk
Unpredictable latency - There is no control over the routing; this impacts the latency
Limited throughput – up to 1.25 Gbps per flow - (It can scale with the use of a transit gateway and ECMP)
Low setup costs but high egress traffic costs after a certain amount of data

AWS Direct Connect

This solution is not the fastest/cheapest to deploy; it is more complicated to design, but it provides some advantages like:

DDoS free - the connection is outside of the public internet
Private Connection but not encrypted by default (possibility of MACsec 👀 or IPsec encryption)
Predictable and Stable latency
High throughput – from 50Mbps up to 400Gbps
You can use LACP to create a LAG and bundle links together working as one (up to 4 times 10GE and 2 times 100GE)
Cost-effective solution after a certain amount of downloaded/egress data
Advanced resilient architectures can be achieved (with a proper design)
Connection backed with an enterprise-grade SLA

What to choose: Direct Connect or VPN?

This will depend on the company's needs; SLA, latency, bandwidth, and time to deploy are some factors that will help you make the final decision.

Resiliency and SLA are critical factors in our example. So, it's crystal clear why we should have had this type of setup rather than relying on a connection that doesn't have SLA, and we can't control.

The Direct Connect service comes in two flavors: Hosted or Dedicated.

Hosted Connections: VLANs provided over an AWS Direct Connect partner. The partner owns and manages the physical connection. The customer can create VLANs that start at 50 Mbps and continue to 25 Gbps.

Dedicated Connection: physical port provisioned directly to a customer. It requires setting up a cross-connect at an AWS Direct Connect location (extra charges) per port. The available bandwidths are 1, 10, 100, and 400 GE.

Okay, but what is MACsec?

MACsec (802.1AE) stands for Media Access Control Security.
It is a point-to-point Layer 2 encryption, which adds an extra security layer at Dedicated Direct Connects.

MACsec is available at some locations, but not all of them are supported.
This encryption is available for ports of 10, 100, and 400GE.

MACsec provides:

Confidentiality: by encrypting the information that is sent (the payload is encrypted).
Data Integrity: by adding additional fields to ensure that data cannot be modified in transit without being detected.
Data Origin authenticity: both parties can see that frames have been sent by the other trusted peer in a MACsec relationship.
Replay protection: attackers cannot capture and resend old frames to trick the system
Super high-speed encrypted throughput: it is designed to work at near-line-rate speeds

MACsec Concepts:

The MACsec Key Agreement Protocol (MKA) manages peer discovery, authentication, and encryption key generation.

Both routers must be associated with a Connectivity Association Key (CAK) and a Connection Key Name (CKN). The CAK is a shared secret key, while the CKN is an identifier for the CAK. The same CAK/CKN must be configured on both devices.
Secure Association Key (SAK): This is the key generated by the MKA using the CKN/CAK pair provided. The generated SAK encrypts the frame payload.

Secure Channel: Each router creates a Secure Channel to send traffic to the other participant. Because they are unidirectional, one channel is used to send and the other to receive. The Secure Channels are assigned an Identifier, the Secure Channel Identifier (SCI).

MACsec encapsulation

MACsec modifies the ethernet frames by inserting a Security Tag (SecTAG) and an Integrity Check Value (ICV). The Ethertype and the Payload are encapsulated and encrypted by the SAK.

The SecTAG contains information about the Packet Number (PN), the Secure Channel Identifier (SCI) used to send traffic between the devices, and other control flags.

The ICV allows the receiving device to verify the integrity and authenticity of the frame. If, for any reason, a different value than the expected is received, the frame will be dropped.

The information (Payload) can not be decrypted without the SAK, and with all these mechanisms, the exchange of information is secure.

How does it work?

The MACsec interaction process consists of three phases:

Session Negotiation: Both routers will use MKA to authenticate peers and generate the same SAK to encrypt the information. For a detailed view of this step, Huawei has a great guide: MACsec Key System
Secure Communication: The sender uses the SAK to encrypt the data, and the receiver uses it to decrypt it. If the frame has been tampered, or the packet number is repeated or incorrect, the frame will be dropped.
Session keepalive: The MKA protocol defines a session keepalive timer. If, after a time, there is no communication between the devices, the session will be declared as insecure, and the negotiation process kick again.

How is the setup?

It´s as easy as following the 5-step guide from AWS.

Who is the target?

Companies that handle sensitive or confidential information require point-to-point encryption to prevent data snooping and ensure the integrity of the information during transmission.

What are the pros compared to an IPsec VPN?

Because the information is encrypted at Layer 2, MACsec scales from megabits to terabits per second. With MACsec, we can reach near-line-rate speeds.
The MACsec is easier to set up and manage than IPsec VPN.
MACsec works at Layer 2, being agnostic to higher-layer protocols. Applications and networking configurations don´t need to be aware of MACsec.

What are the cons?

MACsec requires Dedicated Direct Connect, which has upfront higher costs than using a standard VPN over the internet.
Since MACsec is only supported on Dedicated DX, you must colocate in an AWS DX PoP (Point of Presence) or rely on a connectivity partner capable of extending MACsec frames to AWS locations like DE-CIX. This limits flexibility compared to IPsec, which works over any internet connection.
While MACsec is a standard, not all networking hardware supports it. This may require upgrades to compatible gear to support this technology.
MACsec is a point-to-point encryption that only protects the link between two devices. If your data travels beyond Direct Connect, MACsec can’t secure it.

In conclusion, MACsec provides a powerful security solution for AWS Direct Connect, offering Layer 2 encryption that ensures data integrity and privacy over dedicated connections at near-line-rate speeds. It is the perfect alternative to IPsec VPNs for high throughput connections.

Now that you know how to secure your hybrid workloads, avoid doing this in your application 🌚

If you liked this article, give it some ❤️ and make sure to follow me on dev.to, see you in the next networking article!

Optimize your IPv4 workloads in AWS and save money on the way!

Luis Horvath — Thu, 01 Feb 2024 19:23:25 +0000

Cover image by Sander Weeteling on Unsplash

Introduction

AWS announced in July 2023 that it would charge all Public IPv4 addresses beginning February 1, 2024.

Until now, AWS only charged Public IPv4 addresses when they were unassigned, and some people think it's terrible that AWS is trying to gain more money ...

But other people like us think that's not a big deal and is an excellent opportunity to save IPv4 addresses.

We have a big problem with IPv4 Addresses; when DARPA (Defense Advanced Research Projects Agency) wrote the protocol in 1981, nobody thought that 4.294.967.296 IPs would be exhausted on the feature.

At that time, personal computers were rare, the Web didn't exist, and nobody could imagine the idea of smartphones.

In 2011, IANA (Internet Assigned Numbers Authority) assigned the last IPv4 address blocks. If you need an IPv4 address, you will buy it from anyone with an IPv4 address without using it, which creates a lot of problems for any company that needs an IPv4.

At the end of 1995, the Internet Engineering Task Force (IETF) started to write a new protocol (IPv6) because they knew at that moment that IPv4 addresses would be exhausted in a few years. Internet was in early adoption (Few people use it).

The adoption of IPv6 is too slow. Many Telecommunications Companies use IPv6, and we, as users of them, use IPv6. Still, many companies that publish services on the Internet don't use it because it is a hard change to implement quickly.

That's the reason for this change. We need to use fewer IPv4 addresses; if AWS doesn't charge, we will continue using many IPv4 addresses.

And the big questions that you may be asking:

How many IPv4 addresses are we using on AWS?
How much will AWS charge me?
How can we save IPv4 easily without using IPv6?

How to list the IPv4 Space in use

Some time ago, AWS released a tool for listing, analyzing, and auditing the public IPv4 space being used. This tool is called Amazon VPC IP Address Management (IPAM).

Before deepening dive into this topic, we must differentiate four types of public IPv4 addresses in AWS:

EC2 public IP addresses:
Public IPv4 addresses are taken from an Amazon pool and are only associated with the EC2 instances. When stopping, hibernating, or terminating the instance, the IP gets released back to the pool, and you cannot reuse it.
Elastic IP addresses:
Public IPv4 addresses that can be allocated to your account. They can be associated and disassociated from instances as required. They are allocated until you choose to release them (from the account & not the service)
Service-managed public IPv4 addresses
AWS internet-faced-managed services deployed in your account:
Elastic Load Balancers, NAT Gateways, AWS Global Accelerator, AWS Site-to-Site VPN...
BYOIP addresses
AWS will not charge you for bringing your own IP Space
These IPs can be used in pools to assign to your EC2 instances or NAT Gateways.

Having this in our mind, it is time to use the Amazon VPC IPAM to check the public IPv4 space that is in use and its resources.

Log in to your AWS account.
Search for Amazon VPC IP Address Manager in the search bar.

Click on “Create IPAM”
Select the marked options:

Notes:

The Free Tier will perform the checks on your organization for public IPv4 usage
The Advanced Tier will check on your organization for both public and private IP addresses, at a cost

You can add a name tag or a description to it - optional
Click on “Add All Regions” to perform a report on our global infrastructure
Click on “Create IPAM.”

After some minutes, you will be able to see a report with all the IPv4s your organization is using under the Public IP Insights menu:

For each IPv4 in use, AWS will bill $0.005 per hour; this means 0.005 x 8760 hours in a year = $43.8 per year for each IPv4

If you have 10 IPs in use, you will pay $438 for this IP space.
If you have 100… it will sum to $4380
If you have 1000… well... add another 0

Your face before and after using the IPAM tool.

How can I reduce the IPv4 usage?

To use a Load Balancer

Using a Load Balancer to expose our application is an AWS Best practice and reduces the number of Public IPs; instead of using one IP for every EC2, we will use one IP per subnet where the ALB is deployed.

Advantages:

You improve your availability because the ALB is working on a high availability setup.
You strengthen your scalability using Auto Scaling groups as a target of Load Balancer.
You can offload SSL using certificates on Load Balancer.
Your security can be better using WAF rules.
You can use HTTP or HTTPS ports using ALB or any TCP ports using NLB.

Disadvantages:

Cost (Not too much, but add cost to your solution)

To use a Load Balancer doing a reverse proxy

What happens if we deploy a lot of Load Balancers with few servers? That is a problem because we are wasting a lot of IPs (and Load Balancers)

Since 2017, AWS has supported using an Application Load Balancer like a reverse proxy. This is a remarkable improvement because we can use one load balancer for multiple target groups depending on the host header with your requested URL.

With this feature, you can use only a load balancer for your entire application.

But what happens with the encryption? We need to use multiple certificates, one per URL.
You could use the same DNS zone and a wildcard. Still, it is not a very good idea, and security teams don't like wildcard certificates (Exist some security issues with wildcard certificates …)
But we can use another cool ALB feature like SNI (Server Name Indicator) that permits using multiple certificates for different DNS names in the same ALB.

Advantages

Reduce the number of Public IPs used by our applications
We Reduce the number of ALBs used by our applications.
We are saving costs because fewer ALBs and public IPs mean fewer costs for us.
We Centralize the management of ALBs.

Disadvantages

We Create a dependency on other teams. If we have multiple stacks to manage every application, we create a dependency with the stack that contains the centralized ALB.
It could be a problem using WAF because WAF rules are the same for all applications, and some rules must be more specific.
The solution only works on a multi-account deployment. ALB can send requests to target groups in the same account but not to target groups in other accounts. ALB permits sending requests to other accounts' IPs (If private connectivity exists), but that does not allow elasticity. We can use a reverse proxy server mount on an EC2, but it is not a managed solution and creates more operational overhead.

To use a Bastion

Using a Bastion host is a typical solution to access your cloud servers; instead of adding a public IP address to any server that we manage, we create a Bastion Host with a public IP and log into this Bastion Host using SSH or RDP (Depending on our Bastion Hosts OS). From this bastion, we can jump to our EC2 or RDS.

That is a secure way to access your resources because we can limit the scope of our security group by adding only the public IPs we use from our corporate network or individual public IPs from our internet connection.

From our Bastion Host, we can access any EC2, RDS, ECS, EKS, etc.
We only need to add our Bastion Host security group or IP to the security groups for the instances we need access.

We can access our VPC, but we can also access other VPCs if we implement VPC peering or deploy a Transit Gateway topology.
These interconnections between VPCs allow us to centralize our Bastion host and reduce and simplify our management infrastructure.

That method is easy to use; Bastion Host is something usual on on-prem; we can use different access keys, different OS users, log access, etc.

Also, if we need a more secure way to access, we can use a Client VPN instead of connecting directly to our Bastion Hosts using SSH or RDP.

Advantages

We reduce the number of Public IPs used for managing instances.
We improved security because we had fewer entrance points to our servers.
We need to maintain fewer instances for management.
Baston Host is a familiar topology for IT infrastructure.
We can log access to the Bastion host and audit the activity.

Disadvantages

We need an EC2 for management.
We must manage and audit security groups to limit access to our Bastion Host.
We can have considerable exposure to our infrastructure if someone gains access to our Bastion Host.
We can receive SSH brute force attacks and must protect ourselves from them.

To use the Session Manager

AWS Systems Manager Session Manager (SSM) is a way to access our EC2 like an SSH but without SSH and with many benefits of AWS security out of the box.

To use the AWS Systems Manager Session Manager, we need to accomplish some tasks:

We need to have the SSM agents installed on our instances (If we use an AMI from AWS, the agent is installed by default).
The Instance needs access to the SSM endpoint using a NAT Gateway or deploying an AWS private endpoint.
We need to add an Instance profile with permissions to SSM to permit the EC2 to execute some API calls to SSM services.
We need permission to use SSM on our IAM user or IAM role.

We can follow AWS Documentation to configure.

This access method permits one to log on to an instance without using SSH and use our IAM credentials.
That's very useful because we can use the IAM Identity Center and centralize access to our systems using our IdP credentials instead of Linux Local credentials.
Also, if we use IAM Identity Center or IAM Roles, we are using temporary security credentials that significantly improve our security. Those credentials rotate very often (they are only active for a few hours or less if we choose). If someone stole these credentials, they would be revoked automatically when the token expires, and we can also revoke the credentials immediately.

If we use Windows servers, we can use AWS Systems Manager Fleet Manager, which uses a similar system but for RDP connections.

Also, we can use a mixture using SSM with a private Bastion Host.

That is the same method as if we are using a Bastion Host but without exposure to our Bastion Host on the Internet.

However, SSM is unusable for some people because they need to use X11 on remote servers or upload files using SCP or their terminal instead of the AWS console or AWS CLI.

But we are lucky; SSM has a feature named Port Forwarding that permits us to create a tunnel from our computer to the Bastion Hosts and connect to other servers directly. It is like an SSH tunnel and is very powerful. We can access our RDS servers or private websites without publishing them. We can also forward X11 and use the remote displays.

Advantages

We don't need to use Public IPs
We use IAM credentials with temporary credentials instead of Linux credentials or SSH keys.
We can use our IdP credentials to log on to EC2 instances.
We use an HTTPs encrypted connection encrypted by AWS.
We don't expose servers on the internet.
We can audit logs and actions.
We can explore logs on Cloudwatch and create metrics and alarms.
We can revoke credentials automatically.
We can use the port forwarding feature to create secure tunnels
The solution doesn't have any cost; SSM is free.

Disadvantages

We must use AWS CLI or AWS console to connect to servers.
The method is more complex and needs to be more familiar to users.
We need to install agents and create Instance profiles.

To use private EC2 Instance connect

The service EC2 instance connect allows you to connect to your public/private EC2 instances by establishing an SSH session through the browser. The Instance Connect API will publish a one-time use SSH public key to the EC2 instance metadata, which will remain for 60 seconds.

If the instance has the EC2 instance connect installed, an SSH daemon will pull the public key information from the instance metadata for authentication in this timeframe.

The SSH connection will be established using the one-time use private key that the Instance Connect API generated at the time of the request.
IAM backs the service; no user who doesn´t have access to this service will be allowed to connect. For more information on how the service works, follow the user guide.

Initially, the EC2 instance connect was meant to connect to EC2 instances with a public IP address. In June of 2023, AWS released an update on this service, allowing users to connect to the EC2 instances with Private IP through the internet.

To perform this task, create an EC2 instance Connect Endpoint in a private subnet in your VPC. This endpoint acts as a private tunnel connecting from the internet to your private instances. You can connect to different subnets inside the VPC using the same endpoint.
(If you connect to an instance in a different AZ from the Endpoint, some charges may apply)

Here, you can find a how-to guide on connecting using the EIC Endpoint to a private IPv4 instance.

Advantages

You can connect to your instances from the internet without an internet gateway.
The access for creating and using the EC2 Instance connect endpoints can be restricted/granted through IAM policies and permissions.
Improve the security by having a centralized access control to EC2 instances and removing the need to manage the SSH keys.
Removes the need for a Bastion host.
CloudTrail tracks all the events.

Disadvantages

It does not support IPv6 addresses.

To Migrate to IPv6

Since 2011, AWS has been promoting IPv6; every year, AWS has been adding and adapting more services to use this technology.

Networking compatibility modes supported by AWS:

IPv4-only mode: Your resources can communicate over IPv4; if they communicate with IPv6, it will require an interoperability layer.
IPv6-only mode: Your resources can communicate over IPv6; if they communicate with IPv6, it will require an interoperability layer.
Dual-stack mode: Your resources can communicate over IPv4 and IPv6.

Under this article, you will find the list of services that can use IPv6.
For more information on how to design an IPv6 network, follow the Best Practices runbook

Advantages

Reduce costs by stopping using IPv4
Eliminates the need for translation mechanisms (NAT), removing performance overheads of translations, simplifying the routing of packets
IPv6 adds more security, using IPsec as a standard

Disadvantages

Not all the services support IPv6
An architecture analysis should be done before implementing/adapting anything.

Article created for the AWS Community Builders by:

Miguel Angel Muñoz Sanchez

Luis Maria Horvath Mayor

Ahorra hasta 3 veces más dinero en la migración de un Cloud hacia AWS...

Luis Horvath — Thu, 19 Oct 2023 15:19:03 +0000

¿Alguna vez has usado un proveedor de servicios Cloud, convencido/coartado de que era una buena idea, y te arrepentiste? ¿Estás considerando mover los datos de tus aplicaciones a otro Cloud como AWS?

Subir todo a la nube es fácil, no pagamos nada por los datos que subimos (ingress), la transferencia es gratuita.

Pero amig@ mío, en el momento en el que tienes cierta cantidad de datos en el Cloud y tienes que bajarlos, ahí se complica la cosa...

Todo el tráfico de descarga (egress data) se factura y cobra en la mayoría de Clouds.

No hay duda de que migrar 20 GB es una tarea fácil, pero cuando tienes un volúmen de datos más grande (por ejemplo, +100 TB), deberías de saber qué opciones tienes...

AWS lanzó el servicio Snowball algunos años atrás para migrar cantidades enormes de datos desde on-prem hacia el Cloud de AWS.
Microsoft tiene el mismo servicio (Azure Data Box), y Google también (Transfer Appliance)...

Todos estos dispositivos tienen algo en común, y es que no puedes mandarlos a un Cloud para migrarte del Cloud A al Cloud B, esto no funciona así...

¿Qué opciones tenemos si queremos migrar de un Cloud a otro?

Usar IPsec VPN a través del internet público: Opción recomendada por el 95% de los mortales; es lo que recomendarán usar cuando tengas que migrar datos de un CSP a otro.

Retos con VPN

El coste del tráfico de descarga a partir de cierta cantidad de datos es muy elevado
El caudal está limitado
El tráfico viaja a través de internet

¿Y si te digo que hay otra manera de hacer esta migración, ahorrando hasta 3 veces más dinero en relación al tráfico de descarga?

Usar un Cloud ROUTER:

Muchos partners de conectividad han desarrollado este tipo de solución para tener un hub de enrutamiento centralizado para operaciones multi-cloud y multi-cloud híbridas.

Con el uso de esta tecnología, te puedes ahorrar mucho dinero en la migración ya que el coste de transferencia de datos es mucho menor para una conexión privada que usando VPN.

No necesitas estar presente en un centro de datos para montar una arquitectura multi-cloud. Todo está preparado, no necesitas hacer nada más.

El Cloud ROUTER unifica los distintos servicios de conectividad privada de los diferentes Clouds (AWS Direct Connect, Azure ExpressRoute, Google Interconnect...), y los interconecta de manera fácil y rápida.

Dependiendo de la configuración, puedes crear conexiones de alto rendimiento desde los Clouds y migrar los datos en horas o minutos.

Vamos a comparar los distintos precios de descarga para AWS, Google, y Azure.

Transferencia de datos usando VPN

Transferencia de datos usando Direct Connect: Datos localizados en Europa, saliendo por una localización de Direct Connect en Europa -> $0.0200 por GB

Transferencia de datos usando VPN

Transferencia de datos usando Google Interconnect: Datos saliendo por una conexión de Google Interconnect en Europa -> $0.0200 por GiB

Transferencia de datos usando VPN

Transferencia de datos usando Express Route: Datos en Europa, saliendo por una conexión de Express Route en Europa -> $0.025 por GB

Como podéis observar, el VPN es mucho más caro a la hora de transferir datos que con una conexión privada.
Hagamos un pequeño ejercicio...

Agárrense los machos, se viene la migración...

Ejercicio

Somos un arquitecto de redes, y nuestro amable CTO nos manda la tarea de migrar desde Azure hacia AWS. Tenemos que migrar unos 180 TB de datos de nuestro Azure Blob Storage hacia nuestro bucket en AWS S3.
Nuestros datos se encuentran en Europa.

Hagamos el cálculo; para ello voy a usar la calculadora de Azure:

Transferencia de Datos - 180TB	Precio
via Internet	$10,768.80*
via Express Route	$4,608.00

Los primeros 100GB de tráfico de descarga por internet son gratis*

Si comparamos las cantidades, usando Express Route, es 2.33 veces más barato que usando internet para transferir los datos.

Hagamos el mismo ejemplo, pero con Google:

Transferencia de Datos - 180TB	Precio
via Internet	$11,571.20*
via Google Interconnect	$3,686.40

Los primeros 200GB de tráfico de descarga por internet son gratis*

Es 3.14 veces más barato realizar la migración usando Google Interconnect que yendo por internet para la transferencia de datos.

¿Y qué pasaría si hiciéramos el mismo cálculo con AWS?:

Transferencia de Datos - 180TB	Precio
via Internet	$13.107,20*
via Direct Connect	$3686,40

Los primeros 100GB de tráfico de descarga por internet son gratis*

Resulta que es 3.55 veces más barato hacer la migración con Direct Connect que moviendo los datos a través del internet público.

Nota:
Estos cálculos no incluyen los costes relacionados del Express Route/Google Interconnect/Direct Connect ni los servicios relacionados como PrivateLink o el Cloud Router...

La solución completa, con los costes relacionados es más barata que si se migrase a través del internet público.

Para más información acerca de precios, pregunta a tu partner de conectividad para tu caso en concreto.

Conclusiones finales

Es esencial saber qué opciones tenemos cuando hacemos una migración de este tipo; cuantas más tengamos, mejor.

Con el uso de este tipo de tecnologías, el hacer una migración de Clouds see simplifica, asegurando el máximo rendimiento y minimizando costes.

Espero que hayas disfrutado de este artículo; te leo en los comentarios 😁

Save up to 3 times more money when migrating from a Cloud to AWS...

Luis Horvath — Thu, 19 Oct 2023 10:20:43 +0000

Have you ever used a Cloud Service Provider (CSP), convinced that it was a good idea, and you regretted it? Are you considering moving your application's data to another CSP like AWS?

Uploading everything to the Cloud is easy because the data that goes in (ingress) is free of charge...

But my friend, from the moment you have a certain amount of data in the Cloud and have to download it, it is when the stuff gets challenging...

All the egress traffic (downloaded data) is getting billed in most of the CSPs.

There is no doubt that moving 20 GB is an easy task, but when you have logs or information that is considerably big (for example, +100 TB), you should know what options you have.

AWS released the Snowball service some years ago for migrating vast amounts of data from on-prem to the AWS Cloud. Microsoft has its service (Azure Data Box), and Google too (Transfer Appliance)...

These devices have some in common, and you can not ship them to a CSP for migrating from Cloud A to Cloud B. This doesn´t work.

What options are left if we migrate from one CSP to another?

To use IPsec VPN through the internet: It will be recommended by 95% of the population; it is the way to go for these cases where we have to move data from one CSP to another.

Challenges with VPN

Huge Egress traffic costs at a certain amount of data
Limited throughput
The traffic gets exposed to the internet

What if I tell you that there is another way to perform this task, saving up to three times the money in terms of data transfer?

To use a Cloud ROUTER:

Many connectivity partners have developed this solution to have a centralized routing hub for serving multi-cloud and hybrid-multi-cloud operations.

With this technology, you can save much money for migrating because the data transfer price is much lower for a private connection than via VPN. The best part is that you don´t need any equipment in the Data Center for a multi-cloud setup; everything has been set.

The Cloud ROUTER unifies the different Cloud private connectivity services (AWS Direct Connect, Azure ExpressRoute, Google Interconnect...), and it interconnects them in a fast & easy way.

Depending on the setup, you can create high throughput connections from the CSPs and migrate the data in hours or minutes.

Let´s compare the standard egress traffic prices for AWS, Google, and Azure.

Data Transfer Out using VPN

Data Transfer Out using Direct Connect: Data located in Europe, leaving to a DX location in Europe -> $0.0200 per GB

Data Transfer Out using VPN

Data Transfer Out using Google Interconnect: Data leaving over an Interconnect connection in Europe -> $0.0200 per GiB

Data Transfer Out using VPN

Data Transfer Out using Express Route: Data from EU leaving over an Express Route connection in Europe -> $0.025 per GB

As you can see, going via VPN is much more expensive than going privately; let´s do a small exercise.

Exercise

We are a networking architect, and our CTO brings us the task of migrating from Azure towards AWS. We have 180 TB of data from our Azure Blob Storage, and we have to migrate them to AWS S3.
Our data is located in Europe.

Let´s do the calculation; we will use the Azure Pricing Calculator:

Data Transfer - 180TB	Price
via Internet	$10,768.80*
via Express Route	$4,608.00

The first 100GB of traffic through the public internet are for free*

If we compare the amount, going with an Express Route connection, is 2.33 times cheaper than using the internet for the data transfer.

Let´s do the same exercise with Google:

Data Transfer - 180TB	Price
via Internet	$11,571.20*
via Google Interconnect	$3,686.40

The first 200GB of traffic through the public internet are for free*

It is 3.14 times cheaper to do the migration via a Google Interconnect than using the internet in terms of data transfer

And what about if we do the same exercise using AWS?:

Data Transfer - 180TB	Price
via Internet	$13.107,20*
via Direct Connect	$3686,40

The first 100GB of traffic through the public internet are for free*

It is 3.55 times cheaper to do the migration with Direct Connect than moving the data through the internet in terms of data transfer

Note:
These calculations do not include the related costs of the Express Route/Google Interconnect/Direct Connect and its related services like PrivateLink or the Cloud ROUTER...

The full solution, with the side costs is cheaper than using the public internet.

For more information on the prices, ask your connectivity partner for a quote.

Conclusion

With the usage of this type of new technology, doing a cloud migration gets simplified, in terms of efficiency, performance, and costs.

It is essential to know which options we have; being flexible is the key, especially in something so critical as a Cloud 2 Cloud Migration.

I hope you have enjoyed this article; I read you in the comments 😁

Midiendo la latencia hacia la nueva región de AWS España (eu-south-2 en Zaragoza)

Luis Horvath — Tue, 12 Sep 2023 08:14:05 +0000

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 desde Interxion MAD, 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.

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:

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 directamente para el Host Privado, simplificando el diseño, sin tener que crear un bastion host ni dos subnets distintas...)

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.

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

Utilizando el Servicio de Direct Connect (DX) y con la ayuda de un socio/partner 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 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.

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

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

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

Avg= 16.441 / 2 = 8.2205 ms

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

Promedio = 11.928 / 2 = 5.964 ms

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

Promedio = 16.451 / 2 = 8.2255 ms

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

Promedio = 11.946 / 2 = 5.973 ms

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

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

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

Promedio = 11.975 / 2 = 5.9875 ms

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

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.

Considerations before creating a hybrid infrastructure with AWS

Luis Horvath — Mon, 03 Apr 2023 22:58:49 +0000

What is a Hybrid Architecture?

A hybrid architecture combines computing resources, including local infrastructure and cloud-based services.

This is typically done by companies that want to leverage the benefits of cloud computing while still maintaining control over specific digital data or applications that they prefer to keep on-premises.

“The tricky part in making a hybrid car wasn´t sticking a battery and an electric motor into a petrol-powered car. Getting the two systems to work seamlessly and harmoniously was the critical innovation.”

Gregor Hohpe - Cloud Strategy: A decision-based approach to Successful Cloud Migration

Types of hybrid setups
Gregor, also created a great article pointing different scenarios for hybrid architectures. 8 types of scenarios are identified:

Let´s pick the Workload Demand strategy:

Companies can benefit from the cloud's elasticity to increase the capacity of their services at a burst, when is needed. Another benefit is the Cloud billing model, you pay for what you use, when you use it

Example

Imagine the scenario where you are the solutions architect in a company that sells online tickets for the last concert of a famous group, let´s say Rammstein.

You are going to receive so many requests when the tickets are on sale, it will look like you are receiving a DDoS attack.

You are in charge, nothing can fail, the reputation of the company is at your hand and you don´t want that your server room looks like this:

If you build a proper hybrid architecture, you can overcome any overload problem and avoid any disaster or chance to offer a bad service for your end customers.

The following image is a simplified version of a hybrid architecture solution for our example →

In this architecture, we extend and distribute the application between the different EC2 instances and the on-premise hardware using the Direct Connect service. These EC2 instances are part of autoscaling groups in different AZs that will scale out at a burst based on our defined rules of HW utilization.

Thanks to the elasticity of the cloud, this design will scale out and scale in once you are sold out with the tickets.

If, for example, you would have used VPN instead of the Direct Connect service, you may end up having synchronization issues if there is high latency between the on-premises and the cloud. How can you keep communication almost in real time with a bad latency?.

In the end, you will have customers who will have a bad experience and this will negatively impact your image as an architect and your employer. This scenario could be avoided

Not all hybrid architectures require the exact requirements; for this one, low latency is a must.

Considerations
What options do I have to create a hybrid cloud infrastructure?

VPN Over the internet

In a hybrid-cloud scenario, VPN is the fastest way to achieve the goal, but there are some downsides if you have to rely on the solution:

The connection is Encrypted, but it is no private - DDoS risk
Unpredictable latency
Limited throughput – up to 1.25 Gbps - (It can scale with the use of a transit gateway)
Low setup costs but high egress traffic costs after a certain amount of data
No end-to-end SLAs

AWS Direct Connect

Direct Connect is a private way to connect your on-premises infrastructure with a fiber optic connection to AWS inside a data center. This solution is not the fastest/cheapest to deploy; it is more complicated to design, but it provides some advantages like:

Extra security (connection outside of the public internet) but not encrypted by default, (possibility of MACsec encryption)
Lowest possible latency
High throughput – from 50Mbps up to 100Gbps
Cost-effective solution after a certain amount of data
Enterprise-grade SLA

What to choose: Direct Connect or VPN?

This will depend on the company's needs; SLA, latency, bandwidth, and time to deploy are some factors that will help you make the final decision.

Conclusion

Planning and implementing a network design that meets your business needs and requirements is essential to ensure a successful hybrid cloud deployment in AWS. Not doing a proper analysis can negatively impact the business in all aspects.

Networking is the key to success: Strong networking, seamless integration

Measuring latencies for the new region of AWS Spain (eu-south-2)

Luis Horvath — Mon, 03 Apr 2023 21:53:01 +0000

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 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

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:

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.

Looks easy, right?

Imagine replicating the same infrastructure using a different IP space but keeping the same configuration.

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

Using the Direct connect Service (DX), with the help of an interconnection partner. This is the list of partners; 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.

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.

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

Avg = 11.934 / 2 = 5.967 ms

Window size 128K – Run 2

Avg= 16.441 / 2 = 8.2205 ms

Window size 256K – Run 1

Avg = 11.928 / 2 = 5.964 ms

Window size 256K – Run 2

Avg = 16.451 / 2 = 8.2255 ms

Window size 512K – Run 1

Avg = 11.946 / 2 = 5.973 ms

Window size 512K – Run 2

Avg = 16.452 / 2 = 8.226 ms

Window size 1024K – Run 1

Avg = 11.975 / 2 = 5.9875 ms

Window size 1024K – Run 2

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

DEV Community: Luis Horvath

¡Vamos a bichear! - Dashboard de Ping

Pequeño repaso arquitecturil:

¿Cómo crearías un dashboard de ping?

Estructura del VPC (Virtual Private Cloud // La red)

Dibujo de nuestra arquitectura

Con el cómputo nos hemos topado: EC2

Añadiendo la base de Datos

Expansión a otras regiones

Medidas de Seguridad

Costes Aproximados por mes

Vamos a echarle mano a la red:

Vamos a por las Bases de datos:

Vamos a por las instancias EC2:

Costes aproximados por mes

Huella de carbono estimada

Tercera iteración: Sujétame el cubata

Usemos ARM:

¿Qué le habéis hecho a la red?

Costes aproximados por mes

Huella de carbono estimada

Conclusión

Let's Architect! - Ping Dashboard

Small Architecture Re-cap:

How would you create a ping dashboard?

VPC Structure

Drawing of our design

Let's add some EC2 instances!

Let's add the DBs!

Let's expand our network!

Security Measures

Approximate costs per month

Second Iteration: Searching for savings

Let's start with the network:

Let's continue with the DB!:

Let's end with the EC2:

Approximate costs per month

Third Iteration: Hold my Beer

Let's swap to ARM:

What have you done to the network?

Approximate costs per month

Conclusion

¿Qué es MACsec, y por qué es importante?

What is MACsec, and why is it important?

Optimize your IPv4 workloads in AWS and save money on the way!

Introduction

How to list the IPv4 Space in use

How can I reduce the IPv4 usage?

To use a Load Balancer

To use a Load Balancer doing a reverse proxy

To use a Bastion

To use the Session Manager

To use private EC2 Instance connect

To Migrate to IPv6

Article created for the AWS Community Builders by:

Miguel Angel Muñoz Sanchez

Luis Maria Horvath Mayor

Ahorra hasta 3 veces *más* dinero en la migración de un Cloud hacia AWS...

Agárrense los machos, se viene la migración...

Los primeros 100GB de tráfico de descarga por internet son gratis*

Los primeros 200GB de tráfico de descarga por internet son gratis*

Los primeros 100GB de tráfico de descarga por internet son gratis*

Save up to 3 times *more* money when migrating from a Cloud to AWS...

The first 100GB of traffic through the public internet are for free*

The first 200GB of traffic through the public internet are for free*

The first 100GB of traffic through the public internet are for free*

Midiendo la latencia hacia la nueva región de AWS España (eu-south-2 en Zaragoza)

Considerations before creating a hybrid infrastructure with AWS

Measuring latencies for the new region of AWS Spain (eu-south-2)

Ahorra hasta 3 veces más dinero en la migración de un Cloud hacia AWS...

Save up to 3 times more money when migrating from a Cloud to AWS...