Cloud Networking Services: Connectivity and Architecture Options

Cloud networking services define how computing resources, applications, and users connect across provider-managed infrastructure — spanning public cloud platforms, private environments, and hybrid architectures. This page covers the major connectivity models, architectural patterns, underlying mechanics, classification boundaries, and the tradeoffs that determine fit for different organizational contexts. Understanding these distinctions is essential for evaluating provider offerings, compliance obligations, and operational risk across distributed infrastructure.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Checklist or steps
• Reference table or matrix
• References

Definition and scope

Cloud networking services encompass the set of virtualized and managed capabilities that enable data transmission, routing, security enforcement, and access control within and between cloud environments. The scope extends beyond simple internet connectivity: it includes virtual private clouds (VPCs), dedicated interconnects, software-defined wide area networks, DNS management, content delivery, load balancing, and network security functions delivered as managed services.

The National Institute of Standards and Technology (NIST SP 800-145) defines cloud computing's essential characteristics as including broad network access — meaning the network layer is not incidental to cloud services but foundational to them. Any resource accessible via cloud computing depends on a networking architecture that governs latency, throughput, isolation, and availability.

The functional boundary of cloud networking services includes both the underlay (physical transport, fiber, and provider backbone) and the overlay (virtual networks, tunnels, and software-defined policies). For a broader map of where cloud networking fits among other categories, the networking services types overview provides a taxonomy of the full services landscape.

Core mechanics or structure

Cloud networking operates through a layered architecture that abstracts physical hardware into programmable, policy-driven constructs.

Virtual Private Cloud (VPC): A VPC is an isolated, logically segmented network within a public cloud provider's infrastructure. Subnets within a VPC are assigned CIDR blocks, and traffic between subnets is governed by route tables and security groups. The Internet Engineering Task Force (IETF) RFC 4364 defines the BGP/MPLS IP Virtual Private Networks model that underpins many cloud VPC implementations.

Virtual Network Functions (VNFs): Traditional hardware appliances — firewalls, routers, load balancers — are instantiated as software running on virtualized infrastructure. The European Telecommunications Standards Institute (ETSI) Network Functions Virtualisation framework (ETSI GS NFV 002) establishes the reference architecture for VNF deployment, distinguishing the NFV infrastructure layer, the VNF layer, and the management and orchestration layer.

Software-Defined Networking (SDN): SDN decouples the control plane from the data plane. The control plane, which makes routing decisions, runs on a centralized controller or distributed controller cluster; the data plane, which forwards packets, executes those decisions across switches and routers. The Open Networking Foundation (ONF) publishes SDN architecture specifications defining this separation. Detailed coverage of SD-WAN as a specific deployment pattern is available at SD-WAN services.

Cloud Interconnect: Dedicated private circuits bypass the public internet entirely. AWS Direct Connect, for example, uses 1 Gbps or 10 Gbps hosted connections; Microsoft Azure ExpressRoute supports circuits up to 100 Gbps. Physically, these terminate at colocation facilities where the provider maintains a presence.

Overlay Networking: Protocols such as VXLAN (RFC 7348) encapsulate Layer 2 frames within UDP datagrams, extending virtual Layer 2 segments across a Layer 3 underlay — critical for workload mobility and multi-tenant isolation.

Causal relationships or drivers

Three structural forces drive adoption of cloud networking architectures.

Workload distribution: Enterprise application stacks are no longer colocated in a single data center. A 2023 Flexera State of the Cloud report found that 87% of surveyed enterprises use a multicloud strategy. Distributed workloads require networking fabrics that can span provider boundaries without static hardware re-provisioning.

Regulatory segmentation requirements: Frameworks including NIST SP 800-53 (Rev. 5, §SC-7) mandate boundary protection and network segmentation controls. Organizations subject to HIPAA, FedRAMP, or PCI DSS must architect cloud networks to enforce logical isolation between regulated and unregulated environments — a requirement that shapes VPC design, transit gateway topologies, and private interconnect decisions.

Latency economics: Round-trip latency across a public internet path from a US East Coast data center to a West Coast application tier averages 60–80 ms under normal conditions. Dedicated cloud interconnects reduce that to deterministic sub-20 ms paths by avoiding internet exchange congestion. Applications requiring real-time processing — financial trading systems, surgical robotics telemetry, industrial control — depend on this determinism.

Network infrastructure services covers how physical layer investments interact with cloud overlay capabilities.

Classification boundaries

Cloud networking services are classified along three orthogonal axes:

By deployment model:
- Public cloud networking — fully provider-managed; tenant configures via APIs, no physical access to hardware.
- Private cloud networking — dedicated infrastructure, either on-premises (e.g., VMware vSphere with NSX) or hosted; tenant controls the physical layer.
- Hybrid cloud networking — interconnects between on-premises and public cloud; requires consistent policy enforcement across both domains.
- Multicloud networking — spans two or more distinct public cloud providers; requires abstraction layer (e.g., Aviatrix, Cisco Cloud ACI) or provider-native transit architectures. See multicloud networking services for detailed treatment.

