Arquitectura y Seguridad en la Nube: el próximo nivel del desarrollador

Cuando una aplicación web funciona en local, parece que ya esta casi terminada. Pero en realidad todavía queda una parte muy importante: decidir donde va a vivir, como se va a proteger y que pasara si de repente la usan muchas personas a la vez.

En este articulo voy a explicar, desde el punto de vista de un desarrollador Full-Stack, como llevar una aplicación web al entorno cloud de forma segura. La idea de esta guía es entender los conceptos que permiten tomar buenas decisiones técnicas a la hora de subir nuestra aplicación a la nube.

Imagen de portada: Adi Goldstein en Unsplash.

1. Donde vive mi código: PaaS y modelos de servicio

En cloud hay varias formas de ejecutar una aplicación. Una de las mas importantes para desarrollo web es PaaS, que significa Platform as a Service o Plataforma como Servicio.

Con PaaS, el proveedor cloud se encarga de gran parte de la infraestructura: servidores, sistema operativo, parches, red, escalado y despliegue, mientras que el equipo de desarrollo se centra mas en el código, las variables de entorno, la seguridad de la aplicación y la experiencia del usuario.

Para una aplicación web moderna, PaaS suele ser una opción muy cómoda porque permite desplegar sin tener que administrar maquinas virtuales manualmente.

AWS App Runner

AWS App Runner permite desplegar una aplicación desde código fuente o desde una imagen de contenedor y convertirla en una aplicación web escalable y segura en AWS. Es una opción pensada para reducir la cantidad de infraestructura que el desarrollador tiene que configurar.

En un escenario real, podría usar App Runner si tengo una API o una aplicación web empaquetada en contenedor y quiero que AWS gestione despliegue, escalado y operaciones básicas.

Azure App Service

Azure App Service es la opción PaaS de Microsoft Azure para ejecutar aplicaciones web, APIs REST y backends móviles sin gestionar directamente la infraestructura.

Una ventaja importante de Azure App Service es que se integra muy bien con el ecosistema Microsoft: GitHub Actions, Azure DevOps, certificados gestionados y escalado.

Google Cloud Run

Google Cloud Run es una plataforma gestionada para ejecutar código, funciones o contenedores sobre la infraestructura escalable de Google. Es muy interesante porque permite ejecutar aplicaciones en contenedores sin administrar clusters.

Cloud Run puede escalar automáticamente según el trafico e incluso escalar a cero cuando no hay peticiones. Esto ayuda a ahorrar costes en aplicaciones con trafico irregular.

2. Seguridad en Cloud: el escudo de la aplicación

Subir una aplicación a la nube no significa que automáticamente sea segura. El cloud da herramientas, pero es el desarrollador quien tiene que usarlas bien.

La primera idea clave es el principio de mínimo privilegio: cada usuario, servicio o proceso debe tener solo los permisos que necesita.

En AWS se usa IAM para gestionar usuarios, roles, políticas y permisos. En Azure, el servicio de identidad principal es Microsoft Entra ID, antes llamado Azure Active Directory. En Google Cloud se usa Cloud IAM. Aunque cada proveedor tiene sus nombres, la idea es similar: controlar quien puede hacer que, sobre que recurso y en que condiciones.

Variables de entorno

Uno de los errores mas comunes es dejar una contraseña o token dentro del repositorio. Por ejemplo:

const password = "Pwd123";

Esto es peligroso porque si el repositorio se hace publico, esa credencial queda expuesta. La practica correcta es usar variables de entorno:

const password = process.env.DB_PASSWORD;

Y el archivo .env debe estar dentro de .gitignore:

.env

En producción, esas variables se configuran desde el panel de Vercel, Netlify, Azure, AWS o Google Cloud, no dentro del código.

Soberanía de datos

La soberanía de datos significa saber donde se almacenan los datos y que leyes se aplican sobre ellos. No es lo mismo guardar información de usuarios europeos en una región europea que en otra zona con normas diferentes.

Para una aplicación real, especialmente si maneja datos personales, hay que hacerse preguntas como:

