Connecting Your Network to the MoCy Platform: Interconnects, Three Ways

This is the final post in our series introducing the MoCy Platform. Part one covered the platform architecture and why we built it; part two introduces our private AI agent architecture. This one is for the network engineers.

The enclave is yours. The interconnect is how it reaches you.

Every MoCy customer gets a dedicated, single-tenant enclave: their own cloud environment, in their own dedicated account, in their chosen regions, running their services — ModernISE today. The enclave carries everything the service needs to be production-grade: the service nodes, load balancing, routing, DNS, certificates, and backups, all deployed and maintained by platform orchestration.

What remains is the question every network architect asks first: how does my network reach it?

That's the job of the MoCy Interconnect — the data plane between your environment and your enclave. RADIUS and TACACS+ from your switches, wireless controllers, and VPN headends ride the interconnect into your enclave, encrypted end to end. And because no two enterprise WANs look alike, the interconnect is designed to meet your network where it already is, with three integration patterns you can mix and match per region.

A design principle before the details: the interconnect is a data plane between you and your enclave only. The MoCy control plane orchestrates the enclave from the outside but has no data plane into it and no direct IP access to your network. Connectivity to your environment terminates in your single-tenant enclave, inside your dedicated cloud account — never in shared infrastructure.

Option 1 — Site-to-site VPN: works with what you have

The standard pattern, and the fastest to deploy. Each enclave region runs its own VPN termination, and your existing edge — any mainstream firewall or router — builds redundant IPsec tunnels to each region. Cross-connecting your edge devices to both enclave regions gives you a resilient mesh: any single tunnel, edge device, or even an entire enclave region can fail and your authentication traffic keeps flowing.

Because this is plain, standards-based IPsec, there is nothing exotic to procure and no agent to install. The MoCy App generates sample configuration for your side of the tunnel, shows live tunnel status per peer, and monitors the interconnect continuously — the same connection details, routing, and tunnel-state view for every region in your enclave.

Best for: most customers, most of the time. Multi-site organizations backhaul remote-site RADIUS across their existing WAN to the sites that terminate the tunnels.

Option 2 — AWS VPC peering: ride the WAN you already built

If you already operate an AWS footprint, your WAN has already solved the hard part. Enterprises with Direct Connect circuits or an SD-WAN fabric terminating in a VPC have spent years engineering exactly the private, low-latency, high-bandwidth path that authentication traffic wants.

VPC peering lets your enclave join that path. We peer the enclave's VPC directly with your VPC, and from there your existing routing takes over: RADIUS from headquarters arrives over your Direct Connect; branch traffic arrives over the SD-WAN fabric you already run into AWS; nothing new is tunneled over the public internet, and no additional VPN infrastructure is deployed or maintained on your side.

This is the pattern that surprises people in the best way — the enclave stops being "a cloud service I connect to" and becomes another private segment of the network you already have. Your traffic engineering, your monitoring, your security controls all apply unchanged.

Best for: AWS-centric enterprises, Direct Connect owners, and anyone whose SD-WAN already lands in a VPC.

Option 3 — SD-WAN routers in the enclave: the enclave becomes a branch

For organizations that run their WAN as an SD-WAN fabric end to end, the cleanest integration is to make the enclave a first-class member of the fabric. In this pattern we deploy your SD-WAN virtual routers inside the enclave itself — a Meraki vMX pair joining your AutoVPN topology, or Cisco Catalyst SD-WAN edges, bring-your-own-license.

The result: your enclave appears in your dashboard as, effectively, another branch. Your AutoVPN or OMP topology extends to it automatically. Your segmentation, traffic policies, and path selection apply to authentication traffic the same way they apply to everything else on the fabric. Remote sites reach the enclave directly across the fabric — no backhaul through a headquarters hub, no per-site tunnel engineering.

Deploying the vMX pair uses two platform Node Add-ons, and as with everything else in the enclave, the platform handles the underlying infrastructure lifecycle while you keep policy control of your own fabric.

Best for: Meraki AutoVPN and Cisco Catalyst SD-WAN shops that want one operational model for the entire WAN — enclave included.

Choosing a pattern

These aren't mutually exclusive. A global enterprise might peer VPCs in North America where its Direct Connect lives, run site-to-site VPN in a region with no cloud footprint, and extend its Meraki fabric into an APJ enclave — all within one organization, all visible in one Interconnect dashboard.

Operationally boring, by design

Whichever pattern you choose, the platform treats the interconnect as a managed, monitored component of your enclave — not a one-time setup task. Tunnel and peering status is continuously tracked and surfaced in the MoCy App with per-peer detail. Interconnect configuration is part of your enclave's declared state, so drift is detected like any other infrastructure change, and every modification is checkpointed and deployable — or reversible — through the same lifecycle automation that manages the rest of the enclave.

Authentication is the one service where "the network is down" and "the security system failed" are the same sentence. The interconnect layer is engineered so you never have to say either.