Cloud Networking and Hybrid Infrastructure

Introduction and context

Cloud computing does not remove the need for networking; it changes the location, scale, and programmability of network functions. A cloud network must connect applications, users, databases, security services, operational tools, and external systems while preserving confidentiality, availability, performance, and administrative control. In a hybrid infrastructure, some resources remain in an organisation’s premises or private data centre while others operate in one or more public-cloud environments.

A sound cloud-network design therefore addresses two related questions:

1. How should resources communicate within the cloud?
2. How should cloud resources communicate securely and reliably with users, branches, data centres, partners, and identity systems?

This chapter develops a provider-neutral design model. Cloud providers use different names—for example, virtual networks, virtual private clouds, virtual networks, security groups, network security groups, route tables and private links—but the underlying principles are broadly similar.

Learning objectives

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

• design a virtual network and subnet structure;
• distinguish routing, filtering, translation and gateway functions;
• apply security groups, network controls and private endpoints;
• select and configure load-balancing and DNS strategies;
• compare site-to-site VPNs with dedicated private connectivity;
• explain hybrid routing, addressing and failure considerations;
• integrate on-premises and cloud identity through federation;
• evaluate a hybrid design against security, availability, cost and operational criteria.

1. The cloud networking model

A cloud network is a logically isolated address space implemented on shared physical infrastructure. It normally contains:

• subnets, which divide the address space into network segments;
• route tables, which determine the next hop for packets;
• security controls, which permit or deny traffic;
• gateways, which connect to the internet, private networks or managed services;
• name-resolution services, which translate names into addresses;
• traffic-distribution services, such as load balancers;
• telemetry, including flow logs, metrics and packet-level diagnostics.

Cloud networking is software-defined. Network topology is represented by configuration and APIs rather than only by physical switches and routers. This enables rapid provisioning, but it also creates a risk: an incorrect route, overly broad rule or accidental public address can be deployed at machine speed.

A useful design principle is least connectivity: provide only the communication paths that an application requires. Connectivity should be explicit, observable and reviewable.

Important terminology

2. Addressing and subnet design

2.1 IPv4 and CIDR

IPv4 addresses contain 32 bits. CIDR notation writes an address followed by a prefix length. In 10.20.0.0/16, the first 16 bits identify the network and the remaining 16 bits identify addresses within it.

The number of addresses in an IPv4 prefix of length p is:

where N is the total number of addresses and p is the prefix length, with 0 ≤ p ≤ 32. In a conventional IPv4 subnet, the network and directed-broadcast addresses are reserved, so the commonly usable host count is:

This second expression is not universally applicable: cloud platforms may reserve additional addresses, and point-to-point or specialised subnets may use different conventions. Always consult the provider’s allocation rules.

For example, a /24 contains 2^(32−24) = 256 total addresses and conventionally 254 usable host addresses. A /26 contains 64 total addresses and conventionally 62 usable host addresses.

IPv6 uses 128-bit addresses. Its address quantity for a prefix length p is:

IPv6 subnet planning should account for provider conventions, routing aggregation, security policy and dual-stack operational complexity rather than treating the enormous address space as a reason to ignore structure.

2.2 Hierarchical allocation

A production network should allocate address space hierarchically. For example, an organisation might reserve 10.20.0.0/16 for a cloud environment, then allocate /20 ranges to development, testing and production. Each environment can be divided into availability zones and subnet roles.

A typical multi-tier layout is:

Subnets should not be created merely according to server type. They should reflect trust boundaries, routing requirements, failure domains, regulatory constraints and operational ownership.

2.3 Address planning in hybrid systems

Overlapping private address ranges are a major hybrid-network problem. If both the cloud and data centre use 10.0.0.0/8, a router may not know which destination is intended. The preferred solution is an organisation-wide address-management plan using non-overlapping ranges. Renumbering is usually safer than depending permanently on network-address translation (NAT).

NAT can be useful when connecting legacy systems or controlling outbound internet access, but it obscures original addresses, complicates logging and can interfere with protocols that embed addresses in payloads. It should be a deliberate boundary technique, not a substitute for planning.

