Fundamentos de redes en la nube

Una aplicación en la nube necesita una red además de equipos. Una red virtual es una red privada definida mediante software. Eliges sus direcciones y conexiones sin instalar conmutadores ni cables. Las redes separadas pueden mantener el trabajo de producción apartado del de prueba.

Interpreta las direcciones

AWS llama a su red Amazon VPC; Microsoft usa Azure Virtual Network, o VNet; Google Cloud usa red VPC. Una VPC de AWS o una VNet de Azure tiene un rango general de direcciones. Sus subredes toman rangos más pequeños de él. Una VPC de Google Cloud no tiene un rango general: cada subred recibe el suyo.

La expresión 10.0.0.0/16 usa notación CIDR. El número después de la barra cuenta los bits iniciales fijos de la dirección. Un número menor significa un rango mayor. Este /16 abarca de 10.0.0.0 a 10.0.255.255: 65 536 direcciones. Los bloques privados son 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16. La internet pública no enruta estas direcciones privadas.

Una subred proporciona direcciones a una parte de una red. Por ejemplo, 10.0.3.0/24 abarca de 10.0.3.0 a 10.0.3.255. Una base de datos en ella podría recibir 10.0.3.20. Las subredes separadas para web, aplicaciones y bases de datos permiten a los equipos aplicar distintas rutas y reglas de seguridad. Los rangos de subredes de una misma red no deben solaparse. Los proveedores reservan direcciones para servicios de red: AWS y Azure reservan cinco por subred; Google Cloud reserva cuatro en el rango principal de una subred. Por tanto, una subred de 256 direcciones deja 251 direcciones en AWS o Azure.

Distribuye los recursos entre zonas

Considera una tienda en AWS que usa 10.0.0.0/16. En la zona A coloca servidores web en 10.0.1.0/24, servidores de aplicaciones en 10.0.2.0/24 y su base de datos en 10.0.3.0/24. Para seguir prestando servicio durante una interrupción de zona, repite las capas en la zona B mediante 10.0.11.0/24, 10.0.12.0/24 y 10.0.13.0/24. Las subredes separan funciones; usar dos zonas separa las ubicaciones de fallo. Crear varias subredes en una sola zona no lograría esto último.

Conecta las redes deliberadamente

Las redes virtuales proporcionan aislamiento lógico respecto a otros clientes y otras redes. La comunicación necesita una ruta de red y permisos. Una conexión de emparejamiento permite que dos redes se comuniquen mediante direcciones privadas por la red del proveedor. El emparejamiento puede cruzar regiones y límites de cuentas, suscripciones o proyectos, pero los rangos de direcciones no deben solaparse.

Comprueba los rangos de oficinas y socios antes de elegir los rangos de la nube. Si una oficina y una VPC usan ambas 10.0.0.0/16, un destino como 10.0.3.20 podría pertenecer a cualquiera de los dos lados. Elegir 10.1.0.0/16 para la nube evita ese conflicto. Corregir un plan de direcciones después de implementar servidores puede interrumpir su funcionamiento.

El emparejamiento no es transitivo. Si A se empareja con B y B con C, A sigue necesitando su propia conexión con C. Además, una ruta privada no cifra los datos: usa cifrado para ese propósito. Crear la red virtual en sí es gratuito en estos proveedores; las puertas de enlace, las direcciones IPv4 públicas y la transferencia de datos pueden generar cargos.

Una dirección de destino indica a una red adónde intenta llegar el tráfico. Una tabla de enrutamiento le indica el siguiente lugar al que debe enviarlo. El enrutamiento proporciona una ruta; las reglas de seguridad deciden si el tráfico puede usarla.

Elige la ruta coincidente

Cada ruta vincula un rango de destino con un destino de la ruta. Una ruta local conecta subredes dentro de la misma red virtual. La ruta predeterminada de IPv4, 0.0.0.0/0, coincide con todas las direcciones, pero una ruta coincidente más específica tiene prioridad. Un número de prefijo mayor después de la barra indica un rango más específico.

Supón que una subred de aplicaciones de AWS usa estas rutas:

Una solicitud desde 10.0.2.15 a la base de datos 10.0.3.20 coincide con ambos rangos. El /16 es más específico que /0, por lo que la solicitud permanece en la red local. Una solicitud al servidor de actualizaciones 203.0.113.50 solo coincide con la ruta predeterminada y va a la puerta de enlace NAT. Las reglas de seguridad deben permitir cada conexión.

Permite el acceso público deliberadamente

En AWS, una puerta de enlace a internet une una VPC a internet. Una subred con una ruta predeterminada hacia esa puerta de enlace es una subred pública. Su rango de direcciones puede seguir siendo privado, como 10.0.1.0/24. «Pública» describe su enrutamiento, no la notación de sus direcciones.

