VPC & Project Bootstrap
What does zop.dev create for VPC & Project Bootstrap?
zop.dev bootstraps a GCP project in one step: VPC network, subnetwork, firewall, Cloud NAT router, and private services access for Cloud SQL and Memorystore peering, plus enablement of 11 APIs and 7 project IAM role grants. The vpc_config input is a map of private_subnets_cidr.
| Field | Value |
|---|---|
| Cloud | gcp |
On Google Cloud, a project needs its network, APIs, and IAM groundwork before anything else can run. zop.dev bootstraps all three in one step: the VPC, the service APIs your stack depends on, and the project-level roles.
Network, NAT, and private services access
VPC network, subnetwork, firewall, Cloud NAT router, and private services access (global address plus service networking connection) for Cloud SQL and Memorystore peering. Enables 11 APIs (cloudresourcemanager, compute, container, cloud_sql, secretmanager, redis, sqladmin, dns, servicenetworking, certificatemanager, serviceusage) and grants 7 project IAM roles.
vpc_config carries the private subnet CIDRs
vpc_config as a map of { private_subnets_cidr }.How Cloud SQL and Memorystore peer privately
Private services access is what lets Cloud SQL and Memorystore peer privately with the VPC.
Private services access is the subtle one
Most of the bootstrap list is legible at a glance: network, subnet, firewall, NAT. The item that repays attention is private services access: a reserved global address range plus a service networking connection, which is the plumbing that lets Cloud SQL and Memorystore attach to the VPC over private peering. Without it, managed databases face a choice between public IPs and connection proxies; with it, they get private addresses inside the VPC’s reach. Nearly every later “database is unreachable” mystery on GCP traces back to this peering, which is exactly why it is created here rather than left as an exercise.
The reserved range is hard to change later
That peering range is carved out of the address plan and effectively permanent. Resizing or
moving it after databases populate it is a disruptive, connection-breaking operation.
Together with private_subnets_cidr, this is the bootstrap’s one truly long-lived decision:
subnets can grow, firewall rules can churn, but the address plan set here is the one future
peerings and future databases must live inside. Allocate generously and from an
organization-wide scheme, for the same reason as every other network in this directory.
Overlap discovered later has no cheap fix.
What starts billing at creation
The bootstrap is almost free-standing: VPC, subnets, firewall rules, API enablement, and IAM grants all cost nothing to exist. The exception is the Cloud NAT router, which starts its hourly meter immediately and adds per-GB processing as private workloads generate egress. A bootstrapped-but-idle project therefore carries a small, steady NAT charge (the honest price of being ready), while the 11 enabled APIs and 7 project role grants set the capability and authority ceilings everything later operates under.