Cloud Security Program · Part 2 — Network & Perimeter: Segmentation, Private Connectivity & Edge

This is Part 2 of the Cloud Security Program — the network phase, and it only makes sense because Part 1 is already done. There we built the ground everything else stands on: an account/organization hierarchy that isolates blast radius, one governed identity for humans and machines, and org-wide preventative guardrails a well-meaning engineer cannot click past. With that in place, the perimeter is no longer the network — identity is — but the network is still where a compromise either stays contained or spreads. This part is about containment: drawing boundaries so a breached workload cannot reach what it has no business reaching, keeping traffic to your managed services off the public internet entirely, stopping a compromised host from exfiltrating data freely, and putting a hardened, filtered edge in front of everything the world can see. None of it replaces the identity work from Part 1 — it wraps around it, so that even an attacker who lands inside finds every direction blocked.

As in Part 1, the structure throughout is a three-column comparison — AWS, GCP, Azure side by side — because these are the same four controls wearing three different badges. Learn the concept once; apply it three times. And where Part 1's guardrails matter, we call them out: the SCPs / Organization Policies / Azure Policy you inherited are exactly how you make the network baselines in this part non-optional.

Scope of this phase

Every part of this program is scope-bounded so you know exactly when you are done and are not tempted to boil the ocean.

• In scope: network segmentation and isolation (VPC/VNet design, subnets, security groups / firewall rules / NSGs, per-environment isolation, blast-radius containment); private connectivity to managed services so traffic stays off the public internet (PrivateLink / Private Service Connect / Private Link + private access to Google/Azure services); egress control (default-deny egress, NAT, and egress firewalls so a compromised workload cannot exfiltrate freely); and edge protection (CDN + WAF + DDoS at the perimeter), with a nod to a cloud-agnostic edge.
• Explicitly out of scope (later parts): encryption design, KMS key hierarchies and secrets management (Part 3); the detection, CSPM and incident-response use of the flow logs and firewall logs you enable here (Part 4); and continuous compliance, drift and framework mapping (Part 5). You will generate network telemetry in this phase; you consume it later.
• Definition of done: the exit checklist at the end of this part. When every box is ticked across all three clouds, you are ready for Part 3 — and not before.

The four building blocks — segmentation, private connectivity, egress control, edge — build on each other but can be worked in parallel by a small team. Take them one at a time.

Building block 1 — Segmentation & isolation

The foundational network object in every cloud is a private, software-defined network you own end to end: a range of IP space, carved into subnets, with routing you control. Everything else attaches to it.

The first rule mirrors the account rule from Part 1: isolate environments at the network boundary, not just with tags or naming. Prod, staging and dev get separate VPCs/VNets (typically in separate accounts/projects/subscriptions, exactly as Part 1 laid out), with non-overlapping CIDR ranges so you never have to connect them, and no default route between them. When two environments genuinely need to talk, you peer them explicitly and narrowly — never a flat, everything-can-reach-everything network.

Within a network, use the tiered pattern that has survived every platform shift: public subnets for internet-facing load balancers only; private subnets for application compute with no public IPs; isolated/data subnets for databases and stateful services with no route to the internet at all. Traffic flows inward through choke points, never straight from the internet to your data tier.

The stateful instance firewall — Security Groups / Firewall Rules / NSGs — is where you enforce least-privilege connectivity between tiers. The web tier accepts 443 from the load balancer; the app tier accepts its port only from the web tier's security group; the database accepts 5432 only from the app tier. Reference groups/tags, not IP ranges, so the rules stay correct as instances come and go. Default to deny; open only what a tier provably needs. Here is a minimal, provider-honest example of a default-deny app-tier group that only admits the web tier:

resource "aws_security_group" "app_tier" {
  name        = "app-tier"
  description = "App tier: ingress only from web tier, no broad egress"
  vpc_id      = var.vpc_id

  ingress {
    description     = "App port from web tier only"
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.web_tier.id]
  }

  # No inline egress block => Terraform removes the default allow-all egress,
  # leaving the tier deny-all outbound until you add explicit rules.
  tags = { Tier = "app", Environment = "prod" }
}

Note the deliberate absence of an egress rule — we come back to that in building block 3. This is also where Part 1 pays off a second time: a preventative guardrail (SCP / Organization Policy / Azure Policy) can forbid the anti-patterns outright — deny attaching public IPs to instances, deny 0.0.0.0/0 ingress on sensitive ports, require that new subnets are created private. That way segmentation is not a convention teams remember; it is a baseline the platform enforces the moment a new network is created.

Building block 2 — Private connectivity

