Cloud Networking and Connectivity

Introduction

Cloud applications are not isolated compute instances. They are distributed systems whose reliability, security, performance and cost depend heavily on network design. In Amazon Web Services (AWS), the central networking construct is the Virtual Private Cloud (VPC). In Google Cloud, the corresponding construct is the Virtual Private Cloud (VPC) network. Although the names are similar, the implementation models differ: AWS VPCs are regional and contain subnets tied to Availability Zones, whereas Google Cloud VPC networks are global and their subnets are regional.

A DevOps professional must therefore be able to design address spaces, segment workloads, control routes and traffic, publish services safely, resolve names, connect private networks and diagnose failures. This chapter develops those capabilities for AWS and Google Cloud, while emphasizing transferable networking principles rather than memorization of product screens.

Learning Objectives

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

• design VPCs, subnets and IP address plans;
• distinguish public, private and isolated subnet patterns;
• explain route tables, internet gateways, NAT and load balancers;
• compare AWS security groups and network ACLs with Google Cloud firewall rules;
• design DNS, VPN and private service connectivity;
• troubleshoot network access systematically;
• plan a secure hybrid-cloud environment; and
• evaluate availability, security, operational and cost trade-offs.

1. Networking Foundations for Cloud Environments

A network provides addressing, forwarding and policy enforcement. Four layers are especially important in cloud deployment:

1. Addressing: IP addresses identify interfaces or endpoints. IPv4 addresses contain 32 bits; IPv6 addresses contain 128 bits.
2. Forwarding: Routers select a next hop using the most specific matching route.
3. Security policy: Firewalls determine whether traffic is permitted.
4. Name resolution: DNS maps human-readable names to addresses or service endpoints.

Cloud networking is software-defined. A provider operates the physical fabric, while customers configure logical networks, routes, policies and endpoints through APIs. This enables automation but also makes incorrect configuration easy to reproduce. Infrastructure as Code should therefore be used for important network resources.

Address planning and CIDR

CIDR notation represents a network prefix and prefix length, such as 10.20.0.0/16. The prefix length specifies how many leading bits identify the network. For an IPv4 network with prefix length p, the number of addresses is:

where N is the total number of IPv4 addresses. This includes addresses that may be reserved by a platform or protocol, so usable addresses can be fewer. For example, a /24 contains 2^(32−24) = 256 addresses. A /20 contains 4,096 addresses.

The formula assumes a conventional IPv4 CIDR block and does not by itself account for provider reservations, broadcast behavior, secondary addresses or future subnet requirements. Avoid overlapping CIDR ranges when networks may later be connected through VPN, peering or dedicated links. A practical plan reserves space for growth, management, shared services and multiple environments.

A typical plan might allocate 10.20.0.0/16 to production, dividing it into regional or availability-zone subnets such as 10.20.1.0/24, 10.20.2.0/24 and 10.20.3.0/24. Development and testing should use distinct ranges, for example 10.30.0.0/16 and 10.40.0.0/16.

2. VPC and Subnet Architecture

A VPC is a logically isolated network in a cloud account or project. It normally contains subnets, route tables, firewall policies and connectivity attachments.

Public, private and isolated subnets

A subnet is not inherently public or private. It becomes practically public when resources have a route to an internet gateway and are assigned reachable public addresses. A private subnet may have outbound access through NAT but no direct inbound route from the internet. An isolated subnet has neither direct internet access nor a NAT path and is suitable for databases and sensitive internal services.

A common three-tier design is:

• Public subnets: internet-facing load balancers, bastion alternatives and edge components.
• Private application subnets: application servers, containers and internal APIs.
• Private data subnets: databases, caches and queues with tightly restricted access.

Production workloads should normally span at least two Availability Zones in AWS, or multiple zones within a Google Cloud region, to reduce the effect of a zone failure. Subnet placement, however, is not a security boundary by itself; firewall rules and identity-aware controls remain essential.

