Resilient multi-cloud network backbone
A redundant HA firewall pair anchoring connectivity between a physical datacenter, several regional offices reached over ISP-provided MPLS, and multiple AWS accounts plus Azure — with environment-scoped tunnels and a DDoS scrubbing layer in front of the internet-facing edge.
Overview
Everything on the network side — the datacenter, every regional office, and every cloud account — ultimately terminates on one active/passive pair of next-generation firewalls. That single choke point is deliberate: it's the one place policy, logging, and failover all get enforced consistently, rather than being reimplemented per cloud provider.
┌── AWS DEV ─────────┐
├── AWS TEST ─────────┤
[ Regional offices ] ├── AWS PROD (region A)┤
MPLS / L3VPN ├── AWS PROD (region B)┤
│ └── AWS PrivateLink ───┘
▼ ▲
[ Edge routers, redundant pair ] │
│ [ Firewall HA pair ] ◄──── Internet ── [ DDoS scrubbing ]
│ │
[ On-prem datacenter ] ├── Azure — core / test / dev gateways
└── Managed streaming-analytics VPN pair
1. The HA firewall pair as the single point of policy
Two next-gen firewalls run active/passive with a dedicated HA heartbeat link between them. Every tunnel — datacenter-to-cloud, office-to-datacenter, cloud-to-cloud — terminates on this pair rather than being scattered across individual cloud-native gateways. That gives one place to see, log, and fail over every path in and out of the network, at the cost of the pair itself being a critical dependency — which is exactly why it's HA rather than a single box.
2. Environment-scoped cloud tunnels
Rather than one tunnel per cloud provider, tunnels are scoped per environment: separate tunnel pairs for AWS production (split across two regions for resilience), AWS test, and AWS dev. If a dev-account credential or a test-side misconfiguration causes a problem, it's contained to that tunnel and that account — it can't silently affect production traffic.
The full set of cloud environments reached from the firewall pair on this backbone (account/region names below are illustrative, standing in for the real account structure):
| Environment | Provider / region | Purpose |
|---|---|---|
| DEV-EU-WEST-1 | AWS | Development workloads, western EU region |
| PROD-EU-WEST-1 | AWS | Production workloads, western EU region |
| PROD-EU-NORTH-1 | AWS | Primary production region |
| TEST-EU-NORTH-1 | AWS | Pre-production validation, isolated from the prod tunnel |
| DEV-EU-NORTH-1 | AWS | Development workloads, primary region |
| DEV-EU-CENTRAL-1 | AWS | Development workloads, central EU region; hosts an application-streaming service reached over this tunnel |
| AWS PrivateLink | AWS | Select service integrations that shouldn't traverse a general-purpose tunnel at all |
| CORE-West-Europe | Azure | Core/production Azure workloads, West Europe |
| TEST-West-Europe | Azure | Azure test environment, West Europe |
| DEV-West-Europe | Azure | Azure development environment, West Europe |
| Data-warehouse peering | AWS ↔ AWS | Dedicated redundant VPN pair peering a production account directly to a managed data-warehouse platform account, kept off the general-purpose paths |
3. Regional offices over carrier-provided circuits
Regional offices connect back to the datacenter over a mix of carrier-provided circuits rather than public internet — removing an entire class of internet-path availability and interception concerns for office-to-datacenter traffic. Connection type is matched to each office's size and criticality rather than applying one pattern everywhere:
| Site | Connection type | Notes |
|---|---|---|
| Office — Market A (HQ-adjacent) | MPLS (Layer 2) | Highest-bandwidth office link, Layer 2 extension back to the datacenter |
| Office — Market B | L3VPN over MPLS | Standard office pattern for this market |
| Office — Market B, secondary site | Site-to-site VPN | Smaller secondary site in the same market, VPN over internet rather than dedicated circuit |
| Office — Market C | L3VPN over MPLS | Standard office pattern for this market |
ISP hand-off pattern
At the datacenter side, the carrier hands off through a redundant pair of edge routers, each carrying its own internet uplink and an inter-router IP-link, with the pair's inside interfaces bonded via LACP into the firewall side. VRRP provides a shared virtual gateway address so a single edge router failure doesn't change anything from the firewall's point of view.
Edge router A
IP-link: 10.255.0.1/24
Internet uplink: 203.0.113.9/29 (VRRP shared: .1)
Edge router B
IP-link: 10.255.0.2/24
Internet uplink: 203.0.113.10/29 (VRRP shared: .1)4. DDoS mitigation at the edge
A cloud-based DDoS scrubbing service sits upstream of the firewall pair on the internet-facing side. Traffic is only allowed to reach the firewalls after it's passed through scrubbing, keeping the volumetric-attack surface off the firewall pair entirely rather than relying on the firewalls' own throughput to absorb an attack.
5. Keeping the topology discoverable
A live network inventory tool (LibreNMS) is kept as the source of truth for "what's actually out there" — device models, interface status, and throughput — so the diagram above stays a mental model, not the only record. Anyone troubleshooting a path issue starts there rather than guessing from a static diagram that may be a few changes out of date.
Design checklist for this pattern
- Every cloud/office path terminates on the same HA firewall pair — no shadow gateways created outside that policy point
- Tunnels scoped per environment (prod/test/dev), never shared across environments
- Production split across at least two regions/paths where the provider supports it
- Office connectivity routed over carrier MPLS/L3VPN rather than public internet where available
- DDoS scrubbing placed upstream of the firewall pair, not behind it
- Live network inventory tool kept current and treated as the source of truth over static diagrams