3. Routing and gateways

Routing determines where a packet should be sent. A route generally contains a destination prefix and a next hop or target. The most specific matching route is normally preferred; this is called longest-prefix matching.

A cloud route table may include:

• a local route for traffic within the virtual network;
• a default route, often 0.0.0.0/0, to an internet or inspection gateway;
• routes for on-premises prefixes through a VPN or dedicated-link gateway;
• routes to shared services through a transit hub;
• routes to service endpoints or private-link interfaces.

A route does not itself guarantee communication. Return traffic must also have a valid route, and firewalls, security groups, network ACLs and operating-system controls must permit the flow. This is why hybrid troubleshooting must examine both directions.

Gateway types

• Internet gateway: provides a logical path between public addresses and the virtual network. It does not automatically make every resource public.
• NAT gateway or egress gateway: permits selected private resources to initiate outbound connections without accepting unsolicited inbound connections through the same translation state.
• VPN gateway: terminates encrypted tunnels to remote networks.
• Transit gateway or hub: connects multiple virtual networks and external networks through a central routing domain.
• Virtual firewall or inspection appliance: applies advanced filtering, intrusion prevention, URL controls or traffic recording.
• Direct-connect gateway: associates a private circuit with one or more cloud networks.

Centralised transit can simplify governance and inspection, but it may introduce bottlenecks, additional cost and a larger blast radius. Distributed routing can improve autonomy and resilience but requires stronger standards and more complex policy management.

4. Security controls and segmentation

4.1 Defence in depth

Cloud security should combine several control layers:

1. identity and authentication;
2. network reachability;
3. stateful workload filtering;
4. subnet or perimeter controls;
5. host and application controls;
6. encryption and monitoring.

No single layer should be treated as sufficient.

4.2 Security groups

A security group is commonly associated with a virtual machine, network interface or managed service. It is usually stateful: if an allowed rule permits a connection, return traffic is automatically allowed for that established flow. Rules commonly specify protocol, port, source or destination and action.

A strong rule set expresses application relationships rather than broad addresses. For example, allow the web tier to reach the application tier on TCP 8443, and allow the application tier to reach the database tier on TCP 5432. Avoid allowing 0.0.0.0/0 to administrative ports such as SSH or RDP.

Security groups are not always identical across providers. Some support only allow rules; others support explicit denies. Some are attached to interfaces, while others apply at subnet level. The actual semantics must be verified before relying on them.

4.3 Network ACLs and firewalls

Network ACLs generally apply at subnet boundaries and may be stateless, requiring explicit rules for both directions. They are useful for broad subnet-level guardrails but can become difficult to maintain when used as the primary application policy.

A managed or virtual firewall may provide central inspection, but forced hairpinning—sending all traffic through a central appliance—can increase latency and cost. Inspection should be placed where it provides meaningful risk reduction.

4.4 Zero-trust interpretation

Zero trust is not a particular product or topology. It is a security approach that avoids assuming trust solely from network location. Access decisions consider identity, device condition, workload identity, requested resource, context and policy. Private subnets remain valuable for reducing exposure, but “inside the network” must not automatically mean trusted.

5. Private endpoints and service access

Publicly addressing a managed database, object store or secrets service increases exposure and may conflict with data-residency or compliance requirements. A private endpoint provides a private interface or private route from a virtual network to a provider service. Applications can then reach the service without traversing the public internet.

Private endpoints should be designed with:

• endpoint-specific security rules;
• private DNS names that resolve to private addresses;
• explicit policies restricting which networks may use the service;
• logging of endpoint access;
• consideration of transitive access and data exfiltration.

A private endpoint is not automatically a complete security solution. If every workload can access every service through unrestricted endpoint policy, the endpoint may create a broad data path. Service-level authorisation remains necessary.

6. Load balancing and resilient application access

Load balancers distribute client requests among healthy backend targets. They improve availability, support horizontal scaling and can terminate TLS, but they do not replace application resilience.

Common forms include:

• Layer 4 load balancing, which distributes TCP or UDP flows based largely on addresses and ports;
• Layer 7 load balancing, which understands HTTP or HTTPS and can route by host name, path, header or cookie;
• internal load balancing, which exposes services only to private clients;
• external load balancing, which provides controlled public ingress.

A typical request path is client → DNS → external load balancer → application tier → internal load balancer or service discovery → data tier. Health checks must test meaningful service readiness rather than merely whether a process responds to a port. Timeouts, connection draining, session persistence and cross-zone traffic charges require explicit decisions.

TLS may terminate at the edge, at the workload, or at both. End-to-end encryption is preferable where traffic crosses trust boundaries or sensitive data is involved. Certificates, cipher policies and renewal should be automated.

7. DNS in cloud and hybrid environments

DNS is both a naming system and a traffic-control mechanism. Important functions include:

• public authoritative zones for internet-facing names;
• private hosted zones for internal names;
• recursive resolution for clients;
• conditional forwarding between cloud and on-premises namespaces;
• health-aware responses and geographic or latency-based routing;
• service discovery for dynamic workloads.

A hybrid design commonly uses DNS resolvers in both environments. Cloud clients may forward queries for the corporate namespace to on-premises resolvers, while on-premises clients forward cloud-private zones to cloud resolvers. The design must avoid forwarding loops and should document authoritative ownership for each zone.

DNS caching means that a record change is not instantly visible everywhere. The time-to-live (TTL) value influences the duration of caching, but resolvers may apply local policies. Very low TTLs can support rapid changes but increase query load and operational dependence on DNS availability.

DNS security includes restricted zone transfers, authenticated administrative access, DNS logging, protection against unauthorised record changes and, where appropriate, DNSSEC for public zones. DNSSEC validates authenticity of DNS data; it does not encrypt ordinary DNS queries.

8. Connecting on-premises and cloud

8.1 Site-to-site VPN

A site-to-site VPN uses protocols such as IPsec to create encrypted tunnels between customer and cloud gateways. It is usually faster to deploy and less expensive than a dedicated circuit. Its performance depends on internet paths, tunnel endpoints and encryption capacity.

A resilient design normally uses two tunnels, separate gateway endpoints or availability domains, dynamic routing where supported, and monitored failover. Static routes can be appropriate for small, stable networks but become difficult to manage as prefixes grow.

VPN design decisions include encryption algorithms, key rotation, dead-peer detection, maximum transmission unit (MTU), route advertisements and overlapping address handling. Encapsulation reduces the effective payload size, so fragmentation or path-MTU discovery problems should be tested rather than assumed away.

8.2 Dedicated private connectivity

A dedicated link provides a private circuit between the organisation and a cloud provider or connectivity partner. It can offer more predictable latency, higher throughput and reduced exposure to the public internet. It is not automatically encrypted, however. Sensitive traffic may still require application encryption or an encrypted overlay.

Dedicated links require lead time, colocation or provider interconnection, contractual planning and careful redundancy. A single circuit or single facility is a single point of failure. Diverse physical paths and, where justified, diverse providers should be evaluated.

A hybrid architecture often uses both: a dedicated link for primary traffic and VPN tunnels as backup or for temporary expansion.

8.3 Dynamic routing and transit

Border Gateway Protocol (BGP) is commonly used to exchange prefixes between an organisation and a cloud connectivity service. BGP can support automatic failover and route updates, but route advertisements must be restricted. Unintended advertisement of broad prefixes can redirect traffic or create outages.

A transit hub is useful when many virtual networks, branches and data centres must communicate. Route domains should be separated where full mesh connectivity is not required. For example, development may reach shared logging services but not production databases.

9. Identity federation and access control

Network connectivity is incomplete without identity integration. Identity federation allows a cloud service to trust an organisation’s identity provider. Common protocols include SAML 2.0 for browser-based single sign-on and OpenID Connect, built on OAuth 2.0, for modern application authentication. OAuth 2.0 is primarily an authorisation framework; OpenID Connect adds an identity layer.

A typical federated flow is:

1. a user requests a cloud application;
2. the cloud service redirects the user to the organisational identity provider;
3. the identity provider authenticates the user, often with multi-factor authentication;
4. an assertion or token is issued for the intended service;
5. the cloud service validates the token and maps claims to roles;
6. access is granted according to least privilege and policy.