Figure: A layered VPC design separates internet-facing, application and data workloads.

AWS and Google Cloud differences

These are conceptual comparisons, not claims that the services are identical. Provider documentation should be consulted for limits, supported protocols and regional availability.

3. Routing and Internet Connectivity

A route table contains destination prefixes and targets. When a packet is sent, the forwarding system selects the most specific matching route. For example, a route to 10.20.0.0/16 is less specific than one to 10.20.5.0/24; traffic matching both uses the /24 route.

An internet-facing architecture commonly requires:

1. a subnet route to the local VPC network;
2. a default route, 0.0.0.0/0, to an internet gateway;
3. a public address or load-balancer address; and
4. firewall rules allowing only required inbound and outbound traffic.

An internet gateway is a logical attachment that permits internet routing when addressing and policy requirements are satisfied. It does not automatically make every instance public.

NAT

Network Address Translation allows private resources to initiate outbound connections using a shared public address. A NAT gateway or equivalent managed service generally supports outbound updates and external API calls while preventing unsolicited inbound connections. NAT is not a complete security control: an allowed private workload can still make harmful outbound connections, and firewall, egress filtering, logging and identity controls remain necessary.

NAT gateways are commonly deployed per zone or in a highly available pattern. Centralizing NAT can reduce duplicate resources but may create cross-zone traffic, a dependency bottleneck and a larger failure domain. IPv6 designs often use direct globally routable addresses with restrictive egress controls rather than IPv4-style NAT; the exact provider mechanism must be selected deliberately.

Load balancing

A load balancer provides a stable service endpoint and distributes traffic among healthy targets. It can terminate TLS, perform health checks, route by host or path and reduce direct exposure of application nodes. Common categories include:

• Layer 4: TCP or UDP forwarding with limited application awareness.
• Layer 7: HTTP or HTTPS routing using host, path, header and application-level information.
• Internal load balancing: private access for services within a VPC or connected network.
• External load balancing: public access for internet clients.

Health checks must test meaningful service readiness rather than merely whether a process is listening. Security rules should permit the load balancer to reach the application, while clients should not directly reach application instances unless required.

4. Cloud Firewalls and Security Groups

Security controls should be layered and least-privilege. A rule should specify source, destination, protocol, port and purpose. Avoid allowing 0.0.0.0/0 to administrative ports such as SSH or RDP. Prefer private administration, identity-aware access, short-lived credentials and audited session mechanisms.

AWS controls

An AWS security group is a stateful virtual firewall attached to interfaces. Return traffic for an allowed connection is automatically permitted, so explicit reverse-direction rules are normally unnecessary. Security groups are allow-oriented: traffic not allowed by an applicable rule is denied.

Network ACLs operate at subnet boundaries and are stateless. Both inbound and outbound directions must be considered, including ephemeral return ports. ACLs can provide coarse subnet-level protection, but overly complex ACLs are difficult to operate. Security groups should usually provide workload-level policy, with ACLs as an additional boundary where justified.

Google Cloud controls

Google Cloud VPC firewall rules are applied to eligible network interfaces and can be selected by network tags or service accounts, depending on the design. Rules are stateful and support priorities, direction, source or target selection and logging options. A deny rule with higher precedence can override a lower-priority allow. Google Cloud also provides hierarchical firewall policies for organization- or folder-level governance.

Firewall rules should be managed as code, reviewed like application code and accompanied by ownership, expiry or justification metadata. Logging should be enabled selectively because broad logging can increase cost and noise.

5. DNS and Service Discovery

DNS translates names into records such as A or AAAA addresses, CNAME aliases, MX mail destinations and TXT policy data. Public DNS zones serve internet clients; private DNS zones resolve names only from associated networks or connected environments.

Cloud DNS services support authoritative zones, private resolution and often forwarding or peering. A robust design separates:

• public names, such as api.example.com, which resolve to public load balancers; and
• private names, such as db.prod.internal, which resolve to internal endpoints.

