gen[IA]ll Tutor
CLOUD-COMPUTING-FUNDAMENTALS

Networking

Actualizado en octubre de 2026 · 24 min de lectura

Practicar este tema →

Cloud Networking

Resumen

Esta guía de estudio independiente explica los fundamentos de red en la nube para la certificación LFCA. No está afiliada ni avalada por la Linux Foundation ni por ningún proveedor. El objetivo es entender cómo se aísla, se filtra y se conecta una red virtual, y cómo se resuelven nombres y se distribuye tráfico. AWS, Microsoft Azure y Google Cloud se usan como ejemplos; los conceptos de CIDR, subred, ruta, firewall y DNS son agnósticos.

En la nube, la red deja de ser un cable y se convierte en configuración. Eso aporta flexibilidad, pero también hace posible crear exposures accidentales: una subred pública, una regla demasiado amplia o una tabla de rutas incorrecta pueden abrir un servicio sin que nadie lo note. Diseñar la red es tan importante como diseñar el cómputo.

Objetivos de aprendizaje

Al terminar este tema deberías poder:

  • Explicar qué es una red virtual, una subred y un rango CIDR.
  • Interpretar el papel de las tablas de rutas y las puertas de enlace.
  • Distinguir filtrado con estado de filtrado sin estado.
  • Comparar conectividad híbrida mediante VPN e interconexión dedicada.
  • Relacionar DNS, balanceo de carga y entrega de contenido.

Prerrequisitos y conexiones

Requiere cloud-computing para los modelos de servicio y la responsabilidad compartida, y performance-availability para el balanceo y los dominios de fallo. Se complementa con cloud-best-practices en segmentación y mínimo privilegio, y con budgeting por el coste de transferencia. Conviene manejar conceptos básicos de TCP/IP, direccionamiento IPv4 y resolución DNS.

Redes virtuales, subredes y CIDR

Una red virtual es un espacio de direccionamiento lógico y aislado dentro de la nube. AWS la llama VPC, Azure Virtual Network y Google Cloud VPC. Dentro de ella se definen subredes, cada una con un rango de direcciones. El rango se expresa en notación CIDR, que combina una dirección con la longitud del prefijo; por ejemplo, un prefijo más largo implica una red más pequeña.

El direccionamiento se planifica antes de desplegar. Rangos solapados entre redes que deben comunicarse impiden un emparejamiento directo y obligan a rediseñar o a usar traducción de direcciones. También conviene reservar espacio para crecimiento y separar, al menos lógicamente, cargas públicas, privadas y de gestión.

Una subred se considera pública o privada según su tabla de rutas, no por su nombre. Si la ruta por defecto apunta a una puerta de enlace de Internet y la instancia tiene dirección pública, el tráfico puede salir y entrar. Si la ruta apunta a un NAT, la subred es privada para entrada, aunque pueda iniciar salidas. Este matiz es una fuente habitual de errores.

La tabla de rutas decide hacia dónde va el tráfico según el destino. La ruta local mantiene la comunicación dentro de la red virtual; las rutas adicionales dirigen tráfico hacia Internet, otra red, una VPN o un centro de datos. Una ruta mal priorizada puede enviar tráfico privado a Internet o romper la conectividad entre subredes.

Aislamiento y filtrado

El filtrado se aplica en varias capas. Los grupos de seguridad (security groups) actúan como firewall con estado a nivel de recurso: si se permite una conexión de salida, la respuesta entrante se permite automáticamente. Las listas de control de acceso a red (NACL) actúan a nivel de subred y son sin estado: hay que permitir explícitamente el tráfico de ida y el de vuelta. Azure usa grupos de seguridad de red con reglas de entrada y salida; Google Cloud usa reglas de firewall a nivel de red y etiquetas.

La diferencia entre con estado y sin estado es importante. Un grupo de seguridad recuerda la conexión y no exige una regla de retorno. Una NACL evalúa cada paquete por separado, por lo que una regla de entrada sin la salida correspondiente puede bloquear la respuesta. Además, las NACL pueden tener reglas de denegación explícita, mientras que los grupos de seguridad suelen ser solo permisos.

El principio de diseño es denegar por defecto y abrir solo lo necesario. Exponer SSH o RDP a todo Internet es un riesgo evitable; es preferible usar un bastión, un acceso mediado o una VPN. Para la salida, conviene restringir destinos cuando el servicio no necesita Internet abierto y usar endpoints privados para servicios gestionados cuando estén disponibles.

