Contents and search
Introduction to Cloud Computing

Chapter 3 · Part I · Orientation and foundations

Networking Foundations for Cloud Applications

Read Cloud Computing: A Concrete System Map and Computing Before the Public Cloud, or know that browser requests and provider management requests follow different paths. You should recognize an Internet Protocol (IP) address and a web Unifo

Approximately 3,370 words · 15 minute read

Prerequisites

Read Cloud Computing: A Concrete System Map and Computing Before the Public Cloud, or know that browser requests and provider management requests follow different paths. You should recognize an Internet Protocol (IP) address and a web Uniform Resource Locator (URL). Advanced routing knowledge is not required.

Learning outcomes

After this lesson, you will be able to:

  • follow a cloud request through name resolution, routing, transport, encryption, Hypertext Transfer Protocol (HTTP), traffic distribution, and application handling;
  • read a Classless Inter-Domain Routing (CIDR) prefix and calculate its address count;
  • distinguish a subnet route from a traffic-authorization rule;
  • decompose client timing evidence without adding cumulative fields incorrectly;
  • design a controlled network investigation with a rejectable explanation; and
  • account for Domain Name System caching, Hypertext Transfer Protocol version 3 (HTTP/3), overlapping addresses, request limits, and other important exceptions.

Opening concrete narrative: a slow registration request

At 8:00:01 on registration morning, CampusCart receives a burst of purchases. The bookstore application serves about 5,000 daily users, normally completes 80 application programming interface (API) requests per second, and can receive 400 requests per second at this peak. A student in a campus residence sees a 2.4-second delay before the first response byte. Another student on a wired laboratory computer receives the same page in 180 milliseconds.

The on-call engineer cannot act on “the network is slow.” The student's browser first converts campuscart.example into connection information. Packets leave the laptop, cross the campus network and an Internet provider, reach a cloud traffic distributor, and then cross a virtual cloud network to an API program. The API can wait for a PostgreSQL query before producing a response. Several independently operated queues and programs contribute time.

CivicPermit adds a stricter constraint. Permit submissions contain personally identifiable information (PII), and the application must retain audit evidence. A network packet capture can itself contain names, tokens, or document content. The operator must use synthetic data, restrict capture access, and collect only the bytes or metadata necessary for the question.

The investigation begins by naming every communication endpoint and every artifact producer.

Observable evidence along the path

A Domain Name System (DNS) resolver produces an answer containing resource records, such as an A record for an Internet Protocol version 4 (IPv4) address or an AAAA record for an Internet Protocol version 6 (IPv6) address. dig displays the resolver response it receives. An answer establishes the returned name data and time-to-live field; the answer does not establish which destination a browser ultimately used or which physical machine accepted the request.

curl produces client-side timing fields. time_namelookup ends after name lookup, time_connect ends after the selected transport connection, time_appconnect ends after a security handshake where applicable, time_starttransfer ends when the first response byte arrives, and time_total ends when transfer finishes. Each value is cumulative from the beginning of the operation. The fields must be subtracted to estimate separate phases.

A packet-capture program such as tcpdump records packets visible at the capture interface. The operating-system capture clock timestamps each observed packet. A capture on the laptop cannot directly establish packets on the load balancer-to-API connection because the load balancer terminates one connection and creates another. Encryption also hides HTTP content from an ordinary network capture while leaving some sizes, timing, and addressing visible.

A cloud flow-log facility can produce metadata for accepted or rejected traffic at selected virtual network interfaces. Exact fields and sampling behavior depend on the provider and configuration. A load-balancer access log can identify the selected target and target-response timing. An API log can identify application work. PostgreSQL evidence can identify a query or committed transaction. Correlation requires a safe request identifier because separate clocks can be offset.

Mechanism: from a name to an application response

Name resolution

The browser asks a resolver for information about the requested name. The resolver can answer from a cache while the record's time to live remains valid, or it can query other DNS servers. DNS separates a stable application name from changeable connection addresses. A low time to live can shorten some cache retention, but resolvers and clients still have implementation behavior and in-flight connections.

Addressing and forwarding

