Evert Daniel Romero Garrido
6.2 KiB
03 - Infraestructura AWS
Descripción detallada de cada recurso de AWS que usa
proyectosacc.
1. EC2 T3.small
La EC2 (Elastic Compute Cloud) es el servidor virtual donde corre la aplicación SACC.
Especificaciones
- Tipo de instancia:
t3.small - vCPU: 2
- RAM: 2 GB
- Sistema operativo: Ubuntu 22.04 LTS
- Disco raíz: 20 GB SSD (
gp3), con cifrado obligatorio
¿Qué hace?
- Ejecuta la API/backend de SACC como un servicio de
systemd(puerto8080). - Corre Nginx Proxy solo para redirigir las peticiones de la API hacia el backend.
- NO sirve el frontend React (eso lo hace S3 + CloudFront).
- Se conecta a la base de datos RDS para leer y guardar datos.
- Solo acepta conexiones SSH con llaves dedicadas: el pipeline y los administradores usan un par de llaves SSH generado específicamente para
proyectosacc. No se permite acceso con contraseña.
Dato importante
En Cómputo Contable Soft hay una regla obligatoria: todas las instancias EC2 deben ser de la familia T3. Esto garantiza el mejor balance entre costo y rendimiento.
2. RDS MariaDB
La RDS (Relational Database Service) es la base de datos gestionada por AWS.
Especificaciones
- Motor: MariaDB
- Tipo de instancia:
db.t3.micro - vCPU: 2
- RAM: 1 GB
- Uso: Base de datos de la aplicación SACC
¿Qué hace?
- Guarda todos los datos de la aplicación: usuarios, clientes, productos, facturas, etc.
- AWS se encarga de hacer respaldos automáticos, aplicar parches de seguridad y monitorear el rendimiento.
Ventaja principal
No tenemos que instalar ni mantener MariaDB nosotros mismos en el servidor. AWS lo hace por nosotros.
3. S3 Bucket
El S3 (Simple Storage Service) es el almacén de archivos de AWS.
¿Qué guardamos aquí?
- El frontend React compilado (
build/) como un sitio web estático. CloudFront lee estos archivos para servirlos a los usuarios. - Los archivos compilados (artefactos
.jar) de la API backend. - Versiones anteriores por si necesitamos hacer un rollback.
- Logs y respaldos temporales.
Ejemplo de rutas dentro del bucket
s3://ccsoft-proyectosacc-frontend/index.html
s3://ccsoft-artifacts-sacc4/develop/proyectosacc-app-1.0.0.jar
¿Por qué S3?
- Es muy económico.
- Es duradero (AWS garantiza que no se pierdan los archivos).
- El pipeline puede subir y descargar archivos fácilmente.
4. CloudFront
CloudFront es la red de distribución de contenido (CDN) de AWS.
¿Qué hace?
- Distribuye el frontend React desde el bucket S3 a los usuarios de todo el mundo.
- Reduce la latencia porque los archivos se sirven desde el "edge location" más cercano al usuario.
- Termina el cifrado SSL/TLS (HTTPS) usando el certificado de ACM.
- Se conecta a S3 mediante Origin Access Control (OAC) para que el bucket no sea público directamente.
Relación con S3 y la API
CloudFront lee los archivos estáticos (index.html, CSS, JS) desde S3. Además, tiene un behavior /api/* que redirige las peticiones de la API hacia la EC2. De esta forma, tanto el frontend como el backend comparten el mismo dominio https://sacc.ccsoft.mx, pero los usuarios nunca acceden directamente al bucket S3.
5. Route 53
Route 53 es el servicio de DNS de AWS.
Registro configurado
- Nombre:
sacc.ccsoft.mx - Tipo: A (Alias)
- Destino: CloudFront Distribution (no la IP de la EC2)
¿Qué hace?
Cuando un usuario escribe https://sacc.ccsoft.mx en su navegador, Route 53 le dice: "ve a CloudFront". Sin Route 53, los usuarios tendrían que escribir una URL larga de CloudFront.
6. ACM (AWS Certificate Manager)
ACM es el servicio que gestiona certificados SSL/TLS.
¿Qué es un certificado SSL?
Es un documento digital que permite que la conexión entre el usuario y el servidor esté cifrada. Se ve como el candadito verde 🔒 al lado de la dirección web.
¿Cómo lo usamos?
- Solicitamos un certificado en ACM para el dominio
sacc.ccsoft.mx. - ACM valida que el dominio nos pertenece.
- El certificado se adjunta a la distribución de CloudFront.
- Los usuarios acceden por HTTPS de forma segura. El certificado ya no vive en Nginx de la EC2.
7. Security Groups
Un Security Group es como un "guardia de seguridad" virtual que controla quién puede entrar y salir de la EC2.
Reglas de entrada (inbound)
| Puerto | Origen | ¿Para qué? |
|---|---|---|
22 |
IP del pipeline / VPN | Conexión SSH para despliegues de la API |
80 |
0.0.0.0/0 (todo internet) |
Tráfico HTTP hacia la API (puede redirigir a HTTPS) |
443 |
0.0.0.0/0 (todo internet) |
Tráfico HTTPS hacia la API |
8080 |
IPs de la VPC / CloudFront | Acceso directo a la API backend |
💡 Nota: los puertos
80y443en la EC2 ya no sirven el frontend React. Solo reciben peticiones a la API. El frontend se sirve desde CloudFront.
Reglas de salida (outbound)
| Puerto | Destino | ¿Para qué? |
|---|---|---|
Todo (0-65535) |
0.0.0.0/0 |
La EC2 puede salir a internet (descargar paquetes, consultar APIs, etc.) |
Regla de seguridad importante
El puerto 22 (SSH) solo debe abrirse desde IPs confiables. Nunca dejarlo abierto a todo el mundo (0.0.0.0/0).
8. Nginx Proxy en la EC2
Nginx es un servidor web que en este proyecto actúa como proxy inverso exclusivo para la API.
¿Qué hace Nginx?
- Escucha en los puertos
80y/o443. - Recibe las peticiones dirigidas a la API (por ejemplo,
sacc.ccsoft.mx/api). - Redirige el tráfico al backend que corre en el puerto interno
8080. - NO sirve archivos estáticos del frontend React (eso es trabajo de S3 + CloudFront).
Ejemplo mental simple
Navegador/app ──▶ Nginx (443) ──▶ API SACC (8080)
¿Por qué Nginx y no Apache?
En proyectosacc se decidió usar Nginx porque:
- Consume menos memoria RAM.
- Es más rápido manejando muchas conexiones simultáneas.
- La configuración de proxy inverso es más sencilla.
Anterior: 02-arquitectura-general.md
Siguiente: 04-usuarios-y-permisos.md