Networking, Domains and Cloud Connectivity

Introduction

A deployed web application is not merely code running on a server. It is a communicating system: browsers resolve domain names, establish encrypted connections, send requests through networks, reach application services, and often retrieve data from databases, object storage, payment platforms, or third-party APIs. Networking decisions therefore influence availability, security, latency, scalability, and cost.

This chapter examines the principal networking mechanisms used in cloud deployments, with emphasis on AWS Virtual Private Cloud (VPC) design and Heroku connectivity. The central design problem is to expose only the services that must be public while keeping application components, databases, and administrative interfaces private. The chapter also explains routing, security groups, load balancers, DNS, TLS, content delivery networks (CDNs), NAT, cross-origin communication, and systematic failure diagnosis.

Learning Objectives

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

• Design a VPC with public and private subnets and appropriate route tables.
• Explain internet gateways, NAT gateways, security groups, and network access controls.
• Select and configure load balancers for web applications.
• Explain DNS resolution, domain delegation, TLS certificates, and HTTPS.
• Describe CDN operation and identify when it improves performance.
• Compare common Heroku and AWS connectivity patterns.
• Diagnose routing, DNS, TLS, security, and CORS failures.
• Apply least privilege, observability, and resilient network design principles.

1. The Cloud Application Network Model

A typical production application has several logical layers:

1. Client layer: browsers, mobile applications, or partner systems.
2. Edge layer: DNS, CDN, web application firewall, and TLS termination.
3. Application layer: web servers, APIs, background workers, and load balancers.
4. Data layer: relational databases, caches, queues, and object storage.
5. External-service layer: payment providers, email systems, identity providers, and analytics platforms.

A request may therefore follow this path:

Figure: A simplified request path through edge, application, and data layers.

Cloud networking is based on logical isolation, not physical cables owned by an individual development team. AWS VPC provides an isolated address space in which resources are assigned private IP addresses and controlled routes. Heroku abstracts much of this infrastructure: a dyno is reachable through Heroku’s routing layer, while private spaces and VPN or peering options support more controlled connectivity.

2. IP Addressing, Subnets, and Availability Zones

An IPv4 address is conventionally represented as four decimal octets, such as 10.0.1.25. A CIDR block expresses a network prefix and its length. For example, 10.0.0.0/16 contains 65,536 addresses mathematically, although cloud platforms reserve some addresses and not all are assignable.

The number of IPv4 addresses in a CIDR block is:

Here, N is the total number of addresses and p is the prefix length. This formula applies to IPv4 CIDR blocks; usable cloud addresses are fewer because providers reserve addresses for network functions. Thus, a /24 has 256 total addresses, while a /26 has 64 total addresses.

A subnet is a subdivision of a VPC address range. A subnet is associated with one availability zone (AZ), so resilient systems normally place equivalent resources in multiple AZs. Subnets are commonly classified as:

• Public subnet: its route table contains a route to an internet gateway, and a resource may be publicly reachable if it also has a suitable public address and security rules.
• Private subnet: it has no direct route from the internet gateway. It may still initiate outbound internet traffic through a NAT gateway.
• Isolated subnet: it has no route to the internet, often suitable for databases that need only internal service connectivity.

The terms public and private describe routing, not merely whether an IP address is visible. A public IP without an appropriate route is not useful, and a private resource can still be exposed indirectly through an application proxy.

Example Address Plan

Avoid overlapping CIDR ranges when networks may later be connected through peering or VPN. Overlap makes routing ambiguous and often requires redesign.

3. Route Tables, Gateways, and NAT

A route table determines where packets should be sent. A route usually contains a destination, such as 0.0.0.0/0 for all IPv4 destinations, and a target, such as a local VPC route, internet gateway, NAT gateway, or transit gateway. The most specific matching route is selected.

An internet gateway (IGW) connects a VPC to the public internet. A public subnet usually has the route:

0.0.0.0/0 → Internet Gateway

A private subnet commonly uses:

0.0.0.0/0 → NAT Gateway

A NAT gateway permits resources with private addresses to initiate outbound connections while preventing unsolicited inbound connections initiated from the internet. NAT is not a firewall replacement: security groups and network ACLs still determine whether traffic is permitted. NAT gateways are generally deployed in public subnets and consume resources and data-processing charges.

