Quick answer: Hybrid cloud networking connects on-premises offices and data centers to public cloud platforms such as Azure, AWS and Google Cloud so applications and users can communicate securely across both. For small businesses it usually means a site-to-site IPsec VPN, a hub-and-spoke cloud network, a non-overlapping IP address plan, hybrid DNS resolution and centralized security controls, with private circuits added only when needed.
Key takeaways
- Plan IP addressing first; overlapping ranges between offices and cloud networks are the most painful mistake to fix later.
- Site-to-site IPsec VPN is sufficient for most small businesses; private circuits such as ExpressRoute or Direct Connect suit higher, predictable throughput needs.
- A hub-and-spoke design centralizes connectivity, security and shared services in the cloud.
- Hybrid DNS must be designed deliberately, especially when using private endpoints.
- Build redundancy with two tunnels, ideally over two internet circuits.
When a business moves servers into Azure, AWS or Google Cloud, the office network does not disappear; it needs a reliable, secure path to those cloud workloads. Hybrid cloud networking is that path. Getting it right early avoids re-addressing networks, broken name resolution and fragile tunnels later. This guide covers the practical decisions for small businesses and nonprofits, and it is part of our networking and IT infrastructure services.
What is hybrid cloud networking?
Hybrid cloud networking is the set of connections, routing, name resolution and security controls that let on-premises sites and cloud networks behave as one private network. Common scenarios include:
- Offices reaching file servers, databases or line-of-business applications that were migrated to cloud VMs
- Cloud workloads reaching systems that remain on-site, such as a phone system or a manufacturing controller
- Hybrid identity, with domain controllers in both locations during a transition
- Backups or disaster recovery replicating from the office to the cloud
Step 1: How should IP addressing be planned?
Plan a non-overlapping address scheme for every site and cloud network before building anything. This is the most common and most expensive mistake to undo.
An example plan for a small organization using the 10.0.0.0/8 private range:
| Network | Range | Notes |
|---|---|---|
| Headquarters office | 10.10.0.0/16 | VLANs carved from this range |
| Branch office | 10.11.0.0/16 | One range per site |
| Remote access VPN or ZTNA pool | 10.20.0.0/22 | If required |
| Azure hub | 10.100.0.0/22 | Gateway, firewall, DNS resolver |
| Azure production spoke | 10.101.0.0/20 | Workload subnets |
| AWS VPC (if multi-cloud) | 10.110.0.0/20 | Kept distinct from Azure |
| Reserved for growth | 10.120.0.0/13 | Future sites and clouds |
Avoid 192.168.0.0/24 and 192.168.1.0/24 in offices, since home routers use them and remote users will collide. Do not accept default ranges proposed by cloud portals without checking them against the plan.
Step 2: How should the cloud network be designed?
Use a hub-and-spoke topology for anything beyond a single small workload. The hub holds shared connectivity and security; spokes hold workloads.
| Cloud | Hub and connectivity components | Spoke connection |
|---|---|---|
| Microsoft Azure | Virtual network with VPN Gateway, Azure Firewall or a network virtual appliance, DNS Private Resolver; or Azure Virtual WAN | Virtual network peering |
| AWS | Transit Gateway with Site-to-Site VPN attachments, optional inspection VPC, Route 53 Resolver endpoints | Transit Gateway attachments |
| Google Cloud | Hub VPC with Cloud VPN (HA VPN) and Cloud Router, Network Connectivity Center | VPC peering or Shared VPC |
This structure should be part of your cloud foundation. It aligns with the Azure governance framework and an AWS landing zone, which define how networks, subscriptions or accounts and policies are organized.
Step 3: VPN or private circuit?
Most small businesses should start with a site-to-site IPsec VPN; private circuits are for specific needs.
| Option | Examples | Strengths | Trade-offs |
|---|---|---|---|
| Site-to-site IPsec VPN | Azure VPN Gateway, AWS Site-to-Site VPN, Google Cloud HA VPN | Fast to deploy, low cost, encrypted, uses existing internet | Performance depends on internet quality; throughput limits per tunnel |
| Private circuit | Azure ExpressRoute, AWS Direct Connect, Google Cloud Interconnect | Consistent latency, higher throughput, does not traverse the public internet | Monthly port and circuit costs, carrier lead times, needs a VPN backup |
| SD-WAN cloud integration | Virtual SD-WAN appliance in the cloud hub | Unified policy across many sites and clouds | Added licensing and complexity |
For resilience, configure two tunnels to the cloud gateway, ideally from two firewalls or over two internet circuits, and use BGP routing where supported so failover is automatic. Organizations with many sites should consider designing this alongside SD-WAN.
Step 4: How should routing and DNS work?
Routing must be predictable and DNS must resolve the same names correctly from both sides.
Routing
- Use BGP over VPN tunnels where possible for dynamic failover; static routes are acceptable for a single simple site
- Summarize routes per site to keep tables simple
- Decide whether internet-bound traffic from the cloud exits locally in the cloud or through a central firewall
DNS
- Forward queries for on-premises domains from the cloud to on-premises DNS servers
- Forward queries for cloud private zones from on-premises to a cloud DNS resolver endpoint
- Plan carefully for private endpoints, such as Azure Private Link or AWS PrivateLink, which require private DNS zones so services resolve to private IP addresses from both the office and the cloud
DNS misconfiguration is the most common cause of "the VPN is up but the app does not work" problems after migration.
Step 5: What security controls apply?
Treat the cloud connection as a link between trust zones, not as an extension of a flat network.
- Filter traffic with network security groups (Azure), security groups and network ACLs (AWS) or firewall rules (Google Cloud)
- Inspect traffic between the office and cloud workloads with a firewall in the hub where justified
- Avoid public IP addresses on VMs; use private connectivity and bastion services for administration
- Restrict which office VLANs can reach which cloud subnets
- Enable flow logs and firewall logs for investigation
These controls follow the same principles as zero trust network architecture: grant the minimum necessary access between networks.
Step 6: How do you test and document?
Before migrating workloads, test the connection under realistic conditions:
- Fail each tunnel and confirm traffic moves to the other
- Confirm DNS resolution from office to cloud and cloud to office, including private endpoints
- Measure latency and throughput for key applications
- Verify security rules block what they should
- Document the IP plan, diagrams, tunnel parameters and routing in your network documentation
Hybrid networking best practices
These practices summarize the steps above into a checklist you can use to review an existing hybrid network.
- Plan IP addressing for every office, data center and cloud network before building anything, and keep a central record of ranges.
- Use a hub-and-spoke design so connectivity, firewalls and shared services live in one place.
- Build redundancy: two tunnels at minimum, ideally over two internet circuits or a private circuit with VPN backup.
- Design hybrid DNS deliberately, with conditional forwarding in both directions and a plan for private endpoints.
- Filter traffic between on-premises and cloud networks by application and port instead of allowing all traffic.
- Turn on flow logs and connection monitoring, and alert on tunnel failures.
- Define cloud networking as code so changes are reviewed and repeatable.
- Test failover on a schedule and document the design, addresses and routing.
How does hybrid networking fit into a cloud migration?
Network design should happen early in a migration, before workloads move. The cloud migration checklist includes connectivity as a prerequisite, because applications that depend on low-latency access to on-site systems may need to move together or be redesigned. For on-site office layout and addressing, see small business network design.
What should nonprofits consider?
Nonprofits using cloud credits or discounted cloud programs from Microsoft, AWS or Google should keep networking costs in view: VPN gateways, data transfer and private circuits add recurring charges outside many credit allowances. Starting with a right-sized VPN gateway and reviewing usage after migration keeps costs predictable.
Next steps
Start with an IP address plan and a list of the workloads that must be reachable privately. Desai InfoTech designs hybrid connectivity for Azure, AWS and Google Cloud as part of migration and infrastructure projects; contact us or request a free cloud assessment.
How to connect an office network to the cloud: step-by-step summary
Plan IP addressing
Allocate non-overlapping address ranges for every office and cloud network, with room to grow.
Design the cloud network
Create a hub network for connectivity and shared services, with spoke networks for workloads.
Establish connectivity
Deploy the cloud VPN gateway and configure redundant IPsec tunnels from the office firewall.
Configure routing and DNS
Set up static or BGP routing and conditional DNS forwarding in both directions.
Apply security controls
Restrict traffic with security groups and firewalls, and enable logging.
Test failover and document
Test tunnel and circuit failover, then document the design and configuration.
Frequently asked questions
Do I need ExpressRoute or Direct Connect?
Most small businesses do not. A site-to-site IPsec VPN over a good internet connection handles typical workloads such as file access, line-of-business applications and remote desktops. Private circuits like Azure ExpressRoute, AWS Direct Connect or Google Cloud Interconnect make sense for sustained high throughput, consistent latency requirements, large data transfers or compliance needs, and they add monthly circuit and port costs.
What is hub-and-spoke network design?
Hub-and-spoke is a cloud network topology where a central hub virtual network holds shared services such as the VPN gateway, firewall and DNS, and separate spoke networks hold workloads like production, test or specific applications. Spokes connect to the hub through peering or a transit gateway. It centralizes security and connectivity while isolating workloads from each other.
Why do overlapping IP ranges cause problems?
Routers cannot send traffic correctly when the same address range exists in two places that need to communicate. If the office and a cloud network both use 10.0.0.0/16, the VPN cannot route between them without complex network address translation. Overlaps commonly appear when cloud networks are created with default ranges, so plan addressing before building anything.
Do we need a VPN if we only use Microsoft 365?
No. Microsoft 365 is accessed over the internet and protected by identity controls such as MFA and conditional access. Hybrid cloud networking is needed when you run your own workloads in Azure, AWS or Google Cloud, such as virtual machines, databases or file services, that should be reached privately from offices rather than exposed to the internet.
What are the best practices for hybrid networking?
The core best practices are to plan non-overlapping IP ranges before building anything, use a hub-and-spoke design to centralize connectivity and security, run two VPN tunnels or circuits for redundancy, design hybrid DNS deliberately, filter traffic between on-premises and cloud rather than allowing everything, log and monitor connections, define the network as code, and test failover regularly.
Part of the Networking & IT Infrastructure Services hub.