Provisioning networking

ZopDay provisions the networking layer your clusters, VMs, and datastores run on, as part of the job that needs it. The defaults follow a production layout: private subnets for workloads, public subnets for ingress only, and NAT for egress. This page covers each piece, its defaults, and how to override them.

Before you start

• A cloud account connected with the provisioning permissions for networking (on AWS, the EC2 VPC, subnet, NAT, IGW, security group and route table actions; on GCP, roles/compute.admin). See Cloud permissions.
• A CIDR that doesn’t overlap an existing network, or the default 10.0.0.0/16.
• For GCP Shared VPC, roles/compute.networkUser on the host project. For Private Service Connect, roles/servicenetworking.networksAdmin on the consumer VPC’s project.

How it works

ZopDay provisions networking together with the resource that needs it, not as a separate job. Every cluster, VM, and datastore job in the Provision drawer has a Network choice: create a new VPC for the resource, or use one ZopDay can already see.

VPC / VNet defaults

The VPC (or VNet on Azure) is the base network. ZopDay creates it with the CIDR you specify, or 10.0.0.0/16 if you don’t specify one.

If you enable flow logs on AWS, send them to S3 rather than CloudWatch Logs. On existing VPCs, a ZopNight rightsizing rule flags flow logs sent to CloudWatch, because on AWS, delivery to CloudWatch Logs costs about twice the S3 delivery rate.

Subnet layout

This is the standard layout for a production 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 so that many dev VPCs fit in the address space:

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 under Advanced settings in the Provision drawer.

NAT

ZopDay provisions NAT egress so that worker nodes and other hosts in private subnets can reach external services, for example to pull images or call managed APIs.

NAT is a significant cost. On AWS, NAT Gateway data processing alone is often 10–20% of an account’s bill. ZopNight’s recommendation engine flags idle NAT Gateways (no traffic).

Choose the network for a job

1. Open the Provision drawer

   Go to Infrastructure → Provision and pick the cluster, VM, or datastore type.

2. Pick a Network option

   Create new VPC (recommended): ZopDay provisions the VPC, subnets, NAT, internet gateway, and security groups for this resource. Use existing VPC: pick a VPC ZopDay can already see on your cloud account.

3. Override the defaults if needed

   Open Advanced settings to change the CIDR and per-subnet allocations.

If a networking step fails, Activity → Provisioning Jobs marks the job as failed and shows the failing step and error. Fix the cause and retry; the job resumes from the last successful step.

Set up VPC peering

ZopDay can establish VPC peering on AWS and GCP. Azure VNet peering is on the roadmap. To set up peering, provide:

• The peer VPC’s identity: VPC ID, region, and owning account, plus the peer’s project on GCP
• Whether to enable DNS resolution (optional)
• Which of ZopDay’s route tables should get a route to the peer CIDR

Peering needs both sides. ZopDay creates the request, and the peer’s owner must accept it. ZopDay shows the acceptance link on AWS, or the approval flow on GCP. Until the peer accepts, the connection stays pending and no traffic flows across it.

The architecture canvas shows peering connections as first-class edges. When a provisioning job places a cluster or datastore in a peered VPC, the canvas draws the link automatically. Clicking it opens the discovered peering connection.

Private Service Connect (GCP only)

For cross-VPC connections to Cloud SQL without full VPC peering, ZopDay provisions GCP Private Service Connect (PSC). ZopDay creates the Cloud SQL instance with PSC enabled and provisions a service attachment in the producer VPC. Consumers then create endpoints in their own VPCs.

You supply the consumer project IDs that are allowed to connect. ZopDay handles the rest of the PSC wiring at create time. PSC scales better than peering for many-to-one topologies, where many consumer projects share one Cloud SQL instance.

Transit Gateway (AWS)

Once more than 2–3 VPCs all need to talk to each other, the number of peering connections grows as O(n²). At that point, ZopDay recommends Transit Gateway instead.

ZopDay does not provision Transit Gateway yet; it is on the roadmap. For now, attach existing VPCs to your existing TGW in the AWS console. ZopDay’s architecture canvas draws the TGW connections automatically once it observes them.

DNS zones

ZopDay provisions DNS zones on demand:

DNS provisioning is independent of cluster provisioning. You can share one DNS zone across many clusters, or use a zone per environment.

When you attach a domain to a space, ZopDay writes the matching records to the zone (Route 53, Cloud DNS, or Azure DNS) and records the verified status on the space. You don’t need to edit DNS by hand for attached domains.

Reference

What ZopDay does NOT provision

Tags

Every resource ZopDay provisions in the networking layer carries:

ZopDay uses these tags to recognise the resources it created. Don’t edit them by hand. They are separate from ZopNight Smart Tags, which are derived from resource fields, not from these tags.

Troubleshooting

Next steps