Guía

Conectividad de malla completa para muchas VPC, algunas con CIDR superpuestos.

→Implementar Transit Gateway. Remediar los CIDR superpuestos añadiendo bloques de CIDR secundarios únicos a las VPC afectadas.

Por qué: Transit Gateway proporciona enrutamiento transitorio y escalable, pero no puede enrutar entre rangos de IP superpuestos. Se requiere una remediación de IP.

Conectividad híbrida resiliente, de alto rendimiento y baja latencia.

→Aprovisionar dos conexiones Direct Connect dedicadas en dos ubicaciones Direct Connect diferentes.

Por qué: El uso de dos ubicaciones diferentes protege contra fallos a nivel de ubicación (cortes de fibra, cortes de energía), proporcionando la máxima resiliencia. Una sola ubicación, incluso con múltiples conexiones, es un punto único de fallo.

Resolución DNS bidireccional entre zonas alojadas privadas locales y de AWS.

→Usar Route 53 Resolver. Crear Endpoints de Entrada para que las instalaciones locales consulten AWS. Crear Endpoints de Salida con reglas de reenvío para que AWS consulte las instalaciones locales.

Por qué: Los endpoints de entrada proporcionan IPs accesibles para los reenviadores DNS locales. Los endpoints de salida permiten el reenvío condicional desde dentro de la VPC. El resolver predeterminado de la VPC (VPC+2) no es accesible desde las instalaciones locales.

Proporcionar acceso a nivel de servicio entre dos VPC sin crear rutas a nivel de red.

→Usar AWS PrivateLink. Crear un servicio de endpoint de VPC (respaldado por un NLB) en la VPC del proveedor y un endpoint de interfaz de VPC en la VPC del consumidor.

Por qué: PrivateLink proporciona conectividad unidireccional y específica del servicio utilizando ENIs en la VPC del consumidor, evitando completamente el enrutamiento a nivel de red y los problemas de superposición de CIDR.

Proporcionar acceso a Internet solo de salida para instancias habilitadas para IPv6 en subredes privadas.

→Crear un Egress-Only Internet Gateway (EIGW) y añadir una ruta para `::/0` a la tabla de rutas de la subred privada que apunte al EIGW.

Por qué: Un EIGW es stateful para las conexiones IPv6 salientes, permitiendo el tráfico de retorno pero impidiendo conexiones entrantes no solicitadas, análogo a un NAT Gateway pero para IPv6.

Inspeccionar todo el tráfico entre VPCs utilizando AWS Network Firewall en un modelo centralizado con Transit Gateway.

→Crear una VPC de inspección dedicada con Network Firewall. Configurar las tablas de rutas de TGW para enviar todo el tráfico entre VPCs a la VPC de inspección. Dentro de la VPC de inspección, las tablas de rutas deben dirigir el tráfico a través de los endpoints de NFW para un enrutamiento simétrico.

Por qué: Esta arquitectura requiere un enrutamiento cuidadoso: TGW envía el tráfico a la VPC de inspección; las tablas de rutas de la VPC lo envían al endpoint del firewall; el firewall lo envía de vuelta a la ENI de adjunto de TGW; TGW lo enruta al destino final.

Segmentar VPCs (por ejemplo, producción vs. desarrollo) usando Transit Gateway, permitiendo que ambas accedan a una VPC de servicios compartidos.

→Usar múltiples tablas de rutas de Transit Gateway. Crear una tabla de rutas para cada segmento (producción, desarrollo, compartido). Asociar las VPCs con sus tablas respectivas. Propagar rutas para crear una topología de hub-spoke donde los spokes solo puedan ver el hub.

Por qué: Las asociaciones y propagaciones de tablas de rutas de TGW son el mecanismo principal para la segmentación de red y el aislamiento del tráfico a nivel de red.

Reducir la latencia para una aplicación global dinámica y no cacheable (por ejemplo, API, juegos) alojada en una única región.

→Usar AWS Global Accelerator. Proporciona IPs anycast que enrutan a los usuarios a la ubicación de borde de AWS más cercana, luego el tráfico atraviesa la red troncal optimizada de AWS hasta el origen.

Por qué: Global Accelerator optimiza la "primera milla" y la "milla media" a través de la red de AWS, reduciendo la latencia y la fluctuación para el tráfico TCP/UDP. CloudFront es mejor para contenido cacheable.

Proporcionar acceso privado desde una VPC a S3 y DynamoDB sin atravesar Internet.

→Crear Gateway VPC Endpoints para S3 y DynamoDB. Esto añade entradas de lista de prefijos a las tablas de rutas de subred especificadas.

Por qué: Los endpoints de Gateway son el mecanismo específico, de alto rendimiento y sin coste para el acceso privado a S3 y DynamoDB. Otros servicios utilizan Interface Endpoints (PrivateLink).

Acceder a VPCs en múltiples regiones de AWS desde una única conexión Direct Connect local.

→Usar un Direct Connect Gateway con una Interfaz Virtual de Tránsito (T-VIF). Asociar el DX Gateway con Transit Gateways en cada región requerida.

Por qué: Una T-VIF con un DX Gateway es la solución escalable para conectar a múltiples Transit Gateways entre regiones. Una VIF Privada con un DX Gateway tiene límites inferiores.

Integrar un dispositivo de firewall virtual de terceros para una inspección transparente del tráfico.

→Usar un Gateway Load Balancer (GWLB). Opera en la Capa 3 y utiliza el protocolo GENEVE para encapsular el tráfico, preservando la IP de origen/destino original.

Por qué: La encapsulación GENEVE de GWLB lo convierte en un "bump-in-the-wire", insertando transparentemente los dispositivos en la ruta de red sin requerir NAT de origen, lo cual es crítico para los dispositivos de seguridad.

Administrar la asignación de direcciones IP para cientos de VPCs en una organización de múltiples cuentas para prevenir superposiciones y rastrear el uso.

→Usar Amazon VPC IP Address Manager (IPAM). Crear un pool de nivel superior y delegar pools regionales para automatizar la asignación de CIDR de VPC.

Por qué: VPC IPAM es el servicio de AWS diseñado específicamente y escalable para la gestión centralizada de direcciones IP, reemplazando los métodos manuales propensos a errores.

Integrar un dispositivo SD-WAN de terceros con Transit Gateway utilizando túneles GRE y enrutamiento BGP dinámico.

→Usar un adjunto Transit Gateway Connect.

Por qué: TGW Connect está diseñado específicamente para la integración de SD-WAN. Soporta GRE para mayor ancho de banda (hasta 5 Gbps por par) y BGP para enrutamiento dinámico.

Una VPC solo IPv6 necesita comunicarse con recursos solo IPv4 en Internet.

→Habilitar DNS64 en la configuración del Route 53 Resolver de la VPC y configurar un NAT Gateway en una subred pública. Enrutar `64:ff9b::/96` al NAT Gateway.

Por qué: DNS64 sintetiza registros AAAA para destinos IPv4. El NAT Gateway realiza la traducción de protocolo NAT64 desde la dirección IPv6 sintetizada a la dirección IPv4 real.

Conectar cientos de VPCs en muchas regiones con estrictos requisitos de segmentación (producción, desarrollo, servicios compartidos).

→Usar AWS Cloud WAN. Definir segmentos y acciones de segmento en una única política de red central para controlar el enrutamiento entre segmentos a nivel global.

Por qué: Cloud WAN proporciona una política de red global centralizada y declarativa, que es más escalable y menos compleja que gestionar una malla completa de emparejamientos de Transit Gateway y tablas de rutas en cada región.

Agregar múltiples conexiones Direct Connect en una sola ubicación para aumentar el ancho de banda y la redundancia de enlaces.

→Configurar un Link Aggregation Group (LAG). Todas las conexiones deben tener el mismo ancho de banda y terminar en el mismo dispositivo de AWS.

Por qué: Los LAGs agrupan enlaces físicos en un único enlace lógico. Esto proporciona conmutación por error a nivel de enlace pero no protege contra fallos de dispositivo o ubicación. Usar `minimum links` para definir el umbral de conmutación por error.

Lograr una conmutación por error de DNS de menos de 60 segundos para una aplicación multi-región.