Para acceder a un servidor desde internet deben coincidir tres elementos: una ruta a internet, una dirección IP pública en el servidor o en un equilibrador de carga situado delante de él, y reglas de seguridad que permitan la conexión. Una subred de AWS puede ser pública mientras que un servidor concreto de ella no tiene acceso público directo.

Azure y Google Cloud proporcionan rutas integradas a internet sin una puerta de enlace a internet del tipo de AWS que debas crear. Sus reglas de seguridad y direcciones públicas siguen siendo importantes. Una subred privada, en el sentido general, no da a los usuarios de internet una ruta directa a sus recursos. Esto la hace útil para bases de datos y servidores de aplicaciones internos.

Da acceso saliente a los servidores privados

Una puerta de enlace NAT permite que un servidor privado inicie una conexión a internet. Sustituye la dirección privada de origen por una dirección pública, hace seguimiento de la conexión y entrega la respuesta al servidor correcto. No acepta una nueva conexión iniciada por un usuario de internet hacia ese servidor privado.

En AWS, una puerta de enlace NAT pública se sitúa en una subred pública. La ruta predeterminada de la aplicación privada apunta a ella, y la subred de la puerta de enlace NAT tiene una ruta hacia la puerta de enlace a internet. La aplicación puede obtener actualizaciones mientras que su subred de base de datos, con solo una ruta local, no tiene ruta a internet. Azure NAT Gateway se asocia a una subred; Google Cloud ofrece Cloud NAT. Los servicios NAT generan cargos por tiempo de funcionamiento y procesamiento de datos.

Comprueba los valores predeterminados del proveedor

Las subredes de las VPC predeterminadas de AWS son públicas y normalmente asignan direcciones públicas a las nuevas instancias. Una VPC que creas tú necesita que se le añada una puerta de enlace a internet. Las direcciones públicas estáticas reservadas mantienen una dirección estable; AWS llama a una de ellas Elastic IP. Las direcciones asignadas automáticamente pueden cambiar después de detener e iniciar una máquina. Desde febrero de 2024, AWS cobra por cada dirección IPv4 pública, incluidas las que están en uso.

Azure usa «subred privada» específicamente para una subred con el acceso saliente predeterminado desactivado. Necesita un método de salida explícito, como NAT o una IP pública asignada, y esa configuración por sí sola no bloquea el tráfico entrante. El portal crea subredes privadas de forma predeterminada. Con la versión de la API publicada después del 31 de marzo de 2026, las nuevas redes virtuales también reciben subredes privadas de forma predeterminada; las versiones anteriores de la API conservan el comportamiento anterior y las redes existentes no cambian.

Un servicio administrado puede funcionar fuera de tu red virtual. Un punto de conexión es la dirección que usan los clientes para acceder a él, normalmente mediante un nombre DNS. La ruta de red del punto de conexión y los permisos sobre los datos del servicio resuelven problemas diferentes.

Separa el acceso público del acceso a los datos

Un punto de conexión público se resuelve en una dirección IP pública. Los clientes de internet pueden intentar conectarse, pero eso no hace públicos los datos almacenados. Las credenciales y los permisos normalmente controlan el acceso. Algunos servicios también permiten el acceso anónimo cuando se configuran para ello; un error de permisos en el almacenamiento de objetos puede exponer archivos.

Usa HTTPS, que utiliza cifrado TLS, para el tráfico del servicio. Cuando sea compatible, exige HTTPS y restringe qué direcciones o redes pueden conectarse. La accesibilidad pública, los permisos de acceso y el cifrado son configuraciones independientes. Una aplicación autorizada puede usar un punto de conexión público de forma segura, mientras que un servicio mal configurado puede filtrar datos incluso en una red privada.

Añade una dirección privada

Un punto de conexión privado da a un servicio compatible una dirección privada dentro de tu red. El proveedor crea una interfaz de red en una subred y el tráfico hacia esa dirección permanece en su red.

Los sistemas de oficina también pueden acceder a puntos de conexión privados mediante una VPN o una conexión dedicada. Las redes emparejadas pueden acceder a ellos cuando las configuraciones de enrutamiento, DNS y seguridad permiten la ruta.

Haz que el nombre del servicio encuentre el punto de conexión

Las aplicaciones suelen conectarse mediante un nombre de servicio, no una dirección IP fijada en el código. El DNS privado hace que ese nombre se resuelva en la dirección privada del punto de conexión dentro de la red. Por ejemplo, un cliente interno podría resolver el nombre de su servicio de almacenamiento en 10.0.2.40. Los clientes externos pueden seguir recibiendo la dirección pública.