Federation reduces password duplication but creates dependency on identity-provider availability, clock synchronisation, certificate management and correct claim mapping. Emergency access accounts, tested recovery procedures and monitored administrative actions are essential.

Identity should be integrated with network controls. For example, administrative interfaces may require both a privileged role and access through a managed device or private administration path. Workload identities should be preferred over embedded long-lived access keys.

10. A systematic design method

A professional design can follow these stages:

Stage 1: Establish requirements

Document users, workloads, data classifications, traffic volumes, latency targets, availability objectives, regulatory obligations and operational ownership.

Stage 2: Create an address and naming plan

Reserve non-overlapping CIDR ranges, define IPv6 intentions, allocate subnets by environment and trust boundary, and specify DNS zones and naming conventions.

Stage 3: Define traffic flows

For every important flow, record source, destination, protocol, port, direction, expected volume, route, inspection point and logging requirement. A flow matrix is more reliable than an informal topology sketch.

Stage 4: Select connectivity

Choose internet ingress, NAT, VPN, dedicated connectivity, transit and private endpoints according to risk, performance, resilience and cost.

Stage 5: Apply layered controls

Implement security groups, subnet controls, firewalls, service policies, encryption, identity federation and administrative safeguards.

Stage 6: Design failure behaviour

Specify what happens if a tunnel, link, load-balancer target, DNS resolver, identity provider or availability zone fails. Avoid merely documenting the normal path.

Stage 7: Automate and test

Use infrastructure as code, peer review, policy validation, automated configuration tests and controlled deployment pipelines. Test reachability, denial, failover, recovery and logging.

Stage 8: Operate continuously

Monitor flow logs, route changes, tunnel status, DNS errors, certificate expiry, anomalous egress and load-balancer health. Review rules and privileges periodically.

11. Worked design example

An organisation has a data-centre application and is moving its web and application tiers to a cloud environment. The cloud network is 10.40.0.0/16. Production receives 10.40.0.0/20, testing receives 10.40.16.0/20 and shared services receive 10.40.32.0/20. The data centre uses 10.50.0.0/16, so no ranges overlap.

Production is divided into three zone-specific subnet groups:

• public load-balancer subnets;
• private application subnets;
• restricted data subnets.

Public DNS directs app.example.com to an external HTTPS load balancer. The load balancer sends traffic to application instances on TCP 8443. Application instances connect to the database on TCP 5432. The database has no public address. Cloud applications access object storage through a private endpoint. A pair of VPN tunnels connects the cloud gateway to the data centre, and BGP advertises the data-centre prefix.

The principal security rules are:

• internet clients may reach only TCP 443 on the load balancer;
• the load balancer may reach application targets only on TCP 8443;
• application targets may reach the database only on TCP 5432;
• administration is permitted only from a privileged management path;
• cloud-to-data-centre access is limited to documented application prefixes;
• outbound internet access from private workloads uses a controlled NAT or inspection gateway.

If the /20 production block is considered as a conventional IPv4 network, it contains 2^(32−20) = 4096 addresses, before provider-specific reservations. This is ample for multiple subnets, but the design must reserve capacity for growth and avoid assuming that every address is available to workloads.

The design is validated by testing successful application flows, blocked direct database access, private endpoint resolution, VPN failover, DNS failure behaviour, load-balancer health checks and restoration from configuration backups.

12. Illustrative case study: Northbridge Health Services

Background

Northbridge Health Services operates patient scheduling systems in a private data centre and wants to deploy a cloud-based analytics platform. Patient records are sensitive, and the organisation must demonstrate access control, auditability and service continuity.

Problem

The existing data centre uses overlapping 10.0.0.0/8 ranges acquired through earlier mergers. A direct cloud connection would therefore create ambiguous routes. Analysts also require access to de-identified data, while production applications must not be exposed to the public internet.

Analysis

The technical team identifies three risks: address overlap, excessive data access and dependence on a single connectivity path. It also determines that the analytics platform needs high-volume transfers but does not require interactive, millisecond-level access to the operational database.

