Hay una fase en la vida de cada startup llamada “ClickOps”. Inicia sesión en la consola de AWS. Buscas EC2. Hace clic en “Iniciar instancia”. Llámelo “servidor-heredado-no-tocar”. Funciona. Se siente productivo. Dos años después, ese servidor colapsa. El ingeniero que lo construyó se fue. Nadie sabe qué versión del sistema operativo estaba ejecutando. Nadie sabe qué grupos de seguridad estaban abiertos. Nadie sabe dónde están las claves SSH. El negocio está fuera de línea.

En Maison Code Paris aplicamos una regla estricta: La infraestructura es el código. Si no está en Terraform (o Pulumi/CDK), no existe. Esta guía es una inmersión profunda en la creación de una infraestructura de AWS de nivel de producción que sea resistente, segura y no lo lleve a la quiebra.

Por qué Maison Code habla de esto

En Maison Code Paris, actuamos como la conciencia arquitectónica de nuestros clientes. A menudo heredamos stacks “modernos” construidos sin una comprensión fundamental de la escala.

Discutimos este tema porque representa un punto de inflexión crítico en la madurez de la ingeniería. Implementarlo correctamente diferencia un MVP frágil de una plataforma resistente de nivel empresarial.

Por qué Maison Code habla de infraestructura

Gestionamos infraestructura para marcas que no pueden fallar. Cuando un cliente inicia una colaboración con una superestrella mundial, el tráfico aumenta 100 veces en 60 segundos. Si el equilibrador de carga no se calienta, si la base de datos no es escalable, el sitio falla. Diseñamos para Elasticidad. Utilizamos AWS no como un “host de servidor” sino como una “utilidad programable”. Ayudamos a los CTO a migrar de frágiles “servidores para mascotas” a resistentes “flotas de ganado”.

1. La filosofía central: infraestructura como código (IaC)

¿Por qué escribimos infraestructura en HCL (lenguaje de configuración HashiCorp)?

Reproducibilidad: Puede crear un entorno de “Prueba” que sea un clon exacto de “Producción” en 10 minutos.
Auditabilidad: git listening te dice exactamente quién abrió el Puerto 22 al público y cuándo.
Recuperación ante desastres: si us-east-1 deja de funcionar, cambia una variable region = "eu-west-1" y vuelve a implementarla.

La pila Terraform

No gestionamos el estado localmente. Usamos un backend remoto (S3 + DynamoDB para bloqueo).

# principal.tf
terraformar {
  backend "s3" {
    cubo = "maisoncode-terraform-estado"
    clave = "prod/infraestructura.tfstate"
    región = "nosotros-este-1"
    dynamodb_table = "bloqueos de terraformación"
    cifrar = verdadero
  }
}

proveedor "aws" {
  región = "nosotros-este-1"
  etiquetas_predeterminadas {
    etiquetas = {
      Entorno = "Producción"
      Proyecto = "Comercio electrónico"
      Gestionado por = "Terraformar"
    }
  }
}

2. Redes: la trampa de VPC

El mayor error que cometen los desarrolladores es utilizar la “VPC predeterminada”. La VPC predeterminada coloca todo en subredes públicas. Tu base de datos tiene una IP pública. Esto es imprudente. Diseñamos redes de 3 niveles.

gráfico TD
    Usuario -->|HTTPS| ALB[Equilibrador de carga de aplicaciones]
    subgrafo VPC
        subgrafo Subred pública
            ALBA
            NAT[Puerta de enlace NAT]
        fin
        subgrafo Subred privada
            Aplicación[Servidor de aplicaciones/Lambda]
        fin
        subgrafo Subred de base de datos
            RDS[Postgres RDS]
        fin
    fin
    Aplicación -->|SQL| RDS
    Aplicación -->|Saliente| NAT

Nivel 1: Subred pública

Contiene: equilibradores de carga (ALB), puertas de enlace NAT y hosts bastión.
Enrutamiento: Tiene un Portal de Internet (IGW). 0.0.0.0/0 -> IGW.

Nivel 2: subred privada (capa de aplicación)

Contiene: instancias EC2, contenedores Fargate, ENI Lambda.
Enrutamiento: Sin puerta de enlace a Internet. 0.0.0.0/0 -> NAT Gateway (para actualizaciones salientes).
Seguridad: No se puede acceder directamente desde Internet.

Nivel 3: Subred interna (capa de datos)

Contiene: RDS, ElastiCache, Redshift.
Enrutamiento: No hay ningún acceso a Internet. Sin NAT.
Seguridad: Aislamiento total.

3. La sorpresa de la puerta de enlace NAT de 20.000 dólares

El precio del ancho de banda de AWS es predatorio. Una puerta de enlace NAT te cobra por hora + por GB procesado. Si su aplicación descarga 10 TB de imágenes de S3 y el tráfico estándar de S3 pasa por la puerta de enlace NAT, usted paga ~€450. Solución: Puntos finales de puerta de enlace S3. Este es un “agujero de gusano” virtual desde su VPC a S3 que pasa por alto la NAT. Es Gratis.

recurso "aws_vpc_endpoint" "s3" {
  vpc_id = aws_vpc.main.id
  nombre_servicio = "com.amazonaws.us-east-1.s3"
}

Aprovisione siempre puntos de enlace de puerta de enlace para S3 y DynamoDB.

4. Cálculo: EC2 frente a Fargate frente a Lambda

¿Qué motor informático se adapta al comercio electrónico de lujo?

EC2 (Máquinas virtuales)

Caso de uso: aplicaciones heredadas, servicios con estado (WebSockets), bases de datos (si son autohospedadas).
Veredicto del Código Maison: Evítelo. Demasiado mantenimiento (parches del sistema operativo).

