• •Role-based with predefined/custom roles (permissions as service.resource.verb); Keystone uses simpler flat roles assigned to user-project/domain pairs without granular permissions.
• •Hierarchical inheritance across Org > Folder > Project; OpenStack Keystone assignments scoped per project/domain without automatic inheritance.
• •Supports IAM Conditions for attribute/time-based access, deny policies, VPC Service Controls; no direct OpenStack equivalent.
• •Principals include Google groups/service accounts/federated; Keystone uses local users/groups with federation add-ons.

• •GCP offers external and internal, global and regional, HTTP, TCP, and UDP load balancers. Quake AI workloads use a self-managed reverse proxy or Kubernetes LoadBalancer Service.
• •GCP global HTTP(S) load balancing uses one anycast IP across regions. Self-managed Quake AI edges use the public IP and topology you provision.
• •GCP integrates Cloud CDN, Cloud Armor (WAF/DDoS) with LBs; OpenStack has no native CDN/WAF integration.
• •GCP backend services use health checks and instance groups or NEGs. Self-managed Quake AI edges use proxy upstreams or Kubernetes service selectors.

• •GCP Cloud NAT is a managed service on top of Cloud Router; OpenStack SNAT is built into the L3 router agent/OVN.
• •GCP NAT supports port allocation (static/dynamic), min/max ports per VM; OpenStack SNAT allocates ports dynamically.
• •GCP NAT Gateway billed per hour + per GB processed; OpenStack SNAT is typically included in router costs.

• •GCP Cloud Router is a BGP speaker for dynamic route exchange with VPN/Interconnect; OpenStack routers are L3 gateways with static routes.
• •GCP routers enable Cloud NAT but are separate resources; OpenStack router SNAT is built into the router service.
• •GCP routers regional, created per region for VPN/Interconnect; OpenStack routers can be shared/distributed across AZs.

• •GCP Cloud Storage has an S3-compatible XML API at storage.googleapis.com; auth uses HMAC keys generated separately from GCP service account credentials. Quake AI uses EC2-style credentials (access key + secret) generated via Keystone POST /v3/users/{user_id}/credentials/OS-EC2.
• •GCP S3 XML API endpoint is storage.googleapis.com (path-style); Quake AI endpoint is provider-specific. GCP does not support S3 multipart upload via the XML API — the GCS resumable upload API must be used instead. Quake AI's Swift s3api supports S3 multipart upload.
• •IAM policies on GCS buckets cannot be managed via S3 ACL API calls through the compatibility layer; bucket IAM must be managed via GCP-native tooling (gcloud, Resource Manager API).
• •GCP HMAC keys inherit all permissions of the associated service account with no ability to restrict to a subset of operations. Keystone EC2 credentials inherit the Keystone role of the user who creates them.

No specific divergences documented yet.

• •GCP always-on AES-256-GCM Google-managed (no config), +CMEK/CSEK; Swift optional proxy middleware (keymaster+encryption), AES-256-CTR on body/ETag/user-meta (plaintext client→encrypt cluster), requires root secret config/daemon.
• •GCP encrypts metadata/checksums; Swift selective (no names/size/sysmeta).
• •GCP auto decrypt reads; Swift decrypts GET/HEAD w/ keymaster.
• •GCP client optional; Swift recommends client-side for transit+storage.

• •Uses YAML configurations with optional Jinja2/Python templates expanded server-side; Quake AI offers Heat (legacy, HOT/YAML) and recommends OpenTofu (HCL) for new work.
• •Resource types named as service.v1.resource (e.g., compute.v1.instance) tied to GCP APIs, vs OpenStack prefixed types like OS::Nova::Server.
• •Single integrated GCP service (no separate API/engine processes); Heat has a multi-service architecture (heat-api, heat-engine) but is legacy. OpenTofu runs client-side with no server component.
• •No additional service fee; bills only for deployed GCP resources, same as OpenStack resources billing via provider.

• •Direct disk-to-disk cloning (zonal-to-zonal or zonal-to-regional) without intermediate snapshot, synchronous and instantly usable (regional averages 3 min to full sync).
• •Must match source disk type; rate limits (1 every 30s, 1000 per lineage); clone size >= source.
• •Cross-project supported via full resource path; source VM cannot power on during clone.
• •API uses compute.disks.insert with sourceDisk field, differing from Cinder's clone volume API.

• •GCP firewall rules are VPC-level with target filtering by network tags or service accounts; OpenStack security groups attach to ports.
• •GCP rules are stateful (implied return traffic); OpenStack security groups also stateful but per Neutron port.
• •GCP firewall supports priority (0-65535) with explicit deny rules; OpenStack security groups are allow-only (implicit deny).
• •GCP hierarchical firewall policies apply org/folder-wide; OpenStack has no equivalent scope.

• •GKE provides Autopilot mode with fully managed node provisioning and scaling by Google; on Quake AI you provision clusters through Magnum or self-managed Kubernetes on Nova instances and manage node scaling yourself.
• •Control plane is fully managed with automatic upgrades through release channels; Quake AI requires user-provisioned and user-managed control plane nodes.
• •Cluster creation uses gcloud CLI vs OpenStack CLI (openstack coe cluster create).
• •Custom machine types, spot VMs, accelerators in node pools; Quake AI K8s nodes use standard Nova flavors.

• •Per-hour cluster platform fee with a free tier allowance; Autopilot offers pod-based billing as an alternative model. On Quake AI, whether you use Magnum or self-managed Kubernetes, you pay only for the underlying Nova instances and associated resources, with no Kubernetes platform fee.
• •Separate Cloud Billing Account linked to multiple projects, with self-serve/invoiced, postpay/prepay cycles; OpenStack typically uses external billing systems integrated via usage notifications, no built-in account.
• •Payments via Google Payments Profile (cards/ACH/wire); OpenStack has no native payment processing.
• •Billing-specific IAM roles (e.g., Billing Account Creator) inherited from Org; OpenStack quotas/usage per project via Keystone/Nova, no billing IAM.

• •GCP bills all VM instances per second with no minimum charge per instance. Sustained use discounts apply automatically (up to 30% discount) after using an instance for more than 25% of a month; no commitment required and no OpenStack equivalent.
• •GCP pricing is not embedded in the machine type API; it requires the Cloud Billing Catalog API (GET /v1/services/{serviceId}/skus) or the Pricing Calculator.
• •GCP bills network egress by destination: egress to internet by region (varies), within-region egress is free. Quake AI's egress pricing is operator-defined.
• •Preemptible (now Spot) VMs on GCP offer up to 91% discount with no-notice termination. OpenStack does not natively support preemptible or spot instances.

• •Public images shareable across projects (e.g. debian-cloud); OpenStack typically tenant-private.
• •Image families point to latest version; no OpenStack equivalent.
• •Custom images stored in Cloud Storage with licensing fees for premium OS.

• •Organized by families/series (e.g. N2 general-purpose); OpenStack flavors flat list.
• •Custom types +5% premium for N/E series; no such billing in OpenStack.
• •Naming 'n2-standard-4'; shared-core bursting types absent in OpenStack.

