Building A Multi-Cloud VPN Mesh Across AWS, Azure, And On-Premises
A multi-cloud VPN mesh connects workloads in Amazon Web Services, Microsoft Azure, and a private data centre or office network through encrypted IPsec tunnels. The design gives administrators a controlled path between cloud VPCs, Azure VNets, branch locations, and on-premises services without exposing internal applications directly to the public internet.
For Australian organisations, the architecture must account for regional placement, carrier performance, and data residency. AWS has a Sydney region and Azure operates Australian regions including Australia East in Sydney and Australia Southeast in Melbourne, while users in Perth, Adelaide, or regional areas can experience different latency and circuit options.
A robust design also separates connectivity from application policy. Cloud routers exchange routes, firewalls enforce access, and monitoring verifies tunnel health. Treating the VPN as production infrastructure rather than a one-off configuration makes failover, audits, and future expansion much easier.
Define The Addressing And Traffic Model
Start with a complete IP address plan before creating any gateway. AWS VPCs, Azure VNets, offices, and data centres need unique CIDR ranges. Overlapping networks create avoidable problems with route propagation, NAT, and return traffic, particularly when an organisation acquires another business or connects a managed service using private RFC 1918 space.
A common layout assigns separate ranges to production, non-production, shared services, and management. For example, AWS production might use 10.20.0.0/16, Azure production 10.30.0.0/16, and on-premises networks 10.40.0.0/16. Reserve additional space for future regions and avoid allocating every subnet immediately.
Document which flows are required. An application in AWS may need to query an Azure database, while administrators need SSH, RDP, WinRM, or HTTPS access from on-premises. Restricting routes and security rules to these flows reduces the blast radius of a compromised workload.
Select The Transit And Routing Architecture
For a small environment, route-based IPsec tunnels can connect an AWS Transit Gateway, an Azure VPN Gateway, and an on-premises firewall. Larger deployments benefit from a hub-and-spoke approach, with AWS Transit Gateway and Azure Virtual WAN or a dedicated Azure hub VNet acting as cloud transit points. This avoids creating a full set of tunnels between every VPC, VNet, and branch.
BGP is generally preferable to static routes for a resilient mesh. It allows the gateways to advertise prefixes, withdraw failed paths, and support active-active tunnels. AWS Site-to-Site VPN supports dynamic routing through BGP, and Azure VPN Gateway can use BGP with route-based connections. Confirm ASN compatibility, supported address ranges, and maximum route limits before deployment.
When a native gateway cannot meet inspection or routing requirements, a virtual network appliance from a firewall vendor may be appropriate. Keep stateful inspection symmetrical: a packet entering through one tunnel should return through the same logical path unless the firewall and routing design explicitly support asymmetric traffic.
Build Redundant Encrypted Tunnels
Each cloud connection should use two IPsec tunnels where the provider supports them. Place the endpoints across separate availability zones or gateway instances when possible. On-premises devices should use independent WAN circuits, such as fibre and a 4G/5G backup, rather than relying on two tunnels over the same NBN service.
Use IKEv2, modern AES encryption, SHA-2 integrity, and strong Diffie-Hellman groups supported consistently by all peers. Set matching lifetimes, dead peer detection, and rekey behaviour. Record the pre-shared keys in a secrets manager instead of leaving them in deployment scripts or tickets.
| Design Area | AWS Option | Azure Option | On-Premises Consideration |
|---|---|---|---|
| Cloud transit | Transit Gateway | Virtual WAN or hub VNet | Firewall or SD-WAN hub |
| Encrypted connection | Site-to-Site VPN | VPN Gateway | Route-based IPsec |
| Dynamic routing | BGP over VPN | BGP over VPN | BGP-capable edge device |
| High availability | Two tunnels and zones | Active-active gateway | Separate carriers or devices |
| Route control | TGW route tables | VNet or Virtual WAN routing | Prefix filters and policies |
| Monitoring | CloudWatch and VPN metrics | Azure Monitor and connection metrics | Syslog, SNMP, and packet capture |
Australian offices often have asymmetric carrier options. A Sydney headquarters may have business fibre from one provider and mobile backup from another, while a regional site may depend on fixed wireless. Test the actual failover path, including its changed public IP address, before relying on it during an outage.
Configure AWS And Azure Transit
In AWS, attach VPCs to a Transit Gateway and associate each attachment with an appropriate route table. Create a VPN attachment for the on-premises firewall and, where required, a separate connection toward Azure. Use propagation selectively so development routes do not automatically become visible to production workloads.
Azure designs usually place the VPN Gateway in a dedicated gateway subnet within a hub VNet. Spoke VNets connect through peering, Virtual WAN, or a routing appliance. Enable gateway transit only where it is required, and check that user-defined routes do not override system routes unexpectedly.
For cross-cloud traffic, decide whether AWS and Azure exchange routes directly or through the on-premises hub. A direct cloud-to-cloud path normally reduces latency and avoids unnecessary egress through the data centre. However, routing every flow through a central firewall may be required for compliance, inspection, or operational consistency. Azure and AWS transfer charges should be included in the design review.
Apply Security And Operational Controls
A tunnel being established does not mean an application path is safe. AWS security groups, network ACLs, Azure NSGs, firewall policies, and host-based controls should allow only defined source and destination ports. Management access should come from a controlled administration network, with privileged sessions logged and protected by multi-factor authentication.
Use infrastructure as code for repeatable gateway, route, and firewall configuration. Terraform is useful for coordinating AWS and Azure resources, while PowerShell or vendor APIs can handle device-specific tasks. Store state securely, review plans, and prevent secrets from appearing in pipeline logs. Practical infrastructure guides can help administrators compare provider-specific implementation details before standardising modules.
Test Failover And Monitor The Mesh
Validation should cover more than a successful ping. Test DNS resolution, TCP connections, application transactions, MTU behaviour, and return routes from each security zone. IPsec overhead can reduce the effective packet size, so confirm that path MTU discovery works or configure TCP MSS clamping where required.
Simulate tunnel failure, BGP session loss, gateway maintenance, and WAN outage. Measure convergence time and confirm that applications recover within their service-level objectives. For latency-sensitive links between Melbourne, Sydney, and Perth, record baseline round-trip times and packet loss at different periods of the day.
Centralise CloudWatch, Azure Monitor, firewall logs, and BGP alerts. Useful alarms include both tunnels down, unexpected route withdrawals, rapid changes in advertised prefixes, high packet loss, and unusual cross-cloud traffic. Engineers who maintain independent VPN routing notes can also use those records to compare vendor behaviour during troubleshooting and change reviews.