• ¿En que región se almacenan los datos?
• ¿Hay copias de seguridad en otras regiones?
• ¿Quien tiene acceso administrativo?
• ¿Se cumplen normas como RGPD si los usuarios son de la Unión Europea?

3. Escalabilidad y disponibilidad: que pasa si mi web se vuelve viral

Imaginemos que publicamos una web de venta de entradas. Al principio entran 20 personas y todo va bien, pero de repente un influencer comparte el enlace y entran miles de usuarios en pocos minutos.

En un servidor mal preparado, podrían pasar varias cosas:

• La CPU se satura.
• La memoria se agota.
• La base de datos recibe demasiadas conexiones.
• La web carga muy lento.
• El servidor deja de responder.

La escalabilidad intenta evitar esto. En cloud, muchos servicios pueden crear más instancias automáticamente cuando aumenta el tráfico. Eso se llama autoescalado.

Hay dos formas de verlo:

• Escalado vertical: hacer mas potente una máquina, por ejemplo más CPU o RAM.
• Escalado horizontal: crear más instancias de la aplicación y repartir el tráfico entre ellas.

Para aplicaciones modernas, el escalado horizontal suele ser muy importante. Si una instancia no puede con todo, se levantan mas instancias y un balanceador reparte las peticiones.

La disponibilidad, por otro lado, significa que la aplicación siga funcionando aunque haya fallos. Para mejorarla se usan ideas como:

• Desplegar en varias zonas.
• Usar balanceadores de carga.
• Tener backups.
• Separar frontend, backend y base de datos.
• Monitorizar errores y tiempos de respuesta.

4. Comparación rápida: AWS, Azure y Google Cloud

La mejor plataforma no existe sino que depende del equipo, el presupuesto, los conocimientos previos, la región de datos y el tipo de aplicación.

Para empezar, Vercel o Netlify son opciones muy prácticas. Para una API o backend mas completo, Azure App Service o Google Cloud Run pueden ser alternativas muy buenas.

5. Actividad práctica: El Desafío del Viral

Situación

Has lanzado una web de venta de entradas y un influencer la acaba de compartir. Tienes 5 minutos para que la web sea escalable y no muera por el trafico.

Objetivo

Desplegar una web estática en una plataforma cloud moderna y comprobar que usa buenas practicas básicas de seguridad.

Paso 1: sube el código a GitHub o GitLab

Crea un repositorio con tu web. Puede ser una pagina HTML/CSS/JS sencilla o una aplicación hecha con React, Angular, Vue o Astro.

Antes de subirlo, revisa que no haya datos sensibles:

.env
node_modules/
dist/

El archivo .env debe estar ignorado por Git.

Paso 2: conéctalo a Vercel, Netlify, AWS Amplify o Azure Static Web Apps

Para una web estática, Vercel y Netlify son muy directos:

1. Inicia sesión.
2. Importa el repositorio.
3. Elige el framework si lo detecta automáticamente.
4. Pulsa deploy.

La plataforma construirá la web y la publicara en una URL HTTPS.

Paso 3: configura una variable de entorno

Aunque una web estática no debería exponer secretos privados en el navegador, este paso sirve para practicar una buena costumbre.

Ejemplo:

PUBLIC_SITE_NAME=Entradas Cloud

Si fuera una aplicación con backend, una contraseña de base de datos nunca debería estar escrita en el código ni visible en el frontend. Debe configurarse como secreto o variable de entorno en el proveedor de despliegue.

Paso 4: comprueba el certificado SSL

Abre la URL desplegada y revisa que empiece por:

https://

También debe aparecer el candado en el navegador. Esto indica que la comunicación viaja cifrada mediante TLS.

Resultado esperado

Al terminar la práctica, deberías tener:

• Un repositorio publico sin secretos.
• Una web publicada en una plataforma cloud.
• HTTPS activo.
• Variables de entorno configuradas correctamente.

6. Test de autoevaluación

A continuación tenemos un test de 10 preguntas en Kahoot para comprobar si se han entendido los conceptos principales.

Enlace al test: Kahoot - Arquitectura y Seguridad en la Nube

Fuentes consultadas

• AWS App Runner Documentation
• Azure App Service overview
• Google Cloud Run documentation
• AWS IAM documentation