For high availability, a design may deploy one NAT gateway per AZ and configure each private subnet to use the NAT gateway in its own AZ. A single NAT gateway is cheaper but introduces an AZ dependency and may become a bottleneck or failure point.

A database subnet normally should not use a NAT route merely because the database is “private.” Databases typically require neither internet ingress nor internet egress. If software updates are necessary, carefully controlled mechanisms such as private endpoints, maintenance services, or temporary administrative paths are preferable.

4. Security Groups and Network ACLs

A security group is a stateful, resource-level virtual firewall. Rules specify allowed inbound and outbound traffic using protocols, ports, and sources or destinations. Return traffic for an allowed connection is automatically permitted by the stateful behavior. Security groups contain allow rules; there is no explicit deny rule within a security group.

A network access control list (network ACL) is associated with a subnet and is stateless. It evaluates inbound and outbound traffic separately, so return traffic must be permitted explicitly. ACL rules may include allow and deny entries and are evaluated in rule order. They are useful as a broad subnet boundary but are easier to misconfigure than security groups.

A robust rule model uses references between security groups rather than broad IP ranges. For example:

• Load-balancer security group: allow TCP 443 from the internet.
• Application security group: allow TCP 8080 only from the load-balancer security group.
• Database security group: allow TCP 5432 only from the application security group.

Opening TCP 5432 from 0.0.0.0/0 would expose a PostgreSQL service to the internet and is normally unacceptable. Administrative access should use a bastion with strong controls, a managed session service, or a private VPN rather than unrestricted SSH.

Security must be layered. Identity and access management, application authentication, input validation, encryption, secrets management, patching, logging, and network controls address different threats.

5. Load Balancers and Health Checks

A load balancer distributes requests across healthy targets. An application load balancer (ALB) is appropriate for HTTP or HTTPS routing, host-based routing, path-based routing, redirects, and integration with target groups. A network load balancer (NLB) is suited to high-performance TCP, TLS, or UDP use cases and preserves lower-level connection characteristics.

A health check is not simply a test that a process is running. A useful endpoint such as /health/ready should indicate whether the service can accept traffic. Readiness may include configuration validity and required dependency availability, while liveness should remain simple enough to identify whether the process is alive. If health checks depend on a slow or fragile downstream service, a temporary database issue may remove every application instance from rotation.

TLS may terminate at the load balancer, at the application, or at both. TLS termination at the edge simplifies certificate management and enables HTTP-aware routing. End-to-end encryption from the load balancer to the application may be required by policy or threat model. Applications behind a proxy must correctly interpret forwarded headers, such as the original protocol, and must not trust arbitrary client-supplied forwarding headers.

6. DNS, Domains, and TLS

The Domain Name System (DNS) maps names to records. Common records include:

A domain is registered with a registrar. Its authoritative DNS service is identified through NS records at the parent zone. A resolver caches answers according to their time to live (TTL). TTL affects how quickly changes propagate, but it does not guarantee an exact worldwide update time because resolver behavior, negative caching, and provider practices vary.

A common production arrangement is www.example.com as a CNAME to a CDN or platform hostname, while the zone apex example.com uses an address record or provider-specific alias mechanism. DNS is not a substitute for application authorization: a hidden hostname remains discoverable and must still be protected.

TLS provides encryption in transit, server authentication through certificates, and integrity protection. HTTPS is HTTP carried over TLS. Certificate validation checks that the requested hostname is covered by the certificate, that the certificate chain is trusted, and that the certificate is within its validity period. Automated certificate renewal is a major operational best practice.

Redirecting HTTP to HTTPS is useful, but it is not itself encryption. Applications should use secure cookies, appropriate HSTS policy after careful testing, modern TLS configurations, and correct mixed-content handling. A page loaded over HTTPS cannot safely load active JavaScript over HTTP.

7. CDNs and Caching

A CDN places edge servers closer to users. It can cache static assets, terminate TLS, absorb traffic spikes, reduce origin load, and sometimes provide WAF capabilities. Cache behavior depends on the cache key, which may include the URL, query string, selected headers, and cookies.

