4. Cloud Networking and Application Delivery

Introduction and Context

Cloud applications are not deployed into an undifferentiated pool of computing resources. They operate within networks that determine how users reach the application, how application components communicate, where data is stored, and which traffic is permitted or denied. Cloud networking therefore provides the connective and control layer of a distributed system. A well-designed network can improve security, resilience, performance, and cost efficiency; a poorly designed network can expose sensitive services, create single points of failure, or make ordinary operational tasks unnecessarily complex.

In traditional data centres, network architecture was closely tied to physical equipment, fixed addresses, leased circuits, and carefully controlled perimeters. Cloud platforms preserve many familiar networking concepts—IP addressing, routing, firewalls, DNS, VPNs, and load balancing—but implement them through software-defined services and programmable APIs. This creates flexibility, but it also transfers significant responsibility to architects and development teams. Network design becomes part of application design and should be managed through infrastructure as code, observability, security policies, and automated testing.

This chapter examines virtual networks and subnets, routing and traffic control, private connectivity, name resolution, application delivery, and zero-trust access patterns across AWS, Microsoft Azure, and Google Cloud. Service names differ, but the underlying design principles are broadly transferable.

Learning Objectives

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

1. Design a virtual cloud network with appropriate address spaces, subnets, routes, and availability boundaries.

2. Distinguish among security groups, network firewalls, network ACLs, and web application firewalls.

3. Explain the operation and use of NAT, VPNs, dedicated private connectivity, DNS, and load balancers.

4. Select suitable combinations of load balancing, API gateways, CDNs, and WAFs for application delivery.

5. Apply zero-trust principles to cloud workloads and user access.

6. Evaluate networking alternatives using security, resilience, performance, operational, and financial criteria.

7. Recognise common design errors and develop a secure, observable, and resilient network architecture.

The Cloud Network as an Application System

A virtual private cloud (VPC in AWS and Google Cloud) or virtual network (VNet in Azure) is a logically isolated address space in which cloud resources communicate. Isolation does not automatically mean security. It establishes a boundary, but security depends on routes, firewall rules, identity controls, service configuration, and monitoring.

A typical multi-tier application has a public delivery layer, a private application layer, and a private data layer. Internet users reach a DNS name that resolves to a CDN, public load balancer, or API gateway. The delivery service forwards permitted requests to application services. Those services access databases, caches, queues, or object storage through private paths. Databases generally should not have publicly routable addresses. Administrative access should be provided through controlled management services, a VPN, a bastion pattern, or identity-aware access rather than an open SSH or RDP endpoint.

The design must answer five questions:

• Who or what is communicating?
• Which destination and protocol are required?
• Which network path carries the traffic?
• What policy permits or denies it?
• How can the communication be observed and audited?

These questions are more useful than simply asking whether a resource is “inside” or “outside” the network.

Addressing, Regions, Zones, and Subnets

Cloud networks use private IP ranges defined by RFC 1918, such as 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. An organisation should plan address space before creating networks. Overlapping ranges complicate peering, VPN connectivity, mergers, and hybrid routing. A common approach is to allocate a large CIDR block to each environment or region and divide it into smaller subnet ranges.

A subnet is a logical IP segment associated with a routing domain and, in many platforms, a particular availability zone. Public and private are architectural descriptions rather than intrinsic properties of a subnet. A subnet is effectively public when its route table provides a path to an internet gateway and resources have suitable public addressing. A private subnet lacks a direct inbound internet route; it may still permit controlled outbound access through NAT.

Subnets should be distributed across multiple availability zones. The application tier can then continue operating if one zone fails. Public subnets commonly contain load balancers, whereas private subnets contain application instances and databases. This is not an absolute rule: managed services may not appear within customer subnets, and some architectures use private load balancers or service endpoints.

Subnet size requires capacity planning. The usable address count is reduced by platform-reserved addresses, and autoscaling, temporary interfaces, container tasks, serverless functions, and deployment replacements can consume addresses rapidly. Small subnets may create an operational outage even when compute capacity remains available.

IPv6 deserves deliberate consideration. Its large address space can simplify allocation and reduce dependence on address translation, but it does not remove the need for firewalls or careful routing. Dual-stack operation also increases the number of paths and policies that must be tested.

