Cloud network security is the set of controls, policies, and enforcement mechanisms that protect data in motion, segment workloads from each other, and restrict communication paths inside a cloud environment. It spans virtual network design, security groups, encryption in transit, and east-west traffic controls. Most cloud breaches originate at this layer, which makes getting the architecture right before deployment non-negotiable.
The perimeter model that protected on-premises networks for two decades does not translate to cloud. There is no physical boundary. Any workload with a misconfigured security group or an overly permissive route table is reachable from anywhere, and attackers know it. Your job is to build the equivalent of that perimeter inside the cloud fabric itself, layer by layer.
How VPC and VNet Architecture Shapes Your Attack Surface
Every major cloud provider gives you a logically isolated network segment to work in. AWS calls it a Virtual Private Cloud (VPC). Azure calls it a Virtual Network (VNet). GCP uses the same VPC term but applies it globally rather than regionally, which changes the routing behaviour significantly. The name differs; the concept is the same: a private address space carved out of the provider fabric, under your control, invisible to other tenants by default.
Getting the architecture right at this layer has compounding effects downstream. A single VPC or VNet housing all your workloads, from public web tier to database cluster, creates a flat network where a compromised front-end server can reach your payment data directly. Segmenting by function, environment, and sensitivity level before you deploy a single application is far cheaper than retrofitting segmentation after an incident.
Subnet design is where this plays out in practice. Public subnets host resources that need inbound internet access, typically load balancers or NAT gateways. Private subnets hold application servers, databases, and any workload that should never receive a direct public connection. The routing tables attached to each subnet define what traffic leaves and enters, and a private subnet route table should have no default route pointing to an internet gateway.
Peering connections and transit gateways let VPCs communicate across accounts or regions, but each peering link requires explicit route table entries in both directions. There is no transitive routing by default in AWS VPC peering, which means a hub-and-spoke topology does not automatically let spoke A reach spoke B. In security reviews of multi-account AWS environments, this transitive routing gap is one of the most consistently overlooked misconfigurations, often discovered only after troubleshooting failed service calls in production. Design the topology on paper first, map every required traffic flow, and then implement. Retrofitting routing after the fact consistently introduces gaps and requires change windows that create operational risk.
Security Groups vs Network ACLs: Where Each Control Belongs
AWS uses two distinct constructs for traffic filtering, and conflating them leads to either over-permissive rules or redundant complexity. Security groups are stateful, instance-level firewalls attached to elastic network interfaces. When you allow inbound TCP 443 from a specific CIDR, the return traffic is automatically permitted without a corresponding outbound rule. Security groups are the primary enforcement layer for most teams because they operate at the resource level, can reference other security groups as sources, and scale cleanly across hundreds of instances.
Network Access Control Lists (NACLs) are stateless, subnet-level filters. Because they are stateless, you must explicitly allow both the inbound request and the outbound response, including the ephemeral port range (typically 1024 to 65535) for return traffic. NACLs process rules in numbered order and stop at the first match, which means rule order matters in a way it does not for security group evaluation. They are most useful as a defence-in-depth layer: blocking known malicious CIDRs at the subnet boundary before traffic ever reaches an instance security group.
Azure uses Network Security Groups (NSGs), which are closer in behaviour to AWS security groups but can be applied at both the subnet level and the NIC level simultaneously. A rule attached to the subnet NSG and a conflicting rule on the NIC follow a defined precedence order. Knowing that precedence matters when you inherit an environment with NSG rules at both layers, because the effective security policy is the intersection of those layers, not a simple merge.
The practical guidance: use security groups or Azure NSGs as your primary workload-level control. Keep rules specific. A rule allowing TCP 5432 from the application tier security group is better than allowing TCP 5432 from the entire VPC CIDR, because it survives a subnet redesign without becoming accidentally permissive. Reserve NACLs for subnet-level denial of specific IPs or ranges, and keep the rule count low enough to reason about at a glance.
Micro-Segmentation and East-West Traffic Control
Micro-segmentation is the practice of enforcing access controls at the individual workload level rather than at network boundaries alone. The intent is to ensure that a compromised workload cannot freely communicate with adjacent workloads on the same subnet or in the same VPC, limiting lateral movement after a breach. This directly addresses the fact that perimeter firewalls are blind to traffic that never crosses a network boundary.
The distinction between north-south traffic and east-west traffic is central here. North-south traffic crosses a network boundary, entering or leaving your environment from the internet or from an on-premises network. East-west traffic stays inside: service A calling service B within the same VPC, a database query from an application pod to a database pod in the same Kubernetes cluster. Traditional firewalls see north-south traffic because it crosses their inspection point. East-west traffic bypasses them entirely.
In a flat network, east-west traffic is unrestricted. If a web application is compromised, the attacker can probe every other host in the subnet with nothing stopping lateral movement except host-based controls, which are often disabled or misconfigured on cloud instances. Micro-segmentation changes this by applying policy at the workload level. Security group rules that reference other security groups by ID rather than CIDR are one form of micro-segmentation available natively in AWS. The application server security group allows inbound 5432 only from the database client security group, and nothing else on that port.
In container environments, micro-segmentation typically means Kubernetes NetworkPolicy objects. A default-deny policy for all pods in a namespace, combined with explicit allow rules for known traffic paths, is the baseline. Without a NetworkPolicy, all pods in a cluster can reach all other pods on all ports, which is not acceptable for any workload handling sensitive data. The challenge is that NetworkPolicy is only enforced if the CNI plugin supports it. Vanilla Kubernetes with the default CNI does not enforce NetworkPolicy rules, so confirming your CNI implementation matters before you rely on those policies in production. Calico, Cilium, and Weave Net all support NetworkPolicy enforcement; Flannel does not. Cilium extends the standard NetworkPolicy spec with layer 7 rules that can filter on HTTP methods and paths, which matters when you need to restrict which API endpoints a service can call rather than just which ports it can reach.
For deeper east-west inspection, particularly when you need identity-aware policy or application-layer visibility, a service mesh like Istio or Linkerd inserts a sidecar proxy alongside each service. The proxies handle mutual authentication, authorisation policy, and telemetry for every service-to-service call. This is covered in depth as part of the broader approach to cloud-native security practices, because the service mesh ties directly into certificate management, observability, and workload identity in ways that go beyond pure network filtering.
Encryption in Transit: TLS 1.3, mTLS, and When Each Applies
Encrypting traffic in transit inside a cloud environment is not optional. Provider backbone networks are shared infrastructure, and while physical layer interception is difficult, the compliance argument alone is sufficient for most regulated workloads. PCI DSS 4.0 and ISO 27001 both require encryption of sensitive data in transit. More practically, unencrypted internal traffic means a compromised host can capture credentials and session tokens from adjacent traffic streams through ARP spoofing or misconfigured network mirroring.
TLS 1.3, finalised in RFC 8446, is the current standard for transport encryption. Compared to TLS 1.2, it removes weak cipher suites, mandates forward secrecy on every connection, and reduces the handshake to one round trip in most cases. If you are still accepting TLS 1.0 or 1.1 connections anywhere in your environment, that is a misconfiguration, not a compatibility requirement. Both versions are formally deprecated by RFC 8996 and carry well-documented vulnerabilities.
Mutual TLS (mTLS) extends the standard handshake so that both the client and the server present certificates. In a service-to-service context, each workload has a cryptographic identity, and a service will refuse connections from any caller that cannot present a valid certificate signed by a trusted CA. This eliminates an entire class of lateral movement attack, because a compromised workload lacking the correct certificate cannot authenticate to protected services regardless of network position. The SPIFFE standard defines a framework for workload identity, where each service receives a SPIFFE Verifiable Identity Document (SVID) tied to its deployment context rather than its IP address. Service meshes automate certificate issuance and rotation through integration with SPIFFE/SPIRE or a cloud-native CA, removing the operational burden that makes manual mTLS management impractical at scale. Certificate lifetimes of 24 hours or less reduce the window of exposure if a private key is ever compromised.
For north-south traffic, TLS termination at the load balancer or API gateway is standard practice. For east-west traffic, the choice is between terminating TLS at the service mesh sidecar or implementing TLS natively in each service. The sidecar approach is operationally simpler at scale, but traffic between the sidecar and the local application process runs unencrypted on the loopback interface. Whether that matters depends on your threat model and whether host-level processes other than the application could read that traffic.
Zero Trust Network Architecture in Cloud Environments
Zero trust network access is the model where no network location confers implicit trust. A workload inside the VPC is not trusted more than one outside it. Every access request is evaluated against policy, the requesting identity is verified, the device or workload posture is checked, and access is granted only to the specific resource requested for that session. This is an architectural posture, not a product category. NIST SP 800-207 defines the seven tenets of zero trust architecture, and every major cloud provider has published reference architectures mapping their native services to that framework.
In practice, implementing zero trust network architecture in cloud means four concrete changes. All workloads need explicit identities, whether through IAM roles attached to EC2 instances, Kubernetes service accounts bound to pod identity, or SPIFFE SVIDs issued by a mesh control plane. Access policy is expressed in terms of those identities, not network addresses. All traffic is encrypted and mutually authenticated. Lateral movement is constrained by least-privilege network policy at the workload level, not just at the perimeter.
The alignment with broader cloud security architecture principles is direct: zero trust is not a network-only concern. It spans identity, access management, device policy, and data classification. The network controls described throughout this article represent the network layer of a zero trust model. They are necessary but not sufficient on their own.
One common misconception is that deploying a cloud-native firewall such as AWS Network Firewall or Azure Firewall Premium constitutes zero trust implementation. It does not. These products provide centralised stateful inspection, IDS/IPS rules, and domain-based filtering for north-south and cross-VPC traffic. They are valuable for egress filtering and blocking outbound connections to known malicious domains. But they do not see east-west traffic within a VPC by default, and they do not provide workload-level identity verification. They are one layer of a defence-in-depth model.
VPC Flow Logs and the Network Visibility You Cannot Operate Without
You cannot secure what you cannot see. VPC flow logs in AWS, NSG flow logs in Azure, and VPC flow logs in GCP capture metadata about accepted and rejected traffic: source IP, destination IP, port, protocol, bytes transferred, and whether the traffic was allowed or denied. They do not capture packet payloads, but for incident investigation, detecting unexpected lateral movement, and confirming that security group rules are behaving as intended, flow logs are the foundational visibility layer.
Enable flow logs from day one, not after an incident. Querying them after the fact to reconstruct a three-week-old attack requires that the logs were being collected at the time. Route them to a SIEM or a queryable data store rather than leaving them in S3 buckets that no one opens. A common pattern is routing flow logs to CloudWatch Logs Insights or a security data lake, with periodic queries surfacing anomalies: a database instance initiating outbound connections to external IPs, or a workload communicating on non-standard ports at unusual hours. AWS VPC flow logs support two aggregation intervals: 10-second and 60-second. The 10-second interval increases log volume and cost but provides faster detection fidelity for short-lived connections such as port scans. For most environments, 60-second aggregation paired with a stream to a real-time analytics pipeline gives adequate detection latency at manageable cost.
For teams building network detection capability, flow logs feed detection rules for port scanning, data exfiltration signatures, and compromised instance behaviour such as internal hosts querying known command-and-control infrastructure. The detection logic is only as good as the coverage, and coverage requires flow logs enabled on every subnet and VPC in the environment, not just the ones someone remembered to configure.
This visibility requirement connects directly to your hybrid cloud security posture. When traffic crosses ExpressRoute or Direct Connect links between on-premises and cloud environments, telemetry gaps at the boundary are common and create exactly the kind of blind spot attackers use to move between environments undetected.
Egress Filtering: A Critical Cloud Network Security Control
Most cloud environments have carefully controlled inbound rules and almost no outbound filtering. From a data protection perspective, this is the wrong priority. An attacker who has already compromised a workload is not trying to get in; they are already there. They are trying to get data out. Egress filtering is what constrains that path.
The starting point is restricting internet egress from private subnets. Traffic leaving a private subnet should route through a NAT gateway, not directly to an internet gateway, and the NAT gateway should be complemented by DNS-based egress filtering. AWS Route 53 Resolver DNS Firewall blocks outbound DNS queries to known malicious domains at the resolver level, before a TCP connection is attempted. Combined with AWS Network Firewall domain-based filtering, you can restrict outbound HTTPS to an allow-list of known destinations rather than permitting all outbound traffic on port 443.
Cloud storage services deserve specific attention in any cloud network security programme. An attacker with access to an EC2 instance and an overly permissive IAM role can exfiltrate data by copying it to an S3 bucket they control. VPC Endpoint Policies restrict which S3 buckets can be accessed from within a VPC. AWS Organizations Service Control Policies (SCPs) can prevent any principal in your organisation from copying data to buckets outside it. These controls are enforced independently of bucket policies, which matters because an attacker who has compromised a role with broad S3 permissions cannot bypass organisation-level SCPs.
Frequently Asked Questions
What is cloud network security?
Cloud network security is the collection of controls and policies that protect data in transit, isolate workloads from each other, and restrict communication paths inside a cloud environment. It spans virtual network design, security groups, encryption in transit, east-west traffic controls, and network telemetry, covering traffic within a single VPC as much as traffic crossing cloud or hybrid boundaries.
What is micro-segmentation?
Micro-segmentation enforces access controls at the individual workload level rather than at a shared network perimeter. Instead of relying on subnet boundaries, each server, container, or service has explicit rules governing what it can communicate with. This limits lateral movement after a breach by preventing a compromised workload from reaching adjacent systems it has no legitimate reason to contact.
How do you secure east-west traffic in the cloud?
East-west traffic requires workload-level controls because it never crosses a traditional perimeter. Security groups referencing other security groups by ID, Kubernetes NetworkPolicy objects with default-deny baselines, and mutual TLS enforced by a service mesh are the primary mechanisms. VPC flow logs provide visibility, and anomaly detection on that telemetry surfaces lateral movement attempts before they reach sensitive data.
Are security groups enough for cloud network security?
Security groups are a necessary control but not a complete cloud network security strategy. They filter traffic at the workload level but do not inspect payloads, enforce egress filtering to external destinations, or generate network telemetry. A complete posture adds encryption in transit, VPC flow log analysis, egress controls, and a service mesh for east-west visibility.
