Cloud Networking and Connectivity

Introduction

Cloud computing is fundamentally a networking discipline. Compute instances, containers, databases, storage services, users, and external systems communicate through logical networks that must be designed for performance, security, resilience, and cost control. A poorly designed network can make an otherwise well-engineered cloud application unreliable, insecure, difficult to operate, or unnecessarily expensive.

Cloud networking differs from traditional data-centre networking in several important ways. Physical infrastructure is abstracted behind software-defined constructs; network capacity is often elastic; routing and security policies are expressed through APIs; and services may be distributed across regions, availability zones, edge locations, and multiple providers. These advantages require disciplined design. The architect must understand addressing, segmentation, routing, name resolution, traffic inspection, private service access, hybrid connectivity, and the economic effects of data transfer.

This chapter presents a provider-neutral framework. Individual platforms use different names—for example, virtual networks, virtual private clouds, route tables, security groups, network security groups, private links, or transit gateways—but the underlying architectural principles are broadly similar.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Design virtual networks, address spaces, subnets, and routing domains.
2. Explain DNS resolution, load balancing, gateways, firewalls, and private endpoints.
3. Select suitable methods for internet, hybrid, multi-cloud, and branch connectivity.
4. Apply segmentation and zero-trust principles to cloud networks.
5. Evaluate latency, availability, throughput, operational complexity, and egress cost.
6. Develop a secure and resilient network architecture for a realistic workload.

1. The Cloud Network as a Layered System

A useful model separates cloud networking into five interacting layers:

A packet’s successful journey normally requires all five layers to be correct. For example, a web request may be resolved by DNS, directed to a CDN, forwarded to a regional load balancer, routed to an application subnet, permitted by a firewall policy, and recorded in flow logs. Failure at any stage may appear to an application developer simply as a timeout.

1.1 Control plane and data plane

The control plane creates and changes network resources: routes, interfaces, gateways, firewall policies, and DNS records. The data plane forwards actual packets according to those configurations. A control-plane API may be unavailable while existing data-plane traffic continues, or a successful configuration request may still produce an incorrect data-plane result. This distinction is important during outages and change management.

1.2 Availability domains and failure boundaries

Cloud networks commonly span availability zones within a region. A resilient design avoids treating a single zone, gateway, appliance, or route as indispensable. However, cross-zone traffic may incur latency and data-transfer charges. High availability therefore requires a balanced decision between redundancy and traffic locality rather than indiscriminate distribution.

2. Addressing, CIDR, and Subnet Design

An IP address identifies an interface within an address space. Cloud architects normally allocate private IPv4 ranges using the private blocks defined by RFC 1918: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. IPv6 provides a much larger address space and should be considered where services, users, or regulatory requirements make it valuable.

CIDR notation expresses a network prefix and prefix length, such as 10.20.0.0/16. IPv4 contains 32 bits, so a /16 leaves 16 host bits. The number of addresses in a CIDR block is:

where N is the number of IPv4 addresses and p is the prefix length. This is a binary address count; cloud platforms may reserve several addresses in each subnet, so usable capacity can be lower. For 10.20.0.0/16, N = 2^16 = 65,536 addresses. A /24 contains 256 addresses.

Subnetting divides an address block into smaller prefixes. If a /16 network is divided into /20 networks, the number of equal-sized subnets is:

where p₁ is the original prefix length and p₂ is the new prefix length. Thus, 2^(20−16) = 16 subnets are created. The formula assumes binary equal-sized subdivision and does not account for platform reservations.

2.1 Principles of address planning

A professional address plan should:

• avoid overlap with on-premises, partner, and other cloud networks;
• reserve space for growth, additional environments, and acquisitions;
• distinguish production, testing, development, and shared services;
• support route summarisation where practical;
• document ownership and intended use of every major prefix;
• consider IPv6 dual-stack requirements rather than treating IPv6 as an afterthought.

Overlapping CIDR ranges complicate VPN routing, peering, migration, and incident response. Renumbering after deployment is expensive; address planning is therefore an architectural activity, not a minor implementation detail.