Approach and solution

Northbridge creates a new, non-overlapping cloud range and initially uses a translation boundary for a small legacy segment. It schedules a longer-term renumbering programme. A dedicated link is deployed as the primary path, with two encrypted VPN tunnels as backup. A transit hub separates production, analytics and shared-services routing domains.

Production data is copied through a controlled data pipeline into a de-identification service. Analysts access only the resulting dataset through private endpoints. Private DNS zones prevent service names from resolving to public addresses. Identity federation with mandatory multi-factor authentication maps analyst and administrator groups to separate cloud roles. Security groups restrict application-to-database traffic, while flow logs and data-access logs are retained centrally.

Outcome

The organisation gains predictable bulk connectivity without permitting general analyst access to production systems. VPN failover protects against circuit failure, and the use of private endpoints reduces public exposure. The remaining risk is legacy address translation, which is documented, monitored and assigned a retirement milestone.

Learning points

• Address architecture must be resolved before large-scale connectivity.
• Data classification should influence both network paths and identity roles.
• A dedicated circuit improves path predictability but does not replace encryption or redundancy.
• Hybrid security is strongest when routes, identities, service policies and logs agree.

13. Challenges, governance and contemporary practice

Cloud networking introduces several persistent challenges. Configuration drift can cause undocumented routes or open ports. Multi-cloud environments multiply terminology and policy differences. Egress traffic may create unexpected cost and data-exfiltration risk. Central inspection can reduce visibility if encryption is not considered carefully. Provider-managed services can change endpoint addresses or service behaviour, requiring dependency monitoring.

Governance should define ownership for address ranges, DNS zones, route tables, security groups, certificates, connectivity contracts and emergency access. Changes should be traceable to an approved request and deployed through tested automation. Regulatory requirements may impose data-location restrictions, retention rules, breach-notification duties and separation of administrative responsibilities.

AI-assisted network tools can help summarise flow logs, identify unusual egress and suggest policy changes. They must not be granted unsupervised authority to modify production routes or security rules. Training-data leakage, incorrect inferences, explainability and accountability are important concerns. Human review, least privilege, audit trails and controlled rollout remain necessary.

Contemporary architectures increasingly use software-defined wide-area networking, service meshes, confidential computing, IPv6 dual stack, policy-as-code and cloud-native firewalls. These technologies can improve flexibility, but each adds operational assumptions. A mature design favours measurable requirements and tested controls over fashionable components.

Best-practice checklist

• Use non-overlapping, hierarchically planned address space.
• Separate public, application, data and management functions.
• Prefer private endpoints for sensitive managed services.
• Express rules in terms of required application flows.
• Protect administrative access with federated identity and multi-factor authentication.
• Use redundant VPN tunnels or diverse dedicated paths.
• Advertise only necessary prefixes through BGP.
• Design DNS ownership, forwarding and failure behaviour explicitly.
• Encrypt sensitive traffic even across private circuits.
• Centralise logs while respecting privacy and retention requirements.
• Manage networking as code with review, testing and rollback.
• Test failure, recovery and denial—not only successful connectivity.

Chapter Summary

Cloud networking combines virtual address spaces, subnets, routes, gateways, filtering, private service access, DNS and load distribution. Effective designs use hierarchical, non-overlapping addressing and distinguish reachability from authorisation: a valid route does not override security policy. Security groups, ACLs, firewalls, private endpoints and identity controls provide defence in depth.

Hybrid infrastructure requires careful selection between VPNs and dedicated links, with redundancy, route control, encryption and monitoring. DNS is central to both naming and service discovery, while identity federation connects network access to organisational authentication and least-privilege roles. Professional implementation depends on flow analysis, infrastructure as code, documented ownership, continuous observability and tested failure behaviour.

Key Terms

Virtual network: A logically isolated cloud network.

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

Subnet: A subdivision of an IP network.

Route table: Rules that select next hops for destination prefixes.

Longest-prefix matching: Selection of the most specific matching route.

NAT: Translation between address spaces, commonly used for controlled egress.

