Why this matters
How to separate production and development networks comes down to blast radius. A developer laptop, a test job or a bad script should not be able to touch live customer data or take down a service. Network separation is one layer of that control, not the whole of it.
Most accidents start small. Someone copies a production connection string into a test config. A load test points at the live endpoint. A stale VPN route lets a staging box reach a production database. Each of those becomes less likely when dev and prod have separate accounts, separate credentials and no route between them.
The goal is not to make life hard for engineers. Dev needs room to break things. Prod needs a tight boundary with few doors and good logs. Treat the two as different environments with different rules, then make the safe path the easy path through templates, pipelines and default settings.
Before you start
Draw the current picture before you change anything. List every network, account, VPC or VNet, subnet, peering, VPN, DNS zone, load balancer and database that dev or prod uses. Mark which ones are shared today. Shared pieces are where the work hides.
Choose the isolation unit. A separate AWS account, Azure subscription or Google Cloud project per environment is the cleanest boundary, because it separates billing, identity, quotas and network defaults. If you cannot do that, use separate VPCs or VNets in the same account and do not peer them. Do not rely on subnet names alone.
Plan address space so it never overlaps. Pick a range for production and a different range for dev, then reserve room for growth. Overlapping CIDR blocks make peering, VPNs and migrations painful later. Write the ranges down in your IP address plan and check them against every existing network.
Agree on the rules before the build. Who can approve a production change? Which people need break glass access? Which services may talk to each other? Where will logs go? Put those answers in a short document that the team can review. You will need it when you test the boundary.
How to do it
Build the new boundary first, then move workloads into it. Do not try to bolt separation onto a flat network by renaming subnets. Start with a new production account or project, create the network there, and migrate one low risk service as a pilot. Once that works, repeat the pattern.
Keep the environments apart at every layer that matters: identity, network, DNS, secrets, data and deployment. A single shared admin role or shared DNS zone can reopen the path you just closed. The steps below cover the order that causes the fewest outages.
- Split by account, subscription or project. Create a production account, subscription or project that is separate from dev. Use AWS Organizations, Azure management groups or Google Cloud folders to apply guardrails at the top. Move production workloads into that boundary instead of sharing the old one.
- Allocate non-overlapping address space. Give production and dev different CIDR ranges and record them in one IP plan. Check every VPC, VNet, on-premises network and VPN before you commit. Leave gaps for future services so you do not have to renumber later.
- Create networks with no route between them. Build separate VPCs, VNets or VPC networks for each environment. Do not add peering, a transit gateway attachment, or a VPN route that connects dev to prod. If you need shared services, put them in a controlled shared services account and allow only named traffic.
- Separate identity and secrets. Create distinct IAM roles, groups and service accounts for dev and prod. Keep production secrets in a separate secret store or key management system, and do not grant dev roles read access. Remove standing admin rights from humans and use short lived elevation for production work.
- Split DNS and certificates. Use different DNS zones or subdomains for dev and prod, and do not put production records in the dev zone. Issue certificates for each environment from the same trusted process, but keep private keys separate. Check that a dev host cannot resolve a production database name.
- Scope deployment pipelines to one environment. Give each environment its own pipeline identity and its own infrastructure state file. A dev build should deploy only to dev, and a production deploy should require a separate approval and a production runner. Never let a dev job read production deployment credentials.
- Default deny egress and allow named destinations. Start with no outbound access except DNS and the package sources you approve. Add rules for named services, private endpoints and update servers. Log denied traffic so you can see what breaks and why.
- Move data through a sanitized export. Do not copy production databases into dev. Build an export that removes or masks customer data before it leaves the production boundary. Run that export on a schedule and treat the dev copy as untrusted.
- Test the boundary from both sides. Try to reach production from a dev host, and dev from production. Check DNS, database ports, object storage and internal APIs. Fix any path that opens, then test again after every network change.
How to check it worked
Run connection tests from a dev instance to every production endpoint you know about. Try the database port, the internal API, the object storage endpoint and the admin console. Use AWS VPC Reachability Analyzer, Azure Network Watcher connection troubleshoot or Google Cloud Connectivity Tests where they fit your cloud. A timeout or a refused connection is the result you want.
Check identity and DNS separately from the network. From a dev role, try to read a production secret, assume a production role and resolve a production hostname. All three should fail. If DNS still answers, fix the zone before you call the job done. DNS leaks are common when teams share a private zone.
Review logs for denied attempts and for successful logins from the wrong side. Turn on VPC flow logs, NSG flow logs or firewall logs and send them to a central account. Look at the pipeline too: a dev build should not be able to push to production. Run one deliberate test deploy and confirm the approval step and the production identity are both required.
Check drift after two weeks. Compare the live network against your infrastructure as code, and look for new peering, routes or firewall rules. People add shortcuts under deadline pressure. A short monthly review catches them before they become permanent.
Mistakes to avoid
Separate subnets in one VPC are not a network boundary. A misconfigured route table, a broad security group or a shared load balancer can still connect them. If you need a real boundary, use separate accounts, projects or at least separate VPCs with no route.
A shared admin role undoes the network work. If the same people or CI jobs can change both environments with the same credentials, a mistake in dev can still reach prod. Split the roles, require separate approval, and keep break glass access logged and short.
Overlapping CIDR blocks and shared DNS zones cause long delays. They also tempt people to add a route or a peering just to make one test work. Fix the address plan and the zone design before you migrate. Watch for old VPNs and peering connections that nobody owns.
Do not put production data in dev to make tests realistic. Use masked or synthetic data, and keep the export path under production control. Network separation does not replace patching, least privilege or monitoring. It buys you time when one of those fails. If you want an outside check before you cut over, the Cloudverg Expert architecture session costs $450 one-time and includes a 90 minute call plus a written summary. It is one option among others.
Frequently asked questions
Should production and development use separate AWS accounts?
Yes, when you can. A separate account gives you a cleaner identity, billing and network boundary than separate subnets or VPCs in one account. Use AWS Organizations and service control policies to keep guardrails consistent. If a separate account is not possible, use separate VPCs and no route between them.
Can dev and prod share a VPC with different subnets?
They can, but it is a weak boundary. Security groups, route tables and a shared load balancer can create paths you did not intend. Use separate VPCs at minimum, and separate accounts if you need strong isolation. Labeling a subnet production does not make it production.
What should I test after separating the networks?
Test connectivity in both directions, DNS resolution, role assumption, secret access and pipeline permissions. Confirm that a dev host cannot reach production databases or internal APIs. Check the logs to see the denied attempts, then repeat the test after any network change.