Caching is safe only when the response’s publicness and variability are understood. Public JavaScript and images are good candidates. Personalized account pages, private API responses, and responses containing sensitive data require restrictive cache controls or no caching. Incorrect cache keys can leak one user’s response to another.

Cache invalidation should be designed rather than improvised. Content-addressed filenames such as app.8f31c.js permit long-lived caching while ensuring a new file is requested after deployment. APIs may use explicit Cache-Control directives and controlled invalidation.

8. Cross-Origin Communication and Service Connectivity

An origin is defined by the combination of scheme, host, and port. Thus, https://app.example.com and https://api.example.com are different origins even when they share a registrable domain. Browsers enforce the same-origin policy, which limits scripts from reading responses from another origin unless the server grants permission through Cross-Origin Resource Sharing (CORS).

CORS is a browser policy mechanism, not a general server-to-server firewall. A server may return Access-Control-Allow-Origin: https://app.example.com to authorize that origin. If credentials such as cookies are used, the server must explicitly allow credentials and cannot use a wildcard origin in that credentialed configuration. Non-simple requests may trigger an OPTIONS preflight request; the server, proxy, and load balancer must handle it correctly.

A practical service-connectivity matrix should document source, destination, protocol, port, authentication, and reason. For example, an API may connect to PostgreSQL on TCP 5432, an email provider over HTTPS on TCP 443, and a payment webhook endpoint over HTTPS. Outbound access should be limited where feasible, and secrets should be stored in managed secret systems rather than source code or frontend bundles.

Heroku and AWS Patterns

Heroku provides a managed deployment experience in which the platform supplies routing, TLS options, dyno networking, and add-on integrations. A Heroku web process must bind to the port supplied by the PORT environment variable and generally listens on 0.0.0.0, not only on localhost. A frequent deployment failure occurs when an application hard-codes a local development port.

AWS provides more granular control. A frontend may be hosted in object storage behind a CDN, an API may run behind an ALB in private subnets, and a managed database may reside in isolated subnets. A Heroku application can consume an AWS API over HTTPS, while private Heroku-to-AWS connectivity may require supported private networking, VPN, peering, or a carefully secured public endpoint depending on the selected Heroku plan and architecture.

9. A Systematic Troubleshooting Method

Networking failures should be diagnosed from the outside inward, changing one variable at a time.

1. Client and URL: Confirm the exact scheme, hostname, port, and path. Inspect browser developer tools.
2. DNS: Use dig, nslookup, or equivalent tools. Check A, AAAA, CNAME, NS, and TTL behavior.
3. TLS: Use curl -v, certificate inspection, or an approved TLS diagnostic tool. Confirm hostname coverage and certificate chain.
4. Edge and load balancer: Check listener ports, redirects, target-group health, security groups, and access logs.
5. Routing: Verify subnet route tables, internet or NAT gateway routes, network ACLs, and return paths.
6. Application process: Confirm binding address, listening port, startup logs, environment variables, and health endpoint.
7. Application policy: Check authentication, authorization, CORS headers, preflight responses, cookies, and CSRF controls.
8. Dependency path: Test database, cache, queue, and external API connectivity from the actual runtime environment, not only from a developer laptop.

Typical symptoms provide clues. A DNS failure indicates name resolution or delegation trouble. A timeout often indicates routing, security filtering, or an unavailable endpoint. A connection refusal commonly means that a process is not listening on the expected port. A 502 or 503 from a proxy suggests an unhealthy target or protocol mismatch. A browser CORS error may coexist with a successful server response; the browser is refusing JavaScript access, not necessarily reporting that the server is unreachable.

Observability should include structured logs, request identifiers, metrics for latency and errors, distributed traces where appropriate, and flow or load-balancer logs. Do not log passwords, access tokens, payment data, or unnecessary personal information.

10. Illustrative Case: A Two-Tier Student Marketplace

Background

A fictional student marketplace uses a React frontend, a Node.js API, PostgreSQL, object storage for images, and a payment provider. The frontend is deployed through a CDN. The API initially runs on Heroku, while the database is hosted in AWS.

Problem

