Abrir una cuenta en Google Cloud lleva diez minutos, pero hacerlo bien marca la diferencia entre un entorno que crece de forma ordenada y uno que a los seis meses es imposible de auditar. En esta lección Marta da de alta AlpinaShop en Google Cloud: veremos qué necesitas antes de empezar, qué incluye realmente el nivel gratuito (y qué no), por qué una empresa no debería construir su nube sobre una cuenta de Gmail personal, cómo se crean la cuenta de facturación y el primer proyecto alpinashop-dev, cómo se activan las APIs de los servicios y —lo más importante— cómo se ponen presupuestos y alertas de facturación antes de encender el primer recurso.

Esa última parte no es opcional. La historia de terror clásica de la nube es la factura inesperada de cuatro cifras por algo que se dejó encendido. Se evita con quince minutos de configuración el día uno.

1. Requisitos previos
2. El nivel gratuito: crédito de prueba y "Always Free"
3. Cuenta personal frente a Cloud Identity o Workspace
4. Crear la cuenta de facturación y el proyecto alpinashop-dev
5. Activar las APIs de los servicios
6. Presupuestos y alertas de facturación desde el día 1
7. Higiene de seguridad de la cuenta inicial

Para crear una cuenta de Google Cloud necesitas tres cosas:

Puntos que suelen generar dudas:

• ¿Me van a cobrar sin avisar durante la prueba gratuita? No. Mientras estás en el periodo de prueba con crédito, Google no cobra automáticamente al agotarse: los recursos se detienen y debes activar manualmente la cuenta de pago. Es un comportamiento deliberado para evitar sustos. Aun así, una vez activada la cuenta de pago, la facturación es real y sin techo: de ahí los presupuestos del apartado 6.
• ¿Vale una tarjeta prepago o virtual? Depende del emisor. Google exige que admita cargos recurrentes; muchas prepago son rechazadas. Las tarjetas virtuales de bancos españoles suelen funcionar si no son de un solo uso.
• ¿Se puede usar cuenta de empresa desde el principio? Sí, y es lo recomendable para una organización. Lo vemos en el apartado 3.

Google Cloud combina dos mecanismos gratuitos distintos que se confunden con frecuencia:

Al registrarte por primera vez recibes un crédito (históricamente en torno a 300 USD) válido durante unos 90 días. Es más que suficiente para seguir este curso entero si eres ordenado apagando recursos. Se consume en cualquier servicio de pago, incluidas las VMs y BigQuery.

Independientemente del crédito, hay servicios con una cuota gratuita permanente. Estos son ejemplos representativos, cuyos límites exactos debes verificar en la página oficial de nivel gratuito porque cambian:

Dos matices importantes:

• La restricción geográfica del Always Free de Compute Engine y Cloud Storage es real. La e2-micro gratuita solo existe en ciertas regiones de EE. UU. Como AlpinaShop trabajará en europe-west1 por latencia y residencia del dato, sus VMs no serán gratuitas. Es una decisión consciente: para una empresa española, ahorrar unos euros a costa de servir desde Iowa no compensa.
• El nivel gratuito no cubre el tráfico de salida ni las direcciones IP externas reservadas sin usar. Ambos son fuentes habituales de cargos pequeños pero constantes.

Verifica siempre. Las cifras anteriores son órdenes de magnitud a fecha de escritura del curso. Los límites del nivel gratuito, los precios y las regiones incluidas cambian. Consulta la documentación oficial de precios y de nivel gratuito antes de dar por hecho que algo es gratis.

Aquí está la decisión más estructural de esta lección, y la que más caro sale corregir después.

Cuando te registras con una cuenta @gmail.com, Google Cloud crea tus proyectos sin organización: proyectos sueltos, propiedad de una persona física, sin jerarquía ni políticas centrales.

Cloud Identity es la pieza clave y poco conocida: es un servicio de gestión de identidades que te da usuarios y grupos corporativos vinculados a tu dominio sin necesidad de contratar Google Workspace (es decir, sin pagar por Gmail ni Drive corporativos). Su versión gratuita cubre un número limitado de usuarios, más que suficiente para una pyme de 40 personas como AlpinaShop, y es lo que habilita el nodo Organización.

Marta registra el dominio alpinashop.example en Cloud Identity, verifica la propiedad del dominio mediante un registro DNS de tipo TXT, y crea usuarios corporativos:

• [email protected] (infraestructura)
• [email protected] (desarrollo)
• [email protected] (datos)

Al hacerlo, aparece automáticamente el nodo Organización alpinashop.example, y todos los proyectos que se creen a partir de ese momento colgarán de él. La jerarquía completa (Organización → Carpetas → Proyectos) es el tema de la lección 01-04.

