Ingeniería en la nube para la administración pública: lo que hemos aprendido al utilizar AWS, Azure y GCP en paralelo

El concepto de «multinube» se vende como una estrategia. Pero, por lo general, no lo es: es una consecuencia. Un departamento ya cuenta con un entorno de Azure procedente de su infraestructura de M365, un socio de implementación ha desarrollado el último servicio en AWS y un equipo de ciencia de datos quiere utilizar BigQuery. Nadie lo había planeado. Pero, de todos modos, alguien tiene que gestionarlo.

Tras una década diseñando plataformas en AWS, Azure y Google Cloud para clientes del sector público, esto es lo que realmente importa una vez que se deja atrás el debate sobre «qué nube es la mejor» y se pasa a garantizar que las cargas de trabajo en producción sean seguras, cumplan con la normativa y sean asequibles.

1. La soberanía y la clasificación prevalecen sobre la arquitectura

En los proyectos comerciales, la elección de la región es una decisión relacionada con el rendimiento. En los proyectos públicos, es ante todo una decisión de carácter jurídico.

Antes de escribir ni un solo módulo de Terraform, acordamos lo siguiente:

• ¿Qué clasificación tienen estos datos: «OFICIAL», «OFICIAL-SENSIBLE» o superior?
• ¿Qué región o regiones cumplen el requisito de residencia? ¿Y el modelo de responsabilidad compartida del proveedor lo cumple realmente o solo afirma que lo cumple?
• ¿Quién tiene las claves de cifrado: el proveedor, o el contrato exige que las claves las gestione el cliente (CMK/BYOK)?

# Encryption key ownership is a decision, not a default
resource "aws_kms_key" "official_sensitive" {
  description             = "CMK for OFFICIAL-SENSITIVE workloads"
  deletion_window_in_days = 30
  policy                  = data.aws_iam_policy_document.key_admins.json
  # Key never leaves customer control — no provider-managed fallback
}

Si se comete un error en este aspecto, ni siquiera las mejores soluciones de ingeniería podrán solucionarlo más adelante. Hemos visto cómo algunas migraciones se han paralizado durante meses porque se dio por sentada la residencia de los datos en lugar de verificarla.

2. Elige la nube adecuada para cada carga de trabajo, no una única nube para todo

Los equipos que tienen dificultades con el modelo multicloud son aquellos que intentan que todas las cargas de trabajo sean portables a cualquier lugar. Los equipos que tienen éxito eligen un proveedor principal para cada carga de trabajo en función de sus puntos fuertes y estandarizan las integraciones entre ellos.

El error no es utilizar tres nubes. Es utilizar tres nubes sin decidir ¿por qué? para cada uno.

3. Kubernetes es lo único que hace que el entorno multicloud sea soportable

Las API de computación, IAM y redes difieren entre AWS, Azure y GCP en aspectos que nunca se pueden abstraer por completo. Kubernetes es lo más parecido a un sustrato común, y es la única inversión que sale a cuenta independientemente de los proveedores que acabes utilizando.

# Same manifest, three managed control planes
# EKS, AKS and GKE all accept this without modification
apiVersion: apps/v1
kind: Deployment
metadata:
  name: claims-api
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: claims-api
          image: registry.internal/claims-api:1.4.2
          resources:
            requests: { cpu: "250m", memory: "256Mi" }
            limits:   { cpu: "500m", memory: "512Mi" }

Seguimos utilizando servicios nativos de los proveedores —RDS, Cosmos DB, Cloud SQL— porque rara vez merece la pena reimplementar bases de datos gestionadas en Kubernetes. Sin embargo, la capa de aplicación sigue siendo portátil, y esa portabilidad es lo que permite a un departamento trasladar una carga de trabajo cuando cambia el contrato de un marco de trabajo.

4. FinOps es una práctica semanal, no una revisión anual

Los sobrecostes relacionados con la nube en el sector público rara vez se deben a una sola decisión errónea. Se deben a que nadie se preocupa por ello hasta que la factura llega al escritorio de un director.

# What an unmanaged multi-cloud bill actually looks like after 12 months
AWS:   forecast £18k/mo → actual £31k/mo  (orphaned EBS volumes, over-provisioned RDS)
Azure: forecast £9k/mo  → actual £14k/mo  (dev/test resources never torn down)
GCP:   forecast £4k/mo  → actual £4.2k/mo (tagged and budget-alerted from day one)

La línea GCP destaca por una razón: desde su lanzamiento contó con alertas presupuestarias y un sistema de etiquetado obligatorio establecido por política. Las otras dos no lo tenían, hasta que lo añadimos.

# Tag enforcement at the policy layer, not the honour system
resource "aws_organizations_policy" "require_cost_tags" {
  content = jsonencode({
    tags = {
      "cost-centre" = { tag_key = { "@@assign" = "cost-centre" }, enforced_for = { "@@assign" = ["ec2:instance", "rds:db"] } }
    }
  })
}

El cumplimiento de las etiquetas, las alertas presupuestarias y una revisión semanal de los costes marcan la diferencia entre una previsión y una quimera.

5. La infraestructura como código es la única fuente de verdad — o no es nada

Un entorno multinube sin «IaC» implica tres consolas, tres conjuntos de conocimientos propios de cada equipo y un historial de cambios que, una vez que alguien se marcha, ya nadie recuerda. Terraform (u OpenTofu), con módulos específicos para cada proveedor detrás de una interfaz compartida, es lo que hace que las auditorías sean viables.

module "network" {
  source   = "./modules/network/${var.cloud_provider}"
  cidr     = var.network_cidr
  env      = var.environment
}

Cada cambio pasa por el mismo proceso de revisión de PR, el mismo control de «planificar antes de aplicar» y el mismo registro de auditoría, independientemente de la nube a la que se dirija. Esa coherencia es más importante para un auditor de la norma ISO 27001 o de Cyber Essentials Plus que el proveedor que hayas elegido.

Puntos clave

• Clasifica antes de diseñar la arquitectura — La soberanía y la titularidad de las claves son cuestiones jurídicas, no de infraestructura.
• Elige en función de cada carga de trabajo — El entorno multicloud por casualidad es un inconveniente; el entorno multicloud por diseño es una ventaja
• Kubernetes es la capa de portabilidad — invertir ahí, en lugar de intentar lograr una total independencia de la nube en todos los ámbitos
• FinOps es un proceso continuo — La gestión de etiquetas y las alertas presupuestarias son siempre mejores que una hoja de cálculo trimestral
• IaC es tu registro de auditoría — Si no está en el código y no se ha revisado, es como si no hubiera pasado.

La estrategia multicloud no es, en sí misma, ni buena ni mala. Es un conjunto de limitaciones que ya te ha impuesto otra persona. La labor de los ingenieros consiste en hacer que esas limitaciones resulten «aburridas»: predecibles, auditables y económicas de gestionar.