Enginyeria de Costos

Buscant el desperdici mínim a AWS i Kubernetes

Full Stack Valles - 27 de maig del 2025

Què tractarem avui

Recursos orfes i obsolets

"Els recursos que no s'utilitzen però que encara generen costos."

• EBS volumes no adjuntats
• EIPs no assignades
• Load Balancers buits
• Snapshots antics
• NAT Gateways sense enrutar
• Suport estès (RDS, EKS, ElastiCache)
• En definitiva, tot allò que no s'està utilitzant

Right-sizing

Ajustar els recursos al que realment necessites

• Sobreprovisionament → Diners llençats
• Subprovisionament → Problemes de rendiment
• L'objectiu: El punt òptim
• El veurem en dos contextos: AWS i Kubernetes

Right-sizing: AWS

RDS, ElastiCache, OpenSearch...

• Utilització real vs. capacitat
• Controla CPU, memòria, IOPS
• Valida la necessitat i mida dels clusters
• Cada entorn el que necessita (pro, stg, dev)

Right-sizing: Kubernetes

• Requests vs Limits: la diferència costa diners
• Requests massa alts → Pagues per CPU/memòria no utilitzada
• Requests massa baixos → Throttling o OOMKilled
• HPA: Escala automàticament segons la demanda real
• Node autoscaling: Ajusta el nombre de nodes al cluster

Computació: Tipus d'instància

On-Demand vs Spot vs Savings Plans

Computació: Escalar Kubernetes amb Karpenter

• Provisiona nodes basat els recursos pendents d'assignar
• Consolidació automàtica de nodes quan no hi ha demanda
• Suporta Spot Instances nativament (vs Cluster Autoscaler)

Xarxa: on els costos s'amaguen

Regla d'or: Minimitza els salts entre AZ i evita la sortida a Internet quan pugis accedir via privat

Caching

Redueix càrrega, redueix cost

• Redis / ElastiCache
  • Cacheja respostes d'APIs externes
  • Cacheja resultats de BBDD
  • Sessions d'usuari
• Patró Cache-Aside
  • 1. Mira cache
  • 2. Si no hi és, va a origen
  • 3. Desa a cache per propera vegada
• Estalvi indirecte:
  • Menys càrrega a BBDD = pots fer right-sizing
  • Menys crides a API = estalvi de sortida

Patró Lambda + SQS

Una combinació perillosa per al cost

• El problema:
  • Peticions elevades de Lambda a SQS
  • Provoca molt cost a SQS
  • Impossible configurar
• Solució: KEDA + Kubernetes
  • Permet escalar de 0 a N
  • Permet configurar les peticions a SQS
  • Redueix el consum de SQS
  • Millor optimització de recursos

Bases de dades Multi-AZ

Lectures locals = 0 trànsit entre AZ

  digraph G {
    rankdir=LR;
    node [shape=box, style=rounded, fontname="Arial"];
    edge [fontname="Arial", fontsize=10];

    // Define nodes with colors
    pod_az_a [label="Pod AZ A", fillcolor="#6cf", style="rounded,filled"];
    pod_az_b [label="Pod AZ B", fillcolor="#6cf", style="rounded,filled"];
    primary [label="Primary", fillcolor="#f96", style="rounded,filled"];
    replica_az_a [label="Replica AZ A", fillcolor="#9f9", style="rounded,filled"];
    replica_az_b [label="Replica AZ B", fillcolor="#9f9", style="rounded,filled"];

    // Write flows (solid lines)
    pod_az_a -> primary [label="write"];
    pod_az_b -> primary [label="write"];

    // Sync flows (dashed lines)
    primary -> replica_az_a [label="sync", style=dashed];
    primary -> replica_az_b [label="sync", style=dashed];

    // Read flows
    pod_az_a -> replica_az_a [label="read"];
    pod_az_b -> replica_az_b [label="read"];
  }
  

• WRITE: Tots els pods escriuen al Primary (alguns creuen AZs)
• SYNC: Primary replica automàticament a les altres AZ
• READ: Cada pod llegeix de la rèplica de la seva AZ (gratuït!)

Conclusions

• La enginyeria de costos és continuada, no un esdeveniment
• Monitoritza, mesura, optimitza
• Cultura FinOps: responsabilitat compartida

Gràcies!

Preguntes?

marticardus | marti.cardus | marticardus | marti.cardus