• •Azure automatically provisions and manages the control plane at no additional cost (Free tier) or fixed fee (Standard tier with SLA), offloading health monitoring and upgrades; on Quake AI you provision a cluster through Magnum (openstack coe cluster create) or self-managed Kubernetes on Nova instances (OpenTofu plus kubeadm, k3s, or RKE2), and you operate the cluster after creation.
• •No OpenStack integration; uses Azure Resource Manager for cluster lifecycle.
• •Pre-configured with Azure-specific defaults and add-ons like application routing.
• •Managed via Azure Virtual Machine Scale Sets (VMSS) with auto-scaling and upgrades; Quake AI uses Nova instances provisioned via OpenTofu with user-managed scaling and upgrades.

• •Azure CNI or kubenet, integrates Azure Load Balancer/Application Gateway; Quake AI Kubernetes clusters use Neutron private networks and routers with CNI plugins (Flannel, Calico, Cilium).
• •Bring-your-own CNI supported; Quake AI tenant-isolated Neutron.
• •Azure-specific: Application routing add-on (nginx), no native Neutron.

• •Uses fault/update domains (max 3/20) for HA, fixed at creation, vs flexible OpenStack server group policies (affinity/anti-affinity).
• •ARM resource (Microsoft.Compute/availabilitySets), VMs assigned at create, no dynamic move.
• •No extra cost, but requires 2+ VMs for SLA; prefers zones/scale sets.
• •Lower latency between VMs in set vs zones, hardware-specific isolation.

• •Consumption-based metered billing via Microsoft Commerce pipeline with rated usage, monthly invoices, discounts/reservations; OpenStack has no built-in billing, relies on add-ons like CloudKitty for rating/chargeback.
• •Scopes include subscriptions/RGs for cost analysis, anomaly detection, budgets; OpenStack usage collected via Ceilometer, rated externally.
• •Enterprise Agreements/MCA with complex scopes (billing profiles); OpenStack operator-defined.
• •Cost Management + Billing portal for payments/invoices; OpenStack requires custom integration.

• •Azure requires choosing between generalized (sysprep'd, removes machine identity, destroys the source VM's bootability) and specialized (exact clone, source VM survives). OpenStack Nova createImage is always non-destructive — the server continues running and the image captures the current disk state.
• •Capturing a generalized Azure image requires running waagent -deprovision inside the VM, then deallocating and marking as generalized (az vm generalize) before capture — a multi-step destructive process. OpenStack createImage (POST /v2.1/servers/{id}/action {"createImage": {...}}) requires no VM shutdown.
• •Azure stores instance images in Azure Compute Gallery with versioning and multi-region replication support. Glance stores images with no built-in versioning (images are replaced or new images created).
• •Azure ARM API for capture: POST /providers/Microsoft.Compute/virtualMachines/{vm}/capture (legacy) or via Compute Gallery image versions. Nova API: POST /v2.1/servers/{id}/action.

• •Organized in galleries with image definitions and versioned images (Microsoft.Compute/galleries/images/versions), more structured than flat Glance images.
• •Supports global replication to regions with replicas (up to 100), ZRS storage, unlike OpenStack's store-only model.
• •Sharing via RBAC, community galleries, or direct share; requires gallery setup vs simple OpenStack image sharing.
• •New features like Trusted Launch only in Gallery, legacy managed images deprecated.

• •Pure L4 (TCP/UDP) pass-through; no L7 features (use App Gateway) ().
• •SKUs: Standard w/ zones/HA, health probes, outbound SNAT rules; Basic free but retiring 2025.
• •Azure provides a regional managed service integrated with VNets. Quake AI workloads use a self-managed reverse proxy or Kubernetes LoadBalancer Service.
• •API via ARM; frontend configs w/ multiple IPs/ports.

• •Azure Managed Disks are fully managed with automatic redundancy (3 replicas, 99.999% SLA); Cinder durability depends on backend.
• •Predefined disk types (Ultra Disk, Premium SSD v2, Premium SSD, Standard SSD, Standard HDD) with fixed performance tiers; Cinder uses volume types with configurable QoS.
• •Disks billed on provisioned size regardless of use; Cinder billing typically on provisioned size too but varies by provider.