Crear el punto de conexión por sí solo no cambia la respuesta DNS de todos los clientes. Si un cliente interno sigue resolviendo la dirección pública, seguirá usando la ruta pública. Vincula la zona DNS privada a la red y proporciona reenvío de DNS para los clientes locales. Para exigir acceso privado, desactiva o restringe también el punto de conexión público del servicio. Crear un punto de conexión privado mantiene la configuración de acceso público existente.

Reconoce las opciones relacionadas

Un punto de conexión de puerta de enlace de AWS accede a S3 o DynamoDB mediante una entrada de la tabla de enrutamiento. No crea la interfaz de red privada que usa un punto de conexión de interfaz y no tiene un cargo adicional por el punto de conexión. Un punto de conexión de servicio de Azure identifica una subred permitida y transporta su tráfico de servicio por la red de Microsoft, pero el servicio sigue teniendo una dirección IP pública. Private Google Access permite que las máquinas con direcciones internas accedan a las API y los servicios de Google.

Considera un servidor de análisis que lee cada día 500 GB del almacenamiento de objetos regional. Enviar esas lecturas mediante NAT hace que el servicio NAT procese los 500 GB. En AWS, un punto de conexión de puerta de enlace adecuado para S3 lleva ese tráfico de servicio por la ruta del punto de conexión sin una tarifa adicional por él. Los puntos de conexión de interfaz y privados tienen sus propias tarifas, así que compara la ruta completa y sus cargos. El punto de conexión cambia la conectividad; TLS sigue proporcionando el cifrado en tránsito.

Un servidor puede tener una ruta hacia otra red y aun así rechazar su tráfico. Un grupo de seguridad actúa como un cortafuegos virtual para los recursos. Las reglas de entrada controlan el tráfico que llega a un recurso; las de salida controlan el tráfico que sale de él.

Interpreta una regla

Para TCP o UDP, interpreta conjuntamente el protocolo, el puerto y el origen o destino. La regla «permitir TCP 443 desde 198.51.100.7/32» permite tráfico HTTPS desde una dirección. El origen 0.0.0.0/0 significa todas las direcciones IPv4. Un origen de entrada también puede identificar un grupo de seguridad, de modo que el acceso siga la función de un servidor cuando cambie su dirección IP.

Entre los puertos útiles están SSH 22, RDP 3389, HTTP 80, HTTPS 443, DNS 53, MySQL 3306, PostgreSQL 5432 y Microsoft SQL Server 1433. ICMP, usado por ping, tiene tipos de mensaje en lugar de puertos TCP o UDP.

Entiende el filtrado con estado

Un filtro con estado recuerda las conexiones permitidas. Si una regla de entrada permite una nueva conexión HTTPS, las respuestas pueden salir sin una regla de salida independiente para ellas. Esto no permite que el servidor inicie cualquier conexión saliente no relacionada. Las conexiones nuevas siguen necesitando su propio permiso.

Los grupos de seguridad de AWS se asocian a interfaces de red. Varios recursos pueden compartir un grupo y un recurso puede tener varios grupos. Sus reglas de permiso se combinan: el tráfico pasa si una regla aplicable lo permite. El orden de las reglas no tiene efecto y no hay una regla de denegación explícita que anule un permiso amplio. Un grupo recién creado no permite tráfico entrante y permite tráfico saliente hasta que se cambie.

Crea una cadena de funciones permitidas

Para una aplicación de tres capas, da a cada capa solo las conexiones entrantes que necesita:

1. El equilibrador de carga permite TCP 443 desde los usuarios de internet.
2. Los servidores web permiten TCP 443 desde el grupo del equilibrador de carga. La administración mediante TCP 22 se limita a la dirección de la oficina del administrador.
3. La base de datos MySQL permite TCP 3306 desde el grupo de servidores web.

Cuando un servidor web de reemplazo se une al grupo de servidores web, obtiene el acceso previsto a la base de datos sin una nueva regla basada en direcciones. Una solicitud directa desde internet a la base de datos falla porque su origen no está permitido. Sin embargo, si un segundo grupo asociado permite ampliamente el mismo puerto de base de datos, ese permiso amplio sigue aplicándose; el primer grupo no tiene una denegación más restringida que lo anule.

Compara los filtros de los proveedores

Un grupo de seguridad de red de Azure, o NSG, puede asociarse a una subred, una interfaz de red o ambas. Las prioridades personalizadas van de 100 a 4096, por delante de las predeterminadas integradas en 65000, 65001 y 65500. Las reglas de entrada predeterminadas permiten el tráfico de la red virtual y del equilibrador de carga de Azure, y después deniegan el resto del tráfico entrante. Google Cloud selecciona las máquinas de destino mediante etiquetas o cuentas de servicio; sus reglas implícitas deniegan el tráfico entrante y permiten el saliente.

