Jonatan Matajonmatum.com
conceptosnotasexperimentosensayos
© 2026 Jonatan Mata. All rights reserved.v2.1.1
Experimentos

Módulos Terraform para AWS Serverless

Colección de 13 módulos Terraform publicados en el Terraform Registry para desplegar arquitecturas serverless en AWS, con 12 ejemplos que cubren desde ECS básico hasta CRUD full-stack con DynamoDB y AgentCore con MCP.

evergreen#terraform#aws#serverless#ecs#lambda#api-gateway#dynamodb#well-architected#fargate#mcp#cloudfront#waf#sqs#sns

¿Qué es?

Una colección de 13 módulos Terraform reutilizables para desplegar arquitecturas serverless en AWS. Publicados en el Terraform Registry y disponibles como open source en GitHub.

El proyecto incluye 12 ejemplos completos — cada uno con su propio deploy.sh, documentación de arquitectura y código Terraform listo para ejecutar. Los módulos siguen las mejores prácticas del AWS Well-Architected Framework: seguridad, confiabilidad, excelencia operacional, rendimiento y optimización de costos.

Módulos

Los 13 módulos cubren la infraestructura necesaria para aplicaciones serverless y basadas en contenedores:

MóduloDescripciónCaracterísticas clave
vpcVPC Multi-AZNAT gateways, VPC endpoints, flow logs
ecrContainer registryEncriptación, lifecycle policies, image scanning
ecsFargate serviceAuto-scaling, Container Insights, Spot
lambdaLambda functionsContainer images, DLQ, retry policies, alarmas
albApplication Load BalancerAccess logs, HTTPS, health checks
sqsSQS colas de mensajesFIFO, DLQ, encriptación, long polling
snsSNS pub/subEmail, SQS, Lambda suscripciones, filtrado
dynamodbDynamoDB NoSQLEncriptación, PITR, auto-scaling
api-gatewayHTTP API (v2)Throttling, logging, X-Ray
api-gateway-v1REST API (v1)OpenAPI/Swagger, VPC Link
cloudfront-s3CDN + hosting estáticoSPA routing, OAC, dominios custom
wafWeb Application FirewallRate limiting, IP filtering, managed rules
cloudwatch-alarmsMonitoreoCPU, memoria, response time, error rates

Ejemplos

Los 12 ejemplos están organizados como una ruta de aprendizaje progresiva:

Fundamentos

EjemploPatrónComponentesEnlace
ecs-appALB → ECSVPC, ALB, ECS, ECRcódigo
lambda-functionLambda Function URLLambda, ECR, CloudWatch, SNS, SQScódigo

API Gateway

EjemploPatrónComponentesEnlace
rest-api-serviceREST API + VPC LinkAPI Gateway v1, NLB, ALB, ECScódigo
openapi-rest-apiREST API + SwaggerAPI Gateway v1, OpenAPI 3.0 → Swagger 2.0, ECScódigo
openapi-http-apiHTTP API + OpenAPIAPI Gateway v2, OpenAPI 3.0, ECScódigo

Full-stack CRUD

EjemploPatrónComponentesEnlace
crud-api-restREST API + DynamoDB + ReactAPI Gateway v1, ECS, DynamoDB, CloudFront, WAFcódigo
crud-api-httpHTTP API + DynamoDB + ReactAPI Gateway v2, ECS, DynamoDB, CloudFrontcódigo

Mensajería

EjemploPatrónComponentesEnlace
sqs-queueLambda + SQS + DLQSQS FIFO, Dead Letter Queue, Lambdacódigo
sns-fanoutSNS → múltiples SQSSNS Topic, filtrado por atributos, múltiples colascódigo

Avanzados

EjemploPatrónComponentesEnlace
api-gateway-multi-serviceMulti-servicioAPI Gateway, VPC Link, FastAPI + Node MCPcódigo
mcp-agent-runtimeMCP Server + AgentCoreECS, ALB, Bedrock AgentCore Gatewaycódigo
agentcore-fullAgentCore completoECS, Lambda, SQS, SNS, OpenSearch, Bedrock Agentcódigo

Ejemplo: ECS con ALB

El ejemplo más básico — una aplicación FastAPI detrás de un ALB en ECS Fargate:

Loading diagram...
module "vpc" {
  source = "jonmatum/serverless-modules/aws//modules/vpc"
 
  name               = "my-app-vpc"
  cidr               = "10.0.0.0/16"
  azs                = ["us-east-1a", "us-east-1b"]
  private_subnets    = ["10.0.1.0/24", "10.0.2.0/24"]
  public_subnets     = ["10.0.101.0/24", "10.0.102.0/24"]
  enable_nat_gateway = true
  single_nat_gateway = true
}
 
