What's changed in multi-zone

This guide is for customers familiar with the original single-zone environment who are setting up new deployments in multi-zone. There is no migration path from single-zone to multi-zone—you must recreate your deployments from scratch.

Note: The documentation for the single-zone evroc cloud (Kubernetes API) is available at docs.legacy.evroc.com.

Terminology

Resource groups have been renamed to Projects. This change is unrelated to multi-zone and reflects a broader update to the evroc resource model.

Default resource naming

The naming convention for default resources has changed to reflect the regional and zonal structure.

VPC

Single-zoneMulti-zone
default-sto-1default-se-sto

Each project has one VPC. The new name includes the region prefix (se-sto for Stockholm).

Subnets

Single-zoneMulti-zone
default-sto-1 (10.0.0.0/24)default-se-sto-a (10.0.1.0/24)
default-se-sto-b (10.0.2.0/24)
default-se-sto-c (10.0.3.0/24)

Multi-zone provides one subnet per zone, each with its own CIDR range. All subnets are part of the same VPC.

Security groups

The default security group has been replaced with three groups with more descriptive names.

Single-zoneMulti-zonePurpose
default-sto-1default-allow-egressAllows outbound traffic to the internet
default-allow-web-protocolsAllows HTTP (port 80) and HTTPS (port 443) from any source
default-sto-1-sshdefault-allow-sshAllows SSH access (port 22) from any IP

Note: The single-zone default-sto-1 security group allowed inter-VM communication within the subnet. Multi-zone doesn't provide a default security group for this purpose—to allow VMs to communicate with each other, create a custom security group with appropriate rules.

Behavioural changes

Security group assignment

Single-zone: VMs without specified security groups were added to default-sto-1, which allowed both outbound internet access and inbound traffic from other VMs in the subnet.

Multi-zone: VMs without specified security groups are added to default-allow-egress only. This allows outbound internet access but does not allow inbound traffic from other VMs.

To allow VMs to communicate with each other within the VPC, create a custom security group with appropriate rules.

External gateways

Single-zone: Each resource group included an external gateway object visible in the API.

Multi-zone: External gateways no longer exist as customer-visible objects. The underlying behaviour is unchanged:

  • VMs can make outbound connections to the internet (if security groups allow)
  • VMs with a Public IP can receive inbound connections (if security groups allow)
  • VMs without a Public IP cannot receive unsolicited inbound connections

You do not need to reference or configure an external gateway.

Zone specification

Single-zone: All resources were created in a single zone without specifying a zone.

Multi-zone: Zonal resources require a zone specification when created:

ResourceZone required
Virtual MachineYes
DiskYes
Placement GroupYes
SubnetNo (one per zone, created automatically)
VPCNo (regional)
Public IPNo (regional)
Security GroupNo (regional)

Disks can only be attached to VMs in the same zone.

Checklist for recreating deployments

When recreating a deployment in multi-zone:

  1. Choose which zone(s) to deploy in (se-sto-a, se-sto-b, se-sto-c)
  2. Create disks in the appropriate zone
  3. Create VMs in the same zone as their disks
  4. Create a custom security group if your VMs need to communicate with each other (multi-zone does not provide a default for this)
  5. Add VMs to default-allow-web-protocols if they serve HTTP/HTTPS traffic
  6. Add VMs to default-allow-ssh if they need SSH access from the internet
  7. Update any scripts or automation that reference the old default resource names

Next steps