DevOps desde Cero: Optimizacion de Costos y Lo Que Viene Despues

Introduccion

Bienvenido al articulo veinte, el articulo final de la serie DevOps desde Cero. A lo largo de los diecinueve articulos anteriores construimos una practica DevOps completa desde cero. Escribimos una API en TypeScript, aprendimos control de versiones, configuramos pipelines de CI/CD, deployeamos en AWS, dominamos Kubernetes, automatizamos todo con GitOps, y agregamos observabilidad para poder ver lo que realmente estaba pasando en produccion.

Pero hay un tema que todavia no cubrimos, y puede ser el que mas atencion te consiga de parte de la gerencia: los costos. Las facturas de la nube tienen una forma de crecer silenciosamente en el fondo hasta que alguien nota una factura mensual de cinco cifras y empieza a hacer preguntas dificiles. La optimizacion de costos no se trata de ser tacano. Se trata de gastar intencionalmente y obtener el maximo valor de cada dolar.

En este articulo vamos a cubrir como entender tu factura de AWS, identificar trampas de costos comunes, ajustar tus recursos al tamano correcto, usar instancias Spot y Savings Plans, optimizar costos de Kubernetes, construir una estrategia de tagging, configurar monitoreo de costos, y gestionar ambientes de dev/staging de forma eficiente. Despues vamos a cerrar la serie completa con un repaso de todo lo que aprendimos y hablar sobre hacia donde ir desde aca.

Vamos a meternos de lleno.

Por que importan los costos: el surgimiento de FinOps

Cuando estas aprendiendo cloud en una cuenta personal, los costos se sienten manejables. Un cluster EKS chico, unas instancias EC2 y una base de datos RDS pueden costar entre $100 y $300 por mes. Pero en una organizacion real, esos numeros se multiplican rapido. Los equipos levantan recursos y se olvidan de ellos. Alguien crea un NAT Gateway para pruebas y lo deja corriendo seis meses. Un desarrollador provisiona una instancia m5.4xlarge para un servicio que apenas usa el 10% de su CPU.

La nube hace increiblemente facil gastar plata. Eso es por diseno. No hay proceso de compras, no hay hardware que pedir, no hay espera de seis semanas. Haces click en un boton y los recursos aparecen. Esto es poderoso para la velocidad, pero peligroso para los presupuestos.

Aca es donde entra FinOps. FinOps (Financial Operations) es una practica que trae responsabilidad financiera al gasto en la nube. No se trata de recortar costos a ciegas. Se trata de tomar decisiones informadas sobre que gastar y por que.

Los principios centrales de FinOps son:

• Los equipos necesitan ser duenos de sus costos cloud: Asi como DevOps hizo que los equipos fueran responsables de correr su software, FinOps hace que los equipos sean responsables del costo de correrlo. Si lo deployas, deberias saber cuanto cuesta.
• Las decisiones se basan en valor de negocio: No toda reduccion de costos es buena idea. Recortar tu stack de monitoreo para ahorrar $500/mes puede costarte $50,000 cuando te perdas una caida. La optimizacion de costos se trata de valor, no solo de gastar menos.
• La nube es un modelo de costo variable: A diferencia de on-premise donde compras servidores y los deprecias durante anos, los costos cloud cambian mensualmente. Esto significa que necesitas revisar y optimizar continuamente, no solo una vez al ano.

Pensa en FinOps como el pilar financiero de DevOps. No deployearias codigo sin testearlo. No deberias deployear infraestructura sin entender cuanto cuesta.

AWS Cost Explorer: entendiendo tu factura

El primer paso en la optimizacion de costos es entender a donde va tu plata. AWS Cost Explorer es la herramienta principal para esto. Es gratis y viene incluida en toda cuenta de AWS.

Para acceder, anda a la consola de Billing de AWS y hace click en Cost Explorer. La primera vez que lo habilitas, tarda unas 24 horas en poblar datos historicos. Despues de eso, tenes hasta 12 meses de historial de gastos.

Estas son las vistas que deberias usar regularmente:

Costo mensual por servicio

Este es tu punto de partida. Agrupa por "Service" y configura el rango de tiempo a los ultimos 3 meses. Inmediatamente vas a ver que servicios estan costando mas. En un setup tipico basado en Kubernetes, tus costos principales van a ser usualmente:

• EC2 (incluyendo nodos worker de EKS): El computo es casi siempre la linea mas grande
• RDS: Instancias de base de datos, especialmente si corres Multi-AZ
• NAT Gateway: La transferencia de datos a traves de NAT Gateways es sorprendentemente cara
• EBS: Volumenes persistentes, snapshots y volumenes sin adjuntar
• S3: Costos de almacenamiento y solicitudes
• Data Transfer: Cargos de cross-AZ y egress a internet

Costo por tag