→Usar el enrutamiento de conmutación por error de Route 53 con comprobaciones de estado. Configurar comprobaciones de estado de intervalo rápido (10s) con un umbral de fallo bajo (1). Usar registros Alias o TTLs muy bajos (por ejemplo, 10-60s).

Por qué: La conmutación por error rápida requiere detección rápida (comprobaciones de estado rápidas) y actualizaciones rápidas del lado del cliente (TTLs bajos o registros Alias que tienen TTLs dinámicos).

Aumentar el rendimiento agregado de la VPN utilizando ambos túneles de una conexión VPN Site-to-Site simultáneamente.

→Adjuntar la VPN a un Transit Gateway. Habilitar el soporte ECMP en el adjunto de VPN del Transit Gateway.

Por qué: Por defecto, la VPN a TGW puede usar solo un túnel. Habilitar ECMP en el adjunto de TGW distribuye el tráfico a través de ambos túneles si las rutas BGP tienen el mismo costo.

Asegurar que los servicios TCP de backend detrás de un Network Load Balancer vean la dirección IP original del cliente.

→Registrar destinos por ID de instancia. Si los destinos están registrados por IP, habilitar Proxy Protocol v2 en el grupo de destino.

Por qué: Cuando los destinos se registran por ID de instancia, el NLB preserva la IP del cliente por defecto. Si se registran por IP, la IP del NLB se convierte en el origen, y se necesita Proxy Protocol v2 para pasar la IP original.

Influir en cómo AWS enruta el tráfico de vuelta a una red local cuando existen múltiples rutas Direct Connect.

→Usar el prefijo de ruta BGP AS en la ruta menos preferida desde el router local.

Por qué: Para el tráfico saliente de AWS, el mecanismo principal controlado por el cliente es la longitud de la ruta AS. AWS prefiere la ruta con la longitud de ruta AS más corta. No se puede configurar la preferencia local en el lado de AWS.

Permitir que las cuentas spoke en una organización de AWS adjunten sus VPCs a un Transit Gateway propiedad de una cuenta central de red.

→Usar AWS Resource Access Manager (RAM). La cuenta de red comparte el Transit Gateway con la Organización o con OUs específicas.

Por qué: RAM es el servicio de AWS diseñado específicamente para compartir recursos como Transit Gateways entre cuentas. Esto permite una gestión centralizada al tiempo que habilita el adjunto de autoservicio para las cuentas spoke.

Agregar rendimiento más allá del límite de 1.25 Gbps de un solo túnel VPN.

→Crear múltiples conexiones VPN Site-to-Site a un Transit Gateway con ECMP habilitado.

Por qué: Cada túnel VPN está limitado a ~1.25 Gbps. Para escalar, se deben usar múltiples túneles/conexiones y aprovechar ECMP en un Transit Gateway para equilibrar la carga del tráfico entre ellos.

Configurar comprobaciones de estado de Route 53 para un recurso interno, no expuesto a Internet, como un ALB interno.

→Crear una alarma de CloudWatch que monitorice una métrica para el recurso interno (por ejemplo, `HealthyHostCount` para un ALB). Configurar la comprobación de estado de Route 53 para monitorizar el estado de la alarma de CloudWatch.

Por qué: Los comprobadores de estado de Route 53 son externos. Para monitorizar recursos internos, deben monitorizar una señal proxy como el estado de una alarma de CloudWatch, que puede ser activada por métricas internas.

Conmutar automáticamente el tráfico de CloudFront a un origen secundario (por ejemplo, un sitio S3 estático) cuando el origen primario (por ejemplo, un ALB) devuelve errores 5xx.

→Crear un CloudFront Origin Group con el ALB como primario y S3 como secundario. Configurarlo para que conmute por error en los códigos de estado especificados (por ejemplo, 500, 502, 503, 504).

Por qué: Los Origin Groups son el mecanismo nativo de CloudFront para alta disponibilidad, proporcionando una conmutación por error sin interrupciones en el borde sin requerir cambios de DNS.

Lograr una conmutación por error de menos de un segundo para una conexión Direct Connect a una VPN de respaldo o una ruta DX secundaria.