Routing and Traffic Control

A route table maps destination prefixes to next hops such as an internet gateway, NAT gateway, virtual appliance, peering connection, VPN tunnel, or private service endpoint. Routing follows the most specific matching prefix. A default route, usually 0.0.0.0/0 for IPv4, is used when no more specific route exists.

Routing should be designed from communication requirements rather than convenience. For example, an application subnet may require routes to database subnets, private service endpoints, monitoring services, and a NAT device, while having no direct route to the internet. In hybrid environments, routes must be propagated or configured consistently on both sides of the VPN or private circuit.

A firewall policy is distinct from a route. A route may provide a path, but a security control decides whether the traffic is allowed. Security groups in AWS and Azure, and firewall rules associated with Google Cloud network interfaces, are commonly stateful: when an outbound connection is permitted, the return traffic is automatically recognised as part of that connection. Network ACLs and some network firewall controls operate at subnet or network boundaries and may be stateless, requiring explicit treatment of return traffic.

A useful policy model is least privilege. Permit only the source, destination, protocol, and port required for a business function. For example, an application service may connect to a database on its database port, but the database should not accept connections from the entire virtual network. Rules should refer to security groups, service accounts, managed identities, or stable tags where possible rather than broad IP ranges.

Security groups are generally workload-level controls. Network firewalls and ACLs provide broader inspection or segmentation. A WAF protects HTTP-aware applications and is not a substitute for a network firewall. Defence in depth may therefore involve a public load balancer, WAF, network firewall, security group, application authentication, and database authorisation.

NAT, Internet Egress, and Private Service Access

Network Address Translation allows private resources to initiate connections using a shared public address without accepting unsolicited inbound connections through that translation. A NAT gateway is a managed egress component commonly placed in a public subnet, while private subnets route outbound internet traffic to it. NAT is not a complete security mechanism: an overly permissive egress policy can still permit data exfiltration, malware communication, or access to unapproved services.

For high availability, NAT capacity and placement must be considered. Routing all zones through one NAT gateway can create a zone dependency and a bandwidth bottleneck. Separate NAT resources or a platform-supported resilient design may be appropriate, balanced against cost. Private endpoints or service endpoints can keep traffic to cloud services on provider networks and reduce dependence on public egress.

Organisations often use egress proxies, domain allow-lists, DNS filtering, or network firewalls to control outbound traffic. These controls support governance and reduce accidental exposure, but they must be maintained as applications evolve. Certificate validation and software-update processes should be tested when traffic is inspected or routed through proxies.

Hybrid Connectivity and Private Networking

A site-to-site VPN creates encrypted tunnels over the public internet between a cloud network and an enterprise network. It is relatively quick to deploy and economical for moderate traffic, but performance can vary and tunnel configuration requires monitoring. High availability normally requires redundant tunnels and independent paths.

Dedicated private connectivity—such as AWS Direct Connect, Azure ExpressRoute, or Google Cloud Interconnect—uses a private circuit or partner connection. It can provide more predictable latency, higher throughput, and compliance advantages, but it requires planning, provider coordination, and often higher fixed costs. Private connectivity is not automatically encrypted; organisations may still use encryption at the application layer or overlay VPNs when the threat model requires it.

Network peering provides private communication between network domains, but it can have limitations such as non-transitive routing. A hub-and-spoke model using a transit gateway, virtual WAN, or cloud router can centralise connectivity and policy. Centralisation improves consistency but may create a critical dependency unless designed redundantly. Service mesh technologies can provide workload-level traffic management, encryption, and identity, but they do not replace foundational IP routing.

DNS as a Control Plane

The Domain Name System translates names into addresses and service records. In cloud architectures, DNS is more than a convenience: it supports service discovery, traffic steering, failover, and environment separation. Public DNS zones serve internet users, while private zones resolve names only within selected networks or connected enterprise domains.

DNS policies can route users by geography, latency, weighted distribution, health status, or failover state. A low time-to-live can accelerate changes but increases query volume and may not eliminate caching immediately. A high time-to-live reduces query overhead but slows failover. Health checks should reflect application availability rather than merely the existence of a server.

