An engineer moving a workload from AWS to GCP creates "a VPC" out of habit, treating it the same way they'd treat an AWS VPC - one network, scoped to one region, matching the region their AWS workload lived in. On GCP, that VPC is global by default. It silently spans every region on the platform unless subnets are explicitly scoped, and the migration's network segmentation assumptions - built for AWS's per-region model - don't hold anymore. Nobody notices until a resource in an unexpected region can suddenly reach something it shouldn't.
That's the real risk in cross-cloud terminology: the names map cleanly, the behavior underneath often doesn't. This is a working reference for translating AWS, GCP, and Azure service names - and, more importantly, flagging exactly where "equivalent" service names hide genuinely different scope, pricing, or architectural behavior.
Compute, storage, and serverless map close to 1:1 by function. Networking and IAM are where the terminology overlap becomes actively misleading if you don't check scope explicitly.
Compute: EC2 = [Compute Engine](/glossary/compute-engine) = Azure VMs
Object store: S3 = Cloud Storage = Blob Storage
Serverless: Lambda = Cloud Functions = Azure Functions
Containers: ECS/EKS = GKE = AKS
Networking: VPC (per-region) = VPC (GLOBAL) = VNet (per-region)
IAM: Policy-based = Resource hierarchy = [RBAC](/glossary/kubernetes-rbac) + Entra ID
Compute, storage, and serverless translate directly because the underlying concept - a VM, a bucket, a function that runs on trigger - is genuinely the same shape on all three clouds, with differences mostly in limits and pricing rather than architecture. Networking and IAM translate by name but not by scope or mental model, which is exactly where naive cross-cloud migrations introduce security or connectivity bugs that don't show up until production traffic hits an edge case the mapping didn't warn you about.
These map directly by function, with implementation details that matter for migration planning but don't change the underlying architecture:
- Virtual machines: EC2 (AWS) = Compute Engine (GCP) = Virtual Machines (Azure). Pricing models, instance-type naming conventions, and image formats differ - AMIs on AWS, machine images on GCP, managed disks on Azure - but the concept of a provisioned VM is identical across all three.
- Object storage: S3 (AWS) = Cloud Storage (GCP) = Blob Storage (Azure). All three offer tiered storage classes (hot/cool/cold/archive equivalents) and lifecycle management; naming and exact tier boundaries differ.
- Serverless functions: Lambda (AWS) = Cloud Functions (GCP) = Azure Functions. Execution limits differ meaningfully - Lambda caps at 15 minutes per invocation, while Azure Functions can run up to 60 minutes depending on the hosting plan - which matters directly for long-running job migration planning.
- Managed Kubernetes: EKS (AWS) = GKE (GCP) = AKS (Azure). Feature parity is close in 2026, but autoscaling architecture, control plane pricing, and default node-management abstraction differ significantly between the three - see the dedicated GKE vs EKS vs AKS comparison for that detail.
AWS VPC: per-REGION, subnets span Availability Zones
within that region
GCP VPC: GLOBAL by default, one VPC spans every
region on the platform
Azure VNet: per-REGION, subnets span Availability
Zones within that region
AWS and Azure both scope their virtual network primitive to a single region - a VPC on AWS or a VNet on Azure exists in one region, with subnets distributed across that region's Availability Zones. GCP breaks this pattern entirely: a GCP VPC is global by default, spanning every region on the platform, with subnets defined per-region inside that single global network.
This is not a naming quirk - it's a genuine architectural difference with security consequences. An engineer who assumes "one VPC per region" while designing GCP network segmentation, because that's how AWS and Azure work, can end up with a single global VPC that silently connects resources across regions that were never meant to talk to each other. Always verify VPC scope explicitly per provider rather than assuming AWS's per-region model transfers.
AWS IAM is policy-based: JSON policy documents attached directly to principals - users, roles, or resources - defining allowed or denied actions. Azure uses Entra ID (formerly Azure AD) for identity, layered with role-based access control (RBAC) over a management-group and subscription scope hierarchy. GCP uses a resource hierarchy - organization, folder, project, resource - with allow and deny policies attachable at any level in that hierarchy, inherited downward.
The underlying goal is identical on all three: control who can do what to which resource. But the mental model for reasoning about permission inheritance is not portable. An AWS engineer who understands IAM policy evaluation order has to relearn how Azure RBAC scope inheritance works, and relearn again how GCP's resource-hierarchy allow/deny policies combine - none of that reasoning transfers, even though the policy documents in all three cases are ultimately expressing the same intent.
Terminology Mapping by Category:
| Category |
AWS |
GCP |
| Compute (VMs) |
EC2 |
Compute Engine |
| Object storage |
S3 |
Cloud Storage |
| Serverless |
Lambda (15 min cap) |
Cloud Functions |
Terminology Mapping by Category, continued:
| Category |
Azure |
Scope Warning |
| Compute (VMs) |
Virtual Machines |
None - concept transfers directly |
| Object storage |
Blob Storage |
None - concept transfers directly |
| Serverless |
Azure Functions (60 min cap) |
Execution limit differs meaningfully |
Networking and IAM:
| Category |
AWS |
GCP |
| Virtual network |
VPC - per-region |
VPC - global by default |
| IAM model |
Policy-based, JSON on principals |
Resource hierarchy, allow/deny |
Use this mapping to navigate an unfamiliar cloud's console and documentation faster, not as a source of truth for a migration's architecture. Compute, storage, and serverless services are close enough to 1:1 that the mapping holds for planning purposes; networking and IAM require checking each provider's current documentation before you design segmentation or access control, since the scope differences are not cosmetic.
If your team is planning an AWS-to-GCP migration specifically, treat VPC scope as a required design review item, not an assumption - decide explicitly whether your workload needs GCP's global-VPC model or whether you need to replicate AWS's per-region isolation using GCP's per-region subnet boundaries within that global VPC.
For India-based teams evaluating multi-cloud for data residency under RBI or MeitY guidelines, note that the terminology mapping doesn't extend to compliance posture - each provider's regional availability, data residency controls, and government cloud offerings need to be checked independently per service, not assumed equivalent because the service names map cleanly elsewhere.
INFORMATIONReferences and Further Reading
Discussion0