Todo recurso que crees en Google Cloud vive dentro de un proyecto, y todo proyecto ocupa un lugar en una jerarquía. Esa estructura no es burocracia administrativa: determina quién puede hacer qué, quién paga qué, qué cuotas se aplican, qué políticas se heredan y qué recursos pueden verse entre sí. Diseñarla bien al principio cuesta una tarde; rediseñarla dos años después cuesta un trimestre.

En esta lección construimos la estructura de AlpinaShop en Google Cloud. Veremos la jerarquía completa Organización → Carpetas → Proyectos → Recursos, qué es exactamente un proyecto y por qué el projectId es inmutable y global, en qué sentido el proyecto es una frontera de facturación, cuotas, permisos y red, cómo funcionan las cuentas de facturación y quién puede vincularlas, cómo se reparte el gasto con etiquetas, cómo se exporta la facturación a BigQuery y cómo se leen los informes y se configuran presupuestos. Terminaremos con las buenas prácticas de estructura y un ejemplo práctico completo con gcloud.

1. La jerarquía de recursos de Google Cloud
2. La jerarquía de AlpinaShop
3. Qué es exactamente un proyecto: ID, número y nombre
4. El proyecto como frontera
5. Cuentas de facturación
6. Etiquetas para repartir el gasto
7. Informes, exportación a BigQuery y presupuestos
8. Herencia de políticas en la jerarquía
9. Buenas prácticas de estructura de proyectos
10. Ejemplo práctico completo con gcloud

Google Cloud organiza todo en un árbol de cuatro niveles:

Cada nivel puede llevar políticas de IAM y políticas de organización, y esas políticas se heredan hacia abajo. Ese es el motivo real de que exista la jerarquía: aplicar una regla una vez y que cubra todo lo que hay debajo.

Algunas precisiones que evitan confusiones:

• Sin organización no hay carpetas. Si te registraste con una cuenta personal (lección 01-02), tus proyectos están sueltos y no puedes crear carpetas. Esa es una de las razones principales para usar Cloud Identity en una empresa.
• La organización se crea sola. No la creas tú: aparece automáticamente la primera vez que un usuario del dominio verificado crea un proyecto.
• Los recursos no cuelgan de las carpetas, solo los proyectos. Una VM está siempre dentro de un proyecto, nunca directamente en una carpeta.

Marta diseña esta estructura para AlpinaShop, deliberadamente sencilla: para una empresa de 40 personas, una jerarquía de tres carpetas y cuatro proyectos es más que suficiente. Las estructuras complejas son para organizaciones con decenas de equipos.

Por qué esta estructura y no otra:

• produccion y desarrollo separadas permiten aplicar políticas distintas a cada mundo. En producción se prohibirán las IP públicas y se exigirán logs de auditoría; en desarrollo se permitirá más libertad y se pondrán presupuestos bajos.
• compartido alberga lo que sirve a ambos entornos: el pipeline de CI/CD y el almacén analítico. Separar la analítica en su propio proyecto evita que las consultas de Lucía consuman cuotas de producción y facilita darle permisos amplios ahí sin dárselos en la tienda.
• Un proyecto por entorno, no un proyecto con recursos "de dev" y "de prod" mezclados. Es la regla más importante de todas.

En este módulo trabajaremos solo con alpinashop-dev. Los demás proyectos se irán creando cuando los módulos correspondientes los necesiten.

Un proyecto tiene tres identificadores distintos y confundirlos genera errores difíciles de diagnosticar.

Detalles del projectId que hay que interiorizar:

• Es único en todo Google Cloud, no solo en tu organización. Si otro cliente en el mundo ya usa tienda, tú no puedes. Por eso los IDs corporativos suelen llevar prefijo de empresa.
• No se puede cambiar jamás. Ni renombrando, ni por soporte. La única salida es crear otro proyecto y migrar los recursos, que en muchos casos significa recrearlos.
• Reglas de formato: entre 6 y 30 caracteres, minúsculas, números y guiones, debe empezar por letra y no puede acabar en guion.
• Cuando borras un proyecto, su ID no se libera inmediatamente (y en la práctica es mejor asumir que no se libera nunca para uso propio).

