Cuando aprendemos AWS, solemos estudiar los servicios por separado:
EC2, RDS, S3, VPC…
Pero la verdadera ingeniería comienza cuando entendemos cómo se conectan entre sí para formar una arquitectura escalable, segura y lista para producción.
En este artículo explico una arquitectura moderna para aplicaciones web basada en buenas prácticas.
Objetivo de la arquitectura
Diseñar una infraestructura que sea:
- Altamente disponible
- Escalable
- Segura
- Optimizada en costos
- Preparada para producción
Punto de Entrada: Route 53 + CloudFront
Cuando un usuario escribe el dominio en su navegador, el flujo correcto es:
- Route 53 resuelve el dominio.
- El dominio apunta a CloudFront.
- CloudFront verifica si el contenido está cacheado en una Edge Location cercana.
- Si está cacheado, lo entrega inmediatamente.
- Si no está cacheado, consulta al origin.
Nota: No todo el tráfico entra a la VPC. CloudFront actúa como primera capa de optimización y protección.
Contenido Estático: S3 como Origin
Para contenido estático como:
- HTML
- CSS
- JavaScript
- Imágenes
- Assets del frontend
CloudFront usa Amazon S3 como origin.
Esto permite:
- Baja latencia global
- Reducción de carga en backend
- Menor costo operativo
- Mejor experiencia de usuario
Nota: En muchos casos, el frontend completo puede servirse desde S3 + CloudFront sin tocar la VPC.
Contenido Dinámico: ALB como Origin
Cuando la petición requiere lógica de negocio (API, autenticación, base de datos):
CloudFront redirige la solicitud hacia el Application Load Balancer (ALB).
Flujo dinámico:
Usuario → Route 53 → CloudFront → ALB → EC2 → RDS
Aquí recién entramos a la VPC.
VPC: Nuestra Red Privada
La VPC define:
- Rango de IPs
- Subnets públicas
- Subnets privadas
- Tablas de ruteo
- Gateways
Nota: Es el entorno aislado donde vive nuestra aplicación.
Subnets Públicas
En las subnets públicas normalmente encontramos:
- Application Load Balancer
- NAT Gateway
- Internet Gateway (a nivel VPC)
Nota: El ALB recibe tráfico desde CloudFront. No desde usuarios directamente.
Subnets Privadas (Capa de Aplicación)
Aquí viven las instancias:
- EC2 con nuestro backend
- Auto Scaling Group (recomendado)
Características:
- No tienen IP pública.
- Solo reciben tráfico desde el ALB.
- Pueden salir a Internet mediante NAT Gateway.
Nota: Esto reduce significativamente la superficie de ataque.
Subnets Privadas (Capa de Datos)
La base de datos (Amazon RDS) se ubica en subnets privadas separadas.
Buenas prácticas aplicadas:
- Multi-AZ para alta disponibilidad
- Sin acceso público
- Security Groups restringidos
- Backups automáticos
Nota: Separar aplicación y datos mejora seguridad y organización.
NAT Gateway
Las instancias en subnets privadas pueden necesitar acceso externo para:
- Descargar dependencias
- Consumir APIs externas
- Actualizaciones
Nota: El NAT Gateway permite salida controlada a Internet sin exponer las instancias.
Seguridad por Capas
Esta arquitectura aplica principios clave:
- CDN como primera barrera
- Separación por capas
- Principio de mínimo privilegio
- Base de datos no expuesta
- Instancias privadas
- Balanceo multi-AZ
Nota: La seguridad no es un componente. Es un diseño.
Escalabilidad
La arquitectura permite crecer fácilmente:
- Auto Scaling en EC2
- Read replicas en RDS
- Cacheo en CloudFront
- Separación frontend/backend
- Migración futura a contenedores (ECS/EKS)
Optimización de Costos
CloudFront reduce tráfico al backend.
S3 es más barato que servir estáticos desde EC2.
Auto Scaling evita sobreaprovisionamiento.
Arquitectura moderna no es solo técnica. También es financiera.
¿Por qué esta es una buena base?
Porque:
- Desacopla estático de dinámico
- Reduce latencia global
- Aumenta seguridad
- Aplica buenas prácticas reales
- Te obliga a entender networking, disponibilidad y diseño
Conclusión
Entender cómo diseñar un sistema completo, pensando en rendimiento, seguridad y escalabilidad desde el inicio.
La diferencia entre saber usar servicios y saber diseñar arquitectura es lo que realmente eleva tu carrera como ingeniero.
Feliz codeo gente!
@eduuu.dev
Top comments (0)