Aplica el principio de mínimo privilegio: permite solo los puertos necesarios desde el conjunto de orígenes útil más pequeño. Abrir SSH o RDP a toda internet expone los servicios de inicio de sesión administrativo a ataques automatizados. Las opciones de acceso administrado incluyen AWS Systems Manager Session Manager, Azure Bastion y Google Cloud Identity-Aware Proxy. Un filtro de puertos no puede reconocer un ataque oculto dentro del tráfico HTTPS permitido; las defensas de la aplicación y los controles de inicio de sesión protegen esa capa.

Una lista de control de acceso de red de AWS, o ACL de red, filtra el tráfico que cruza el límite de una subred. Se aplica a todos los recursos de esa subred. Cada subred tiene una ACL de red y la misma ACL puede servir a varias subredes.

Sigue la primera regla coincidente

Las reglas de una ACL de red pueden permitir o denegar el tráfico. AWS las comprueba desde el número de regla más bajo hacia arriba y se detiene en la primera coincidencia. Una regla final * deniega el tráfico que no coincide. La ACL predeterminada de la VPC permite el tráfico entrante y saliente; una ACL personalizada recién creada deniega el tráfico hasta que añadas reglas de permiso.

Supón que la regla 100 permite TCP 443 desde todas las direcciones IPv4, mientras que la regla 110 deniega el tráfico desde 203.0.113.0/24. Una solicitud desde 203.0.113.77 al puerto 443 coincide primero con la regla 100 y pasa. La denegación posterior nunca llega a evaluarse. Mueve esa denegación a la regla 90 para bloquear el rango antes del permiso amplio de HTTPS.

Sigue la respuesta como un paquete independiente

Una ACL no tiene estado: no recuerda que se permitió una conexión. Una solicitud web usa el puerto de destino 443 del servidor, pero la respuesta vuelve al puerto temporal, o efímero, del cliente. Puede ser un número alto como 50432.

Para un sitio web con una ruta y un grupo de seguridad que funcionan:

1. Un cliente envía una solicitud desde su puerto temporal al puerto 443 del servidor.
2. La ACL de la subred admite el paquete entrante mediante su regla HTTPS.
3. El servidor responde al puerto temporal del cliente.
4. La ACL de salida comprueba ese puerto de destino de forma independiente.

Una regla de salida que solo permita el puerto de destino 443 no cubre esa respuesta. La respuesta necesita un permiso de salida que cubra su puerto de destino; TCP 1024–65535 es un rango efímero amplio de uso común. El rango necesario depende de los clientes y del tráfico que se admitan. El permiso de un grupo de seguridad con estado no elude la decisión independiente de la ACL.

Compara las dos capas de AWS

El tráfico entrante de internet debe pasar por ambas capas. El tráfico entre dos recursos de la misma subred no cruza el límite de la subred, por lo que la ACL de esa subred no lo filtra. Los grupos de seguridad de los recursos siguen aplicándose.

Usa capas independientes

La defensa en profundidad limita el daño de una configuración errónea. Los grupos de seguridad dan permisos precisos a cada función de la aplicación. Las ACL añaden controles de protección para toda la subred, como denegar un rango malicioso conocido. Los cortafuegos del sistema operativo, los cortafuegos de red administrados, los cortafuegos de aplicaciones web, TLS y las comprobaciones de identidad protegen otras partes de la ruta. Los registros de flujo recogen los flujos de red permitidos y rechazados; Amazon Inspector ayuda a identificar vulnerabilidades de las cargas de trabajo y exposición involuntaria.

Azure no tiene una ACL de red independiente del tipo de AWS: los NSG de subred e interfaz proporcionan esas capas y ambos tienen estado. Para el tráfico entrante de Azure, primero el NSG de la subred y después el de la interfaz deben permitirlo. Google Cloud usa reglas de cortafuegos de VPC con estado y políticas de cortafuegos más amplias, incluidas políticas de organización y carpeta.

Las personas recuerdan nombres como www.example.com; los equipos envían tráfico a direcciones IP. DNS, el sistema de nombres de dominio, conecta ambos. Los proveedores de servicios en la nube alojan registros mediante Amazon Route 53, Azure DNS y Google Cloud DNS.

Sigue una búsqueda de nombre

Un cliente solicita una dirección a un resolutor. Si el resolutor no tiene una respuesta en caché, pregunta a un servidor raíz dónde encontrar los servidores de .com. Esos servidores identifican los servidores de nombres autoritativos del dominio. Un servidor autoritativo contiene los registros del dominio y devuelve la respuesta, que el resolutor almacena en caché para clientes posteriores. Route 53 asigna cuatro servidores de nombres autoritativos a una zona alojada pública. Después, el cliente se conecta a la dirección devuelta. DNS no transporta el tráfico de la aplicación del sitio web.

