Caso Técnico 03
Arquitectura de hosting estático low-cost para un negocio real
Cómo un negocio tradicional consiguió presencia online rápida, segura y mantenible usando arquitectura estática, S3, Cloudflare y Terraform.
- AWS S3
- Cloudflare
- Terraform
- Static Hosting
- Seguridad
Resumen
Un negocio tradicional necesitaba presencia online profesional: rápida, segura, fácil de mantener y casi sin costo operativo.
La respuesta no era un CMS pesado, un servidor, una base de datos o una plataforma con pagos mensuales. La arquitectura correcta era hosting estático: S3 como origen, Cloudflare para DNS, CDN y TLS, Terraform para infraestructura repetible y una ruta de origen restringida.
Contexto
Era una necesidad real de negocio, no un experimento de portfolio. El sitio tenía que servir para el trabajo de mi papá, así que la solución debía ser confiable sin crear carga operativa.
El componente humano importaba, pero el requisito técnico seguía siendo simple: resolver el problema real con el menor mantenimiento posible en el tiempo.
Problema Visible
El negocio necesitaba una web creíble, pero el riesgo era elegir una arquitectura que generara más trabajo que valor.
Opción 01
Website builder. Rápido para arrancar, pero atado a una plataforma y costo mensual.
Opción 02
Hosting tradicional. Conocido, pero innecesario para una presencia estática simple.
Opción 03
Arquitectura estática. Menos partes móviles, menor costo y confiabilidad más simple.
Arquitectura
La arquitectura mantiene el origen simple y mueve la entrega a Cloudflare. S3 almacena archivos estáticos, Cloudflare maneja DNS, CDN, TLS y cache, y Terraform deja los cambios de infraestructura explícitos.
Decisiones Clave
- Usar archivos estáticos porque el sitio no necesitaba server-side rendering ni base de datos.
- Usar S3 como origen low-cost para HTML, assets e imágenes optimizadas.
- Usar Cloudflare para DNS, CDN, TLS y comportamiento de cache.
- Usar Terraform para que la infraestructura pudiera revisarse y recrearse.
- Restringir acceso directo a S3 para que la ruta pública pase por Cloudflare.
Consideraciones de Seguridad
Una web chica no necesita seguridad compleja, pero sí límites correctos. Lo importante fue evitar un origen público sin control y mantener el proceso de deploy repetible.
Origen restringido
La bucket policy limita acceso directo y mantiene Cloudflare como entrada pública esperada.
Sin superficie runtime
Sin servidor, sin base de datos y sin panel admin significa menos piezas para parchear o monitorear.
Performance y Costo
Lighthouse
98/100 en la página medida.
LCP
1.4s con entrega estática optimizada.
Costo
Prácticamente cero usando bajo uso de S3 y plan free de Cloudflare.
Trade-offs
La arquitectura estática no siempre es la respuesta. Es la respuesta correcta cuando el contenido es principalmente informativo, las actualizaciones son controladas y el negocio no necesita comportamiento backend dinámico.
El trade-off es aceptar un flujo de contenido más simple a cambio de menor costo operativo, mejor performance y menos modos de falla.
Resultado
- Presencia online rápida y profesional para un negocio real.
- Casi nada de infraestructura runtime para operar.
- Deploy repetible con Terraform y AWS CLI.
- Ruta de entrega suficientemente segura para el perfil de riesgo real.
Lección Aprendida
La mejor arquitectura no es la más compleja. Es la que resuelve el problema correcto con el menor costo operativo.