2.2 Public and private subnets

A subnet is often called public when its route table provides a path to an internet gateway and its resources can receive public addresses. A private subnet normally has no direct inbound path from the internet. A private subnet may still make outbound internet connections through a network address translation (NAT) gateway or proxy.

The terms are conceptual rather than universal. A subnet is not secure merely because it is labelled private. Security depends on routes, firewall rules, identity, application behaviour, and the presence or absence of public addresses.

3. Routing and Traffic Engineering

Routing determines the next hop for a destination. Cloud route tables commonly use longest-prefix matching: when multiple routes match a destination, the most specific prefix is preferred. For example, a route for 10.20.4.0/24 takes precedence over a broader route for 10.20.0.0/16 for addresses within 10.20.4.0/24.

A typical route table may contain:

• a local route for resources in the same virtual network;
• a default route, such as 0.0.0.0/0, to an internet gateway, NAT gateway, firewall, or VPN;
• specific routes to on-premises networks through a virtual private gateway or transit hub;
• routes to shared services through peering or a service-insertion appliance.

3.1 Static and dynamic routing

Static routes are predictable and simple, but changes must be configured manually or through automation. Dynamic routing protocols such as BGP exchange reachability information and can support automatic failover, path selection, and route advertisement. BGP does not make a network secure by itself; it determines reachability, while security policies determine permission.

Route propagation must be controlled. Advertising overly broad prefixes can attract unintended traffic, create asymmetric paths, or expose networks. Route filters, maximum-prefix limits, and documented ownership reduce these risks.

3.2 Asymmetric routing

Asymmetric routing occurs when the forward and return paths differ. It may be acceptable for stateless routing, but stateful firewalls often expect both directions of a flow to pass through the same inspection point. Introducing firewalls, NAT, load balancers, or multiple transit paths can therefore create failures that are not visible in a simple connectivity test.

3.3 Transit architectures

A small environment may use virtual-network peering. Peering offers direct connectivity but commonly does not provide transitive routing: network A may communicate with B and B with C without A automatically reaching C. A transit gateway or hub-and-spoke architecture centralises connectivity and policy, although it introduces dependency on the hub and may add processing and transfer costs.

A full-mesh design can provide direct paths but becomes difficult to manage as the number of networks increases. The number of undirected pairwise connections in a full mesh of n networks is:

This is a topology count, not a performance formula. Ten networks require 45 pairwise links in a full mesh, illustrating why transit designs are often preferred as environments grow.

4. DNS and Service Discovery

The Domain Name System maps names to records such as A, AAAA, CNAME, MX, and TXT. In cloud architectures, DNS is more than a convenience: it is a control mechanism for service discovery, failover, traffic steering, and abstraction from changing addresses.

A robust design separates:

• public DNS, which answers for internet clients;
• private DNS, which answers for internal clients and private service names;
• authoritative zones, which hold the definitive records;
• recursive resolvers, which obtain answers on behalf of clients.

Split-horizon DNS uses different answers for the same name depending on the requester’s network. For example, app.example.com may resolve to a private load balancer internally and a public CDN externally. Care is required to prevent inconsistent records and difficult troubleshooting.

DNS records have a time-to-live (TTL). A low TTL can accelerate changes but increases query volume and dependency on DNS availability. A high TTL reduces query traffic but slows failover and migration. DNS-based failover is not instantaneous: cached responses remain valid until their TTL expires, and some clients cache longer than specified.

Private hosted zones and cloud-native service discovery are valuable for internal applications. Names should reflect stable service identities rather than individual instances. Applications should also tolerate address changes because autoscaling, failover, and deployment frequently alter endpoints.

5. Load Balancing and Content Delivery

A load balancer distributes requests across healthy backends. Common types include:

• Layer 4 load balancers, which operate on TCP or UDP and preserve high throughput with limited application awareness;
• Layer 7 load balancers, which understand HTTP or HTTPS and can route using hostnames, paths, headers, cookies, or content;
• global load balancers, which select a region or endpoint using health, policy, geography, or latency;
• internal load balancers, which expose services only to private clients.