→Habilitar Bidirectional Forwarding Detection (BFD) en la interfaz virtual de Direct Connect. Configurar BFD en el router local.

Por qué: BFD proporciona una detección de fallos de enlace mucho más rápida (tan baja como 300ms) en comparación con los temporizadores de keepalive de BGP (90s por defecto), permitiendo una rápida reconvergencia del tráfico.

Habilitar la conectividad entre Transit Gateways en dos regiones diferentes.

→Establecer una conexión de emparejamiento de Transit Gateway. Añadir manualmente rutas estáticas en cada tabla de rutas de TGW apuntando a los CIDR de la región remota a través del adjunto de emparejamiento.

Por qué: Crucialmente, el emparejamiento entre regiones de Transit Gateway no soporta la propagación dinámica de rutas. Todas las rutas entre regiones deben configurarse estáticamente.

Solucionar problemas de conectividad dentro de AWS identificando el componente de bloqueo específico (por ejemplo, ruta, NACL, SG).

→Usar VPC Reachability Analyzer. Especificar un origen y un destino, y realiza un análisis estático de la configuración de la ruta de red.

Por qué: Reachability Analyzer proporciona un análisis definitivo, salto a salto, de los constructos de red de AWS, lo cual es más efectivo que traceroute (que puede no funcionar) o la comprobación manual de cada componente.

Almacenamiento a largo plazo y consulta ad-hoc de logs de flujo detallados de VPC para cumplimiento.

→Publicar logs de flujo directamente en S3 en formato Parquet con un diseño de campo personalizado. Usar Amazon Athena para consultas ad-hoc basadas en SQL.

Por qué: S3 es el almacenamiento más rentable. El formato Parquet es altamente eficiente para las consultas de Athena, reduciendo los costos de escaneo y mejorando el rendimiento. Este es el patrón sin servidor y escalable para el análisis de logs de flujo.

Aplicar de forma centralizada reglas de grupo de seguridad obligatorias en todas las VPCs de una organización de AWS y remediar automáticamente el incumplimiento.

→Usar AWS Firewall Manager con una política de auditoría de grupos de seguridad. Definir las reglas requeridas y configurar la política para remediar automáticamente los grupos no conformes.

Por qué: Firewall Manager es la herramienta de gobernanza centralizada para políticas de seguridad (WAF, SG, NFW) en una Organización. Su política de auditoría con auto-remediación proporciona aplicación.

Visualizar y monitorizar una topología de red global que incluya Transit Gateways, VPNs y Direct Connect en todas las regiones y cuentas.

→Usar AWS Network Manager. Registrar Transit Gateways en una única red global para obtener un panel de control centralizado, un mapa de topología y monitorización de estado.

Por qué: Network Manager está diseñado específicamente para proporcionar un panel único para redes de AWS globales complejas, consolidando la monitorización y la gestión.

Diagnosticar pérdida intermitente de paquetes o errores en una conexión Direct Connect.

→Verificar las métricas de CloudWatch de Direct Connect (`ConnectionErrorCount`). En el router del cliente, verificar los niveles de señal óptica (niveles de luz Tx/Rx) y los contadores de errores de interfaz (errores CRC, errores de entrada).

Por qué: La pérdida de paquetes puede ser un problema de la capa física. Se necesitan tanto métricas del lado de AWS como diagnósticos del router del lado del cliente para aislar problemas como un cable de fibra óptica o un transceptor degradado.

Detectar y remediar automáticamente configuraciones de red no conformes, como un grupo de seguridad que permite el acceso público SSH.

→Usar AWS Config con una regla gestionada (por ejemplo, `restricted-ssh`) y configurar una acción de remediación automática utilizando un documento de automatización de SSM.

Por qué: Esto proporciona un sistema de cumplimiento de circuito cerrado. AWS Config detecta la violación y su acción de remediación activa un documento de SSM para corregir automáticamente la configuración.

Identificar proactivamente rutas de acceso de red no intencionadas a recursos sensibles desde Internet u otras redes no confiables.