Si tenes una estrategia de tagging adecuada (lo vamos a cubrir mas adelante), podes agrupar costos por tag. Esto te permite responder preguntas como "Cuanto cuesta el ambiente de staging?" o "Cuanto esta gastando el equipo-alpha por mes?" Para usar esta vista, primero necesitas activar tus cost allocation tags en la consola de Billing bajo Cost Allocation Tags.

Tendencias diarias de costos

Cambia a granularidad diaria y busca picos. Un salto repentino en costos de EC2 puede significar que alguien levanto un monton de instancias para un test de carga y se olvido de terminarlas. Un pico en costos de transferencia de datos puede indicar un servicio mal configurado que esta trayendo datos entre regiones.

Tambien podes usar la CLI de AWS para consultar datos de costos programaticamente:

# Obtener el costo del mes pasado agrupado por servicio
aws ce get-cost-and-usage \
  --time-period Start=2026-05-01,End=2026-06-01 \
  --granularity MONTHLY \
  --metrics "BlendedCost" \
  --group-by Type=DIMENSION,Key=SERVICE

# Obtener costos diarios del mes actual
aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-06-17 \
  --granularity DAILY \
  --metrics "BlendedCost"

Trampas de costos comunes

Todo ambiente cloud tiene costos ocultos esperando para sorprenderte. Aca estan los mas comunes y como encontrarlos.

Recursos olvidados

Estos son recursos que se crearon con un proposito pero ya no se necesitan. Acumulan cargos silenciosamente todos los meses.

• Volumenes EBS sin adjuntar: Cuando terminas una instancia EC2, sus volumenes EBS pueden no borrarse automaticamente (depende del flag DeleteOnTermination). Estos volumenes huerfanos cuestan plata aunque nada los este usando.
• Snapshots EBS viejos: Los snapshots se acumulan con el tiempo. Una politica de snapshots diarios en un volumen de 500GB crea 365 snapshots por ano. A $0.05/GB-mes, eso suma.
• Load balancers inactivos: Un load balancer sin targets saludables igual cuesta unos $16-22/mes. Si tenes ALBs abandonados de proyectos viejos, encontralos y borralos.
• NAT Gateways: Cada NAT Gateway cuesta unos $32/mes solo por existir, mas $0.045 por GB de datos procesados. Si tenes NAT Gateways en multiples AZs a traves de multiples VPCs, son cientos de dolares por mes sin hacer nada si esas VPCs estan inactivas.
• Elastic IPs: Una Elastic IP adjunta a una instancia corriendo es gratis. Una Elastic IP sin adjuntar a nada cuesta $3.65/mes. Poco, pero se acumula.
• Imagenes ECR sin usar: Las imagenes de containers en ECR cuestan $0.10/GB-mes. Si tu pipeline de CI pushea una imagen nueva en cada commit y nunca limpias las viejas, los costos de almacenamiento crecen linealmente.

Encontra recursos olvidados con estos comandos:

# Encontrar volumenes EBS sin adjuntar
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].{ID:VolumeId,Size:Size,Created:CreateTime}' \
  --output table

# Encontrar Elastic IPs no asociadas con nada
aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==`null`].{IP:PublicIp,AllocID:AllocationId}' \
  --output table

# Encontrar load balancers sin targets
aws elbv2 describe-target-groups \
  --query 'TargetGroups[*].{ARN:TargetGroupArn,Name:TargetGroupName}' \
  --output table

Instancias sobredimensionadas

Esta es la trampa de costos mas comun. Los equipos eligen un tipo de instancia cuando deployean un servicio por primera vez y nunca lo revisan. Ese m5.xlarge que elegiste "por las dudas" puede estar corriendo con 5% de utilizacion de CPU. Podrias estar en un t3.medium y ahorrar 75%.

Ambientes dev/staging inactivos

Tu ambiente de staging corre 24/7 pero tu equipo trabaja 8 horas al dia, 5 dias a la semana. Eso significa que staging esta inactivo el 76% del tiempo. Si staging cuesta $2,000/mes, estas desperdiciando unos $1,500/mes en computo que nadie esta usando.

Transferencia de datos cross-AZ

La transferencia de datos entre Availability Zones cuesta $0.01/GB en cada direccion ($0.02/GB ida y vuelta). Suena minusculo, pero una arquitectura de microservicios con mucha comunicacion y servicios distribuidos entre AZs puede generar terabytes de trafico cross-AZ. Esto es frecuentemente la linea mas sorprendente en una factura de AWS.

Right-sizing: ajustando recursos al uso real

Right-sizing significa ajustar tus recursos de computo para que coincidan con lo que tu carga de trabajo realmente necesita. Es la optimizacion de costos de mayor impacto que podes hacer porque el computo es usualmente tu gasto mas grande.

Paso 1: Recolectar metricas

Antes de poder hacer right-sizing, necesitas datos. Usa CloudWatch para entender tu utilizacion real de recursos:

# Obtener la utilizacion promedio de CPU para una instancia en los ultimos 7 dias
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0abc123def456789 \
  --start-time 2026-06-10T00:00:00Z \
  --end-time 2026-06-17T00:00:00Z \
  --period 3600 \
  --statistics Average Maximum \
  --output table

Mira tanto el promedio como el maximo. Si tu CPU promedio es 10% y tu maximo es 25%, tenes espacio significativo para reducir. Si tu promedio es 10% pero tu maximo llega a 95%, puede que necesites esa capacidad para picos de carga (o puede que necesites investigar que causa esos picos).

Paso 2: Usar AWS Compute Optimizer

AWS Compute Optimizer analiza tus metricas de CloudWatch y recomienda tipos de instancia que se ajustarian mejor a tu carga de trabajo. Habilitalo en la consola de AWS bajo Compute Optimizer. Es gratis para recomendaciones basicas.

Te va a decir cosas como: "Esta instancia m5.xlarge promedia 8% de utilizacion de CPU. Un t3.medium ahorraria 75% y aun asi proveeria capacidad suficiente." Estas recomendaciones son un buen punto de partida, pero siempre validalas contra los requerimientos reales de tu aplicacion. Aplicaciones intensivas en memoria pueden necesitar mas RAM que CPU, por ejemplo.

Paso 3: Hacer right-sizing gradualmente

No reduzcas todo de una vez. Elegi tus instancias mas sobredimensionadas, reducilas una a la vez, y monitorealas por una semana. Si el rendimiento esta bien, pasa a la siguiente. Si ves problemas, volvela a subir. El right-sizing es iterativo, no un evento unico.

# Cambiar tipo de instancia (requiere stop/start)
aws ec2 stop-instances --instance-ids i-0abc123def456789
aws ec2 modify-instance-attribute \
  --instance-id i-0abc123def456789 \
  --instance-type '{"Value":"t3.medium"}'
aws ec2 start-instances --instance-ids i-0abc123def456789

Para nodos worker de EKS gestionados por un node group, actualizarias la launch template o la configuracion del node group:

# Actualizar el node group gestionado de EKS
aws eks update-nodegroup-config \
  --cluster-name my-cluster \
  --nodegroup-name my-nodegroup \
  --scaling-config minSize=2,maxSize=6,desiredSize=3

Instancias Spot y Karpenter

Las instancias Spot te permiten usar capacidad EC2 no utilizada con hasta 90% de descuento comparado con precios on-demand. La contrapartida es que AWS puede reclamarlas con un aviso de 2 minutos cuando necesita la capacidad de vuelta. Esto suena aterrador, pero con la arquitectura correcta, Spot es una de las estrategias de optimizacion de costos mas efectivas disponibles.

Como funciona Spot

Cuando AWS tiene capacidad no utilizada en un tipo de instancia y AZ particular, hace esa capacidad disponible como instancias Spot a un precio reducido. El precio fluctua segun oferta y demanda pero tipicamente es 60-90% mas barato que on-demand. Cuando AWS necesita esa capacidad de vuelta (una "interrupcion Spot"), tu instancia recibe un aviso de 2 minutos y despues es terminada.

Cuando usar Spot

• Cargas de trabajo stateless: Servidores web, servidores de API y workers que no guardan datos localmente son perfectos para Spot. Si una instancia se interrumpe, el load balancer enruta trafico a otras instancias.
• Procesamiento por lotes: Trabajos que pueden hacer checkpoint y reiniciarse funcionan bien con Spot.
• Runners de CI/CD: Los agentes de build son de corta vida por naturaleza y pueden tolerar interrupciones.
• Ambientes de desarrollo y staging: Estos no necesitan las mismas garantias de confiabilidad que produccion.

Cuando NO usar Spot

• Bases de datos: Perder una instancia de base de datos a mitad de una transaccion es un mal dia.
• Cargas de trabajo stateful sin replicacion: Si perder una instancia significa perder datos, no la pongas en Spot.
• Cargas de trabajo de una sola instancia: Si solo tenes una instancia y se interrumpe, tu servicio esta caido.

Mezclando on-demand y Spot

La mejor practica es correr una base de instancias on-demand que pueda manejar tu carga minima esperada, y usar Spot para todo lo que este por encima. Por ejemplo, si tu API necesita al menos 3 instancias para manejar trafico normal pero escala a 10 durante horas pico, corres 3 on-demand y dejas que las 7 restantes sean Spot.

Karpenter para Kubernetes

Si estas corriendo EKS, Karpenter es la mejor forma de usar instancias Spot con Kubernetes. Karpenter es una herramienta open-source de provisionamiento de nodos que automaticamente selecciona los tipos de instancia y opciones de compra correctos (on-demand vs Spot) basandose en los requerimientos de tus pods.