DNS is cached according to the time to live (TTL). A shorter TTL can accelerate change propagation but increases query traffic and dependence on authoritative infrastructure. DNS is not a substitute for authorization: resolving a private name does not prove that a caller should connect.

Service discovery for microservices may use private DNS, provider registries or an orchestration platform. Names should represent stable services rather than ephemeral instance addresses.

6. Private Connectivity and Hybrid Environments

Hybrid networking connects cloud resources to on-premises data centres, branch offices or another cloud. The principal choices are:

• Site-to-site VPN: encrypted tunnels over the public internet; relatively rapid and economical, but performance depends on internet paths.
• Dedicated private connection: provider or carrier connectivity with more predictable performance and potentially higher cost and provisioning time.
• Peering: private routing between networks; often non-transitive, meaning a peered network cannot automatically act as a transit router.
• Transit hub: a central routing service for multiple VPCs, regions or sites; simplifies topology but creates cost and governance considerations.
• Private service endpoints: access to a provider or partner service without exposing traffic to the public internet.

High availability requires redundant tunnels, devices, circuits and routing paths. Border Gateway Protocol (BGP) may dynamically exchange routes over supported VPN or dedicated connections. Static routes are simpler but require manual changes during topology evolution. Route summarization reduces table size but must not hide required destinations.

Hybrid designs should document address ownership, route propagation, encryption, latency expectations, failure behavior, DNS forwarding, data classification and operational responsibility. Overlapping ranges are a frequent cause of failed connectivity; remediation may require renumbering, NAT or application-level proxies.

7. A Systematic Troubleshooting Method

Network troubleshooting should proceed from the simplest layer to the most complex rather than changing multiple settings at once.

1. Clarify the flow: identify source, destination, protocol, port, direction, expected response and whether the path is public or private.
2. Verify name resolution: use tools such as dig or nslookup; compare returned addresses with the intended endpoint.
3. Check addressing: confirm interface addresses, subnet membership, public or private address allocation and overlapping CIDRs.
4. Inspect routes: verify local, default, NAT, peering, VPN or transit routes in both directions.
5. Inspect policy: check security groups, ACLs, cloud firewall rules, host firewalls and load-balancer listeners.
6. Check service health: confirm that the process listens on the expected interface and port and that health checks succeed.
7. Measure the path: use flow logs, reachability analyzers, traceroute where meaningful, packet capture where permitted, and load-balancer logs.
8. Test from the correct location: a public client, private instance and VPN-connected host may legitimately receive different results.

Typical symptoms can be mapped to likely causes. A DNS failure suggests zone, record, delegation or resolver issues. A timeout often indicates routing or filtering. An immediate connection refusal commonly indicates that the destination is reachable but no service is listening or a host firewall rejected it. A successful TCP connection followed by an HTTP error shifts attention to TLS, authentication, application routing or backend health.

8. Worked Design Example

An organization needs a production web application in AWS with two Availability Zones. It requires public HTTPS access, private application servers, a private database and outbound software updates.

The design allocates 10.20.0.0/16. It creates two public /24 subnets, two private application /24 subnets and two data /24 subnets, leaving substantial space for growth. A public Application Load Balancer is placed in the public subnets. Application instances are placed in private subnets and accept TCP 8080 only from the load balancer security group. The database accepts its database port only from the application security group.

Each public subnet routes 0.0.0.0/0 to an internet gateway. Each private application subnet routes its default traffic to a NAT gateway located in the corresponding public zone. Data subnets have no default internet route. The database is therefore not dependent on internet access for normal operation. DNS publishes app.example.com to the load balancer, while database discovery uses a private zone.

The design improves availability by distributing the load balancer and application targets across zones. It reduces exposure by avoiding public addresses on application and database instances. Its trade-offs include NAT cost, additional route tables and the need to maintain zone-level capacity. If the application needs cloud object storage, provider-specific private endpoints may reduce NAT traffic and improve control.

9. Illustrative Case: Hybrid Retail Platform

