Obrir un compte a Google Cloud costa deu minuts, però fer-ho bé marca la diferència entre un entorn que creix de manera ordenada i un que al cap de sis mesos és impossible d'auditar. En aquesta lliçó Marta dona d'alta AlpinaShop a Google Cloud: veurem què necessites abans de començar, què inclou realment el nivell gratuït (i què no), per què una empresa no hauria de construir el seu núvol sobre un compte de Gmail personal, com es creen el compte de facturació i el primer projecte alpinashop-dev, com s'activen les APIs dels serveis i —el més important— com es posen pressupostos i alertes de facturació abans d'encendre el primer recurs.

Aquesta darrera part no és opcional. La història de terror clàssica del núvol és la factura inesperada de quatre xifres per alguna cosa que es va deixar encesa. S'evita amb quinze minuts de configuració el dia u.

1. Requisits previs
2. El nivell gratuït: crèdit de prova i «Always Free»
3. Compte personal davant de Cloud Identity o Workspace
4. Crear el compte de facturació i el projecte alpinashop-dev
5. Activar les APIs dels serveis
6. Pressupostos i alertes de facturació des del dia 1
7. Higiene de seguretat del compte inicial

Per crear un compte de Google Cloud necessites tres coses:

Punts que solen generar dubtes:

• Em cobraran sense avisar durant la prova gratuïta? No. Mentre ets al període de prova amb crèdit, Google no cobra automàticament quan s'esgota: els recursos s'aturen i has d'activar manualment el compte de pagament. És un comportament deliberat per evitar ensurts. Tot i així, un cop activat el compte de pagament, la facturació és real i sense sostre: d'aquí els pressupostos de l'apartat 6.
• Serveix una targeta prepagament o virtual? Depèn de l'emissor. Google exigeix que admeti càrrecs recurrents; moltes prepagament són rebutjades. Les targetes virtuals de bancs espanyols solen funcionar si no són d'un sol ús.
• Es pot fer servir un compte d'empresa des del principi? Sí, i és el recomanable per a una organització. Ho veiem a l'apartat 3.

Google Cloud combina dos mecanismes gratuïts diferents que es confonen sovint:

En registrar-te per primera vegada reps un crèdit (històricament al voltant de 300 USD) vàlid durant uns 90 dies. És més que suficient per seguir aquest curs sencer si ets ordenat apagant recursos. Es consumeix en qualsevol servei de pagament, incloent-hi les VMs i BigQuery.

Independentment del crèdit, hi ha serveis amb una quota gratuïta permanent. Aquests són exemples representatius, els límits exactes dels quals has de verificar a la pàgina oficial de nivell gratuït perquè canvien:

Dos matisos importants:

• La restricció geogràfica de l'Always Free de Compute Engine i Cloud Storage és real. La e2-micro gratuïta només existeix en certes regions dels EUA. Com que AlpinaShop treballarà a europe-west1 per latència i residència de la dada, les seves VMs no seran gratuïtes. És una decisió conscient: per a una empresa espanyola, estalviar uns euros a costa de servir des d'Iowa no compensa.
• El nivell gratuït no cobreix el trànsit de sortida ni les adreces IP externes reservades sense fer servir. Tots dos són fonts habituals de càrrecs petits però constants.

Verifica sempre. Les xifres anteriors són ordres de magnitud a data d'escriptura del curs. Els límits del nivell gratuït, els preus i les regions incloses canvien. Consulta la documentació oficial de preus i de nivell gratuït abans de donar per fet que una cosa és gratis.

Aquí hi ha la decisió més estructural d'aquesta lliçó, i la que surt més cara de corregir després.

Quan et registres amb un compte @gmail.com, Google Cloud crea els teus projectes sense organització: projectes solts, propietat d'una persona física, sense jerarquia ni polítiques centrals.

Cloud Identity és la peça clau i poc coneguda: és un servei de gestió d'identitats que et dona usuaris i grups corporatius vinculats al teu domini sense necessitat de contractar Google Workspace (és a dir, sense pagar per Gmail ni Drive corporatius). La seva versió gratuïta cobreix un nombre limitat d'usuaris, més que suficient per a una pime de 40 persones com AlpinaShop, i és el que habilita el node Organització.

Marta registra el domini alpinashop.example a Cloud Identity, verifica la propietat del domini mitjançant un registre DNS de tipus TXT, i crea usuaris corporatius:

• [email protected] (infraestructura)
• [email protected] (desenvolupament)
• [email protected] (dades)

En fer-ho, apareix automàticament el node Organització alpinashop.example, i tots els projectes que es creïn a partir d'aquell moment en penjaran. La jerarquia completa (Organització → Carpetes → Projectes) és el tema de la lliçó 01-04.

Si segueixes el curs a títol personal amb un compte de Gmail, ho pots fer tot igualment: simplement no tindràs node Organització ni carpetes. Quan una lliçó faci servir carpetes, s'indicarà l'alternativa.

Un compte de facturació és l'objecte que defineix qui paga i amb quin mètode. No és el mateix que un projecte: els projectes consumeixen recursos, el compte de facturació els paga. Un projecte sense compte de facturació vinculat només pot fer servir serveis gratuïts, i la majoria d'APIs es negaran a activar-se.

El camí a la consola és directe:

1. Entra a console.cloud.google.com amb el compte corporatiu.
2. Menú de navegació → Facturació → Crear compte. Indica país (Espanya), tipus de compte (empresa), dades fiscals (CIF) i mètode de pagament.
3. Menú superior → selector de projecte → Projecte nou. Nom: alpinashop-dev.
4. Comprova l'ID de projecte que proposa la consola. El nom és editable després; l'ID no.

Aquest darrer punt mereix èmfasi perquè és irreversible: l'ID de projecte (projectId) és únic a tot Google Cloud, no només a la teva organització, i no es pot canviar mai. Si alpinashop-dev estigués ocupat per un altre client de Google al món, la consola proposaria una cosa com alpinashop-dev-482913. Tria l'ID amb cura. La diferència entre projectId, projectNumber i nom s'explica a fons a la lliçó 01-04.

Els mateixos passos amb gcloud (l'eina s'explica en detall a la lliçó 01-06; aquí només la fem servir com a referència del que passa per sota):

Desglossament del que fa cada comanda:

• gcloud billing accounts list consulta els comptes de facturació sobre els quals el teu usuari té permisos. Retorna l'ACCOUNT_ID, que necessites al pas 3. Si la llista surt buida, o no has creat el compte de facturació o el teu usuari no té el rol per veure'l.
• gcloud projects create crea el projecte. L'argument posicional alpinashop-dev és el projectId definitiu; --name és només l'etiqueta visible.
• gcloud billing projects link associa projecte i compte de facturació. Requereix el permís billing.resourceAssociations.create sobre el compte de facturació i ser propietari del projecte: és a dir, no n'hi ha prou de ser administrador del projecte, cal tenir també permís sobre la facturació. És una separació de responsabilitats deliberada.
• gcloud config set project desa el projecte actiu a la teva configuració local.

A Google Cloud, cada servei s'exposa com una API, i les APIs venen desactivades per defecte a cada projecte nou. És una mesura de seguretat i de claredat: redueix la superfície exposada i fa explícit què fa servir realment cada projecte.

Si intentes crear una VM sense haver activat compute.googleapis.com, la consola t'oferirà activar-la i la CLI retornarà un error del tipus "API has not been used in project ... before or it is disabled".

Notes pràctiques:

• L'activació pot trigar uns segons a propagar-se. Si just després d'activar una API una comanda falla, espera mig minut i torna-ho a provar abans de suposar que hi ha un problema real.
• Activar una API no costa diners; costa fer-la servir. Tot i així, no activis per sistema tot el catàleg: cada API activa és superfície d'atac i soroll a l'auditoria.
• L'API cloudresourcemanager.googleapis.com i cloudbilling.googleapis.com solen ser necessàries per gestionar projectes i pressupostos mitjançant scripts.

Aquest és l'apartat que no t'has de saltar. Un pressupost a Google Cloud és un objecte que vigila la despesa i avisa en superar llindars. Convé entendre bé què fa i què no:

• Sí: envia notificacions per correu als administradors de facturació en assolir els llindars que defineixis, i pot publicar un missatge en un topic de Pub/Sub per automatitzar reaccions.
• No: no apaga recursos ni bloqueja la despesa per si mateix. Un pressupost de 50 € no impedeix gastar 500 €. És un detector de fums, no un extintor.

Per arribar a apagar recursos automàticament cal combinar el pressupost amb Pub/Sub i una Cloud Function que desvinculi la facturació, cosa que s'aborda a la lliçó 07-05.

Explicació de cada opció, perquè cadascuna té una conseqüència:

• --billing-account: els pressupostos pengen del compte de facturació, no del projecte. Per això cal el rol d'administrador de facturació per crear-los.
• --budget-amount=50EUR: l'import de referència. També existeix l'opció de basar el pressupost en la despesa del mes anterior, útil quan el consum és estable.
• --threshold-rule=percent=...: cada regla genera un avís. Posar-ne tres és una bona pràctica: el 50 % t'informa, el 90 % t'alerta i el 100 % t'obliga a actuar. S'hi pot afegir basis=forecasted-spend per avisar quan la previsió de final de mes superi el llindar, cosa que dona marge de reacció.
• --filter-projects: limita el pressupost a un projecte concret. Sense aquest filtre, el pressupost vigila la despesa de tot el compte de facturació.

Segons la versió del SDK que tinguis instal·lada, aquest grup de comandes pot viure sota gcloud billing budgets o requerir la via gcloud alpha billing budgets. Si la comanda no existeix, prova amb el prefix alpha o consulta gcloud billing budgets --help.

Per a AlpinaShop, Marta deixa muntat des del primer dia:

I un costum igual de valuós que qualsevol configuració: revisar els informes de facturació un cop per setmana durant els primers mesos. Es troben a Facturació → Informes, amb desglossament per projecte, servei i SKU. L'anàlisi a fons d'aquests informes és el tema de la lliçó 01-04.

El primer compte que crea l'organització acumula un poder enorme: pot crear projectes, vincular facturació i concedir permisos a qualsevol. Tractar-lo com un compte de treball normal és un risc innecessari.

Bones pràctiques des del minut u:

1. Verificació en dos passos obligatòria. Activa-la per a tots els comptes de l'organització, i fes servir preferentment una clau de seguretat física o l'app d'autenticació, no SMS. Google permet imposar-la com a política per a tot el domini des de la consola d'administració.
2. No treballar diàriament amb el compte superadministrador. Marta ha de tenir dues identitats: el seu compte normal [email protected], amb els permisos que necessita per a la seva feina, i un compte de superadministrador que només es fa servir per a tasques excepcionals (crear l'organització, recuperar accessos).
3. Com a mínim dos superadministradors. Si només n'hi ha un i perd l'accés o deixa l'empresa, la recuperació és lenta i dolorosa. Dos és el mínim raonable; tres si l'equip ho permet.
4. Compte de recuperació i dades de contacte actualitzades, amb un correu alternatiu que no depengui del propi domini.
5. Principi de mínim privilegi des del principi. Dani no necessita ser propietari del projecte per desplegar; Lucía no necessita permisos de xarxa per consultar dades. Concedir «Propietari» a tothom «perquè no doni problemes» és còmode avui i molt car d'aquí a un any. El detall de rols i polítiques d'IAM s'estudia a la lliçó 03-04.
6. Permisos per grups, no per persones. Crea grups com [email protected] o [email protected] i concedeix els permisos al grup. Quan algú entri o surti, es canvia la pertinença al grup i no cal tocar cap política.
7. No comparteixis mai credencials. Si dues persones necessiten el mateix, es concedeix a dues identitats, no es comparteix una.

• Construir el núvol de l'empresa sobre un compte de Gmail personal. Migrar després a una organització és possible però tediós: cal moure projectes, refer permisos i transferir facturació. Si el núvol és per a una empresa, comença amb Cloud Identity.
• Confondre crèdit de prova amb Always Free. Quan s'esgoti el crèdit, el que continuï corrent es factura llevat que estigui dins de les quotes Always Free, que són petites i moltes vegades limitades a regions dels EUA.
• Creure que un pressupost atura la despesa. No ho fa. Només avisa.
• Crear el pressupost «quan ja hi hagi alguna cosa desplegada». La despesa sorpresa apareix justament als primers experiments, que és quan encara no se sap què costa cada cosa.
• Triar un projectId poc pensat. És immutable i global. Adopta una convenció (empresa-entorn, empresa-carrega-entorn) i respecta-la.
• Oblidar recursos «invisibles». Discos persistents de VMs esborrades, IP externes reservades sense associar, snapshots antics i balancejadors orfes generen càrrecs encara que no hi hagi res «encès».
• Consell: crea primer alpinashop-dev i només després alpinashop-prod. Aprendre al projecte on no hi ha clients és més barat en tots els sentits.
• Consell: activa les APIs a mesura que les necessitis, no totes de cop. La llista d'APIs actives és una bona documentació implícita de què fa servir realment el projecte.

Marta dubta entre tres opcions per donar d'alta AlpinaShop a Google Cloud:

• A) Fer servir el seu Gmail personal [email protected] per crear els projectes.
• B) Contractar Google Workspace complet per a les 40 persones de l'empresa.
• C) Registrar el domini alpinashop.example a Cloud Identity Free i crear-hi les identitats de l'equip tècnic.

Argumenta quina triaries, quina conseqüència concreta té cada opció quan d'aquí a dos anys Marta canviï d'empresa, i en quin cas l'opció B seria la correcta.

Escriu les comandes necessàries per:

1. Localitzar l'ID del compte de facturació d'AlpinaShop.
2. Crear un pressupost anomenat Presupuesto AlpinaShop Desarrollo de 30 euros mensuals aplicat únicament al projecte alpinashop-dev, amb avisos al 60 %, 90 % i 100 %.
3. Verificar que s'ha creat.

Després respon: si el projecte arriba a gastar 200 €, què haurà fet el pressupost?

Un consultor extern revisa la configuració inicial d'una altra empresa i troba aquesta situació:

• Hi ha un únic superadministrador, que a més fa servir aquest compte per al correu diari.
• La verificació en dos passos està desactivada.
• Els cinc desenvolupadors tenen el rol de Propietari a tots els projectes «per agilitzar».
• No hi ha cap pressupost configurat.
• El correu de recuperació del compte d'administrador és el mateix compte corporatiu.

Enumera els riscos concrets de cada punt i la correcció que proposaries, ordenats de més urgent a menys.

Solució 1

L'opció correcta per a AlpinaShop és la C.

• Amb l'opció A, els projectes pertanyen a una persona física. Quan Marta se'n vagi, l'empresa es troba amb recursos la propietat dels quals cal transferir manualment un a un, sense node Organització, sense carpetes, sense polítiques centrals i sense registres d'auditoria corporatius. És un risc de continuïtat de negoci, no només una incomoditat.
• Amb l'opció C, l'organització alpinashop.example és la propietària de tot. En marxar Marta, se suspèn el seu usuari i els recursos continuen intactes i accessibles per a la resta. Cloud Identity Free cobreix sense cost els usuaris que l'equip tècnic necessita.
• L'opció B seria la correcta si AlpinaShop volgués a més el correu, el calendari i l'emmagatzematge corporatius de Google (és a dir, si la decisió fos de lloc de treball, no només de núvol). Contractar Workspace només per poder fer servir Google Cloud és pagar de més: Cloud Identity ja aporta el node Organització.

Solució 2

Si el projecte arriba a gastar 200 €, el pressupost haurà enviat tres correus d'avís (en superar 18 €, 27 € i 30 €) i res més: la despesa haurà continuat sense obstacle fins als 200 €. El pressupost avisa, no bloqueja. Per aturar la despesa automàticament cal connectar el pressupost a un topic de Pub/Sub i a una funció que hi reaccioni, cosa que es veu a la lliçó 07-05.

Solució 3

Per ordre d'urgència:

1. Verificació en dos passos desactivada. És el risc més greu: una contrasenya filtrada dona control total sobre tot el núvol de l'empresa. Correcció immediata: activar 2FA per a tots els comptes i imposar-la com a política de domini, preferiblement amb clau física per als administradors.
2. Cinc propietaris i cap control de privilegis. El rol Propietari permet esborrar projectes sencers i modificar permisos. Qualsevol error o compte compromès és catastròfic. Correcció: aplicar mínim privilegi amb rols específics, concedits a grups i no a persones.
3. Un únic superadministrador que a més fa servir el compte diàriament. Risc doble: punt únic de fallada si perd l'accés, i exposició constant del compte més poderós al correu i la navegació quotidians. Correcció: crear un segon superadministrador i un compte de treball diari amb permisos normals.
4. Correu de recuperació dins del mateix domini. Si es perd l'accés al domini, es perd també la via de recuperació. Correcció: configurar un correu alternatiu extern i un telèfon de recuperació.
5. Sense pressupostos. És un risc econòmic, no de seguretat, i per això va l'últim, però és el més fàcil de corregir: quinze minuts per crear pressupostos amb alertes a més d'un destinatari.

Ja tenim compte. En aquesta lliçó hem vist els requisits previs de l'alta, la diferència real entre el crèdit de prova i les quotes Always Free (amb l'advertiment que moltes d'elles només existeixen en regions dels EUA i no a europe-west1), i per què una empresa com AlpinaShop s'ha de recolzar en Cloud Identity sobre el domini alpinashop.example en lloc de en comptes personals. Hem creat el compte de facturació i el projecte alpinashop-dev, entenent que el projectId és immutable i global; hem activat les APIs dels serveis que farem servir; hem muntat pressupostos amb alertes al 50, 90 i 100 %, sabent que avisen però no bloquegen; i hem establert la higiene mínima del compte: doble factor, dos superadministradors, comptes separats per al treball diari i permisos per grups.

Marta ja té un projecte buit i una xarxa de seguretat econòmica. El següent és aprendre a moure's per l'entorn: a la propera lliçó, Descripció general de la consola de GCP, recorrerem la interfície web peça a peça —selector de projecte, menú de navegació, cercador, quotes, tauler d'APIs i serveis—, coneixerem de vista Cloud Shell i el seu editor, i compararem les tres maneres de treballar amb GCP (consola, CLI i biblioteques client) per saber quan convé cadascuna. Marta deixarà el projecte alpinashop-dev preparat amb els seus serveis preferits a mà.