• •GCP has no subscription concept. A Billing Account is linked to one or more Projects; usage across linked projects is aggregated and invoiced together. OpenStack projects do not have a native billing account concept.
• •GCP Billing Accounts can be linked to up to 5 projects by default (quota increase required for more); each project can only have one billing account. OpenStack projects have no billing account concept built in.
• •GCP Projects are resource containers and quota boundaries; the Billing Account is purely a financial construct. OpenStack projects serve both purposes (resource isolation and, in some deployments, billing isolation).
• •GCP billing exports to BigQuery are a first-class feature for cost analysis at the billing account level. No OpenStack equivalent; billing data requires custom instrumentation.

• •GCP VMs have network interfaces attached at creation; OpenStack ports are explicit Neutron resources manageable independently.
• •GCP multi-NIC VMs require one interface per VPC (max 8); OpenStack supports multiple ports on same or different networks.
• •GCP alias IP ranges allow multiple IPs per interface without additional resources; OpenStack uses allowed_address_pairs.

• •GCP bucket-level enable, auto live/noncurrent via generation/metageneration, DELETE noncurrent permanent (w/gen), costs all versions + lifecycle mgmt; Swift container-level X-Versions/Histor y-Location modes (archive on PUT/DELETE, naming <len>obj/ts>), middleware required, DELETE behavior mode-dependent (restore vs archive).
• •GCP soft delete separate/interactive; Swift no soft delete mention.
• •GCP no manifest versioning; Swift same.
• •GCP disable retains versions; Swift similar.

• •Organizations auto-provisioned for Google Workspace/Cloud Identity accounts with immutable owner directory ID; OpenStack domains are manually created without such tight identity coupling.
• •Single org per company as root with Folders for sub-grouping (e.g., departments); OpenStack lacks native multi-level folders, using domains/projects.
• •Central point for IAM policy inheritance to all descendants and organization policies (constraints); Keystone domain-scoped assignments don't inherit multi-level.

• •Uses Google Compute Engine REST API instead of OpenStack Cinder API.
• •Offers multiple performance tiers (pd-standard HDD, pd-balanced SSD, pd-ssd, pd-extreme) with performance scaling linearly with provisioned size, unlike Cinder's backend-dependent performance.
• •Supports regional disks replicated synchronously across 2 zones for higher availability (better than 99.9999% durability), while Cinder volumes are typically zonal unless using replication features.
• •Online resize to increase size without detaching; no manual striping/RAID needed as GCP handles distribution automatically.

• •GCP Projects have both human-readable Project ID (custom) and auto-generated numeric Project Number, used interchangeably in APIs unlike OpenStack projects which use single ID.
• •Projects required to enable billing and host all service resources; no direct equivalent to OpenStack's billing per project without linking to Billing Account.
• •Projects inherit IAM policies from Org/Folders; moving project changes inheritance, unlike flat OpenStack project isolation.

• •MIGs offer autoscaling, autohealing, rolling updates via templates; OpenStack only scheduling policies (affinity etc.).
• •Zonal/regional with HA/load balancing integration; no management in OpenStack groups.
• •App health checks trigger recreation; requires external orchestration in OpenStack.

• •Managed in project/instance metadata or OS Login (IAM); no central 'keypairs' resource like Nova.
• •Auto-generates ephemeral keys for CLI/console; manual upload only in OpenStack.
• •Public key includes username suffix; injected differently.

• •Crash-consistent point-in-time copies stored incrementally in Cloud Storage (geo-redundant by default), unlike Cinder snapshots which depend on backend (often full copies).
• •Two types: Standard (faster recovery) and Archive (cheaper long-term); supports snapshot schedules (standard only).
• •Global by default, shareable across projects/regions/zones with network egress costs for cross-region restore; regional scoping (preview) for location control.
• •Frequency limit: max 6 snapshots per disk every 60 minutes.

• •GCP static IPs are regional or global resources, with unassociated IPs metered per-hour; OpenStack floating IPs are pool-based. See the GCP pricing page for current rates.
• •GCP supports both ephemeral (auto-released on stop) and static IPs; OpenStack floating IPs are always explicit.
• •GCP global static IPs used with global load balancers only; no direct OpenStack equivalent.

• •GCP subnets are regional (cover all zones in a region); OpenStack subnets are project-scoped within a network.
• •GCP supports secondary IP ranges for alias IPs/GKE pods; OpenStack subnets have single CIDR.
• •GCP private Google access allows VMs without external IPs to reach Google APIs; OpenStack has no equivalent.

• •Uses HCL with google_compute_instance, google_storage_bucket etc.; Quake AI uses the OpenStack Terraform/OpenTofu provider with openstack_compute_instance_v2 and equivalent resources.
• •Remote state stored in GCS backend; OpenStack uses Terraform state stored locally or in S3-compatible backend.

• •Uses REST API 'instances.insert' instead of Nova 'servers.create' with different auth via service accounts vs Keystone.
• •Supports bare metal instances (no hypervisor), not in standard OpenStack Nova.
• •Network interfaces tied to VPC subnets; differs from Neutron ports/floating IPs.

• •GCP VPC is global (spans all regions) whereas OpenStack Neutron networks are project-scoped and region-local.
• •GCP uses shared VPC for cross-project networking (requires org-level config); OpenStack uses shared networks via admin.
• •Subnets in GCP are regional, auto-mode creates one per region automatically; OpenStack requires explicit subnet creation.
• •GCP VPC Flow Logs per-subnet; OpenStack has no native equivalent without external tools.

• •Per-cluster Neutron networks + floating IPs; GKE shared VPC with alias IP ranges.
• •Kubernetes LoadBalancer behavior replaces Google Cloud Load Balancers after migration.

• •Role-based with predefined/custom roles (permissions as service.resource.verb); Keystone uses simpler flat roles assigned to user-project/domain pairs without granular permissions.
• •Hierarchical inheritance across Org > Folder > Project; OpenStack Keystone assignments scoped per project/domain without automatic inheritance.
• •Supports IAM Conditions for attribute/time-based access, deny policies, VPC Service Controls; no direct OpenStack equivalent.
• •Principals include Google groups/service accounts/federated; Keystone uses local users/groups with federation add-ons.

• •GCP offers external and internal, global and regional, HTTP, TCP, and UDP load balancers. Quake AI workloads use a self-managed reverse proxy or Kubernetes LoadBalancer Service.
• •GCP global HTTP(S) load balancing uses one anycast IP across regions. Self-managed Quake AI edges use the public IP and topology you provision.
• •GCP integrates Cloud CDN, Cloud Armor (WAF/DDoS) with LBs; OpenStack has no native CDN/WAF integration.
• •GCP backend services use health checks and instance groups or NEGs. Self-managed Quake AI edges use proxy upstreams or Kubernetes service selectors.

• •GCP Cloud NAT is a managed service on top of Cloud Router; OpenStack SNAT is built into the L3 router agent/OVN.
• •GCP NAT supports port allocation (static/dynamic), min/max ports per VM; OpenStack SNAT allocates ports dynamically.
• •GCP NAT Gateway billed per hour + per GB processed; OpenStack SNAT is typically included in router costs.

