Construir sobre bases sólidas: Por qué su infraestructura en la nube es más importante que nunca

RESUMEN

El borrador del blog «Construyendo sobre Cimientos Sólidos» reflexiona sobre la interrupción masiva de AWS de ayer, causada por un fallo en la resolución de DNS en la región US-EAST-1 de AWS, que se propagó a numerosos servicios a nivel mundial. Desde mi perspectiva como parte de nuestro equipo de vCISO, esta interrupción ilustra claramente que depender de un solo proveedor de nube o sistema DNS, sin estrategias de conmutación por error multinube y DNS resilientes y multiproveedor, es como construir un negocio sobre arena.

Quiero destacar que, si bien operamos principalmente con Google Cloud Platform (GCP), trabajamos con clientes en todas las nubes, promoviendo un enfoque multinube en lugar de reemplazar a los proveedores existentes. GCP ofrece ventajas significativas, especialmente para cargas de trabajo de IA generativa a través de Vertex AI, la infraestructura TPU de Google y el ecosistema Gemini AI. Google Workspace también funciona como una solución de continuidad empresarial infrautilizada, pero vital, que complementa las suites de productividad existentes.

El blog enfatiza las configuraciones prácticas de resiliencia de DNS, incluyendo el DNS autoritativo multiproveedor de GoDaddy con registros NS delegados tanto a AWS Route 53 como a Google Cloud DNS, la distribución geográfica de DNS, la conmutación por error automatizada basada en comprobaciones de estado y la seguridad DNSSEC. Esta estrategia de DNS, combinada con la monitorización automatizada y las pruebas de recuperación ante desastres, es crucial para mitigar los riesgos de interrupciones centradas en el DNS, como la interrupción de ayer.

Finalmente, relaciono estas estrategias de resiliencia con los riesgos más amplios que los equipos de CISO y vCISO gestionan a diario (riesgo de proveedores externos, planificación de la continuidad del negocio y respuesta a incidentes) y afirmo que una arquitectura multicloud eficaz y las prácticas de infraestructura como código son fundamentales para respaldar las implementaciones de IA de misión crítica con una infraestructura segura, compatible y fiable.

En resumen, la interrupción del servicio de ayer pone de relieve la importancia de que las organizaciones adopten la multicloud, inviertan en resiliencia de DNS y construyan bases de infraestructura que perduren, no solo que funcionen.

---

Artículo completo

La interrupción de AWS del lunes fue un duro recordatorio de algo que hablo constantemente con mis clientes: la fiabilidad de su infraestructura en la nube depende de los cimientos sobre los que la ha construido. Mientras observaba a más de 1000 empresas luchando por restaurar sus servicios, a 6,5 ​​millones de usuarios sin acceso a aplicaciones críticas y a empresas perdiendo ingresos minuto a minuto, la misma idea me rondaba la cabeza: para muchas de ellas, esto era totalmente evitable.

Esto no pretende criticar a AWS (todos los proveedores sufren interrupciones, incluido Google Cloud), sino compartir lo que hemos aprendido como equipo de vCISO que ayuda a las organizaciones a construir arquitecturas de nube resilientes y preparadas para el futuro. Porque esta es la incómoda verdad: si apuesta todo su negocio a un solo proveedor de nube sin una estrategia de conmutación por error, está construyendo su casa sobre arena.

«Su infraestructura en la nube es tan confiable como las bases sobre las que la ha construido.»

La verificación de la realidad del DNS que todos necesitábamos

La interrupción de ayer se originó por algo aparentemente simple: un fallo en la resolución de DNS de los puntos finales de la API de DynamoDB en la región US-EAST-1 de AWS. El Sistema de Nombres de Dominio (DNS), básicamente la guía telefónica de internet, no pudo traducir los nombres de los servicios de DynamoDB a sus direcciones IP correspondientes. En ese caso, las aplicaciones no pudieron encontrar sus bases de datos, los sitios web no pudieron acceder a sus sistemas de autenticación y los dispositivos domésticos inteligentes no pudieron comunicarse con el servidor.

Este es exactamente el tipo de punto único de falla que me mantiene despierto por la noche como parte de un equipo vCISO.

Lo que hizo que esto fuera particularmente devastador no fue solo el fallo del DNS, sino que muchas organizaciones no contaban con una estrategia de resiliencia de DNS. No tenían configuración de DNS multiproveedor. No tenían conmutación por error automatizada a regiones alternativas. No tenían servidores de nombres distribuidos geográficamente. Cuando falló la resolución de DNS de AWS, estas empresas descubrieron que habían construido toda su presencia digital con una única dependencia de DNS.

