Cloud Networking and Connectivity

Introduction

Cloud computing depends on networking. Compute instances, databases, containers, storage services, users, administrators, and external systems communicate through logical networks implemented in software. A well-designed cloud network provides connectivity, segmentation, security, resilience, predictable performance, and controlled access to services. A poorly designed network can expose sensitive data, create bottlenecks, increase operational cost, or make recovery difficult.

This chapter explains the principal components used to design cloud networks: virtual networks, subnets, addressing, routing, gateways, load balancers, DNS, content delivery networks, firewalls, private endpoints, VPNs, and hybrid connectivity. The terminology differs slightly among cloud providers, but the underlying principles are broadly transferable.

Learning Objectives

After studying this chapter, you should be able to:

1. Design a virtual network using appropriate address ranges and subnet boundaries.
2. Explain routing, gateways, and the flow of packets through cloud environments.
3. Select suitable load-balancing, DNS, CDN, and firewall services.
4. Distinguish public access, private access, private endpoints, VPNs, and dedicated hybrid links.
5. Apply security, availability, governance, and operational principles to a cloud connectivity design.
6. Evaluate a practical cloud networking architecture and identify its limitations.

1. The Cloud Networking Model

A traditional network is built from physical switches, routers, firewalls, cables, and dedicated circuits. A cloud network is a software-defined construct. The provider operates the physical infrastructure, while the customer defines logical resources through a console, command-line interface, or application programming interface.

Common provider terms include virtual network, virtual private cloud, virtual network, subnet, route table, security group, network security group, internet gateway, NAT gateway, transit gateway, private link, and peering. These names are not identical across providers, but they usually describe similar functions.

A useful conceptual model has four layers:

Cloud networking is usually governed by a shared-responsibility model. The provider secures the physical network, virtualization layer, and core service infrastructure. The customer remains responsible for address planning, access policies, routing configuration, encryption choices, workload exposure, logging, and often the security of virtual appliances.

2. Virtual Networks and Subnets

A virtual network is an isolated logical network allocated to a customer account or project. It normally has a customer-selected address space, one or more subnets, route tables, and security controls. Isolation is logical rather than physical: the provider uses virtualization and software-defined networking to separate customers.

A subnet is a range of IP addresses within a larger network. Subnets are commonly associated with an availability zone or fault domain. A public subnet is one whose routing permits access through an internet gateway, although a route alone does not make a workload secure or publicly reachable. A private subnet normally has no direct inbound route from the internet. It may still reach the internet through a network address translation (NAT) gateway for software updates or external APIs.

Subnet design should reflect function and trust boundary. For example, a three-tier application may use:

• Public subnets for internet-facing load balancers.
• Application subnets for web and API servers.
• Database subnets with no direct internet route.
• Management subnets for controlled administrative services.
• Dedicated subnets for private endpoints or network appliances where required by the provider.

Subnets are not a complete security boundary. Traffic can sometimes move between subnets through routing, peering, transit services, or firewalls. Security must therefore be enforced by multiple controls, including workload identity, security groups, network ACLs, host firewalls, and application authorization.

CIDR Addressing

Cloud networks commonly use Classless Inter-Domain Routing (CIDR). A prefix such as 10.20.0.0/16 identifies a network with 16 network bits and 16 host bits in IPv4. The number of addresses in an IPv4 prefix is:

where N is the total number of addresses and p is the prefix length. This formula assumes IPv4 and counts all addresses, including addresses that a provider may reserve. The number of usable addresses is therefore provider-dependent.

For example, a /24 network contains:

addresses. If it is divided into four equal /26 subnets, each subnet contains 64 addresses because 26 bits identify the network and 6 bits remain for addresses.

A practical address plan must account for growth, multiple environments, overlapping networks, provider reservations, future mergers, disaster recovery, and on-premises connectivity. Private IPv4 ranges defined by RFC 1918 include 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Organizations should avoid arbitrary reuse when networks may later be connected, because overlapping ranges complicate routing and often require address translation.

