Region-scoped: a VPC network is created in a specific datacenter region and resources must be in that same region to be attached, whereas OpenStack Neutron networks/subnets are generally available across all AZs in a region and attachments are controlled by network reachability rather than an explicit region slug ().
Resource migration is limited: Droplets require snapshot/recreate to move between VPCs and some resources (Kubernetes clusters, load balancers, NAT gateways) cannot be migrated between VPCs, whereas in OpenStack you typically can attach/detach ports or move router interfaces without recreating servers (behavior depends on deployment, but Neutron’s object model supports it) ().
NAT is a managed NAT Gateway with tiered capacity (1–16 increments; each increment gives 25 Mbps symmetrical bandwidth and 100 GiB outbound transfer/month) and can be set as the default gateway for the VPC, whereas OpenStack commonly expresses egress via Neutron routers with SNAT and does not use this specific ‘size tier’ model ().
Security-policy coupling differs: DigitalOcean notes Cloud Firewall rules affect both public and VPC traffic and rules must specify whether they apply to the public or private IP range, whereas in OpenStack security groups are generally applied to ports and are not framed as “public vs private IP range” rule modes ().
Networks are isolated Layer 2 segments that give your instances connectivity. Instances attach to at least one network; most production deployments use private networks with routers and floating IPs for controlled internet access.
The Network service (OpenStack Neutron) defines each network as a broadcast domain. Within it, you create one or more subnets that assign IP address ranges, gateways, and DHCP settings. Instances connect to networks through ports: each port carries an IP address and a MAC address and represents a virtual network interface on the instance.
Your project scopes networks to that project by default: only instances within the same project can communicate over a private network. This isolation is fundamental to multi-tenant security in the cloud.
PublicEphemeral: lets you attach an instance directly to the internet. Best for testing and quick experiments, since the instance is fully exposed on the provider network with no router or NAT in between.
PublicStatic: provides controlled internet access through a router. You cannot attach an instance directly to PublicStatic; create a private network, attach a router to both PublicStatic and your private network, and use floating IPs for inbound access. Production workloads use this path when they need stable public addresses and private subnets.
Routers link private networks to external networks and to each other, providing Layer 3 routing and NAT. Floating IPs give instances a stable public address that survives reboots and can be moved between instances. Security groups filter traffic at the port level, acting as a virtual firewall closest to the workload. For traffic distribution, run a reverse proxy on an instance or connect an external edge service.
Together, these components let you build network topologies from simple single-network setups to multi-tier architectures with web, application, and database segments.
Click to zoom
Network topology: private networks connect to the internet through a router and floating IPs
For a single application or experiment, one private network with a router and a floating IP is enough. As your project grows, separate tiers into distinct networks (web-facing instances on one network, application logic on another, databases on a third) and use routers and security groups to control traffic between them.
Consider your IP addressing scheme early. Subnet CIDR ranges cannot overlap within the same router, and changing them later means recreating the network. Plan for growth by using ranges larger than your immediate need.