Del projectNumber conviene saber que aparece en las cuentas de servicio predeterminadas, con formas como [email protected] o [email protected]. Cuando veas un número largo en un correo de cuenta de servicio, es el número de tu proyecto.

El flag --format="table(...)" selecciona qué campos mostrar y los presenta en columnas. Sin él, gcloud devolvería una tabla por defecto con menos información. En la lección 01-06 veremos a fondo --format y --filter.

Esta es la idea central de la lección: el proyecto es simultáneamente cuatro fronteras distintas, y por eso decidir qué va en qué proyecto es una decisión de arquitectura.

De estas cuatro, la de red es la que más sorprende a quien viene de un entorno tradicional. Dos VMs en proyectos distintos no comparten red privada salvo que lo configures explícitamente mediante VPC compartida o peering, temas de las lecciones 03-01 y 07-03. Esto es una ventaja de aislamiento, no un obstáculo.

Y una consecuencia útil que se aprovecha continuamente: borrar un proyecto borra todo lo que contiene. Es la forma más fiable de limpiar un entorno de pruebas y de garantizar que no queda nada generando gasto.

Ese margen de 30 días es una red de seguridad importante: un borrado accidental es recuperable, siempre que se detecte a tiempo.

Una cuenta de facturación define quién paga, con qué método de pago y a qué datos fiscales se emite la factura. Es un objeto que vive fuera de la jerarquía de proyectos: no cuelga de una carpeta ni de un proyecto, sino que se asocia a ellos.

La relación es N a 1: muchos proyectos pueden apuntar a una misma cuenta de facturación, pero cada proyecto tiene como máximo una.

Vincular un proyecto a una cuenta de facturación exige permisos en los dos lados, y esto es una separación de responsabilidades deliberada:

En AlpinaShop, Marta tiene billing.admin, el responsable financiero tiene billing.viewer para consultar el gasto sin poder tocar nada, y Dani tiene billing.user sobre la cuenta para poder vincular proyectos de pruebas él mismo. El detalle de cómo funcionan los roles de IAM se estudia en la lección 03-04.

unlink es una herramienta contundente y muy útil: es el "corte de emergencia" cuando un proyecto se dispara en coste. Detiene el consumo de servicios facturables casi de inmediato, aunque también puede provocar la pérdida de datos en servicios que no toleran quedarse sin facturación. Úsalo con conocimiento de causa.

Las etiquetas (labels) son pares clave-valor que se pueden aplicar a proyectos y a la mayoría de recursos. Su superpoder es que aparecen en los informes de facturación y en la exportación a BigQuery, lo que permite responder preguntas como "¿cuánto nos costó el entorno de desarrollo el mes pasado?" o "¿qué gasta el equipo de datos?".

Reglas de formato:

• Clave y valor en minúsculas, con números, guiones y guiones bajos.
• Máximo 63 caracteres cada uno; hasta 64 etiquetas por recurso.
• La clave no puede estar vacía; el valor sí.

Un esquema de etiquetado razonable para AlpinaShop:

Consejos sobre etiquetado, aprendidos por la vía dolorosa en muchos equipos:

• Define el esquema antes de empezar a crear recursos. Etiquetar 300 recursos a posteriori es un proyecto en sí mismo.
• Sé estricto con los valores. dev, desarrollo y Desarrollo son tres etiquetas distintas y romperán tus informes.
• No pongas información sensible en las etiquetas. Son visibles para cualquiera con permisos de lectura sobre el recurso.
• No confundas labels con tags. Google Cloud tiene además unas tags (etiquetas con gobernanza) que sirven para aplicar políticas condicionalmente, no para facturación. Se ven en la lección 07-07.

En la consola, Facturación → Informes ofrece una vista interactiva del gasto con filtros por proyecto, servicio, SKU, región, etiquetas y periodo, y agrupación configurable. Es donde se responden la mayoría de preguntas cotidianas.

Conceptos que aparecen en esos informes y conviene distinguir:

Un consejo muy concreto: cuando el gasto no cuadre, agrupa por SKU, no por servicio. "Compute Engine: 210 €" no dice nada; "Storage PD Capacity: 140 €" te dice que tienes discos huérfanos.

Los informes de la consola son cómodos pero limitados. Para análisis serio, Google permite exportar los datos de facturación a un dataset de BigQuery, donde llegan con detalle diario por SKU, proyecto, etiqueta y región, y donde se pueden consultar con SQL.

Se activa en Facturación → Exportación de facturación, eligiendo el proyecto y el dataset de destino. AlpinaShop la enviará al dataset alpinashop_analitica del proyecto alpinashop-datos, para que Lucía pueda cruzar el gasto con datos de negocio.

Dos advertencias:

• La exportación no es retroactiva: solo trae datos desde el momento en que la activas. Es otro motivo para configurarla pronto aunque todavía no la vayas a usar.
• Los datos tardan varias horas en aparecer y se corrigen durante el mes, así que no sirven para alertas en tiempo real.

El análisis con SQL de esos datos corresponde a la lección 04-01 (BigQuery) y su uso para optimizar costes a la 07-05. Aquí basta con activarla.

Ya creamos un presupuesto básico en la lección 01-02. Ahora podemos aprovechar la jerarquía y las etiquetas para afinarlo:

Puntos a destacar del comando:

• --filter-labels limita el presupuesto al gasto de los recursos con esa etiqueta, en lugar de a un proyecto concreto. Es más flexible: si mañana hay tres proyectos de desarrollo, el presupuesto los cubre todos sin tocar nada.
• basis=forecasted-spend cambia la naturaleza del aviso: en lugar de avisarte cuando ya has gastado el 90 %, te avisa cuando la proyección de fin de mes alcanza ese porcentaje. Da días de margen en lugar de horas.
• Recuerda de la lección 01-02: los presupuestos avisan, no bloquean.

Según la versión del SDK, este grupo de comandos puede requerir el prefijo alpha (gcloud alpha billing budgets ...). Comprueba con gcloud billing budgets --help.

La jerarquía existe, sobre todo, para que las políticas se apliquen una vez y cubran todo lo que hay debajo. Hay dos tipos de política y ambas se heredan:

Reglas de herencia que hay que entender bien:

• Los permisos de IAM se acumulan hacia abajo y no se pueden restar. Si concedes a alguien el rol de editor a nivel de organización, lo será en todos los proyectos, y no puedes quitárselo en uno concreto mediante IAM. Por eso conceder roles amplios en niveles altos es peligroso.
• Las políticas de organización sí restringen. Son la herramienta correcta para prohibir cosas, y por defecto una política definida en un nodo sustituye o se combina con la heredada según su configuración.
• La regla práctica: concede permisos en el nivel más bajo posible y restricciones en el más alto posible.

Ambos temas se estudian a fondo más adelante: IAM en la lección 03-04 y las políticas de organización y el gobierno a escala en la 07-07. Lo que necesitas retener ahora es que el sitio donde colocas un proyecto en la jerarquía determina qué hereda, y por eso mover un proyecto entre carpetas cambia sus políticas efectivas.

Sobre el último punto: existe una escuela que defiende un proyecto por microservicio y entorno. Para una organización grande con equipos autónomos puede tener sentido; para AlpinaShop sería una carga de mantenimiento desproporcionada. La estructura debe ser proporcional al tamaño del equipo. Cuatro proyectos para 40 personas es razonable; cuarenta no lo sería.

Marta va a montar la estructura de AlpinaShop desde Cloud Shell. Este bloque reúne todo lo visto.

gcloud organizations list devuelve las organizaciones sobre las que tienes permisos. Con --format="value(ID)" extraemos solo el identificador numérico, sin cabeceras, para poder guardarlo en una variable. Si la salida está vacía, no tienes organización (cuenta personal) y deberás saltarte los pasos de carpetas.

Aquí aparecen por primera vez juntos --filter y --format. --filter="displayName=desarrollo" reduce la lista a la carpeta que nos interesa, y --format="value(name)" extrae únicamente su identificador. Es el patrón de scripting que usaremos durante todo el curso.

Si el proyecto ya existía de la lección 01-02 sin carpeta, se puede mover en lugar de recrearlo:

El campo parent.type debe mostrar folder y parent.id el identificador de la carpeta de desarrollo. billingEnabled debe ser True: si es False, la vinculación no se completó y prácticamente ninguna API funcionará.

Con esto, AlpinaShop tiene una jerarquía real, un proyecto correctamente ubicado y etiquetado, facturación vinculada y una alarma económica activa.

• Elegir mal el projectId. Es inmutable y global. Adopta la convención empresa-carga-entorno y aplícala sin excepciones.
• Confundir projectId con projectNumber. Cuando una API o un mensaje de error pida uno concreto, dale ese: no son intercambiables en todos los contextos.
• Mezclar desarrollo y producción en un proyecto. El día que alguien borre por error la base de datos equivocada entenderás por qué. Además impide separar cuotas, permisos y coste.
• Conceder roles amplios a nivel de organización o carpeta. Los permisos de IAM se heredan hacia abajo y no se pueden restar en un nivel inferior.
• Etiquetar tarde o de forma inconsistente. Un esquema definido desde el principio y respetado vale más que uno sofisticado y aplicado a medias.
• Activar la exportación de facturación a BigQuery cuando ya la necesitas. No es retroactiva: los meses anteriores están perdidos.
• Suponer que el presupuesto corta el gasto. No lo hace. Sigue siendo un detector de humos.
• Consejo: usa gcloud projects delete para limpiar entornos de prueba. Es la única forma fiable de asegurarte de que no queda nada facturando, y tienes 30 días de margen para arrepentirte.
• Consejo: no crees más proyectos de los que puedas gobernar. Cada uno arrastra permisos, red, cuotas y presupuesto.

AlpinaShop crece y abre una filial en Portugal que operará una tienda propia (alpinashop.pt) con su propia base de datos, pero compartirá el pipeline de CI/CD y el almacén analítico con la matriz. Además, dirección exige poder ver de un vistazo cuánto cuesta cada país por separado.

Diseña la jerarquía resultante (carpetas y proyectos), indica qué etiquetas añadirías y explica en qué nivel colocarías la política que prohíbe crear VMs con IP pública en producción y por qué.

Responde razonadamente:

1. Marta se ha equivocado y ha creado el proyecto con el ID alpinshop-dev (falta una a). ¿Puede corregirlo? ¿Qué opciones tiene?
2. Dani ve en un log el correo [email protected]. ¿Qué es ese número y cómo comprobaría a qué proyecto pertenece?
3. Marta quiere que el gasto del proyecto alpinashop-dev deje de producirse de forma inmediata porque un proceso se ha descontrolado. ¿Qué comando ejecuta y qué riesgo asume?

Escribe un script de bash que cree un proyecto llamado alpinashop-pruebas con estas características, comprobando en cada paso que la operación ha tenido éxito:

• Ubicado en la carpeta desarrollo.
• Etiquetado con entorno=pruebas, equipo=infraestructura y responsable=marta.
• Vinculado a la cuenta de facturación.
• Con un presupuesto de 10 EUR y avisos al 50 %, 90 % (sobre previsión) y 100 %.

Y añade al final el comando que usarías para eliminar por completo ese entorno cuando termines las pruebas.

Solución 1

Una estructura razonable:

Etiquetas: a las ya existentes (entorno, equipo, centro-coste) se añade pais con valores es y pt. Con esa etiqueta, dirección obtiene el desglose por país en los informes de facturación sin necesidad de mirar la jerarquía, y se pueden crear presupuestos por país con --filter-labels=pais=pt.

La política que prohíbe IP públicas se coloca en la carpeta produccion, no en cada proyecto. Motivos: se define una sola vez, se hereda automáticamente por es y pt y por cualquier país que se añada en el futuro, y no afecta a desarrollo, donde esa restricción entorpecería el trabajo. Colocarla en la organización sería excesivo (rompería desarrollo) y colocarla en cada proyecto sería frágil (el próximo proyecto se crearía sin ella).

Solución 2

1. No puede corregirlo. El projectId es inmutable. Sus opciones son: (a) crear un proyecto nuevo con el ID correcto y recrear o migrar los recursos, algo barato si el proyecto está recién creado y prácticamente vacío; o (b) quedarse con el ID erróneo y corregir solo el nombre para mostrar, que sí es editable con gcloud projects update alpinashop-dev --name="...". Dado que el proyecto es joven, lo sensato es recrearlo y borrar el erróneo.
2. Es el projectNumber, el identificador numérico del proyecto, y esa dirección corresponde a la cuenta de servicio predeterminada de Compute Engine de ese proyecto. Para saber a qué proyecto pertenece:

   gcloud projects list --filter="projectNumber=482913057261" \\
     --format="value(projectId)"
   

3. Ejecuta gcloud billing projects unlink alpinashop-dev. Al desvincular la facturación, los servicios de pago dejan de funcionar casi inmediatamente y el gasto se detiene. El riesgo es que algunos servicios no toleran quedarse sin facturación y pueden perder datos o recursos: instancias detenidas, tareas canceladas, y en ciertos casos eliminación de recursos si la situación se prolonga. Es una medida de emergencia, no una forma de "pausar" un proyecto. Una alternativa menos agresiva es identificar y detener el recurso concreto que se ha descontrolado.

Solución 3

Para eliminar por completo el entorno al terminar:

Este único comando elimina el proyecto y todos sus recursos, garantizando que no queda nada generando gasto. El proyecto permanece 30 días en estado DELETE_REQUESTED y puede recuperarse en ese plazo con gcloud projects undelete alpinashop-pruebas.

Esta lección ha establecido el esqueleto sobre el que se apoyará todo lo demás. Hemos recorrido la jerarquía Organización → Carpetas → Proyectos → Recursos y la hemos aplicado a AlpinaShop con las carpetas produccion, desarrollo y compartido; hemos distinguido los tres identificadores de un proyecto y grabado que el projectId es inmutable y único en todo Google Cloud; hemos visto que el proyecto es simultáneamente frontera de facturación, cuotas, permisos y red, y que borrarlo es la forma más fiable de limpiar un entorno; hemos entendido las cuentas de facturación, su relación N a 1 con los proyectos, quién puede vincularlas y qué significa unlink como corte de emergencia; hemos definido un esquema de etiquetas para repartir el gasto por entorno, equipo y centro de coste; hemos activado la exportación a BigQuery hacia alpinashop_analitica y afinado los presupuestos con avisos sobre previsión; y hemos repasado cómo se hereda cada tipo de política y qué estructura de proyectos es proporcional a una empresa de 40 personas.

Sabemos ya quién es dueño de qué y quién paga. Falta la otra coordenada: dónde viven los recursos. En la próxima lección, Regiones, zonas y modelo de responsabilidad compartida, veremos la geografía de Google Cloud —multirregión, región y zona—, qué significa que un servicio sea zonal, regional o global, cómo funciona la red troncal privada de Google, qué criterios llevan a AlpinaShop a decidir entre europe-west1 y europe-southwest1 (latencia, precio, servicios disponibles y residencia del dato bajo el RGPD), qué protege realmente desplegar en varias zonas, y cómo se reparte la responsabilidad de seguridad entre Google y tú según el tipo de servicio.