Background. A fictional retailer operates an on-premises inventory system and is moving its customer-facing API to Google Cloud. The API must read inventory privately, while customers access it over HTTPS.

Problem. The initial deployment used overlapping 10.0.0.0/8 ranges in both environments. A VPN tunnel appeared established, but traffic to inventory followed ambiguous routes and failed intermittently.

Analysis. Engineers documented the full source-to-destination flow, inspected route advertisements and used flow logs. They found both networks claimed the same destinations. They also discovered that the API firewall allowed health-check traffic but not the inventory port.

Approach. The team assigned the cloud VPC 10.60.0.0/16, reserved regional subnets, replaced broad firewall rules with service-account-targeted rules and established two VPN tunnels with dynamic routing. Private DNS forwarding was configured so cloud services could resolve the inventory name without publishing it. The public API was placed behind an external HTTPS load balancer; application instances remained private.

Outcome. Inventory traffic used the VPN, customer traffic used the load balancer, and health checks reflected actual application readiness. Monitoring was added for tunnel state, route changes, firewall denies, latency and API error rates.

Learning points. Connectivity is a combination of addressing, routing, policy, DNS and application behavior. A tunnel being “up” does not prove that a particular application flow works. Hybrid designs should be planned before deployment, with non-overlapping ranges and tested failure scenarios.

10. Governance, Security and Contemporary Practice

Network governance should define who may create VPCs, allocate addresses, approve public exposure and modify routes. Centralized logging, configuration drift detection, policy-as-code and change review support accountability. Network flow logs may contain sensitive metadata and therefore require retention, access-control and privacy decisions.

Regulated workloads may require encryption in transit, evidence of access control, data-location restrictions and documented incident response. VPN encryption protects traffic in transit but does not replace endpoint authentication or application authorization. Zero-trust approaches treat network location as insufficient evidence of trust and combine identity, device posture, service identity and continuously evaluated policy.

Infrastructure as Code enables repeatability, peer review and automated validation. Useful automated checks include CIDR overlap detection, prohibition of unrestricted administrative ports, required flow logging, encryption requirements and confirmation that production databases lack public addresses. AI-assisted operations can summarize flow logs or suggest likely causes, but recommendations must be validated against authoritative configuration and least-privilege principles. Sensitive logs should not be sent to unapproved external systems.

Chapter Summary

Cloud networking combines IP addressing, subnets, routing, security policy, DNS and service endpoints. AWS VPCs are regional, while Google Cloud VPC networks are global with regional subnets. Public, private and isolated subnet patterns reduce exposure when supported by precise firewall rules. Internet gateways provide public routing; NAT supports controlled outbound IPv4 access. Load balancers provide stable endpoints, health checks and traffic distribution. Security groups and cloud firewall rules are generally stateful, while AWS network ACLs are stateless. DNS supports public naming, private resolution and service discovery but is not an authorization mechanism. VPNs, dedicated connections, peering, transit hubs and private endpoints enable hybrid and private connectivity. Effective troubleshooting follows the complete flow from DNS and addressing through routes, policy and service health. Sound designs emphasize non-overlapping address spaces, least privilege, redundancy, observability, automation and documented governance.

Key Terms

VPC: A logically isolated virtual network in a cloud environment.

CIDR: A notation describing an IP network prefix and prefix length.

Subnet: A defined portion of a network address range.

Availability Zone: An isolated failure domain within a cloud region.

Route table: A collection of destination prefixes and forwarding targets.

Internet gateway: A logical component enabling eligible public internet traffic.

NAT: Translation that allows private resources to initiate connections using another address.

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

Security group: A stateful, interface-level AWS firewall.

Network ACL: A stateless, subnet-level AWS traffic filter.

Firewall rule: A policy controlling permitted or denied network traffic.

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

Private DNS: Name resolution restricted to selected networks or clients.

VPN: An encrypted logical connection over another network.

Peering: Private connectivity between networks, often with non-transitive routing.