Aca tenes una configuracion basica de NodePool de Karpenter que mezcla on-demand y Spot:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand", "spot"]
        - key: node.kubernetes.io/instance-type
          operator: In
          values:
            - m5.large
            - m5.xlarge
            - m5a.large
            - m5a.xlarge
            - m6i.large
            - m6i.xlarge
        - key: topology.kubernetes.io/zone
          operator: In
          values:
            - us-east-1a
            - us-east-1b
            - us-east-1c
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
  limits:
    cpu: "100"
    memory: 400Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 1m

Karpenter automaticamente se diversifica entre multiples tipos de instancia y AZs para reducir la chance de interrupciones Spot simultaneas. El bloque disruption le dice a Karpenter que consolide nodos subutilizados, lo que ahorra plata empaquetando pods de forma mas eficiente.

Manejando interrupciones Spot

Para manejar interrupciones Spot de forma graciosa en Kubernetes, asegurate de que tus pods manejen SIGTERM correctamente y tengan terminationGracePeriodSeconds apropiados. Karpenter se integra con el AWS Node Termination Handler para hacer cordon y drain de nodos antes de que sean reclamados.

Reserved Instances y Savings Plans

Si sabes que vas a necesitar cierta cantidad de computo por los proximos 1-3 anos, los Reserved Instances (RIs) y Savings Plans ofrecen descuentos significativos (hasta 72%) a cambio de un compromiso.

Savings Plans vs Reserved Instances

• Compute Savings Plans: Te comprometes a un monto especifico en dolares de computo por hora (ej: $10/hora) por 1 o 3 anos. El descuento aplica en EC2, Fargate y Lambda. Esta es la opcion mas flexible.
• EC2 Instance Savings Plans: Te comprometes a una familia de instancias especifica en una region especifica (ej: m5 en us-east-1). Mayor descuento que los Compute Savings Plans pero menos flexible.
• Reserved Instances: Te comprometes a un tipo de instancia, AZ y tenencia especificos. El mayor descuento pero el menos flexible. Estos son la opcion legacy y generalmente se recomiendan los Savings Plans en su lugar.

Cuando los compromisos tienen sentido

• Cargas de trabajo estables y predecibles: Si tu base de datos de produccion viene corriendo en un r5.2xlarge hace un ano y va a seguir asi, un Savings Plan es obvio.
• Computo base: Comprometete a tu computo minimo requerido. Usa on-demand y Spot para todo lo que este por encima de la base.
• Despues del right-sizing: Siempre hace right-sizing primero, despues comprometete. No hay nada peor que comprometerse a una instancia sobredimensionada por 3 anos.

Cuando evitar compromisos

• Cargas de trabajo nuevas: Espera hasta que entiendas los requerimientos reales de recursos (al menos 2-3 meses de datos).
• Arquitecturas que cambian rapidamente: Si estas migrando de EC2 a containers o de x86 a ARM, bloquearte en compromisos puede salir mal.
• Montos chicos: La sobrecarga administrativa de gestionar RIs para ahorrar $50/mes no vale la pena.

Un enfoque practico es cubrir el 60-70% de tu computo estable con Savings Plans, manejar el siguiente 20% con on-demand, y usar Spot para el 10-20% restante que maneja picos de carga.

Optimizacion de costos en Kubernetes

Kubernetes agrega su propia capa de complejidad de costos. Los pods solicitan recursos, los nodos los proveen, y la brecha entre lo solicitado y lo realmente usado es plata desperdiciada.

Requests y limits de recursos

Todo pod deberia tener requests y limits de recursos definidos. Los requests le dicen al scheduler cuanto CPU y memoria necesita un pod. Los limits ponen un tope a cuanto puede usar. La brecha entre lo que solicitas y lo que realmente usas es desperdicio.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: api
          image: my-api:latest
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"

El error mas comun es poner requests muy altos "por las dudas." Si tu container de API usa 50m de CPU en promedio pero solicitas 500m, cada pod desperdicia 450m de CPU. Con 10 replicas, estas desperdiciando 4.5 vCPUs, que podria ser un nodo entero de computo.

Para encontrar los valores correctos, revisa el uso real con kubectl top:

# Revisar uso real de recursos por pod
kubectl top pods -n my-namespace

# Revisar utilizacion de recursos a nivel de nodo
kubectl top nodes

# Asignacion detallada de recursos por nodo
kubectl describe node <node-name> | grep -A 5 "Allocated resources"

Configura los requests basandote en el uso P95 (lo que el pod realmente usa el 95% del tiempo) y los limits a aproximadamente 2x el request para manejar rafagas. Revisa y ajusta estos valores cada mes.

Resource quotas por namespace

Los resource quotas previenen que un solo equipo o namespace consuma mas de su parte justa de recursos del cluster. Sin quotas, un deployment descontrolado de un equipo puede dejar sin recursos a todos los demas y forzar escalado innecesario del cluster.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-alpha-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "8"
    requests.memory: "16Gi"
    limits.cpu: "16"
    limits.memory: "32Gi"
    pods: "50"
    persistentvolumeclaims: "10"

