--- title: "AWS refuerza su interconexión privada en España: nuevo punto de Direct Connect en Madrid (Digital Realty MAD3) con enlaces de 10 y 100 Gbps y MACsec" description: "Amazon Web Services ha abierto un nuevo emplazamiento de AWS Direct Connect en el centro de datos MAD3 de Digital Realty , en el área metropolitana de Madrid. Con este anuncio, la capital suma tres ub..." url: https://revistacloud.com/aws-refuerza-su-interconexion-privada-en-espana-nuevo-punto-de-direct-connect-en-madrid-digital-realty-mad3-con-enlaces-de-10-y-100-gbps-y-macsec/ date: 2025-10-10 modified: 2025-10-10 author: "Antonio" image: https://revistacloud.com/wp-content/uploads/2016/02/sala-de-dentro-de-datos-en-interxion-madrid.jpg categories: ["Noticias"] tags: ["aws", "Digital Realty", "direct connect", "interxion"] type: post lang: es --- # AWS refuerza su interconexión privada en España: nuevo punto de Direct Connect en Madrid (Digital Realty MAD3) con enlaces de 10 y 100 Gbps y MACsec Amazon Web Services ha abierto un **nuevo emplazamiento de AWS Direct Connect** en el **centro de datos MAD3 de [Digital Realty](https://revistacloud.com/tag/digital-realty/)**, en el área metropolitana de Madrid. Con este anuncio, la capital suma **tres** ubicaciones de Direct Connect y **España alcanza cuatro** puntos en total, ampliando las opciones para que empresas y administraciones **conecten su red privada** con la nube de AWS mediante **enlaces físicos dedicados** y **cifrado MACsec**. La novedad aterriza en un momento de fuerte adopción de **arquitecturas híbridas y multicloud**, *workloads* de **IA**, analítica en tiempo real y **banca digital**, donde la **consistencia de red** y la **latencia controlada** se han convertido en piezas críticas. Para muchos casos de uso, mover tráfico sensible por **enlaces privados**—en lugar de salir a Internet—reduce **variabilidad**, simplifica **cumplimiento** y evita sorpresas en **picos de demanda**. --- ## Qué ofrece el nuevo sitio de Direct Connect en MAD3 - **Acceso privado** (capa 2) desde Madrid a **todas las regiones públicas de AWS** (excepto China), a **AWS GovCloud** y a **Local Zones**. - **Capacidades dedicadas**: puertos físicos de **10 Gbps** y **100 Gbps** (con opción de **LAG** para agregar enlaces y escalar). - **Cifrado en el enlace**: **MACsec** disponible entre su equipo y el puerto de AWS, añadiendo **confidencialidad y protección** contra manipulación a nivel de Ethernet. - **Menos *jitter***, menor dependencia de Internet y posibilidad de **segmentar tráfico** (producción, DR, backups, datos sensibles) con políticas a medida. Para el cliente, el flujo típico es **solicitar el puerto** en el *console*, recibir la **LOA-CFA**, tramitar el **cross-connect** dentro del *data center* y **levantar la capa 3** (BGP) hasta los **Virtual Interfaces** que darán acceso a **VPCs, S3, DynamoDB** u otros servicios compatibles. --- ## Por qué importa (más allá de los gigabits) **1) Variabilidad a la baja.** Las aplicaciones modernas—pagos en tiempo real, *trading*, *replication* de bases de datos o *training* de modelos—sufren cuando la red se comporta de forma impredecible. Los **circuitos dedicados** aportan **predecibilidad**: no hay “tráfico de terceros” disputando ancho de banda. **2) Seguridad y cumplimiento.** Muchas normativas valoran que el flujo **no salga a Internet** y viaje por **circuitería privada**; si además se activa **MACsec** en el tramo físico, se gana **cifrado por hardware** y **protección** frente a escuchas en la última milla del *colocation*. **3) Control de costes.** En escenarios de alto volumen (p. ej., **copias** diarias hacia **S3**, **ETL** intensivo, **data lakes** en **EMR**), canalizar tráfico por **Direct Connect + tarifas de *data transfer*** puede resultar **más eficiente** que pagar *egress* por Internet, al tiempo que se evitan tasas por picos inesperados en IPS/ISP. **4) Híbrido real.** *Mainframes*, *on-prem* y nube conviven. Con Direct Connect se pueden **anunciar prefijos** on-prem hacia AWS y **llevar rutas** de VPC a su *data center*, orquestando **DR** y **activos compartidos** con latencias y *SLA* más predecibles que con una VPN convencional. --- ## Madrid como hub: más resiliencia, menos latencia La tercera ubicación en Madrid mejora la **opción de redundancia geográfica** dentro del mismo mercado. Es factible **terminar dos puertos** en **instalaciones distintas** (p. ej., un 100 Gbps en MAD3 y otro en otro *site* de la capital) y levantar **VIFs** redundantes para **alta disponibilidad**. En términos prácticos, esto se traduce en: - **Plan A/B** físico y lógico (dos edificios, dos *cross-connect*, dos fibras). - **Failover/BGP** afinado con **timers** y políticas de **ruta preferida** por latencia o coste. - **Pruebas programadas** de caída de un lado sin impacto en producción. Para organizaciones con sedes en la Península, el emplazamiento madrileño reduce **saltos** y **milisegundos** respecto a otros *hubs* europeos, algo que se nota en **ingestas**, **escritorios virtuales** o **servicios al cliente**. --- ## Casos de uso donde Direct Connect brilla - **Servicios financieros**: *core banking*, pagos instantáneos, conciliación y **reporting** regulatorio. - **IA y datos**: *feature stores*, *training* distribuido, *feature pipelines* con flujos constantes a/desde **S3** o **Redshift**. - **Media y entretenimiento**: ingestión en bruto (vídeo, audio), *render farms* y distribución a *partners* con **SLA**. - **Industria y OT**: telemetría desde plantas, **MES/ERP** híbridos, *digital twins* con sincronización estable. - **Sector público y sanidad**: historiales, imágenes médicas y **servicios críticos** con exigencia de **segmentación** y **cifrado**. --- ## Modelos de despliegue: dedicado, hospedado y *partners* - **Dedicated Connection** (10/100 Gbps): puerto físico en el *rack* de AWS dentro del *colo* (MAD3). Requiere **cableado** y **equipamiento propio**. - **Hosted Connection**: el ancho de banda se “subarrienda” a través de un **partner** con presencia en el *colo*. Útil para **pruebas**, escalado gradual o cuando no compensa un puerto completo. - **LAG y VIFs múltiples**: agregue varios puertos para **escala** y **resiliencia**; cree **Virtual Interfaces** separadas para *prod*, *dev*, **transit** o **VIFs** hacia cuentas distintas (*multi-account*). **Consejo operativo:** trate Direct Connect como **cualquier circuito WAN crítico**: dos *paths*, **monitorización SNMP/NetFlow**, *playbooks* de conmutación y **pruebas trimestrales**. --- ## Seguridad: MACsec no es TLS (y eso es bueno) **MACsec** (IEEE 802.1AE) cifra **tramas Ethernet** punto a punto entre su **equipo de borde** y el **puerto** de AWS en el *colo*. No sustituye el **cifrado de aplicación** (TLS en HTTPS, S2S IPsec, KMS), lo **complementa**: - Cubre el **tramo físico** del **cross-connect** y el puerto, mitigando ataques de **intercepción local**. - Aporta **integridad** y **autenticación** a nivel de **enlace** con **latencia mínima**. - Es transparente para **BGP/VLAN** y resto de la pila. Para cargas que requieren **cifrado extremo a extremo**, mantenga **TLS**, **client-side encryption** y **políticas de KMS**; considere **PrivateLink** y **VPC endpoints** para mantener tráfico de servicio dentro de la **malla privada**. --- ## ¿Y los costes? Direct Connect tiene tres bloques de coste habituales: 1. **Puerto** (10/100 Gbps) o **capacidad hospedada** (según partner). 2. **Data transfer** (ingreso/salida) bajo tarifa de **Direct Connect** (suele ser **más predecible** que el *egress* a Internet). 3. **Colocation**: el **cross-connect** y el **lateral** del *rack* (se contrata con el *data center*). La **ecuación de ahorro** depende del **volumen** y **patrones**. Para una pyme con tráfico moderado, una **VPN site-to-site** puede ser suficiente. Para una organización con **decenas de terabytes** mensuales o picos regulares, Direct Connect suele **amortizar** por **consistencia** y **precio por GB**. --- ## Cómo empezar (lista rápida) 1. **Evalúe** el caso de negocio (latencia, GB/mes, cumplimiento, picos). 2. **Elija** modelo: dedicado (10/100 Gbps) o **hosted** vía *partner*. 3. **Solicite** el puerto en la consola y descargue la **LOA-CFA**. 4. **Tramite** el **cross-connect** con Digital Realty (MAD3). 5. **Implemente BGP** y **VLAN** (VIFs) hacia las cuentas/VRFs deseadas. 6. **Pruebe**: *failover*, *throughput*, **MACsec**, *monitoring*. 7. **Documente** y **automatice** (Infra as Code para VIFs, alarmas, *dashboards*). --- ## El contexto español: más puntos, más opciones Con **tres** ubicaciones en Madrid y **cuatro** en España, la interconexión privada con AWS gana **capilaridad**. Para clientes con presencia en **Cataluña, Comunidad Valenciana, Andalucía** o **País Vasco**, la red de *colo* y *carriers* facilita **backhaul** a MAD3 y el resto de *sites*, ofreciendo **trayectorias diversas** y **acuerdos de nivel de servicio** acordes con necesidades críticas. --- ## Conclusión El nuevo **Direct Connect en MAD3** refuerza la posición de Madrid como **hub de interconexión** en la Península y da a las organizaciones una vía más para construir **redes híbridas** con **consistencia**, **seguridad de enlace** (*MACsec*) y **escala** (10/100 Gbps). No es una varita mágica—sigue exigiendo **diseño**, **redundancia** y **monitorización**—pero para quien mueve datos a gran escala o no puede vivir con la variabilidad de Internet, **marca la diferencia** entre “funciona la mayoría de días” y “funciona siempre”. --- ### Preguntas frecuentes **¿Qué diferencia práctica hay entre AWS Direct Connect y una VPN site-to-site por Internet?** Direct Connect ofrece **enlaces físicos dedicados** con **menor jitter** y **SLA** más predecibles. La VPN viaja por Internet y está sujeta a **congestión** y **variabilidad**. A menudo se combinan: **Direct Connect + IPsec** sobre el enlace para **cifrado adicional**. **¿Puedo usar MACsec y, además, cifrado de aplicación (TLS/KMS)?** Sí, y es lo recomendable. **MACsec** protege el **tramo de enlace**; **TLS/KMS** protege el **contenido extremo a extremo** en capas superiores. Son **complementarios**. **¿Cómo dimensiono 10 Gbps vs 100 Gbps y cuándo usar LAG?** Depende de **picos** y **crecimiento**. Muchas empresas empiezan con **10 Gbps** y agregan con **LAG** al crecer. Si su *baseline* ya se acerca a 10 Gbps sostenidos o requiere **muchas VIFs**, un **100 Gbps** puede simplificar y dar margen. **¿Qué *down-time* implica la puesta en marcha?** El *turn-up* del puerto no corta su producción actual; el impacto depende del **cambio de rutas**. Con **BGP bien planificado** (preferencias/med), puede **migrar** tráfico de forma **gradual** y con **cortes mínimos o nulos**.