Si estás siguiendo el curso a título personal con una cuenta de Gmail, puedes hacerlo todo igualmente: simplemente no tendrás nodo Organización ni carpetas. Cuando una lección use carpetas, se indicará la alternativa.

Una cuenta de facturación es el objeto que define quién paga y con qué método. No es lo mismo que un proyecto: los proyectos consumen recursos, la cuenta de facturación los paga. Un proyecto sin cuenta de facturación vinculada solo puede usar servicios gratuitos, y la mayoría de APIs se negarán a activarse.

El camino en la consola es directo:

1. Entra en console.cloud.google.com con la cuenta corporativa.
2. Menú de navegación → Facturación → Crear cuenta. Indica país (España), tipo de cuenta (empresa), datos fiscales (CIF) y método de pago.
3. Menú superior → selector de proyecto → Proyecto nuevo. Nombre: alpinashop-dev.
4. Comprueba el ID de proyecto que propone la consola. El nombre es editable después; el ID no.

Ese último punto merece énfasis porque es irreversible: el ID de proyecto (projectId) es único en todo Google Cloud, no solo en tu organización, y no se puede cambiar nunca. Si alpinashop-dev estuviera ocupado por otro cliente de Google en el mundo, la consola propondría algo como alpinashop-dev-482913. Elige el ID con cuidado. La diferencia entre projectId, projectNumber y nombre se explica a fondo en la lección 01-04.

Los mismos pasos con gcloud (la herramienta se explica en detalle en la lección 01-06; aquí solo la usamos como referencia de lo que ocurre por debajo):

Desglose de lo que hace cada comando:

• gcloud billing accounts list consulta las cuentas de facturación sobre las que tu usuario tiene permisos. Devuelve el ACCOUNT_ID, que necesitas en el paso 3. Si la lista sale vacía, o no has creado la cuenta de facturación o tu usuario no tiene el rol para verla.
• gcloud projects create crea el proyecto. El argumento posicional alpinashop-dev es el projectId definitivo; --name es solo la etiqueta visible.
• gcloud billing projects link asocia proyecto y cuenta de facturación. Requiere el permiso billing.resourceAssociations.create sobre la cuenta de facturación y ser propietario del proyecto: es decir, no basta con ser administrador del proyecto, hay que tener también permiso sobre la facturación. Es una separación de responsabilidades deliberada.
• gcloud config set project guarda el proyecto activo en tu configuración local.

En Google Cloud, cada servicio se expone como una API, y las APIs vienen desactivadas por defecto en cada proyecto nuevo. Es una medida de seguridad y de claridad: reduce la superficie expuesta y hace explícito qué usa realmente cada proyecto.

Si intentas crear una VM sin haber activado compute.googleapis.com, la consola te ofrecerá activarla y la CLI devolverá un error del tipo "API has not been used in project ... before or it is disabled".

Notas prácticas:

• La activación puede tardar unos segundos en propagarse. Si justo después de activar una API un comando falla, espera medio minuto y reinténtalo antes de suponer que hay un problema real.
• Activar una API no cuesta dinero; cuesta usarla. Aun así, no actives por sistema todo el catálogo: cada API activa es superficie de ataque y ruido en la auditoría.
• La API cloudresourcemanager.googleapis.com y cloudbilling.googleapis.com suelen ser necesarias para gestionar proyectos y presupuestos mediante scripts.

Este es el apartado que no debes saltarte. Un presupuesto en Google Cloud es un objeto que vigila el gasto y avisa al superar umbrales. Conviene entender bien qué hace y qué no:

• Sí: envía notificaciones por correo a los administradores de facturación al alcanzar los umbrales que definas, y puede publicar un mensaje en un topic de Pub/Sub para automatizar reacciones.
• No: no apaga recursos ni bloquea el gasto por sí mismo. Un presupuesto de 50 € no impide gastar 500 €. Es un detector de humos, no un extintor.

Para llegar a apagar recursos automáticamente hay que combinar el presupuesto con Pub/Sub y una Cloud Function que desvincule la facturación, algo que se aborda en la lección 07-05.

Explicación de cada opción, porque cada una tiene una consecuencia:

• --billing-account: los presupuestos cuelgan de la cuenta de facturación, no del proyecto. Por eso hace falta el rol de administrador de facturación para crearlos.
• --budget-amount=50EUR: el importe de referencia. También existe la opción de basar el presupuesto en el gasto del mes anterior, útil cuando el consumo es estable.
• --threshold-rule=percent=...: cada regla genera un aviso. Poner tres es una buena práctica: el 50 % te informa, el 90 % te alerta y el 100 % te obliga a actuar. Se puede añadir basis=forecasted-spend para avisar cuando la previsión de fin de mes supere el umbral, lo que da margen de reacción.
• --filter-projects: limita el presupuesto a un proyecto concreto. Sin este filtro, el presupuesto vigila el gasto de toda la cuenta de facturación.