Cluster Autoscaler y Karpenter

Tanto el Cluster Autoscaler como Karpenter escalan la cantidad de nodos basandose en pods pendientes, pero lo abordan de forma diferente:

• Cluster Autoscaler: Trabaja con AWS Auto Scaling Groups. Vos predefiniras configuraciones de node groups (tipos de instancia, tamanos). El autoscaler agrega o remueve nodos de estos grupos predefinidos. Mas simple de configurar pero menos flexible.
• Karpenter: Evalua los pods pendientes y provisiona el tipo de instancia optimo en el momento. Puede elegir de un amplio rango de tipos de instancia y automaticamente empaquetar pods eficientemente. Mas flexible y generalmente mas cost-effective, pero requiere mas configuracion inicial.

Cualquiera que uses, asegurate de que el scale-down este habilitado y ajustado. Por defecto, el Cluster Autoscaler espera 10 minutos antes de remover un nodo subutilizado. En un ambiente con trafico variable, este delay significa que estas pagando por nodos inactivos 10 minutos despues de cada pico de trafico.

Horizontal Pod Autoscaler (HPA)

El HPA escala la cantidad de pods basandose en metricas como CPU o metricas personalizadas. Esto te permite correr menos pods durante periodos de poco trafico y escalar durante picos, en lugar de correr capacidad pico 24/7.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60

Estrategia de tagging: etiqueta todo

Los tags son la base de la visibilidad de costos. Sin tags, tu factura de AWS es un solo numero grande. Con tags, podes responder "Cuanto cuesta cada ambiente?", "Que equipo esta gastando mas?", y "Cual es el costo por cliente?"

Tags minimos requeridos

Cada recurso en tu cuenta de AWS deberia tener al menos estos tags:

• Environment: production, staging, development
• Team: El equipo que es dueno del recurso
• Service: El nombre de la aplicacion o servicio
• CostCenter: Para chargeback o showback a unidades de negocio
• ManagedBy: terraform, manual, karpenter, etc.

Forzar tags con politicas

Los tags solo funcionan si se aplican consistentemente. Usa politicas de tags de AWS Organizations o validacion de Terraform para forzar el tagging:

# Terraform: forzar tags en todos los recursos
variable "required_tags" {
  type = map(string)
  default = {
    Environment = ""
    Team        = ""
    Service     = ""
    ManagedBy   = "terraform"
  }
}

resource "aws_instance" "api" {
  ami           = "ami-0abc123def456789"
  instance_type = "t3.medium"

  tags = merge(var.required_tags, {
    Name        = "api-server"
    Environment = "production"
    Team        = "backend"
    Service     = "user-api"
  })
}

Para un enfoque mas robusto, usa una politica de tags de AWS Organizations:

{
  "tags": {
    "Environment": {
      "tag_key": {
        "@@assign": "Environment"
      },
      "tag_value": {
        "@@assign": [
          "production",
          "staging",
          "development"
        ]
      },
      "enforced_for": {
        "@@assign": [
          "ec2:instance",
          "rds:db",
          "s3:bucket",
          "elasticloadbalancing:loadbalancer"
        ]
      }
    }
  }
}

Activar cost allocation tags

Crear tags no alcanza. Tambien necesitas activarlos como cost allocation tags en la consola de Billing. Solo los tags activados aparecen en Cost Explorer para agrupar y filtrar. Anda a Billing, despues a Cost Allocation Tags, encontra tus tags, y hace click en Activate. Tarda hasta 24 horas para que los tags activados aparezcan en Cost Explorer.

Monitoreo de costos: presupuestos y alertas

Configurar monitoreo de costos es como configurar monitoreo de aplicaciones. No esperas a que los usuarios reporten caidas. Configuras alertas. Tampoco deberias esperar a que finanzas reporte excesos de costos.

AWS Budgets

Crea presupuestos para tu gasto total de cuenta y para cada servicio o ambiente principal:

# Crear un presupuesto mensual con alertas por email
aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{
    "BudgetName": "monthly-total",
    "BudgetLimit": {
      "Amount": "5000",
      "Unit": "USD"
    },
    "TimeUnit": "MONTHLY",
    "BudgetType": "COST"
  }' \
  --notifications-with-subscribers '[
    {
      "Notification": {
        "NotificationType": "ACTUAL",
        "ComparisonOperator": "GREATER_THAN",
        "Threshold": 80,
        "ThresholdType": "PERCENTAGE"
      },
      "Subscribers": [
        {
          "SubscriptionType": "EMAIL",
          "Address": "[email protected]"
        }
      ]
    },
    {
      "Notification": {
        "NotificationType": "FORECASTED",
        "ComparisonOperator": "GREATER_THAN",
        "Threshold": 100,
        "ThresholdType": "PERCENTAGE"
      },
      "Subscribers": [
        {
          "SubscriptionType": "EMAIL",
          "Address": "[email protected]"
        }
      ]
    }
  ]'

