Todo proyecto en GCP empieza limpio y, unos seis meses después, se convierte en un conjunto de recursos cuyo origen y coste nadie conoce. Se puede evitar con media docena de decisiones tomadas a tiempo.
Organiza la casa antes de escalar
Antes de crear la primera VM, piensa en la jerarquía: Organization en la parte superior, Folders por área o entorno y Projects como unidad de aislamiento. Un proyecto por entorno (dev, staging, prod) es el mínimo razonable: las cuotas, IAM y la facturación quedan separados sin coste adicional.
Asocia cada proyecto a un Billing Account y añade etiquetas del equipo y del centro de costes a todo. Sin etiquetas, el informe de costes es un borrón. Con etiquetas, puedes responder «¿cuánto gastó el equipo X este mes?» en treinta segundos.
IAM: siempre lo mínimo necesario
El pecado clásico es dar Editor a todo el mundo porque «es más rápido». Es rápido hasta que alguien borra un bucket de producción. Empieza por los roles predefinidos más específicos y solo aumenta el nivel cuando realmente sea necesario.
Usa cuentas de servicio por carga de trabajo, nunca la cuenta predeterminada del proyecto. Evita descargar claves JSON: prefiere Workload Identity Federation e impersonation, que evitan que los secretos circulen por ahí. Y revisa los bindings de vez en cuando: Policy Analyzer muestra quién puede hacer qué antes de que se convierta en una mala noticia.
Prefiere lo gestionado a «administrarlo tú mismo»
GCP no consiste en alquilar una VM. Cada vez que montas una máquina para ejecutar PostgreSQL por tu cuenta, asumes las copias de seguridad, los parches, la alta disponibilidad y las guardias nocturnas. Cloud SQL, Pub/Sub, Cloud Run y BigQuery existen precisamente para que no tengas que hacerlo.
El precio de lo gestionado a veces asusta sobre el papel, pero desaparece cuando sumas las horas de ingeniería que consume una VM sin configurar. Reserva Compute Engine para lo que realmente no encaja en un servicio gestionado, no para aquello que da pereza migrar.
El coste no debería ser una sorpresa de fin de mes
Crea Budgets con alertas al 50 %, 90 % y 100 %, y envíalas por correo electrónico y a un tema de Pub/Sub. No impide el gasto, pero te avisa antes del susto de la factura. Además, activa los informes de costes usando las etiquetas que definiste al principio.
Revisa las Recommendations sin pereza: idle VMs, discos huérfanos y committed use discounts. Es dinero inmovilizado a la vista. Añade también una política de retención: los registros y el almacenamiento olvidados son la huella más silenciosa de la nube.
Si no lo ves, no puedes controlarlo
Cloud Logging y Cloud Monitoring ya vienen activados; el error es no mirarlos nunca. Crea dashboards con lo que importa (latencia, tasa de errores y saturación) y alertas con una política de notificación realmente útil, no un gráfico bonito que nadie abre.
Define una retención de registros consciente, porque no todo necesita conservarse durante 400 días. Y usa log-based metrics para convertir esa línea de error recurrente en una alerta accionable, antes de que el cliente te avise del problema.
¿Has hecho clic una vez? Entonces versiona para siempre
¿Configuraste algo en la consola para probarlo? Perfecto, ya aprendiste cómo funciona. Ahora elimínalo y vuelve a crearlo con Terraform. Un recurso creado con un clic es un recurso que nadie puede recrear después y que termina convertido en el clásico «no lo toques, que funciona».
Con la infraestructura como código obtienes revisión, historial y reproducibilidad. Como ventaja adicional, la mitad de los descuidos de IAM y billing aparece en el diff del pull request, mucho antes de llegar a producción.
Las buenas prácticas en GCP no consisten en memorizar servicios, sino en crear hábitos: organiza, restringe, delega en servicios gestionados, vigila el coste y versiona todo. Hazlo desde el primer día y tu yo de dentro de seis meses te lo agradecerá.