Split-horizon DNS provides different answers for internal and external clients. It is useful when internal traffic should reach private addresses while external users reach a public delivery service. DNSSEC can protect the integrity of DNS responses in appropriate public-domain scenarios, while private DNS governance must prevent conflicting zones and unauthorised record changes.

Application Delivery: Load Balancers, API Gateways, and CDNs

A load balancer distributes traffic across healthy targets. Layer 4 load balancers operate primarily on TCP or UDP characteristics and are suitable when high performance, arbitrary protocols, or source-address preservation is important. Layer 7 load balancers understand HTTP or HTTPS and can route by host name, path, header, cookie, or request attributes. They can terminate TLS, apply redirects, perform health checks, and support blue-green or canary deployment patterns.

A load balancer improves availability only when its targets and dependencies are also resilient. Health checks should test meaningful readiness, not merely whether a process responds to a port. Poor health checks can send traffic to an instance that is alive but unable to serve requests. Connection draining and graceful shutdown are important during scaling and deployment.

An API gateway is an application-facing control point for APIs. It may provide authentication integration, rate limiting, request transformation, quotas, version routing, logging, and developer-oriented publication. It is particularly valuable where many clients and independently managed services require consistent API policies. It should not be used to conceal poorly designed service boundaries or to place excessive business logic in an infrastructure component.

A content delivery network caches and serves content from geographically distributed edge locations. CDNs reduce latency for static assets and can absorb large volumes of requests before they reach the origin. Cache keys, invalidation, compression, content security headers, and protection of the origin are essential design concerns. Dynamic or personalised responses require careful cache-control policies to prevent data leakage.

Web Application Firewalls and Application Protection

A WAF examines HTTP requests and can detect or block patterns associated with attacks such as SQL injection, cross-site scripting, protocol abuse, and automated exploitation. Managed rule sets are useful starting points, but they generate false positives and require tuning. Rules should be deployed in monitoring mode before enforcement where operationally appropriate, with exceptions documented and reviewed.

A WAF does not replace secure coding, input validation, authentication, authorisation, patching, or network controls. Rate-based rules and bot-management functions can reduce abuse, while logs should be correlated with application traces and identity information. Privacy principles require that request logs do not unnecessarily retain passwords, tokens, personal data, or sensitive query parameters.

Zero-Trust Access Patterns

Zero trust rejects the assumption that network location establishes trust. Access is granted after evaluating identity, device or workload posture, requested resource, context, and policy. The practical implications are significant: private network placement is helpful but does not replace authentication; internal traffic should be authorised; administrative access should be short-lived and auditable; and services should use workload identities rather than shared secrets.

A zero-trust architecture commonly combines identity-aware proxies, single sign-on, multifactor authentication, just-in-time privilege, micro-segmentation, mutual TLS, central policy enforcement, and continuous logging. For human administrators, a managed access service or bastion with identity integration is preferable to exposing management ports to the internet. For services, service accounts or managed identities should receive only the permissions required for a defined task.

Zero trust is a risk-management approach rather than a product. Excessive authentication prompts, poorly designed policy dependencies, or unavailable identity services can impair operations. Resilience, emergency access, and recovery procedures must therefore be included in the design.

A Reference Design Method

A disciplined design process begins with requirements. Identify users, services, data classifications, regulatory obligations, expected traffic, availability targets, recovery objectives, and administrative workflows. Then create a communication matrix showing legitimate source-destination flows, protocols, data sensitivity, and expected volume.

Next, allocate non-overlapping address ranges and map subnets across availability zones. Decide which components require public access, which require private access, and which cloud services can be reached through private endpoints. Define route tables and firewall policies together, then validate that every required flow has both a path and permission.

The delivery path should normally be layered: DNS directs clients to a CDN, WAF, public load balancer, or API gateway; the delivery layer reaches private application targets; applications reach private data services. Add authentication and authorisation at the application layer. Finally, define observability: flow logs, DNS query logs, firewall logs, load-balancer access logs, WAF events, metrics, traces, and alerts.

