# Ensure Resources Are Deployed Within A VPC - Source: https://support.icompaas.com/support/solutions/articles/ensure-resources-are-deployed-within-a-vpc - Section: [Solutions](https://support.icompaas.com/support/solutions) › [DigitalOcean Cloud](https://support.icompaas.com/support/solutions/c_do_cloud) › [DigitalOcean Rules](https://support.icompaas.com/support/solutions/folders/digitalocean-rules) - Last updated: 2026-08-13 - Publisher: iCompaas, Inc. (https://www.icompaas.com) ## Description This rule verifies that Droplets, managed databases, load balancers, and Kubernetes clusters run inside a purpose-created VPC network rather than the region's default VPC. On DigitalOcean there is no such thing as a resource with no VPC: every applicable resource created since 1 October 2020 is placed on a VPC automatically. The meaningful control is therefore whether that VPC is a dedicated network you defined for an environment or tier, or simply the shared per-region default VPC that everything lands in when no network is specified. The default VPC (named default-) exists in every region, keeps the legacy private-networking IP range for backward compatibility, and cannot be deleted. Because every unspecified resource lands there, it tends to accumulate unrelated workloads on one flat private network. Placing resources in dedicated VPCs restores the isolation and segmentation a default catch-all network cannot provide. - Droplets, databases, load balancers, or clusters residing in the region's default- VPC. - Production and non-production resources sharing the same default VPC. ## Rationale A VPC is a private network boundary: resources in one VPC cannot reach resources in another over private networking, and VPC traffic stays off the public internet. When everything defaults into a single per-region network, unrelated systems (including production and test) sit on the same flat private segment, so a compromise of any one host has private-network reach to all the others. Dedicated VPCs per environment or tier give you real segmentation and let firewall rules key off VPC membership. Deliberately choosing the VPC for each resource also makes network intent explicit, which is far easier to audit than a shared default that fills up implicitly. ## Impact Pros: - Provides private-network isolation between environments and tiers. - Contains lateral movement: a compromised host cannot privately reach unrelated resources in other VPCs. - Makes network placement an explicit, auditable decision. Cons: - VPC membership is set at creation; moving an existing Droplet to a different VPC requires a power-off and migration, and some resources must be rebuilt. - More VPCs means more network design and management overhead. ## Default Value Every region has a default VPC (default-); Droplets, databases, load balancers, and Kubernetes clusters created since 1 October 2020 are automatically added to that default VPC unless a specific VPC is chosen at creation. ## Pre-Requisite - A DigitalOcean member with write access to create VPCs and provision resources. - A network design mapping environments/tiers to dedicated VPCs. - doctl or an API token with VPC read/write scope for CLI/API checks. ## Remediation ### Test Plan Using the DigitalOcean Control Panel: 1. In the Control Panel, go to Networking, then VPC. 2. Select each VPC to view its member resources, or open a Droplet/database and check its Networking details for the VPC name. 3. Identify resources whose VPC is the region's default- network. 4. Pass: resources reside in dedicated, purpose-created VPCs appropriate to their environment. 5. Fail: resources that should be isolated are sitting in the region's default VPC. Using doctl or the API: List VPCs and their members to see which resources are in the default versus dedicated VPCs. doctl vpcs list curl -s -H "Authorization: Bearer $DIGITALOCEAN\_TOKEN" "https://api.digitalocean.com/v2/vpcs" curl -s -H "Authorization: Bearer $DIGITALOCEAN\_TOKEN" "https://api.digitalocean.com/v2/vpcs//members" In the vpcs list, the default network has \`"default": true\`. Pass: sensitive resources are members of non-default VPCs. Fail: they are members of the \`default: true\` VPC when isolation was intended. ### Implementation Steps Using the DigitalOcean Control Panel: 1. In Networking, then VPC, click Create VPC Network; choose the region, name it for the environment/tier, and optionally set its private IP range. 2. Provision new resources into the dedicated VPC by selecting it under VPC Network in the Droplet/database/cluster creation flow. 3. For existing Droplets, follow 'How to Configure VPC Networking on an Existing Droplet' (power off and migrate); rebuild resources that cannot be migrated in place. Using doctl or the API: Create a dedicated VPC via doctl/API, then select it when provisioning resources (resource creation flags are per-product). doctl vpcs create --name --region curl -X POST -H "Content-Type: application/json" -H "Authorization: Bearer $DIGITALOCEAN\_TOKEN" -d '{"name":"","region":""}' "https://api.digitalocean.com/v2/vpcs" doctl compute droplet create --image --size --region --vpc-uuid ### Backout Plan: 1. Moving resources back is disruptive; to revert, migrate the Droplet to its prior VPC (power off, migrate) or reprovision it selecting the original network. 2. An empty dedicated VPC created during remediation can be deleted; the region's default VPC cannot be deleted. ## References: 1. [VPC](https://docs.digitalocean.com/products/networking/vpc/) 2. [How to Configure VPC Networking on an Existing Droplet](https://docs.digitalocean.com/products/networking/vpc/how-to/enable/) 3. [How to Set a Default VPC](https://docs.digitalocean.com/products/networking/vpc/how-to/set-default-vpc/) 4. [doctl vpcs](https://docs.digitalocean.com/reference/doctl/reference/vpcs/) ## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.