Health checks should test meaningful service readiness rather than merely process existence. A server that accepts TCP connections but cannot reach its database should not receive production traffic. Session persistence, connection draining, proxy protocol, client-IP preservation, and TLS termination must be explicit design decisions.

A content delivery network (CDN) caches content at edge locations close to users. It reduces origin requests and can improve latency for cacheable content. Cache-control headers, invalidation strategy, encryption, and protection against cache poisoning are essential. Dynamic, personalised, or rapidly changing content may obtain less benefit and may require careful cache-key design.

Latency is influenced by propagation distance, routing, queuing, encryption, processing, and application behaviour. Geographic proximity alone does not guarantee the lowest latency. Architects should measure round-trip time, tail latency, packet loss, and application response time from representative user locations.

6. Firewalls, Security Groups, and Segmentation

Cloud security uses several control types:

A stateful rule permits return traffic automatically for an established flow. A stateless rule requires explicit treatment of both directions, including ephemeral ports. The exact behaviour varies by provider and product; documentation must be consulted before implementation.

Segmentation limits blast radius. Useful boundaries include environment, application tier, data sensitivity, administrative function, and tenant. A common three-tier design separates public-facing load balancers, application services, and databases. Segmentation should be based on required communication flows, not simply on subnet labels.

Zero trust complements segmentation. It assumes that network location alone does not establish trust. Access should be authenticated, authorised, encrypted where appropriate, logged, and continuously evaluated. Micro-segmentation can enforce workload-level policies, but excessive rules increase operational complexity and may encourage unsafe exceptions.

Egress deserves special attention. Outbound traffic can expose sensitive data and create substantial cost. Approved egress gateways, domain filtering, private service endpoints, data-loss prevention, and central logging can reduce risk. NAT gateways solve address translation; they do not constitute a complete security strategy.

7. Gateways, Private Endpoints, and Service Access

An internet gateway connects a virtual network to the public internet. A NAT gateway permits outbound connections from private resources without accepting unsolicited inbound connections. A VPN gateway terminates encrypted tunnels, while a transit gateway or virtual hub connects multiple networks.

Private endpoints provide private access to managed services without traversing the public internet. Common implementation patterns include interface endpoints using private network interfaces and provider-specific endpoint services. They improve exposure control and may reduce data-transfer paths, but they can incur hourly and per-processed-data charges. DNS must be configured so that the service name resolves to the private endpoint for internal clients.

Private access is not automatically cheaper. The architecture should compare endpoint charges, NAT processing charges, cross-zone transfer, and the cost of central inspection. It should also consider availability: endpoint interfaces may need to be deployed across zones, and service quotas may constrain scale.

8. Hybrid Connectivity and SD-WAN

Hybrid connectivity links cloud resources with corporate data centres, branches, factories, or partner networks.

Site-to-site VPN uses encrypted tunnels over the public internet. It is comparatively quick and inexpensive, but performance depends on internet conditions and tunnel capacity. Redundant tunnels and dynamic routing improve resilience.

Dedicated connectivity uses a provider or carrier circuit. It generally provides more predictable performance and avoids some internet-path uncertainty, but provisioning takes longer and does not eliminate the need for encryption in all situations. A backup VPN is commonly appropriate.

SD-WAN creates an overlay that applies central policy to multiple underlay connections, such as broadband, private circuits, and cellular links. It can select paths based on latency, loss, jitter, application identity, and business priority. SD-WAN is not a substitute for correct cloud route design; it adds an orchestration and policy layer over connectivity.

A hybrid design should document address ownership, route advertisement, encryption, failure detection, MTU, DNS forwarding, and operational responsibility. Maximum transmission unit (MTU) problems are frequent when tunnels add encapsulation overhead. Symptoms include selective failures, especially for large packets, while small-packet tests appear successful.

9. Latency, Throughput, Availability, and Cost