IPv6 uses 128-bit addresses. A common subnet size is /64, but the exact allocation should follow provider and organizational standards. IPv6 can reduce address scarcity, but it does not remove the need for segmentation, filtering, monitoring, or careful route design.

Worked Example: Address Planning

An organization allocates 10.40.0.0/16 to a production virtual network. It requires six application subnets, each supporting up to 200 workload addresses, and wants equal-sized subnets.

A /24 provides 256 total addresses and is the smallest conventional subnet size that exceeds 200 before provider reservations. Six /24 subnets consume 6 × 256 = 1,536 addresses. The /16 contains 65,536 total addresses, so substantial space remains for database, management, endpoint, and future subnets. A possible allocation is 10.40.1.0/24 through 10.40.6.0/24 for application subnets, with larger or separately reserved ranges for databases and shared services.

The result is technically adequate, but the designer must verify provider-specific reserved addresses and avoid allocating the entire address space without a growth plan.

3. Routing and Gateways

Routing determines the next hop for a packet. A route normally contains a destination prefix and a target, such as a local network, internet gateway, NAT gateway, VPN gateway, peering connection, or transit gateway. The most specific matching route is generally preferred. This is called longest-prefix matching.

A route table associated with a subnet might contain:

The default route 0.0.0.0/0 matches all IPv4 destinations not matched by a more specific route. A route is not equivalent to permission. A packet may have a valid route and still be blocked by a security group, firewall, network ACL, or destination policy.

An internet gateway provides a path between a virtual network and the public internet, usually with provider-managed translation or public address association. A NAT gateway generally allows resources with private addresses to initiate outbound connections while preventing unsolicited inbound connections. NAT is not a firewall replacement and does not automatically provide application-layer protection.

A virtual private gateway or VPN gateway terminates encrypted tunnels. A transit gateway or virtual WAN hub connects multiple virtual networks and external networks through a central routing service. Centralization simplifies shared connectivity but can create a bottleneck, dependency, or blast radius if designed without redundancy.

Peering provides direct connectivity between selected virtual networks. It commonly has non-transitive behavior: if Network A peers with B and B peers with C, A may not automatically reach C through B. Transit architectures are more suitable when many networks require controlled, transitive connectivity.

4. Availability and Resilience

Cloud networks should be designed across multiple availability zones or fault domains. A single NAT gateway, firewall appliance, VPN tunnel, or load balancer endpoint can become a single point of failure even when application servers are distributed.

Resilient designs typically include:

• Redundant subnets across at least two zones.
• Load balancers with provider-managed multi-zone capacity.
• One NAT gateway per zone when zonal failure and cross-zone charges matter.
• Two VPN tunnels, preferably terminating in independent infrastructure.
• Redundant dedicated circuits for important hybrid workloads.
• Health checks and automated failover for service endpoints.
• Tested route propagation and recovery procedures.

Availability is not identical to performance. A design may survive a zone failure but still exhibit high latency because traffic crosses zones unnecessarily. Architects must evaluate availability, latency, data-transfer cost, and operational complexity together.

5. Load Balancers

A load balancer distributes client requests across healthy backend targets. It can terminate TLS, perform health checks, preserve or replace client connection information, apply routing rules, and provide a stable service address.

A layer 4 load balancer operates using transport protocols such as TCP or UDP. It is appropriate when the system requires high throughput, low latency, or protocols that should not be interpreted at the application layer. A layer 7 load balancer understands HTTP or HTTPS and can route using hostnames, paths, headers, cookies, or methods.

For example, requests for api.example.com may go to an API target group, while requests for example.com/images may go to an image service. Health checks should test meaningful service readiness rather than merely whether a process is running. A server returning HTTP 200 while unable to reach its database may still be unhealthy from the user’s perspective.

TLS termination at a load balancer simplifies certificate management, but traffic from the load balancer to backends may also need encryption. Mutual TLS, client certificate validation, and end-to-end encryption may be required for regulated or highly sensitive workloads.

