Cloud-only networking works until the enterprise shows up.
The moment your network scope includes branches, data centers, SaaS, partners, and multi-cloud traffic, “cloud networking” stops being the problem statement. The problem becomes how to provide enterprise-wide connectivity and consistent policy, delivered with a controlled blast radius.
And this is where the architecture divide becomes obvious.
Cloud-only networking models scale by adding controllers and gateways. Enterprises needing more need a cross-domain operating model that scales without deploying anything.
The real breakpoint is scope
Inside a single cloud domain, most requirements are local:
- Connect workloads
- Standardize constructs
- Automate repetitive changes
- Improve visibility and troubleshooting within cloud boundaries
That approach can be viable because the operating surface area is bounded.
Enterprise scope is different:
- Users and apps are distributed across branches, campuses, data centers, clouds, and SaaS
- Traffic paths cross domains by default
- Segmentation must be consistent across domains, not “best effort” per environment
- Governance and audit evidence must be repeatable everywhere
At enterprise scope, the question is not “How do we configure cloud networking faster?”
It is “How do we deliver connectivity and segmentation across domains without expanding blast radius every time scope changes?”
Blast radius is the cost of change at scale
Blast radius is not a theoretical risk concept. It is the operational surface area touched by a change.
It shows up as:
- How many systems you must touch to implement the change
- How many enforcement points must be updated and validated
- How many teams must coordinate to execute safely
- How many failure modes you introduce into the traffic path
- How long it takes to troubleshoot when something goes sideways
Small blast radius enables speed with confidence.
Large blast radius forces slowdowns, process, exceptions, and drift.
Cloud-only networking expands blast radius by design
Cloud-only networking platforms commonly rely on a controller layer and distributed gateways to deliver connectivity and policy across cloud environments.
That architectural choice has an operational consequence:
When scope grows, topology grows.
You feel it immediately in day-2:
- More gateways to deploy, scale, and keep highly available
- More lifecycle work: upgrades, compatibility checks, certificates, monitoring, and incident response
- More distributed troubleshooting across more components
- More policy translation work as you cross domains that do not share the same primitives
This is not a knock on engineering quality. It is the predictable tax of “you deploy it” networking at enterprise scale.
Enterprise-wide connectivity via a -aaS operating model removes “deploy and manage it” complexity
A cross-domain operating model is not a set of per-domain builds. It is a single operating model for delivering enterprise-wide connectivity. It is defined by two outcomes:
- New scope does not require new infrastructure.
- Segmentation stays consistent across domains from one operating model.
In practice, that means:
- One onboarding workflow for clouds, regions, branches, and partners
- One segmentation approach that remains consistent as traffic crosses domains
- A controlled blast radius, because scaling coverage does not mean scaling components
At enterprise scale, operational surface area becomes a risk factor. As scope expands, more components increase the likelihood of drift, misconfiguration, and longer recovery during change. The right model limits what you have to operate as coverage grows.
Where cloud-only breaks first
The failure mode is not “multi-cloud is hard.” The failure mode is that scope expansion forces architecture expansion. Here are the places where the boundary becomes non-negotiable.
1) Branches and campuses
As soon as you include branches, the network stops being cloud-local. Now you are operating end-to-end connectivity, segmentation, and troubleshooting across WAN, internet, and cloud. If your model requires adding gateways to extend scope, you expand blast radius before you deliver the business outcome.
2) Data centers and colocation
Hybrid dependencies do not disappear on a migration plan. Identity, shared services, databases, and legacy apps keep traffic crossing domains. A cloud-only model turns this into a growing web of attachments, policies, and exceptions. A cross-domain operating model treats data centers and colos as a first-class domain in the same enterprise-wide connectivity workflow, with consistent segmentation and governance.
3) SaaS and internet egress
SaaS is where policy consistency becomes a board-level issue. Egress, inspection, and segmentation must be consistent and auditable. Cloud-only models tend to fragment enforcement because different domains end up using different constructs and tools. Fragmentation becomes drift. Drift becomes audit work.
4) Partner connectivity
Partners multiply faster than internal environments. If every partner onboarding requires new components, new paths, and special-case policy handling, the model does not scale. As scope grows to be enterprise-wide, the infrastructure and fabric that is needed requires repeatable onboarding and repeatable segmentation boundaries.
5) Multi-cloud traffic patterns
Cross-cloud traffic breaks cloud-local assumptions. Paths cross domains, segmentation must remain consistent, and troubleshooting becomes multi-team by default. This is where controller-and-gateway architectures most visibly become a topology problem.
6) AI infrastructure and AI-driven traffic patterns
AI introduces new traffic patterns and new operational expectations. Data pipelines, shared model services, vector databases, and distributed inference endpoints increase east-west traffic across clouds and sites, and they raise the bar for consistency in segmentation and inspection. If extending AI environments requires deploying additional gateways or stitching together new policy translations per domain, blast radius increases quickly.
Even when cloud-only models “support” broader scope, the operating burden remains
Cloud-only networking platforms can and often do extend to cover broader enterprise scope over time. The issue is not whether they can connect branches, data centers, SaaS, partners, multi-cloud paths, or AI environments.
The issue is the delivery model.
When the foundation depends on customer-deployed controllers and gateways, expanding scope typically means:
- More components to deploy and keep highly available as new environments, regions, and connectivity patterns are added.
- More lifecycle management (sizing, upgrades, patching, certificate rotation, monitoring, and incident response) across a growing footprint.
- More distributed troubleshooting, because connectivity and policy enforcement are now spread across more nodes and paths.
- More change coordination, since “simple” updates increasingly touch multiple gateways, attachments, and policy translations.
As a result, capability expansion does not eliminate complexity. It increases operational surface area. At enterprise scope, that becomes a primary constraint alongside policy consistency and blast radius.
The challenge of being consistent across domains
At enterprise scope, segmentation intent must be implemented consistently across domains with different primitives and different operational owners. When enforcement varies by environment, it drives:
- Exceptions that accumulate over time
- Divergence between environments
- Inconsistent enforcement
- Higher audit burden
- Higher incident risk during change
You can automate configuration steps, but you cannot achieve durable consistency when the operating model remains domain-bound.
What to validate in a proof of concept
A serious POC should not be a feature demo. It should be a blast radius test.
Validate:
- Time to onboard a new environment without deploying customer-managed infrastructure
- Steps required to connect a new scope boundary (new region, new branch, new partner)
- Number of operational components that expand as scope grows
- Time to apply segmentation consistently across domains
- Troubleshooting workflow across domains (time to isolate path versus policy)
- Ability to produce audit evidence without manual reconciliation
If the POC “wins” only by building more topology, it is not winning. It is borrowing from your future operating budget.
Takeaway
Cloud-only networking is a bounded-scope model. It can fit when requirements stay cloud-local, but it typically depends on controllers and gateways that you must deploy, operate, and lifecycle-manage.
As scope expands across branches, data centers, SaaS, partners, multiple clouds, and AI-driven traffic patterns, a cross-domain operating model becomes necessary. At that point, consistent segmentation and governance across domains drive the requirement, and blast radius becomes the constraint.
If your model scales by adding controllers and gateways, operational surface area grows with every new environment.
A cross-domain operating model delivers enterprise-wide connectivity at scale by standardizing delivery across domains and extending coverage without requiring additional customer-deployed infrastructure.
How Alkira Can Help
Whether you are cloud-first today or planning for broader enterprise-wide scope over time, Alkira provides a cloud-delivered operating model for enterprises that enable hyper-agility as requirements evolve:
- Supports cloud-only requirements now, while extending cleanly to branches, data centers, SaaS, and partners as scope expands.
- No customer-deployed controllers or gateways required to stand up and operate the platform, reducing lifecycle overhead.
- Unified connectivity and segmentation workflows across domains to prevent policy drift as environments multiply.
- Repeatable onboarding for new regions, sites, and partners with consistent governance and faster time-to-service.
- Day-2 operational consistency with standardized change and troubleshooting workflows that scale with the organization.
FAQs
Calvin Nguyen