Esto crea un presupuesto de $5,000/mes con dos alertas: una cuando el gasto real llega al 80% del presupuesto, y otra cuando el gasto proyectado se proyecta que va a exceder el presupuesto. La alerta de proyeccion es especialmente util porque te da tiempo para actuar antes de que realmente te pases.

Revisiones semanales de costos

Arma un ritual semanal donde alguien del equipo revise los costos. No necesita ser una reunion larga. Un chequeo de 15 minutos de Cost Explorer una vez por semana alcanza. Busca:

• Picos inesperados: Cualquier cosa que haya saltado significativamente respecto a la semana anterior
• Servicios nuevos: Cualquier servicio que aparecio en tu factura que no estaba antes
• Lineas de tendencia: El gasto general esta subiendo? Si es asi, es proporcional al crecimiento?
• Recursos inactivos: Cualquier recurso con cero o casi cero utilizacion

La persona que hace la revision deberia rotar en el equipo. Esto construye conciencia de costos en todo el equipo, no solo en un vigilante de costos designado.

Estrategias para ambientes dev/staging

Los ambientes de desarrollo y staging son frecuentemente el lugar mas facil para recortar costos porque no necesitan estar disponibles 24/7 y no necesitan recursos de grado produccion.

Apagar de noche y los fines de semana

Si tu equipo trabaja de 9am a 6pm los dias habiles, tus ambientes de dev y staging estan inactivos el 73% del tiempo. Usa escalado programado para apagarlos fuera del horario laboral:

# Reducir el node group de EKS de noche (ejecutar via cron o Lambda)
aws eks update-nodegroup-config \
  --cluster-name dev-cluster \
  --nodegroup-name dev-nodes \
  --scaling-config minSize=0,maxSize=3,desiredSize=0

# Levantar a la manana
aws eks update-nodegroup-config \
  --cluster-name dev-cluster \
  --nodegroup-name dev-nodes \
  --scaling-config minSize=1,maxSize=3,desiredSize=2

Podes automatizar esto con una funcion Lambda disparada por EventBridge en un horario:

{
  "schedule_expression": "cron(0 22 ? * MON-FRI *)",
  "description": "Reducir cluster dev a las 10 PM",
  "action": "scale-down"
}

Usar instancias mas chicas para no-produccion

Si produccion corre en m5.xlarge, staging probablemente puede correr en t3.medium. Dev puede correr en t3.small. El objetivo no es ambientes identicos. Es ambientes que sean lo suficientemente similares para detectar bugs pero lo suficientemente chicos para ser accesibles.

Ambientes efimeros

En lugar de correr un ambiente de staging persistente, considera levantar ambientes de corta vida para cada pull request. El ambiente se crea cuando se abre el PR, corre tests de integracion, y se destruye cuando el PR se mergea o se cierra. Solo pagas por el tiempo en que alguien esta activamente testeando. Herramientas como Argo CD ApplicationSets o Terraform workspaces pueden automatizar este patron.

Clusters dev de un solo nodo

Para desarrollo, considera correr un cluster Kubernetes de un solo nodo o usar una herramienta local como kind o minikube. Esto evita el costo del control plane de EKS ($73/mes) y los costos de computo multi-nodo completamente para desarrollo local.

Juntando todo: checklist de optimizacion de costos

Aca tenes un checklist practico que podes seguir para optimizar tus costos cloud:

• Semana 1: Habilitar Cost Explorer, activar cost allocation tags, crear un presupuesto basico con alertas
• Semana 2: Auditar recursos olvidados (volumenes sin adjuntar, load balancers inactivos, Elastic IPs sin usar). Borrar todo lo que no se necesite
• Semana 3: Analizar utilizacion de computo con CloudWatch y Compute Optimizer. Identificar candidatos para right-sizing
• Semana 4: Hacer right-sizing de tus instancias mas sobredimensionadas. Empezar con no-produccion
• Mes 2: Implementar politicas de tagging, configurar escalado programado para dev/staging, evaluar Spot para cargas de trabajo stateless
• Mes 3: Revisar requests/limits de recursos de Kubernetes, implementar HPA, considerar Karpenter. Evaluar Savings Plans para cargas de trabajo de produccion estables
• Continuo: Revisiones semanales de costos, pasadas de optimizacion mensuales, evaluacion trimestral de Savings Plans

Repaso completo de la serie

Cubrimos un monton de terreno en esta serie. Tomemos un momento para mirar atras cada articulo y lo que aprendimos en cada uno. Si te perdiste alguno o queres revisitar un tema, los links de abajo te van a llevar.