Así es como se ve la resiliencia de DNS adecuada en la práctica:

Arquitectura DNS multiproveedor: Configure DNS autoritativo entre varios proveedores (normalmente recomendamos Google Cloud DNS junto con su proveedor principal). Cuando un proveedor de DNS experimenta problemas, las consultas se resuelven automáticamente mediante alternativas eficaces.

Distribución geográfica de DNS: Distribuya los servidores DNS entre múltiples regiones y proveedores. Si el DNS US-EAST-1 de AWS falla, su infraestructura de DNS debería procesar sin problemas las respuestas de las regiones europe-west2 o asia-southeast1 de GCP.

Conmutación por error basada en comprobación de estado: implemente una supervisión de estado automatizada que detecte fallas en los puntos finales y actualice los registros DNS en tiempo real, redirigiendo el tráfico a alternativas saludables incluso antes de que los usuarios noten la degradación.

DNSSEC y controles de seguridad: habilite las extensiones de seguridad de DNS en todos los proveedores para evitar el envenenamiento de caché y los ataques de suplantación de identidad durante escenarios de conmutación por error.

Las organizaciones que superaron con éxito la interrupción del servicio de ayer habían invertido en estos fundamentos de resiliencia del DNS. Como Arquitecto Principal de Nube de nuestro equipo de vCISO, este es precisamente el tipo de trabajo de base de infraestructura que implementamos para nuestros clientes, ya que las fallas del DNS son inevitables, pero la interrupción del negocio causada por el DNS es completamente opcional.

La fiebre del oro de la IA y la infraestructura de la que nadie habla

Todos se apresuran a implementar la IA generativa. Gemini, ChatGPT, LLM personalizados… las conversaciones en las salas de juntas son electrizantes. Vemos organizaciones que impulsan proyectos de IA a un ritmo vertiginoso, desesperadas por no quedarse atrás de la competencia. Y lo entiendo. El potencial es realmente transformador.

Pero esto es lo que me quita el sueño como parte de un equipo de vCISO: el 98 % de las organizaciones están explorando la IA generativa, pero la mayoría no ha construido la base de infraestructura para respaldarla de manera confiable.

Piense en lo que sucede cuando implementa un servicio de IA de producción en una infraestructura que no ha sido reforzada para ser resiliente:

• Su chatbot de atención al cliente con IA deja de funcionar durante una interrupción del proveedor.
• Su flujo de contenido generativo se detiene a mitad de campaña.
• Su motor de análisis basado en IA pierde el acceso a las fuentes de datos en tiempo real.
• Sus herramientas de monitorización de IA, esenciales para el cumplimiento normativo, no pueden alertarle sobre incidentes de seguridad.

Acabas de construir un Ferrari sobre una base de arena. Y cuando sube la marea —y lo hará, como vimos ayer— todo se derrumba.

Acabas de construir un Ferrari sobre una base de arena.

Por qué Google Cloud Platform merece su atención

Quiero hablar sobre Google Cloud Platform, teniendo en cuenta que Wursta no es exclusivamente una tienda de GCP (trabajamos con clientes de todos los proveedores de nube), sino porque GCP ofrece algunas ventajas realmente atractivas que a menudo se pasan por alto en la conversación sobre el duopolio AWS-Azure.

La ventaja de la infraestructura de IA

Google no integró la IA en una plataforma de nube existente; construyó su infraestructura de nube en torno a la IA desde cero. Al implementar cargas de trabajo de IA generativa en GCP, se aprovechan:

• Vertex AI: Una plataforma unificada que gestiona todo, desde el entrenamiento de modelos hasta la implementación, con seguridad y gobernanza de nivel empresarial integradas desde el primer día. Sin necesidad de añadir controles de cumplimiento a posteriori.

• Chips TPU v5p e Ironwood: Los aceleradores de IA personalizados de Google ofrecen un rendimiento de inferencia por dólar hasta 2,5 veces superior en comparación con generaciones anteriores. Al ejecutar IA a gran escala, esa rentabilidad no es un lujo: marca la diferencia entre una estrategia de IA sostenible y un agujero negro en el presupuesto.

