If your company runs on Google Workspace, you are further along with Google Cloud than you might think. The users, groups and security settings you manage in the Workspace admin console are the same identities Google Cloud uses. There is no second directory to build and no new passwords for your team.

What you don’t have yet is the structure on the Google Cloud side: who is in charge, who pays, and where things live. Get those three right in the first week and everything you build afterwards has a clean home.

What you already have

• Your domain and users. Everyone with a Workspace account can be given access to Google Cloud. When someone leaves and you suspend them in Workspace, they lose their cloud access too.
• Groups. The groups you manage in Workspace can be given cloud permissions. This is the single most useful thing to carry over.
• Security policies. 2-Step Verification and the other login rules you enforce in Workspace apply when people sign in to Google Cloud.
• An organisation, waiting to be switched on. Google Cloud has a top-level “organization” that sits above every project. For a Workspace customer it is created automatically when a super admin signs in to the Google Cloud console and accepts the terms, or when someone creates the first project or billing account.

Step 1: Take charge of the organisation

The Workspace super admin who creates the organisation is automatically given the Organization Administrator role. That is convenient, but it shouldn’t stay that way.

• Create a few admin groups in Workspace, for example gcp-org-admins, gcp-billing-admins and gcp-developers.
• Give cloud roles to the groups, not to people. Adding or removing someone is then a change in Workspace, and you can see who has access in one place.
• Keep the super admin account for emergencies. Day-to-day cloud work should use normal accounts that are in the right groups.
• Bring stray projects home. Projects someone created before the organisation existed show up under “No organization”. Google says this is normal; move them into the organisation so your policies apply to them.

Step 2: Set up billing you can see

• One billing account, linked to the organisation. Give the billing admin role to your finance contact’s group, not to a developer.
• Budgets and alerts from day one. Set a monthly budget per project with email alerts at 50%, 90% and 100%. Budgets warn you; they don’t switch anything off, so someone has to read the alerts.
• Labels on everything, such as team, app and environment, so the bill can be split in a way finance understands.
• Use what is free. New customers get US$300 in free credit to try Google Cloud. On top of that, the free tier gives every eligible account a monthly allowance, for example 2 million Cloud Run requests and one e2-micro Compute Engine VM a month. Small internal tools can run for very little.

Step 3: Decide where things live

A simple layout is enough for most companies starting out:

Then add two rules at the organisation level, called organization policies:

• Keep resources in India. The resource locations policy can limit new resources to Google Cloud’s Indian regions, Mumbai (asia-south1) and Delhi (asia-south2). This stops someone accidentally creating a database in the US.
• No downloadable service account keys. Leaked keys are one of the most common ways cloud accounts get misused. Blocking key creation pushes your team to safer ways of connecting apps.

Google’s own Cloud Setup guide in the console walks through all of this. It offers a proof-of-concept foundation, a production foundation and an advanced one. For a first project, the proof-of-concept or production option is plenty.

A first week, day by day

1. Day 1: a super admin signs in to the Google Cloud console, accepts the terms, and the organisation appears. Create the admin groups in Workspace.
2. Day 2: give the groups their cloud roles, create the billing account, link it, and set budgets with alerts.
3. Day 3: create the Production and Non-production folders, add the India location rule and the service account key rule.
4. Day 4: move any “No organization” projects in, and take personal accounts off ownership.
5. Day 5: create the first real project and deploy something small, such as an internal tool on Cloud Run, to prove the setup end to end.

None of this needs a large team. One person who knows the Workspace admin console and one who will build on Google Cloud can do it together.

Who should hold which role

Quick wins for Workspace teams

• Connected Sheets. Your team can analyse large BigQuery tables from inside Google Sheets, with the formulas and charts they already know.
• Internal tools on Cloud Run. Small apps for your staff can sit behind Google sign-in, so only people with a company account can open them.
• Apps Script that outgrew itself. Scripts that run your approvals or reports can move to a proper Google Cloud project with logging and a budget.

What can wait

Some things look important in the guides but can wait until you run more than a couple of apps: Shared VPC networks, VPN links to your office, advanced security tooling and a full infrastructure-as-code landing zone. Plan for them, but don’t let them hold up a first project.

Where DevOps TechLab fits

DevOps TechLab is a Select partner for both Google Workspace and Google Cloud, and we manage Google Workspace for clients every day, so we work on both sides of this setup. We can claim and tidy your organisation, set up the admin groups, billing, budgets and the India location rule, move stray projects in, and leave you with a written record of who can do what.