• •Azure bills Linux VMs per second; pricing is not included in the VM size API and requires the Azure Retail Prices API (GET https://prices.azure.com/api/retail/prices) or the Pricing Calculator.
• •Azure Hybrid Benefit allows using on-premises Windows Server and SQL Server licenses to reduce Azure VM costs; no equivalent in OpenStack.
• •Azure pricing includes Basic, Standard, and Premium tiers for many services (load balancers, public IPs) with different SLAs per tier. Quake AI uses a flat pricing model without service tiers.
• •Azure reserved instances (1-year or 3-year commitments) offer up to 72% discount vs. on-demand. Quake AI does not currently offer reserved capacity pricing.

• •Azure uses RBAC/ABAC with Entra ID (AAD), SAS, shared keys; Quake AI/OpenStack Swift S3 uses Keystone/S3 token auth mapped to Swift ACLs, bucket policies via s3api middleware.
• •Azure granular roles/conditions at account/container/blob; Swift ACLs are read/write/ACL granularities per account/container.
• •Azure recommends Entra over keys; Swift s3api translates S3 auth to Swift accounts.

• •Authoring format differs: ARM templates are JSON documents for Azure Resource Manager deployments, whereas Quake AI offers Heat (legacy, HOT/YAML format) and recommends OpenTofu (HCL) for new infrastructure automation.
• •Deployment target/scope differs: ARM templates can deploy at multiple scopes (resource group, subscription, management group, tenant) via Azure Resource Manager's management layer, while Heat orchestrates within a single OpenStack project/tenant. OpenTofu can target multiple projects via provider configuration.
• •Change-preview behavior differs: ARM supports a built-in “what-if” style preview of changes via Resource Manager deployments, while OpenTofu provides `tofu plan` for change previews. Heat relies on stack update events (legacy workflow).
• •Resource coverage lifecycle differs: ARM templates support Azure resource types exposed by Azure resource providers; OpenTofu covers OpenStack resource types via the OpenStack provider, and Heat (legacy) supports a narrower set via built-in resource plugins.

• •Resource Groups store metadata in a specific region and support resources from multiple regions; OpenStack lacks formal grouping beyond projects, resources directly scoped to projects.
• •Built-in features like ARM locks (Read-only/Delete), integrated tags for cost allocation, and deployment history views; OpenStack uses project quotas and locks via extensions, no native group-level deployments.
• •Lifecycle management: Easy group delete/update via ARM templates; OpenStack deletes resources individually or via OpenTofu destroy/Heat stacks scoped to projects.
• •Portal views aggregate metrics/deployments across group; OpenStack Horizon shows per-project.

• •Azure supports automated tiering (hot/cool/cold/archive) and expiration rules based on age, access time; Quake AI Swift S3 API lacks native lifecycle management per official OpenStack docs and no Quake AI-specific extension found.
• •Azure policies apply account-wide or filtered by prefix/tags; Swift requires external cron/object-expirer daemon for deletes, no built-in tiering.
• •Azure charges for tiering API calls; Swift has no equivalent billing as feature missing.

• •Both support versioning via S3 API in Quake AI and Blob REST API in Azure, but Azure automatic on write/delete for supported accounts; Swift native uses container headers (X-Versions-Location) requiring archive container, two modes differing on DELETE behavior.
• •Azure versions immutable, one current version; Swift POST metadata doesn't version, DELETE promotes or moves to history based on mode.
• •Azure integrates with soft delete/lifecycle; Swift S3 emulation may differ in delete markers/version listing behaviors from pure S3.

• •Azure cloning via 'az disk create --source' from disk ID or snapshot, supports cross-subscription/region with grants; Cinder uses 'cinder create --source-volid' or from snapshot, backend-local unless multi-backend.
• •No direct thin-clone in Azure (full copy via snapshot); Cinder supports thin cloning depending on backend (e.g., Ceph clone).
• •Azure copy requires same region for direct source ID use, cross-region via snapshot export/import; Cinder cloning typically same backend.

• •Azure's organization model is a four-level hierarchy: Tenant (Entra ID) → Management Groups → Subscriptions → Resource Groups. OpenStack uses a two-level model: Domain → Project. Quake AI exposes Projects within an Organization.
• •Azure Management Groups support up to 10,000 groups with 6 levels of depth; policy and RBAC assigned at a management group cascade to all child subscriptions. OpenStack has no equivalent cascading policy inheritance between projects.
• •Azure subscriptions are both billing containers and resource containers; each has its own cost center and invoice. OpenStack projects are resource containers only; billing is aggregated at the account level.
• •Azure resources must be placed in both a Subscription and a Resource Group; no resource exists outside a Resource Group. OpenStack resources belong to a project with no resource group concept.

• •Proprietary Microsoft identity platform with OAuth2/OIDC, MSAL libraries, Microsoft Graph API integration; OpenStack Keystone provides OpenStack-specific token auth with pluggable backends (LDAP/SQL).
• •Entra ID supports external identities (B2B/B2C), social logins (Google/Facebook); Keystone focuses on domain/project/role auth, federation via SAML/OIDC possible but secondary.
• •Integrated with Azure subscriptions (one tenant per sub); Keystone is deployment-wide, not subscription-scoped.
• •Advanced features like PIM, app provisioning; OpenStack roles are simpler, assigned per project.

• •Azure Blob Storage has no native S3-compatible endpoint; S3 compatibility requires third-party gateways (Flexify.IO, S3Proxy). Applications using AWS SDK pointing at Quake AI's S3 endpoint require zero code changes; migrating to Azure Blob requires SDK replacement (azure-storage-blob).
• •Azure Blob uses a different REST API with Azure-specific URL paths and x-ms-* headers; Quake AI's S3 endpoint uses standard AWS SigV4 authentication with EC2 credentials issued by Keystone.
• •Azure Blob's hierarchy is Storage Account → Container → Blob; Quake AI's Swift S3 layer maps S3 Buckets to Swift containers and Keys to objects, preserving the S3 mental model.
• •Azure auth uses Shared Access Signatures (SAS) or Azure AD RBAC; Quake AI's S3 endpoint uses AWS SigV4 with project-scoped access key/secret pairs (EC2 credentials in Keystone).

• •Managed subnet-level service w/ dynamic SNAT ports (no exhaustion), up to 16 static Public IPs ().
• •Highest precedence over LB/instance Public IP; zonal/zone-redundant SKUs; billed.
• •No router namespace; scales to 100Gbps; TCP/UDP only vs OpenStack L3 agent/OVN router SNAT.
• •Subnet attachment (one per subnet); overrides default Internet route.

No specific divergences documented yet.

• •NSGs can associate to both subnets and NICs with specific processing order (inbound: subnet then NIC; outbound: NIC then subnet) ().
• •Stateful with priority-based rules (100-4096); augmented rules allow multiple IPs/ports per rule (Resource Manager only).
• •Default rules allow VNet/LB/Internet out; service tags like VirtualNetwork.
• •No direct port-level only like OpenStack; subnet-level affects all instances.

• •Public IP is a dedicated ARM resource with SKUs (Basic/Standard); IPv4 billed, IPv6 free ().
• •Static/dynamic allocation (Standard static only); zone-redundant option (Standard v2).
• •Associated directly to NIC/LB/gateway vs via router DNAT in OpenStack.
• •Dynamic outbound uses ephemeral IPs even without assoc; no pool allocation like Neutron external nets.

• •Snapshots of managed disks (Microsoft.Compute/snapshots), billed on used size, separate from volumes unlike Cinder volume snapshots integration.
• •Supports incremental snapshots for efficiency, ZRS storage in zones.
• •API /providers/Microsoft.Compute/snapshots vs Nova/Cinder volume snapshot APIs.
• •Primarily for disks, not full instances; instance snapshots via images instead.

• •Managed as ARM resources (Microsoft.Compute/sshPublicKeys), reusable across VMs, vs OpenStack's keypairs injected only at boot.
• •API /providers/Microsoft.Compute/sshPublicKeys, supports ED25519/RSA, no private key storage.
• •Keys provided during VM create or via portal/CLI, not listed/injected separately post-boot like OpenStack.
• •No deletion/re-import of injected keys; new VM for changes.

• •Both SSE transparent; Azure SSE default with Microsoft-managed keys (256-bit AES), optional CMK in Key Vault/CPK/client-side; Swift encryption middleware (AES-256 CTR) derives keys from root secret, internal not API-exposed.
• •Azure scopes keys to account, container, or blob and integrates Key Vault. Swift can encrypt object data and metadata at the storage layer.
• •Azure client-side explicit in SDKs; Swift recommends client-side for full protection, server-side mitigates disk theft.

• •Uses azurerm_virtual_machine/azurerm_linux_virtual_machine; OpenStack uses openstack_compute_instance_v2.
• •AzureRM provider requires subscription_id, tenant_id, client_id, client_secret; OpenStack uses auth_url and application credentials.

• •Uses Azure Resource Manager (ARM) REST API at /providers/Microsoft.Compute/virtualMachines instead of OpenStack Nova API at /v2.1/servers.
• •Tightly integrated with Azure services like Azure Active Directory for authentication, unlike OpenStack's Keystone.
• •VM creation requires specifying size from predefined series with hardware-specific features (e.g., AMD/Intel/ARM), not custom flavor configs.
• •Billed per second with complex pricing tiers based on series/reservation options, vs OpenStack's typically hourly or usage-based.

• •Azure VNets are strictly regional Layer 3 overlays scoped to one subscription with no L2 VLAN support ().
• •VNets and subnets creation free, but subnets min /29 with Azure reserving 5 IPs per subnet ().
• •Managed via ARM REST APIs/PowerShell/CLI vs Neutron REST API.
• •Isolated per subscription; peering for cross-VNet connectivity vs OpenStack project networks connected via routers.

No specific divergences documented yet.

• •Azure subnets are child resources of a Virtual Network defined as /providers/Microsoft.Network/virtualNetworks/{vnet}/subnets/{subnet}; Neutron subnets are top-level resources with their own UUIDs associated to a network via network_id.
• •Azure subnets support service endpoints (for Azure Storage, SQL) and delegations (reserving a subnet for specific Azure services) with no Neutron equivalent.
• •Azure subnet CIDR cannot overlap with other subnets in the same VNet or peered VNets and is immutable after creation; Neutron supports updating allocation pools but not the CIDR block post-creation.
• •Network Security Groups (NSGs) attach at the Azure subnet level (and optionally at NIC level); Neutron security groups attach to ports/interfaces, not to subnets.

• •Predefined hardware-optimized series (e.g., D-family general purpose) with complex naming (e.g., Standard_D4as_v5), not user-defined vCPU/RAM like OpenStack flavors.
• •Sizes listed via API /providers/Microsoft.Compute/locations/{location}/vmSizes, region-specific availability.
• •Includes accelerator features (GPU, FPGA) baked into sizes, unavailable in basic OpenStack flavors without extensions.
• •Cannot create custom sizes; selection from catalog, limiting flexibility vs OpenStack flavor creation.

• •Azure automatically provisions and manages the control plane at no additional cost (Free tier) or fixed fee (Standard tier with SLA), offloading health monitoring and upgrades; on Quake AI you provision a cluster through Magnum (openstack coe cluster create) or self-managed Kubernetes on Nova instances (OpenTofu plus kubeadm, k3s, or RKE2), and you operate the cluster after creation.
• •No OpenStack integration; uses Azure Resource Manager for cluster lifecycle.
• •Pre-configured with Azure-specific defaults and add-ons like application routing.
• •Managed via Azure Virtual Machine Scale Sets (VMSS) with auto-scaling and upgrades; Quake AI uses Nova instances provisioned via OpenTofu with user-managed scaling and upgrades.

• •Azure CNI or kubenet, integrates Azure Load Balancer/Application Gateway; Quake AI Kubernetes clusters use Neutron private networks and routers with CNI plugins (Flannel, Calico, Cilium).
• •Bring-your-own CNI supported; Quake AI tenant-isolated Neutron.
• •Azure-specific: Application routing add-on (nginx), no native Neutron.

• •Uses fault/update domains (max 3/20) for HA, fixed at creation, vs flexible OpenStack server group policies (affinity/anti-affinity).
• •ARM resource (Microsoft.Compute/availabilitySets), VMs assigned at create, no dynamic move.
• •No extra cost, but requires 2+ VMs for SLA; prefers zones/scale sets.
• •Lower latency between VMs in set vs zones, hardware-specific isolation.

• •Consumption-based metered billing via Microsoft Commerce pipeline with rated usage, monthly invoices, discounts/reservations; OpenStack has no built-in billing, relies on add-ons like CloudKitty for rating/chargeback.
• •Scopes include subscriptions/RGs for cost analysis, anomaly detection, budgets; OpenStack usage collected via Ceilometer, rated externally.
• •Enterprise Agreements/MCA with complex scopes (billing profiles); OpenStack operator-defined.
• •Cost Management + Billing portal for payments/invoices; OpenStack requires custom integration.

• •Azure requires choosing between generalized (sysprep'd, removes machine identity, destroys the source VM's bootability) and specialized (exact clone, source VM survives). OpenStack Nova createImage is always non-destructive — the server continues running and the image captures the current disk state.
• •Capturing a generalized Azure image requires running waagent -deprovision inside the VM, then deallocating and marking as generalized (az vm generalize) before capture — a multi-step destructive process. OpenStack createImage (POST /v2.1/servers/{id}/action {"createImage": {...}}) requires no VM shutdown.
• •Azure stores instance images in Azure Compute Gallery with versioning and multi-region replication support. Glance stores images with no built-in versioning (images are replaced or new images created).
• •Azure ARM API for capture: POST /providers/Microsoft.Compute/virtualMachines/{vm}/capture (legacy) or via Compute Gallery image versions. Nova API: POST /v2.1/servers/{id}/action.

• •Organized in galleries with image definitions and versioned images (Microsoft.Compute/galleries/images/versions), more structured than flat Glance images.
• •Supports global replication to regions with replicas (up to 100), ZRS storage, unlike OpenStack's store-only model.
• •Sharing via RBAC, community galleries, or direct share; requires gallery setup vs simple OpenStack image sharing.
• •New features like Trusted Launch only in Gallery, legacy managed images deprecated.

• •Pure L4 (TCP/UDP) pass-through; no L7 features (use App Gateway) ().
• •SKUs: Standard w/ zones/HA, health probes, outbound SNAT rules; Basic free but retiring 2025.
• •Azure provides a regional managed service integrated with VNets. Quake AI workloads use a self-managed reverse proxy or Kubernetes LoadBalancer Service.
• •API via ARM; frontend configs w/ multiple IPs/ports.

• •Azure Managed Disks are fully managed with automatic redundancy (3 replicas, 99.999% SLA); Cinder durability depends on backend.
• •Predefined disk types (Ultra Disk, Premium SSD v2, Premium SSD, Standard SSD, Standard HDD) with fixed performance tiers; Cinder uses volume types with configurable QoS.
• •Disks billed on provisioned size regardless of use; Cinder billing typically on provisioned size too but varies by provider.

• •Azure bills Linux VMs per second; pricing is not included in the VM size API and requires the Azure Retail Prices API (GET https://prices.azure.com/api/retail/prices) or the Pricing Calculator.
• •Azure Hybrid Benefit allows using on-premises Windows Server and SQL Server licenses to reduce Azure VM costs; no equivalent in OpenStack.
• •Azure pricing includes Basic, Standard, and Premium tiers for many services (load balancers, public IPs) with different SLAs per tier. Quake AI uses a flat pricing model without service tiers.
• •Azure reserved instances (1-year or 3-year commitments) offer up to 72% discount vs. on-demand. Quake AI does not currently offer reserved capacity pricing.

• •Azure uses RBAC/ABAC with Entra ID (AAD), SAS, shared keys; Quake AI/OpenStack Swift S3 uses Keystone/S3 token auth mapped to Swift ACLs, bucket policies via s3api middleware.
• •Azure granular roles/conditions at account/container/blob; Swift ACLs are read/write/ACL granularities per account/container.
• •Azure recommends Entra over keys; Swift s3api translates S3 auth to Swift accounts.

• •Authoring format differs: ARM templates are JSON documents for Azure Resource Manager deployments, whereas Quake AI offers Heat (legacy, HOT/YAML format) and recommends OpenTofu (HCL) for new infrastructure automation.
• •Deployment target/scope differs: ARM templates can deploy at multiple scopes (resource group, subscription, management group, tenant) via Azure Resource Manager's management layer, while Heat orchestrates within a single OpenStack project/tenant. OpenTofu can target multiple projects via provider configuration.
• •Change-preview behavior differs: ARM supports a built-in “what-if” style preview of changes via Resource Manager deployments, while OpenTofu provides `tofu plan` for change previews. Heat relies on stack update events (legacy workflow).
• •Resource coverage lifecycle differs: ARM templates support Azure resource types exposed by Azure resource providers; OpenTofu covers OpenStack resource types via the OpenStack provider, and Heat (legacy) supports a narrower set via built-in resource plugins.

• •Resource Groups store metadata in a specific region and support resources from multiple regions; OpenStack lacks formal grouping beyond projects, resources directly scoped to projects.
• •Built-in features like ARM locks (Read-only/Delete), integrated tags for cost allocation, and deployment history views; OpenStack uses project quotas and locks via extensions, no native group-level deployments.
• •Lifecycle management: Easy group delete/update via ARM templates; OpenStack deletes resources individually or via OpenTofu destroy/Heat stacks scoped to projects.
• •Portal views aggregate metrics/deployments across group; OpenStack Horizon shows per-project.

• •Azure supports automated tiering (hot/cool/cold/archive) and expiration rules based on age, access time; Quake AI Swift S3 API lacks native lifecycle management per official OpenStack docs and no Quake AI-specific extension found.
• •Azure policies apply account-wide or filtered by prefix/tags; Swift requires external cron/object-expirer daemon for deletes, no built-in tiering.
• •Azure charges for tiering API calls; Swift has no equivalent billing as feature missing.

• •Both support versioning via S3 API in Quake AI and Blob REST API in Azure, but Azure automatic on write/delete for supported accounts; Swift native uses container headers (X-Versions-Location) requiring archive container, two modes differing on DELETE behavior.
• •Azure versions immutable, one current version; Swift POST metadata doesn't version, DELETE promotes or moves to history based on mode.
• •Azure integrates with soft delete/lifecycle; Swift S3 emulation may differ in delete markers/version listing behaviors from pure S3.

• •Azure cloning via 'az disk create --source' from disk ID or snapshot, supports cross-subscription/region with grants; Cinder uses 'cinder create --source-volid' or from snapshot, backend-local unless multi-backend.
• •No direct thin-clone in Azure (full copy via snapshot); Cinder supports thin cloning depending on backend (e.g., Ceph clone).
• •Azure copy requires same region for direct source ID use, cross-region via snapshot export/import; Cinder cloning typically same backend.

• •Azure's organization model is a four-level hierarchy: Tenant (Entra ID) → Management Groups → Subscriptions → Resource Groups. OpenStack uses a two-level model: Domain → Project. Quake AI exposes Projects within an Organization.
• •Azure Management Groups support up to 10,000 groups with 6 levels of depth; policy and RBAC assigned at a management group cascade to all child subscriptions. OpenStack has no equivalent cascading policy inheritance between projects.
• •Azure subscriptions are both billing containers and resource containers; each has its own cost center and invoice. OpenStack projects are resource containers only; billing is aggregated at the account level.
• •Azure resources must be placed in both a Subscription and a Resource Group; no resource exists outside a Resource Group. OpenStack resources belong to a project with no resource group concept.

• •Proprietary Microsoft identity platform with OAuth2/OIDC, MSAL libraries, Microsoft Graph API integration; OpenStack Keystone provides OpenStack-specific token auth with pluggable backends (LDAP/SQL).
• •Entra ID supports external identities (B2B/B2C), social logins (Google/Facebook); Keystone focuses on domain/project/role auth, federation via SAML/OIDC possible but secondary.
• •Integrated with Azure subscriptions (one tenant per sub); Keystone is deployment-wide, not subscription-scoped.
• •Advanced features like PIM, app provisioning; OpenStack roles are simpler, assigned per project.

• •Azure Blob Storage has no native S3-compatible endpoint; S3 compatibility requires third-party gateways (Flexify.IO, S3Proxy). Applications using AWS SDK pointing at Quake AI's S3 endpoint require zero code changes; migrating to Azure Blob requires SDK replacement (azure-storage-blob).
• •Azure Blob uses a different REST API with Azure-specific URL paths and x-ms-* headers; Quake AI's S3 endpoint uses standard AWS SigV4 authentication with EC2 credentials issued by Keystone.
• •Azure Blob's hierarchy is Storage Account → Container → Blob; Quake AI's Swift S3 layer maps S3 Buckets to Swift containers and Keys to objects, preserving the S3 mental model.
• •Azure auth uses Shared Access Signatures (SAS) or Azure AD RBAC; Quake AI's S3 endpoint uses AWS SigV4 with project-scoped access key/secret pairs (EC2 credentials in Keystone).

• •Managed subnet-level service w/ dynamic SNAT ports (no exhaustion), up to 16 static Public IPs ().
• •Highest precedence over LB/instance Public IP; zonal/zone-redundant SKUs; billed.
• •No router namespace; scales to 100Gbps; TCP/UDP only vs OpenStack L3 agent/OVN router SNAT.
• •Subnet attachment (one per subnet); overrides default Internet route.

No specific divergences documented yet.

• •NSGs can associate to both subnets and NICs with specific processing order (inbound: subnet then NIC; outbound: NIC then subnet) ().
• •Stateful with priority-based rules (100-4096); augmented rules allow multiple IPs/ports per rule (Resource Manager only).
• •Default rules allow VNet/LB/Internet out; service tags like VirtualNetwork.
• •No direct port-level only like OpenStack; subnet-level affects all instances.

• •Public IP is a dedicated ARM resource with SKUs (Basic/Standard); IPv4 billed, IPv6 free ().
• •Static/dynamic allocation (Standard static only); zone-redundant option (Standard v2).
• •Associated directly to NIC/LB/gateway vs via router DNAT in OpenStack.
• •Dynamic outbound uses ephemeral IPs even without assoc; no pool allocation like Neutron external nets.

• •Snapshots of managed disks (Microsoft.Compute/snapshots), billed on used size, separate from volumes unlike Cinder volume snapshots integration.
• •Supports incremental snapshots for efficiency, ZRS storage in zones.
• •API /providers/Microsoft.Compute/snapshots vs Nova/Cinder volume snapshot APIs.
• •Primarily for disks, not full instances; instance snapshots via images instead.

• •Managed as ARM resources (Microsoft.Compute/sshPublicKeys), reusable across VMs, vs OpenStack's keypairs injected only at boot.
• •API /providers/Microsoft.Compute/sshPublicKeys, supports ED25519/RSA, no private key storage.
• •Keys provided during VM create or via portal/CLI, not listed/injected separately post-boot like OpenStack.
• •No deletion/re-import of injected keys; new VM for changes.

• •Both SSE transparent; Azure SSE default with Microsoft-managed keys (256-bit AES), optional CMK in Key Vault/CPK/client-side; Swift encryption middleware (AES-256 CTR) derives keys from root secret, internal not API-exposed.
• •Azure scopes keys to account, container, or blob and integrates Key Vault. Swift can encrypt object data and metadata at the storage layer.
• •Azure client-side explicit in SDKs; Swift recommends client-side for full protection, server-side mitigates disk theft.

• •Uses azurerm_virtual_machine/azurerm_linux_virtual_machine; OpenStack uses openstack_compute_instance_v2.
• •AzureRM provider requires subscription_id, tenant_id, client_id, client_secret; OpenStack uses auth_url and application credentials.

• •Uses Azure Resource Manager (ARM) REST API at /providers/Microsoft.Compute/virtualMachines instead of OpenStack Nova API at /v2.1/servers.
• •Tightly integrated with Azure services like Azure Active Directory for authentication, unlike OpenStack's Keystone.
• •VM creation requires specifying size from predefined series with hardware-specific features (e.g., AMD/Intel/ARM), not custom flavor configs.
• •Billed per second with complex pricing tiers based on series/reservation options, vs OpenStack's typically hourly or usage-based.

• •Azure VNets are strictly regional Layer 3 overlays scoped to one subscription with no L2 VLAN support ().
• •VNets and subnets creation free, but subnets min /29 with Azure reserving 5 IPs per subnet ().
• •Managed via ARM REST APIs/PowerShell/CLI vs Neutron REST API.
• •Isolated per subscription; peering for cross-VNet connectivity vs OpenStack project networks connected via routers.

No specific divergences documented yet.

• •Azure subnets are child resources of a Virtual Network defined as /providers/Microsoft.Network/virtualNetworks/{vnet}/subnets/{subnet}; Neutron subnets are top-level resources with their own UUIDs associated to a network via network_id.
• •Azure subnets support service endpoints (for Azure Storage, SQL) and delegations (reserving a subnet for specific Azure services) with no Neutron equivalent.
• •Azure subnet CIDR cannot overlap with other subnets in the same VNet or peered VNets and is immutable after creation; Neutron supports updating allocation pools but not the CIDR block post-creation.
• •Network Security Groups (NSGs) attach at the Azure subnet level (and optionally at NIC level); Neutron security groups attach to ports/interfaces, not to subnets.

• •Predefined hardware-optimized series (e.g., D-family general purpose) with complex naming (e.g., Standard_D4as_v5), not user-defined vCPU/RAM like OpenStack flavors.
• •Sizes listed via API /providers/Microsoft.Compute/locations/{location}/vmSizes, region-specific availability.
• •Includes accelerator features (GPU, FPGA) baked into sizes, unavailable in basic OpenStack flavors without extensions.
• •Cannot create custom sizes; selection from catalog, limiting flexibility vs OpenStack flavor creation.

• •Azure automatically provisions and manages the control plane at no additional cost (Free tier) or fixed fee (Standard tier with SLA), offloading health monitoring and upgrades; on Quake AI you provision a cluster through Magnum (openstack coe cluster create) or self-managed Kubernetes on Nova instances (OpenTofu plus kubeadm, k3s, or RKE2), and you operate the cluster after creation.
• •No OpenStack integration; uses Azure Resource Manager for cluster lifecycle.
• •Pre-configured with Azure-specific defaults and add-ons like application routing.
• •Managed via Azure Virtual Machine Scale Sets (VMSS) with auto-scaling and upgrades; Quake AI uses Nova instances provisioned via OpenTofu with user-managed scaling and upgrades.

• •Azure CNI or kubenet, integrates Azure Load Balancer/Application Gateway; Quake AI Kubernetes clusters use Neutron private networks and routers with CNI plugins (Flannel, Calico, Cilium).
• •Bring-your-own CNI supported; Quake AI tenant-isolated Neutron.
• •Azure-specific: Application routing add-on (nginx), no native Neutron.

• •Uses fault/update domains (max 3/20) for HA, fixed at creation, vs flexible OpenStack server group policies (affinity/anti-affinity).
• •ARM resource (Microsoft.Compute/availabilitySets), VMs assigned at create, no dynamic move.
• •No extra cost, but requires 2+ VMs for SLA; prefers zones/scale sets.
• •Lower latency between VMs in set vs zones, hardware-specific isolation.

• •Consumption-based metered billing via Microsoft Commerce pipeline with rated usage, monthly invoices, discounts/reservations; OpenStack has no built-in billing, relies on add-ons like CloudKitty for rating/chargeback.
• •Scopes include subscriptions/RGs for cost analysis, anomaly detection, budgets; OpenStack usage collected via Ceilometer, rated externally.
• •Enterprise Agreements/MCA with complex scopes (billing profiles); OpenStack operator-defined.
• •Cost Management + Billing portal for payments/invoices; OpenStack requires custom integration.

• •Azure requires choosing between generalized (sysprep'd, removes machine identity, destroys the source VM's bootability) and specialized (exact clone, source VM survives). OpenStack Nova createImage is always non-destructive — the server continues running and the image captures the current disk state.
• •Capturing a generalized Azure image requires running waagent -deprovision inside the VM, then deallocating and marking as generalized (az vm generalize) before capture — a multi-step destructive process. OpenStack createImage (POST /v2.1/servers/{id}/action {"createImage": {...}}) requires no VM shutdown.
• •Azure stores instance images in Azure Compute Gallery with versioning and multi-region replication support. Glance stores images with no built-in versioning (images are replaced or new images created).
• •Azure ARM API for capture: POST /providers/Microsoft.Compute/virtualMachines/{vm}/capture (legacy) or via Compute Gallery image versions. Nova API: POST /v2.1/servers/{id}/action.

• •Organized in galleries with image definitions and versioned images (Microsoft.Compute/galleries/images/versions), more structured than flat Glance images.
• •Supports global replication to regions with replicas (up to 100), ZRS storage, unlike OpenStack's store-only model.
• •Sharing via RBAC, community galleries, or direct share; requires gallery setup vs simple OpenStack image sharing.
• •New features like Trusted Launch only in Gallery, legacy managed images deprecated.

• •Pure L4 (TCP/UDP) pass-through; no L7 features (use App Gateway) ().
• •SKUs: Standard w/ zones/HA, health probes, outbound SNAT rules; Basic free but retiring 2025.
• •Azure provides a regional managed service integrated with VNets. Quake AI workloads use a self-managed reverse proxy or Kubernetes LoadBalancer Service.
• •API via ARM; frontend configs w/ multiple IPs/ports.

• •Azure Managed Disks are fully managed with automatic redundancy (3 replicas, 99.999% SLA); Cinder durability depends on backend.
• •Predefined disk types (Ultra Disk, Premium SSD v2, Premium SSD, Standard SSD, Standard HDD) with fixed performance tiers; Cinder uses volume types with configurable QoS.
• •Disks billed on provisioned size regardless of use; Cinder billing typically on provisioned size too but varies by provider.

• •Azure bills Linux VMs per second; pricing is not included in the VM size API and requires the Azure Retail Prices API (GET https://prices.azure.com/api/retail/prices) or the Pricing Calculator.
• •Azure Hybrid Benefit allows using on-premises Windows Server and SQL Server licenses to reduce Azure VM costs; no equivalent in OpenStack.
• •Azure pricing includes Basic, Standard, and Premium tiers for many services (load balancers, public IPs) with different SLAs per tier. Quake AI uses a flat pricing model without service tiers.
• •Azure reserved instances (1-year or 3-year commitments) offer up to 72% discount vs. on-demand. Quake AI does not currently offer reserved capacity pricing.

• •Azure uses RBAC/ABAC with Entra ID (AAD), SAS, shared keys; Quake AI/OpenStack Swift S3 uses Keystone/S3 token auth mapped to Swift ACLs, bucket policies via s3api middleware.
• •Azure granular roles/conditions at account/container/blob; Swift ACLs are read/write/ACL granularities per account/container.
• •Azure recommends Entra over keys; Swift s3api translates S3 auth to Swift accounts.

• •Authoring format differs: ARM templates are JSON documents for Azure Resource Manager deployments, whereas Quake AI offers Heat (legacy, HOT/YAML format) and recommends OpenTofu (HCL) for new infrastructure automation.
• •Deployment target/scope differs: ARM templates can deploy at multiple scopes (resource group, subscription, management group, tenant) via Azure Resource Manager's management layer, while Heat orchestrates within a single OpenStack project/tenant. OpenTofu can target multiple projects via provider configuration.
• •Change-preview behavior differs: ARM supports a built-in “what-if” style preview of changes via Resource Manager deployments, while OpenTofu provides `tofu plan` for change previews. Heat relies on stack update events (legacy workflow).
• •Resource coverage lifecycle differs: ARM templates support Azure resource types exposed by Azure resource providers; OpenTofu covers OpenStack resource types via the OpenStack provider, and Heat (legacy) supports a narrower set via built-in resource plugins.

• •Resource Groups store metadata in a specific region and support resources from multiple regions; OpenStack lacks formal grouping beyond projects, resources directly scoped to projects.
• •Built-in features like ARM locks (Read-only/Delete), integrated tags for cost allocation, and deployment history views; OpenStack uses project quotas and locks via extensions, no native group-level deployments.
• •Lifecycle management: Easy group delete/update via ARM templates; OpenStack deletes resources individually or via OpenTofu destroy/Heat stacks scoped to projects.
• •Portal views aggregate metrics/deployments across group; OpenStack Horizon shows per-project.

• •Azure supports automated tiering (hot/cool/cold/archive) and expiration rules based on age, access time; Quake AI Swift S3 API lacks native lifecycle management per official OpenStack docs and no Quake AI-specific extension found.
• •Azure policies apply account-wide or filtered by prefix/tags; Swift requires external cron/object-expirer daemon for deletes, no built-in tiering.
• •Azure charges for tiering API calls; Swift has no equivalent billing as feature missing.

• •Both support versioning via S3 API in Quake AI and Blob REST API in Azure, but Azure automatic on write/delete for supported accounts; Swift native uses container headers (X-Versions-Location) requiring archive container, two modes differing on DELETE behavior.
• •Azure versions immutable, one current version; Swift POST metadata doesn't version, DELETE promotes or moves to history based on mode.
• •Azure integrates with soft delete/lifecycle; Swift S3 emulation may differ in delete markers/version listing behaviors from pure S3.

• •Azure cloning via 'az disk create --source' from disk ID or snapshot, supports cross-subscription/region with grants; Cinder uses 'cinder create --source-volid' or from snapshot, backend-local unless multi-backend.
• •No direct thin-clone in Azure (full copy via snapshot); Cinder supports thin cloning depending on backend (e.g., Ceph clone).
• •Azure copy requires same region for direct source ID use, cross-region via snapshot export/import; Cinder cloning typically same backend.

• •Azure's organization model is a four-level hierarchy: Tenant (Entra ID) → Management Groups → Subscriptions → Resource Groups. OpenStack uses a two-level model: Domain → Project. Quake AI exposes Projects within an Organization.
• •Azure Management Groups support up to 10,000 groups with 6 levels of depth; policy and RBAC assigned at a management group cascade to all child subscriptions. OpenStack has no equivalent cascading policy inheritance between projects.
• •Azure subscriptions are both billing containers and resource containers; each has its own cost center and invoice. OpenStack projects are resource containers only; billing is aggregated at the account level.
• •Azure resources must be placed in both a Subscription and a Resource Group; no resource exists outside a Resource Group. OpenStack resources belong to a project with no resource group concept.

• •Proprietary Microsoft identity platform with OAuth2/OIDC, MSAL libraries, Microsoft Graph API integration; OpenStack Keystone provides OpenStack-specific token auth with pluggable backends (LDAP/SQL).
• •Entra ID supports external identities (B2B/B2C), social logins (Google/Facebook); Keystone focuses on domain/project/role auth, federation via SAML/OIDC possible but secondary.
• •Integrated with Azure subscriptions (one tenant per sub); Keystone is deployment-wide, not subscription-scoped.
• •Advanced features like PIM, app provisioning; OpenStack roles are simpler, assigned per project.

• •Azure Blob Storage has no native S3-compatible endpoint; S3 compatibility requires third-party gateways (Flexify.IO, S3Proxy). Applications using AWS SDK pointing at Quake AI's S3 endpoint require zero code changes; migrating to Azure Blob requires SDK replacement (azure-storage-blob).
• •Azure Blob uses a different REST API with Azure-specific URL paths and x-ms-* headers; Quake AI's S3 endpoint uses standard AWS SigV4 authentication with EC2 credentials issued by Keystone.
• •Azure Blob's hierarchy is Storage Account → Container → Blob; Quake AI's Swift S3 layer maps S3 Buckets to Swift containers and Keys to objects, preserving the S3 mental model.
• •Azure auth uses Shared Access Signatures (SAS) or Azure AD RBAC; Quake AI's S3 endpoint uses AWS SigV4 with project-scoped access key/secret pairs (EC2 credentials in Keystone).

• •Managed subnet-level service w/ dynamic SNAT ports (no exhaustion), up to 16 static Public IPs ().
• •Highest precedence over LB/instance Public IP; zonal/zone-redundant SKUs; billed.
• •No router namespace; scales to 100Gbps; TCP/UDP only vs OpenStack L3 agent/OVN router SNAT.
• •Subnet attachment (one per subnet); overrides default Internet route.

No specific divergences documented yet.

• •NSGs can associate to both subnets and NICs with specific processing order (inbound: subnet then NIC; outbound: NIC then subnet) ().
• •Stateful with priority-based rules (100-4096); augmented rules allow multiple IPs/ports per rule (Resource Manager only).
• •Default rules allow VNet/LB/Internet out; service tags like VirtualNetwork.
• •No direct port-level only like OpenStack; subnet-level affects all instances.

• •Public IP is a dedicated ARM resource with SKUs (Basic/Standard); IPv4 billed, IPv6 free ().
• •Static/dynamic allocation (Standard static only); zone-redundant option (Standard v2).
• •Associated directly to NIC/LB/gateway vs via router DNAT in OpenStack.
• •Dynamic outbound uses ephemeral IPs even without assoc; no pool allocation like Neutron external nets.

• •Snapshots of managed disks (Microsoft.Compute/snapshots), billed on used size, separate from volumes unlike Cinder volume snapshots integration.
• •Supports incremental snapshots for efficiency, ZRS storage in zones.
• •API /providers/Microsoft.Compute/snapshots vs Nova/Cinder volume snapshot APIs.
• •Primarily for disks, not full instances; instance snapshots via images instead.

• •Managed as ARM resources (Microsoft.Compute/sshPublicKeys), reusable across VMs, vs OpenStack's keypairs injected only at boot.
• •API /providers/Microsoft.Compute/sshPublicKeys, supports ED25519/RSA, no private key storage.
• •Keys provided during VM create or via portal/CLI, not listed/injected separately post-boot like OpenStack.
• •No deletion/re-import of injected keys; new VM for changes.

• •Both SSE transparent; Azure SSE default with Microsoft-managed keys (256-bit AES), optional CMK in Key Vault/CPK/client-side; Swift encryption middleware (AES-256 CTR) derives keys from root secret, internal not API-exposed.
• •Azure scopes keys to account, container, or blob and integrates Key Vault. Swift can encrypt object data and metadata at the storage layer.
• •Azure client-side explicit in SDKs; Swift recommends client-side for full protection, server-side mitigates disk theft.

• •Uses azurerm_virtual_machine/azurerm_linux_virtual_machine; OpenStack uses openstack_compute_instance_v2.
• •AzureRM provider requires subscription_id, tenant_id, client_id, client_secret; OpenStack uses auth_url and application credentials.

• •Uses Azure Resource Manager (ARM) REST API at /providers/Microsoft.Compute/virtualMachines instead of OpenStack Nova API at /v2.1/servers.
• •Tightly integrated with Azure services like Azure Active Directory for authentication, unlike OpenStack's Keystone.
• •VM creation requires specifying size from predefined series with hardware-specific features (e.g., AMD/Intel/ARM), not custom flavor configs.
• •Billed per second with complex pricing tiers based on series/reservation options, vs OpenStack's typically hourly or usage-based.

• •Azure VNets are strictly regional Layer 3 overlays scoped to one subscription with no L2 VLAN support ().
• •VNets and subnets creation free, but subnets min /29 with Azure reserving 5 IPs per subnet ().
• •Managed via ARM REST APIs/PowerShell/CLI vs Neutron REST API.
• •Isolated per subscription; peering for cross-VNet connectivity vs OpenStack project networks connected via routers.

No specific divergences documented yet.

• •Azure subnets are child resources of a Virtual Network defined as /providers/Microsoft.Network/virtualNetworks/{vnet}/subnets/{subnet}; Neutron subnets are top-level resources with their own UUIDs associated to a network via network_id.
• •Azure subnets support service endpoints (for Azure Storage, SQL) and delegations (reserving a subnet for specific Azure services) with no Neutron equivalent.
• •Azure subnet CIDR cannot overlap with other subnets in the same VNet or peered VNets and is immutable after creation; Neutron supports updating allocation pools but not the CIDR block post-creation.
• •Network Security Groups (NSGs) attach at the Azure subnet level (and optionally at NIC level); Neutron security groups attach to ports/interfaces, not to subnets.

• •Predefined hardware-optimized series (e.g., D-family general purpose) with complex naming (e.g., Standard_D4as_v5), not user-defined vCPU/RAM like OpenStack flavors.
• •Sizes listed via API /providers/Microsoft.Compute/locations/{location}/vmSizes, region-specific availability.
• •Includes accelerator features (GPU, FPGA) baked into sizes, unavailable in basic OpenStack flavors without extensions.
• •Cannot create custom sizes; selection from catalog, limiting flexibility vs OpenStack flavor creation.

• •Azure Managed Disks are fully managed with automatic redundancy (3 replicas, 99.999% SLA); Cinder durability depends on backend.
• •Predefined disk types (Ultra Disk, Premium SSD v2, Premium SSD, Standard SSD, Standard HDD) with fixed performance tiers; Cinder uses volume types with configurable QoS.
• •Disks billed on provisioned size regardless of use; Cinder billing typically on provisioned size too but varies by provider.

• •Azure cloning via 'az disk create --source' from disk ID or snapshot, supports cross-subscription/region with grants; Cinder uses 'cinder create --source-volid' or from snapshot, backend-local unless multi-backend.
• •No direct thin-clone in Azure (full copy via snapshot); Cinder supports thin cloning depending on backend (e.g., Ceph clone).
• •Azure copy requires same region for direct source ID use, cross-region via snapshot export/import; Cinder cloning typically same backend.

• •Azure automatically provisions and manages the control plane at no additional cost (Free tier) or fixed fee (Standard tier with SLA), offloading health monitoring and upgrades; on Quake AI you provision a cluster through Magnum (openstack coe cluster create) or self-managed Kubernetes on Nova instances (OpenTofu plus kubeadm, k3s, or RKE2), and you operate the cluster after creation.
• •No OpenStack integration; uses Azure Resource Manager for cluster lifecycle.
• •Pre-configured with Azure-specific defaults and add-ons like application routing.
• •Managed via Azure Virtual Machine Scale Sets (VMSS) with auto-scaling and upgrades; Quake AI uses Nova instances provisioned via OpenTofu with user-managed scaling and upgrades.

• •Azure CNI or kubenet, integrates Azure Load Balancer/Application Gateway; Quake AI Kubernetes clusters use Neutron private networks and routers with CNI plugins (Flannel, Calico, Cilium).
• •Bring-your-own CNI supported; Quake AI tenant-isolated Neutron.
• •Azure-specific: Application routing add-on (nginx), no native Neutron.

• •Uses fault/update domains (max 3/20) for HA, fixed at creation, vs flexible OpenStack server group policies (affinity/anti-affinity).
• •ARM resource (Microsoft.Compute/availabilitySets), VMs assigned at create, no dynamic move.
• •No extra cost, but requires 2+ VMs for SLA; prefers zones/scale sets.
• •Lower latency between VMs in set vs zones, hardware-specific isolation.

• •Consumption-based metered billing via Microsoft Commerce pipeline with rated usage, monthly invoices, discounts/reservations; OpenStack has no built-in billing, relies on add-ons like CloudKitty for rating/chargeback.
• •Scopes include subscriptions/RGs for cost analysis, anomaly detection, budgets; OpenStack usage collected via Ceilometer, rated externally.
• •Enterprise Agreements/MCA with complex scopes (billing profiles); OpenStack operator-defined.
• •Cost Management + Billing portal for payments/invoices; OpenStack requires custom integration.

• •Azure requires choosing between generalized (sysprep'd, removes machine identity, destroys the source VM's bootability) and specialized (exact clone, source VM survives). OpenStack Nova createImage is always non-destructive — the server continues running and the image captures the current disk state.
• •Capturing a generalized Azure image requires running waagent -deprovision inside the VM, then deallocating and marking as generalized (az vm generalize) before capture — a multi-step destructive process. OpenStack createImage (POST /v2.1/servers/{id}/action {"createImage": {...}}) requires no VM shutdown.
• •Azure stores instance images in Azure Compute Gallery with versioning and multi-region replication support. Glance stores images with no built-in versioning (images are replaced or new images created).
• •Azure ARM API for capture: POST /providers/Microsoft.Compute/virtualMachines/{vm}/capture (legacy) or via Compute Gallery image versions. Nova API: POST /v2.1/servers/{id}/action.

• •Organized in galleries with image definitions and versioned images (Microsoft.Compute/galleries/images/versions), more structured than flat Glance images.
• •Supports global replication to regions with replicas (up to 100), ZRS storage, unlike OpenStack's store-only model.
• •Sharing via RBAC, community galleries, or direct share; requires gallery setup vs simple OpenStack image sharing.
• •New features like Trusted Launch only in Gallery, legacy managed images deprecated.

• •Pure L4 (TCP/UDP) pass-through; no L7 features (use App Gateway) ().
• •SKUs: Standard w/ zones/HA, health probes, outbound SNAT rules; Basic free but retiring 2025.
• •Azure provides a regional managed service integrated with VNets. Quake AI workloads use a self-managed reverse proxy or Kubernetes LoadBalancer Service.
• •API via ARM; frontend configs w/ multiple IPs/ports.

• •Azure Managed Disks are fully managed with automatic redundancy (3 replicas, 99.999% SLA); Cinder durability depends on backend.
• •Predefined disk types (Ultra Disk, Premium SSD v2, Premium SSD, Standard SSD, Standard HDD) with fixed performance tiers; Cinder uses volume types with configurable QoS.
• •Disks billed on provisioned size regardless of use; Cinder billing typically on provisioned size too but varies by provider.

• •Azure bills Linux VMs per second; pricing is not included in the VM size API and requires the Azure Retail Prices API (GET https://prices.azure.com/api/retail/prices) or the Pricing Calculator.
• •Azure Hybrid Benefit allows using on-premises Windows Server and SQL Server licenses to reduce Azure VM costs; no equivalent in OpenStack.
• •Azure pricing includes Basic, Standard, and Premium tiers for many services (load balancers, public IPs) with different SLAs per tier. Quake AI uses a flat pricing model without service tiers.
• •Azure reserved instances (1-year or 3-year commitments) offer up to 72% discount vs. on-demand. Quake AI does not currently offer reserved capacity pricing.

• •Azure uses RBAC/ABAC with Entra ID (AAD), SAS, shared keys; Quake AI/OpenStack Swift S3 uses Keystone/S3 token auth mapped to Swift ACLs, bucket policies via s3api middleware.
• •Azure granular roles/conditions at account/container/blob; Swift ACLs are read/write/ACL granularities per account/container.
• •Azure recommends Entra over keys; Swift s3api translates S3 auth to Swift accounts.

• •Authoring format differs: ARM templates are JSON documents for Azure Resource Manager deployments, whereas Quake AI offers Heat (legacy, HOT/YAML format) and recommends OpenTofu (HCL) for new infrastructure automation.
• •Deployment target/scope differs: ARM templates can deploy at multiple scopes (resource group, subscription, management group, tenant) via Azure Resource Manager's management layer, while Heat orchestrates within a single OpenStack project/tenant. OpenTofu can target multiple projects via provider configuration.
• •Change-preview behavior differs: ARM supports a built-in “what-if” style preview of changes via Resource Manager deployments, while OpenTofu provides `tofu plan` for change previews. Heat relies on stack update events (legacy workflow).
• •Resource coverage lifecycle differs: ARM templates support Azure resource types exposed by Azure resource providers; OpenTofu covers OpenStack resource types via the OpenStack provider, and Heat (legacy) supports a narrower set via built-in resource plugins.

• •Resource Groups store metadata in a specific region and support resources from multiple regions; OpenStack lacks formal grouping beyond projects, resources directly scoped to projects.
• •Built-in features like ARM locks (Read-only/Delete), integrated tags for cost allocation, and deployment history views; OpenStack uses project quotas and locks via extensions, no native group-level deployments.
• •Lifecycle management: Easy group delete/update via ARM templates; OpenStack deletes resources individually or via OpenTofu destroy/Heat stacks scoped to projects.
• •Portal views aggregate metrics/deployments across group; OpenStack Horizon shows per-project.

• •Azure supports automated tiering (hot/cool/cold/archive) and expiration rules based on age, access time; Quake AI Swift S3 API lacks native lifecycle management per official OpenStack docs and no Quake AI-specific extension found.
• •Azure policies apply account-wide or filtered by prefix/tags; Swift requires external cron/object-expirer daemon for deletes, no built-in tiering.
• •Azure charges for tiering API calls; Swift has no equivalent billing as feature missing.

• •Both support versioning via S3 API in Quake AI and Blob REST API in Azure, but Azure automatic on write/delete for supported accounts; Swift native uses container headers (X-Versions-Location) requiring archive container, two modes differing on DELETE behavior.
• •Azure versions immutable, one current version; Swift POST metadata doesn't version, DELETE promotes or moves to history based on mode.
• •Azure integrates with soft delete/lifecycle; Swift S3 emulation may differ in delete markers/version listing behaviors from pure S3.

• •Azure cloning via 'az disk create --source' from disk ID or snapshot, supports cross-subscription/region with grants; Cinder uses 'cinder create --source-volid' or from snapshot, backend-local unless multi-backend.
• •No direct thin-clone in Azure (full copy via snapshot); Cinder supports thin cloning depending on backend (e.g., Ceph clone).
• •Azure copy requires same region for direct source ID use, cross-region via snapshot export/import; Cinder cloning typically same backend.

• •Azure's organization model is a four-level hierarchy: Tenant (Entra ID) → Management Groups → Subscriptions → Resource Groups. OpenStack uses a two-level model: Domain → Project. Quake AI exposes Projects within an Organization.
• •Azure Management Groups support up to 10,000 groups with 6 levels of depth; policy and RBAC assigned at a management group cascade to all child subscriptions. OpenStack has no equivalent cascading policy inheritance between projects.
• •Azure subscriptions are both billing containers and resource containers; each has its own cost center and invoice. OpenStack projects are resource containers only; billing is aggregated at the account level.
• •Azure resources must be placed in both a Subscription and a Resource Group; no resource exists outside a Resource Group. OpenStack resources belong to a project with no resource group concept.

• •Proprietary Microsoft identity platform with OAuth2/OIDC, MSAL libraries, Microsoft Graph API integration; OpenStack Keystone provides OpenStack-specific token auth with pluggable backends (LDAP/SQL).
• •Entra ID supports external identities (B2B/B2C), social logins (Google/Facebook); Keystone focuses on domain/project/role auth, federation via SAML/OIDC possible but secondary.
• •Integrated with Azure subscriptions (one tenant per sub); Keystone is deployment-wide, not subscription-scoped.
• •Advanced features like PIM, app provisioning; OpenStack roles are simpler, assigned per project.

• •Azure Blob Storage has no native S3-compatible endpoint; S3 compatibility requires third-party gateways (Flexify.IO, S3Proxy). Applications using AWS SDK pointing at Quake AI's S3 endpoint require zero code changes; migrating to Azure Blob requires SDK replacement (azure-storage-blob).
• •Azure Blob uses a different REST API with Azure-specific URL paths and x-ms-* headers; Quake AI's S3 endpoint uses standard AWS SigV4 authentication with EC2 credentials issued by Keystone.
• •Azure Blob's hierarchy is Storage Account → Container → Blob; Quake AI's Swift S3 layer maps S3 Buckets to Swift containers and Keys to objects, preserving the S3 mental model.
• •Azure auth uses Shared Access Signatures (SAS) or Azure AD RBAC; Quake AI's S3 endpoint uses AWS SigV4 with project-scoped access key/secret pairs (EC2 credentials in Keystone).

• •Managed subnet-level service w/ dynamic SNAT ports (no exhaustion), up to 16 static Public IPs ().
• •Highest precedence over LB/instance Public IP; zonal/zone-redundant SKUs; billed.
• •No router namespace; scales to 100Gbps; TCP/UDP only vs OpenStack L3 agent/OVN router SNAT.
• •Subnet attachment (one per subnet); overrides default Internet route.

No specific divergences documented yet.

• •NSGs can associate to both subnets and NICs with specific processing order (inbound: subnet then NIC; outbound: NIC then subnet) ().
• •Stateful with priority-based rules (100-4096); augmented rules allow multiple IPs/ports per rule (Resource Manager only).
• •Default rules allow VNet/LB/Internet out; service tags like VirtualNetwork.
• •No direct port-level only like OpenStack; subnet-level affects all instances.

• •Public IP is a dedicated ARM resource with SKUs (Basic/Standard); IPv4 billed, IPv6 free ().
• •Static/dynamic allocation (Standard static only); zone-redundant option (Standard v2).
• •Associated directly to NIC/LB/gateway vs via router DNAT in OpenStack.
• •Dynamic outbound uses ephemeral IPs even without assoc; no pool allocation like Neutron external nets.

• •Snapshots of managed disks (Microsoft.Compute/snapshots), billed on used size, separate from volumes unlike Cinder volume snapshots integration.
• •Supports incremental snapshots for efficiency, ZRS storage in zones.
• •API /providers/Microsoft.Compute/snapshots vs Nova/Cinder volume snapshot APIs.
• •Primarily for disks, not full instances; instance snapshots via images instead.

• •Managed as ARM resources (Microsoft.Compute/sshPublicKeys), reusable across VMs, vs OpenStack's keypairs injected only at boot.
• •API /providers/Microsoft.Compute/sshPublicKeys, supports ED25519/RSA, no private key storage.
• •Keys provided during VM create or via portal/CLI, not listed/injected separately post-boot like OpenStack.
• •No deletion/re-import of injected keys; new VM for changes.

• •Both SSE transparent; Azure SSE default with Microsoft-managed keys (256-bit AES), optional CMK in Key Vault/CPK/client-side; Swift encryption middleware (AES-256 CTR) derives keys from root secret, internal not API-exposed.
• •Azure scopes keys to account, container, or blob and integrates Key Vault. Swift can encrypt object data and metadata at the storage layer.
• •Azure client-side explicit in SDKs; Swift recommends client-side for full protection, server-side mitigates disk theft.

• •Uses azurerm_virtual_machine/azurerm_linux_virtual_machine; OpenStack uses openstack_compute_instance_v2.
• •AzureRM provider requires subscription_id, tenant_id, client_id, client_secret; OpenStack uses auth_url and application credentials.

• •Uses Azure Resource Manager (ARM) REST API at /providers/Microsoft.Compute/virtualMachines instead of OpenStack Nova API at /v2.1/servers.
• •Tightly integrated with Azure services like Azure Active Directory for authentication, unlike OpenStack's Keystone.
• •VM creation requires specifying size from predefined series with hardware-specific features (e.g., AMD/Intel/ARM), not custom flavor configs.
• •Billed per second with complex pricing tiers based on series/reservation options, vs OpenStack's typically hourly or usage-based.

• •Azure VNets are strictly regional Layer 3 overlays scoped to one subscription with no L2 VLAN support ().
• •VNets and subnets creation free, but subnets min /29 with Azure reserving 5 IPs per subnet ().
• •Managed via ARM REST APIs/PowerShell/CLI vs Neutron REST API.
• •Isolated per subscription; peering for cross-VNet connectivity vs OpenStack project networks connected via routers.

No specific divergences documented yet.

• •Azure subnets are child resources of a Virtual Network defined as /providers/Microsoft.Network/virtualNetworks/{vnet}/subnets/{subnet}; Neutron subnets are top-level resources with their own UUIDs associated to a network via network_id.
• •Azure subnets support service endpoints (for Azure Storage, SQL) and delegations (reserving a subnet for specific Azure services) with no Neutron equivalent.
• •Azure subnet CIDR cannot overlap with other subnets in the same VNet or peered VNets and is immutable after creation; Neutron supports updating allocation pools but not the CIDR block post-creation.
• •Network Security Groups (NSGs) attach at the Azure subnet level (and optionally at NIC level); Neutron security groups attach to ports/interfaces, not to subnets.

• •Predefined hardware-optimized series (e.g., D-family general purpose) with complex naming (e.g., Standard_D4as_v5), not user-defined vCPU/RAM like OpenStack flavors.
• •Sizes listed via API /providers/Microsoft.Compute/locations/{location}/vmSizes, region-specific availability.
• •Includes accelerator features (GPU, FPGA) baked into sizes, unavailable in basic OpenStack flavors without extensions.
• •Cannot create custom sizes; selection from catalog, limiting flexibility vs OpenStack flavor creation.

• •Authoring format differs: ARM templates are JSON documents for Azure Resource Manager deployments, whereas Quake AI offers Heat (legacy, HOT/YAML format) and recommends OpenTofu (HCL) for new infrastructure automation.
• •Deployment target/scope differs: ARM templates can deploy at multiple scopes (resource group, subscription, management group, tenant) via Azure Resource Manager's management layer, while Heat orchestrates within a single OpenStack project/tenant. OpenTofu can target multiple projects via provider configuration.
• •Change-preview behavior differs: ARM supports a built-in “what-if” style preview of changes via Resource Manager deployments, while OpenTofu provides `tofu plan` for change previews. Heat relies on stack update events (legacy workflow).
• •Resource coverage lifecycle differs: ARM templates support Azure resource types exposed by Azure resource providers; OpenTofu covers OpenStack resource types via the OpenStack provider, and Heat (legacy) supports a narrower set via built-in resource plugins.

• •Uses azurerm_virtual_machine/azurerm_linux_virtual_machine; OpenStack uses openstack_compute_instance_v2.
• •AzureRM provider requires subscription_id, tenant_id, client_id, client_secret; OpenStack uses auth_url and application credentials.

• •Resource Groups store metadata in a specific region and support resources from multiple regions; OpenStack lacks formal grouping beyond projects, resources directly scoped to projects.
• •Built-in features like ARM locks (Read-only/Delete), integrated tags for cost allocation, and deployment history views; OpenStack uses project quotas and locks via extensions, no native group-level deployments.
• •Lifecycle management: Easy group delete/update via ARM templates; OpenStack deletes resources individually or via OpenTofu destroy/Heat stacks scoped to projects.
• •Portal views aggregate metrics/deployments across group; OpenStack Horizon shows per-project.

• •Azure's organization model is a four-level hierarchy: Tenant (Entra ID) → Management Groups → Subscriptions → Resource Groups. OpenStack uses a two-level model: Domain → Project. Quake AI exposes Projects within an Organization.
• •Azure Management Groups support up to 10,000 groups with 6 levels of depth; policy and RBAC assigned at a management group cascade to all child subscriptions. OpenStack has no equivalent cascading policy inheritance between projects.
• •Azure subscriptions are both billing containers and resource containers; each has its own cost center and invoice. OpenStack projects are resource containers only; billing is aggregated at the account level.
• •Azure resources must be placed in both a Subscription and a Resource Group; no resource exists outside a Resource Group. OpenStack resources belong to a project with no resource group concept.

• •Proprietary Microsoft identity platform with OAuth2/OIDC, MSAL libraries, Microsoft Graph API integration; OpenStack Keystone provides OpenStack-specific token auth with pluggable backends (LDAP/SQL).
• •Entra ID supports external identities (B2B/B2C), social logins (Google/Facebook); Keystone focuses on domain/project/role auth, federation via SAML/OIDC possible but secondary.
• •Integrated with Azure subscriptions (one tenant per sub); Keystone is deployment-wide, not subscription-scoped.
• •Advanced features like PIM, app provisioning; OpenStack roles are simpler, assigned per project.

• •Consumption-based metered billing via Microsoft Commerce pipeline with rated usage, monthly invoices, discounts/reservations; OpenStack has no built-in billing, relies on add-ons like CloudKitty for rating/chargeback.
• •Scopes include subscriptions/RGs for cost analysis, anomaly detection, budgets; OpenStack usage collected via Ceilometer, rated externally.
• •Enterprise Agreements/MCA with complex scopes (billing profiles); OpenStack operator-defined.
• •Cost Management + Billing portal for payments/invoices; OpenStack requires custom integration.

• •Azure bills Linux VMs per second; pricing is not included in the VM size API and requires the Azure Retail Prices API (GET https://prices.azure.com/api/retail/prices) or the Pricing Calculator.
• •Azure Hybrid Benefit allows using on-premises Windows Server and SQL Server licenses to reduce Azure VM costs; no equivalent in OpenStack.
• •Azure pricing includes Basic, Standard, and Premium tiers for many services (load balancers, public IPs) with different SLAs per tier. Quake AI uses a flat pricing model without service tiers.
• •Azure reserved instances (1-year or 3-year commitments) offer up to 72% discount vs. on-demand. Quake AI does not currently offer reserved capacity pricing.

• •Resource Groups store metadata in a specific region and support resources from multiple regions; OpenStack lacks formal grouping beyond projects, resources directly scoped to projects.
• •Built-in features like ARM locks (Read-only/Delete), integrated tags for cost allocation, and deployment history views; OpenStack uses project quotas and locks via extensions, no native group-level deployments.
• •Lifecycle management: Easy group delete/update via ARM templates; OpenStack deletes resources individually or via OpenTofu destroy/Heat stacks scoped to projects.
• •Portal views aggregate metrics/deployments across group; OpenStack Horizon shows per-project.