Una zona es el conjunto administrado de registros de un dominio. Para usar la zona pública de un nuevo proveedor, configura los servidores de nombres de ese proveedor en el registrador del dominio. El alojamiento de zonas y el registro de dominios son servicios separados: Route 53 ofrece ambos, mientras que Azure DNS aloja zonas sin vender registros de dominio.

Elige el registro

El ápice de zona es el dominio sin subdominio, como example.com. Un CNAME estándar no puede situarse allí porque el ápice también necesita registros NS y SOA. Los registros de alias de Route 53 y los conjuntos de registros de alias de Azure pueden hacer que los registros compatibles del ápice apunten a recursos en la nube y reflejen los cambios en sus direcciones.

Ten en cuenta las respuestas en caché

El TTL, o tiempo de vida, de un registro indica cuántos segundos puede un resolutor almacenar la respuesta en caché. Supón que un resolutor guarda en caché una respuesta de 3600 segundos a las 9:55. Cambiar el registro a las 10:00 no borra esa copia: puede seguir siendo válida hasta las 10:55. Reduce el TTL a 300 segundos al menos un TTL anterior antes de un traslado previsto, para que las copias anteriores de larga duración tengan tiempo de caducar. Reducirlo en el momento del traslado no puede acortar la duración de las copias ya almacenadas en caché.

Las políticas de enrutamiento DNS influyen en las respuestas a las consultas. El enrutamiento simple proporciona una respuesta directa. El enrutamiento ponderado da respuestas en las proporciones elegidas, como el 90 % para la versión actual y el 10 % para una nueva; el enrutamiento basado en latencia favorece la menor latencia medida; el enrutamiento por geolocalización selecciona según la ubicación del usuario; el enrutamiento de conmutación por error cambia de un sistema principal a uno en espera cuando las comprobaciones de estado muestran un fallo. Cada comprobador de estado de Route 53 normalmente envía una comprobación cada 30 segundos. Azure Traffic Manager y Google Cloud DNS también ofrecen opciones de enrutamiento basado en DNS.

En una tienda con un sistema principal en Fráncfort y uno en espera en Irlanda, una comprobación de estado fallida del sistema principal hace que las nuevas respuestas apunten al sistema en espera. Las respuestas ya almacenadas en caché siguen vigentes hasta que caducan; un TTL corto, como 60 segundos, reduce ese retraso. Del mismo modo, el enrutamiento ponderado distribuye respuestas DNS, no números exactos de usuarios o solicitudes de aplicaciones: una respuesta en caché puede servir a muchos usuarios. Un equilibrador de carga actúa sobre el tráfico entrante en otra capa.

Resuelve nombres internos

Una zona DNS privada proporciona respuestas a las redes virtuales vinculadas. Puede asignar db.internal.example.com a una dirección privada de base de datos o dirigir un nombre de servicio a un punto de conexión privado. Los clientes locales necesitan una ruta adecuada de reenvío de DNS a través de su VPN o conexión dedicada, mediante opciones como los puntos de conexión de Route 53 Resolver o Azure DNS Private Resolver. Un túnel de red que funciona por sí solo no indica al resolutor de una oficina dónde consultar los nombres privados de la nube.

Route 53 y Azure DNS publican acuerdos de nivel de servicio de disponibilidad del 100 % para sus servicios DNS. Un SLA es un compromiso contractual de servicio; una respuesta en caché puede seguir apuntando a un servidor de aplicaciones que no está disponible.

Una red de distribución de contenido, o CDN, mantiene copias temporales de contenido cerca de los usuarios. Su origen contiene los archivos originales o produce las respuestas de la aplicación. Amazon CloudFront, Azure Front Door y Google Cloud CDN proporcionan este servicio mediante ubicaciones de borde en todo el mundo.

Sigue una solicitud

El navegador resuelve el nombre de la CDN y se conecta a una ubicación de borde cercana. CloudFront puede dirigir a los usuarios mediante respuestas DNS; Azure Front Door y Google Cloud CDN usan direcciones anycast, con las que varias ubicaciones anuncian la misma dirección IP y el enrutamiento lleva a los usuarios a una cercana. Una ubicación de borde no es una región completa de la nube, y los proveedores operan muchas más ubicaciones de borde que regiones.

Se produce un acierto de caché cuando la ubicación de borde tiene una copia vigente y utilizable y la sirve. Ante un fallo de caché, obtiene el contenido del origen, lo devuelve y puede almacenarlo en caché para solicitudes posteriores. Las imágenes, los scripts, las hojas de estilo, las descargas y los vídeos suelen funcionar bien porque muchos usuarios solicitan el mismo contenido.

Mide la ventaja