Network design is a multi-objective optimisation problem. Improving one property may worsen another. Central inspection can improve governance but add latency and a failure dependency. Cross-zone redundancy improves availability but may increase transfer cost. A CDN reduces user latency but introduces cache invalidation and edge-security considerations.

For a simple serial path with independent component availability, an approximate availability is:

where Aᵢ is the availability of component i. This assumes components are in series, failures are independent, and the availability values represent the same measurement period. Real cloud dependencies may share failure domains, so independence is often an optimistic assumption.

For two independent components arranged in active-active parallel, approximate availability is:

This assumes either component can serve the complete required workload and that failover is effective. Capacity loss, correlated failures, configuration errors, and shared dependencies can make actual availability lower.

Cost analysis should identify:

• internet egress and inter-region transfer;
• cross-zone transfer;
• NAT gateway processing;
• firewall and inspection processing;
• VPN or dedicated-circuit charges;
• load balancer hours and processed bytes;
• CDN requests, transfer, and invalidation;
• private endpoint hours and processed bytes.

A useful practice is to model traffic volume by source, destination, direction, region, and security path. Egress cost is not merely a finance concern: application placement, replication strategy, caching, compression, and data architecture determine it.

10. Reference Architecture

The following conceptual architecture illustrates a common secure pattern.

Figure: A conceptual secure cloud network separating edge access, application services, data services, private endpoints, and hybrid connectivity.

In this pattern, users reach an edge service and controlled public entry point. Application workloads remain in private subnets, databases have no direct public route, and managed services are accessed through private endpoints. Hybrid traffic terminates through a controlled VPN or transit function. In production, each critical component should be deployed across suitable failure domains, with explicit route tables, health checks, logging, and policy ownership.

11. Illustrative Case: Regional Retail Platform

Background

A fictional retailer operates an online store, a warehouse system in a private data centre, and analytics workloads in the cloud. Customers are distributed across two continents. The existing design places web servers and databases in one cloud network, uses public database addresses for administration, and sends all traffic through a single VPN tunnel.

Problem

The retailer experiences slow customer responses during campaigns, database exposure concerns, intermittent warehouse disconnections, and unexpectedly high outbound transfer charges. The architecture also lacks a documented failover process.

Analysis

The principal issues are insufficient segmentation, a single hybrid failure path, excessive origin traffic, and poor traffic locality. Public database addressing increases attack surface. A single VPN tunnel creates both a capacity bottleneck and a single point of failure. Serving static assets from the origin across continents increases latency and egress.

Approach and solution

The redesigned architecture uses:

1. Separate virtual networks or subnets for edge, application, data, shared services, and management functions.
2. A CDN for static assets and carefully selected cacheable responses.
3. A layer 7 load balancer with health-based routing to application instances in multiple zones.
4. Private database addresses and workload-level security policies allowing only required application flows.
5. Private endpoints for selected managed services, with private DNS records.
6. Two VPN tunnels terminating on redundant gateways, with dynamic routing and a dedicated circuit as a later improvement.
7. Centralised firewall inspection for approved egress and inter-network flows, while avoiding unnecessary hairpinning.
8. Flow logs, DNS query logs, load-balancer metrics, synthetic probes, and cost dashboards.
9. Traffic placement that keeps application-to-database communication within the same region and minimises cross-zone transfers where resilience permits.

Outcome

The design removes public database exposure, improves resilience, and reduces origin requests. It does not guarantee a particular performance or cost result; those must be validated through load tests, measurements from customer locations, and billing analysis. The most important improvement is architectural visibility: each communication path has an owner, route, security rule, monitoring signal, and cost category.

Learning points

• Security, performance, availability, and cost are coupled decisions.
• Redundancy must include routing, gateways, DNS, and operational procedures.
• Private connectivity requires correct DNS as well as correct routes.
• A measured traffic model is more reliable than assumptions about “cheap” or “fast” designs.

12. Governance, Operations, and Contemporary Practice

