General Network Principles

Overview

Cloud network security differs from on-premises network security in one foundational way: the control plane is reached over the public internet through an authenticated API, and that API is the real perimeter. Traditional defence-in-depth thinking — concentric rings around a data centre with the firewall as the trust boundary — does not survive contact with a cloud tenant where any caller anywhere with a valid credential can provision, modify, or delete resources. NIST SP 800-207 Zero Trust Architecture codifies the shift: trust is established per request, against an authenticated identity and a verified device posture, not inherited from a network location.

That said, network controls have not disappeared. Cloud workloads still expose listening services that need to be protected from internet scanning, lateral movement within a virtual network is still a real attack chain (Capital One 2019, summarised on general/threat-model.html as Chain B, traversed network primitives to reach the IMDS endpoint), and exfiltration over outbound connections is still the egress most cloud tenants fail to filter. This page sets eight provider-neutral principles — defence in depth, segmentation, zero trust, egress control, private connectivity, encryption in transit, DNS security — and the cross-provider primitives that implement them. Provider-specific depth lives on AWS, Azure, GCP, and OCI network pages; this page is the principles reference those pages link back to. Encryption-in-transit guidance lives canonically here; general/data.html cross-references rather than duplicates.

Defense in depth for cloud networks

Defence in depth means layered controls such that the failure of any single layer does not directly enable compromise. In a cloud network the layers stack from the cloud-provider primitive at the bottom to the application-layer identity at the top, and each layer is a distinct configuration surface with distinct failure modes.

The lowest layer is the cloud firewall attached to the workload's network interface: AWS Security Groups, Azure Network Security Groups, Google Cloud VPC firewall rules, and Oracle Cloud Infrastructure Security Lists. These are stateful packet filters scoped per instance or per subnet, and they are the most common point at which a misconfigured deploy exposes a database or management port to the public internet. Above that layer sits the subnet-level control: AWS Network ACLs (stateless), Azure route tables and subnet-attached NSGs, GCP VPC firewall rules at the network level, OCI Security Lists at the subnet level. These provide a coarser-grained filter that the cloud firewall layer cannot bypass and are useful for enforcing organisation-wide bans (no SSH from the internet anywhere in this VPC, regardless of individual SG misconfigurations).

Above the cloud firewall and subnet layers, workload-level controls enforce policy that the network primitives cannot express. Host firewalls (iptables, nftables, Windows Defender Firewall) still run on individual instances and remain useful for defence in depth, even when the cloud firewall is correctly configured. Service-mesh identity (mTLS via Istio, Linkerd, Consul Connect, App Mesh) authenticates service-to-service traffic on identity rather than IP. At the application layer, Web Application Firewalls (AWS WAF, Azure Front Door / Application Gateway WAF, Google Cloud Armor, OCI WAF) filter application-layer attacks (OWASP Top 10 patterns) on hostnames the cloud-firewall layer can only filter on by port. API gateway authentication enforces caller identity on every API request.

The point of layered controls is not redundancy for its own sake — it is that misconfigurations are common, and the operating discipline is to assume any single layer is misconfigured at any time. A defence-in-depth design tolerates that assumption.

Network segmentation

Network segmentation isolates workloads of different trust levels into distinct network domains, so that compromise in one domain does not propagate to another. The cloud's strongest isolation primitive is the account, subscription, project, or compartment boundary itself — these are administrative containers with separate IAM, separate billing, separate audit trails, and (importantly) no implicit network connectivity. A workload in a production AWS account cannot reach a workload in a development AWS account over the network unless an explicit peering, Transit Gateway attachment, or VPN tunnel has been provisioned.

Within an account, the next isolation primitive is the virtual network: an AWS Virtual Private Cloud (VPC), an Azure Virtual Network (VNet), a Google Cloud VPC, or an Oracle Cloud Infrastructure Virtual Cloud Network (VCN). Each is an isolated address space with its own routing, its own internet gateway (or absence of one), and its own firewall posture. Below the VPC, subnets partition the address space and attach distinct routing policies — public subnets route via an internet gateway, private subnets route via NAT or not at all, intra-cloud subnets route via VPC endpoints to provider services without touching the public internet.