ECS Fargate (contenedores sin servidor)

Caso de uso: aplicaciones Node.js/Docker de larga ejecución.
Pros: No hay parches para el sistema operativo. Usted define “CPU: 2, RAM: 4 GB”. AWS lo ejecuta.
Veredicto del código de Maison: Elección estándar para servidores Next.js que envían HTML.

Lambda (Funciones)

Caso de uso: Tareas basadas en eventos (cambio de tamaño de imágenes, procesamiento de pedidos).
Pros: Escala a cero.
Veredicto del Código de Maison: Excelente por “Glue Code” y trabajadores de fondo.

5. La base de datos: RDS Aurora Serverless v2

El RDS tradicional requiere que elijas un tamaño de instancia (db.m5.large). Si el tráfico aumenta, te estrellarás. Si el tráfico disminuye, paga de más. Aurora Serverless v2 aumenta y reduce la capacidad informática localmente en milisegundos. Es la combinación perfecta para el modelo de lanzamientos de lujo “Flash Sale”.

recurso "aws_rds_cluster" "predeterminado" {
  cluster_identifier = "aurora-cluster-demo"
  motor = "aurora-postgresql"
  motor_mode = "aprovisionado"
  serverlessv2_scaling_configuration {
    capacidad_min = 0,5 # $40/mes
    max_capacity = 64.0 # Carga pesada
  }
}

Cuando finaliza la caída, se reduce a 0,5 ACU (Unidades de capacidad Aurora). Pagas por lo que usas.

6. Entrega de contenido: CloudFront

No puede entregar activos desde S3 directamente a los usuarios. S3 es lento (tiempo hasta el primer byte). CloudFront es obligatorio. Es una CDN global. Configuración crítica: Políticas de caché. No guardes todo en caché.

Imágenes: Caché durante 1 año.
Respuestas de API: caché durante 0 segundos (o 60 segundos si es público).
HTML: caché durante 0 segundos (representado en el lado del servidor).

Seguridad: utilice OAC (control de acceso de Origin) para bloquear su depósito S3 para que solo CloudFront pueda leerlo. Los usuarios no pueden omitir la CDN.

7. El marco bien diseñado (6 pilares)

AWS proporciona una lista de verificación denominada “Marco de buena arquitectura”. Auditamos a cada cliente contra esto.

Excelencia operativa: Automatiza todo. Sin cambios manuales.
Seguridad: cifra todo. Mínimo privilegio.
Confiabilidad: implementaciones Multi-AZ. Sistemas de autocuración.
Eficiencia de rendimiento: utilice Serverless/Spot para escalar el contenido.
Optimización de costos: analiza las facturas diariamente. Etiqueta cada recurso.
Sostenibilidad: Utilice procesadores Graviton (ARM). Utilizan un 60% menos de energía.

8. Recuperación ante desastres: RTO frente a RPO

Si AWS us-east-1 se incendia, ¿qué pasa? Defines 2 métricas:

RTO (objetivo de tiempo de recuperación): ¿Cuánto tiempo tardará en volver a estar en línea? (Objetivo: < 1 hora).
RPO (Objetivo de punto de recuperación): ¿Cuántos datos podemos perder? (Objetivo: < 5 minutos). Estrategia:
Base de datos: réplicas de lectura entre regiones (EE. UU. -> UE). La promoción dura 5 minutos.
Archivos: Replicación entre regiones (CRR) de S3.
Código: Aplicación Terraform multiregión.

9. Seguridad: El principio del mínimo privilegio

IAM (Identity Access Management) es el firewall para los humanos. Nunca use la cuenta raíz. Guárdelo en una caja fuerte. Nunca proporcione AdministratorAccess a un desarrollador.

Cree políticas detalladas estrictamente centradas en los recursos.

{
    "Efecto": "Permitir",
    "Acción": ["s3:PutObject"],
    "Recurso": "arn:aws:s3:::maisoncode-uploads/images/*"
}

Este usuario puede subir imágenes. No pueden eliminar el depósito. No pueden leer los informes financieros.

8. Optimización de costos: instancias puntuales

Para el procesamiento de datos por lotes (por ejemplo, trabajos de optimización de imágenes que se ejecutan por la noche), no utilice instancias bajo demanda. Utilice instancias puntuales. Se trata de capacidad sobrante de AWS que se vende con un descuento del 70 al 90 %. El problema: AWS puede cancelarlos con una advertencia de 2 minutos. Si su aplicación no tiene estado (como un trabajador de cola), esto no importa. Maneja la terminación y se reinicia en otro lugar. Esto ahorra miles de dólares al mes en trabajos en segundo plano.

9. Flujo de trabajo de desarrollo: entornos efímeros

¿Cómo se prueban los cambios de infraestructura? Usamos “Efímeros”. Cuando se abre un PR en GitHub:

Las acciones de GitHub activan Terraform.
Crea un nuevo Espacio de Trabajo pr-123.
Implementa una pila completa (VPC + Fargate + RDS).
Ejecuta pruebas E2E.
Ejecuta “terraform destroy”.

Esto brinda total confianza de que los cambios de código no interrumpirán la producción.

10. Conclusión

AWS es una motosierra. Es lo suficientemente poderoso como para talar un bosque, pero lo suficientemente peligroso como para cortarte una pierna. Hacer clic en la consola es jugar con juguetes. Escribir Terraform es ingeniería. Para 2026, avanzamos hacia la “infraestructura a partir del código” (usando SST o Pulumi para inferir infraestructura a partir del código), pero los fundamentos de las VPC y la IAM siguen siendo inmutables.

¿Tu nube es un desastre?

¿Tiene “Servidores Desconocidos” ejecutándose? ¿Es su factura un misterio? Contrate a nuestros arquitectos.