Dictionary

⚠ Where the analogy breaks

All three move the message after N failed deliveries, but the 'container' differs: implicit subqueue (Azure), separate queue (AWS) or separate topic that needs a subscription (GCP). In GCP a dead-letter topic without a subscription drops the messages.

⚠ Where the analogy breaks

Peek-lock (Service Bus), visibility timeout (SQS) and ack deadline (Pub/Sub) are the same mechanism: at-least-once delivery. None of them frees you from idempotent consumers.

⚠ Where the analogy breaks

API Management and Apigee are full platforms (portal, monetization, policies); Amazon API Gateway and Google API Gateway are lighter gateways. Comparing APIM with AWS API Gateway on price alone compares products in different categories.

⚠ Where the analogy breaks

Pod identity is where they differ most: AKS uses Microsoft Entra Workload ID (OIDC federation), EKS uses Pod Identity or IRSA, and GKE uses Workload Identity Federation for GKE. The concept is the same (Kubernetes service account token → cloud identity), the configuration isn't.

⚠ Where the analogy breaks

ACA and Cloud Run include HTTP ingress and scale to zero. ECS Fargate doesn't: ingress is a separate ALB (with fixed cost) and scaling comes from Application Auto Scaling.

⚠ Where the analogy breaks

Azure Policy evaluates resource configuration and can audit, deny or remediate (modify, deployIfNotExists). AWS SCPs don't look at configuration: they limit which API actions principals can use, and configuration compliance goes through AWS Config. GCP organization policies restrict configuration with predefined or custom constraints, without automatic remediation.

⚠ Where the analogy breaks

In AWS key access is defined first by the KMS key policy (in addition to IAM); in Azure and GCP RBAC/IAM on the key or its container is enough. Copying IAM permissions without the key policy is the typical mistake when migrating to AWS.

⚠ Where the analogy breaks

Where the trust rule lives differs. In Azure, each federated identity credential is an issuer + subject pair that must match exactly (no wildcards, up to 20 per identity). In AWS it's a trust policy with condition operators (StringEquals/StringLike). In GCP it's a CEL expression (attribute_condition) plus IAM bindings on mapped attributes.

⚠ Where the analogy breaks

Azure and GCP assign roles at a scope that's inherited downward (management group/subscription/RG in Azure; organization/folder/project in GCP). AWS evaluates identity and resource policies per request, with explicit deny always winning, and the hard boundary is the account.

⚠ Where the analogy breaks

Key Vault groups secrets, keys and certificates. In AWS that is split across Secrets Manager, KMS and ACM; in GCP across Secret Manager, Cloud KMS and Certificate Manager.

⚠ Where the analogy breaks

aws_iam_role has no 1:1 Azure resource. In AWS the role bundles identity + trust policy + permissions (attached policies). In Azure the identity (Managed Identity) and the permission (role assignment on a scope) are separate objects. In GCP the Service Account is the identity and the permission is an IAM binding on the resource.

⚠ Where the analogy breaks

Cloud CDN isn't a standalone service: it's enabled on a global external Application Load Balancer. Front Door and CloudFront are entry points by themselves.

⚠ Where the analogy breaks

In Azure and AWS, inbound and outbound are endpoints with IPs in subnets that you pay for hourly even with zero queries. In GCP there are no endpoints: the inbound policy takes one IP from each subnet in the VPC and outbound is a forwarding zone, billed like any zone plus queries.

⚠ Where the analogy breaks

In ACA and the internal ALB, the network is the access boundary. In Cloud Run, 'internal' restricts the network origin, but by default IAM (roles/run.invoker) is also required on every request: two controls, not one.

⚠ Where the analogy breaks

AWS Security Groups only have allow rules (stateful) and attach to interfaces; explicit deny lives in NACLs (stateless, per subnet). Azure NSGs have prioritized allow and deny rules attached to a subnet or NIC. In GCP rules belong to the VPC and target instances by network tags or service accounts.

⚠ Where the analogy breaks

The deployment model differs. Azure Firewall is a resource that lives in a dedicated subnet of the VNet. Network Firewall creates endpoints in VPC subnets and traffic reaches them through route tables. Cloud NGFW transparently intercepts the traffic that a policy rule selects and sends the packets to a zonal firewall endpoint for layer 7 inspection.

⚠ Where the analogy breaks

The mechanism differs. Azure Firewall application rules (HTTP/S and MSSQL) and Network Firewall domain lists (with TLS_SNI and HTTP_HOST, HTTP and HTTPS) rely on the SNI or the Host header. Cloud NGFW FQDN objects, and the FQDNs in Azure Firewall network rules, are resolved to IPs through DNS.

⚠ Where the analogy breaks

In Azure the NAT gateway is attached to the subnet and needs no routing configuration in its route table. In AWS it lives in a public subnet and private subnets need a route that points to it. In GCP it is configured on a Cloud Router and, per the docs, is not based on proxy VMs or appliances.

⚠ Where the analogy breaks

'Private Endpoint' (Azure), 'Interface Endpoint' (AWS) and 'Private Service Connect' (GCP) are conceptually the same. 'Service Endpoint' (Azure), 'Gateway Endpoint' (AWS) and 'Private Google Access' (GCP) are similar in being free, but do NOT do the same thing: none gives the service a private IP in your network.

⚠ Where the analogy breaks

The private zone resolves inside the cloud; for on-premises to resolve Private Endpoint/interface endpoint names (and vice versa) all three need a separate component: Private Resolver, Resolver endpoints or an inbound server policy.

⚠ Where the analogy breaks

GCP's VPC is global with regional subnets; Azure's VNet and AWS's VPC are regional. In AWS each subnet lives in a single AZ; in Azure a subnet spans every zone in the region.

⚠ Where the analogy breaks

Azure SQL Database is NOT the equivalent of RDS PostgreSQL (it is SQL Server). Comparing different engines invalidates any conclusion about auth or cost.

⚠ Where the analogy breaks

The cost model is the first thing that breaks when translating: Cosmos DB bills Request Units (provisioned or serverless), DynamoDB read/write capacity (on-demand or provisioned) and Firestore per operation. A partitioning design that's cheap in one can be expensive in another.

⚠ Where the analogy breaks

None of the three is an exact TTL. They are asynchronous background processes; design assuming the object may still exist hours or days after it "expires".

⚠ Where the analogy breaks

In Azure, networking, encryption and auth settings live on the Storage Account (which holds N containers); in S3 and Cloud Storage they live on each bucket. A 'bucket' is not a 'container': it is closer to Storage Account + container.