Users report that the homepage loads, but product searches fail in the browser. The API works from a developer’s laptop. After migration of the API to AWS, intermittent 503 responses appear during traffic peaks.

Analysis

The team first inspects the browser network panel. The API request is sent to https://api.market.example, but the preflight OPTIONS request returns 301. The server redirects HTTP to HTTPS even though the browser already contacted the HTTPS endpoint through a proxy that misinterprets forwarded headers. The API also returns an overly broad or missing CORS policy.

A second investigation finds that the AWS application targets listen on port 3000, while the load balancer target group health check uses port 8080. All targets are therefore marked unhealthy, producing 503 responses. Finally, the application subnets use one NAT gateway located in another AZ; when that gateway is unavailable, workers cannot reach the payment provider.

Approach and Solution

The team makes the following changes:

• It configures the application to trust only the known proxy configuration and to interpret forwarded protocol headers correctly.
• It responds to OPTIONS requests without an authentication redirect and permits only the exact frontend origin.
• It passes the platform-provided port to the application and aligns the target-group health-check port with the listening port.
• It deploys NAT gateways per AZ or replaces unnecessary internet calls with private service endpoints where supported.
• It places the database in isolated subnets and permits database traffic only from the application security group.
• It adds request identifiers, load-balancer access logs, health metrics, and deployment smoke tests.

Outcome

Browser searches succeed, target health becomes stable, and AZ-level resilience improves. The team also documents a connectivity matrix and adds automated tests for DNS, TLS, CORS preflight behavior, and health endpoints.

Learning Points

The case demonstrates that a visible browser error may originate in proxy interpretation, not frontend code. It also shows that port alignment, health checks, route design, and CORS must be treated as one end-to-end communication path rather than isolated configuration tasks.

11. Design Principles, Governance, and Contemporary Practice

A sound network architecture follows least privilege: expose the smallest number of endpoints, ports, routes, and identities required for operation. Separate development, staging, and production accounts or environments where practical. Use infrastructure as code and peer review so that network changes are reproducible and auditable.

Governance requirements may include data residency, retention, breach reporting, encryption standards, access reviews, and payment or health-data obligations. A public cloud does not transfer all responsibility to the provider. The provider secures underlying infrastructure, while the customer remains responsible for configuration, identities, data, and application behavior under the shared-responsibility model.

Modern architectures increasingly use IPv6, private service endpoints, zero-trust access, managed WAFs, service meshes, and policy-as-code. AI-assisted operations can summarize logs or detect anomalies, but generated recommendations must be validated. Sending source code, credentials, personal data, or confidential logs to an unapproved AI service creates governance and privacy risks. Automated remediation should have bounded permissions, audit trails, and human approval for high-impact changes.

Chapter Summary

Cloud networking connects users, edge services, application processes, data stores, and external providers. VPCs provide logical isolation through address ranges, subnets, route tables, gateways, and security controls. Public subnets commonly host internet-facing load balancers, while application and database services belong in private or isolated subnets. Internet gateways provide public routing; NAT gateways support controlled outbound access from private subnets but do not replace firewalls.

Security groups are stateful resource-level controls, whereas network ACLs are stateless subnet-level controls. Load balancers distribute traffic and rely on correctly designed health checks. DNS maps names to services, TLS protects and authenticates connections, and CDNs improve delivery when cache behavior is safe. CORS governs browser cross-origin access and must be distinguished from network reachability.

Reliable diagnosis proceeds from DNS and TLS through edge components, routes, security controls, processes, application policy, and dependencies. Least privilege, multi-AZ design, observability, infrastructure as code, and careful governance make cloud connectivity more secure and maintainable.

Key Terms

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

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

Availability zone: An isolated cloud infrastructure location within a region.

Public subnet: A subnet with a route toward an internet gateway.

Private subnet: A subnet without a direct inbound route from the internet.

Isolated subnet: A subnet with no internet route.

Route table: A set of destination-to-target routing rules.

Internet gateway: A VPC component enabling internet connectivity for suitable resources.

NAT gateway: A managed translator enabling controlled outbound connections from private resources.

Security group: A stateful, resource-level allow-list firewall.

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

Load balancer: A service that distributes traffic among targets.

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