Infrastructure as code should create networks, routes, policies, and delivery services consistently across environments. Policy-as-code tools can detect public storage, unrestricted management ports, excessive CIDR ranges, or missing encryption. Change approval should consider blast radius and provide tested rollback procedures.

Illustrative Case Study: A Multi-Region Learning Platform

Background

A fictional organisation, LearnSphere, operates a postgraduate learning platform. Its web application includes a browser interface, API services, video metadata, payment integration, and a relational database. Students access the system globally, while administrators require secure access from corporate offices.

Situation and Problem

The original deployment placed application servers and the database in one cloud region. The database had a public address restricted by a small allow-list, administrative SSH access was open from several office ranges, and static assets were served directly from application instances. During a traffic surge, response times increased and a deployment caused intermittent downtime. Security review also found inconsistent firewall rules and insufficient central logging.

Analysis

The principal issues were architectural rather than merely capacity-related. The single-region design created a major availability dependency. Direct public exposure of the database increased attack surface. Serving static content through application servers consumed compute capacity. The absence of a communication matrix made firewall rules broad and difficult to review. Administrative access depended on network location rather than user identity.

Approach and Solution

LearnSphere allocated non-overlapping network ranges for two regions and created public subnets for redundant load-balancer endpoints and private subnets for application services. Database services were kept private and deployed using the provider’s multi-zone capabilities. A CDN was placed in front of static content and a WAF was attached to the public application entry point.

DNS used health-aware routing for regional failover. Application traffic entered through a layer 7 load balancer, which performed TLS termination, host and path routing, and readiness checks. Private application services accessed the database through narrowly scoped security rules. Private endpoints were used for selected cloud services, while controlled NAT provided necessary outbound access. Corporate connectivity used redundant VPN tunnels, with a private circuit considered for future predictable high-volume traffic.

Administrators used single sign-on, multifactor authentication, short-lived privileges, and an identity-aware management path. Flow logs, WAF logs, load-balancer logs, and application traces were centralised. Infrastructure as code and policy checks were introduced into the deployment pipeline.

Outcome

The revised design separated public delivery from private computation and data, reduced the load on application servers, improved regional recovery options, and made administrative access auditable. The organisation also gained a repeatable method for reviewing new service-to-service connections. The case does not imply that multi-region deployment is always optimal; its cost and operational complexity must be justified by business requirements.

Learning Points

The most important lesson is that resilience and security emerge from the interaction of network topology, delivery services, identity, application behaviour, and operations. Adding a firewall to an otherwise unsuitable architecture would not have solved the underlying problems.

Challenges, Risks, and Common Mistakes

Common errors include overlapping CIDR ranges, placing stateful services in public subnets, permitting 0.0.0.0/0 to management ports, assuming a private subnet is automatically secure, and routing all traffic through a single unmonitored NAT device. Other mistakes include using IP allow-lists as the sole authorisation method, failing to protect the origin behind a CDN, relying on shallow health checks, and forgetting IPv6 firewall rules after enabling dual stack.

Over-segmentation can be as harmful as under-segmentation. Excessive network boundaries create operational friction and encourage emergency exceptions. Conversely, a flat network makes lateral movement easier. Segmentation should correspond to trust boundaries, data sensitivity, failure domains, and operational ownership.

Cloud networking also creates cost risks. NAT processing, inter-region transfer, dedicated circuits, load balancer usage, logging, and CDN egress can become substantial. Cost analysis should be conducted alongside security and performance analysis, not after deployment.

Governance, Ethics, and Professional Responsibility

Network administrators control pathways through which personal, financial, educational, and business data travels. Policies should define data residency, retention, lawful access, incident response, and separation of duties. Access logs must be protected from unauthorised alteration, and monitoring should be proportionate to legitimate security objectives.

Engineers should avoid collecting sensitive request data unnecessarily. WAF and proxy logs can contain personal identifiers, tokens, and user-generated content. Redaction, access controls, retention limits, and secure disposal are therefore professional obligations. Regulatory compliance is not achieved merely by selecting a compliant cloud region; the complete configuration and operating process must satisfy applicable requirements.

Current Developments

