Fix: caracteres no-ASCII en descripciones de Security Groups (rompía terraform apply)

Date: 2026-07-28 Status: ✅ Confirmado aplicado — coincide byte a byte con lo que ya estaba en el working tree (sin commitear) del repo real. Ver "Verificación" y "Chequeo preventivo" al final.

El error real

Error: creating Security Group (soterex-staging-alb-sg): ... InvalidParameterValue:
Value (Solo el ALB puede recibir tráfico de internet) for parameter GroupDescription
is invalid. Character sets beyond ASCII are not supported.

La API de EC2 (CreateSecurityGroup y las reglas de ingress/egress) no acepta caracteres por fuera de ASCII en el campo description — ni tildes, ni — (guión largo), ni ñ. Esto es una limitación vieja de esa API específica de AWS, no de Terraform.

Importante — no es un problema general del proyecto: los description de los bloques variable de Terraform (metadata interna, nunca llega a una API de AWS) siguen con tildes sin problema. Tampoco afectó a aws_ecr_lifecycle_policy (ese sí tiene tildes y se creó bien en el mismo apply — confirmado en el log real). Es específico de Security Groups.

Qué se corrigió

infra/terraform/modules/network/main.tf — 4 descripciones, sacando tildes y reemplazando — por -:

Recurso	Antes	Después
aws_security_group.alb	"Solo el ALB puede recibir tráfico de internet"	"...trafico de internet"
aws_security_group.ecs	"Tareas de ECS Fargate — solo reciben tráfico del ALB"	"...Fargate - solo reciben trafico..."
aws_security_group.ecs (ingress)	"Tráfico del ALB"	"Trafico del ALB"
aws_security_group.database	"Aurora — solo acepta..."	"Aurora - solo acepta..."
aws_security_group.redis	"ElastiCache Redis — solo acepta..."	"...Redis - solo acepta..."

Checklist

• [x] Aplicar el mismo fix sobre el código real — no hizo falta: el working tree ya tenía exactamente este mismo contenido sin commitear (confirmado con diff byte a byte contra el paquete entregado). Se commitea tal cual estaba, sin pisar nada.
• [ ] Revisar si hay más aws_security_group en módulos que se agreguen a futuro — mismo cuidado (ASCII only en description, tanto del recurso como de cada bloque ingress/egress).
• [x] No hace falta revisar otros tipos de recursos por este mismo motivo — confirmado que ECR lifecycle policies y variables de Terraform no tienen esta restricción.

Verificación

Al aplicar este fix se encontró que el working tree (sin commitear) tenía, además del fix de Security Groups, dos cambios más de la misma sesión real de terraform apply que no estaban mencionados en este documento ni en el paquete entregado:

• infra/terraform/modules/database/main.tf — engine_version de Aurora PostgreSQL bump de 16.4 a 16.13 (probablemente 16.4 dejó de ser una versión válida/disponible en Aurora al momento del apply real).
• infra/terraform/environments/staging/main.tf — 7 outputs nuevos (ecs_cluster_name, ecs_web_service_name, ecs_queue_service_name, ecs_web_task_family, ecs_queue_task_family, ecs_security_group_id, private_subnet_ids) — necesarios para que el Paso 7 del runbook de Staging (cargar los GitHub Secrets desde terraform output) funcione de verdad; confirmado que el módulo ecs ya expone todos los outputs que estos referencian.
• Dos .terraform.lock.hcl nuevos (bootstrap/ y environments/staging/) — evidencia física de que terraform init corrió de verdad contra estos módulos. Se commitean siguiendo la práctica estándar de Terraform (mismo criterio que composer.lock/package-lock.json en este proyecto).

Confirmado con el usuario, se incluye todo en el mismo commit — es trabajo real de la misma sesión de apply, no algo a descartar.

Chequeo preventivo (pedido explícitamente antes de avanzar con Producción)

Barrido de todo infra/terraform/**/*.tf buscando caracteres no-ASCII fuera de comentarios y descripciones de variable/output (esas nunca llegan a una API de AWS, confirmado arriba). Un solo hallazgo real: infra/terraform/modules/monitoring/main.tf, 4 alarm_description de aws_cloudwatch_metric_alarm (atributo real de un recurso, sí llega a la API de CloudWatch PutMetricAlarm) con tildes y —.

Aclaración honesta: a diferencia del bug de Security Groups (confirmado con un error real de terraform apply), esto es una corrección preventiva, no la confirmación de un bug real — no tengo evidencia de que la API de CloudWatch tenga la misma restricción ASCII-only que la de EC2 (es una limitación vieja y específica de esa API en particular, no una regla general de AWS; el propio hallazgo de ECR lifecycle policies de este documento ya muestra que no todas las APIs de AWS comparten esta restricción). Corregido de todos modos por ser un cambio de costo casi nulo (texto plano, sin pérdida de claridad) frente a un riesgo — aunque probablemente bajo — de encontrar el mismo problema recién en el apply real de Producción.

Se revisó también el resto del repo (backend Laravel, frontend Vue) por si hubiera alguna llamada directa a un SDK de AWS con un campo similar — no hay ninguna, todo el aprovisionamiento de AWS pasa por Terraform.