Introducción: El proyecto es tu punto de partida en Google Cloud
Desde el momento en que aprovisionas tu primer recurso hasta el día en que eliminas el último, todo en Google Cloud ocurre dentro de un proyecto. Los permisos de Cloud IAM se aplican a nivel de proyecto, los cargos de facturación se consolidan por proyecto, y la habilitación de APIs se gestiona de forma independiente en cada proyecto. Comprender este modelo no es opcional — es la base sobre la que se construyen todos los demás conceptos de GCP. Esta guía recorre la jerarquía de recursos, los tipos de cuentas de facturación, las herramientas de visibilidad de costos y las herramientas de línea de comandos que impulsan las operaciones diarias en la nube.
---
La jerarquía Organización → Carpeta → Proyecto
Google Cloud organiza los recursos en una jerarquía de tres niveles: Organización, Carpeta y Proyecto. Esto no es solo una convención de nomenclatura — es la columna vertebral estructural para la herencia de políticas y los límites de control de acceso.
El nodo Organización corresponde a toda tu empresa. Está vinculado a un dominio de Google Workspace o Cloud Identity, y cualquier Organization Policy o rol de Cloud IAM aplicado a este nivel se hereda automáticamente en todas las carpetas y proyectos que se encuentren por debajo. Por ejemplo, si configuras la restricción para permitir solo , ningún equipo en la organización podrá aprovisionar recursos en ninguna otra región. Un ingeniero que intente crear una VM de Compute Engine en recibirá una denegación inmediata a nivel de API — la restricción se aplica antes de que se cree cualquier recurso.
Las carpetas representan agrupaciones lógicas como unidades de negocio, equipos o entornos como dev, staging y prod. Puedes anidar carpetas hasta diez niveles de profundidad. Al otorgar un rol de Cloud IAM en una carpeta, todos los proyectos dentro de esa carpeta heredan automáticamente el mismo permiso.
Los proyectos son el límite de aislamiento principal para recursos, Cloud IAM y facturación en GCP. Cuando una pregunta del examen de certificación pregunta sobre el aislamiento de equipos y el seguimiento independiente de costos, la respuesta correcta es la separación de proyectos — no las etiquetas.
| Nivel | Corresponde a | Propósito principal | |-------|--------------|--------------------| | Organización | Empresa completa | Raíz de políticas, línea base de Cloud IAM para toda la empresa | | Carpeta | Unidad de negocio / equipo / entorno | Herencia intermedia de políticas, agrupación de proyectos | | Proyecto | Unidad de servicio individual | Límite de aislamiento de recursos, Cloud IAM y facturación | | Recurso | VM, bucket de Cloud Storage, etc. | Objeto de infraestructura real |
---
Comprendiendo las cuentas de facturación y el modelo de cobros
Un proyecto debe estar vinculado a exactamente una cuenta de Cloud Billing antes de poder consumir servicios de pago en GCP. Una sola cuenta de facturación puede vincularse a múltiples proyectos, lo que facilita consolidar los cargos de varios equipos en una sola factura.
Las cuentas de Cloud Billing existen en dos modalidades. Una cuenta de autoservicio cobra automáticamente a una tarjeta de crédito o cuenta bancaria y es la opción habitual para desarrolladores individuales y startups. Una cuenta facturada emite una factura mensual que debe pagarse en un plazo de treinta días y es preferida por empresas y organizaciones del sector público que requieren flujos de trabajo con órdenes de compra.
Un punto de diseño crítico: el Cloud IAM de la cuenta de Cloud Billing y el Cloud IAM a nivel de proyecto son completamente independientes. Otorgar al equipo de finanzas a nivel de cuenta de facturación les da acceso de solo lectura a facturas e informes de costos — nada más. No obtienen ningún acceso a ningún recurso dentro de los proyectos vinculados. Este es el principio de mínimo privilegio aplicado en un escenario concreto y real.
| Rol de facturación | Permiso principal | Palabra clave del examen | |-------------------|------------------|------------------------| | billing.viewer | Acceso de solo lectura a facturas e informes de costos | Solo lectura para equipo de finanzas | | billing.user | Vincular un proyecto a una cuenta de facturación | Vinculación de proyecto por desarrollador | | billing.admin | Gestión completa de una cuenta de facturación | Agregar o eliminar métodos de pago | | billing.costsManager | Gestionar presupuestos y controles de costos | Gestión dedicada de presupuestos |
---
Visibilidad de costos: presupuestos, alertas y exportación de facturación
La gestión eficaz de costos significa diseñar alertas en tu arquitectura antes de gastar dinero — no descubrir excesos después del hecho. Google Cloud proporciona Cloud Billing Budget, Cloud Billing Export y Looker Studio para este propósito.
Cloud Billing Budget te permite establecer un objetivo de gasto mensual y envía notificaciones por correo electrónico o mensajes de Pub/Sub cuando el gasto real alcanza el 50%, 80%, 90% y 100% del umbral. Un punto que confunde a muchos ingenieros y candidatos al examen: un Cloud Billing Budget no detiene ni limita automáticamente ningún servicio. Si quieres apagar automáticamente VMs de Compute Engine cuando se supera un presupuesto, debes construir esa automatización tú mismo usando un tema de Pub/Sub combinado con una función de Cloud Functions.
Cloud Billing Export envía datos de facturación a un dataset de BigQuery de forma automática. La exportación de Standard Usage Cost proporciona datos a nivel de proyecto y SKU, mientras que la exportación de Detailed Usage Cost profundiza hasta el nivel de recurso individual. Los datos exportados incluyen el ID del proyecto, el nombre del servicio, el SKU y las etiquetas que hayas aplicado — lo que te proporciona el material base para escribir consultas SQL que agregan costos por departamento, equipo o entorno. Ten en cuenta que hay un retraso de hasta veinticuatro horas, lo que hace que esta solución no sea adecuada para el monitoreo en tiempo real.
| Herramienta | Caso de uso | Limitación | |-------------|-------------|------------| | Consola de Cloud Billing | Revisión visual, consultas rápidas | Sin análisis SQL ni retención a largo plazo | | Cloud Billing Budget | Alertas de umbral, seguimiento de presupuestos | No puede detener recursos automáticamente | | BigQuery Billing Export | Análisis SQL, retención a largo plazo | Retraso de datos de hasta 24 horas | | Looker Studio | Visualización en dashboards | Requiere datos de BigQuery como prerequisito |
Looker Studio se conecta nativamente a BigQuery sin necesidad de ningún pipeline ETL, por lo que puedes construir un dashboard de costos en vivo directamente sobre los datos de facturación exportados. Para escenarios que requieren tanto análisis SQL basado en etiquetas como informes visuales, la arquitectura estándar es: exportación de facturación a BigQuery, luego BigQuery como fuente de datos para Looker Studio.
---
gcloud, gsutil, bq y kubectl: división de responsabilidades entre herramientas CLI
Google Cloud SDK incluye cuatro herramientas de línea de comandos, cada una con un ámbito claramente definido. Mantener claras sus diferencias reduce la confusión tanto en las operaciones del día a día como en el examen de certificación.
gcloud es la herramienta principal para controlar la gran mayoría de los servicios de GCP. Crear instancias de Compute Engine, gestionar clústeres de GKE, asignar roles de Cloud IAM, configurar redes de VPC — casi toda la gestión de infraestructura fluye a través de gcloud. gsutil es la CLI dedicada para Cloud Storage: crear buckets, subir y descargar objetos, y gestionar listas de control de acceso. bq es la CLI específica de BigQuery para crear datasets, ejecutar consultas SQL y cargar datos en tablas. kubectl controla las cargas de trabajo de Kubernetes en clústeres de GKE. Antes de poder usar kubectl contra un clúster de GKE, necesitas poblar tu archivo kubeconfig ejecutando .
| Herramienta CLI | Objetivo principal | Comandos representativos | |----------------|-------------------|-------------------------| | gcloud | La mayoría de servicios GCP (Compute Engine, Cloud IAM, GKE, etc.) | gcloud compute instances create | | gsutil | Buckets y objetos de Cloud Storage | gsutil cp, gsutil mb | | bq | Datasets, tablas y consultas de BigQuery | bq query, bq load | | kubectl | Clústeres y cargas de trabajo de Kubernetes (GKE) | kubectl apply, kubectl get pods |
---
Configuraciones de gcloud y cambio de contexto
gcloud usa un concepto llamado Configuraciones para almacenar y cambiar rápidamente entre diferentes combinaciones de cuenta, proyecto y configuración de región. Piénsalo como perfiles de navegador — guardas una Configuración de dev y una Configuración de prod por separado, y cambias entre ellas con un solo comando en lugar de volver a especificar flags en cada invocación.
Los patrones de comandos clave de gcloud se dividen en cuatro categorías:
| Categoría | Comando | Descripción | |-----------|---------|-------------| | Autenticación | gcloud auth login | Iniciar sesión con una cuenta de Google | | Autenticación | gcloud auth list | Listar cuentas autenticadas actualmente | | Configuración | gcloud config set project PROJECT_ID | Cambiar el proyecto activo | | Configuración | gcloud config configurations create NAME | Crear una nueva Configuración | | Configuración | gcloud config configurations activate NAME | Cambiar a una Configuración diferente | | Proyecto | gcloud projects list | Listar proyectos a los que tienes acceso |
Agregar directamente a cualquier comando de gcloud te permite apuntar a un proyecto específico para esa única invocación sin cambiar tu Configuración activa. La estructura de comandos de gcloud sigue el patrón , por lo que una vez que internalizas este patrón a menudo puedes inferir el comando correcto sin memorizarlo.
Para permitir q