Migrate from GCP VPC to Quake AI

GCP's global VPC model is architecturally unique among cloud providers and requires the most significant conceptual restructuring for migration. A single GCP VPC spans all regions within a project, with regional subnets, global firewall rules that support both allow and deny actions with priority ordering, and hierarchical firewall policies. On Quake AI, the Network service (OpenStack Neutron) is regional by design: each region gets its own network, subnet, and router. Firewall deny rules and policy hierarchies collapse into flat, allow-only security groups.

Service mapping#

Prerequisites#

• A Quake AI account with application credentials
• The OpenStack CLI installed and configured
• An inventory of your GCP resources: VPCs, subnets, firewall rules (including hierarchical policies), Cloud NAT, static external IPs, Cloud Load Balancers, and Cloud DNS zones
• An SSH key pair imported to Quake AI (openstack keypair create --public-key)

Topology mapping#

The key restructuring: GCP's single global VPC with regional subnets becomes per-region Neutron deployments. Applications that relied on cross-region VM communication within one GCP VPC require explicit connectivity setup on Quake AI.

Set up the Neutron equivalent#

For each GCP region your workloads occupy, create a separate Neutron network:

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#

GCP's firewall model is the most different from Neutron of the five providers: it supports both allow and deny rules with priority ordering, hierarchical policies (Org, Folder, VPC level), and targeting by network tags or service accounts.

Translating deny rules#

GCP commonly uses explicit deny rules to block specific traffic at a lower priority than allow rules. In Neutron, you cannot create deny rules. The migration approach:

1. For each deny rule, identify what traffic it blocks.
2. Verify that no allow rule exists in your Neutron security groups for that traffic. Neutron's implicit deny-all ingress handles the rest.
3. For deny rules that carve out exceptions from a broader allow rule (e.g., allow 0.0.0.0/0 except 10.0.0.0/8), split the allow rules into specific non-overlapping CIDRs that exclude the denied range.

Translating hierarchical policies#

GCP hierarchical firewall policies (Org, Folder, VPC) with goto_next delegation have no Neutron equivalent. Consolidate all policy layers into a flat set of security group rules:

1. Enumerate all effective rules per instance (accounting for priority at each policy level).
2. Group instances by access pattern.
3. Create one Neutron security group per access pattern.

3-tier app example#

GCP source:

Priority 100: Allow TCP 80,443 from 0.0.0.0/0 to tag web-tier
Priority 100: Allow TCP 8080 from tag web-tier to tag app-tier
Priority 100: Allow TCP 5432 from tag app-tier to tag db-tier
Priority 65534: Deny all ingress (implicit)
Priority 65535: Allow all egress (implied)

Neutron target:

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

Each GCP network tag maps to a Neutron security group. All deny rules are dropped because Neutron's implicit deny-all achieves the same result when the corresponding allow rules are absent. The hierarchical policy layer collapses into these three flat security groups.

Load balancer migration#

Replace GCP load balancing with a regional reverse proxy on Quake AI and an external edge where the source architecture uses global services.

Assign a floating IP to the proxy instance. 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

DNS cutover#

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

1. Export records: gcloud dns record-sets list --zone=ZONE_NAME --format=json
2. Lower TTLs: Use gcloud dns record-sets update to lower TTLs to 300 seconds; wait for current TTL propagation.
3. Import at new provider: Standard BIND zone file or Terraform.
4. Validate: dig @NEW_NAMESERVER example.com A
5. Update registrar NS records.
6. Monitor for 48 hours and restore TTLs after successful cutover.

Validation checklist#

• Per-region Neutron networks, subnets, and routers are operational
• Security group rules cover the intent of all GCP firewall allow rules
• GCP deny rules are handled by the absence of corresponding allow rules in Neutron
• Hierarchical policy intent is captured in flat security group rules
• Network tag-to-security-group mapping is documented and applied to ports
• Cross-region communication is functional (VPN overlay or public endpoints)
• Floating IPs are associated with the correct instance ports
• Reverse proxy health checks pass for application backends
• DNS records resolve to the proxy floating IP or external edge hostname
• Applications respond correctly through the full network path

Provider-specific gotchas#

See also#

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