Las solicitudes a larga distancia tardan más en cada recorrido de ida y vuelta por la red. Una página consultada desde Sídney necesita cuatro recorridos de ida y vuelta secuenciales hasta su origen en Fráncfort. Con 250 ms por recorrido, pasa 1000 ms esperando esos recorridos. Con una ubicación de borde en Sídney que tarda 15 ms por recorrido, los cuatro recorridos tardan 60 ms. Este ejemplo mide el retraso de ida y vuelta, no el tiempo completo de carga de la página.

La tasa de aciertos de caché es:

Con 9200 aciertos de 10 000 solicitudes, la tasa es del 92 %. En este ejemplo sencillo, los 800 fallos llegan al origen. Una tasa de aciertos alta reduce el trabajo del origen y los datos que envía, lo que ayuda ante un aumento repentino de visitantes.

Controla la vigencia

El TTL de una CDN controla cuánto tiempo puede reutilizarse el contenido. El origen puede enviar Cache-Control: max-age=86400, lo que permite un día de almacenamiento en caché, o la configuración de la CDN puede controlar la duración. Cambiar un archivo en el origen no sustituye inmediatamente las copias vigentes en caché.

Para publicar una corrección urgente, invalida o purga la ruta almacenada en caché. Otra opción es publicar un nuevo nombre de archivo, como app.v2.js, y actualizar la página para que lo solicite. El nuevo nombre identifica un objeto diferente. Evita que las páginas personalizadas, como una página de cuenta o un carrito de compra, se compartan como contenido público en caché. Incluso cuando una respuesta no puede almacenarse en caché, la ubicación de borde puede mejorar la entrega al terminar TLS cerca del usuario y reutilizar las conexiones hacia el origen.

Distingue la caché de otros servicios de red

Los equilibradores de carga pueden ser regionales o globales. Global Accelerator proporciona direcciones anycast fijas y puede ser adecuado para tráfico de juegos o voz que no se beneficia de almacenar contenido web en caché.

La ubicación de borde también puede aplicar certificados HTTPS y reglas de cortafuegos de aplicaciones web. Su amplia red absorbe muchos ataques DDoS; CloudFront incluye AWS Shield Standard. Las restricciones de origen, como el control de acceso al origen de CloudFront para S3, pueden impedir que los usuarios eludan la CDN. Los cargos dependen principalmente de los datos entregados y del número de solicitudes. Los usuarios que ya están cerca del origen, o las aplicaciones con respuestas casi siempre únicas, se benefician menos de la caché. Las copias de borde son temporales y pueden eliminarse, por lo que el origen sigue necesitando su propio almacenamiento fiable y copias de seguridad.

Una oficina puede necesitar usar una aplicación en una dirección privada de la nube. Una red híbrida une redes locales con redes en la nube. Una VPN, o red privada virtual, transporta ese tráfico en un túnel cifrado a través de la internet pública.

Elige qué se conecta

Una VPN de sitio a sitio conecta toda una red de oficina o de centro de datos. Un enrutador o cortafuegos compatible con VPN gestiona el túnel para esa sede. Una VPN de punto a sitio, o de cliente, conecta un dispositivo individual que ejecuta software cliente. AWS Client VPN y las conexiones de punto a sitio de Azure VPN Gateway admiten usuarios remotos.

Las VPN de sitio a sitio usan IPsec. Los extremos del túnel se autentican entre sí, a menudo mediante una clave compartida o certificados. IKE, intercambio de claves de internet, acuerda las claves de cifrado; después, IPsec protege los paquetes a través del túnel. Una VPN usa una ruta compartida de internet aunque su contenido esté cifrado.

Identifica ambos extremos

En AWS, una puerta de enlace privada virtual se asocia a una VPC; una puerta de enlace de tránsito puede atender a varias VPC. Azure implementa su puerta de enlace VPN en una subred dedicada llamada GatewaySubnet. Google Cloud ofrece puertas de enlace HA VPN. En la oficina, un enrutador o cortafuegos con una dirección pública proporciona el otro extremo; AWS lo llama dispositivo de puerta de enlace del cliente.

Las puertas de enlace también necesitan rutas. Estas pueden configurarse de forma estática o aprenderse mediante BGP, el protocolo de puerta de enlace de frontera. BGP permite que los enrutadores intercambien los rangos de direcciones a los que pueden acceder. Un túnel cifrado sin las rutas correctas no proporciona a una aplicación una ruta utilizable de extremo a extremo.

Sigue una solicitud privada

Considera una oficina que usa 192.168.10.0/24 y una VPC de AWS que usa 10.0.0.0/16:

1. El equipo crea la puerta de enlace en la nube y configura el enrutador de la oficina para la VPN.
2. La ruta de la oficina para 10.0.0.0/16 apunta al túnel.
3. La ruta en la nube para 192.168.10.0/24 apunta de vuelta a través de la puerta de enlace VPN.
4. El grupo de seguridad de la aplicación permite el tráfico necesario de la oficina.

El dispositivo de oficina 192.168.10.25 puede ahora conectarse a la aplicación 10.0.2.15. Su tráfico se cifra entre los extremos de la VPN. Los rangos que no se solapan permiten que cada lado distinga los destinos locales de los remotos. Los nombres de servicios privados necesitan además reenvío de DNS; el túnel no lo configura automáticamente.

Elimina los puntos únicos de fallo

Una conexión de AWS Site-to-Site VPN proporciona dos túneles hacia distintos puntos de conexión de AWS. Configura ambos para que uno pueda transportar tráfico durante un mantenimiento o fallo. Azure admite puertas de enlace activo-activo. Google Cloud HA VPN puede proporcionar un acuerdo de nivel de servicio de disponibilidad del 99,99 % con la configuración requerida de túneles redundantes en ambas interfaces. Un segundo enrutador de oficina y un segundo proveedor de internet protegen frente a fallos que dos túneles en la nube por sí solos no pueden resolver.

Las VPN suelen poder configurarse en horas con el acceso a internet existente. Los costos incluyen principalmente el tiempo de conexión y la transferencia de datos. La congestión de internet y la distancia afectan a la latencia y a la tasa de transferencia efectiva; un túnel estándar de AWS admite hasta 1,25 Gbps, no una tasa de transferencia sostenida garantizada. Una VPN suele proporcionar acceso inicial mientras se instala un circuito dedicado y después permanece como ruta de respaldo cifrada. Un sitio web público ya destinado a usuarios de internet no necesita una VPN de sitio a sitio para esos visitantes.

Algunas organizaciones necesitan un enlace a la nube con un rendimiento más constante que el que ofrece una ruta por internet. Una conexión privada dedicada une la red de la organización con el proveedor sin cruzar la internet pública. Los servicios son AWS Direct Connect, Azure ExpressRoute y Google Cloud Interconnect.

Sigue la ruta física

Los proveedores de servicios en la nube se encuentran con los clientes y las redes de telecomunicaciones en centros de alojamiento de servidores en instalaciones compartidas, centros de datos donde muchas redes tienen equipos. Si el enrutador del cliente ya está allí, una conexión cruzada, un cable físico corto, lo une al equipo del proveedor. De lo contrario, un socio de telecomunicaciones o conectividad extiende un circuito desde la oficina o el centro de datos hasta ese punto de encuentro.

Contratar el puerto del lado de la nube no elimina la necesidad de llegar a ese centro. La instalación puede implicar una carta de autorización, un pedido de conexión cruzada, un circuito de telecomunicaciones y pruebas coordinadas. Cuenta con semanas de preparación. Los cargos pueden incluir el puerto, el servicio del socio, el circuito de telecomunicaciones y los datos transferidos.

Ajusta el servicio a la capacidad

Un puerto dedicado se ofrece en capacidades fijas elevadas. AWS Direct Connect ofrece conexiones dedicadas de 1, 10, 100 y 400 Gbps. Las opciones proporcionadas por socios, como las conexiones alojadas de AWS y Google Partner Interconnect, ofrecen incrementos de capacidad más pequeños, desde unos 50 Mbps. ExpressRoute suele proporcionarse mediante un proveedor de conectividad.

Un enlace alojado de 50 Mbps tiene menos capacidad que un túnel VPN estándar de AWS con un límite de 1,25 Gbps. La palabra «dedicada» describe la modalidad de conexión; no promete superar a todas las VPN en ancho de banda. Compara la capacidad contratada real y la tasa de transferencia efectiva medida.

Separa la privacidad del cifrado

Evitar la internet compartida mejora la constancia del rendimiento y proporciona una ruta privada. Los circuitos de alta capacidad admiten grandes transferencias periódicas, y las rutas privadas pueden cumplir requisitos que exigen que el tráfico no pase por la internet pública. La salida de datos de AWS mediante Direct Connect también tiene tarifas por gigabyte inferiores a las de la salida por internet, aunque los costos fijos del circuito siguen siendo importantes.

Un circuito privado no está cifrado de forma predeterminada. Si la confidencialidad requiere cifrado, elige un método adecuado: TLS en las aplicaciones, una VPN IPsec sobre el enlace privado o MACsec en puertos dedicados compatibles. TLS protege las sesiones de las aplicaciones; IPsec protege el tráfico IP dentro del túnel; MACsec cifra las tramas en enlaces compatibles. Un requisito de usar una ruta privada y otro de cifrar el tráfico deben cumplirse por separado.