Load balancing does not eliminate application-state problems. Stateful sessions should use shared session storage, signed tokens, or deliberate session affinity. The preferred design is usually stateless application servers so that any healthy instance can process a request.

6. DNS and Service Discovery

The Domain Name System maps names to records. Common records include A for IPv4 addresses, AAAA for IPv6 addresses, CNAME for aliases, MX for mail routing, TXT for verification and policy, and NS for delegation.

Public DNS makes services discoverable on the internet. Private DNS zones resolve names only within selected virtual networks or connected environments. Split-horizon DNS uses the same name with different answers depending on whether the query originates internally or externally. This enables internal clients to resolve a service to a private address while external clients receive a public endpoint.

DNS caching is controlled by time to live (TTL). A low TTL can support quicker changes but increases query volume and may not eliminate propagation delay because resolvers can apply policy-specific behavior. A high TTL reduces query load but slows failover and migration. DNS is therefore a traffic-management tool, but it is not a substitute for application health checking.

Weighted, latency-based, geolocation, and failover routing policies support different objectives. Weighted routing distributes traffic by configured proportions; latency-based routing selects a region with comparatively low measured latency; failover routing directs clients to a secondary endpoint when the primary is considered unhealthy.

Service discovery inside a cloud environment can use private DNS names, registries, container orchestration services, or platform-native naming. Names should be stable even when instances are replaced.

7. Content Delivery Networks

A content delivery network (CDN) caches and serves content from edge locations closer to users. It is most effective for cacheable static assets such as images, JavaScript, stylesheets, software downloads, and video segments. A CDN can also provide TLS termination, compression, request filtering, bot controls, and some denial-of-service protection.

The origin remains the authoritative source. Cache-control headers, object versioning, invalidation procedures, and protection against direct origin access are important. Dynamic or personalized responses require careful cache-key design; incorrect caching can disclose one user’s content to another. Sensitive responses should normally be marked non-cacheable or separated by an authenticated cache key.

A CDN reduces user-perceived latency and origin load, but it introduces another operational layer. Teams must understand cache invalidation, stale content, logging, certificate management, origin failover, and regional availability.

8. Firewalls and Network Security Controls

A firewall enforces traffic policy. Cloud environments commonly provide several layers:

• Security groups or stateful firewall rules attached to interfaces or workloads.
• Network ACLs or stateless subnet-level filters.
• Managed cloud firewalls for centralized inspection and egress control.
• Web application firewalls (WAFs) for HTTP-layer attacks such as injection and malicious request patterns.
• Host-based firewalls inside operating systems.
• Provider service policies and identity-based authorization.

Stateful controls remember connection state. If an outbound connection is permitted, the returning traffic is usually allowed automatically. Stateless ACLs require explicit rules for both directions and ephemeral ports. Neither model should be assumed without reading the provider documentation.

The principle of least privilege means allowing only necessary protocols, ports, sources, destinations, and directions. A rule such as “allow TCP 443 from the internet to every server” is generally broader than required. Instead, public traffic should terminate at a protected load balancer, while backend security groups permit traffic only from that load balancer.

Egress filtering is frequently overlooked. Restricting outbound destinations can limit malware communication, data exfiltration, and accidental access to unapproved services. Centralized inspection may be justified, but forced hairpin routing can increase latency and cost.

Logs should record accepted and rejected flows, firewall decisions, WAF events, DNS queries where appropriate, and load-balancer access. Logs must be protected against tampering and retained according to legal, contractual, and operational requirements.

9. Private Endpoints and Managed Services

A private endpoint provides private connectivity from a virtual network to a managed service. Instead of sending traffic through the public internet, the application resolves a service name to a private interface or provider-managed private address. This reduces exposure and can simplify compliance and egress control.

Private endpoints are especially useful for object storage, databases, secrets management, container registries, and software repositories. DNS is critical: clients must resolve the service’s expected name to the private endpoint. A private route without correct DNS may cause clients to use a public address or fail to connect.