By functional layer:
- Connectivity services — VPNs, dedicated interconnects, SD-WAN overlays.
- Security services — cloud firewalls, WAFs, DDoS mitigation, zero trust network access (ZTNA). Zero trust network services examines ZTNA architecture in depth.
- Delivery services — content delivery networks (CDNs), global load balancers, DNS anycast.
- Observability services — flow logs, network performance monitoring, distributed tracing.

By management model:
- Self-managed — the organization configures and operates all networking controls through provider APIs or consoles.
- Provider-managed — the cloud or managed service provider operates the network layer under an SLA.
- Co-managed — shared responsibility, defined by a formal responsibility matrix.

Tradeoffs and tensions

Performance vs. cost: Dedicated interconnects deliver consistent throughput and latency but carry monthly port fees. A 10 Gbps AWS Direct Connect dedicated connection carries a fixed hourly port charge plus data transfer rates per GB. Internet-based VPN connectivity costs less but introduces variable latency and packet loss during congestion events.

Flexibility vs. complexity: SDN and VNF-based architectures enable programmable network policies and rapid reconfiguration, but they add orchestration overhead. Managing state synchronization across distributed controllers introduces failure modes absent from hardware-based networks.

Vendor lock-in vs. operational simplicity: Using native cloud provider networking (AWS Transit Gateway, Azure Virtual WAN, GCP Network Connectivity Center) simplifies operations but creates architectural dependencies that complicate migration. Overlay abstraction tools reduce lock-in but add latency from additional encapsulation and management plane complexity.

Isolation depth vs. resource efficiency: Dedicated VPCs with no shared infrastructure maximize isolation — meeting requirements in frameworks like FedRAMP High (baseline controls per NIST SP 800-53 Rev. 5) — but consume more addressable IP space and require more routing configuration than shared-network models.

Common misconceptions

Misconception: A VPN to the cloud is equivalent to a dedicated interconnect.
A site-to-site VPN traverses the public internet and is subject to its congestion dynamics. Dedicated interconnects (Direct Connect, ExpressRoute) use provider backbone paths entirely separate from internet routing tables. Performance characteristics, availability SLAs, and security postures differ materially.

Misconception: Cloud provider network controls replace organizational security policy.
NIST SP 800-145 explicitly frames cloud security as a shared responsibility. The provider secures the physical and hypervisor layers; the tenant is responsible for security group rules, network ACLs, traffic encryption in transit, and monitoring. Relying on default security group configurations without explicit policy review has been a documented source of data exposure.

Misconception: Higher bandwidth always resolves latency problems.
Latency and bandwidth are independent variables. A 100 Gbps link with 80 ms round-trip time does not serve a 1 ms latency requirement. Latency is determined by physical distance, routing path length, and queuing delay — not link capacity. Architecture decisions about geographic placement of cloud regions and availability zones directly control achievable latency floors.

Misconception: SD-WAN eliminates the need for dedicated interconnects.
SD-WAN optimizes path selection across available circuits and improves application performance visibility. It does not eliminate physical transport constraints. An SD-WAN policy routing traffic across multiple broadband links still subjects traffic to internet path variability; a dedicated circuit provides a qualitatively different transport guarantee.

Checklist or steps

The following steps describe the structural phases of cloud network architecture evaluation and provisioning:

1. Inventory workload communication patterns — Identify all source-destination pairs, required throughput, latency tolerances, and data classification for each application or service.
2. Map regulatory segmentation requirements — Determine which compliance frameworks apply (HIPAA, PCI DSS, FedRAMP, CMMC) and identify their specific network boundary, encryption, and logging controls.
3. Select deployment model — Choose public, private, hybrid, or multicloud based on data residency, sovereignty, and integration requirements.
4. Design VPC/VNET topology — Define subnet CIDR allocations, availability zone distribution, and route table hierarchy. Account for RFC 1918 address space to avoid overlap with on-premises ranges.
5. Specify connectivity method — Evaluate internet VPN, dedicated interconnect, or SD-WAN overlay for each site-to-cloud and cloud-to-cloud path based on SLA and latency requirements.
6. Define security policy layer — Configure security groups, network ACLs, firewall rules, and DDoS protection tiers. Document the responsibility boundary per provider shared responsibility model.
7. Establish observability baseline — Enable VPC flow logs, DNS query logs, and network performance telemetry. Define retention periods consistent with applicable compliance requirements. Network monitoring services covers tooling categories in this space.
8. Validate failover and redundancy — Test circuit failover, route convergence times, and recovery procedures. Document RTO and RPO for each network path.
9. Document the architecture — Produce logical and physical diagrams referencing actual provider regions, circuit IDs, and policy rule sets.

Reference table or matrix

References

• NIST SP 800-145: The NIST Definition of Cloud Computing
• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations
• ETSI GS NFV 002: Network Functions Virtualisation — Architectural Framework
• Open Networking Foundation (ONF) — SDN Architecture
• IETF RFC 4364: BGP/MPLS IP Virtual Private Networks
• IETF RFC 7348: Virtual eXtensible Local Area Network (VXLAN)
• IETF RFC 4301: Security Architecture for the Internet Protocol (IPsec)
• MEF 3.0: SD-WAN Service Attributes and Services
• FedRAMP Program — Cloud Security Authorization Requirements