Según la versión del SDK que tengas instalada, este grupo de comandos puede vivir bajo gcloud billing budgets o requerir la vía gcloud alpha billing budgets. Si el comando no existe, prueba con el prefijo alpha o consulta gcloud billing budgets --help.

Para AlpinaShop, Marta deja montado desde el primer día:

Y una costumbre igual de valiosa que cualquier configuración: revisar los informes de facturación una vez por semana durante los primeros meses. Se encuentran en Facturación → Informes, con desglose por proyecto, servicio y SKU. El análisis a fondo de esos informes es el tema de la lección 01-04.

La primera cuenta que crea la organización acumula un poder enorme: puede crear proyectos, vincular facturación y conceder permisos a cualquiera. Tratarla como una cuenta de trabajo normal es un riesgo innecesario.

Buenas prácticas desde el minuto uno:

1. Verificación en dos pasos obligatoria. Actívala para todas las cuentas de la organización, y usa preferentemente una llave de seguridad física o la app de autenticación, no SMS. Google permite imponerla como política para todo el dominio desde la consola de administración.
2. No trabajar a diario con la cuenta superadministradora. Marta debe tener dos identidades: su cuenta normal [email protected], con los permisos que necesita para su trabajo, y una cuenta de superadministrador que solo se usa para tareas excepcionales (crear la organización, recuperar accesos).
3. Al menos dos superadministradores. Si solo hay uno y pierde el acceso o deja la empresa, la recuperación es lenta y dolorosa. Dos es el mínimo razonable; tres si el equipo lo permite.
4. Cuenta de recuperación y datos de contacto actualizados, con un correo alternativo que no dependa del propio dominio.
5. Principio de mínimo privilegio desde el principio. Dani no necesita ser propietario del proyecto para desplegar; Lucía no necesita permisos de red para consultar datos. Conceder "Propietario" a todo el mundo "para que no dé problemas" es cómodo hoy y muy caro dentro de un año. El detalle de roles y políticas de IAM se estudia en la lección 03-04.
6. Permisos por grupos, no por personas. Crea grupos como [email protected] o [email protected] y concede los permisos al grupo. Cuando alguien entre o salga, se cambia la pertenencia al grupo y no hay que tocar ninguna política.
7. Nunca compartas credenciales. Si dos personas necesitan lo mismo, se conceden a dos identidades, no se comparte una.

• Construir la nube de la empresa sobre una cuenta de Gmail personal. Migrar después a una organización es posible pero tedioso: hay que mover proyectos, rehacer permisos y transferir facturación. Si la nube es para una empresa, empieza con Cloud Identity.
• Confundir crédito de prueba con Always Free. Cuando se agote el crédito, lo que siga corriendo se factura salvo que esté dentro de las cuotas Always Free, que son pequeñas y muchas veces limitadas a regiones de EE. UU.
• Creer que un presupuesto detiene el gasto. No lo hace. Solo avisa.
• Crear el presupuesto "cuando ya haya algo desplegado". El gasto sorpresa aparece justo en los primeros experimentos, que es cuando aún no se sabe qué cuesta cada cosa.
• Elegir un projectId poco pensado. Es inmutable y global. Adopta una convención (empresa-entorno, empresa-carga-entorno) y respétala.
• Olvidar recursos "invisibles". Discos persistentes de VMs borradas, IP externas reservadas sin asociar, snapshots antiguos y balanceadores huérfanos generan cargos aunque no haya nada "encendido".
• Consejo: crea primero alpinashop-dev y solo después alpinashop-prod. Aprender en el proyecto donde no hay clientes es más barato en todos los sentidos.
• Consejo: activa las APIs a medida que las necesites, no todas de golpe. La lista de APIs activas es una buena documentación implícita de qué usa realmente el proyecto.

Marta duda entre tres opciones para dar de alta a AlpinaShop en Google Cloud:

• A) Usar su Gmail personal [email protected] para crear los proyectos.
• B) Contratar Google Workspace completo para las 40 personas de la empresa.
• C) Registrar el dominio alpinashop.example en Cloud Identity Free y crear ahí las identidades del equipo técnico.

Argumenta cuál eligirías, qué consecuencia concreta tiene cada opción cuando dentro de dos años Marta cambie de empresa, y en qué caso la opción B sería la correcta.

Escribe los comandos necesarios para:

1. Localizar el ID de la cuenta de facturación de AlpinaShop.
2. Crear un presupuesto llamado Presupuesto AlpinaShop Desarrollo de 30 euros mensuales aplicado únicamente al proyecto alpinashop-dev, con avisos al 60 %, 90 % y 100 %.
3. Verificar que se ha creado.