TLS: A protocol providing encryption, integrity, and endpoint authentication.

CDN: A geographically distributed content-delivery network.

CORS: Browser-controlled rules for cross-origin resource access.

Origin: The combination of scheme, host, and port.

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

Least privilege: Granting only the access required for a task.

Shared responsibility: The division of security duties between provider and customer.

Review Questions

5 Short Answer Questions

1. What makes a subnet public in an AWS VPC?
2. How does a NAT gateway differ from an internet gateway?
3. Why are security-group references preferable to broad IP allow rules?
4. What information does a DNS CNAME record provide?
5. Why can a browser report a CORS error even when the server is reachable?

5 Long Answer Questions

1. Design a two-AZ VPC for a web application with public load balancers, private API servers, and an isolated database tier. Explain the route tables and security groups.
2. Explain the complete sequence from entering a domain name in a browser to receiving an HTTPS response from an application.
3. Compare an ALB, an NLB, and a CDN in terms of function, traffic layer, and appropriate use cases.
4. Discuss the security and operational consequences of placing a database in a public subnet.
5. Develop a systematic troubleshooting procedure for an application that returns intermittent 502 and 503 responses.

3 Analytical / Application Questions

1. An API works from a laptop but fails only in the browser. Construct a diagnostic analysis that distinguishes DNS, TLS, CORS, authentication, and routing causes.
2. A private application subnet cannot call an external payment API, although its security group allows outbound TCP 443. Identify at least four additional components or assumptions that should be checked.
3. A company proposes one NAT gateway for three availability zones to reduce cost. Evaluate the resilience, cost, and operational trade-offs and recommend a design for a payment-processing system.

Multiple Choice Questions with Answers

Question 1

Which condition most directly makes an AWS subnet public?

A. It contains a database instance.

B. Its route table has a route to an internet gateway.

C. It uses a security group with outbound rules.

D. It is located in the first availability zone.

Correct Answer: B. Its route table has a route to an internet gateway.

Question 2

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

A. To accept unsolicited inbound internet connections.

B. To replace all security-group rules.

C. To enable controlled outbound connections using private resources.

D. To assign public DNS names to databases.

Correct Answer: C. To enable controlled outbound connections using private resources.

Question 3

Which statement correctly describes a security group?

A. It is stateless and requires separate return rules.

B. It supports only deny rules.

C. It is a stateful, resource-level allow control.

D. It automatically encrypts application data.

Correct Answer: C. It is a stateful, resource-level allow control.

Question 4

Which DNS record maps a hostname directly to an IPv4 address?

A. A

B. MX

C. TXT

D. NS

Correct Answer: A. A

Question 5

What does TLS primarily provide for HTTPS?

A. Database replication

B. Encryption, integrity, and server authentication

C. Automatic application scaling

D. Browser cache invalidation

Correct Answer: B. Encryption, integrity, and server authentication

Question 6

Why might an application load balancer mark every target unhealthy?

A. The domain has a short DNS TTL.

B. The health-check port does not match the application listening port.

C. The database is in an isolated subnet.

D. The CDN caches static assets.

Correct Answer: B. The health-check port does not match the application listening port.

Question 7

Which statement about CORS is correct?

A. It is a replacement for network firewalls.

B. It controls whether browsers may read cross-origin responses.

C. It encrypts traffic between two servers.

D. It assigns IP addresses to frontend applications.

Correct Answer: B. It controls whether browsers may read cross-origin responses.

Question 8

A /26 IPv4 CIDR block contains how many total addresses before provider reservations?

A. 26

B. 32

C. 64

D. 128

Correct Answer: C. 64

Question 9

Which component is most appropriate for caching public static assets close to users?

A. CDN

B. Network ACL

C. NAT gateway

D. Database security group

Correct Answer: A. CDN

Question 10

Which troubleshooting sequence is most systematic for a browser connection failure?

A. Rewrite application code before checking the URL.

B. Check DNS and TLS, then edge routing, security, process, and application policy.

C. Disable all firewall rules permanently.

D. Increase database storage immediately.

Correct Answer: B. Check DNS and TLS, then edge routing, security, process, and application policy.