Private connectivity does not automatically grant authorization. Identity policies, resource policies, endpoint policies, encryption, and service-level controls remain necessary. Private endpoints can also create unexpected cost, scale, and DNS-management considerations.

10. VPN and Hybrid Connectivity

A site-to-site VPN creates encrypted tunnels over an untrusted network, generally using IPsec. It is relatively fast to deploy and economical for moderate traffic. Its limitations include internet-dependent performance, encryption overhead, tunnel configuration complexity, and potentially variable latency.

A remote-access VPN connects individual users to cloud or corporate resources. It requires strong identity verification, device posture controls, split-tunnel decisions, and careful authorization. A VPN should not be treated as proof that a user is trusted.

Dedicated connectivity services provide a private physical or provider-partner path between an organization and the cloud. They can offer more predictable performance and higher throughput than internet VPNs, but they involve lead time, carrier coordination, location constraints, and higher cost. Dedicated links should generally be paired with backup VPN tunnels or a second circuit.

Hybrid designs must address:

• Non-overlapping address ranges.
• Route exchange, static routes, or dynamic routing such as BGP.
• Asymmetric routing and return paths.
• DNS resolution in both directions.
• MTU and packet-fragmentation behavior.
• Encryption and key rotation.
• Monitoring of tunnels, circuits, and route changes.
• Data residency and regulatory restrictions.

11. Applied Case: Retail Analytics Platform

The following is an illustrative case.

Background

A regional retailer operates an on-premises inventory system and is moving its customer-facing website and analytics platform to the cloud. The website must support seasonal demand, while inventory data must remain accessible to existing stores. Payment data is subject to contractual security requirements.

Problem

The initial proposal places web servers, application servers, databases, and administration tools in one public subnet. It also uses overlapping address ranges with several stores and permits broad inbound access for convenience.

Analysis

The proposal has weak segmentation, an unnecessary public database, difficult future hybrid routing, and a large attack surface. It also lacks a clear failure strategy for a zone outage. The overlapping ranges would make direct routing between stores and cloud services unreliable.

Approach and Solution

The organization reserves a non-overlapping 10.80.0.0/16 cloud range. Two availability zones are used. Public subnets contain only a CDN origin load balancer and controlled ingress components. Application subnets contain stateless web and API services. Private database subnets have no internet route. A managed NAT gateway permits controlled outbound updates from private workloads.

A site-to-site VPN is deployed initially with two tunnels, while a dedicated circuit is planned for predictable long-term traffic. A transit gateway connects the cloud network to store networks. Private DNS allows applications to resolve inventory services consistently. Private endpoints are used for object storage, secrets, and the container registry. A WAF protects the public HTTP interface, and security groups allow database traffic only from the application tier.

The CDN caches versioned static assets. The load balancer performs TLS termination, health checks, and path-based routing. Centralized logs record flow decisions, VPN status, DNS activity, and application access. Automated tests verify that databases are unreachable from the internet and that failover works.

Outcome

The revised design reduces public exposure, supports horizontal scaling, provides a clear migration path from VPN to dedicated connectivity, and permits independent failure of an application instance or availability zone. It also introduces additional cost and operational responsibilities for endpoint management, logging, route governance, and multi-zone capacity.

Learning Points

The case demonstrates that networking decisions are architectural decisions, not merely configuration tasks. Address planning affects future mergers and hybrid connectivity; DNS affects private access and failover; segmentation affects security; and redundancy must be tested rather than assumed.

12. Governance, Ethics, and Contemporary Practice

Network architecture must comply with privacy, cybersecurity, sector-specific, and contractual requirements. Data may be restricted by geographic location, retention rules, or cross-border transfer obligations. Security teams should document who can access network logs because logs may contain IP addresses, usernames, URLs, or other personal data.