Network governance should define naming, address allocation, approved regions, route ownership, firewall policy review, logging retention, emergency access, and change approval. Infrastructure-as-code allows network configuration to be reviewed, tested, versioned, and reproduced. Policy-as-code can prevent public database interfaces, unrestricted inbound rules, or unapproved CIDR ranges.

Observability should correlate DNS resolution, flow logs, load-balancer access logs, firewall decisions, application traces, and billing data. Useful operational questions include: Was the name resolved? Which route was selected? Which security rule applied? Did the packet return through the same path? Was the request rejected at the edge, gateway, firewall, or application?

Automation and AI-assisted operations can identify anomalous flows, suggest security rules, detect route drift, and forecast egress cost. Such systems should not autonomously apply high-impact network changes without testing, approval boundaries, rollback, and human accountability. Training data and logs may contain sensitive addresses, identities, or traffic metadata.

Regulatory requirements may govern data residency, encryption, retention, lawful access, and separation of tenants. Network location does not by itself prove compliance. Evidence should include configuration state, access records, encryption settings, monitoring, incident procedures, and periodic control testing.

Challenges and Limitations

Cloud networking abstracts physical infrastructure but does not eliminate physical constraints. Provider quotas, address exhaustion, route limits, MTU restrictions, service-specific behaviour, and regional outages remain relevant. Managed services can simplify operation while reducing low-level control. Central firewalls improve visibility but may create bottlenecks, cost, and correlated failure. Multi-cloud connectivity increases bargaining flexibility and resilience in selected cases, but it also multiplies identity, DNS, routing, monitoring, and skills requirements.

The safest design is not the one with the most components. It is the one whose traffic flows, trust boundaries, failure modes, costs, and operational responsibilities are understood and tested.

Best-Practice Checklist

• Allocate non-overlapping address space before deployment.
• Separate environments, tiers, and sensitive workloads.
• Prefer private addressing for internal services and databases.
• Use least-privilege, state-aware security policies and review them regularly.
• Design redundant gateways, routes, DNS paths, and hybrid links.
• Validate DNS, MTU, asymmetric routing, and failover—not only reachability.
• Keep traffic local when appropriate, but do not sacrifice required resilience.
• Measure latency, loss, throughput, tail response time, and egress cost.
• Use infrastructure-as-code, policy-as-code, logging, and controlled change processes.
• Test recovery and document ownership for every network dependency.

Chapter Summary

Cloud networking provides the logical foundation for secure and reliable distributed systems. Effective design begins with non-overlapping address spaces, purposeful subnet boundaries, explicit routing, and clear failure domains. DNS provides service identity and traffic control; load balancers distribute healthy workloads; CDNs move suitable content closer to users. Firewalls, security groups, private endpoints, and zero-trust policies reduce exposure and constrain lateral movement.

Hybrid connectivity may use VPN, dedicated circuits, transit architectures, or SD-WAN, each with different trade-offs in performance, cost, control, and complexity. Network decisions must account for latency, availability, asymmetric routing, MTU, quotas, and egress charges. Governance, observability, infrastructure-as-code, and tested recovery procedures turn a technically possible network into an operable professional platform.

Key Terms

CIDR: A notation that represents an IP network prefix and prefix length.

Subnet: A logical division of an IP address space.

Route table: A set of destination-prefix and next-hop decisions.

Longest-prefix matching: Selecting the most specific matching route.

BGP: A routing protocol used to exchange reachability information between networks.

Virtual network: An isolated logical cloud network containing subnets and interfaces.

NAT gateway: A service that translates private outbound addresses for external communication.

Security group: A commonly stateful, workload-associated traffic control.

Network ACL: A subnet-level traffic control, often stateless.

Zero trust: A security approach that grants no implicit trust based solely on network location.

Private endpoint: A private interface or service connection for accessing a managed service.

DNS: The distributed naming system that maps domain names to network records.

TTL: The period for which a DNS response may be cached.

Load balancer: A service that distributes traffic among backend endpoints.

CDN: A distributed edge system that caches and serves content near users.

