Estandarización multi-cloud: qué imponer y qué dejar flexible

Un solo proveedor. Define roles y federación una vez. Cualquier inconsistencia es enteramente autoinfligida.

Cómo se ve un buen estado: Un IdP central federado a todos los proveedores activos. Cada entrada de acceso humano tiene un propietario nominado y una fecha de revisión. Sin claves de service account de larga duración. Ver: RBAC patterns for production cloud environments. RBAC.

Un proveedor. Estandariza el layout de VPC, el esquema de subnets y la ruta de egress. No hay argumento de complejidad para divergir.

Cómo se ve un buen estado: Un diagrama de red que coincide con lo desplegado. Egress por una ruta controlada. Private endpoints para servicios gestionados en producción. Ver: Network topology in multi-cloud estates. Network topology.

Aún no hay IaC, o un solo proveedor. Empieza con una estructura de módulos estándar. Divergir antes de tener una línea base crea deuda desde el día uno.

Cómo se ve un buen estado: Cero infraestructura de producción provisionada fuera de control de versiones. Nuevos entornos reproducibles desde código. State remoto con locking en cada proveedor. Ver: Terraform module patterns for multi-environment cloud estates. Terraform modules.

Un proveedor. No hay razón para divergir. Elige un destino de logs y aplícalo.

Cómo se ve un buen estado: Cada servicio de producción tiene un destino de logs y una retención mínima de 90 días. Los logs de auditoría de management se retienen de forma inmutable y son inaccesibles para las cuentas de workload.

Un solo proveedor. Impón etiquetado en cada recurso. Usa la asignación de costes nativa del proveedor. No hace falta abstracción.

Cómo se ve un buen estado: Cada recurso etiquetado con equipo y entorno. Informe de costes diario o semanal por equipo. Las alertas de presupuesto saltan antes del sobrecoste, no después de la factura.

Un proveedor o equipos grandes. Estandariza los controles del CIS benchmark, el escaneo de vulnerabilidades y la higiene de secretos.

Cómo se ve un buen estado: Una línea base escrita que se prueba automáticamente en CI. CIS benchmark activado en todos los proveedores. Sin credenciales de larga duración en código, imágenes o secretos de CI. Ver: Golden image architecture for production Linux baselines. Golden images.

Un proveedor. No es posible divergir. Estandariza los runbooks ahora.

Cómo se ve un buen estado: Cada servicio de producción tiene un runbook escrito por alguien que no es el ingeniero principal. Todas las alertas van a una única plataforma de on-call.