Automation through infrastructure as code improves consistency and reviewability. Changes should pass peer review, policy checks, and controlled deployment pipelines. Secrets, private keys, and VPN credentials must not be embedded in source code.

Artificial intelligence can assist with anomaly detection, traffic classification, configuration analysis, and incident triage. However, AI-generated recommendations require human validation. An automated system may misclassify legitimate traffic, expose sensitive logs to an external service, or recommend an overly permissive rule. Explainability, data minimization, access control, and audit trails remain essential.

Contemporary cloud networking increasingly uses zero-trust principles, identity-aware proxies, service meshes, confidential connectivity, IPv6, edge computing, and software-defined wide-area networking. Zero trust does not mean that networks are irrelevant; it means that network location alone is insufficient evidence of trust. Access should be continuously evaluated using identity, device, workload, context, and policy.

13. Design and Operational Best Practices

1. Start with business flows and trust boundaries, not with provider products.
2. Reserve non-overlapping address space and document ownership of every prefix.
3. Separate public, application, data, management, and shared-service subnets.
4. Use private connectivity to managed services where exposure reduction justifies the cost.
5. Apply least privilege to ingress and egress rules.
6. Prefer stateless application tiers and health-based load balancing.
7. Design DNS, routes, gateways, and security policies together.
8. Deploy redundancy across fault domains and test failover regularly.
9. Monitor accepted and rejected traffic, route changes, DNS failures, latency, and packet loss.
10. Control network changes through infrastructure as code, review, tagging, and policy enforcement.
11. Evaluate data-transfer charges and cross-zone traffic before implementation.
12. Document operational runbooks for certificate renewal, tunnel failure, route rollback, and incident response.

Challenges and Limitations

Cloud networking abstracts physical infrastructure but does not remove complexity. Provider-specific behavior can make designs difficult to port. NAT, cross-zone transfer, inspection appliances, private endpoints, and dedicated links can create significant costs. Distributed architectures make troubleshooting harder because a failure may involve DNS, routing, identity, firewall policy, service health, or an external provider.

Security controls can conflict with availability and usability. Extremely restrictive egress policies may prevent patching; centralized inspection may increase latency; low DNS TTLs may increase operational load; and excessive segmentation may make legitimate service communication difficult. Good design therefore depends on measured risk, documented requirements, testing, and continuous review.

Chapter Summary

Cloud networking provides the logical foundation for secure and reliable cloud services. Virtual networks and subnets establish address spaces and segmentation, while routing and gateways determine packet paths. CIDR supports systematic address planning, but provider reservations and future hybrid connectivity must be considered.

Load balancers distribute traffic and provide health-based service access. DNS enables naming, private resolution, failover, and traffic management. CDNs improve delivery of cacheable content but require careful cache and origin controls. Firewalls, security groups, ACLs, WAFs, identity policies, and endpoint policies operate as complementary layers rather than substitutes for one another.

Private endpoints reduce public exposure to managed services. VPNs provide flexible encrypted connectivity, while dedicated links offer more predictable hybrid performance at greater cost. Resilient designs use multiple fault domains, redundant paths, tested recovery, and observability. Professional cloud networking also requires governance, privacy protection, automation, cost awareness, and human oversight of emerging AI-assisted operations.

Key Terms

Virtual network: A logically isolated software-defined network in a cloud environment.

Subnet: A defined IP address range within a larger network.

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

Route table: A collection of destination prefixes and next-hop targets.

Internet gateway: A cloud component providing a path between a virtual network and the public internet.

NAT gateway: A service that enables outbound access from private addresses without normally permitting unsolicited inbound connections.

Transit gateway: A central routing service connecting multiple networks and connectivity types.

Peering: A direct logical connection between selected virtual networks.

Load balancer: A service that distributes connections or requests among backend targets.

Health check: A test used to determine whether a service target can receive traffic.

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

CDN: A distributed edge service that caches and delivers content near users.

Firewall: A control that permits or denies network traffic according to policy.

WAF: A firewall designed to inspect and protect web application traffic.

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

VPN: An encrypted logical connection across an untrusted network.

Hybrid connectivity: Networking that links cloud environments with on-premises or other external environments.

Zero trust: A security approach that does not grant trust solely because of network location.

Review Questions

Short Answer Questions

1. What is the difference between a virtual network and a subnet?
2. Why should cloud address ranges be planned before hybrid connectivity is implemented?
3. What is the principal purpose of a NAT gateway?
4. How does a layer 7 load balancer differ from a layer 4 load balancer?
5. Why is DNS important when private endpoints are used?

Long Answer Questions

1. Explain how routing, gateways, security groups, and firewalls work together in a cloud network.
2. Design a three-tier cloud network for a web application and justify the placement of each tier.
3. Compare VPN connectivity, dedicated connectivity, and network peering in terms of use, benefits, and limitations.
4. Discuss how DNS, load balancing, and CDN services can jointly improve application availability and performance.
5. Explain the security and governance implications of public subnets, private subnets, private endpoints, and egress filtering.

Analytical / Application Questions

1. An organization has 10.0.0.0/16 available and needs eight equal subnets. Determine an appropriate prefix length and explain the address capacity and design assumptions.
2. A private application can reach a managed database through a route, but the connection is rejected. Identify at least four possible causes and propose a systematic troubleshooting sequence.
3. Design a resilient hybrid architecture for an enterprise with two data centres, three cloud virtual networks, and a requirement for continued operation after one VPN tunnel or availability zone fails. Justify your routing, redundancy, DNS, and security decisions.

Multiple Choice Questions with Answers

Question 1

Which component normally determines the next hop for a packet in a cloud virtual network?

A. Route table

B. DNS TXT record

C. CDN cache

D. TLS certificate

Correct Answer: A. Route table

Question 2

How many total IPv4 addresses are contained in a /26 prefix?

A. 32

B. 64

C. 128

D. 256

Correct Answer: B. 64

Question 3

What is the primary function of a NAT gateway for private workloads?

A. Allow unsolicited inbound internet connections

B. Provide outbound connectivity while hiding private source addresses

C. Resolve internal DNS names

D. Distribute HTTP requests across servers

Correct Answer: B. Provide outbound connectivity while hiding private source addresses

Question 4

Which service is most appropriate for routing HTTP requests by hostname or URL path?

A. Layer 7 load balancer

B. Layer 2 switch

C. NAT gateway

D. VPN concentrator

Correct Answer: A. Layer 7 load balancer

Question 5

What is a major risk of overlapping address ranges in a hybrid network?

A. DNS records become immutable

B. Direct routing becomes ambiguous or impossible

C. TLS certificates cannot be issued

D. CDN objects cannot be cached

Correct Answer: B. Direct routing becomes ambiguous or impossible

Question 6

Which statement best describes a private endpoint?

A. A public IP address assigned to every database

B. A private connection from a virtual network to a managed service

C. A DNS record that always points to the internet

D. A firewall rule that permits all outbound traffic

Correct Answer: B. A private connection from a virtual network to a managed service

Question 7

What is the principal purpose of a CDN?

A. Cache and deliver content from locations near users

B. Allocate private IPv4 addresses

C. Exchange dynamic routes with a data centre

D. Replace all application authentication

Correct Answer: A. Cache and deliver content from locations near users

Question 8

Which control is specifically designed to inspect HTTP-layer attacks?

A. Web application firewall

B. NAT gateway

C. Transit gateway

D. Internet gateway

Correct Answer: A. Web application firewall

Question 9

A /16 IPv4 network is divided into equal /24 subnets. How many subnets result?

A. 16

B. 64

C. 256

D. 512

Correct Answer: C. 256

Question 10

Why are two VPN tunnels commonly used in a production hybrid design?

A. To eliminate the need for routing

B. To provide redundancy if one tunnel fails

C. To make all traffic public

D. To replace DNS resolution

Correct Answer: B. To provide redundancy if one tunnel fails