An IP address identifies an interface for packet delivery within an addressing context. A router examines a destination address and selects a matching route. CIDR notation writes an address plus the number of leading prefix bits. The IPv4 prefix 10.20.4.0/24 fixes 24 of 32 address bits and leaves eight variable bits, so the block contains 2^8 = 256 addresses. Cloud providers reserve some addresses in many subnet products; 256 is the mathematical block size, not necessarily the assignable host count.

A subnet is an address prefix attached to a defined network placement. In Amazon Web Services (AWS), for example, a subnet belongs to one Availability Zone and associates with a route table. A route table contains destination prefixes and next-hop targets. When several routes match, IP forwarding normally uses the longest matching prefix. A default IPv4 route, 0.0.0.0/0, matches every IPv4 destination but loses to any more-specific route.

A route says where matching packets should go. A security group or provider firewall rule says which traffic is authorized at a protected interface or workload. AWS security groups are stateful, while AWS network access control lists have different stateless rule behavior. Google Cloud virtual-network firewall rules and Azure network security groups have their own scopes and defaults. Product names do not erase the distinction between forwarding and authorization.

Transport, encryption, and HTTP

Transmission Control Protocol (TCP) uses sequence numbers, acknowledgments, retransmission, and flow control to present an ordered byte stream between two endpoints. A port number helps the receiving host select a listening program. User Datagram Protocol (UDP) presents datagrams without TCP's ordered byte-stream mechanism.

Transport Layer Security (TLS) authenticates the server under the chosen certificate and parameters, establishes keys, and protects later application bytes for confidentiality and integrity. As of July 20, 2026, Request for Comments (RFC) 9846 is the current TLS 1.3 specification and obsoletes RFC 8446. RFC 9846 retains the TLS 1.3 version number and is backward compatible with RFC 8446, while tightening requirements and clarifying the earlier text. A successful TLS handshake authenticates the presented identity under the client's trust rules; the handshake does not prove that the application is authorized to release a permit.

Hypertext Transfer Protocol (HTTP) defines request methods, target identifiers, fields, content, and response status semantics. HTTP/1.1 and HTTP/2 commonly operate over TCP with TLS for an https URL. HTTP/3 operates over QUIC, which uses UDP, so the https scheme does not guarantee TCP port 443. A traffic distributor can terminate the client connection and use a different HTTP version or protection arrangement on the API side.

The uppercase label HTTPS names HTTP carried with TLS under the https URL scheme. HTTPS protects the connection under the negotiated TLS properties; the label does not specify one HTTP version or one transport protocol.

Traffic distribution and private paths

The public traffic distributor checks target health and selects an API destination according to configured behavior. A private API address need not be reachable from the public Internet. The traffic distributor can have public reachability on one side and private virtual-network reachability on the other.

CampusCart's API opens a separate connection to PostgreSQL. A database subnet route, name, port rule, database authentication rule, and TLS configuration can all affect that connection. A browser cannot infer those server-side conditions from the public address alone.

Technical terms in context: configured communication boundaries

An endpoint is one named side of a communication, such as the browser address and port or the traffic distributor address and port. A network flow is a set of packets grouped by identifiers such as source address, destination address, transport protocol, and ports. Provider flow logs summarize selected flow metadata; they are delayed or sampled under some products and are not packet captures.

A virtual private cloud (VPC) is a provider network object with configured addressing, routing, and policy. Provider scope differs: an AWS VPC is regional and contains zonal subnets, a Google Cloud VPC is global with regional subnets that span zones, and an Azure Virtual Network is regional with subnets that span zones. A generic architecture diagram must therefore state the provider before a “subnet per zone” claim.

A load balancer is a traffic distributor that selects among eligible destinations. Layer 4 and Layer 7 products observe different protocol information, and one provider can offer several products under a load-balancing portfolio. A private address is not globally routed on the public Internet under the relevant address rules; private addressing does not encrypt or authorize traffic.

Working model: a lower-bound latency budget

Let each timing quantity use milliseconds. For a fresh HTTPS operation over TCP and TLS 1.3, a useful approximate decomposition is:

T_total = T_DNS + T_TCP + T_TLS + T_server_wait + T_transfer

The terms represent elapsed time, not packet counts. A sample curl run reports these cumulative values:

| Cumulative field | Value | |---|---:| | name lookup | 0.012 s | | TCP connect | 0.032 s | | TLS complete | 0.055 s | | first byte | 0.133 s | | total | 0.140 s |