Cloud providers increasingly offer managed network firewalls, global traffic managers, private service connectivity, distributed WAFs, and identity-aware application proxies. eBPF-based observability can provide detailed workload visibility in containerised environments. Service meshes add workload identity and encrypted service-to-service communication, although their operational overhead remains significant.

Infrastructure automation is becoming more policy-driven. Security and network policies can be tested before deployment, while anomaly detection can identify unusual flows, sudden egress, or deviations from normal service behaviour. Artificial intelligence may assist with log classification, topology analysis, and policy recommendations, but generated recommendations require human validation because an incorrect rule can cause either an outage or a security breach.

Best-Practice Checklist

A professional cloud network should generally follow these practices:

• Plan non-overlapping address ranges before deployment.
• Distribute critical components across appropriate availability zones.
• Keep databases and internal services private unless a documented requirement says otherwise.
• Separate routing from authorisation and test both independently.
• Apply least privilege to ingress and egress policies.
• Use private endpoints for supported cloud services and monitor NAT usage.
• Provide redundant VPN or private-connectivity paths.
• Use DNS health checks and sensible TTL values.
• Protect public HTTP services with TLS, a WAF, and suitable rate controls.
• Use CDNs for cacheable content and secure the origin.
• Prefer identity-aware, short-lived administrative access.
• Centralise logs, monitor flows, and test failure scenarios.
• Manage networking through reviewed infrastructure as code.
• Evaluate cost, compliance, and operational complexity with every architectural decision.

Chapter Summary

Cloud networking provides the paths, boundaries, and policies through which distributed applications operate. Effective design begins with address planning, availability-zone-aware subnetting, explicit routing, and least-privilege traffic controls. Security groups, ACLs, network firewalls, and WAFs operate at different layers and should be combined deliberately rather than treated as interchangeable.

NAT supports controlled outbound access but does not replace egress governance. VPNs and dedicated private connections support hybrid architectures with different cost, performance, and operational characteristics. DNS enables discovery and traffic steering, while load balancers, API gateways, CDNs, and WAFs form complementary application-delivery layers. Zero trust shifts the focus from network location to verified identity, context, workload authorisation, and continuous observation.

The most reliable designs are requirements-driven, multi-zone where justified, private by default, automated through infrastructure as code, and continuously tested. Networking decisions should be evaluated together with application behaviour, security, resilience, cost, governance, and user experience.

Key Terms

Virtual private cloud: A logically isolated cloud network in which resources communicate through defined routes and controls.

CIDR: A notation for representing an IP network and its prefix length, such as 10.0.0.0/16.

Subnet: A segmented range of IP addresses associated with routing and, commonly, an availability zone.

Route table: A set of destination-prefix rules that determine the next hop for network traffic.

Security group: A usually stateful, workload-level virtual firewall controlling permitted traffic.

Network ACL: A subnet-level access-control list that may evaluate traffic statelessly.

NAT: Network Address Translation, which maps private addresses to another address for communication.

NAT gateway: A managed cloud service that enables controlled outbound connectivity from private resources.

VPN: An encrypted logical connection, commonly established across the public internet.

Private connectivity: A dedicated or provider-mediated private path between networks or services.

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

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

API gateway: A managed entry point that applies policies and controls to application programming interfaces.

CDN: A distributed edge network that caches and serves content close to users.

WAF: A Web Application Firewall that evaluates HTTP requests for application-layer threats.

Zero trust: A security approach that continuously verifies identity, context, and authorisation instead of trusting network location.

Private endpoint: A private network interface or connection used to reach a managed service without public internet routing.

Infrastructure as code: The declarative or programmatic management of infrastructure through version-controlled definitions.

Micro-segmentation: Fine-grained separation and policy enforcement among workloads or services.

Review Questions

Short Answer Questions

1. Why should cloud address ranges be planned before creating multiple networks?

2. Distinguish between a route and a firewall rule.

3. What is the primary purpose of a NAT gateway?

4. How does a CDN improve application delivery?

5. Why is a private subnet not automatically secure?

Long Answer Questions

1. Explain how public, private, and data subnets can be designed across multiple availability zones.

2. Compare security groups, network ACLs, network firewalls, and WAFs by layer and purpose.