• El ecosistema de Gemini: Acceso a los modelos multimodales de vanguardia de Google (Gemini 2.5 Flash, Imagen para imágenes, Veo para vídeo) con una ventana de contexto de 2 millones de tokens. Para aplicaciones de IA con gran dependencia del contexto, esto es revolucionario.
• Infraestructura de red global: La red de fibra privada de Google ofrece constantemente la latencia media más baja del mundo: alrededor de 40 ms para la entrega de contenido estático a usuarios del Reino Unido y Europa, frente a los 50 ms de Azure y los 60 ms de AWS. Al desarrollar aplicaciones de IA en tiempo real, esos milisegundos son cruciales.
• Resiliencia de DNS integrada: Google Cloud DNS incluye distribución geográfica, comprobación automatizada del estado de servicio y funciones de sincronización con múltiples proveedores listas para usar. Tras la interrupción de AWS de ayer, esto no es un lujo técnico, sino un seguro para el negocio.

El imperativo de las múltiples nubes

Aquí es donde la cosa se pone interesante. No estamos diciendo «eliminar AWS y apostar todo por GCP» ni abandonar por completo su proveedor de nube actual. Eso sería tan absurdo como la estrategia de un solo proveedor que dejó a tantas empresas vulnerables ayer.

Lo que defendemos es una arquitectura estratégica multi-nube.

La interrupción de AWS de ayer demostró lo que he estado advirtiendo a mis clientes: la resiliencia en 2025 implica distribuir cargas de trabajo críticas entre múltiples proveedores de nube. No porque un solo proveedor sea poco fiable, sino porque ningún proveedor es inmune a las interrupciones.

Una estrategia multicloud bien diseñada le ofrece:

• Resiliencia ante interrupciones: Cuando AWS US-EAST-1 falla, su conmutación por error a GCP europe-west2 mantiene las operaciones en marcha. Sus clientes no saben (ni les importa) en qué nube se encuentra; solo saben que su servicio funciona.

• Servicios de primera clase: Ejecute sus cargas de trabajo de entrenamiento de IA en las TPU de Google y Vertex AI, aproveche Google Workspace para mejorar la productividad y la continuidad del negocio, y utilice su proveedor de nube actual para cargas de trabajo heredadas específicas que sea conveniente mantener. ¿Por qué limitarse a la interpretación de las «mejores prácticas» de un solo proveedor cuando puede seleccionar las mejores soluciones?

• Optimización de costos: La multinube no se trata solo de resiliencia, sino también de apalancamiento. Cuando se pueden mover cargas de trabajo entre proveedores, se pueden negociar mejores precios. Y con el aumento vertiginoso de los costos de la infraestructura de IA, ese poder de negociación vale su peso en oro.

• Cumplimiento normativo: Cada proveedor tiene su propia red de centros de datos regionales. La multinube le ofrece la flexibilidad de cumplir con los requisitos de soberanía de datos en diferentes jurisdicciones sin necesidad de grandes modificaciones arquitectónicas.

El ángulo de Google Workspace que nadie considera

Esto es algo que la mayoría de las organizaciones pasan por alto: si usa Microsoft 365 y AWS, no tiene conmutación por error para su capa de productividad.

He visto cómo esto se desarrolla en tiempo real. Un cliente que operaba completamente con Microsoft 365 sufrió una interrupción de Azure Active Directory. El correo electrónico desapareció. Teams desapareció. SharePoint desapareció. Todas las herramientas de colaboración de las que dependía su empresa, sin conexión simultáneamente.

Google Workspace como solución de continuidad empresarial es una estrategia infrautilizada. Incluso si Google Workspace no es su suite de productividad principal, tenerlo como un entorno de conmutación por error inactivo significa:

• Acceso preconfigurado para personal crítico durante una interrupción de Microsoft 365
• Datos esenciales sincronizados que pueden activarse durante una crisis
• Canales de comunicación que permanecen operativos cuando fallan sus herramientas principales
• Chromebooks configurados con seguridad equilibrada que pueden distribuirse a equipos clave

Ayudamos a nuestros clientes a implementar esto como parte de una planificación integral de la continuidad del negocio. No se trata de reemplazar a Microsoft, sino de tener un plan B que realmente funcione cuando todo lo demás falla. Como vCISO, he visto a demasiadas organizaciones descubrir durante una crisis que su «plan de recuperación ante desastres» era solo una ilusión.

Construyendo cimientos que perduren

¿Cómo se ve realmente una base sólida en la nube en 2025? Basándome en los cientos de arquitecturas que he revisado y reconstruido como parte de nuestro equipo de vCISO, esto es lo que requiere una infraestructura resiliente:

1. Diseño multiregión y multinube

No como una idea de último momento. Su arquitectura debe asumir que los fallos del proveedor ocurrirán y diseñarlos en función de ellos desde el principio. Esto incluye estrategias de conmutación por error de DNS que no dependan de la infraestructura de DNS de su proveedor principal de nube.

2. Infraestructura como código con recuperación ante desastres integrada

Si no puede reconstruir toda su infraestructura en otra región u otra nube en cuestión de horas, su IaC no está lo suficientemente madura. Ayudamos a nuestros clientes a implementar configuraciones de Terraform que son completamente independientes de la nube, con políticas de enrutamiento DNS que conmutan automáticamente por error a endpoints en buen estado..

3. Estrategia de soberanía y replicación de datos

¿Dónde están sus datos? ¿Con qué frecuencia se replican? ¿Puede acceder a ellos si su nube principal deja de funcionar? Estas no son preguntas teóricas; son las que se plantean los ejecutivos durante una interrupción del servicio, cuando ya es demasiado tarde para implementar soluciones.

4. Monitoreo y conmutación por error automatizados

Los procedimientos manuales de conmutación por error fallan. La gente entra en pánico durante las crisis. La monitorización automatizada del estado, que activa procedimientos de conmutación por error previamente probados (incluidas las actualizaciones de registros DNS), es el único enfoque que funciona a las 3:00 a. m., cuando AWS US-EAST-1 devuelve errores.

5. Pruebas periódicas de recuperación ante desastres

Insistimos en que nuestros clientes realicen simulacros trimestrales de recuperación ante desastres que incluyan escenarios de fallos de proveedores de nube y fallos de resolución de DNS. Porque la única manera de saber si su conmutación por error funciona es probándola en condiciones reales.

La verificación de la realidad de la infraestructura de IA

Permítanme volver al tema de la IA porque es ahí donde estamos viendo las decisiones de infraestructura más peligrosas en este momento.

La IA generativa es costosa. Los costos de entrenamiento, inferencia y tokens se acumulan rápidamente. Y cuando las organizaciones se apresuran a implementar la IA sin una infraestructura adecuada, terminan con:

• Vulnerabilidades de seguridad: modelos de IA que acceden a datos a los que no deberían, sin una capa de gobernanza adecuada
• Pesadillas de cumplimiento: datos de entrenamiento que cruzan límites jurisdiccionales y violan los requisitos de soberanía de datos
• Sobrecostos: canales de inferencia ineficientes que agotan los presupuestos a un ritmo exorbitante
• Fallas de confiabilidad: servicios de IA que se apagan durante las interrupciones del proveedor, destruyendo la confianza del usuario.o dark during provider outages, destroying user trust

La ventaja de la infraestructura de IA de Google Cloud no solo tiene que ver con el rendimiento, sino también con brindar la gobernanza, la seguridad y los controles de costos que las implementaciones de IA de producción realmente necesitan.

Cuando ayudamos a los clientes a implementar IA generativa en GCP, implementamos:

• Controles de residencia de datos que mantienen los datos confidenciales dentro de límites geográficos específicos
• Control de versiones y gobernanza de modelos a través de Vertex AI Model Registry
• Monitoreo de costos y alertas presupuestarias que previenen costos de inferencia descontrolados
• Controles de seguridad que garantizan que los modelos de IA solo puedan acceder a datos con los permisos adecuados
• Patrones de implementación multirregionales que sobreviven a interrupciones regionales
• Estrategias de resiliencia de DNS que garantizan que los servicios de IA permanezcan accesibles incluso durante fallas de DNS del proveedor

Este es el trabajo fundamental que no aparece en los titulares, pero que determina si su iniciativa de IA tendrá éxito o se convertirá en una advertencia.

Lo que aportamos

Como Arquitecto Principal de la Nube en nuestro equipo de vCISO, mi perspectiva es diferente a la de las consultorías de nube tradicionales. No solo optimizo el rendimiento o el coste, sino que diseño pensando en el riesgo.

Cuando revisamos la infraestructura de un cliente, nos preguntamos:

• ¿Qué sucede cuando falla su proveedor principal de nube?
• ¿Puede demostrar el cumplimiento normativo durante una auditoría cuando su infraestructura de registro está desconectada?
• ¿Cómo mantiene las operaciones comerciales cuando su proveedor de identidad es inaccesible?
• ¿Cuáles son su RTO (Objetivo de Tiempo de Recuperación) y RPO (Objetivo de Punto de Recuperación)? ¿Puede su arquitectura realmente alcanzarlos?
• ¿Dispone de estrategias de conmutación por error de DNS que no dependan de su proveedor principal??

Estas son preguntas de nivel vCISO porque la resiliencia de la nube es fundamentalmente un desafío de seguridad y gestión de riesgos.

La interrupción de AWS de ayer afectó directamente al dominio de vCISO porque afectó a:

• Gestión de riesgos de proveedores externos: ¿su proveedor de nube es un punto único de falla?
• Planificación de la continuidad del negocio: ¿Puede su organización operar durante interrupciones prolongadas de la nube?
• Respuesta a incidentes: ¿Dispone de estrategias para escenarios de caídas críticas de proveedores?

Como parte de nuestro equipo de CISO, ayudo a las organizaciones a responder estas preguntas antes de la crisis, no a apresurarse a resolverlas durante una interrupción de 9 horas.

El camino a seguir

Si está ejecutando cargas de trabajo críticas en un solo proveedor de nube (ya sea AWS, Azure o incluso Google Cloud), debe preguntarse: ¿cuál es mi plan cuando (no si) experimentan una interrupción?

Si la respuesta es «esperar y confiar en que lo solucionen rápidamente», estás construyendo sobre arena.

Esto es lo que recomendamos:

1. Audite sus dependencias actuales en la nube para identificar puntos de fallo, en particular las dependencias de DNS.
2. Evalúe GCP como una capa de resiliencia, especialmente para cargas de trabajo de IA donde realmente destacan.
3. Implemente una arquitectura multicloud para servicios críticos para el negocio con conmutación por error automatizada y resiliencia de DNS.
4. Considere Google Workspace como una solución de continuidad empresarial junto con su suite de productividad actual.
5. Construya una infraestructura como código independiente de la nube y que pueda implementarse en múltiples proveedores.
6. Pruebe sus procedimientos de recuperación ante desastres con escenarios reales de fallos de proveedores de la nube, incluyendo fallos de resolución de DNS.

Las organizaciones que superaron la interrupción de AWS de ayer con un impacto mínimo no tuvieron suerte: estaban preparadas. Habían invertido en la arquitectura fundamental que consideraba la resiliencia de la nube una prioridad, no una consideración secundaria.

Construyamos algo sólido juntos

La revolución de la IA generativa es real y las oportunidades son extraordinarias. Pero si desarrolla capacidades de IA en una infraestructura que no puede sobrevivir a una interrupción del proveedor, se está preparando para el fracaso.

Nos especializamos en construir arquitecturas de nube que no solo funcionan, sino que perduran. Estrategias multicloud que equilibran las ventajas de la IA de Google Cloud con la resiliencia que ofrece una diversificación inteligente de proveedores. Integraciones con Google Workspace que proporcionan una auténtica continuidad del negocio. Infraestructura como código totalmente independiente de la nube. Controles de seguridad y cumplimiento normativo que resisten las interrupciones de los proveedores. Estrategias de resiliencia de DNS que garantizan la accesibilidad de sus servicios incluso cuando los principales proveedores experimentan fallos de DNS.

Porque al final del día, el modelo de IA más avanzado del mundo no sirve de nada si funciona en una infraestructura construida sobre arena.

Si la interrupción de ayer le hizo cuestionar su estrategia de resiliencia en la nube, hablemos. Como parte de nuestro equipo de vCISO, estamos aquí para ayudarle a construir bases duraderas.

Visite nuestro sitio web para conocer nuestro servicio gestionado de vCISO. ¿Quiere hablar sobre una colaboración con vCISO? ¡Contáctenos hoy mismo!

---

Conozca al autor: Maurice Manning. Como arquitecto principal de la nube en nuestro equipo de vCISO, trabajo con organizaciones para diseñar arquitecturas multicloud seguras y resilientes que respalden sus cargas de trabajo más críticas, incluyendo implementaciones de IA generativa. Si desea conversar sobre cómo Google Cloud Platform o Workspace podrían mejorar la resiliencia de su negocio e infraestructura, o explorar estrategias multicloud que proporcionen una verdadera continuidad del negocio, contacte con nuestro equipo.