Migrate from Azure VNet to Quake AI

Azure's networking model introduces these constructs with no direct Neutron equivalent: the dual NSG layer (subnet-level and NIC-level), User Defined Routes for traffic inspection, Application Gateway WAF, and Azure-specific services (Service Endpoints, Private Link, Azure Firewall). The core migration shift: Azure's two independent security enforcement points (subnet NSG + NIC NSG) collapse into a single port-level security group on Quake AI's OpenStack Neutron. This simplification requires auditing effective rules at both Azure layers so you do not lose any during the merge.

Service mapping#

Prerequisites#

• A Quake AI account with application credentials
• The OpenStack CLI installed and configured
• An inventory of your Azure resources: VNets, subnets, NSGs (both subnet and NIC level), Public IPs, Load Balancers, Application Gateways, and Azure DNS zones
• Effective NSG rules per VM: run az network nic list-effective-nsg to audit what each VM actually sees
• An SSH key pair imported to Quake AI (openstack keypair create --public-key)

Topology mapping#

Azure's per-subnet NSGs, per-NIC NSGs, and UDR route tables compress into Neutron's simpler model: one network, one subnet, one router, and per-port security groups.

Set up the Neutron equivalent#

openstack network create my-network

openstack subnet create my-subnet \
  --network my-network \
  --subnet-range 10.0.0.0/24 \
  --gateway 10.0.0.1 \
  --dns-nameserver 8.8.8.8

openstack router create my-router
openstack router set my-router --external-gateway PublicStatic
openstack router add subnet my-router my-subnet

Security rule translation#

The critical difference: Azure allows NSGs at both subnet and NIC level. Traffic entering a VM passes through the subnet NSG first, then the NIC NSG. Both must allow the traffic. Neutron has one enforcement point: the port (equivalent to the NIC).

Merging dual NSG layers#

For each VM, audit the effective rules across both NSG layers:

1. Run az network nic list-effective-nsg --resource-group MY_RG --network-interface-name MY_NIC to see what rules actually apply.
2. Merge the subnet NSG and NIC NSG into a single set of Neutron security group rules.
3. Express the allow rules from both layers in one Neutron SG per VM role.

Translating Azure-specific constructs#

Service Tags (e.g., Internet, AzureLoadBalancer, VirtualNetwork, Storage): These expand to Azure-managed IP ranges with no Neutron equivalent. Use explicit CIDR ranges instead. Drop the AllowAzureLoadBalancerInBound default rule and add only the health-check sources required by your replacement proxy.

AllowVnetInBound default rule: Azure permits all traffic within the VNet by default at priority 65000. Neutron's default is deny-all inbound. Applications that relied on this permissive VNet default (without explicit NSG rules for internal traffic) will break until you add explicit allow rules for internal traffic patterns.

Deny rules: Same approach as GCP. Enumerate what the deny rules block. Ensure corresponding allow rules are absent in Neutron security groups.

3-tier app example#

Azure source:

• Web subnet NSG: Priority 100 allow inbound TCP 80, 443 from Internet; Priority 65000 AllowVnetInBound; Priority 65500 DenyAllInBound
• App subnet NSG: Priority 100 allow TCP 8080 from 10.0.1.0/24 (web subnet)
• DB subnet NSG: Priority 100 allow TCP 5432 from 10.0.2.0/24 (app subnet)

Neutron target (merged to single layer, upgraded to SG references):

openstack security group create sg-web
openstack security group rule create sg-web \
  --protocol tcp --dst-port 80 --remote-ip 0.0.0.0/0 --ingress
openstack security group rule create sg-web \
  --protocol tcp --dst-port 443 --remote-ip 0.0.0.0/0 --ingress

openstack security group create sg-app
openstack security group rule create sg-app \
  --protocol tcp --dst-port 8080 --remote-group sg-web --ingress

openstack security group create sg-db
openstack security group rule create sg-db \
  --protocol tcp --dst-port 5432 --remote-group sg-app --ingress

The subnet-level NSG layer is dropped entirely. The AllowVnetInBound default rule (which allows all VNet internal traffic) is replaced by explicit rules. This is a security improvement: Neutron's default deny is stricter than Azure's permissive VNet default.

Load balancer migration#

Replace Azure traffic services according to their scope:

Assign a floating IP to the proxy instance and keep application backends on a private network. Install TLS certificates on the proxy with Certbot, use Caddy's ACME support, or terminate public TLS at the external edge.

Floating IP setup#

openstack floating ip create PublicStatic
openstack server add floating ip MY_INSTANCE FLOATING_IP_ADDRESS

Azure Standard SKU Public IPs can be zone-redundant (replicated across AZs). Quake AI has no AZ concept; floating IPs are region-scoped.

DNS cutover#

Azure DNS must be replaced by an external provider. Quake AI has no managed DNS service.

1. Export zone: az network dns zone export -g RESOURCE_GROUP -n example.com -f zone.txt
2. Review private zones: Azure Private DNS Zones (VNet-internal name resolution) must be replicated with an internal DNS service. Options: dnsmasq, a custom resolver VM, or Neutron DHCP subnet DNS server configuration.
3. Lower TTLs: Modify all records to 300 seconds; wait for the current TTL to expire.
4. Import at new provider: Standard BIND zone file accepted by most providers.
5. Validate: dig @NEW_NAMESERVER example.com A
6. Update registrar NS records.
7. Monitor for 48 hours and restore TTLs after successful cutover.

Records to remap:

• Alias records pointing to Azure LB/App Gateway DNS names become CNAME or A records pointing to the reverse proxy floating IP or external edge hostname
• Azure Traffic Manager endpoints become external DNS load balancing records (Cloudflare, NS1 Pulsar)
• Azure Front Door CNAMEs become CDN provider CNAMEs

Validation checklist#

• Neutron network, subnet, and router are operational
• Security group rules capture the merged intent of both subnet-level and NIC-level NSGs
• Azure AllowVnetInBound equivalent rules are explicitly added for internal traffic
• Azure deny rules are handled by the absence of corresponding allow rules
• Azure Service Tag references are replaced by explicit CIDRs
• Floating IPs are associated with the correct instance ports
• Reverse proxy health checks pass for application backends
• WAF replacement is in place (CDN/WAF edge or reverse proxy) if Application Gateway WAF was used
• DNS records resolve to Quake AI floating IPs or external edge hostnames
• Applications respond correctly through the full network path

Provider-specific gotchas#

See also#

• Migrating from Azure to Quake AI: full cross-service migration hub
• Migrate from Azure VMs to Quake AI Compute: compute workload migration
• Network migration guides: all provider guides
• Create a security group: Neutron security group setup