Convert each field to milliseconds and subtract adjacent endpoints:

  • T_DNS = 12 ms
  • T_TCP = 32 - 12 = 20 ms
  • T_TLS = 55 - 32 = 23 ms
  • T_server_wait = 133 - 55 = 78 ms
  • T_transfer = 140 - 133 = 7 ms

The sum is 12 + 20 + 23 + 78 + 7 = 140 ms.

The model assumes a fresh connection, one chosen address, no proxy timing hidden before curl, and a response small enough that transfer is simple. T_server_wait includes travel to the server, traffic-distributor work, API work, database work, and travel of the first response byte. The field is not “application processor time.” Connection reuse can make TCP and TLS setup disappear from a later request. HTTP/3 has different transport setup. Parallel address attempts, redirects, DNS-over-HTTPS, radio scheduling, packet loss, and congestion can change the phases.

Bandwidth and latency also name different quantities. Network throughput is delivered bits divided by the observation interval, measured in bits per second. A 1-megabyte response contains approximately 8 megabits when “megabyte” means 1,000,000 bytes. At an achieved 20 megabits per second, its ideal serialization time is 8 megabits ÷ 20 megabits/second = 0.4 seconds. Round-trip latency affects handshakes, acknowledgments, and request-response dependencies even when the link can carry many bits per second.

Empirical test: decompose a real request

Run the following command against the reserved documentation site. Preserve at least ten output rows.

curl -V
for n in 1 2 3 4 5 6 7 8 9 10; do
  curl -sS -o /dev/null \
    -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total} ip=%{remote_ip} code=%{http_code}\n' \
    https://example.com/
done

Keep the target, client machine, and network access constant. Vary only the repetition number. Preserve curl -V because supported HTTP versions depend on the client build. Compute the five phase increments for each row. Record whether the remote address changes. The expected evidence may show a shorter cached DNS phase after the first operation. Each curl invocation can still create a new connection, so the experiment does not test browser connection reuse.

The explanation “DNS dominates the delay” is rejected for a row where DNS contributes 2 milliseconds to a 500-millisecond total. The evidence cannot identify the remaining cause by itself. A slow first-byte increment can reflect API work, database waiting, proxy queueing, packet loss, or distant routing. Run a controlled server-side correlation before assigning responsibility.

Optional traceroute or tracert output can reveal replies from some routing hops. A missing hop reply does not establish a broken path because routers can forward application traffic without answering diagnostic probes. A returned hop name does not establish physical location.

Worked investigation: why do large CivicPermit uploads fail?

Initial question

Why does a 2-mebibyte synthetic Portable Document Format (PDF) upload succeed while a 12-mebibyte synthetic PDF upload fails? One mebibyte (MiB) is 1,048,576 bytes.

Operating conditions

The staging CivicPermit endpoint uses the production-like traffic distributor, two API instances in separate availability zones, and synthetic documents with no PII. The client uses one wired host and the same authentication role. Operators perform five 2 MiB uploads and five 12 MiB uploads. The configured edge request limit is believed to be 10 MiB.

Evidence collected

curl verbose output shows TLS completion for every operation. Each 2 MiB upload returns 201 after about 600 milliseconds. Each 12 MiB upload returns HTTP 413 after about 45 milliseconds. Traffic-distributor access logs contain all ten request identifiers and identify the distributor as the response producer for the 413 entries. API logs contain only the five small-upload identifiers. Packet counters show transmitted bytes, but no repeated retransmission pattern is present in the client capture.

Interpretation

HTTP 413 means that the responding HTTP intermediary or origin rejected the request content as too large under its policy. The absence of large-upload identifiers from API logs, combined with distributor-generated 413 entries, places the rejection before the API program. The fast, repeatable response contradicts a simple packet-loss explanation.

Proposed intervention or prediction

After a security and storage review, raise the staging distributor's explicit body limit from 10 MiB to 16 MiB. Predict that 12 MiB uploads will reach an API instance and return 201, while 17 MiB uploads will still return 413 at the distributor.

Observed result

Five 12 MiB uploads return 201, and correlated API logs plus object metadata show five stored synthetic objects of the expected byte length. Five 17 MiB uploads return 413 and remain absent from API logs.