module "alb" {
  source = "jonmatum/serverless-modules/aws//modules/alb"
 
  name              = "my-app-alb"
  vpc_id            = module.vpc.vpc_id
  subnet_ids        = module.vpc.public_subnet_ids
  target_port       = 8000
  health_check_path = "/health"
}
 
module "ecr" {
  source = "jonmatum/serverless-modules/aws//modules/ecr"
 
  repository_name = "my-app"
  scan_on_push    = true
}
 
module "ecs" {
  source = "jonmatum/serverless-modules/aws//modules/ecs"
 
  cluster_name              = "my-app-cluster"
  service_name              = "my-app-service"
  container_name            = "my-app"
  container_image           = "${module.ecr.repository_url}:latest"
  container_port            = 8000
  subnet_ids                = module.vpc.private_subnet_ids
  target_group_arn          = module.alb.target_group_arn
  enable_autoscaling        = true
  enable_container_insights = true
}

Ejemplo: CRUD API con HTTP API (v2)

Aplicación full-stack con React, FastAPI, DynamoDB y API Gateway HTTP API:

Loading diagram...
module "dynamodb" {
  source = "jonmatum/serverless-modules/aws//modules/dynamodb"
 
  table_name                    = "my-app-items"
  hash_key                      = "id"
  billing_mode                  = "PAY_PER_REQUEST"
  enable_point_in_time_recovery = true
  enable_encryption             = true
}
 
module "api_gateway" {
  source = "jonmatum/serverless-modules/aws//modules/api-gateway"
 
  name                        = "my-app-api"
  vpc_link_subnet_ids         = module.vpc.private_subnet_ids
  vpc_link_security_group_ids = [aws_security_group.vpc_link.id]
 
  integrations = {
    proxy = {
      method          = "ANY"
      route_key       = "ANY /{proxy+}"
      connection_type = "VPC_LINK"
      uri             = module.alb.listener_arn
    }
  }
 
  enable_access_logs  = true
  enable_xray_tracing = true
}
 
module "cloudfront" {
  source = "jonmatum/serverless-modules/aws//modules/cloudfront-s3"
 
  name           = "my-app-web"
  enable_logging = true
}

REST API vs HTTP API

Una decisión clave al usar API Gateway — los módulos soportan ambas versiones:

CaracterísticaHTTP API (v2)REST API (v1)
Costo$1.00/millón de requests$3.50/millón de requests
Integración VPCDirecta a ALBRequiere NLB intermedio
LatenciaMenorMayor (hop adicional)
OpenAPISíSí
CORSBuilt-inConfiguración manual
API Keys / Usage PlansNoSí
Validación de requestsLimitadaCompleta

Recomendación: usar HTTP API (v2) a menos que se necesiten API keys o usage plans. Es 71% más barato y tiene menor latencia.

Well-Architected Framework

Cada módulo implementa las mejores prácticas del AWS Well-Architected Framework. El documento completo detalla cada decisión.

PilarImplementación
SeguridadEncriptación at rest/transit, IAM least-privilege, VPC endpoints, WAF
ConfiabilidadMulti-AZ, auto-scaling, health checks, DLQ, alarmas
Excelencia operacionalContainer Insights, access logs, CloudWatch, pre-commit hooks
RendimientoFargate compute, VPC endpoints, CloudFront CDN
Optimización de costosFargate Spot, lifecycle policies, VPC endpoints, single NAT para dev

Configuración de producción vs desarrollo

# Producción: Multi-AZ, On-Demand, auto-scaling
module "vpc" {
  source             = "jonmatum/serverless-modules/aws//modules/vpc"
  single_nat_gateway = false  # Multi-AZ NAT
  enable_vpc_endpoints = true
}
 
module "ecs" {
  source                   = "jonmatum/serverless-modules/aws//modules/ecs"
  enable_fargate_spot      = false
  enable_autoscaling       = true
  autoscaling_min_capacity = 2
  autoscaling_max_capacity = 10
  autoscaling_target_cpu   = 70
}
# Desarrollo: Single NAT, Spot, mínima capacidad
module "vpc" {
  source             = "jonmatum/serverless-modules/aws//modules/vpc"
  single_nat_gateway = true
}
 
module "ecs" {
  source              = "jonmatum/serverless-modules/aws//modules/ecs"
  enable_fargate_spot = true
  desired_count       = 1
}

Costos estimados