• •GCP Cloud Router is a BGP speaker for dynamic route exchange with VPN/Interconnect; OpenStack routers are L3 gateways with static routes.
• •GCP routers enable Cloud NAT but are separate resources; OpenStack router SNAT is built into the router service.
• •GCP routers regional, created per region for VPN/Interconnect; OpenStack routers can be shared/distributed across AZs.

• •GCP Cloud Storage has an S3-compatible XML API at storage.googleapis.com; auth uses HMAC keys generated separately from GCP service account credentials. Quake AI uses EC2-style credentials (access key + secret) generated via Keystone POST /v3/users/{user_id}/credentials/OS-EC2.
• •GCP S3 XML API endpoint is storage.googleapis.com (path-style); Quake AI endpoint is provider-specific. GCP does not support S3 multipart upload via the XML API — the GCS resumable upload API must be used instead. Quake AI's Swift s3api supports S3 multipart upload.
• •IAM policies on GCS buckets cannot be managed via S3 ACL API calls through the compatibility layer; bucket IAM must be managed via GCP-native tooling (gcloud, Resource Manager API).
• •GCP HMAC keys inherit all permissions of the associated service account with no ability to restrict to a subset of operations. Keystone EC2 credentials inherit the Keystone role of the user who creates them.

No specific divergences documented yet.

• •GCP always-on AES-256-GCM Google-managed (no config), +CMEK/CSEK; Swift optional proxy middleware (keymaster+encryption), AES-256-CTR on body/ETag/user-meta (plaintext client→encrypt cluster), requires root secret config/daemon.
• •GCP encrypts metadata/checksums; Swift selective (no names/size/sysmeta).
• •GCP auto decrypt reads; Swift decrypts GET/HEAD w/ keymaster.
• •GCP client optional; Swift recommends client-side for transit+storage.

• •Uses YAML configurations with optional Jinja2/Python templates expanded server-side; Quake AI offers Heat (legacy, HOT/YAML) and recommends OpenTofu (HCL) for new work.
• •Resource types named as service.v1.resource (e.g., compute.v1.instance) tied to GCP APIs, vs OpenStack prefixed types like OS::Nova::Server.
• •Single integrated GCP service (no separate API/engine processes); Heat has a multi-service architecture (heat-api, heat-engine) but is legacy. OpenTofu runs client-side with no server component.
• •No additional service fee; bills only for deployed GCP resources, same as OpenStack resources billing via provider.

• •Direct disk-to-disk cloning (zonal-to-zonal or zonal-to-regional) without intermediate snapshot, synchronous and instantly usable (regional averages 3 min to full sync).
• •Must match source disk type; rate limits (1 every 30s, 1000 per lineage); clone size >= source.
• •Cross-project supported via full resource path; source VM cannot power on during clone.
• •API uses compute.disks.insert with sourceDisk field, differing from Cinder's clone volume API.

• •GCP firewall rules are VPC-level with target filtering by network tags or service accounts; OpenStack security groups attach to ports.
• •GCP rules are stateful (implied return traffic); OpenStack security groups also stateful but per Neutron port.
• •GCP firewall supports priority (0-65535) with explicit deny rules; OpenStack security groups are allow-only (implicit deny).
• •GCP hierarchical firewall policies apply org/folder-wide; OpenStack has no equivalent scope.

• •GKE provides Autopilot mode with fully managed node provisioning and scaling by Google; on Quake AI you provision clusters through Magnum or self-managed Kubernetes on Nova instances and manage node scaling yourself.
• •Control plane is fully managed with automatic upgrades through release channels; Quake AI requires user-provisioned and user-managed control plane nodes.
• •Cluster creation uses gcloud CLI vs OpenStack CLI (openstack coe cluster create).
• •Custom machine types, spot VMs, accelerators in node pools; Quake AI K8s nodes use standard Nova flavors.

• •Per-hour cluster platform fee with a free tier allowance; Autopilot offers pod-based billing as an alternative model. On Quake AI, whether you use Magnum or self-managed Kubernetes, you pay only for the underlying Nova instances and associated resources, with no Kubernetes platform fee.
• •Separate Cloud Billing Account linked to multiple projects, with self-serve/invoiced, postpay/prepay cycles; OpenStack typically uses external billing systems integrated via usage notifications, no built-in account.
• •Payments via Google Payments Profile (cards/ACH/wire); OpenStack has no native payment processing.
• •Billing-specific IAM roles (e.g., Billing Account Creator) inherited from Org; OpenStack quotas/usage per project via Keystone/Nova, no billing IAM.

• •GCP bills all VM instances per second with no minimum charge per instance. Sustained use discounts apply automatically (up to 30% discount) after using an instance for more than 25% of a month; no commitment required and no OpenStack equivalent.
• •GCP pricing is not embedded in the machine type API; it requires the Cloud Billing Catalog API (GET /v1/services/{serviceId}/skus) or the Pricing Calculator.
• •GCP bills network egress by destination: egress to internet by region (varies), within-region egress is free. Quake AI's egress pricing is operator-defined.
• •Preemptible (now Spot) VMs on GCP offer up to 91% discount with no-notice termination. OpenStack does not natively support preemptible or spot instances.

• •Public images shareable across projects (e.g. debian-cloud); OpenStack typically tenant-private.
• •Image families point to latest version; no OpenStack equivalent.
• •Custom images stored in Cloud Storage with licensing fees for premium OS.

• •Organized by families/series (e.g. N2 general-purpose); OpenStack flavors flat list.
• •Custom types +5% premium for N/E series; no such billing in OpenStack.
• •Naming 'n2-standard-4'; shared-core bursting types absent in OpenStack.

• •GCP has no subscription concept. A Billing Account is linked to one or more Projects; usage across linked projects is aggregated and invoiced together. OpenStack projects do not have a native billing account concept.
• •GCP Billing Accounts can be linked to up to 5 projects by default (quota increase required for more); each project can only have one billing account. OpenStack projects have no billing account concept built in.
• •GCP Projects are resource containers and quota boundaries; the Billing Account is purely a financial construct. OpenStack projects serve both purposes (resource isolation and, in some deployments, billing isolation).
• •GCP billing exports to BigQuery are a first-class feature for cost analysis at the billing account level. No OpenStack equivalent; billing data requires custom instrumentation.

• •GCP VMs have network interfaces attached at creation; OpenStack ports are explicit Neutron resources manageable independently.
• •GCP multi-NIC VMs require one interface per VPC (max 8); OpenStack supports multiple ports on same or different networks.
• •GCP alias IP ranges allow multiple IPs per interface without additional resources; OpenStack uses allowed_address_pairs.

