--- title: "Overview - VPC" description: "Exoscale VPC provides isolated private networks per zone, with routed subnets, private IPv4 addressing, custom routes and security group filtering." url: https://community.exoscale.com/product/networking/vpc/overview/ product: "VPC" section: product last_updated: 2026-10-26 --- > For AI agents: the documentation index is at https://community.exoscale.com/llms.txt. Every page is available as markdown at `index.md` or with `Accept: text/markdown`. # Overview - VPC ## Architecture An __Exoscale VPC (Virtual Private Cloud)__ is a private, isolated network that you define and operate yourself inside a single Exoscale zone. It gives your Compute instances private addresses of your choosing, routing between the segments of that VPC, and complete traffic isolation from every other organization on the platform. A VPC is an empty container until you carve it into __Subnets__. Each Subnet holds one private IPv4 block. Instances can be attached to a Subnet and receive an address from that block. All Subnets of the same VPC can reach each other by default, and you can add your own __routes__ to steer traffic to appliances running inside the VPC. ![An example of an infrastructure using VPC](vpc.drawio.svg "An example of an infrastructure using VPC") ### A Routed Network A VPC is a __layer 3 (routed) network__, not a layer 2 segment: instead of being plugged into a shared virtual switch, each attached interface is connected to its own port on a distributed virtual router. Every packet — including traffic between two instances of the same Subnet — is routed by the platform. This means: - Only IPv4 unicast traffic is carried. Broadcast and multicast are not forwarded, so protocols that rely on them (mDNS or NetBIOS discovery, VRRP/keepalived in multicast mode, your own DHCP or PXE servers, non-IPv4 ethertypes) do not work inside a VPC. - Instances are not on a common ethernet segment, so they never see each other's MAC addresses: ARP is answered by the virtual router port. Bridging an interface into a VPC, or emitting traffic from an unknown MAC address, is not possible. - Traffic is only delivered to addresses the platform knows about — a Subnet block or a destination covered by a route. Forwarding through an instance therefore requires a [route](#routing) pointing at it (either an implicit or a custom one). ### Isolation and Addressing Each VPC is backed by a dedicated network overlay, so traffic never leaves the boundary of the VPC and is never visible to other VPCs — including other VPCs of your own organization. There is no shared address space: two VPCs may use the same private ranges without conflicting. Addressing is entirely under your control, as long as the subnet IPv4 blocks are contained in the [RFC 1918](https://datatracker.ietf.org/doc/html/rfc1918) range (`10.0.0.0/8`, `172.16.0.0/12` or `192.168.0.0/16`) ### Attaching Instances A Compute instance joins a VPC by being attached to one of its Subnets. The attachment adds a network interface to the instance, with an IPv4 address either picked automatically from the Subnet block, or specified by you at attachment time. No extra configuration is required inside the instance as everything is configured via DHCP. Attachment and detachment are performed while the instance is running — no reboot is required. An instance may be attached to several Subnets of the same VPC at once, but it cannot be attached to two different VPCs. ### Routing There are two kinds of route objects: * __Implicit routes__ or __VPC route__ are created for you whenever a Subnet is added, so every Subnet of a VPC can reach every other Subnet of that VPC without any configuration. Those routes are managed by Exoscale and cannot be modified directly * __Custom routes__ or __Subnet routes__ are attached to a specific Subnet and apply to the traffic of the instances in that Subnet. A route is a destination CIDR plus a target expressed as `ip=` — the next hop that should receive the traffic. Custom routes are what you use to place an appliance in the traffic path: a firewall, a NAT or VPN gateway, an IDS, or any instance you have set up to forward packets. Traffic destined outside the VPC (including internet-bound traffic) is only possible through such an instance, since a VPC has no gateway of its own. For a given instance, the custom routes that come from its subnet and the implicit routes that come from the VPC are merged and applied. The most precise route takes priority and for route with the same destination, the subnet one is preferred. ### Traffic Filtering VPC interfaces are filtered by the [Security Groups](https://community.exoscale.com/product/networking/security-group/index.md) of the instance, exactly like public interfaces. Rules therefore apply to the private traffic of your instances, and can reference other Security Groups or CIDR blocks of your Subnets. ## Terminology VPC : A private, isolated network scoped to a single organization and a single zone. It is a container for Subnets and routes; it carries no address block itself. Default VPC : A VPC that is provisioned automatically for your organization. It behaves like any other VPC but cannot be deleted. You have one default VPC per zone. Subnet : A segment of a VPC, defined by a single private IPv4 block (its `ipv4-block`). Instances are attached to Subnets, not to the VPC directly. A Subnet is where the addressing, the attachments and the custom routes live. Address family : The protocol version used by a Subnet. Only `inet4` (IPv4) is supported today. Address space : The kind of addressing used by a Subnet. Only `private` is supported today, which restricts blocks to the RFC 1918 ranges. Attachment : The link between a Compute instance and a Subnet. It materialises as a network interface on the instance, holding one IPv4 address from the Subnet block. Route : A rule to direct VPC traffic to specific target. Can be either a VPC route or a Subnet route. Subnet Route / Custom route : A rule directing traffic for a destination CIDR to a target next hop, expressed as `ip=`. Routes are scoped to a Subnet. VPC route / Implicit route : A route created and maintained by the platform when a Subnet is added, ensuring reachability between all the Subnets of a VPC. ## Features Private, isolated networking : Your VPC traffic stays inside your VPC. Isolation is enforced by the platform at the network layer, with no address space shared between VPCs. Your own addressing plan : Choose your Subnet blocks in the RFC 1918 ranges, size them for your workloads, and assign fixed private IPv4 addresses to the instances that need them. Multi-Subnet segmentation : Split a VPC into up to 50 Subnets to separate tiers, environments or tenants, while keeping them mutually reachable and centrally managed. Custom routing : Add routes to direct traffic through your own appliances — firewalls, NAT or VPN gateways, or any instance acting as a router — without touching the configuration of the workloads behind them. Live attachment : Attach and detach running instances from Subnets without a reboot, so networking can follow your deployments instead of driving them. Security Group filtering : Reuse the Security Groups you already apply to your instances to filter private traffic inside the VPC. Labels : VPCs and Subnets support [labels](https://community.exoscale.com/product/compute/instances/how-to/labels/index.md), so they can be organised and selected like the rest of your Exoscale resources. Full API, CLI and Terraform coverage : Everything described here is available through the [API](https://community.exoscale.com/reference/api/networking/vpc/index.md) and the [`exo networking vpc` commands](https://community.exoscale.com/reference/cli/exo/networking/vpc/index.md), so VPCs can be created and wired up from your infrastructure-as-code pipelines.