Internet gateway: A logical connection between a virtual network and the internet.

Security group: A workload- or interface-associated traffic filter.

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

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

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

DNS: A distributed naming and resolution system.

VPN: An encrypted logical tunnel across an underlying network.

Dedicated link: A private circuit connecting an organisation to cloud infrastructure.

BGP: A routing protocol used to exchange network prefixes.

Transit hub: A central routing service connecting multiple networks.

Identity federation: Trust between separate identity providers and services.

Zero trust: A security model that continuously evaluates access rather than trusting network location.

Infrastructure as code: Declarative or programmatic management of infrastructure configuration.

Review Questions

Short Answer Questions

1. What is the purpose of a route table in a virtual network?
2. Distinguish a security group from a network ACL.
3. Why are overlapping private address ranges problematic in hybrid networking?
4. What does a private endpoint provide?
5. State one benefit and one limitation of a dedicated cloud link.

Long Answer Questions

1. Explain how you would design public, application, data and management subnets for a three-tier application.
2. Compare site-to-site VPNs and dedicated links in terms of security, performance, cost and resilience.
3. Describe a hybrid DNS architecture using private zones and conditional forwarding.
4. Explain how identity federation and network controls can jointly implement least privilege.
5. Discuss the role of transit hubs, route domains and BGP in a multi-network cloud environment.

Analytical / Application Questions

1. A company uses 10.0.0.0/16 in its data centre and plans to use the same range in the cloud. Analyse the likely routing problems and recommend a migration strategy.
2. Design the traffic rules for a web application in which public clients access HTTPS, the web tier calls an application tier on TCP 8443, and the application tier calls a database on TCP 5432. Explain which paths must be denied.
3. A dedicated link is the primary hybrid connection and two VPN tunnels are backups. Identify at least five failure or monitoring scenarios that should be tested before production deployment.

Multiple Choice Questions with Answers

Question 1

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

A. 32

B. 64

C. 128

D. 256

Correct Answer: B. 64

Question 2

Which component normally determines the next hop for a destination prefix?

A. Route table

B. DNS zone

C. Certificate authority

D. Load-balancer health check

Correct Answer: A. Route table

Question 3

What is a principal purpose of a private endpoint?

A. To expose a database directly to the internet

B. To provide private access to a managed service

C. To replace all identity controls

D. To increase public DNS propagation speed

Correct Answer: B. To provide private access to a managed service

Question 4

Which load-balancing layer can commonly route HTTP requests by host name or URL path?

A. Layer 1

B. Layer 2

C. Layer 4

D. Layer 7

Correct Answer: D. Layer 7

Question 5

Why is overlapping address space especially problematic in a hybrid network?

A. It prevents TLS certificate renewal

B. It creates ambiguity about the intended destination

C. It disables all DNS caching

D. It guarantees excessive bandwidth

Correct Answer: B. It creates ambiguity about the intended destination

Question 6

Which protocol is commonly used to exchange cloud and on-premises route prefixes dynamically?

A. BGP

B. SMTP

C. SNMP

D. NTP

Correct Answer: A. BGP

Question 7

Which statement best describes a stateful security group?

A. It automatically makes every subnet public

B. It generally permits return traffic for an allowed established flow

C. It translates all private addresses into public addresses

D. It replaces the need for application authentication

Correct Answer: B. It generally permits return traffic for an allowed established flow

Question 8

What is a common advantage of a site-to-site VPN compared with a dedicated link?

A. It always provides more predictable latency

B. It is usually faster and less expensive to deploy

C. It never requires monitoring

D. It removes the need for route configuration

Correct Answer: B. It is usually faster and less expensive to deploy

Question 9

What does identity federation primarily establish?

A. Trust between identity systems for authentication and access decisions

B. A physical fibre connection between data centres

C. A new IPv4 address range

D. A replacement for DNS resolution

Correct Answer: A. Trust between identity systems for authentication and access decisions

Question 10

A conventional /24 IPv4 subnet has how many commonly usable host addresses before provider-specific reservations?

A. 128

B. 原

C. 254

D. 512

Correct Answer: C. 254