• •GCP bucket-level enable, auto live/noncurrent via generation/metageneration, DELETE noncurrent permanent (w/gen), costs all versions + lifecycle mgmt; Swift container-level X-Versions/Histor y-Location modes (archive on PUT/DELETE, naming <len>obj/ts>), middleware required, DELETE behavior mode-dependent (restore vs archive).
• •GCP soft delete separate/interactive; Swift no soft delete mention.
• •GCP no manifest versioning; Swift same.
• •GCP disable retains versions; Swift similar.

• •Organizations auto-provisioned for Google Workspace/Cloud Identity accounts with immutable owner directory ID; OpenStack domains are manually created without such tight identity coupling.
• •Single org per company as root with Folders for sub-grouping (e.g., departments); OpenStack lacks native multi-level folders, using domains/projects.
• •Central point for IAM policy inheritance to all descendants and organization policies (constraints); Keystone domain-scoped assignments don't inherit multi-level.

• •Uses Google Compute Engine REST API instead of OpenStack Cinder API.
• •Offers multiple performance tiers (pd-standard HDD, pd-balanced SSD, pd-ssd, pd-extreme) with performance scaling linearly with provisioned size, unlike Cinder's backend-dependent performance.
• •Supports regional disks replicated synchronously across 2 zones for higher availability (better than 99.9999% durability), while Cinder volumes are typically zonal unless using replication features.
• •Online resize to increase size without detaching; no manual striping/RAID needed as GCP handles distribution automatically.

• •GCP Projects have both human-readable Project ID (custom) and auto-generated numeric Project Number, used interchangeably in APIs unlike OpenStack projects which use single ID.
• •Projects required to enable billing and host all service resources; no direct equivalent to OpenStack's billing per project without linking to Billing Account.
• •Projects inherit IAM policies from Org/Folders; moving project changes inheritance, unlike flat OpenStack project isolation.

• •MIGs offer autoscaling, autohealing, rolling updates via templates; OpenStack only scheduling policies (affinity etc.).
• •Zonal/regional with HA/load balancing integration; no management in OpenStack groups.
• •App health checks trigger recreation; requires external orchestration in OpenStack.

• •Managed in project/instance metadata or OS Login (IAM); no central 'keypairs' resource like Nova.
• •Auto-generates ephemeral keys for CLI/console; manual upload only in OpenStack.
• •Public key includes username suffix; injected differently.

• •Crash-consistent point-in-time copies stored incrementally in Cloud Storage (geo-redundant by default), unlike Cinder snapshots which depend on backend (often full copies).
• •Two types: Standard (faster recovery) and Archive (cheaper long-term); supports snapshot schedules (standard only).
• •Global by default, shareable across projects/regions/zones with network egress costs for cross-region restore; regional scoping (preview) for location control.
• •Frequency limit: max 6 snapshots per disk every 60 minutes.

• •GCP static IPs are regional or global resources, with unassociated IPs metered per-hour; OpenStack floating IPs are pool-based. See the GCP pricing page for current rates.
• •GCP supports both ephemeral (auto-released on stop) and static IPs; OpenStack floating IPs are always explicit.
• •GCP global static IPs used with global load balancers only; no direct OpenStack equivalent.

• •GCP subnets are regional (cover all zones in a region); OpenStack subnets are project-scoped within a network.
• •GCP supports secondary IP ranges for alias IPs/GKE pods; OpenStack subnets have single CIDR.
• •GCP private Google access allows VMs without external IPs to reach Google APIs; OpenStack has no equivalent.

• •Uses HCL with google_compute_instance, google_storage_bucket etc.; Quake AI uses the OpenStack Terraform/OpenTofu provider with openstack_compute_instance_v2 and equivalent resources.
• •Remote state stored in GCS backend; OpenStack uses Terraform state stored locally or in S3-compatible backend.

• •Uses REST API 'instances.insert' instead of Nova 'servers.create' with different auth via service accounts vs Keystone.
• •Supports bare metal instances (no hypervisor), not in standard OpenStack Nova.
• •Network interfaces tied to VPC subnets; differs from Neutron ports/floating IPs.

• •GCP VPC is global (spans all regions) whereas OpenStack Neutron networks are project-scoped and region-local.
• •GCP uses shared VPC for cross-project networking (requires org-level config); OpenStack uses shared networks via admin.
• •Subnets in GCP are regional, auto-mode creates one per region automatically; OpenStack requires explicit subnet creation.
• •GCP VPC Flow Logs per-subnet; OpenStack has no native equivalent without external tools.

• •Per-cluster Neutron networks + floating IPs; GKE shared VPC with alias IP ranges.
• •Kubernetes LoadBalancer behavior replaces Google Cloud Load Balancers after migration.

• •Role-based with predefined/custom roles (permissions as service.resource.verb); Keystone uses simpler flat roles assigned to user-project/domain pairs without granular permissions.
• •Hierarchical inheritance across Org > Folder > Project; OpenStack Keystone assignments scoped per project/domain without automatic inheritance.
• •Supports IAM Conditions for attribute/time-based access, deny policies, VPC Service Controls; no direct OpenStack equivalent.
• •Principals include Google groups/service accounts/federated; Keystone uses local users/groups with federation add-ons.

• •GCP offers external and internal, global and regional, HTTP, TCP, and UDP load balancers. Quake AI workloads use a self-managed reverse proxy or Kubernetes LoadBalancer Service.
• •GCP global HTTP(S) load balancing uses one anycast IP across regions. Self-managed Quake AI edges use the public IP and topology you provision.
• •GCP integrates Cloud CDN, Cloud Armor (WAF/DDoS) with LBs; OpenStack has no native CDN/WAF integration.
• •GCP backend services use health checks and instance groups or NEGs. Self-managed Quake AI edges use proxy upstreams or Kubernetes service selectors.

• •GCP Cloud NAT is a managed service on top of Cloud Router; OpenStack SNAT is built into the L3 router agent/OVN.
• •GCP NAT supports port allocation (static/dynamic), min/max ports per VM; OpenStack SNAT allocates ports dynamically.
• •GCP NAT Gateway billed per hour + per GB processed; OpenStack SNAT is typically included in router costs.

• •GCP Cloud Router is a BGP speaker for dynamic route exchange with VPN/Interconnect; OpenStack routers are L3 gateways with static routes.
• •GCP routers enable Cloud NAT but are separate resources; OpenStack router SNAT is built into the router service.
• •GCP routers regional, created per region for VPN/Interconnect; OpenStack routers can be shared/distributed across AZs.

• •GCP Cloud Storage has an S3-compatible XML API at storage.googleapis.com; auth uses HMAC keys generated separately from GCP service account credentials. Quake AI uses EC2-style credentials (access key + secret) generated via Keystone POST /v3/users/{user_id}/credentials/OS-EC2.
• •GCP S3 XML API endpoint is storage.googleapis.com (path-style); Quake AI endpoint is provider-specific. GCP does not support S3 multipart upload via the XML API — the GCS resumable upload API must be used instead. Quake AI's Swift s3api supports S3 multipart upload.
• •IAM policies on GCS buckets cannot be managed via S3 ACL API calls through the compatibility layer; bucket IAM must be managed via GCP-native tooling (gcloud, Resource Manager API).
• •GCP HMAC keys inherit all permissions of the associated service account with no ability to restrict to a subset of operations. Keystone EC2 credentials inherit the Keystone role of the user who creates them.

