# Migrate from GCP VPC to Quake AI

Source: https://docs.quake.ai/docs/network/migration/migrate-from-gcp-vpc
Markdown: https://docs.quake.ai/docs/network/migration/migrate-from-gcp-vpc.md

---

# 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](/resources/migration/openstack)) 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

<MigrationTable provider="gcp" service="network" />


## Prerequisites

- A Quake AI account with [application credentials](/docs/tools/generate-app-credentials)
- The [OpenStack CLI](/docs/tools/install-openstack-client) 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.

<Figure caption="GCP global VPC with regional subnets and priority firewall rules maps to per-region Neutron networks with allow-only security groups and floating IPs">

```d2
direction: down

gcp: GCP Global VPC {
  region_a: Region A {
    subnet_a: Subnet
  }
  region_b: Region B {
    subnet_b: Subnet
  }
  cloud_nat: Cloud NAT
  fw: Firewall Rules (priority-ordered)
  static_ip: Static External IP
  cloud_nat -> region_a
  cloud_nat -> region_b
  static_ip -> region_a
  fw -> region_a: priority-ordered
}

neutron: Quake AI (per-region) {
  region_a: Region A {
    network_a: Network
    router_a: Router (SNAT)
    sg_a: Security Group
    fip_a: Floating IP
    network_a -> router_a
    sg_a -> network_a: allow-only
    fip_a -> network_a
  }
  region_b: Region B {
    network_b: Network
    router_b: Router (SNAT)
    sg_b: Security Group
    fip_b: Floating IP
    network_b -> router_b
    sg_b -> network_b: allow-only
    fip_b -> network_b
  }
}

gcp -> neutron: maps to (one VPC becomes N independent regions)
```

</Figure>

| GCP concept | Neutron equivalent | Notes |
|---|---|---|
| VPC (global) | Network (regional) | GCP VPC spans all regions; Neutron networks are per-region |
| Regional Subnet | Subnet | Direct match; Neutron subnets are inherently regional |
| Cloud Router | **No equivalent** | BGP dynamic routing for HA VPN and Cloud Interconnect, and the control plane for Cloud NAT. On Quake AI, the Neutron router provides SNAT directly. |
| VPN Gateway | Software VPN on instance | No managed VPN; implement WireGuard or OpenVPN |
| External static IP | Floating IP | Regional, reservable, re-assignable |
| Firewall Rules (allow) | Security Group rules | Target tags become security group references |
| Firewall Rules (deny) | **No equivalent** | Neutron SGs are allow-only; see translation below |
| Hierarchical Firewall Policies | **No equivalent** | No policy hierarchy; all rules are flat per SG |
| Network tags | Security Group assignment | Tags target firewall rules; SGs assign to ports |
| Service Account network tags | **No equivalent** | Must use SG IDs as proxy |
| Cloud NAT | Router (SNAT) | Router SNAT is the equivalent; no separate object |
| Shared VPC | **No equivalent** | Cross-project network sharing. In GCP Shared VPC, a host project owns the network and service projects attach workloads. On Quake AI, each project (tenant) has its own isolated network. Map each GCP service project to a separate Quake AI project with its own network stack, and use a VPN overlay or public endpoints for cross-project communication. |
| VPC Network Peering | **No equivalent** | No network peering on Quake AI |

### Set up the Neutron equivalent

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

```bash
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
```



GCP cross-region VM communication within a single VPC works transparently. On Quake AI, each region is a separate deployment. Cross-region communication must be redesigned: use public-facing endpoints between regions or a VPN overlay (WireGuard on a dedicated instance in each region).



## 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.

| Dimension | GCP Firewall Rules | Neutron Security Groups |
|---|---|---|
| Rule model | Allow and deny | Allow-only |
| Evaluation | Priority-ordered (0 = highest) | All rules additive |
| Default inbound | Deny-all (custom VPC; the GCP default VPC includes default-allow-internal and other permissive rules to audit before migration) | Deny-all |
| Default outbound | Allow-all (implied) | Allow-all |
| Applied to | VMs via network tags or service account | Ports via security group assignment |
| Scope | VPC-level (all matching VMs) | Per-port |
| Hierarchical | Yes (Org/Folder/VPC policies) | No hierarchy |
| Source types | CIDR, tags, service accounts | CIDR, Security Group ID |

### 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:**

```text
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:**

```bash
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.

| GCP source | Quake AI migration pattern |
|---|---|
| Global External HTTP(S) Load Balancer | External CDN or DNS traffic manager in front of a Quake AI origin |
| Regional External HTTP(S) Load Balancer | HAProxy, Nginx, Caddy, Traefik, or Envoy on a Compute instance |
| External Network Load Balancer | HAProxy or Nginx stream proxy |
| Cloud Armor | External CDN/WAF |
| URL maps | Host and path routing in the reverse proxy |

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

| GCP External Static IP | Neutron Floating IP |
|---|---|
| Regional or global scope | Regional only |
| Reservable by name, attachable to VM/LB | Allocatable from pool, attachable to port |
| Global IPs used for global LBs (anycast) | No global anycast available |
| Premium vs Standard network tier | Single tier on Quake AI. GCP Premium routes over Google's backbone and Standard routes over the internet; both assign regional IPs to VMs. |
| IPv6 supported | IPv6 not documented on Quake AI |
| Charged when unattached on GCP | Included in Quake AI pricing |

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



GCP global external IPs enable anycast routing, where users are served from the nearest Google PoP. For global performance, place a CDN or traffic manager in front of the Quake AI origin.



## 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.



GCP-specific DNS features with no standard equivalent: private zones (internal VPC DNS resolution), DNS peering (cross-VPC DNS), and Cloud DNS routing policies (geolocation, latency, weighted). Replace private zones with a local DNS resolver. Replace routing policies with external traffic managers (Cloudflare Load Balancing, NS1 Pulsar).



## 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

| Topic | Detail |
|---|---|
| Global VPC re-architecture | GCP workloads in multiple regions under one VPC have internal routing without configuration. On Quake AI, each region is a separate deployment. Cross-region communication must be redesigned. |
| Egress pricing | GCP bills egress per-GiB with rates that vary by source-destination pair, often higher for cross-continental routes. Quake AI's bandwidth-inclusive model is a major cost reduction for egress-heavy workloads. See [GCP network pricing](https://cloud.google.com/vpc/network-pricing). |
| Cloud Armor / DDoS | GCP Cloud Armor provides DDoS mitigation and WAF at the global load balancer. Place a CDN/WAF edge service in front of the Quake AI origin. |
| Shared VPC | GCP Shared VPC (XPN) shares a network across multiple projects. Each Quake AI project is isolated. Cross-project networking must be redesigned. |
| Firewall rule migration at scale | Large GCP deployments may have hundreds of firewall rules with complex tag targeting and hierarchical policies. Script the migration: enumerate effective rules per instance, group by access pattern, and generate Neutron SG definitions. |

## See also

- [Migrating from GCP to Quake AI](/resources/migration/from-gcp): full cross-service migration hub
- [Migrate from GCE to Quake AI Compute](/docs/compute/migration/migrate-from-gce): compute workload migration
- [Network migration guides](/docs/network/migration): all provider guides
- [Create a security group](/docs/network/how-to/create-security-group): Neutron security group setup