Google Cloud for People Who Learned AWS First

If you learned AWS first, most of Google Cloud is a vocabulary exercise. EC2 is Compute Engine, S3 is Cloud Storage, Lambda is Cloud Functions. You can look those up in a minute and they are not where the difficulty lives.

The trouble is the handful of places where the model itself is different. Those do not feel like new words. They feel like the cloud behaving wrongly, because your instinct is right for the other one.

Here are the four that actually matter.

1. The project is the account

In AWS, the account is the boundary. Separate environments means separate accounts, and Organizations exists to hold them together.

In Google Cloud that boundary is the project. A resource lives in exactly one project, billing attaches to the project, quotas are per project, and the IAM policy sits on the project. When people say Google Cloud is project-centric, this is the whole of what they mean.

So the translation is not "AWS account equals Google Cloud account". It is "AWS account equals Google Cloud project", and projects are much cheaper to create than AWS accounts are. Spinning up a project per environment is normal here rather than a governance decision.

Above projects there are folders, and above those the organisation. Permissions flow down all of it, which means somebody with a role at the organisation level holds it on every project without showing up in any project's own list. If you are auditing access, that is the thing to remember.

2. The network is global, and this is the big one

This is the difference that catches everybody, because it is not a renaming. It is a different shape.

Google: "VPC networks, including their associated routes and firewall rules, are global resources. They are not associated with any particular region or zone." And then: "Subnets are regional resources."

Read that against what you know. An AWS VPC is regional. Want workloads in two regions to talk privately and you are looking at peering, or a transit gateway, and a diagram.

In Google Cloud one VPC spans every region at once. You add a subnet in Frankfurt and a subnet in Iowa, both inside the same network, and machines in each can reach one another over internal addresses with no peering, no gateway, nothing to configure.

That is genuinely nicer and it has a sharp edge. The blast radius of a firewall rule is bigger than your instinct expects. In AWS, a mistake in a VPC is contained to that region. Here, a rule is a global object, and a careless one applies everywhere you run.

3. Firewall rules are not security groups

They do the same job and they are put together differently, which is worse than being completely different because it lets you assume.

An AWS security group is an object you attach to an instance. You manage the list of what is attached.

A Google Cloud firewall rule lives on the network and selects what it applies to, usually by network tag. You do not attach the rule to the machine. You put a tag on the machine and the rule finds it.

The consequence is that adding a tag to a VM can change what it is exposed to, immediately, without anybody touching a firewall. Tags look like labels and they behave like access control. Treat them as security configuration, because that is what they are.

One thing that does carry over: Google notes rules are "implemented on the VMs themselves", so like security groups, this is enforcement at the instance rather than a box in the middle.

And if you are starting a project, check what the default network came with. It ships with default-allow-ssh permitting tcp:22 from 0.0.0.0/0, and default-allow-rdp doing the same for 3389.

4. The discounts happen without you

This one is good news and it changes what is worth your time.

In AWS, getting the better price is a decision. You buy a Reserved Instance or a Savings Plan, you commit to a term, and you carry the risk of committing to the wrong thing.

Google Cloud applies sustained use discounts automatically on Compute Engine. Run an instance for a large share of the month and the rate drops by itself. Nothing to buy, nothing to forecast, nothing to forget to renew.

So the optimisation instinct you built on AWS points at the wrong thing here. The steady always-on machines are already discounted. Your waste is in things that should not exist at all, and in the services where Google's pricing model is unlike anything in AWS. BigQuery is the main one: on demand, it charges for the bytes your query reads, so a scheduled dashboard running a wide query can cost more than the servers it sits next to.

A few smaller ones worth knowing

Zones are zones, near enough. AWS Availability Zones and Google Cloud zones fill the same role and your instincts about spreading across them transfer intact.

There is no equivalent of creating an IAM user inside the cloud. Human identities are Google accounts, managed in Cloud Identity or Google Workspace, and Google Cloud grants roles to them. If you are used to creating users in IAM, that habit has nowhere to go here.

Service accounts do roughly what IAM roles do for workloads, with one trap. A service account can have a downloadable JSON key, which is a long-lived credential in a way an instance profile never was. If something runs inside Google Cloud, attach the service account instead and skip the key.

What actually transfers

More than you would think. Least privilege, tagging discipline, watching what is open to the internet, not trusting anything called default, and knowing that the bill is a lagging indicator of a decision you made weeks ago.

The judgement is the part you built, and it is portable. The vocabulary is the part you have to look up, and looking things up is not the hard bit of this job.

Where we are with this

This translation problem is close to why Liberra exists. An AI already knows both clouds cold. What it does not have, by itself, is your account: what is in it, what talks to what, what changed on Tuesday. So we index that, and then you can just ask, in the words you already use, and stop translating.

That runs on AWS and Azure today. Google Cloud is next, and I am not putting a date on it here, because a date given before something ships is a guess with good posture.

And on every cloud it touches, it cannot delete anything. The delete commands are blocked in the code, not in a permission somebody configures correctly on each one. Every change that writes stops, explains itself in plain English, and waits for you to approve it. When you are working in a cloud whose defaults you do not know by heart yet, that gate is the whole point.

Founder, Liberra AI