La segmentación reduce el movimiento lateral. Separar subredes por función, aplicar políticas entre ellas y registrar el tráfico rechazado facilita detectar comportamientos anómalos. La segmentación excesiva también tiene coste operativo; el equilibrio depende del riesgo y de la complejidad tolerable.

Conectividad híbrida y entre redes

Para conectar una red virtual con otra se usa peering o emparejamiento. El peering conecta dos redes sin pasar por Internet, pero no es transitivo por defecto: si A se conecta con B y B con C, A no alcanza C automáticamente. Las arquitecturas hub-and-spoke concentran la conectividad y el filtrado en una red central, con reglas claras para el tránsito.

Para conectar con un centro de datos se usan dos enfoques principales. Una VPN de sitio a sitio cifra el tráfico sobre Internet; es rápida de aprovisionar y flexible, pero su rendimiento y latencia dependen del camino público. Una interconexión dedicada ofrece un enlace privado y más predecible, con mayor coste y tiempo de provisión. La elección depende de la criticidad, el volumen y los requisitos de latencia.

La traducción de direcciones (NAT) permite que recursos con direcciones privadas inicien conexiones salientes sin ser accesibles desde fuera. Un NAT gateway suele ser gestionado y escala, pero introduce coste por procesamiento y no sustituye a un firewall. Para publicación de servicios se usan balanceadores o puertas de enlace de entrada, no reglas amplias en las instancias.

Nombres, balanceo y entrega

El DNS traduce nombres a direcciones. Un registro A asocia un nombre a una dirección IPv4; un registro AAAA lo hace con IPv6; un CNAME crea un alias hacia otro nombre. El RFC 1035 define el sistema y los formatos originales. En la nube, las zonas privadas permiten resolver nombres internos sin exponerlos a Internet, y las políticas de enrutamiento pueden dirigir tráfico según latencia o geografía.

El balanceador de carga distribuye peticiones entre destinos y comprueba su salud. Puede operar en capa 4 (transporte) o capa 7 (aplicación), terminar TLS, enrutar por ruta y aplicar afinidad. Un balanceador no arregla una aplicación con estado mal diseñada; solo distribuye el tráfico que recibe.

Una red de entrega de contenido (CDN) cachea contenido cerca del usuario y reduce la latencia y la carga del origen. Es útil para contenido estático y para descargas, pero requiere gestionar la invalidación y los encabezados de caché. La seguridad de la entrega incluye TLS, control de acceso y protección contra abuso.

Planificación de direcciones y capacidad

Un plan de direccionamiento sólido evita rediseños costosos. Conviene reservar bloques por región, entorno y función, dejar espacio para crecimiento y documentar qué rango pertenece a cada red. Los rangos privados definidos en el RFC 1918 son habituales; los enlaces punto a punto pueden usar prefijos muy pequeños, mientras que las subredes de carga necesitan espacio para escalado y para direcciones que el proveedor reserva.

Dentro de una subred, no todas las direcciones están disponibles: el proveedor suele reservar la primera, la última y algunas adicionales para servicios internos. Calcular la capacidad efectiva antes de dimensionar evita descubrir durante un despliegue que faltan direcciones. En IPv6 el espacio es amplio, pero la disciplina de prefijos y la documentación siguen siendo necesarias para no crear redes difíciles de auditar.

La asignación de direcciones públicas debe ser deliberada. Una dirección pública en una instancia facilita la administración, pero también la expone; los servicios de entrada gestionados permiten publicar aplicaciones sin que cada servidor tenga presencia directa en Internet. Registrar qué recurso usa cada dirección y liberar las que quedan sin uso reduce tanto el riesgo como el coste.

DNS privado y resolución híbrida

Las zonas privadas resuelven nombres internos solo dentro de las redes autorizadas. Su diseño requiere decidir qué nombres son locales, cómo se delegan subdominios y qué resolutores consultan los clientes. Una zona privada mal asociada produce respuestas que funcionan en una red y fallan en otra, un síntoma que suele confundirse con un problema de aplicación.

En entornos híbridos, la resolución debe atravesar fronteras: el centro de datos pregunta por nombres de la nube y viceversa. Los reenviadores condicionales dirigen consultas de un dominio concreto hacia el resolutor adecuado, mientras que la delegación de zona reparte autoridad. Hay que evitar bucles de reenvío y definir qué ocurre cuando el enlace entre ambos entornos falla; la caché puede mantener respuestas durante el TTL, pero no las renueva.