No specific divergences documented yet.

• •GCP always-on AES-256-GCM Google-managed (no config), +CMEK/CSEK; Swift optional proxy middleware (keymaster+encryption), AES-256-CTR on body/ETag/user-meta (plaintext client→encrypt cluster), requires root secret config/daemon.
• •GCP encrypts metadata/checksums; Swift selective (no names/size/sysmeta).
• •GCP auto decrypt reads; Swift decrypts GET/HEAD w/ keymaster.
• •GCP client optional; Swift recommends client-side for transit+storage.

• •Uses YAML configurations with optional Jinja2/Python templates expanded server-side; Quake AI offers Heat (legacy, HOT/YAML) and recommends OpenTofu (HCL) for new work.
• •Resource types named as service.v1.resource (e.g., compute.v1.instance) tied to GCP APIs, vs OpenStack prefixed types like OS::Nova::Server.
• •Single integrated GCP service (no separate API/engine processes); Heat has a multi-service architecture (heat-api, heat-engine) but is legacy. OpenTofu runs client-side with no server component.
• •No additional service fee; bills only for deployed GCP resources, same as OpenStack resources billing via provider.

• •Direct disk-to-disk cloning (zonal-to-zonal or zonal-to-regional) without intermediate snapshot, synchronous and instantly usable (regional averages 3 min to full sync).
• •Must match source disk type; rate limits (1 every 30s, 1000 per lineage); clone size >= source.
• •Cross-project supported via full resource path; source VM cannot power on during clone.
• •API uses compute.disks.insert with sourceDisk field, differing from Cinder's clone volume API.

• •GCP firewall rules are VPC-level with target filtering by network tags or service accounts; OpenStack security groups attach to ports.
• •GCP rules are stateful (implied return traffic); OpenStack security groups also stateful but per Neutron port.
• •GCP firewall supports priority (0-65535) with explicit deny rules; OpenStack security groups are allow-only (implicit deny).
• •GCP hierarchical firewall policies apply org/folder-wide; OpenStack has no equivalent scope.

• •GKE provides Autopilot mode with fully managed node provisioning and scaling by Google; on Quake AI you provision clusters through Magnum or self-managed Kubernetes on Nova instances and manage node scaling yourself.
• •Control plane is fully managed with automatic upgrades through release channels; Quake AI requires user-provisioned and user-managed control plane nodes.
• •Cluster creation uses gcloud CLI vs OpenStack CLI (openstack coe cluster create).
• •Custom machine types, spot VMs, accelerators in node pools; Quake AI K8s nodes use standard Nova flavors.

• •Per-hour cluster platform fee with a free tier allowance; Autopilot offers pod-based billing as an alternative model. On Quake AI, whether you use Magnum or self-managed Kubernetes, you pay only for the underlying Nova instances and associated resources, with no Kubernetes platform fee.
• •Separate Cloud Billing Account linked to multiple projects, with self-serve/invoiced, postpay/prepay cycles; OpenStack typically uses external billing systems integrated via usage notifications, no built-in account.
• •Payments via Google Payments Profile (cards/ACH/wire); OpenStack has no native payment processing.
• •Billing-specific IAM roles (e.g., Billing Account Creator) inherited from Org; OpenStack quotas/usage per project via Keystone/Nova, no billing IAM.

• •GCP bills all VM instances per second with no minimum charge per instance. Sustained use discounts apply automatically (up to 30% discount) after using an instance for more than 25% of a month; no commitment required and no OpenStack equivalent.
• •GCP pricing is not embedded in the machine type API; it requires the Cloud Billing Catalog API (GET /v1/services/{serviceId}/skus) or the Pricing Calculator.
• •GCP bills network egress by destination: egress to internet by region (varies), within-region egress is free. Quake AI's egress pricing is operator-defined.
• •Preemptible (now Spot) VMs on GCP offer up to 91% discount with no-notice termination. OpenStack does not natively support preemptible or spot instances.

• •Public images shareable across projects (e.g. debian-cloud); OpenStack typically tenant-private.
• •Image families point to latest version; no OpenStack equivalent.
• •Custom images stored in Cloud Storage with licensing fees for premium OS.

• •Organized by families/series (e.g. N2 general-purpose); OpenStack flavors flat list.
• •Custom types +5% premium for N/E series; no such billing in OpenStack.
• •Naming 'n2-standard-4'; shared-core bursting types absent in OpenStack.

• •GCP has no subscription concept. A Billing Account is linked to one or more Projects; usage across linked projects is aggregated and invoiced together. OpenStack projects do not have a native billing account concept.
• •GCP Billing Accounts can be linked to up to 5 projects by default (quota increase required for more); each project can only have one billing account. OpenStack projects have no billing account concept built in.
• •GCP Projects are resource containers and quota boundaries; the Billing Account is purely a financial construct. OpenStack projects serve both purposes (resource isolation and, in some deployments, billing isolation).
• •GCP billing exports to BigQuery are a first-class feature for cost analysis at the billing account level. No OpenStack equivalent; billing data requires custom instrumentation.

• •GCP VMs have network interfaces attached at creation; OpenStack ports are explicit Neutron resources manageable independently.
• •GCP multi-NIC VMs require one interface per VPC (max 8); OpenStack supports multiple ports on same or different networks.
• •GCP alias IP ranges allow multiple IPs per interface without additional resources; OpenStack uses allowed_address_pairs.

• •GCP bucket-level enable, auto live/noncurrent via generation/metageneration, DELETE noncurrent permanent (w/gen), costs all versions + lifecycle mgmt; Swift container-level X-Versions/Histor y-Location modes (archive on PUT/DELETE, naming <len>obj/ts>), middleware required, DELETE behavior mode-dependent (restore vs archive).
• •GCP soft delete separate/interactive; Swift no soft delete mention.
• •GCP no manifest versioning; Swift same.
• •GCP disable retains versions; Swift similar.

• •Organizations auto-provisioned for Google Workspace/Cloud Identity accounts with immutable owner directory ID; OpenStack domains are manually created without such tight identity coupling.
• •Single org per company as root with Folders for sub-grouping (e.g., departments); OpenStack lacks native multi-level folders, using domains/projects.
• •Central point for IAM policy inheritance to all descendants and organization policies (constraints); Keystone domain-scoped assignments don't inherit multi-level.

• •Uses Google Compute Engine REST API instead of OpenStack Cinder API.
• •Offers multiple performance tiers (pd-standard HDD, pd-balanced SSD, pd-ssd, pd-extreme) with performance scaling linearly with provisioned size, unlike Cinder's backend-dependent performance.
• •Supports regional disks replicated synchronously across 2 zones for higher availability (better than 99.9999% durability), while Cinder volumes are typically zonal unless using replication features.
• •Online resize to increase size without detaching; no manual striping/RAID needed as GCP handles distribution automatically.

