TL;DR
- Infracost muestra el impacto de costos de cambios Terraform en cada PR — antes del deployment, no despues de la facturacion
- Las policies de costos pueden bloquear PRs que excedan umbrales (como los scanners de seguridad bloquean vulnerabilidades)
- El error #1: tratar las revisiones de costos como opcionales en lugar de gates automatizados
Ideal para: Equipos con gasto cloud significativo o que han tenido sorpresas en facturas Omite si: Estas en tier gratuito o infraestructura de precio fijo Tiempo de lectura: 9 minutos
Tu PR de Terraform se ve bien. Tests pasan, scan de seguridad limpio, aprobado por dos revisores. Haces merge. Llega la factura de AWS del proximo mes: $47,000 sobre presupuesto. Alguien agrego una instancia RDS db.r6g.4xlarge donde db.t3.medium hubiera funcionado.
Este es el gap de FinOps — decisiones de infraestructura hechas sin visibilidad de costos. En 2026, la estimacion de costos pertenece en CI junto al scanning de seguridad. No deberias deployar lo que no puedes pagar.
El Problema Real
Los costos cloud fallan en mantenerse predecibles porque el feedback de costos llega muy tarde. El ciclo de facturacion es mensual. Para cuando ves el impacto, los recursos han estado corriendo por semanas.
Enfoques tradicionales de gestion de costos:
- Alertas de presupuesto que disparan despues de que te pasaste
- Revisiones mensuales de costos que ocurren despues de deployar recursos
- Estimaciones manuales que estan mal o se omiten completamente
El enfoque shift-left para costos:
- Cada PR muestra el cambio estimado de costo mensual
- Policies de costo bloquean cambios que excedan umbrales
- La atribucion de costos ocurre en tiempo de deploy, no a fin de mes
No se trata de tacano — es hacer del costo una preocupacion de ingenieria de primera clase junto con performance y seguridad.
Infracost: La Herramienta Estandar
Infracost se ha convertido en el estandar de facto para estimacion de costos de Terraform. Parsea tus archivos Terraform, consulta APIs de precios cloud y produce desgloses de costos.
# Instalar
brew install infracost
# Autenticar (tier gratuito disponible)
infracost auth login
# Desglose basico de costos
infracost breakdown --path ./terraform
# Comparar dos estados (para diffs de PR)
infracost diff --path ./terraform --compare-to infracost-base.json
El output muestra costos de recursos existentes y nuevos:
Project: terraform
Name Monthly Qty Unit Monthly Cost
aws_instance.web
├─ Instance usage (Linux/UNIX, on-demand, t3.large)
│ 730 hours $60.74
└─ root_block_device
└─ Storage (gp3) 50 GB $4.00
aws_rds_instance.database
├─ Database instance (on-demand, db.r6g.4xlarge)
│ 730 hours $1,752.40
└─ Storage (gp2) 100 GB $11.50
OVERALL TOTAL $1,828.64
El insight clave: ves precios exactos antes de terraform apply.
Integracion CI/CD
Infracost brilla cuando se integra en workflows de PR. Aqui un setup de GitHub Actions:
name: Cost Estimation
on:
pull_request:
paths:
- 'terraform/**'
jobs:
infracost:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
steps:
- uses: actions/checkout@v4
- name: Setup Infracost
uses: infracost/actions/setup@v3
with:
api-key: ${{ secrets.INFRACOST_API_KEY }}
- name: Generate Infracost baseline
run: |
infracost breakdown --path=terraform \
--format=json \
--out-file=/tmp/infracost-base.json
env:
INFRACOST_API_KEY: ${{ secrets.INFRACOST_API_KEY }}
- name: Generate Infracost diff
run: |
infracost diff --path=terraform \
--format=json \
--compare-to=/tmp/infracost-base.json \
--out-file=/tmp/infracost-diff.json
- name: Post PR comment
uses: infracost/actions/comment@v1
with:
path: /tmp/infracost-diff.json
behavior: update
Esto postea un comentario en cada PR mostrando:
- Costo mensual actual
- Costo despues de cambios
- Diff (incremento o decremento)
- Desglose por recurso
Policies de Costos
Visibilidad es el paso uno. Paso dos es enforcement. Infracost soporta policy-as-code para costos:
# infracost-policy.yml
version: 0.1
policies:
- policy_path: policies/cost-policy.rego
rego_url: https://raw.githubusercontent.com/infracost/infracost/master/examples/opa/policies/cost-policy.rego
Escribe policies de costos en Rego (igual que OPA):
package infracost
# Bloquear PRs que incrementen costo mensual mas de $500
deny[msg] {
maxDiff := 500.0
input.diffTotalMonthlyCost > maxDiff
msg := sprintf("Monthly cost increase ($%.2f) exceeds maximum allowed ($%.2f)", [
input.diffTotalMonthlyCost,
maxDiff
])
}
# Requerir aprobacion para cambios sobre $100
warn[msg] {
input.diffTotalMonthlyCost > 100
input.diffTotalMonthlyCost <= 500
msg := sprintf("Cost increase of $%.2f requires finance team approval", [
input.diffTotalMonthlyCost
])
}
# Bloquear tipos de instancia caros especificos
deny[msg] {
resource := input.projects[_].breakdown.resources[_]
contains(resource.name, "aws_instance")
contains(resource.metadata.instance_type, "x2idn")
msg := sprintf("Instance type x2idn not allowed without exception. Resource: %s", [resource.name])
}
Ejecuta evaluacion de policy en CI:
infracost breakdown --path ./terraform --format json | \
infracost policy --policy-path ./policies/
Codigo de salida 1 significa violacion de policy — bloquea el PR.
Tagging para Atribucion de Costos
La estimacion de costos funciona mejor con tagging apropiado. Enforza tags que habiliten atribucion de costos:
# variables.tf
variable "cost_center" {
description = "Centro de costos para atribucion de facturacion"
type = string
validation {
condition = can(regex("^CC-[0-9]{4}$", var.cost_center))
error_message = "Centro de costos debe coincidir con formato CC-XXXX"
}
}
variable "environment" {
description = "Ambiente (dev/staging/prod)"
type = string
validation {
condition = contains(["dev", "staging", "prod"], var.environment)
error_message = "Ambiente debe ser dev, staging o prod"
}
}
# main.tf
locals {
common_tags = {
CostCenter = var.cost_center
Environment = var.environment
ManagedBy = "terraform"
Project = var.project_name
}
}
resource "aws_instance" "web" {
# ...
tags = merge(local.common_tags, {
Name = "web-server"
})
}
Combina con Compliance Testing para enforzar policies de tagging.
Manejando Costos Basados en Uso
Infracost estima basado en recursos provisionados, pero muchos costos cloud dependen del uso. Para estimaciones precisas, provee datos de uso:
# infracost-usage.yml
version: 0.1
resource_usage:
aws_lambda_function.api:
monthly_requests: 10000000
request_duration_ms: 250
aws_s3_bucket.data:
standard:
storage_gb: 500
monthly_tier_1_requests: 100000
monthly_tier_2_requests: 1000000
aws_dynamodb_table.users:
monthly_write_request_units: 5000000
monthly_read_request_units: 25000000
Ejecuta con archivo de uso:
infracost breakdown --path ./terraform --usage-file infracost-usage.yml
Para workloads de produccion, genera uso de metricas reales de CloudWatch:
# Exportar uso de infraestructura corriendo
infracost breakdown --path ./terraform --sync-usage-file infracost-usage.yml
Vistas de Costos Multi-Ambiente
La mayoria de equipos deployan a multiples ambientes. Estructura corridas de Infracost para mostrar costos por ambiente:
# .github/workflows/cost-estimation.yml
jobs:
infracost:
strategy:
matrix:
environment: [dev, staging, prod]
steps:
- name: Infracost for ${{ matrix.environment }}
run: |
infracost breakdown \
--path=terraform/environments/${{ matrix.environment }} \
--format=json \
--out-file=/tmp/infracost-${{ matrix.environment }}.json
Agrega para vista de costo total:
infracost output --path="/tmp/infracost-*.json" --format=table
Enfoques Asistidos por IA
La optimizacion de costos involucra entender tanto modelos de pricing como patrones de uso. Las herramientas de IA aceleran esto.
Lo que la IA hace bien:
- Sugerir tipos de instancia mas baratos para workloads
- Identificar oportunidades de Reserved Instances o Savings Plans
- Explicar modelos de pricing para servicios desconocidos
- Generar archivos de uso Infracost desde requerimientos
Lo que aun necesita humanos:
- Decidir tradeoffs aceptables de costo vs performance
- Entender contexto de negocio para asignacion de costos
- Aprobar excepciones para recursos caros
- Validar que optimizaciones sugeridas por IA realmente funcionan
Prompt util:
Revisa esta configuracion Terraform y sugiere optimizaciones de costo:
- Actual: instancia RDS db.r6g.4xlarge
- Workload: 500 QPS lectura, 50 QPS escritura, 100GB almacenamiento
- Restricciones: Debe mantener latencia p99 <10ms
Provee tipos de instancia alternativos con ahorros mensuales estimados
Cuando Esto Falla
La estimacion de costos tiene limitaciones:
Precision de pricing: Los proveedores cloud cambian precios. Limites de tier gratuito varian por antiguedad de cuenta. Descuentos de uso comprometido no se reflejan en estimaciones crudas.
Estimacion de uso: Servicios serverless y basados en uso requieren predicciones de uso. Lambda, requests S3, transferencia de datos — todos dependen de trafico que podrias no conocer de antemano.
Costos cross-resource: Transferencia de datos entre recursos (VPC endpoints, replicacion cross-region) frecuentemente domina facturas pero es dificil de estimar solo desde Terraform.
Pricing spot/preemptible: Si usas instancias spot, los costos reales varian significativamente de estimaciones on-demand.
Considera enfoques complementarios:
- AWS Cost Explorer / Azure Cost Management para analisis historico
- Presupuestos del proveedor cloud para alertas en tiempo real
- Deteccion de Drift para capturar recursos caros creados manualmente
Framework de Decision
Habilita Infracost en todos los PRs cuando:
- Factura cloud excede $10K/mes
- Multiples equipos deployan independientemente
- Has tenido sorpresas de costos en el ultimo ano
- Ingenieros no conocen pricing cloud
Agrega policies de costos cuando:
- Tipos de recursos especificos necesitan aprobacion
- Limites de presupuesto son restricciones duras
- Equipos solicitan excepciones frecuentemente
- Incrementos de costo correlacionan con incidentes (over-provisioning como “fix”)
Omite estimacion de costos cuando:
- Contratos de precio fijo cubren infraestructura
- Ambientes solo de desarrollo con auto-shutdown
- Proyectos greenfield donde la escala es desconocida
Midiendo el Exito
| Metrica | Antes | Despues | Como Rastrear |
|---|---|---|---|
| Sorpresas de costo por trimestre | Desconocido | 0 | Escalaciones de finanzas |
| Correlacion PR-a-factura | Manual | Automatizada | Infracost vs real |
| Tiempo para identificar causa de spike | Dias | Minutos | Logs de respuesta a incidentes |
| Recursos over-provisionados | Desconocido | <10% | Reportes de right-sizing |
Senales de alarma de que no funciona:
- Equipos ignorando comentarios de costos
- Demasiadas excepciones de policy solicitadas
- Estimaciones consistentemente erroneas vs facturas reales
- Revisiones de costos ocurriendo manualmente a pesar de automatizacion
Que Sigue
Empieza con visibilidad, luego agrega enforcement:
- Habilita Infracost en un repositorio
- Ejecuta por 2 sprints sin policies (recolecta baseline)
- Identifica umbrales razonables de datos historicos
- Agrega policies de warning primero (sin bloqueo)
- Gradua a policies bloqueantes para violaciones claras
- Expande a repositorios adicionales
El objetivo es hacer del costo parte de la definicion de “terminado” — un cambio no esta completo hasta que sabes cuanto cuesta.
Articulos relacionados:
- Compliance Testing para IaC
- Policy as Code Testing: OPA vs Sentinel
- Deteccion de Drift en Infraestructura
- Testing de Infrastructure as Code
Recursos externos: