Cloud Network Security Fundamentals: VPCs and Segmentation

Cloud network security controls which traffic can reach your workloads and which traffic can move between them, using constructs like virtual networks, subnets, security groups, and firewall rules. Getting these basics right stops most opportunistic attacks before they ever touch an application.

Every major cloud breach investigation eventually asks the same question: what was the network path that let this happen? A misconfigured security group, an overly broad firewall rule, or a flat network with no segmentation is often the reason a single compromised credential turns into a full environment takeover. This guide covers the core building blocks of cloud network security across AWS, Azure, and Google Cloud, and how they fit into the broader security model you will use throughout a cloud security career.

What Cloud Network Security Actually Means

In a traditional data center, network security meant a perimeter firewall, a demilitarized zone, and a handful of chokepoints where traffic could be inspected. In the cloud, the perimeter is distributed. Every virtual machine, container, and managed service can have its own network policy, and traffic between services inside the same account can be just as dangerous as traffic coming from the internet.

Cloud network security is the set of controls that:

• Define which resources can talk to each other (segmentation)
• Define which traffic is allowed in and out of a resource or subnet (filtering)
• Encrypt traffic in transit between resources and users
• Provide visibility into what traffic is actually flowing (flow logs and monitoring)

None of this replaces identity and access management. It works alongside it. A well-configured network reduces the blast radius when an identity is compromised, and a well-configured identity layer reduces how much damage a network misconfiguration can cause.

The Building Blocks: VPCs, VNets, and Subnets

Each major cloud provider uses a similar concept with a different name for the isolated network you build your resources inside:

• AWS calls it a Virtual Private Cloud (VPC)
• Azure calls it a Virtual Network (VNet)
• Google Cloud calls it a VPC as well, but its VPCs are global by default and span regions

Inside each of these, you carve out subnets, smaller address ranges tied to a specific availability zone or region that hold your actual resources. The standard pattern is to separate public subnets, which can route directly to the internet, from private subnets, which cannot. Databases, internal APIs, and anything that does not need direct internet exposure belong in private subnets behind a load balancer, API gateway, or bastion host.

Getting subnet design right early matters more than it might seem. Re-architecting network layout after an application is in production is disruptive, so this is one of the first decisions a cloud security engineer reviews on any new environment.

Stateful vs Stateless Controls: Security Groups, NACLs, and NSGs

Once the network topology exists, you need rules that control traffic. Each provider gives you at least one resource-level control and one subnet-level control, and the distinction between stateful and stateless matters for how you write rules.

A stateful control automatically allows return traffic for a connection you already approved. If you allow inbound traffic on port 443, the response does not need a separate outbound rule. A stateless control evaluates every packet independently in both directions, so you must explicitly allow both the request and the response.

Control	Provider	Level	Stateful?	Rule types
Security Group	AWS	Resource (ENI/instance)	Yes	Allow only
Network ACL	AWS	Subnet	No	Allow and deny
Network Security Group (NSG)	Azure	Subnet or NIC	Yes	Allow and deny
VPC Firewall Rules	Google Cloud	Network (global, tag or service-account scoped)	Yes	Allow and deny

According to AWS documentation, security groups act at the instance level while network ACLs act at the subnet level, and security groups only support allow rules, meaning anything not explicitly permitted is denied by default. Azure's guidance recommends applying NSGs at the subnet level and reusing them across resources rather than attaching a unique NSG to every network interface, since that quickly becomes unmanageable at scale. Google Cloud's architecture guidance similarly emphasizes starting from a default-deny posture and scoping allow rules to specific service accounts or tags rather than broad IP ranges.

The practical takeaway for anyone new to this: default to deny, allow only the specific ports and protocols a workload needs, and use the subnet-level or policy-level control as your backstop rather than your primary defense.

Segmentation Strategies That Actually Work

Segmentation is the practice of dividing a network into smaller zones so that a compromise in one zone does not automatically grant access to everything else. A few patterns show up repeatedly in well-run cloud environments:

1. Tiered segmentation. Separate web, application, and data tiers into their own subnets with rules that only allow traffic to flow one direction, web to app to data, never the reverse.
2. Environment separation. Keep production, staging, and development in separate accounts or projects rather than separate subnets in the same account. This limits how far a mistake in a lower environment can travel.
3. Microsegmentation. Rather than relying only on subnet boundaries, apply rules at the individual workload level using tags or service accounts, so two servers in the same subnet still cannot talk to each other unless explicitly allowed.
4. Hub-and-spoke topology. Route traffic between multiple VNets or VPCs through a central hub that hosts shared inspection and logging services, which keeps monitoring consistent across a growing environment.