AmbienteCosto mensualConfiguración
Desarrollo$70–90Single NAT, Fargate Spot, 1 task
Staging$150–200Single NAT, On-Demand, 2 tasks
Producción$200–400Multi-AZ NAT, auto-scaling 2–10 tasks

Desglose de producción: NAT Gateways (2×) ~$65/mes, Fargate (2–10 tasks) ~$50–200/mes, ALB ~$20/mes, DynamoDB on-demand variable.

Despliegue

Cada ejemplo incluye scripts de despliegue idempotentes:

cd examples/ecs-app
./deploy.sh          # Despliegue inicial (Terraform + Docker build + push)
./redeploy.sh        # Redespliegue tras cambios de código
terraform destroy    # Destruir infraestructura

Los módulos soportan despliegues idempotentes — terraform apply && terraform destroy && terraform apply funciona sin errores.

¿Por qué importa?

Estos módulos resuelven un problema concreto: desplegar aplicaciones serverless en AWS requiere coordinar decenas de recursos (VPC, subnets, NAT, ALB, ECS, IAM roles, security groups, CloudWatch) con configuraciones que deben seguir las mejores prácticas de seguridad y confiabilidad. Sin módulos reutilizables, cada equipo reinventa estas configuraciones — y frecuentemente omite encriptación, health checks o auto-scaling. La colección reduce un despliegue de producción de cientos de líneas de IaC a composiciones de 5–10 módulos con defaults seguros.

Referencias

  • Repositorio en GitHub — Código fuente de los 13 módulos y 12 ejemplos.
  • Terraform Registry — Módulos publicados en el registro oficial de Terraform.
  • Documentación Well-Architected — Mapeo de decisiones al Well-Architected Framework.
  • Guía de ejemplos — Ruta de aprendizaje progresiva con 12 ejemplos.
  • Terraform Modules — HashiCorp, 2024. Documentación oficial de módulos Terraform.
  • AWS Well-Architected Framework — AWS, 2024. Marco de referencia para arquitecturas en la nube.
  • AWS Fargate — AWS, 2024. Documentación de Fargate para ECS.
  • Amazon API Gateway HTTP APIs — AWS, 2024. Documentación de HTTP API (v2).

Contenido relacionado

  • Infrastructure as Code

    Práctica de definir y gestionar infraestructura mediante archivos de configuración versionados en lugar de procesos manuales. Fundamento de la automatización moderna de operaciones.

  • Serverless

    Modelo de computación en la nube donde el proveedor gestiona la infraestructura automáticamente, permitiendo ejecutar código sin aprovisionar ni administrar servidores, pagando solo por el uso real.

  • Terraform

    Herramienta de Infrastructure as Code de HashiCorp que permite definir, provisionar y gestionar infraestructura multi-cloud mediante archivos declarativos en HCL.

  • AWS ECS

    Servicio de orquestación de contenedores de AWS que ejecuta y escala aplicaciones Docker sin gestionar la infraestructura de cluster subyacente.

  • AWS Fargate

    Motor de cómputo serverless para contenedores que elimina la necesidad de gestionar servidores, permitiendo ejecutar contenedores Docker pagando solo por los recursos consumidos.

  • AWS API Gateway

    Servicio managed de AWS para crear, publicar y gestionar APIs REST, HTTP y WebSocket que actúan como puerta de entrada a funciones Lambda y otros servicios backend.

  • AWS Lambda

    Servicio de cómputo serverless de AWS que ejecuta código en respuesta a eventos sin necesidad de aprovisionar ni administrar servidores, escalando automáticamente desde cero hasta miles de ejecuciones concurrentes.

  • AWS DynamoDB

    Base de datos NoSQL serverless de AWS con latencia de milisegundos a cualquier escala, ideal para aplicaciones que requieren alto rendimiento y escalabilidad automática.

  • AWS Well-Architected Framework

    Framework de AWS con seis pilares de mejores prácticas para diseñar y operar sistemas confiables, seguros, eficientes y rentables en la nube.

  • AWS SQS

    Servicio de colas de mensajes completamente administrado de AWS que desacopla componentes de aplicaciones distribuidas, garantizando la entrega de mensajes con escalabilidad ilimitada.

  • AWS SNS

    Servicio de mensajería pub/sub de AWS que distribuye mensajes a múltiples suscriptores simultáneamente, habilitando patrones de fan-out y notificaciones a escala.

  • Registros de Contenedores

    Repositorios para almacenar, versionar y distribuir imágenes de contenedores, desde registros públicos como Docker Hub hasta registros privados como ECR.

Experimentos