• •GCP Projects have both human-readable Project ID (custom) and auto-generated numeric Project Number, used interchangeably in APIs unlike OpenStack projects which use single ID.
• •Projects required to enable billing and host all service resources; no direct equivalent to OpenStack's billing per project without linking to Billing Account.
• •Projects inherit IAM policies from Org/Folders; moving project changes inheritance, unlike flat OpenStack project isolation.

• •MIGs offer autoscaling, autohealing, rolling updates via templates; OpenStack only scheduling policies (affinity etc.).
• •Zonal/regional with HA/load balancing integration; no management in OpenStack groups.
• •App health checks trigger recreation; requires external orchestration in OpenStack.

• •Managed in project/instance metadata or OS Login (IAM); no central 'keypairs' resource like Nova.
• •Auto-generates ephemeral keys for CLI/console; manual upload only in OpenStack.
• •Public key includes username suffix; injected differently.

• •Crash-consistent point-in-time copies stored incrementally in Cloud Storage (geo-redundant by default), unlike Cinder snapshots which depend on backend (often full copies).
• •Two types: Standard (faster recovery) and Archive (cheaper long-term); supports snapshot schedules (standard only).
• •Global by default, shareable across projects/regions/zones with network egress costs for cross-region restore; regional scoping (preview) for location control.
• •Frequency limit: max 6 snapshots per disk every 60 minutes.

• •GCP static IPs are regional or global resources, with unassociated IPs metered per-hour; OpenStack floating IPs are pool-based. See the GCP pricing page for current rates.
• •GCP supports both ephemeral (auto-released on stop) and static IPs; OpenStack floating IPs are always explicit.
• •GCP global static IPs used with global load balancers only; no direct OpenStack equivalent.

• •GCP subnets are regional (cover all zones in a region); OpenStack subnets are project-scoped within a network.
• •GCP supports secondary IP ranges for alias IPs/GKE pods; OpenStack subnets have single CIDR.
• •GCP private Google access allows VMs without external IPs to reach Google APIs; OpenStack has no equivalent.

• •Uses HCL with google_compute_instance, google_storage_bucket etc.; Quake AI uses the OpenStack Terraform/OpenTofu provider with openstack_compute_instance_v2 and equivalent resources.
• •Remote state stored in GCS backend; OpenStack uses Terraform state stored locally or in S3-compatible backend.

• •Uses REST API 'instances.insert' instead of Nova 'servers.create' with different auth via service accounts vs Keystone.
• •Supports bare metal instances (no hypervisor), not in standard OpenStack Nova.
• •Network interfaces tied to VPC subnets; differs from Neutron ports/floating IPs.

• •GCP VPC is global (spans all regions) whereas OpenStack Neutron networks are project-scoped and region-local.
• •GCP uses shared VPC for cross-project networking (requires org-level config); OpenStack uses shared networks via admin.
• •Subnets in GCP are regional, auto-mode creates one per region automatically; OpenStack requires explicit subnet creation.
• •GCP VPC Flow Logs per-subnet; OpenStack has no native equivalent without external tools.

• •Per-cluster Neutron networks + floating IPs; GKE shared VPC with alias IP ranges.
• •Kubernetes LoadBalancer behavior replaces Google Cloud Load Balancers after migration.

• •Direct disk-to-disk cloning (zonal-to-zonal or zonal-to-regional) without intermediate snapshot, synchronous and instantly usable (regional averages 3 min to full sync).
• •Must match source disk type; rate limits (1 every 30s, 1000 per lineage); clone size >= source.
• •Cross-project supported via full resource path; source VM cannot power on during clone.
• •API uses compute.disks.insert with sourceDisk field, differing from Cinder's clone volume API.

• •Uses Google Compute Engine REST API instead of OpenStack Cinder API.
• •Offers multiple performance tiers (pd-standard HDD, pd-balanced SSD, pd-ssd, pd-extreme) with performance scaling linearly with provisioned size, unlike Cinder's backend-dependent performance.
• •Supports regional disks replicated synchronously across 2 zones for higher availability (better than 99.9999% durability), while Cinder volumes are typically zonal unless using replication features.
• •Online resize to increase size without detaching; no manual striping/RAID needed as GCP handles distribution automatically.

• •Role-based with predefined/custom roles (permissions as service.resource.verb); Keystone uses simpler flat roles assigned to user-project/domain pairs without granular permissions.
• •Hierarchical inheritance across Org > Folder > Project; OpenStack Keystone assignments scoped per project/domain without automatic inheritance.
• •Supports IAM Conditions for attribute/time-based access, deny policies, VPC Service Controls; no direct OpenStack equivalent.
• •Principals include Google groups/service accounts/federated; Keystone uses local users/groups with federation add-ons.

• •GCP offers external and internal, global and regional, HTTP, TCP, and UDP load balancers. Quake AI workloads use a self-managed reverse proxy or Kubernetes LoadBalancer Service.
• •GCP global HTTP(S) load balancing uses one anycast IP across regions. Self-managed Quake AI edges use the public IP and topology you provision.
• •GCP integrates Cloud CDN, Cloud Armor (WAF/DDoS) with LBs; OpenStack has no native CDN/WAF integration.
• •GCP backend services use health checks and instance groups or NEGs. Self-managed Quake AI edges use proxy upstreams or Kubernetes service selectors.

• •GCP Cloud NAT is a managed service on top of Cloud Router; OpenStack SNAT is built into the L3 router agent/OVN.
• •GCP NAT supports port allocation (static/dynamic), min/max ports per VM; OpenStack SNAT allocates ports dynamically.
• •GCP NAT Gateway billed per hour + per GB processed; OpenStack SNAT is typically included in router costs.

• •GCP Cloud Router is a BGP speaker for dynamic route exchange with VPN/Interconnect; OpenStack routers are L3 gateways with static routes.
• •GCP routers enable Cloud NAT but are separate resources; OpenStack router SNAT is built into the router service.
• •GCP routers regional, created per region for VPN/Interconnect; OpenStack routers can be shared/distributed across AZs.

• •GCP Cloud Storage has an S3-compatible XML API at storage.googleapis.com; auth uses HMAC keys generated separately from GCP service account credentials. Quake AI uses EC2-style credentials (access key + secret) generated via Keystone POST /v3/users/{user_id}/credentials/OS-EC2.
• •GCP S3 XML API endpoint is storage.googleapis.com (path-style); Quake AI endpoint is provider-specific. GCP does not support S3 multipart upload via the XML API — the GCS resumable upload API must be used instead. Quake AI's Swift s3api supports S3 multipart upload.
• •IAM policies on GCS buckets cannot be managed via S3 ACL API calls through the compatibility layer; bucket IAM must be managed via GCP-native tooling (gcloud, Resource Manager API).
• •GCP HMAC keys inherit all permissions of the associated service account with no ability to restrict to a subset of operations. Keystone EC2 credentials inherit the Keystone role of the user who creates them.

No specific divergences documented yet.