The hub-and-spoke topology is the dominant pattern for multi-VPC estates. A central hub VPC holds shared inspection appliances (firewall, IDS/IPS, DNS resolver, egress proxy) and connects to spoke VPCs through Transit Gateway (AWS), Virtual WAN (Azure), Network Connectivity Center (GCP), or Dynamic Routing Gateway (OCI). Spoke-to-spoke traffic routes through the hub and is inspected; spoke-to-internet traffic routes through the hub's egress controls. The design centralises inspection at one operational cost and allows spokes to remain simple. Provider-specific topology depth is described on aws/network.html, azure/network.html, gcp/network.html, and oci/network.html; this page treats only the topology pattern.

A common segmentation failure is the flat production VPC — one VPC, one subnet, every workload in the same broadcast domain — paired with permissive security groups that allow intra-VPC traffic by default. The remediation is mechanical: split workloads by tier (web, application, data) into distinct subnets, default-deny intra-VPC traffic at the security-group layer, and require explicit allow rules between tiers.

Zero trust principles

Zero trust is the design discipline of treating every network request as untrusted regardless of its source, and authenticating and authorising the request against the requesting identity, the device posture, and the requested resource — never against the network location alone. NIST SP 800-207 (Zero Trust Architecture, Aug 2020) is the foundational reference; CISA's Zero Trust Maturity Model 2.0 (Apr 2023) extends it with a maturity-based path organised around five pillars.

The CISA pillars are Identity, Devices, Networks, Applications & Workloads, and Data, with Visibility & Analytics, Automation & Orchestration, and Governance as cross-cutting capabilities. For a cloud tenant, the implications are concrete. The Identity pillar drives federated authentication and phishing-resistant MFA — covered on general/iam.html §Identity federation and §Multi-factor authentication. The Devices pillar drives endpoint posture verification (managed laptops, EDR enrolment, OS-level encryption) before granting access. The Networks pillar — most directly relevant to this page — replaces the flat virtual-network trust assumption with micro-segmentation: every service-to-service connection is authenticated, authorised, and ideally encrypted with mutual TLS regardless of whether the source and destination sit in the same VPC.

The Applications & Workloads pillar drives identity-aware proxies: Google Cloud Identity-Aware Proxy, AWS Verified Access, Azure AD Application Proxy, and equivalent third-party access brokers (Cloudflare Access, Tailscale, Zscaler Private Access). These products front internal applications with an authenticated reverse proxy so that the application is never directly reachable on the network — the reverse proxy authenticates the user and forwards the request only if policy permits. The Data pillar drives encryption, classification, and authorisation at the data layer (treated on general/data.html); the network pillar does not stop at the network alone.

Workload-to-workload zero trust is implemented through service mesh: Istio, Linkerd, AWS App Mesh, Azure Service Fabric Mesh, OCI Service Mesh. The mesh provides each workload with a SPIFFE identity, enforces mTLS on every service call, and applies authorisation policy that names the calling identity rather than its IP address. The result is that a compromised pod cannot reach another pod simply because they share a subnet; it must hold the calling identity's certificate, which is short-lived and rotated automatically.

Egress control

Egress control is the deliberate filtering of outbound traffic from workloads, allowing only the destinations a workload provably requires and denying the rest. The principle is the inverse of the well-understood ingress posture (deny by default; allow only the listening services the workload publishes), and across all four major providers it is the most-missed control because the cloud-provider defaults allow outbound traffic to anywhere on the public internet.

The threat model is data exfiltration and command-and-control callback. An attacker who establishes code execution in a workload — through a vulnerable dependency, a poisoned container image, or a misconfigured admin endpoint — needs a return channel to receive instructions and to send stolen data. If the workload's outbound traffic is default-allow, the attacker uses any outbound port to any destination. If outbound traffic is restricted to a small allow-list of known-required destinations (the application's database, the provider's KMS endpoint, a small set of dependency mirrors), exfiltration and C2 become structurally difficult and far easier to detect.

The implementation pattern is consistent across providers. Workloads have no direct internet route; instead, their outbound traffic flows through an egress proxy (Squid, Envoy, or a managed offering such as AWS Network Firewall, Azure Firewall, Cloud NGFW Enterprise on GCP, OCI Network Firewall) that enforces FQDN-aware allow lists. The proxy logs every request, supports DNS-aware policy (allow connections to *.example.com rather than to IP ranges that change), and integrates with the cloud audit log so that policy violations produce alerts. Workloads needing to reach the provider's own API surface use VPC endpoints / Private Link / Private Service Connect / Service Gateway (see §Private connectivity) so that traffic never crosses the public internet at all.