→Usar VPC Network Access Analyzer. Definir un alcance de acceso y ejecutar un análisis para obtener una lista de todas las posibles rutas de red que coincidan.

Por qué: Esta herramienta realiza una verificación formal de la red, analizando todos los componentes (SGs, NACLs, TGW, IGW) para encontrar rutas potenciales, lo cual es más completo que las comprobaciones manuales o el monitoreo reactivo.

Recopilar logs de flujo de VPC, logs de consultas DNS y logs de Network Firewall de muchas cuentas miembro en una cuenta de logging central.

→Configurar servicios en cuentas miembro para publicar logs directamente en un bucket S3 centralizado (para Flow Logs/NFW) o un grupo de logs de CloudWatch (para logs DNS) en la cuenta de logging, utilizando políticas de bucket de cuentas cruzadas y roles de IAM.

Por qué: La publicación directa de logs entre cuentas es el patrón más eficiente y escalable, aprovechando las capacidades nativas de AWS sin requerir agentes o complejos pipelines de datos.

Optimizar los costos de red para el tráfico de alto volumen entre pares específicos de VPCs en una arquitectura de hub-and-spoke de Transit Gateway.

→Para pares de VPCs con mucho tráfico, crear una conexión de emparejamiento de VPC directa para evitar el Transit Gateway. Mantener el TGW para todo el demás tráfico hub-spoke.

Por qué: El emparejamiento de VPC no tiene un cargo por procesamiento de datos por GB (solo la transferencia de datos estándar), mientras que Transit Gateway sí. Mover el tráfico punto a punto de alto volumen al emparejamiento reduce significativamente los costos.

Cifrar el tráfico de Direct Connect en la Capa 2 para un rendimiento a velocidad de línea.

→Habilitar MACsec (IEEE 802.1AE). Requiere una conexión dedicada de 10Gbps o 100Gbps en una ubicación compatible con MACsec.

Por qué: MACsec proporciona cifrado salto a salto entre el router del cliente y el dispositivo de AWS, asegurando el enlace físico con una sobrecarga de rendimiento mínima.

Proteger una aplicación web de ataques comunes (SQLi, XSS) y restringir el acceso por país.

→Usar AWS WAF. Adjuntar una ACL web al ALB/CloudFront. Usar grupos de reglas gestionadas de AWS (por ejemplo, `AWSManagedRulesSQLiRuleSet`, `AWSManagedRulesCommonRuleSet`) y crear una regla de geo-coincidencia.

Por qué: Las AWS Managed Rules proporcionan protección lista para usar contra amenazas comunes, mientras que las reglas de geo-coincidencia proporcionan control geográfico. Este es el patrón de implementación estándar de WAF.

Implementar aislamiento de aplicaciones de múltiples niveles (por ejemplo, web -> app -> db) dentro de una VPC.

→Crear un grupo de seguridad para cada nivel. Usar referencias de ID de grupo de seguridad en las reglas (por ejemplo, el app-sg permite la entrada desde el web-sg).

Por qué: Referenciar grupos de seguridad es más dinámico y seguro que usar rangos CIDR. Se adapta automáticamente a medida que se añaden o eliminan instancias de un nivel.

Monitorizar y detectar amenazas basadas en DNS como el tunneling de DNS y la comunicación con servidores C2.

→Habilitar el registro de consultas del Route 53 Resolver. Habilitar Amazon GuardDuty, que analiza los logs de consultas DNS como fuente de datos.

Por qué: GuardDuty tiene inteligencia de amenazas incorporada que analiza los logs de DNS para detectar dominios maliciosos conocidos, DGAs y patrones de consulta anómalos indicativos de exfiltración de datos.

Asegurar que el contenido de S3 solo sea accesible a través de CloudFront, no directamente a través de la URL de S3, al tiempo que se permite el acceso a otros principales de IAM.

→Usar Origin Access Control (OAC). Actualizar la política del bucket de S3 para permitir el acceso desde el principal de servicio de OAC y cualquier otro rol/usuario de IAM requerido.

Por qué: OAC es el reemplazo moderno de OAI. Crea un principal de servicio que puede ser referenciado en las políticas de bucket, proporcionando un control de acceso más granular y flexible.