Planifica la rotura de un enlace

Un circuito físico puede fallar por un cable cortado, un fallo de enrutador o una interrupción del centro. Un circuito ExpressRoute tiene dos conexiones a dos enrutadores de borde de Microsoft, pero las cargas de trabajo críticas siguen beneficiándose de conexiones a través de dos ubicaciones. Dos enlaces que pasan por el mismo centro conservan ese centro como punto de fallo compartido.

Una VPN de sitio a sitio puede proporcionar un respaldo de menor costo si falla el enlace privado. Sus rutas y permisos deben estar preparados, y su tasa de transferencia efectiva, menor o más variable, debe ser suficiente para el tráfico esencial. Es posible que la ruta por internet del respaldo no cumpla un requisito estricto de mantener siempre el tráfico fuera de internet; tanto la disponibilidad como los requisitos de la ruta afectan a la elección.

Los enlaces dedicados acceden a recursos de redes virtuales mediante direcciones privadas. Con configuración adicional, también pueden acceder a servicios públicos compatibles en la nube, por ejemplo mediante una interfaz virtual pública de AWS o el emparejamiento de Microsoft de ExpressRoute. Son enlaces de red a la nube; los servidores existentes de la organización permanecen donde están.

La elección de una conexión empieza por el trabajo que debe admitir. Identifica quién necesita acceso, cuánto volumen de datos se mueve, el plazo, la constancia requerida, la fecha de instalación, los requisitos de seguridad y el efecto de una interrupción. Las distintas respuestas llevan a distintos enlaces.

Reduce las opciones

Una empresa con 40 empleados en la oficina y un plazo que vence la próxima semana puede empezar con una VPN de sitio a sitio. Para 300 empleados que trabajan por separado desde casa, una VPN de cliente da a cada dispositivo acceso a las herramientas internas. Un banco que mueve terabytes a diario puede justificar conexiones dedicadas por ubicaciones distintas y cifrado. Un fabricante que espera un circuito puede usar inicialmente una VPN y conservarla como respaldo.

Comprueba la ventana de transferencia

El ancho de banda es la capacidad del enlace; la tasa de transferencia efectiva es la tasa que se alcanza realmente. La latencia es el retraso de un recorrido. Un enlace de gran capacidad puede mover un archivo grande rápidamente mientras que una gran distancia sigue haciendo lento cada recorrido de ida y vuelta.

Usa unidades de datos decimales: 1 GB son mil millones de bytes y 1 TB es un billón de bytes. Cada byte contiene 8 bits. Expresa la cantidad de datos y la tasa en unidades de bits compatibles:

Una copia de seguridad de 2 TB contiene 16 billones de bits. Con 500 Mbps efectivos, divide entre 500 millones de bits por segundo para obtener 32 000 segundos, unas 8,9 horas. Eso supera una ventana de 8 horas. Con 10 Gbps sostenidos, el cálculo da 1600 segundos, unos 27 minutos. Usa la tasa de transferencia efectiva para una estimación práctica; la velocidad anunciada de un puerto por sí sola no tiene en cuenta la sobrecarga del protocolo, la contención ni un disco de origen lento.

Para una migración puntual de tamaño excepcional, una red puede tardar demasiado incluso cuando se utiliza al máximo. Enviar 500 TB a 1 Gbps tarda 4 000 000 de segundos, unos 46 días. Los servicios de transferencia física, como Azure Data Box, pueden mover datos masivos mediante el envío de un dispositivo lleno. Compara el calendario completo de la migración, no solo la transferencia por red.

Comprueba la seguridad y el comportamiento ante fallos

Una VPN proporciona transporte cifrado a través de internet. Un enlace dedicado proporciona una ruta privada y necesita que se añada cifrado cuando sea necesario. Un requisito de ambas propiedades exige ambos controles. Si falla un enlace dedicado, una VPN de respaldo restablece una ruta, pero puede que no mueva los mismos datos dentro de la ventana original. Decide qué aplicaciones deben seguir funcionando y qué puede transportar el respaldo.

Sea cual sea el transporte, comprueba que los rangos de direcciones no se solapen, que haya rutas en ambas direcciones, permisos en los cortafuegos de los recursos y reenvío de DNS para los nombres privados. Un circuito más grande no puede resolver un conflicto de direcciones ni una ruta de retorno ausente. Del mismo modo, un túnel que funciona no puede resolver un nombre privado sin la ruta de resolución adecuada.

Para la decisión final, relaciona cada elección con una necesidad concreta. «VPN porque la oficina necesita acceso privado mañana y el tráfico es moderado» es una explicación útil. «Dedicada porque es más rápida» deja fuera la capacidad contratada, la ventana de transferencia, el plazo de instalación y el plan ante fallos.