Cloud attack paths usually begin with something reachable that should not be, such as an open management port, a permissive security group or a public bucket, and these settings can change with every deployment. Cloud network security is the set of controls, architectures and processes that protect traffic, connectivity, workloads and access paths across public, private and hybrid cloud environments. It decides how virtual networks are segmented, which resources can reach the internet, how services talk to each other east-west, and who is allowed to change any of it. This October 2026 guide covers cloud network security architecture, risks by layer, a step-by-step implementation framework and the tool categories that enforce and monitor it.
Key takeaways
- ✓Cloud network security protects traffic, connectivity, workloads and access paths, and in IaaS the customer, not the provider, configures nearly all of it.
- ✓A secure cloud network separates public, application and data tiers into distinct subnets and uses private endpoints so internal services never need public IPs.
- ✓Identity is part of the network perimeter, because an over-permissioned role can open a security group faster than an attacker can scan for one.
- ✓Flow logs, DNS logs and audit logs sent to a SIEM are the minimum observability baseline for detecting lateral movement and misconfiguration.
- ✓Runtime context shows which exposed workloads are actually running and communicating, which separates real attack paths from theoretical ones.
What is cloud network security?
Cloud network security controls who and what can reach cloud resources, over which paths, and with what level of trust. In a data center, a hardware firewall at the edge did most of this work. In the cloud, the network is software-defined, so every security group, route table and peering link is an API call that any engineer or pipeline can change.
The CSA Security Guidance for Cloud Computing treats infrastructure and network security as its own domain, covering software-defined networks (SDN), security groups and the wider infrastructure footprint. The provider secures the physical network. The customer secures everything they configure on top of it, and that share changes with the service model.
| Model | Provider secures | Customer secures |
|---|---|---|
| IaaS (EC2, Azure VMs, Compute Engine) | Physical hosts, hypervisor, backbone network | VPCs, subnets, security groups, NACLs, routing, OS, encryption, IAM |
| PaaS (RDS, App Service, Cloud Run) | Runtime, OS patching, underlying network | Network access rules, private endpoints, identities, data, app config |
| SaaS (Microsoft 365, Salesforce) | Application, infrastructure, most network controls | User access, MFA, data sharing settings, conditional access |
Cloud network security architecture
The architecture combines network isolation, traffic filtering, private connectivity and identity-aware access in layers that control every path into and between workloads.
| Component | What it does | Examples |
|---|---|---|
| VPC / VNet and subnets | Isolated address space split into public and private tiers | AWS VPC, Azure VNet, GCP VPC |
| Security groups | Stateful, instance-level allow rules | AWS security groups, Azure NSGs, GCP firewall rules |
| Network ACLs | Stateless subnet-level allow and deny rules | AWS NACLs |
| Internet and NAT gateways | Controlled inbound access and outbound-only egress | AWS NAT Gateway, Azure NAT Gateway, Cloud NAT |
| Private endpoints | Reach PaaS services without public IPs | AWS PrivateLink, Azure Private Endpoint, Private Service Connect |
| Load balancers and WAF | Terminate TLS and filter Layer 7 attacks | ALB with AWS WAF, Azure Application Gateway, Cloud Armor |
| Hybrid connectivity and transit | Link on-prem, branches and VPCs through a hub | Site-to-site VPN, Direct Connect, ExpressRoute, Transit Gateway |
| Service mesh and ZTNA | mTLS between services; per-app, identity-based user access | Istio, Linkerd, zero trust network access brokers |
Reference architecture for a secure multi-tier environment
- Place only load balancers and the WAF in public subnets with an internet gateway.
- Put application servers or Kubernetes nodes in private subnets that egress through a NAT gateway or an egress firewall with domain allow-lists.
- Isolate databases in a data subnet whose security group accepts traffic only from the app tier’s security group ID, never from CIDR ranges like 0.0.0.0/0.
- Reach storage, key vaults and managed databases through private endpoints.
- Route spoke VPCs through a hub (Transit Gateway or Azure Virtual WAN) with centralized inspection, instead of building full-mesh peering.
- Replace bastion hosts and open SSH/RDP with ZTNA or session tools such as AWS Systems Manager Session Manager or Azure Bastion.
- Enforce microsegmentation inside Kubernetes with NetworkPolicies and mesh mTLS.
| Criterion | Security groups | Network ACLs |
|---|---|---|
| Scope | Instance or interface | Subnet |
| State | Stateful: return traffic allowed automatically | Stateless: both directions need rules |
| Rules | Allow only | Allow and deny, evaluated in number order |
| Best use | Primary workload-level control | Coarse guardrail, such as blocking a known-bad range |
For hybrid links, site-to-site VPN is fast to set up but runs over the internet. Direct Connect, ExpressRoute and Cloud Interconnect give private, predictable bandwidth but are not encrypted by default, so add MACsec or IPsec. Private Link-style services expose a single service rather than a whole network, which makes them the narrowest option.
Cloud network security risks and attack paths
Cloud network risks sit in five layers, and real attacks chain weaknesses across several of them.
| Layer | Typical risk |
|---|---|
| Identity | Over-permissioned roles that can modify security groups or routes; long-lived access keys; missing MFA |
| Network | 0.0.0.0/0 inbound rules, misconfigured VPC peering, flat networks with no segmentation |
| Workload | Vulnerable packages on internet-facing VMs or containers; privileged pods |
| Application | Unauthenticated APIs, missing WAF rules, server-side request forgery to metadata endpoints |
| Data | Public object storage, unencrypted traffic to databases, unrestricted egress for exfiltration |
Common attack paths include:
- Exposed management ports (22, 3389, 6443 for the Kubernetes API) open to the internet.
- Open S3 buckets, Azure Blob containers or GCS buckets with public read.
- Lateral movement between workloads over unencrypted, unfiltered east-west traffic.
- Peering that connects a dev VPC to production with permissive routes.
- Weak remote access through shared VPN credentials without device posture checks.
Worked example: a security group allows port 22 from 0.0.0.0/0 on a VM with a known SSH vulnerability, and the VM’s instance role holds s3:* on all buckets. Each finding alone looks medium severity. Together they form a direct path from the internet to your data, so prioritize by chained exposure instead of individual score.
Cloud network security best practices
Start with default-deny segmentation and least-privilege identity, then add encryption, continuous monitoring and policy checks in the pipeline.
- Inventory every account, subscription, project, VPC and public IP across AWS, Azure and GCP.
- Define a landing zone with hub-and-spoke routing and centralized egress.
- Apply default-deny security groups and reference other groups instead of CIDR ranges.
- Move PaaS access to private endpoints and remove public endpoints.
- Enforce least privilege, MFA and short-lived credentials for anyone who can change network resources.
- Turn on flow, DNS and audit logging in every region.
- Codify the rules as policy and block non-compliant changes before deployment.
Encryption and key management
Encrypt data in transit with TLS 1.2 or later and mTLS between services, and at rest with KMS-managed keys (AWS KMS, Azure Key Vault, Cloud KMS) or HSM-backed keys for regulated data. TLS inspection at an egress firewall improves visibility but breaks certificate pinning and creates a high-value decryption point, so exclude sensitive categories. Automate certificate issuance and rotation with ACM, Key Vault certificates or cert-manager so expiring certificates do not cause outages.
Observability and response
Enable VPC Flow Logs or NSG flow logs, Route 53 Resolver or Azure DNS logs, and CloudTrail, Azure Activity Logs or Cloud Audit Logs. Forward them to a cloud SIEM and alert on new 0.0.0.0/0 rules, unusual east-west connections, DNS queries to newly registered domains and spikes in egress volume. Write response runbooks that isolate a workload by swapping its security group rather than deleting it, so forensic evidence survives.
DevSecOps and policy as code
Scan Terraform, CloudFormation and Bicep with tools like Checkov, tfsec or Open Policy Agent before merge. Pair this with AWS Service Control Policies, Azure Policy or GCP Organization Policy as runtime guardrails, so a manual console change cannot reopen what the pipeline blocked.
Microsoft Cloud Security Benchmark (MCSB) and the Azure security baseline
The Microsoft Cloud Security Benchmark is Microsoft’s set of security controls and recommendations for assessing cloud posture across Azure, AWS and GCP through Defender for Cloud. Its network guidance covers segmentation, hub-and-spoke designs, Azure Firewall, Private Endpoints and centralized logging. The Azure security baselines apply those controls to individual Azure services and include Azure Policy definitions to measure and enforce them. Network controls also map to regulatory requirements:
| Framework | Network controls that support it |
|---|---|
| PCI DSS | Segmenting the cardholder data environment, firewall rule reviews, TLS in transit |
| HIPAA | Encryption of ePHI in transit, access controls, audit logging |
| GDPR | Data residency through regional VPCs, encryption, breach detection |
| ISO 27001 / SOC 2 | Network security controls, change management, continuous monitoring evidence |
For practitioners, ISC2’s CCSP is the broadest vendor-neutral certification, CSA’s CCSK is a lighter starting point, and AWS Security Specialty, Google Professional Cloud Security Engineer and AZ-500 cover platform-specific network controls.
Cloud network security tools by function
Each category of tool covers one part of the problem: configuration, identity, workloads, traffic or access. For a wider overview, see these types of cloud security tools.
| Category | Network security role |
|---|---|
| CSPM | Finds open security groups, public buckets and risky peering |
| CIEM / IAM | Finds over-permissioned and unused identities that can change network rules |
| CWPP | Protects VMs, containers and serverless workloads at runtime |
| CNAPP | Combines CSPM, CWPP, CIEM and detection and correlates them into attack paths |
| Firewalls and WAF | Filter north-south and Layer 7 traffic (AWS Network Firewall, Azure Firewall, Cloud Armor) |
| ZTNA, SWG, CASB | Identity-based user access, web egress filtering and SaaS control |
| Secrets and key management | Store credentials and keys (HashiCorp Vault, AWS Secrets Manager, KMS) |
| Approach | Strength | Limit |
|---|---|---|
| Agentless (API and snapshot) | Fast, broad inventory and configuration coverage | Point-in-time; cannot see live connections or loaded processes |
| Agent or sensor-based (eBPF) | Real-time process, network flow and syscall visibility | Needs node access; does not run on Fargate or fully managed serverless |
Cloud-native services such as AWS GuardDuty, Inspector, Security Hub, Microsoft Defender for Cloud and Google Security Command Center go deep inside their own provider. Third-party platforms unify findings across clouds, which matters when policy and routing have to stay consistent across AWS, Azure, GCP and on-prem. When comparing CNAPP tools, check whether they combine agentless discovery with runtime sensing.
How Upwind adds runtime context to cloud network security
Upwind is a runtime-first CNAPP that pairs agentless cloud discovery with lightweight eBPF sensors on VMs, containers and Kubernetes nodes (EKS, AKS, GKE and OKE), so it sees which workloads are actually running and communicating instead of inferring exposure from configuration alone. One reviewer on Gartner Peer Insights, where Upwind holds 4.8/5 from 88 reviews as of October 2026, valued “the ability to see exactly how resources are communicating.” Teams running mostly on AWS Fargate or other node-less serverless platforms get less runtime depth, because the sensor needs node-level access.
- ✓Sees network flows, system calls and API activity at the kernel level
- ✓Threat Stories show a timeline, root cause and response recommendations
- ✓CIEM flags over-permissioned roles, unused permissions and toxic combinations
- ✓IaC scanning covers Terraform and CloudFormation and traces runtime findings back to code
- ✓Integrates with ServiceNow, Jira, PagerDuty, AWS Security Hub and Microsoft Sentinel playbooks for container isolation
Cloud network security checklist
These checks turn the architecture and practices above into a repeatable routine for new deployments, audits and multi-cloud hardening.
- ✓New deployment: private subnets by default, no public IPs on app or data tiers, private endpoints for PaaS, flow logs on.
- ✓Audit: list every 0.0.0.0/0 rule, public bucket, peering link and unused role; confirm each has an owner.
- ✓Multi-cloud: one policy baseline mapped to AWS SCPs, Azure Policy and GCP Organization Policy, with logs from all three in one SIEM.
- ✓Remote access: ZTNA or session managers instead of open SSH/RDP and shared VPN accounts.
Track these KPIs every month:
- ✓Percentage of internet-exposed assets
- ✓Mean time to detect and remediate a misconfiguration
- ✓MFA coverage for identities that can modify network resources
- ✓Number of privileged accounts
- ✓Segmentation policy coverage across VPCs and Kubernetes namespaces
Strong cloud network security comes from treating the network as code. Segment by default, give identities only the access they use, log every flow and change, and fix first the exposures that runtime evidence shows are actually reachable.
FAQ
What is cloud network security?
Cloud network security is the set of controls, architectures, and processes that protect traffic, connectivity, workloads, and access paths across public, private, and hybrid cloud environments. It controls who and what can reach cloud resources, over which paths, and with what level of trust.
Who is responsible for cloud network security?
The cloud provider secures the physical network and underlying infrastructure, but the customer secures the network resources they configure on top of it. In IaaS, that includes VPCs, subnets, security groups, routing, OS settings, encryption, and IAM. In PaaS and SaaS, the customer still controls access rules, identities, and data-sharing settings.
What does a secure cloud network architecture look like?
A secure cloud network separates public, application, and data tiers into distinct subnets. Only load balancers and WAFs should sit in public subnets, while application workloads and databases stay in private subnets. Internal services should use private endpoints instead of public IPs, and remote admin access should use ZTNA or session tools instead of open SSH or RDP.
What are the most common cloud network security risks?
Common risks include inbound rules open to 0.0.0.0/0, exposed management ports such as 22 or 3389, public storage buckets, flat networks with little segmentation, misconfigured peering, over-permissioned roles that can change security settings, and weak remote access controls. Real attacks often chain several of these weaknesses together.
What logs are the minimum baseline for cloud network security monitoring?
The article recommends enabling flow logs, DNS logs, and audit logs in every region, then forwarding them to a cloud SIEM. This baseline helps detect lateral movement, misconfigurations, unusual east-west traffic, suspicious DNS activity, and spikes in egress volume.