Aplicación de patrones WAF a arquitecturas reales

Aplicar patrones del WAF a arquitecturas reales no es un ejercicio teórico: requiere evaluar cada decisión de diseño según los cinco pilares y realizar concesiones fundamentadas. Un punto de partida habitual es el diagrama de arquitectura: siga el recorrido de una solicitud de usuario por cada componente y pregúntese, en cada salto, qué ocurre si falla ese componente, cuánto cuesta y cómo está protegido.

Considere una aplicación web monolítica tradicional: una sola máquina virtual que ejecuta conjuntamente un servidor web y una base de datos, detrás de una IP pública. Según los pilares del WAF, obtiene una puntuación baja en los cinco: sin redundancia (fiabilidad), la base de datos en el mismo host que la capa web (seguridad), una máquina virtual siempre activa independientemente del tráfico (costes), sin CI/CD (excelencia operativa) y solo escalado vertical (eficiencia del rendimiento).

Para abordar el pilar de Confiabilidad, distribuya la capa web entre varias VM en diferentes zonas de disponibilidad, respalde la base de datos con replicación geográfica en una región secundaria y coloque un Azure Load Balancer al frente. Esto elimina el punto único de fallo y permite que la aplicación sobreviva a una interrupción zonal o regional sin intervención manual.

Para el pilar de Seguridad, separe la capa web y la base de datos en subredes diferentes, con reglas de NSG que solo permitan a la capa web conectarse al puerto de la base de datos. Almacene la cadena de conexión de la base de datos en Azure Key Vault y use una identidad administrada en la aplicación web para recuperarla en tiempo de ejecución, eliminando así las credenciales codificadas directamente del código de la aplicación y de los archivos de configuración.

Para la Optimización de costes, sustituya las VM que están siempre activas por un Virtual Machine Scale Set que reduzca su tamaño durante las horas de menor demanda. Para la base de datos, evalúe si un servicio PaaS administrado como Azure SQL Database, con un nivel de DTU adecuado, cuesta menos que una VM completa con SQL Server. Adquiera Reserved Instances para cualquier capacidad base que pueda predecir con 12 meses de antelación.

Mejore la Excelencia operativa definiendo toda la infraestructura como plantillas de Bicep o ARM almacenadas en el control de versiones. Cree una canalización de CI/CD en Azure Pipelines o GitHub Actions que implemente automáticamente los cambios de infraestructura y el código de la aplicación. Añada puertas de implementación —pruebas de humo automatizadas y aprobación manual— antes de que los cambios lleguen a producción.

Para la Eficiencia del rendimiento, introduzca Azure Cache for Redis delante de la base de datos para almacenar en caché las consultas más frecuentes y reducir la carga de la base de datos. Implemente los recursos estáticos (imágenes, CSS y JavaScript) mediante Azure CDN para servirlos desde nodos perimetrales cercanos a los usuarios de todo el mundo. Realice pruebas de carga de la aplicación después de cada cambio para confirmar que las mejoras son cuantificables.

Todo cambio arquitectónico implica una concesión. Por ejemplo, pasar a una arquitectura multizona mejora la confiabilidad, pero aumenta los costes (dos zonas = dos VM). Añadir el almacenamiento en caché de Redis mejora el rendimiento, pero añade complejidad operativa (otro servicio que supervisar y mantener). Una buena documentación de arquitectura registra estas concesiones explícitamente para que los futuros arquitectos entiendan por qué se tomaron las decisiones.

Evite intentar alcanzar la perfección en un solo rediseño: ese enfoque es costoso, arriesgado y lento. En su lugar, adopte un ciclo de mejora iterativa: realice una revisión de Well-Architected, identifique los tres problemas de mayor impacto, corríjalos, mida la mejora y repita el proceso. Este enfoque alinea las mejoras arquitectónicas con la entrega ágil y hace visible el progreso para las partes interesadas en cada sprint.

Microsoft publica arquitecturas de referencia para patrones de cargas de trabajo comunes en el Azure Architecture Center. Estas incluyen arquitecturas de aplicaciones web, microservicios en AKS, canalizaciones de análisis de datos y muchas más. Cada arquitectura de referencia ya se ha evaluado según los pilares de WAF e incluye notas sobre las concesiones realizadas para ese patrón específico.

Use Architecture Decision Records (ADRs) para documentar las decisiones arquitectónicas importantes, el contexto en el que se tomaron, las alternativas consideradas y sus implicaciones para los pilares de WAF. Los ADR almacenados en el control de versiones junto con el código crean un historial auditable que ayuda a los nuevos miembros del equipo a entender por qué la arquitectura tiene su aspecto actual.

Compruebe su comprensión de los conceptos de Microsoft Azure Fundamentals (AZ-900) de esta lección.

En esta lección ha aprendido que los patrones de WAF se aplican evaluando cada decisión arquitectónica según los cinco pilares; las mejoras pueden realizarse de forma iterativa empezando por los problemas de mayor impacto; y las concesiones deben documentarse para que los futuros arquitectos entiendan el razonamiento. A continuación exploraremos los SLA de Azure y cómo calcular SLA compuestos para arquitecturas con varios servicios.