• •GCP always-on AES-256-GCM Google-managed (no config), +CMEK/CSEK; Swift optional proxy middleware (keymaster+encryption), AES-256-CTR on body/ETag/user-meta (plaintext client→encrypt cluster), requires root secret config/daemon.
• •GCP encrypts metadata/checksums; Swift selective (no names/size/sysmeta).
• •GCP auto decrypt reads; Swift decrypts GET/HEAD w/ keymaster.
• •GCP client optional; Swift recommends client-side for transit+storage.

• •Uses YAML configurations with optional Jinja2/Python templates expanded server-side; Quake AI offers Heat (legacy, HOT/YAML) and recommends OpenTofu (HCL) for new work.
• •Resource types named as service.v1.resource (e.g., compute.v1.instance) tied to GCP APIs, vs OpenStack prefixed types like OS::Nova::Server.
• •Single integrated GCP service (no separate API/engine processes); Heat has a multi-service architecture (heat-api, heat-engine) but is legacy. OpenTofu runs client-side with no server component.
• •No additional service fee; bills only for deployed GCP resources, same as OpenStack resources billing via provider.

• •Direct disk-to-disk cloning (zonal-to-zonal or zonal-to-regional) without intermediate snapshot, synchronous and instantly usable (regional averages 3 min to full sync).
• •Must match source disk type; rate limits (1 every 30s, 1000 per lineage); clone size >= source.
• •Cross-project supported via full resource path; source VM cannot power on during clone.
• •API uses compute.disks.insert with sourceDisk field, differing from Cinder's clone volume API.

• •GCP firewall rules are VPC-level with target filtering by network tags or service accounts; OpenStack security groups attach to ports.
• •GCP rules are stateful (implied return traffic); OpenStack security groups also stateful but per Neutron port.
• •GCP firewall supports priority (0-65535) with explicit deny rules; OpenStack security groups are allow-only (implicit deny).
• •GCP hierarchical firewall policies apply org/folder-wide; OpenStack has no equivalent scope.

• •GKE provides Autopilot mode with fully managed node provisioning and scaling by Google; on Quake AI you provision clusters through Magnum or self-managed Kubernetes on Nova instances and manage node scaling yourself.
• •Control plane is fully managed with automatic upgrades through release channels; Quake AI requires user-provisioned and user-managed control plane nodes.
• •Cluster creation uses gcloud CLI vs OpenStack CLI (openstack coe cluster create).
• •Custom machine types, spot VMs, accelerators in node pools; Quake AI K8s nodes use standard Nova flavors.

• •Per-hour cluster platform fee with a free tier allowance; Autopilot offers pod-based billing as an alternative model. On Quake AI, whether you use Magnum or self-managed Kubernetes, you pay only for the underlying Nova instances and associated resources, with no Kubernetes platform fee.
• •Separate Cloud Billing Account linked to multiple projects, with self-serve/invoiced, postpay/prepay cycles; OpenStack typically uses external billing systems integrated via usage notifications, no built-in account.
• •Payments via Google Payments Profile (cards/ACH/wire); OpenStack has no native payment processing.
• •Billing-specific IAM roles (e.g., Billing Account Creator) inherited from Org; OpenStack quotas/usage per project via Keystone/Nova, no billing IAM.

• •GCP bills all VM instances per second with no minimum charge per instance. Sustained use discounts apply automatically (up to 30% discount) after using an instance for more than 25% of a month; no commitment required and no OpenStack equivalent.
• •GCP pricing is not embedded in the machine type API; it requires the Cloud Billing Catalog API (GET /v1/services/{serviceId}/skus) or the Pricing Calculator.
• •GCP bills network egress by destination: egress to internet by region (varies), within-region egress is free. Quake AI's egress pricing is operator-defined.
• •Preemptible (now Spot) VMs on GCP offer up to 91% discount with no-notice termination. OpenStack does not natively support preemptible or spot instances.

• •Public images shareable across projects (e.g. debian-cloud); OpenStack typically tenant-private.
• •Image families point to latest version; no OpenStack equivalent.
• •Custom images stored in Cloud Storage with licensing fees for premium OS.

• •Organized by families/series (e.g. N2 general-purpose); OpenStack flavors flat list.
• •Custom types +5% premium for N/E series; no such billing in OpenStack.
• •Naming 'n2-standard-4'; shared-core bursting types absent in OpenStack.

• •GCP has no subscription concept. A Billing Account is linked to one or more Projects; usage across linked projects is aggregated and invoiced together. OpenStack projects do not have a native billing account concept.
• •GCP Billing Accounts can be linked to up to 5 projects by default (quota increase required for more); each project can only have one billing account. OpenStack projects have no billing account concept built in.
• •GCP Projects are resource containers and quota boundaries; the Billing Account is purely a financial construct. OpenStack projects serve both purposes (resource isolation and, in some deployments, billing isolation).
• •GCP billing exports to BigQuery are a first-class feature for cost analysis at the billing account level. No OpenStack equivalent; billing data requires custom instrumentation.

• •GCP VMs have network interfaces attached at creation; OpenStack ports are explicit Neutron resources manageable independently.
• •GCP multi-NIC VMs require one interface per VPC (max 8); OpenStack supports multiple ports on same or different networks.
• •GCP alias IP ranges allow multiple IPs per interface without additional resources; OpenStack uses allowed_address_pairs.

• •GCP bucket-level enable, auto live/noncurrent via generation/metageneration, DELETE noncurrent permanent (w/gen), costs all versions + lifecycle mgmt; Swift container-level X-Versions/Histor y-Location modes (archive on PUT/DELETE, naming <len>obj/ts>), middleware required, DELETE behavior mode-dependent (restore vs archive).
• •GCP soft delete separate/interactive; Swift no soft delete mention.
• •GCP no manifest versioning; Swift same.
• •GCP disable retains versions; Swift similar.

• •Organizations auto-provisioned for Google Workspace/Cloud Identity accounts with immutable owner directory ID; OpenStack domains are manually created without such tight identity coupling.
• •Single org per company as root with Folders for sub-grouping (e.g., departments); OpenStack lacks native multi-level folders, using domains/projects.
• •Central point for IAM policy inheritance to all descendants and organization policies (constraints); Keystone domain-scoped assignments don't inherit multi-level.

• •Uses Google Compute Engine REST API instead of OpenStack Cinder API.
• •Offers multiple performance tiers (pd-standard HDD, pd-balanced SSD, pd-ssd, pd-extreme) with performance scaling linearly with provisioned size, unlike Cinder's backend-dependent performance.
• •Supports regional disks replicated synchronously across 2 zones for higher availability (better than 99.9999% durability), while Cinder volumes are typically zonal unless using replication features.
• •Online resize to increase size without detaching; no manual striping/RAID needed as GCP handles distribution automatically.

• •GCP Projects have both human-readable Project ID (custom) and auto-generated numeric Project Number, used interchangeably in APIs unlike OpenStack projects which use single ID.
• •Projects required to enable billing and host all service resources; no direct equivalent to OpenStack's billing per project without linking to Billing Account.
• •Projects inherit IAM policies from Org/Folders; moving project changes inheritance, unlike flat OpenStack project isolation.

