¡Vamos a bichear! - Dashboard de Ping

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é es se debe de usar 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 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. 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. Es posible permitir que los recursos dentro de una subnet privada se comuniquen con Internet sin que haya acceso desde fuera. 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 priva

Mar 12, 2025 - 22:22

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é es se debe de usar 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 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.

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.

Es posible permitir que los recursos dentro de una subnet privada se comuniquen con Internet sin que haya acceso desde fuera. 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 acceso SSH para reducir la superficie de ataque.

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