• Articulo 1: Que Significa Realmente - Empezamos desde el principio. Que es DevOps, de donde viene, las metricas DORA que lo miden, y como se relaciona DevOps con SRE y Platform Engineering.
• Articulo 2: Tu Primera API en TypeScript - Construimos una aplicacion real con Express y Docker. Esto nos dio algo concreto para deployear a lo largo del resto de la serie.
• Articulo 3: Control de Versiones para Equipos - Aprendimos workflows de Git, estrategias de branching, pull requests y code review. La base de colaboracion para todo lo que siguio.
• Articulo 4: Testing Automatizado - Escribimos tests unitarios, tests de integracion y aprendimos la piramide de testing. Ningun pipeline de CI funciona sin buenos tests.
• Articulo 5: Tu Primer Pipeline de CI - Configuramos GitHub Actions para automaticamente hacer lint, testear y buildear nuestro codigo en cada push. Nuestra primera probada de automatizacion.
• Articulo 6: AWS desde Cero - Creamos una cuenta de AWS, configuramos usuarios y roles de IAM, entendimos regiones y AZs, y nos sentimos comodos con la CLI de AWS.
• Articulo 7: Infraestructura como Codigo con Terraform - Dejamos de clickear en la consola y empezamos a definir infraestructura como codigo. VPCs, subnets, security groups, todo en Terraform.
• Articulo 8: Deployeando a ECS con Fargate - Deployeamos nuestra API en AWS por primera vez usando ECS y Fargate. Infraestructura cloud real corriendo nuestra aplicacion real.
• Articulo 9: Gestion de Secrets y Configuracion - Aprendimos como gestionar secretos de forma segura con AWS Secrets Manager y SSM Parameter Store. No mas passwords hardcodeados.
• Articulo 10: DNS, TLS y Networking - Hicimos nuestra app accesible con un dominio real, configuramos certificados TLS con ACM, y entendimos como el networking conecta todo.
• Articulo 11: Fundamentos de Kubernetes - Aprendimos pods, deployments, services y namespaces. Los bloques fundamentales de la orquestacion de containers.
• Articulo 12: Helm Charts - Empaquetamos nuestra aplicacion Kubernetes con Helm, haciendola reutilizable y configurable entre ambientes.
• Articulo 13: EKS, Corriendo Kubernetes en AWS - Configuramos un cluster EKS de grado produccion con Terraform, incluyendo managed node groups, integracion IAM y networking.
• Articulo 14: GitOps con ArgoCD - Implementamos GitOps para que git se convirtiera en la unica fuente de verdad para nuestros deploys. Push a git y ArgoCD se encarga del resto.
• Articulo 15: Observabilidad en Kubernetes - Configuramos Prometheus, Grafana y logging estructurado. Aprendimos sobre los tres pilares: logs, metricas y trazas.
• Articulo 16: CI/CD, El Pipeline Completo - Unimos todo en un pipeline completo desde pull request hasta produccion, con gates de staging y aprobaciones manuales.
• Articulo 17: Seguridad y Compliance - Cubrimos escaneo de imagenes de containers, politicas RBAC, network policies, y como integrar seguridad en cada etapa del pipeline.
• Articulo 18: Disaster Recovery y Alta Disponibilidad - Aprendimos deploys multi-AZ, estrategias de backup, objetivos de RTO/RPO, y como planificar para lo peor para que tus sistemas sigan funcionando.
• Articulo 19: Estrategias de Deploy Avanzadas - Exploramos deploys canary, deploys blue/green, feature flags, y patrones de entrega progresiva para releases sin downtime.
• Articulo 20: Optimizacion de Costos y Lo Que Viene Despues (este articulo) - Aprendimos como entender, monitorear y optimizar costos cloud, y cerramos la serie completa.

Son veinte articulos, y si seguiste el recorrido, pasaste de no saber nada de DevOps a tener un pipeline completo de grado produccion con testing automatizado, infraestructura como codigo, Kubernetes, GitOps, observabilidad, seguridad y optimizacion de costos. Eso es un logro serio.

Que viene despues

Terminar esta serie no significa que dejaste de aprender. En muchos sentidos, recien estas empezando. Ahora tenes una base solida, y hay varios caminos hacia adelante dependiendo de tus intereses y objetivos de carrera.

Site Reliability Engineering (SRE)

Si disfrutaste los aspectos de observabilidad, monitoreo y confiabilidad de esta serie, SRE es un paso natural. SRE toma los principios DevOps que cubrimos y agrega practicas de ingenieria rigurosas alrededor de la confiabilidad: SLIs, SLOs, error budgets, gestion de incidentes, chaos engineering y capacity planning.

Tenemos una serie completa de SRE en este blog que continua donde esta termina. Empeza con SRE: SLIs, SLOs, and Automations That Actually Help y trabaja los catorce articulos.

Platform Engineering

Si te encontraste pensando "ojala los desarrolladores no tuvieran que saber todo esto solo para deployear sus apps," Platform Engineering es para vos. Los equipos de plataforma construyen plataformas internas para desarrolladores que abstraen la complejidad de la infraestructura. Construirias golden paths, portales de autoservicio y herramientas para desarrolladores que hacen facil para cualquier developer deployear, observar y gestionar sus aplicaciones sin necesidad de entender cada componente subyacente.