Después responde: si el proyecto llega a gastar 200 €, ¿qué habrá hecho el presupuesto?

Un consultor externo revisa la configuración inicial de otra empresa y encuentra esta situación:

• Existe un único superadministrador, que además usa esa cuenta para el correo diario.
• La verificación en dos pasos está desactivada.
• Los cinco desarrolladores tienen el rol de Propietario en todos los proyectos "para agilizar".
• No hay ningún presupuesto configurado.
• El correo de recuperación de la cuenta de administrador es la propia cuenta corporativa.

Enumera los riesgos concretos de cada punto y la corrección que propondrías, ordenados de más urgente a menos.

Solución 1

La opción correcta para AlpinaShop es la C.

• Con la opción A, los proyectos pertenecen a una persona física. Cuando Marta se marche, la empresa se encuentra con recursos cuya propiedad hay que transferir manualmente uno a uno, sin nodo Organización, sin carpetas, sin políticas centrales y sin registros de auditoría corporativos. Es un riesgo de continuidad de negocio, no solo una incomodidad.
• Con la opción C, la organización alpinashop.example es la propietaria de todo. Al marcharse Marta, se suspende su usuario y los recursos siguen intactos y accesibles para el resto. Cloud Identity Free cubre sin coste los usuarios que el equipo técnico necesita.
• La opción B sería la correcta si AlpinaShop quisiera además el correo, el calendario y el almacenamiento corporativos de Google (es decir, si la decisión fuera de puesto de trabajo, no solo de nube). Contratar Workspace solo para poder usar Google Cloud es pagar de más: Cloud Identity ya aporta el nodo Organización.

Solución 2

Si el proyecto llega a gastar 200 €, el presupuesto habrá enviado tres correos de aviso (al superar 18 €, 27 € y 30 €) y nada más: el gasto habrá continuado sin obstáculo hasta los 200 €. El presupuesto avisa, no bloquea. Para detener el gasto automáticamente hay que conectar el presupuesto a un topic de Pub/Sub y a una función que reaccione, algo que se ve en la lección 07-05.

Solución 3

Por orden de urgencia:

1. Verificación en dos pasos desactivada. Es el riesgo más grave: una contraseña filtrada da control total sobre toda la nube de la empresa. Corrección inmediata: activar 2FA para todas las cuentas e imponerla como política de dominio, preferiblemente con llave física para los administradores.
2. Cinco propietarios y ningún control de privilegios. El rol Propietario permite borrar proyectos enteros y modificar permisos. Cualquier error o cuenta comprometida es catastrófico. Corrección: aplicar mínimo privilegio con roles específicos, concedidos a grupos y no a personas.
3. Un único superadministrador que además usa la cuenta a diario. Riesgo doble: punto único de fallo si pierde el acceso, y exposición constante de la cuenta más poderosa al correo y la navegación cotidianos. Corrección: crear un segundo superadministrador y una cuenta de trabajo diaria con permisos normales.
4. Correo de recuperación dentro del propio dominio. Si se pierde el acceso al dominio, se pierde también la vía de recuperación. Corrección: configurar un correo alternativo externo y un teléfono de recuperación.
5. Sin presupuestos. Es un riesgo económico, no de seguridad, y por eso va el último, pero es el más fácil de corregir: quince minutos para crear presupuestos con alertas a más de un destinatario.

Ya tenemos cuenta. En esta lección hemos visto los requisitos previos del alta, la diferencia real entre el crédito de prueba y las cuotas Always Free (con la advertencia de que muchas de ellas solo existen en regiones de EE. UU. y no en europe-west1), y por qué una empresa como AlpinaShop debe apoyarse en Cloud Identity sobre el dominio alpinashop.example en lugar de en cuentas personales. Hemos creado la cuenta de facturación y el proyecto alpinashop-dev, entendiendo que el projectId es inmutable y global; hemos activado las APIs de los servicios que usaremos; hemos montado presupuestos con alertas al 50, 90 y 100 %, sabiendo que avisan pero no bloquean; y hemos establecido la higiene mínima de la cuenta: doble factor, dos superadministradores, cuentas separadas para el trabajo diario y permisos por grupos.

Marta tiene ya un proyecto vacío y una red de seguridad económica. Lo siguiente es aprender a moverse por el entorno: en la próxima lección, Descripción general de la consola de GCP, recorreremos la interfaz web pieza a pieza —selector de proyecto, menú de navegación, buscador, cuotas, panel de APIs y servicios—, conoceremos de vista Cloud Shell y su editor, y compararemos las tres formas de trabajar con GCP (consola, CLI y bibliotecas cliente) para saber cuándo conviene cada una. Marta dejará el proyecto alpinashop-dev preparado con sus servicios favoritos a mano.