Private connectivity

Private connectivity refers to reaching cloud-provider services and third-party SaaS endpoints without traversing the public internet. The motivation is twofold: the public internet is a wider blast surface (any DNS hijack, any BGP leak, any TLS-stripping intermediary affects the connection), and traffic that traverses the public internet is also visible to the provider's egress accounting and to any network-layer adversary on the path. Private connectivity keeps traffic on the provider's backbone and (in most cases) inside the customer's own address space.

The four major providers expose three categories of primitive. The first is the service endpoint — a private routable address inside the customer's VPC that resolves to the provider service. AWS VPC Endpoints (interface and gateway varieties) provide private addresses for S3, DynamoDB, KMS, Secrets Manager, and most other AWS services. Azure Private Endpoint provides equivalent access for Storage, Key Vault, SQL Database, and most other Azure services. Google Cloud Private Service Connect provides private endpoints for Google APIs, third-party SaaS, and customer-published services. Oracle Cloud Infrastructure Service Gateway provides private routes from a VCN to OCI services within a region.

The second category is private-to-private connection brokering. AWS PrivateLink, Azure Private Link, and Google Private Service Connect publish a customer's service to other customers' VPCs as a private endpoint; the consumer reaches the producer over the provider backbone without exposing a public endpoint. Third-party SaaS providers increasingly publish their services via these mechanisms, eliminating the need for an internet-routable address on either side.

The third category is hybrid connectivity — Direct Connect, ExpressRoute, Cloud Interconnect, OCI FastConnect — for traffic between on-premises and cloud. These dedicated lines remove the public-internet path entirely for the office-to-cloud connection. The design rule across all three categories: if a piece of traffic can be expressed as private connectivity instead of public-internet connectivity, it should be. The cost is configuration; the benefit is reduced surface and reduced exposure to the entire class of public-network attacks.

Encryption in transit

Encryption in transit protects network traffic against interception and modification by adversaries on the path. The current standard is Transport Layer Security version 1.3 (IETF RFC 8446, Aug 2018), which closes the protocol-downgrade and cipher-negotiation weaknesses of TLS 1.2 and earlier. The minimum acceptable floor across all cloud workloads is TLS 1.2 with modern cipher suites; TLS 1.3 is preferred wherever client compatibility allows. TLS 1.0 and 1.1 are forbidden — they remain enabled on some legacy provider endpoints for backward compatibility but the customer's own load balancers, API gateways, and application listeners must refuse them.

For service-to-service traffic inside the cloud, mutual TLS (mTLS) authenticates both ends of the connection cryptographically. Service-mesh implementations (Istio, Linkerd, App Mesh, Azure Service Fabric Mesh) provision short-lived certificates per workload and rotate them automatically, making mTLS the default for east-west traffic without per-application configuration effort. This page treats encryption in transit canonically; general/data.html §Encryption in transit cross-references rather than duplicates.

DNS security

DNS is the network layer most often overlooked in cloud network design. Three controls matter. First, DNSSEC verifies authoritative DNS responses against a chain of trust rooted at the DNS root zone; enabling DNSSEC on customer-managed zones (Route 53, Azure DNS, Cloud DNS, OCI DNS all support it) defeats spoofed responses. Second, private DNS zones (Route 53 private hosted zones, Azure Private DNS, Cloud DNS managed private zones, OCI private zones) provide split-horizon resolution so that internal hostnames resolve to private endpoints from within the VPC and to nothing from outside. Third, DNS query logging — Route 53 Resolver query logs, Azure DNS analytics, Cloud DNS logging, OCI DNS analytics — surfaces the destinations a workload is attempting to reach, including the DNS-based exfiltration patterns (NXDOMAIN tunnelling, beaconing to look-alike domains) that pure connection-based egress filtering can miss.

Cross-provider equivalence

The table below maps the principal network primitives across the four major providers. Each cell names the load-bearing service; provider IAM and routing details belong on the provider network pages and are not duplicated here. The provider pages — AWS, Azure, GCP, OCI — extend each entry to the depth a hardening reviewer requires.

Illustrative control — Default-deny egress

The control entry below is an illustrative example of how the egress-control principle (§4 above) translates into a concrete, severity-rated, compliance-mapped control. Provider-specific controls with CLI and Terraform remediation live on the four provider network pages (AWS, Azure, GCP, OCI) and not here.