BGP: A routing protocol used to exchange reachability information dynamically.

Flow log: A record of network flow metadata used for monitoring and diagnosis.

Zero trust: A security model that does not grant trust solely from network location.

Review Questions

Short Answer Questions

1. Why does a subnet not automatically become public merely because it belongs to a VPC?
2. What is the difference between an internet gateway and NAT?
3. Why should production applications normally span multiple failure zones?
4. What makes an AWS network ACL different from a security group?
5. Why are overlapping CIDR ranges problematic in hybrid networking?

Long Answer Questions

1. Explain a three-tier cloud network design and the security purpose of each tier.
2. Compare AWS VPC networking with Google Cloud VPC networking, including scope, subnets and firewall models.
3. Describe how DNS, load balancing and private application subnets work together in a secure web application.
4. Compare VPN, dedicated connectivity, peering and transit-hub approaches for hybrid networking.
5. Develop a systematic troubleshooting procedure for an application that cannot reach a private database.

Analytical / Application Questions

1. Design an address plan for two production zones, development, testing and shared services. State how you would prevent future CIDR overlap.
2. A private application can resolve an external API name but receives timeouts when connecting. Analyze at least five possible causes in the order you would test them.
3. Evaluate the trade-offs of deploying one centralized NAT gateway versus one NAT gateway per Availability Zone, considering resilience, cost and operational complexity.

Multiple Choice Questions with Answers

Question 1

Which condition most directly makes a subnet practically public?

A. It contains a database instance

B. It has a route to an internet gateway and eligible public addressing

C. It uses a private CIDR block

D. It is located in a second Availability Zone

Correct Answer: B. It has a route to an internet gateway and eligible public addressing

Question 2

How many IPv4 addresses are represented by a /20 CIDR block before provider-specific reservations?

A. 256

B. 1,024

C. 4,096

D. 65,536

Correct Answer: C. 4,096

Question 3

What is the primary purpose of NAT for a private subnet?

A. To allow unsolicited inbound internet connections

B. To provide controlled outbound connectivity using another address

C. To replace all firewall rules

D. To perform DNS name resolution

Correct Answer: B. To provide controlled outbound connectivity using another address

Question 4

Which AWS control is stateful and attached to network interfaces?

A. Network ACL

B. Security group

C. Route table

D. Internet gateway

Correct Answer: B. Security group

Question 5

What happens when two routes match a packet destination?

A. The route with the least specific prefix is always selected

B. Both routes are always used simultaneously

C. The most specific matching route is selected

D. The packet is automatically encrypted

Correct Answer: C. The most specific matching route is selected

Question 6

Which DNS zone is intended to resolve names only for associated private networks?

A. Public authoritative zone

B. Private DNS zone

C. Root zone

D. MX zone

Correct Answer: B. Private DNS zone

Question 7

What is a major advantage of a load balancer health check?

A. It permanently replaces application monitoring

B. It directs traffic toward targets that pass a defined readiness test

C. It automatically removes all firewall restrictions

D. It guarantees zero application errors

Correct Answer: B. It directs traffic toward targets that pass a defined readiness test

Question 8

Which hybrid connectivity option normally uses encrypted tunnels over the public internet?

A. Site-to-site VPN

B. Private DNS

C. Subnet routing

D. Application security group

Correct Answer: A. Site-to-site VPN

Question 9

Why are overlapping CIDR ranges dangerous when connecting networks?

A. They prevent TLS certificates from being issued

B. They create ambiguity in route selection and destination ownership

C. They increase DNS TTL values

D. They disable load-balancer health checks

Correct Answer: B. They create ambiguity in route selection and destination ownership

Question 10

A TCP connection is immediately refused rather than timing out. Which explanation is most likely?

A. The destination is reachable but no service is listening on that port

B. The DNS root servers are unavailable

C. The CIDR prefix is necessarily too large

D. The route must be using BGP

Correct Answer: A. The destination is reachable but no service is listening on that port