El registro de consultas y la coherencia de nombres son parte del diagnóstico. Un nombre que resuelve a una dirección privada desde fuera no es útil; uno que resuelve a una dirección pública desde dentro puede eludir controles internos. Documentar la ruta de resolución —cliente, resolutor, reenviador, zona autoritativa— permite localizar en qué salto se pierde la respuesta.

Balanceo, comprobaciones de salud y recuperación

Un balanceador solo es tan fiable como sus comprobaciones de salud. Una prueba que consulta un puerto abierto pero no la dependencia real puede mantener destinos enfermos en rotación. Las comprobaciones deben reflejar la función del servicio: una página de estado que verifica base de datos y caché es más útil que un simple saludo TCP, siempre que no genere carga excesiva ni dependa de un componente que pueda fallar por separado.

La distribución de tráfico y la recuperación son decisiones distintas. El balanceo reparte carga entre destinos sanos; la recuperación ante fallos de zona o región requiere réplicas, rutas y procedimientos. Un balanceador multi-zona evita perder el servicio por el fallo de una zona, pero no sustituye una copia de datos en otra región. La conmutación debe probarse con el mismo tráfico y las mismas dependencias que producción.

Los timeouts y los reintentos mal configurados amplifican incidentes. Un cliente que reintenta sin límite multiplica la carga sobre un servicio degradado; un timeout demasiado corto expulsa destinos que solo eran lentos. Definir presupuestos de tiempo, aplicar retroceso exponencial con jitter y limitar los reintentos a operaciones seguras reduce el riesgo de tormenta.

Visibilidad, flujos y diagnóstico

Los registros de flujo describen conexiones aceptadas y rechazadas sin capturar el contenido. Sirven para responder quién habló con quién, en qué puerto y durante cuánto tiempo, y para detectar tráfico inesperado entre subredes. Su valor depende de la retención y de la capacidad de correlacionar con identidades y eventos de aplicación; un flujo aislado rara vez explica un incidente.

El diagnóstico sigue un orden: verificar la configuración, comprobar la resolución de nombres, probar el puerto y observar el camino. Las herramientas cambian según el proveedor, pero la lógica es la misma que en un host Linux: dirección, ruta, filtro y servicio. Comparar el comportamiento desde dentro y desde fuera de la red revela si el problema está en la política de entrada, en la salida o en el servicio.

Las pruebas deben ser reproducibles. Registrar la hora, el origen, el destino y el resultado convierte una comprobación puntual en evidencia. Cuando se modifica una regla, conviene verificar inmediatamente el caso que motivó el cambio y el caso que debía seguir bloqueado; así se evita abrir más de lo necesario y se documenta el efecto real.

Coste de transferencia y ubicación

El tráfico tiene precio y latencia. La salida a Internet, la transferencia entre zonas y la comunicación entre regiones se facturan de forma distinta; por eso la ubicación de los datos y de los servicios que los consumen es una decisión de arquitectura. Mantener el tráfico dentro de una zona o región suele ser más barato y más rápido, pero concentra el riesgo y puede complicar la recuperación.

Las cachés y los endpoints privados reducen transferencia repetida y exposición. Una CDN acerca contenido estático y disminuye la carga del origen; un endpoint privado evita que el tráfico a un servicio gestionado salga por Internet. La optimización debe medirse: ahorrar en transferencia pero añadir latencia o complejidad operativa puede empeorar el resultado global.

La topología también afecta a la factura de los balanceadores, las puertas de enlace y las VPN. Antes de elegir, conviene estimar el volumen, el patrón de acceso y los requisitos de recuperación. Revisar esas estimaciones cuando cambia el uso evita que una decisión razonable en el diseño inicial se convierta en un coste fijo difícil de justificar.

Endpoints privados y servicios gestionados

Los servicios gestionados suelen ofrecer dos caminos: un endpoint público, accesible desde Internet, y un endpoint privado dentro de la red virtual. El privado mantiene el tráfico en la red del proveedor y evita depender de reglas de salida hacia Internet. Su adopción requiere planificar la resolución DNS, porque el nombre del servicio debe apuntar a la interfaz privada y no a la pública.

Los endpoints privados no eliminan la necesidad de controles. Siguen sujetos a grupos de seguridad, políticas de red y permisos de identidad, y su resolución puede fallar si la zona privada no está asociada a la red correcta. Conviene probar el acceso desde cada subred que lo consumirá y documentar qué nombres resuelven de forma privada y cuáles permanecen públicos.

La salida a Internet también merece un diseño explícito. Un NAT gestionado permite que las instancias privadas descarguen actualizaciones sin recibir conexiones entrantes, pero añade un punto de concentración y un coste por procesamiento. Si varias subredes comparten la misma salida, una carga con mucho tráfico puede afectar a las demás; separar salidas por función o limitar el ancho de banda evita que un vecino ruidoso degrade el resto.