• •MIGs offer autoscaling, autohealing, rolling updates via templates; OpenStack only scheduling policies (affinity etc.).
• •Zonal/regional with HA/load balancing integration; no management in OpenStack groups.
• •App health checks trigger recreation; requires external orchestration in OpenStack.

• •Managed in project/instance metadata or OS Login (IAM); no central 'keypairs' resource like Nova.
• •Auto-generates ephemeral keys for CLI/console; manual upload only in OpenStack.
• •Public key includes username suffix; injected differently.

• •Crash-consistent point-in-time copies stored incrementally in Cloud Storage (geo-redundant by default), unlike Cinder snapshots which depend on backend (often full copies).
• •Two types: Standard (faster recovery) and Archive (cheaper long-term); supports snapshot schedules (standard only).
• •Global by default, shareable across projects/regions/zones with network egress costs for cross-region restore; regional scoping (preview) for location control.
• •Frequency limit: max 6 snapshots per disk every 60 minutes.

• •GCP static IPs are regional or global resources, with unassociated IPs metered per-hour; OpenStack floating IPs are pool-based. See the GCP pricing page for current rates.
• •GCP supports both ephemeral (auto-released on stop) and static IPs; OpenStack floating IPs are always explicit.
• •GCP global static IPs used with global load balancers only; no direct OpenStack equivalent.

• •GCP subnets are regional (cover all zones in a region); OpenStack subnets are project-scoped within a network.
• •GCP supports secondary IP ranges for alias IPs/GKE pods; OpenStack subnets have single CIDR.
• •GCP private Google access allows VMs without external IPs to reach Google APIs; OpenStack has no equivalent.

• •Uses HCL with google_compute_instance, google_storage_bucket etc.; Quake AI uses the OpenStack Terraform/OpenTofu provider with openstack_compute_instance_v2 and equivalent resources.
• •Remote state stored in GCS backend; OpenStack uses Terraform state stored locally or in S3-compatible backend.

• •Uses REST API 'instances.insert' instead of Nova 'servers.create' with different auth via service accounts vs Keystone.
• •Supports bare metal instances (no hypervisor), not in standard OpenStack Nova.
• •Network interfaces tied to VPC subnets; differs from Neutron ports/floating IPs.

• •GCP VPC is global (spans all regions) whereas OpenStack Neutron networks are project-scoped and region-local.
• •GCP uses shared VPC for cross-project networking (requires org-level config); OpenStack uses shared networks via admin.
• •Subnets in GCP are regional, auto-mode creates one per region automatically; OpenStack requires explicit subnet creation.
• •GCP VPC Flow Logs per-subnet; OpenStack has no native equivalent without external tools.

• •Per-cluster Neutron networks + floating IPs; GKE shared VPC with alias IP ranges.
• •Kubernetes LoadBalancer behavior replaces Google Cloud Load Balancers after migration.

• •Uses YAML configurations with optional Jinja2/Python templates expanded server-side; Quake AI offers Heat (legacy, HOT/YAML) and recommends OpenTofu (HCL) for new work.
• •Resource types named as service.v1.resource (e.g., compute.v1.instance) tied to GCP APIs, vs OpenStack prefixed types like OS::Nova::Server.
• •Single integrated GCP service (no separate API/engine processes); Heat has a multi-service architecture (heat-api, heat-engine) but is legacy. OpenTofu runs client-side with no server component.
• •No additional service fee; bills only for deployed GCP resources, same as OpenStack resources billing via provider.

• •Uses HCL with google_compute_instance, google_storage_bucket etc.; Quake AI uses the OpenStack Terraform/OpenTofu provider with openstack_compute_instance_v2 and equivalent resources.
• •Remote state stored in GCS backend; OpenStack uses Terraform state stored locally or in S3-compatible backend.

• •Role-based with predefined/custom roles (permissions as service.resource.verb); Keystone uses simpler flat roles assigned to user-project/domain pairs without granular permissions.
• •Hierarchical inheritance across Org > Folder > Project; OpenStack Keystone assignments scoped per project/domain without automatic inheritance.
• •Supports IAM Conditions for attribute/time-based access, deny policies, VPC Service Controls; no direct OpenStack equivalent.
• •Principals include Google groups/service accounts/federated; Keystone uses local users/groups with federation add-ons.

• •Organizations auto-provisioned for Google Workspace/Cloud Identity accounts with immutable owner directory ID; OpenStack domains are manually created without such tight identity coupling.
• •Single org per company as root with Folders for sub-grouping (e.g., departments); OpenStack lacks native multi-level folders, using domains/projects.
• •Central point for IAM policy inheritance to all descendants and organization policies (constraints); Keystone domain-scoped assignments don't inherit multi-level.

• •GCP Projects have both human-readable Project ID (custom) and auto-generated numeric Project Number, used interchangeably in APIs unlike OpenStack projects which use single ID.
• •Projects required to enable billing and host all service resources; no direct equivalent to OpenStack's billing per project without linking to Billing Account.
• •Projects inherit IAM policies from Org/Folders; moving project changes inheritance, unlike flat OpenStack project isolation.

• •Per-hour cluster platform fee with a free tier allowance; Autopilot offers pod-based billing as an alternative model. On Quake AI, whether you use Magnum or self-managed Kubernetes, you pay only for the underlying Nova instances and associated resources, with no Kubernetes platform fee.
• •Separate Cloud Billing Account linked to multiple projects, with self-serve/invoiced, postpay/prepay cycles; OpenStack typically uses external billing systems integrated via usage notifications, no built-in account.
• •Payments via Google Payments Profile (cards/ACH/wire); OpenStack has no native payment processing.
• •Billing-specific IAM roles (e.g., Billing Account Creator) inherited from Org; OpenStack quotas/usage per project via Keystone/Nova, no billing IAM.

• •GCP bills all VM instances per second with no minimum charge per instance. Sustained use discounts apply automatically (up to 30% discount) after using an instance for more than 25% of a month; no commitment required and no OpenStack equivalent.
• •GCP pricing is not embedded in the machine type API; it requires the Cloud Billing Catalog API (GET /v1/services/{serviceId}/skus) or the Pricing Calculator.
• •GCP bills network egress by destination: egress to internet by region (varies), within-region egress is free. Quake AI's egress pricing is operator-defined.
• •Preemptible (now Spot) VMs on GCP offer up to 91% discount with no-notice termination. OpenStack does not natively support preemptible or spot instances.

• •GCP has no subscription concept. A Billing Account is linked to one or more Projects; usage across linked projects is aggregated and invoiced together. OpenStack projects do not have a native billing account concept.
• •GCP Billing Accounts can be linked to up to 5 projects by default (quota increase required for more); each project can only have one billing account. OpenStack projects have no billing account concept built in.
• •GCP Projects are resource containers and quota boundaries; the Billing Account is purely a financial construct. OpenStack projects serve both purposes (resource isolation and, in some deployments, billing isolation).
• •GCP billing exports to BigQuery are a first-class feature for cost analysis at the billing account level. No OpenStack equivalent; billing data requires custom instrumentation.