Google Cloud's own architecture guidance for VPC design recommends starting with a small number of well-planned networks rather than sprawling ad hoc ones, since firewall rule management gets exponentially harder as the number of networks grows without a clear ownership model.

Common Network Security Mistakes That Get Cloud Environments Breached

A short list of the errors that show up again and again in incident reports and cloud security assessments:

• Leaving a security group or firewall rule open to 0.0.0.0/0 on a management port like SSH or RDP
• Placing a database in a public subnet because it was faster to set up during development, then never moving it
• Relying entirely on the network layer for security while ignoring identity and access management, so a stolen credential bypasses every network control
• Not enabling flow logs, which means there is no record of what traffic actually occurred when something goes wrong
• Treating internal traffic as automatically trusted, which is the exact assumption a zero trust architecture is designed to remove

How Network Security Fits Into a Zero Trust Model

Network segmentation and zero trust are related but not identical. Segmentation limits which paths exist. Zero trust adds the requirement that every request, even one traveling a permitted path, must be authenticated and authorized on its own merits rather than trusted because it originated inside the network.

In practice, a mature cloud environment combines both: tight segmentation to reduce the number of possible paths, strong identity and access management with least privilege to control who can use those paths, and continuous verification so that being on the "trusted" network is never treated as sufficient on its own.

Building Cloud Network Security Skills for a Cloud Security Career

Network security fundamentals show up in every cloud security certification and in nearly every hands-on interview exercise, because they are foundational to how the rest of a cloud environment gets secured. If you are early in a transition into this field, this is one of the areas worth practicing directly rather than only reading about: build a VPC or VNet from scratch, intentionally misconfigure a security group, then find and fix it using the provider's own tooling.

Structured, lab-based practice across AWS, Azure, and Google Cloud is exactly what the PrimeSec Academy curriculum is built around, alongside the identity, monitoring, and AI security topics covered elsewhere on this blog. If you are not sure whether your current background is a fit, the eligibility quiz is a fast way to find out before committing to a program.

Frequently asked questions

What is the difference between a security group and a firewall in the cloud? A cloud security group is a virtual firewall that filters traffic at the resource level, typically supporting only allow rules and automatically allowing return traffic for approved connections. A traditional firewall or a subnet-level control like a network ACL often supports both allow and deny rules and evaluates traffic in both directions independently.

Do I need both security groups and network ACLs in AWS? Most workloads can run securely using only security groups, since they are more flexible and support multiple groups per resource. Network ACLs are commonly added as a secondary, subnet-wide control for rules that should apply to every resource in that subnet, such as explicitly blocking a known bad IP range.

Is a public subnet always less secure than a private subnet? A public subnet is not inherently insecure, but any resource placed there is directly reachable from the internet unless firewall rules restrict it. The safer default is to keep resources that do not need direct internet access, such as databases, in private subnets behind a load balancer or gateway.

How does network segmentation help if an attacker already has valid credentials? Segmentation limits which systems a compromised credential or compromised workload can reach, even if the identity itself is valid. Combined with least privilege access controls, this significantly reduces how far an attacker can move after an initial compromise, a technique known as lateral movement.

What tools show me what traffic is actually happening in my cloud network? AWS, Azure, and Google Cloud each provide flow logging services, VPC Flow Logs, Azure Network Watcher flow logs, and Google Cloud VPC Flow Logs respectively, that record metadata about traffic crossing your network interfaces. These logs are commonly forwarded to a SIEM for analysis and alerting.

Do I need to learn all three cloud providers' networking models to get a cloud security job? Most cloud security roles focus on one primary provider, but the underlying concepts, subnets, stateful versus stateless filtering, segmentation, and default-deny design, transfer directly between AWS, Azure, and Google Cloud. Learning one deeply and understanding the equivalents in the others is a strong, realistic goal for a career changer.

Ready to move from reading about cloud network security to configuring it yourself in guided labs across AWS, Azure, and Google Cloud? Enroll in PrimeSec Academy and start building the hands-on skills that cloud security roles actually test for.