3. Discuss the decision factors involved in choosing a VPN, dedicated private connectivity, or both.

4. Explain how DNS, load balancing, API gateways, CDNs, and WAFs can operate as a coordinated delivery architecture.

5. Describe a zero-trust access model for cloud administrators and service-to-service communication.

Analytical / Application Questions

1. An application server in a private subnet cannot access a managed cloud storage service, although its security group permits outbound HTTPS. Analyse the possible routing, endpoint, DNS, and policy causes.

2. Design a network and application-delivery architecture for a globally accessed e-commerce API with private databases, regional failure requirements, and administrative access for a distributed operations team. Justify your choices.

3. A company proposes routing every region through one central NAT gateway to reduce cost. Evaluate the proposal in terms of resilience, latency, security, traffic capacity, and cost, and recommend a decision framework.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes the relationship between a route and a firewall rule?

A. A route permits traffic, while a firewall rule selects the next hop

B. A route determines a path, while a firewall rule permits or denies traffic

C. A route encrypts traffic, while a firewall rule translates addresses

D. A route applies only to HTTP, while a firewall rule applies only to databases

Correct Answer: B. A route determines a path, while a firewall rule permits or denies traffic

Question 2

A private application subnet needs controlled outbound access to download updates but must not accept unsolicited internet connections. Which design is most appropriate?

A. Assign public IP addresses to all application instances

B. Permit inbound SSH from 0.0.0.0/0

C. Route outbound traffic through a NAT gateway and restrict egress policies

D. Place the database in a public subnet

Correct Answer: C. Route outbound traffic through a NAT gateway and restrict egress policies

Question 3

Which component is specifically designed to inspect HTTP requests for threats such as SQL injection and cross-site scripting?

A. Web application firewall

B. NAT gateway

C. Route table

D. VPN tunnel

Correct Answer: A. Web application firewall

Question 4

Why are non-overlapping CIDR ranges important in hybrid cloud networking?

A. They increase CDN cache duration

B. They prevent all application-layer attacks

C. They simplify routing, peering, and VPN connectivity

D. They eliminate the need for DNS

Correct Answer: C. They simplify routing, peering, and VPN connectivity

Question 5

An organisation wants users in different regions to be directed to the lowest-latency healthy application endpoint. Which combination is most relevant?

A. DNS traffic steering and health checks

B. A subnet ACL and a database index

C. NAT and object lifecycle policies

D. A bastion host and a static route only

Correct Answer: A. DNS traffic steering and health checks

Question 6

Which practice best reflects zero-trust networking?

A. Trust every service inside the VPC

B. Allow internal traffic without authentication

C. Grant access based on verified identity, context, and least privilege

D. Replace all application authorisation with IP allow-lists

Correct Answer: C. Grant access based on verified identity, context, and least privilege

Question 7

What is a significant limitation of a shallow load-balancer health check that tests only whether a port is open?

A. It may direct traffic to an instance that is alive but unable to serve requests

B. It always prevents autoscaling

C. It disables TLS termination

D. It forces databases to become public

Correct Answer: A. It may direct traffic to an instance that is alive but unable to serve requests

Question 8

Which statement about a dedicated private connection is accurate?

A. It always provides encryption without additional controls

B. It can offer more predictable performance but requires planning and may cost more

C. It can connect only public subnets

D. It eliminates the need for routing policies

Correct Answer: B. It can offer more predictable performance but requires planning and may cost more

Question 9

A CDN is serving personalised account pages from cache to the wrong users. Which design issue is most likely?

A. An overly broad cache key or incorrect cache-control policy

B. An insufficient number of private subnets

C. A missing NAT gateway for database traffic

D. A lack of IPv4 address translation on the client

Correct Answer: A. An overly broad cache key or incorrect cache-control policy

Question 10

Which approach best supports auditable administrative access to private cloud workloads?

A. Expose SSH directly to the internet with a shared password

B. Use identity-aware access, multifactor authentication, and short-lived privileges

C. Permit all corporate IP ranges permanently

D. Disable logging to reduce operational cost

Correct Answer: B. Use identity-aware access, multifactor authentication, and short-lived privileges