Evitar que los usuarios eludan CloudFront y accedan directamente a un origen ALB.

→Configurar CloudFront para añadir un encabezado HTTP personalizado con un valor secreto a las solicitudes de origen. Crear una regla de oyente de ALB que verifique este encabezado y valor, bloqueando las solicitudes que no lo tengan.

Por qué: Esto proporciona una protección más fuerte que las restricciones basadas en IP (utilizando la lista de prefijos gestionada), ya que verifica que la solicitud provino de su distribución específica. Usar ambos para una defensa en profundidad.

Capturar datos completos de paquetes de red de una instancia EC2 específica para análisis forense sin instalar agentes.

→Usar VPC Traffic Mirroring. Configurar una sesión de espejo en la ENI de la instancia para copiar el tráfico a un destino (por ejemplo, un NLB que esté delante de herramientas de análisis).

Por qué: Traffic Mirroring proporciona captura de paquetes completa y sin agentes, lo cual es esencial para un análisis forense profundo. Los logs de flujo solo proporcionan metadatos.

Proporcionar protección DDoS integral para aplicaciones de cara al público.

→Suscribirse a AWS Shield Advanced. Asociar la protección con recursos críticos (CloudFront, ALB, EIPs, Route 53). Usar AWS WAF para la mitigación de Capa 7. Involucrar al Shield Response Team (SRT) durante los ataques.

Por qué: Shield Advanced proporciona detección mejorada, protección de costos contra el escalado inducido por DDoS y acceso al SRT para asistencia experta, lo cual es crítico para aplicaciones de misión crítica.

Emitir y rotar automáticamente certificados TLS para microservicios internos desde una Autoridad de Certificación privada.

→Usar AWS Private Certificate Authority (Private CA) para crear la CA. Usar AWS Certificate Manager (ACM) para emitir y gestionar el ciclo de vida (incluida la renovación automática) de certificados privados desde esa CA.

Por qué: Esta combinación proporciona una solución PKI privada totalmente gestionada, automatizando el complejo ciclo de vida de los certificados internos sin exposición pública.

Evitar que cualquier usuario en cualquier cuenta miembro de una organización de AWS cree o adjunte un internet gateway.

→Aplicar una Política de Control de Servicios (SCP) en la raíz de la Organización que deniegue las acciones `ec2:CreateInternetGateway` y `ec2:AttachInternetGateway`.

Por qué: Las SCPs proporcionan barreras de seguridad preventivas que no pueden ser anuladas por las políticas de IAM dentro de las cuentas miembro, convirtiéndolas en la herramienta definitiva para aplicar políticas de seguridad a nivel de organización.

Desencriptar e inspeccionar el tráfico HTTPS en busca de amenazas usando AWS Network Firewall, luego volver a cifrarlo.

→Crear o importar un certificado CA en ACM. Crear una configuración de inspección TLS en la política de firewall que haga referencia a esta CA. Distribuir el certificado CA a los sistemas cliente como una CA raíz de confianza.

Por qué: Network Firewall realiza la inspección TLS mediante un enfoque de hombre en el medio, utilizando una CA que usted proporciona para volver a firmar certificados sobre la marcha. Los clientes deben confiar en esta CA para evitar errores de certificado.

Bloquear consultas DNS a dominios maliciosos conocidos en todas las VPCs de una organización de AWS.

→Crear grupos de reglas de DNS Firewall en una cuenta central usando listas de dominios gestionadas por AWS. Compartir los grupos de reglas a través de RAM y asociarlos con VPCs en cuentas miembro.

Por qué: DNS Firewall proporciona inteligencia de amenazas gestionada y actualizable centralmente para bloquear dominios maliciosos en la capa de resolución de DNS, un control de seguridad crítico.

Cifrar todo el tráfico de red entre instancias EC2 en la misma VPC sin cambios en la aplicación.

→Usar tipos de instancia basados en AWS Nitro System.

Por qué: Las instancias Nitro cifran automáticamente todo el tráfico entre instancias a nivel de hardware, proporcionando cifrado transparente y a velocidad de línea sin necesidad de configuración.