By default, when a workload talks to a managed service — object storage, a managed database, a secrets store — that traffic can traverse a public endpoint, even if it never leaves the provider's backbone. Private connectivity replaces that public path with a private one, so the service appears as a private IP inside your own network. Two things improve at once: the data path never touches the public internet, and you can lock the service down to refuse any request that did not arrive privately.

The pattern is the same everywhere: create a private endpoint for the managed service inside your subnet, point DNS at it so existing client code needs no change, and then restrict the service to accept only private traffic. On AWS that is an S3/Interface Endpoint plus a bucket/endpoint policy; on GCP, Private Google Access or a PSC endpoint; on Azure, a Private Endpoint that gives the PaaS resource a NIC in your VNet while you disable its public network access. A short Azure example:

resource "azurerm_private_endpoint" "storage" {
  name                = "pe-storage-prod"
  location            = var.location
  resource_group_name = var.rg_name
  subnet_id           = var.private_subnet_id

  private_service_connection {
    name                           = "psc-storage"
    private_connection_resource_id = azurerm_storage_account.prod.id
    subresource_names              = ["blob"]
    is_manual_connection           = false
  }
}

# Pair with: public_network_access_enabled = false on the storage account,
# so the blob endpoint is reachable ONLY through this private endpoint.

Why this matters beyond tidiness: it collapses a whole class of data-exfiltration and misconfiguration risk. A storage account with public access disabled cannot be reached by a leaked SAS token from the open internet; a database with only a private endpoint is invisible to internet scanners entirely. GCP's VPC Service Controls takes the idea furthest, drawing a service perimeter around your projects so that even a valid credential cannot be used to pull data to a destination outside the perimeter — a strong mitigation against the "stolen token, exfiltrated bucket" pattern. Private connectivity is the control that turns "we told people not to expose the database" into "the database has no public surface to expose."

Building block 3 — Egress control

This is the underrated control, the one most teams skip and attackers count on. Ingress filtering gets all the attention, but a compromised workload's next move is outbound — to a command-and-control server, or to push your data somewhere they control. If every subnet has an unrestricted path to 0.0.0.0/0, a breached container can talk to anything. Default-deny egress, with outbound traffic forced through a NAT and an inspecting egress firewall, is what turns a foothold into a dead end.

The target architecture in all three clouds: private subnets have no direct internet route; outbound traffic that is genuinely required goes through a NAT and then an egress firewall that filters by destination FQDN, not just IP — because IP allowlists are useless against fast-moving CDNs and cloud-hosted C2. You allow the specific domains a workload legitimately needs (your package registry, OS update servers, a named third-party API) and deny the rest. Combine this with building block 2: traffic to your own cloud's managed services should go over private endpoints and never hit the egress path at all, which keeps the allowlist small and the NAT bill lower.

The pattern looks like default-deny outbound at the instance firewall, plus an explicit domain allowlist at the egress firewall:

# AWS Network Firewall — stateful rule group: allow only named domains outbound
resource "aws_networkfirewall_rule_group" "egress_allow" {
  capacity = 100
  type     = "STATEFUL"
  rule_group {
    rules_source {
      rules_source_list {
        generated_rules_type = "ALLOWLIST"
        target_types         = ["TLS_SNI", "HTTP_HOST"]
        targets = [
          ".amazonaws.com",           # provider APIs
          "registry.npmjs.org",       # package registry
          "deb.debian.org",           # OS updates
        ]
      }
    }
  }
  # Anything not on this list is dropped by the firewall's default deny action.
}

The payoff is concrete: with default-deny egress, an attacker who executes code in your app tier cannot open a reverse shell to an arbitrary host, cannot curl your database dump to a random bucket, and cannot pull a second-stage payload from an unknown domain — every one of those is an outbound connection to a destination that is not on the allowlist, and the firewall drops it while logging the attempt (telemetry Part 4 will alert on). It is one of the highest-return controls in the whole program, and almost nobody does it on day one.

Building block 4 — Edge protection

The final layer faces outward. Everything the internet can reach — your APIs, your web apps, your public load balancers — should sit behind a managed edge that absorbs volumetric attacks, filters malicious requests, and serves cached content close to users. Three capabilities, one perimeter.

Put the WAF in front of every public HTTP(S) entry point and start from a managed rule set — the provider's baseline for the OWASP-style common attacks (injection, path traversal, known-bad inputs) — then add rate-based rules to blunt brute-force and layer-7 floods, and geo or IP reputation rules where they fit your traffic. Terminate TLS and serve through the CDN so the origin is never contacted directly; then close the loop by locking the origin so it only accepts traffic from the edge (an origin access control / a shared secret header the WAF injects and the origin verifies / firewall rules restricted to the CDN's ranges). Without that step, an attacker simply finds the origin IP and walks around the WAF entirely — a common and avoidable mistake. A minimal managed-rules + rate-limit WAF web ACL:

resource "aws_wafv2_web_acl" "edge" {
  name  = "edge-acl"
  scope = "CLOUDFRONT"
  default_action { allow {} }

  rule {
    name     = "AWSManagedCommonRules"
    priority = 1
    override_action { none {} }
    statement {
      managed_rule_group_statement {
        vendor_name = "AWS"
        name        = "AWSManagedRulesCommonRuleSet"
      }
    }
    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "common"
      sampled_requests_enabled   = true
    }
  }

  rule {
    name     = "RateLimit"
    priority = 2
    action { block {} }
    statement {
      rate_based_statement {
        limit              = 2000   # requests per 5 min per IP
        aggregate_key_type = "IP"
      }
    }
    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "ratelimit"
      sampled_requests_enabled   = true
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "edge-acl"
    sampled_requests_enabled   = true
  }
}

DDoS protection at the network and transport layers is largely automatic on all three clouds' front doors (AWS Shield Standard, Google's front-end, Azure's infrastructure protection); the paid tiers — Shield Advanced, Azure DDoS Network/IP Protection, Cloud Armor's advanced rules — add attack visibility, cost protection and rapid-response support, and are worth it once you carry meaningful public traffic.

Finally, a cloud-agnostic option worth naming: Cloudflare provides the same CDN + WAF + DDoS + bot-management stack in front of any origin, on any cloud or across several. For multi-cloud estates, or teams that want one edge policy and one set of logs regardless of where the workload runs, a vendor-neutral edge decouples your perimeter from any single provider — at the cost of introducing another control plane to govern. Either way, the principle holds: nothing public without a filtering, rate-limiting, DDoS-absorbing edge in front, and a locked origin behind it.

Definition of done — Network & Perimeter exit checklist

You are ready for Part 3 when every one of these is true, in each cloud you run:

• Segmentation: prod/staging/dev isolated in separate VPCs/VNets with non-overlapping CIDRs and no default route between them; the tiered public/private/isolated subnet pattern in use; databases and stateful services in subnets with no internet route; cross-network links explicit and narrow, never flat.
• Instance firewalls: Security Groups / Firewall Rules / NSGs default-deny, opening only least-privilege paths between tiers by group/tag reference rather than broad IP ranges; no 0.0.0.0/0 on sensitive ports.
• Guardrail-enforced baselines: Part 1's policy engine (SCP / Organization Policy / Azure Policy) forbidding public IPs on instances, broad ingress, and public-by-default subnets — so segmentation is enforced, not merely conventional.
• Private connectivity: managed services reached over VPC Endpoints / Private Service Connect + Private Google Access / Private Endpoints; public network access disabled on the PaaS resources that support it; DNS pointed at the private endpoints; VPC Service Controls (GCP) considered for high-value data.
• Egress control: private subnets have no direct internet route; required outbound goes through NAT + an egress firewall filtering by destination FQDN with a small allowlist; default-deny for everything else; drops logged.
• Edge protection: every public HTTP(S) entry point behind a CDN + WAF (managed rules + rate limiting) with DDoS protection; the origin locked to accept traffic only from the edge; advanced DDoS tier evaluated for high-traffic services; a cloud-agnostic edge (Cloudflare) considered where multi-cloud uniformity helps.

Tick every box and the network is contained in all directions. Skip one — the staging VNet peered a little too widely, the one storage account still public, the subnet with a lingering default route to the internet — and it becomes the exact path a later incident travels.

What's next

Part 3 — Data & Secrets turns from the network to the thing the network exists to protect: the data itself. With segmentation, private connectivity, egress control and a hardened edge now in place, we design encryption across all three clouds — KMS key hierarchies and the choice between provider-managed and customer-managed keys, encryption at rest and in transit by default, and disciplined secrets management so credentials, tokens and keys are generated, stored, rotated and accessed without ever landing in a repo or an environment variable. The private endpoints and guardrails you built here are exactly what keep those keys and secrets reachable only from inside your perimeter. It ships next month.

Standing up the network layer is also where a platform earns its keep a second time: ISMShed captures your segmentation model, private-connectivity coverage, egress posture and edge protection as continuous, framework-mapped audit evidence across ISO 27001, ENS, NIS2, DORA, SOC 2 and GDPR — so the network controls this phase produces become your compliance story rather than a diagram you redraw before every audit. And if you would like experienced hands to design the segmentation, private connectivity and edge across your own AWS, GCP and Azure estate, Axelia's cloud-security and GRC consultants run the program alongside you. Contain the network now, and the data-protection work in Part 3 has a perimeter it can trust.