Los servicios de entrada gestionados, como balanceadores y puertas de enlace, concentran la publicación y el certificado TLS. Esto simplifica la rotación y el filtrado, aunque exige revisar los límites del servicio, los tiempos de espera y las reglas que conectan la entrada con los destinos privados. La cadena completa —DNS, entrada, filtro y destino— debe probarse como una unidad.

La elección entre endpoint público y privado no es binaria: un servicio puede exponer una API pública y consumir bases de datos por una vía privada. Separar ambas rutas reduce la superficie y facilita aplicar políticas distintas a cada flujo. Documentar qué flujos cruzan cada ruta ayuda a revisar reglas y a estimar el coste de transferencia antes de que el diseño se consolide.

Ejemplos prácticos

Escenario 1. Una aplicación web necesita subredes públicas y privadas. El balanceador se sitúa en subredes públicas; las instancias de aplicación, en privadas, salen a Internet mediante NAT y reciben tráfico solo del balanceador. La base de datos queda en una subred privada sin ruta directa a Internet.

Escenario 2. Dos equipos crean redes con el mismo rango CIDR. El peering falla porque los rangos se solapan. Se rediseña el direccionamiento o se usa una capa de traducción; lo más sano es planificar rangos únicos desde el inicio.

Escenario 3. Una empresa necesita conectar su centro de datos con la nube. Empieza con una VPN para validar la arquitectura y, cuando el volumen y la criticidad lo justifican, evalúa una interconexión dedicada. La VPN no se descarta: puede quedar como respaldo.

Errores frecuentes

  • Asumir que el nombre "subred pública" define el comportamiento. Lo define la tabla de rutas y la asignación de direcciones.
  • Confundir grupos de seguridad con NACL. Los primeros tienen estado y actúan por recurso; las segundas no tienen estado y actúan por subred.
  • Abrir administración a todo Internet. Es preferible un bastión, VPN o acceso mediado.
  • Planificar CIDR sin margen. El crecimiento y las conexiones futuras requieren espacio.
  • Olvidar que el peering no es transitivo. Las redes en hub-and-spoke necesitan rutas y políticas explícitas.
  • Ignorar el coste de transferencia. Salida a Internet y tráfico entre regiones pueden ser relevantes.

Puntos clave para el examen

  • La red virtual contiene subredes definidas por rangos CIDR.
  • La tabla de rutas determina si una subred es pública o privada en la práctica.
  • Los grupos de seguridad tienen estado; las NACL no.
  • El peering conecta redes, pero no es transitivo por defecto.
  • VPN e interconexión dedicada son opciones híbridas con distinto coste y previsibilidad.
  • DNS, balanceo y CDN resuelven nombres, distribuyen carga y acercan contenido.

Recursos externos

Autoevaluación

1. ¿Qué define que una subred sea pública?

Respuesta: Su tabla de rutas, normalmente con una ruta por defecto hacia una puerta de enlace de Internet, junto con direcciones públicas.

Justificación: El nombre o la etiqueta no cambian el comportamiento. Sin la ruta y el direccionamiento adecuados, la subred no es accesible desde Internet.

2. ¿Cuál es la diferencia principal entre un grupo de seguridad y una NACL?

Respuesta: El grupo de seguridad tiene estado y filtra por recurso; la NACL no tiene estado y filtra por subred.

Justificación: El grupo recuerda la conexión y permite la respuesta automáticamente. La NACL evalúa cada paquete y exige reglas de ida y vuelta.

3. ¿Qué significa que el peering no sea transitivo?

Respuesta: Que si A está emparejada con B y B con C, A no alcanza C automáticamente.

Justificación: Cada emparejamiento es una relación directa. El tránsito requiere rutas y políticas explícitas, típicamente en una arquitectura hub-and-spoke.

4. ¿Qué registro DNS asocia un nombre a una dirección IPv4?

Respuesta: Un registro A.

Justificación: El RFC 1035 define el registro A para direcciones IPv4; AAAA se usa para IPv6 y CNAME para alias.

5. ¿Cuándo tiene sentido una interconexión dedicada frente a una VPN?

Respuesta: Cuando se necesita conectividad privada más predecible en latencia y rendimiento, y el volumen o la criticidad justifican su coste.

Justificación: La VPN es más rápida de aprovisionar y flexible, pero depende de Internet. La dedicada ofrece un camino privado con mayor previsibilidad y mayor coste.