AWS vs GCP vs Azure: A Terminology Map

An engineer moving a workload from AWS to GCP creates "a VPC" out of habit and treats it like an AWS VPC: one network, scoped to one region, matching the region the workload lived in. On GCP that VPC is global by default. It silently spans every region on the platform, and the segmentation assumptions built for AWS's per-region model no longer hold. Nobody notices until a resource in an unexpected region can reach something it should not.

That is the real risk in cross-cloud terminology: the names map cleanly, but the behaviour underneath often does not. This is a working reference for translating AWS, GCP, and Azure service names, and for flagging exactly where "equivalent" services hide different scope, limits, or architecture.

Which services are direct equivalents across AWS, GCP, and Azure?

Compute, object storage, serverless, and managed Kubernetes map by function, so you can translate the name and then check limits and pricing. A VM, a bucket, or a function is the same shape on all three clouds.

Managed data and platform services follow the same pattern:

Two cautions apply even to the clean rows. Instance naming, image formats (AMIs, machine images, managed disks), and storage tier boundaries all differ. And "equivalent" never means identical pricing or limits, so treat every row as a starting point for reading the real documentation.

How do networking services map across the three clouds?

Networking names map less cleanly than compute because each provider builds the pieces differently. Use this table to find the right page to read, not to assume identical behaviour.

The most visible gap is load balancing. GCP offers a single global load balancer family, while AWS and Azure split the job across several regional products by protocol and layer. A design that fronts one global anycast IP on GCP may need multiple load balancers plus DNS routing elsewhere.

How does a VPC differ on AWS, GCP, and Azure?

AWS and Azure scope their virtual network to one region, while a GCP VPC is global by default. This is the single most dangerous mismatch in cross-cloud work, because it changes your security boundary and not only a label.

Subnet scope also differs, which catches people who assume it matches AWS:

1. AWS: a VPC lives in one region, and each subnet lives in exactly one Availability Zone.
2. GCP: the VPC is global, and each subnet is regional, spanning all zones in its region.
3. Azure: a VNet lives in one region, and each subnet spans all zones in that region.

An engineer who designs GCP segmentation as "one VPC per region" can end up with a single global network connecting regions that were never meant to talk. GCP has a second trap: an auto mode VPC creates a subnet in every region for you. For production, use a custom mode network and add only the regions you need:

To audit an existing project, list its networks and read the subnet mode column. Any network in AUTO mode deserves a review:

Firewalls differ too. AWS security groups attach to network interfaces, GCP firewall rules apply at the VPC level and target instances by network tag or service account, and Azure network security groups attach to subnets or interfaces. Remap targets instead of copying rules.

How do IAM models differ across the three clouds?

All three answer the same question, who can do what to which resource, but each uses a different inheritance model. AWS attaches JSON policies to principals and resources, while GCP and Azure inherit permissions down a resource hierarchy.

• AWS IAM is policy-based. Identity policies attach to users and roles, resource policies attach to resources such as S3 buckets, and Organizations service control policies set account-level limits. An explicit deny always wins.
• Azure uses Microsoft Entra ID (formerly Azure AD) for identity and RBAC role assignments, which are inherited downward from management group to resource.
• GCP attaches allow policies at any level of its resource hierarchy, inherited downward, and adds deny policies to override grants.

The trap is that grants in GCP and Azure are additive down the tree. A child scope cannot simply remove what a parent granted, so reasoning from AWS policy evaluation order does not transfer. Relearn inheritance on each platform.

How do workload identities map?

Applications should never carry long-lived keys, and each cloud has a native answer. The names differ, and so does what the identity is bound to.

When migrating a service, rebuild its identity from scratch on the target cloud. Exporting a service account key or an access key to "make it work" removes the main security benefit of moving.

Where do serverless limits and compute behaviour differ?

Execution time limits are the most common serverless surprise in a migration. Lambda caps a single invocation at 15 minutes. Azure Functions on the Consumption plan allow up to 10 minutes, while Premium and Dedicated plans run much longer. On GCP, HTTP-triggered 2nd generation Cloud Functions can run up to 60 minutes, and Cloud Run request timeouts can be extended to 60 minutes.

If a job runs longer than 15 minutes, do not port it as a function. Move it to a container service such as Fargate, Cloud Run, or Container Apps, or split it into steps. Memory ceilings, concurrency models, and cold-start behaviour differ as well, so load-test the ported function instead of trusting the equivalence table.

Managed Kubernetes follows the same pattern. EKS, GKE, and AKS are close in features in 2026, but autoscaling design, control plane pricing, and default node management still differ, so autoscaler configuration is not a drop-in port. Quotas change often, so verify current limits on each provider's quotas page before you finalise a design.

Which five differences cause the most migration bugs?

Most cross-cloud incidents trace back to the same five mismatches. Review each one as a required design item, not an assumption.

1. VPC scope. Global on GCP, regional on AWS and Azure.
2. Subnet scope. One AZ on AWS, a whole region on GCP and Azure.
3. IAM inheritance. Policies on principals in AWS, hierarchy inheritance in GCP and Azure.
4. Execution limits. 15 minutes on Lambda, different ceilings elsewhere.
5. Firewall attachment. Network interface, VPC rule, or subnet, depending on the cloud.

Trade-offs and Alternatives

A terminology map speeds up reading, but it is not a design tool. Pick the approach that matches how portable the workload really needs to be.

Terraform and Kubernetes reduce lock-in at the workload level, but they do not erase the networking and IAM differences above. You still write cloud-specific modules for each provider.

Production Implementation Guidelines

Use this mapping to navigate an unfamiliar console and documentation faster, not as the source of truth for a migration's architecture. Compute, storage, and serverless are close enough to 1:1 for planning. Networking and IAM require reading each provider's current documentation before you design segmentation or access control.

If you are planning an AWS-to-GCP migration, make VPC scope a required design review item. Decide explicitly whether the workload needs GCP's global network model or whether you need to recreate AWS-style regional isolation with per-region subnets and firewall rules inside the global VPC.

For India-based teams weighing multi-cloud under RBI or MeitY data residency rules, the terminology map does not extend to compliance. Check each provider's regional availability, residency controls, and government cloud offerings service by service, because matching names do not imply matching compliance posture.

Finally, write a one-page "scope differences" checklist that lists the five items above and attach it to every cloud migration ticket. A reviewer who has to tick each box will catch what a skim of the mapping table misses.

💡 Tip: Pilot with one non-critical service first and run a Flow Logs or VPC Flow equivalent from day one on the new cloud. Unexpected cross-region traffic is the earliest visible sign that a scope assumption was wrong.

Note

References and Further Reading

• AWS Documentation - Official AWS service reference
• Google Cloud Documentation - Official GCP reference, including VPC scope details
• Azure Documentation - Official Azure reference, including the Entra ID and RBAC model
• Azure for AWS Professionals - Microsoft's service comparison for AWS users