What a 12-Year AWS Engineer Expects to Get Wrong About Google Cloud

I have spent twelve years on AWS. IAM, Organizations, VPC, ECS, Lambda, RDS, KMS — the mental model is deep enough that I stopped noticing it was a model at all. It was just how cloud works.

This week I enrolled in the Google Cloud Gen AI Academy APAC Edition, and the track I picked ends with deploying a Gemini-backed Streamlit application to Cloud Run. I have not done it yet. I am writing this first, deliberately.

Here is why: once you have solved something, you reconstruct the experience as though it were obvious. The genuinely interesting information — which assumptions you carried in, which ones were load-bearing, which ones quietly failed — is only available before. So this post is a set of predictions I am putting on record, from reading the documentation, before I touch the console. The follow-up will mark them right or wrong.

Everything technical below comes from Google's documentation, not from my own hands. That distinction matters and I have tried to keep it visible throughout.

The map I built from the docs

Most of the vocabulary translates. This is the table I assembled in the first twenty minutes of reading:

That gets me eighty percent of the way. The remaining twenty percent is where I expect to be wrong, and three specific things in the documentation have already knocked against my instincts hard enough to be worth naming.

Three documented behaviours that break my AWS reflexes

1. Concurrency is 80, not 1

A Lambda invocation handles exactly one request. That constraint is so fundamental to the AWS serverless model that I had internalised it as the serverless model — a category truth rather than a vendor decision.

Cloud Run defaults to 80 concurrent requests per instance, configurable up to 1000. One container, eighty simultaneous requests, sharing a process.

Two consequences fall out of that, and only one of them is obvious.

The commercial one: cost is roughly instance count multiplied by duration, and concurrency is the divisor. Raising it serves the same load on fewer instances. Which means dropping concurrency to 1 — precisely what an AWS engineer's instinct suggests, because that is what "safe" looks like to me — is close to the worst available choice. More instances, more cold starts, more load on everything downstream.

The technical one is sharper. My code now has to actually be concurrency-safe. On Lambda, module-level mutable state is accidentally safe, because only one request is ever in flight. On Cloud Run that assumption is simply false. A module-scoped dictionary I would not have thought twice about becomes a race condition.

I have written a lot of Python that runs on Lambda. I do not know how much of it would survive being moved here unchanged, and I suspect the honest answer is "less than I would like".

2. Scale to zero is the default, not a feature you enable

Minimum instances defaults to 0. No traffic, no instances, no cost — without configuring anything. Maximum instances defaults to 100.

The AWS equivalent requires choosing Lambda specifically and accepting its constraints, or accepting that Fargate keeps a task running and billing whether anyone shows up or not.

My prediction is that this default is excellent for a proof of concept and quietly wrong for anything user-facing, because the first request after an idle period pays the cold start. The documented lever is --min-instances=1. I expect I will reach for it faster than I expect to.

3. There is no VPC in the deployment path

This is the one I keep re-reading because it does not feel right.

The documented deployment is a single command that builds from source, pushes to Artifact Registry, and returns an HTTPS URL with a managed certificate attached:

gcloud run deploy my-service --source .

No Dockerfile strictly required — Cloud Run can build from source using buildpacks.

Count the AWS path for the same outcome. Build the image. Authenticate to ECR. Push. Write a task definition. Create the service. Provision an ALB. Request a certificate in ACM. Wire up a target group, a listener, a security group, subnets across two availability zones. Point Route 53 at it.

I am not claiming the AWS path is wrong. That ALB does real work and exposes control Cloud Run does not. But I have spent years treating the VPC as the load-bearing wall of any design, and the idea of something publicly reachable without opening the networking console at all is genuinely disorienting. Cloud Run appears to give you a public endpoint by default and have you opt into restriction — ingress controls, Direct VPC egress, a load balancer with Cloud Armor in front — rather than opting out of isolation.

That is a real philosophical difference about where the default sits, and I do not yet know whether I will end up thinking it is right.

The predictions, stated so they can be wrong

1. The first deploy will work faster than I expect, and I will distrust it. I predict I spend more time verifying that it really is deployed and really is public than I spend deploying it.
2. IAM will be where I struggle. GCP's predefined roles look coarser to me than a hand-written IAM policy with conditions and resource ARNs. I predict this turns out to be my inexperience rather than a real limitation, and that custom roles cover it — but I am recording the discomfort now so I can check it later.
3. I will over-provision out of habit. Specifically, I predict I reach for --concurrency=1 at some point because it feels safe, and have to talk myself out of it.

Why bother

I am not planning to move anyone off AWS. That is rarely the right answer and my existing depth is an asset, not a sunk cost.

The narrower question is the interesting one. For a workload that is specifically a Gen AI application — request-driven, bursty, stateless, where the expensive thing is the model call rather than the compute wrapped around it — is Cloud Run plus Vertex AI a better fit than Fargate plus Bedrock? I do not know. I would like to have an informed opinion instead of a default one.

And there is a more general point I would make to any engineer who has gone deep on a single platform: the depth is worth having, but it quietly converts vendor-specific decisions into invisible assumptions. Half a day somewhere else is the cheapest available way to find out which of your beliefs are about computing and which are about a company.

Part two will report which of the three predictions survived.