SD-WAN: A policy-driven overlay that manages traffic across multiple network underlays.

Egress: Data leaving a cloud service, often subject to transfer charges.

MTU: The maximum packet size transmitted over a network link without fragmentation.

Transit gateway: A central routing function connecting multiple networks.

Flow log: A record describing observed network-flow metadata, usually without full packet content.

Review Questions

Short Answer Questions

1. What is the difference between a public and a private subnet?
2. Why is non-overlapping address space important in hybrid cloud design?
3. Distinguish a layer 4 load balancer from a layer 7 load balancer.
4. What problem does a private endpoint solve?
5. Why can low DNS TTL values increase operational cost or load?

Long Answer Questions

1. Explain how CIDR planning, subnetting, route tables, and security policies work together in a multi-tier cloud application.
2. Compare VPN, dedicated connectivity, and SD-WAN for a business connecting branches to cloud workloads.
3. Discuss the availability and cost trade-offs of centralised firewall inspection.
4. Explain how DNS, load balancing, and CDN services can be combined to improve global application delivery.
5. Develop a zero-trust segmentation strategy for web, application, database, and management tiers.

Analytical / Application Questions

1. A company has eight virtual networks and is considering a full-mesh peering design. Calculate the number of pairwise links and recommend an alternative architecture, explaining the trade-offs.
2. A hybrid application has intermittent failures for large packets but succeeds with small-packet tests. Analyse the likely network causes and propose a diagnostic sequence.
3. Design a connectivity and cost-control strategy for a globally distributed application whose users need low latency but whose database must remain in one regulated region.

Multiple Choice Questions with Answers

Question 1

A /16 IPv4 network is divided into /20 subnets. How many equal-sized subnets are created?

A. 4

B. 8

C. 16

D. 32

Correct Answer: C. 16

Question 2

When two routes match a destination, which route is normally preferred?

A. The route with the least specific prefix

B. The route with the longest, most specific prefix

C. The route created most recently

D. The route with the largest next-hop address

Correct Answer: B. The route with the longest, most specific prefix

Question 3

Which service is primarily intended to provide private access to a managed cloud service without using a public endpoint?

A. Private endpoint

B. Internet gateway

C. Public DNS zone

D. CDN invalidation

Correct Answer: A. Private endpoint

Question 4

What is a principal advantage of a CDN?

A. It eliminates the need for origin servers

B. It caches suitable content closer to users

C. It automatically encrypts every database

D. It replaces all cloud route tables

Correct Answer: B. It caches suitable content closer to users

Question 5

Which statement best describes BGP in a hybrid architecture?

A. It encrypts all application data

B. It exchanges reachability information between networks

C. It caches DNS records at the edge

D. It performs HTTP content inspection

Correct Answer: B. It exchanges reachability information between networks

Question 6

A full mesh of 10 networks requires how many undirected pairwise links?

A. 10

B. 20

C. 45

D. 100

Correct Answer: C. 45

Question 7

Which control is generally most associated with HTTP-aware filtering?

A. Web application firewall

B. NAT gateway

C. Route table

D. BGP session

Correct Answer: A. Web application firewall

Question 8

What is a major risk of overlapping private CIDR ranges in hybrid connectivity?

A. Higher DNS TTL values

B. Ambiguous or impossible routing between networks

C. Automatic CDN cache invalidation

D. Improved route summarisation

Correct Answer: B. Ambiguous or impossible routing between networks

Question 9

For two independent active-active components with availabilities A₁ and A₂, which expression represents approximate combined availability?

A. A₁ × A₂

B. A₁ + A₂

C. 1 − (1 − A₁)(1 − A₂)

D. 1 − A₁A₂

Correct Answer: C. 1 − (1 − A₁)(1 − A₂)

Question 10

Why should a private endpoint normally be accompanied by appropriate private DNS configuration?

A. To ensure the service name resolves to the private address

B. To increase public internet exposure

C. To disable route tables

D. To force all traffic through a CDN

Correct Answer: A. To ensure the service name resolves to the private address