Provisioning networking

ZopDay provisions the networking layer that everything else sits on. The defaults are production-shape: private subnets for workloads, public subnets only for ingress, NAT for egress, no IPv4 leakage. This page covers each piece, the defaults, and how to override.

What ZopDay can provision

VPC / VNet

The base network. Created with a CIDR you specify (default 10.0.0.0/16 if unspecified).

Flow logs go to object storage (not CloudWatch) by default. ZopNight’s compliance rules catch the inverse pattern on existing VPCs because CloudWatch flow logs are 10× more expensive.

Subnet layout

The standard layout for a production-shape VPC:

VPC (10.0.0.0/16)
├── Public subnets. 10.0.0.0/24, 10.0.1.0/24, 10.0.2.0/24   (one per AZ)
│   └── Hosts: Load balancers, NAT gateways, bastion (if any)
├── Private subnets. 10.0.16.0/20, 10.0.32.0/20, 10.0.48.0/20  (one per AZ)
│   └── Hosts: Worker nodes, datastores, internal services
└── (Optional) DB subnet group; uses the private subnets

For development VPCs, ZopDay uses smaller CIDRs to leave room for many dev VPCs:

VPC (10.0.0.0/24)
├── Public subnets.  10.0.0.0/26 (AZ a), 10.0.0.64/26 (AZ b)
└── Private subnets. 10.0.0.128/26 (AZ a), 10.0.0.192/26 (AZ b)

You can override the CIDR and per-subnet allocations in the wizard’s advanced view.

NAT

For worker nodes and other private-subnet hosts to reach external services (pulling images, talking to managed APIs, etc.), ZopDay provisions NAT egress.

NAT cost is non-trivial; on AWS, NAT Gateway data processing alone is often 10–20% of an account’s bill. ZopDay’s recommendation engine catches:

• Idle NAT Gateways (no traffic)
• High S3 / DynamoDB traffic through NAT instead of through a Gateway Endpoint

VPC peering

ZopDay can establish VPC peering on AWS and GCP. Azure VNet peering is on the roadmap.

The wizard asks for the peer VPC’s identity (VPC ID + region + owning account, plus the peer’s project for GCP), an optional DNS-resolution toggle, and which of ZopDay’s route tables should get a route to the peer CIDR added.

Peering creation is bilateral. ZopDay creates the request side; the peer’s owner must accept (the wizard’s review screen shows the explicit acceptance link for AWS / approval flow for GCP). While acceptance is outstanding, the connection sits in a pending state and no traffic flows across it; if the peer never accepts, the request eventually expires on the cloud side and the provisioning step is marked failed. Complete the acceptance on the peer account, then retry.

Peering connections are first-class edges on the architecture canvas in the UI; when a provisioning job lands a cluster or datastore in a peered VPC, the link is rendered automatically and click-throughs land on the discovered peering connection.

Private Service Connect (GCP only)

For cross-VPC connections to Cloud SQL where you don’t want full VPC peering, ZopDay provisions GCP Private Service Connect. The Cloud SQL instance is created with PSC enabled; a service attachment is provisioned in the producer VPC; consumers create endpoints in their own VPCs.

The wizard takes the consumer project IDs that should be allowed to connect, and ZopDay handles the rest of the PSC wiring at create time.

PSC scales better than peering for many-to-one topologies (many consumer projects → one shared Cloud SQL).

Transit Gateway (AWS)

For more than 2–3 VPCs that all need to communicate, peering becomes O(n²) and ZopDay recommends Transit Gateway instead.

ZopDay does not provision Transit Gateway today (on the roadmap, not yet available). For now, attach existing VPCs to your existing TGW via the AWS console; ZopDay’s architecture canvas will render the TGW connections automatically once it observes them.

DNS zones

ZopDay provisions DNS zones on demand:

DNS provisioning is decoupled from cluster provisioning; you can have one DNS zone shared across many clusters, or per-environment zones.

External-DNS (one of the default cluster Helm components) writes records to the zone from your Ingress resources automatically. So a new ingress on an EKS cluster ⇒ a DNS record in Route 53 ⇒ resolvable globally. No manual DNS edits required.

Networking-only provisioning jobs

You can run networking-only provisioning jobs (no cluster, no datastore); useful for establishing a foundation before any compute lands.

Provisioning → New provisioning job → Networking only. Provisions the VPC + subnets + NAT + IGW + (optional) DNS zone. When the job reaches completed the VPC is ready; subsequent jobs (cluster, datastore, VM) target it by selecting it in the “Existing VPC” mode.

If a networking step fails, the job is marked failed in the Provisioning Jobs view with the failing step and error. Common causes are quota limits (VPCs, NAT gateways, Elastic IPs), CIDR overlap with an existing network, or insufficient permissions. Fix the cause and retry; the job resumes from the last successful step.

What ZopDay does NOT provision

Tags

Every resource ZopDay provisions in the networking layer carries:

These tags drive ZopDay’s own resource discovery and the Smart Tag attribution path. Don’t manually edit these tags; they’re how ZopDay tracks its own creations.