Developer Experience (DX)

Relacionado con Platform Engineering, Developer Experience se enfoca en hacer que los desarrolladores sean productivos y esten contentos. Pipelines de CI rapidos, setups locales de desarrollo excelentes, documentacion clara, onboarding facil. Si te importa como la gente experimenta las herramientas y procesos que construis, DX vale la pena explorar.

Certificaciones

Si queres formalizar tu conocimiento y senalar tus habilidades a empleadores, considera estas certificaciones:

• AWS Solutions Architect Associate (SAA-C03): Cubre los servicios core de AWS que usamos a lo largo de la serie. Si seguiste el recorrido y construiste todo, ya sabes como el 70% de lo que esta en este examen.
• Certified Kubernetes Administrator (CKA): Valida tus habilidades de Kubernetes. Los articulos sobre fundamentos de Kubernetes, Helm y EKS te dieron una ventaja fuerte.
• HashiCorp Terraform Associate: Cubre los conceptos de Terraform que usamos para infraestructura como codigo. Probablemente la mas facil de las tres si veniste escribiendo Terraform a lo largo de la serie.

Ninguna de estas certificaciones es obligatoria. La experiencia practica importa mas que los certificados. Pero pueden ser utiles para conseguir entrevistas, especialmente al principio de tu carrera.

Comunidades y recursos

Aprender no pasa en aislamiento. Aca hay algunas comunidades y recursos que vale la pena revisar:

• CNCF (Cloud Native Computing Foundation): La organizacion detras de Kubernetes, Prometheus, ArgoCD y muchas otras herramientas que usamos. Su pagina de landscape te da un mapa de todo el ecosistema cloud native.
• Subreddits y foros de DevOps: r/devops, r/kubernetes y r/aws son comunidades activas donde la gente comparte experiencias y se ayuda mutuamente.
• Charlas de KubeCon: Las charlas grabadas de KubeCon estan disponibles gratis en YouTube y cubren desde temas para principiantes hasta avanzados.
• El libro de SRE: El libro "Site Reliability Engineering" de Google esta disponible gratis online en sre.google. Es el texto fundacional para practicas SRE.
• "Accelerate" de Forsgren, Humble y Kim: El libro detras de las metricas DORA. Si queres entender la investigacion que prueba que las practicas DevOps funcionan, este es el indicado.

Notas finales

Este es el final de la serie DevOps desde Cero, y si llegaste hasta aca, quiero decirte algo con sinceridad: muy bien hecho. Veinte articulos es mucho. Construir todo esto desde cero requiere compromiso real, y el hecho de que te hayas mantenido dice mucho de vos.

Cuando empezamos esta serie, hablamos de lo que DevOps realmente significa. No el buzzword, no el titulo de puesto, sino la idea real: que las personas que construyen software y las personas que lo corren deberian trabajar juntos, compartir responsabilidad, y usar automatizacion para moverse mas rapido sin sacrificar estabilidad. Cada articulo desde entonces fue una expresion practica de esa idea. Tests automatizados, pipelines de CI, infraestructura como codigo, Kubernetes, GitOps, observabilidad, seguridad, y ahora optimizacion de costos. Cada pieza refuerza a las otras. Juntas, forman una practica completa.

Pero lo mas importante que construiste no es un pipeline o un cluster. Es una forma de pensar. Ahora encaras los problemas de forma diferente. Cuando ves un proceso manual, pensas en automatizarlo. Cuando ves un deploy que requiere SSH y oraciones, pensas en CI/CD. Cuando alguien dice "funciona en mi maquina," pensas en containers. Esa mentalidad es mas valiosa que cualquier herramienta especifica, y te va a servir bien sin importar a donde te lleve tu carrera.

El ecosistema cloud va a seguir evolucionando. Nuevas herramientas van a aparecer, algo de lo que cubrimos se va a volver obsoleto, y las mejores practicas van a cambiar. Esta bien. Los fundamentos que cubrimos (control de versiones, testing, automatizacion, infraestructura como codigo, observabilidad, seguridad, conciencia de costos) son atemporales. Las herramientas especificas cambian, pero los principios no.

Asi que anda y construi algo. Toma lo que aprendiste aca y aplicalo en el trabajo, en un proyecto personal, o en una contribucion open source. La mejor forma de solidificar el conocimiento es usarlo. Y cuando te trabes, recorda que todo experto que admiras estuvo alguna vez exactamente donde vos estas ahora.

Gracias por leer esta serie. Genuinamente espero que te haya ayudado, y espero que la hayas disfrutado tanto siguiendola como yo escribiendola. Hasta la proxima serie!

Errata

Si encontras algun error o tenes alguna sugerencia, por favor mandame un mensaje para que se corrija.

Tambien podes revisar el codigo fuente y los cambios en las fuentes aca