Bounded conclusion

The configured distributor body limit caused the tested staging failures. The intervention changed the threshold in the predicted direction.

Remaining uncertainty

The test does not establish safe production capacity, malware scanning behavior, interrupted-upload recovery, user radio performance, audit completeness, or a maximum permitted document size under agency policy. Another upstream intermediary could apply a separate limit outside staging.

Normal case, failure cases, and qualifications

In the normal CampusCart path, DNS returns usable addresses, the client selects a supported transport, routing tables provide next hops, authorization rules allow the intended ports, TLS validates the CampusCart name, HTTP reaches a healthy target, and the API reaches PostgreSQL through a separate private path. Each communication has two named endpoints and a configured return path.

An address-planning edge case appears when the campus network and cloud network both use 10.20.0.0/16. A virtual private network cannot select a unique destination from the overlapping prefixes without translation or renumbering. Both prefixes are valid private address space; the conflict comes from using the same addresses on two connected administrative sides.

A routing failure can coexist with an apparently correct firewall rule. Allowing TCP destination port 5432 toward PostgreSQL does not create a route to the database subnet. Conversely, a valid route does not authorize the traffic. DNS can also return the intended address while TLS fails because the certificate identity does not match the requested name.

Network Address Translation (NAT) is another qualification. NAT rewrites address or port information at a defined inside/outside connection point. NAT can provide outbound reachability for privately addressed instances, but NAT is not a general inbound firewall and does not provide application authentication. Stateful translation tables can exhaust ports under large connection counts.

DNS commonly uses UDP for an initial ordinary query, but current DNS operation also uses TCP and encrypted transport arrangements. A diagnostic rule that blocks or tests only UDP port 53 does not describe every resolver path.

Common errors

  • Adding cumulative `curl` fields. time_connect already includes name-lookup time. Subtract adjacent values to estimate phase increments.
  • Calling every delay “latency.” Name the measured interval: DNS lookup, connection establishment, first-byte time, full transfer, API execution, or database wait.
  • Treating a subnet as a security control. A subnet assigns and places an address prefix. Routes and authorization rules perform different actions.
  • Treating one packet capture as the full path. A traffic distributor terminates one connection and creates another, so client capture evidence stops at that connection endpoint.
  • Assuming ping failure means application failure. Internet Control Message Protocol replies can be blocked while HTTPS remains reachable.
  • Assuming HTTPS hides all metadata. TLS protects application content and integrity under its guarantees, while addresses, some names, sizes, timing, and endpoint behavior can remain observable.

Knowledge check

Question: An AWS route table sends 0.0.0.0/0 to a NAT gateway and 10.20.4.0/24 to a local target. Which route matches destination 10.20.4.17, and does the match prove that TCP port 5432 is allowed?

Answer: The /24 route matches because longest-prefix selection favors it over /0. The route establishes a next-hop choice only. A security group, network access control list, host firewall, and database listener can still deny or fail the connection.

Exercises

Check

For 10.30.8.0/23, calculate the number of IPv4 addresses, the first address, and the last address. Submit the binary or power-of-two calculation. Mark the mathematical block size separately from any provider-specific assignable count.

Practice

Run the ten-request curl test. Preserve raw rows in a text file and create a table of phase increments in milliseconds. Report the median and maximum total time, the program and clock source, one observation, one inference, and two alternative explanations.

Challenge

Design a private address plan for CampusCart with two availability zones. Include separate API and database subnet prefixes inside one stated VPC prefix, route destinations and targets, allowed communication pairs, and a non-overlap check against a campus prefix of 10.20.0.0/16. Submit a diagram, a route table, and a firewall-intent table. The evidence must name both endpoints for every allowed flow.

Authoritative sources and further reading

Required standards

Implementation documentation

Standards status, browser transport selection, provider defaults, reserved subnet addresses, route targets, and firewall behavior are version-sensitive. Verify the status page and the exact provider documentation before applying a rule to production.

Next-chapter transition

Networking explains how CampusCart reaches a compute endpoint and how CivicPermit separates public and private communication. The next chapter opens that endpoint and explains how hypervisors, virtual machines, containers, and managed service models divide a physical computer and divide operational responsibility.