Cloud Network Security

Cloud network security encompasses the technical controls, architectural frameworks, and regulatory obligations that govern the protection of data, workloads, and communications within cloud-hosted infrastructure. This page describes the service landscape, structural mechanics, classification boundaries, and professional standards relevant to organizations deploying or evaluating cloud network security in the United States. The field intersects federal compliance mandates, provider-shared responsibility models, and evolving zero trust principles that collectively define how cloud environments are secured at the network layer.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Checklist or steps
• Reference table or matrix
• References

Definition and scope

Cloud network security refers to the set of policies, technologies, and controls applied to protect the network infrastructure, traffic flows, and communication pathways of cloud computing environments. As defined within NIST SP 800-145, cloud computing is a model for enabling ubiquitous, on-demand network access to a shared pool of configurable computing resources — and the security of those resources at the network layer is a discrete discipline from endpoint, application, or physical security.

The scope of cloud network security spans five primary domains: perimeter definition and segmentation, traffic inspection and filtering, identity-bound access control, encryption of data in transit, and threat detection across distributed cloud-native infrastructure. Unlike traditional on-premises network security, the perimeter in cloud environments is logical rather than physical, making boundary enforcement dependent on software-defined controls rather than hardware appliances.

The network security providers on this platform reflect the range of providers and practitioners operating across these five domains within the United States market.

Regulatory scope is defined by multiple frameworks. The Federal Risk and Authorization Management Program (FedRAMP) establishes baseline security requirements for cloud services used by federal agencies, requiring controls mapped to NIST SP 800-53 Rev. 5. The Health Insurance Portability and Accountability Act (HIPAA) Security Rule, administered by the HHS Office for Civil Rights (45 CFR Part 164), extends network security obligations to cloud environments processing protected health information. The Payment Card Industry Data Security Standard (PCI DSS v4.0), published by the PCI Security Standards Council, mandates network segmentation and access controls for cloud-hosted cardholder data environments.

Core mechanics or structure

Cloud network security operates through layered controls applied at distinct functional points within cloud infrastructure. The architectural structure follows a defense-in-depth model, wherein each layer independently enforces policy even if an adjacent layer is compromised.

Virtual Private Clouds (VPCs) and Network Segmentation. Cloud providers implement isolated virtual networks — termed Virtual Private Clouds by AWS and equivalent constructs by Azure and Google Cloud Platform — that establish logical boundaries between workloads. Segmentation within VPCs uses subnets, route tables, and network access control lists (NACLs) to limit lateral movement.

Security Groups and Stateful Filtering. Security groups function as distributed stateful firewalls applied at the virtual machine or container interface level. Unlike NACLs, which evaluate each packet independently, security groups track connection state and apply rules to traffic flows, enabling more precise control of east-west traffic within cloud environments.

Encryption in Transit. Transport Layer Security (TLS), currently at version 1.3, is the baseline standard for encrypting network communications. NIST SP 800-52 Rev. 2 provides federal guidance on TLS configuration, prohibiting TLS 1.0 and 1.1 for federal systems.

Cloud-Native Firewalls and Web Application Firewalls (WAFs). Cloud-native firewalls operate at the network edge and inspect traffic based on rule sets. WAFs are applied at Layer 7 of the OSI model, filtering HTTP/S traffic against known attack signatures and behavioral anomalies.

DNS Security and DDoS Mitigation. DNS-layer security controls prevent resolution of known malicious domains. Distributed Denial of Service (DDoS) mitigation services — typically implemented at the cloud provider's edge — absorb volumetric attacks before they reach hosted workloads.

Zero Trust Network Access (ZTNA). ZTNA replaces implicit VPN-based trust with identity-verified, policy-enforced access to specific resources. NIST SP 800-207 defines the zero trust architecture model that underpins ZTNA deployment in both federal and commercial cloud environments.

Causal relationships or drivers

The growth and complexity of cloud network security as a discipline is attributable to four structural forces operating simultaneously.

Migration velocity and attack surface expansion. As workloads migrate from on-premises data centers to cloud environments, the total network attack surface increases in proportion to the number of public-facing endpoints, APIs, and interconnected services. The Cloud Security Alliance (CSA) identifies misconfiguration as the leading cause of cloud security incidents in its annual Top Threats reports, with exposed storage buckets and overly permissive security group rules cited as primary vectors.

Shared responsibility ambiguity. Cloud service providers define security responsibility in terms of a shared responsibility model — providers secure the underlying infrastructure, while customers secure their configurations, data, and network controls. Misunderstanding this boundary is a documented driver of breaches. The FedRAMP Authorization Boundary Guidance formalizes boundary delineation for federal cloud deployments.

Regulatory expansion. Federal and state mandates have proliferated. The Cybersecurity and Infrastructure Security Agency (CISA) Binding Operational Directive 22-01 required federal agencies to remediate known exploited vulnerabilities — a directive with direct implications for cloud-hosted systems. Executive Order 14028 (May 2021) mandated zero trust adoption across federal civilian agencies, creating downstream demand for ZTNA-capable cloud network architectures.

Multi-cloud and hybrid complexity. Organizations operating across 2 or more cloud providers face compounded network security challenges — inconsistent control plane APIs, differing identity federation models, and fragmented visibility across environments. The NIST Cybersecurity Framework (CSF) 2.0 addresses governance of multi-cloud environments within its Govern function tier.

Classification boundaries

Cloud network security is classified along three primary axes: deployment model, service model, and control ownership.

By deployment model: Public cloud, private cloud, hybrid cloud, and multi-cloud each present distinct network security profiles. Public cloud environments rely on provider-managed physical infrastructure with customer-managed logical controls. Private clouds extend on-premises security models into dedicated cloud infrastructure. Hybrid and multi-cloud deployments require policy consistency across environments with heterogeneous control planes.

By service model: Infrastructure as a Service (IaaS) gives customers the broadest network control surface, including OS-level firewall configuration, routing, and VPC design. Platform as a Service (PaaS) abstracts network controls, leaving customers responsible for application-layer security. Software as a Service (SaaS) transfers nearly all network control to the provider, leaving customers responsible only for access policy and identity management.

By control ownership: Controls are classified as provider-managed (physical network, hypervisor isolation), shared (DDoS mitigation, availability zone design), or customer-managed (security groups, NACLs, VPC peering, TLS configuration, WAF rules). The AWS Shared Responsibility Model, Microsoft Azure's equivalent documentation, and Google Cloud's published model each present provider-specific interpretations of this boundary.

The network security provider network purpose and scope page provides additional context on how cloud network security practitioners are categorized within this reference resource.

Tradeoffs and tensions

Cloud network security involves a set of structural tensions that practitioners and procurement teams navigate without universal resolution.

Visibility versus performance. Deep packet inspection (DPI) and full-flow logging generate the visibility necessary for threat detection but introduce latency and storage costs. High-throughput environments may disable or sample logging, creating blind spots. NIST SP 800-92 (Guide to Computer Security Log Management) establishes log retention and coverage expectations that conflict with cost optimization objectives.

Segmentation granularity versus operational complexity. Micro-segmentation — enforcing policy at the workload or container level — reduces blast radius but multiplies the number of policy rules that must be maintained. Misconfiguration risk increases proportionally with segmentation granularity.

Native provider controls versus third-party tooling. Cloud-native security services are deeply integrated with provider infrastructure but create vendor lock-in and may not align with policies enforced in other cloud environments. Third-party security tools offer portability but introduce integration overhead and additional attack surface.

Encryption coverage versus inspection capability. End-to-end TLS encryption protects data in transit but prevents intermediate inspection by WAFs and intrusion detection systems unless TLS inspection (decryption and re-encryption) is implemented — a practice that introduces its own key management and trust chain risks, as addressed in NIST SP 800-52 Rev. 2.

Zero trust maturity versus operational continuity. Migrating from perimeter-based to zero trust network architectures requires reconfiguring access policies for every application and user segment. Organizations with legacy cloud architectures face disruption risk during transition periods that can extend 18 to 36 months depending on environment complexity.

Common misconceptions

Misconception: The cloud provider secures the network.
Cloud providers secure the physical network infrastructure and hypervisor layer. Network controls within the customer's VPC — security group rules, NACLs, routing tables, and TLS configuration — are entirely customer-managed under all three major providers' documented shared responsibility models. Provider documentation explicitly excludes customer-configured network controls from provider-managed security scope.

Misconception: A VPN is equivalent to cloud network security.
VPN tunnels encrypt traffic between endpoints but do not provide network segmentation, traffic inspection, lateral movement controls, or threat detection within cloud environments. VPN connectivity is one component of a cloud network security architecture, not a substitute for it.

Misconception: FedRAMP authorization means a service is fully secure for all use cases.
FedRAMP authorization confirms that a cloud service meets a defined set of baseline controls mapped to NIST SP 800-53 at the Low, Moderate, or High impact level. It does not guarantee that a customer's specific configuration of that service meets those same baselines. The FedRAMP Program Management Office explicitly requires agencies to review customer responsibility matrices before assuming compliance inheritance.

Misconception: Cloud-native DDoS protection eliminates DDoS risk.
Cloud provider DDoS mitigation services protect against volumetric Layer 3 and Layer 4 attacks. Application-layer (Layer 7) DDoS attacks — which mimic legitimate traffic — require WAF and behavioral analysis controls that are separate from volumetric DDoS mitigation and are not automatically included in baseline cloud subscriptions.

Checklist or steps

The following sequence describes the discrete phases of a cloud network security implementation as documented across NIST, FedRAMP, and CSA reference frameworks. This is a structural description of the process, not prescriptive advice.

1. Define the authorization boundary. Identify all cloud assets, services, and data flows included in scope, following the FedRAMP Authorization Boundary Guidance methodology for federal systems or equivalent organizational asset inventory procedures.

2. Apply VPC segmentation and subnet isolation. Separate workloads by trust zone (public, private, restricted) using distinct subnets, with routing rules that enforce zone-to-zone traffic policies.

3. Configure stateful security groups and NACLs. Define ingress and egress rules at both the subnet (NACL) and instance/container (security group) levels, adhering to least-privilege principles as specified in NIST SP 800-53 Rev. 5 Control AC-6.

4. Enable full-flow logging and centralized log aggregation. Activate VPC flow logs, DNS query logs, and WAF logs. Route logs to a centralized security information and event management (SIEM) system with retention aligned to applicable regulatory requirements.

5. Enforce TLS 1.2 minimum (TLS 1.3 preferred) on all endpoints. Disable TLS 1.0, TLS 1.1, and SSL 3.0 on all load balancers, API gateways, and service endpoints per NIST SP 800-52 Rev. 2 requirements.

6. Deploy WAF with ruleset mapped to OWASP Top 10. Configure Layer 7 inspection rules covering the OWASP Top 10 vulnerability categories, including injection, broken access control, and security misconfiguration.

7. Implement identity-based network access controls. Replace implicit network-location trust with verified identity claims for all service-to-service and user-to-service access, consistent with NIST SP 800-207 zero trust principles.

8. Conduct continuous configuration drift detection. Automated scanning for security group rule changes, public bucket exposure, and routing anomalies — aligned with CSA Cloud Controls Matrix domain DSP-01 through DSP-07.

9. Document and test incident response procedures for cloud network events. Define runbooks for VPC isolation, traffic rerouting, and forensic log preservation specific to cloud provider APIs, per NIST SP 800-61 Rev. 2.

The how to use this network security resource page provides guidance on locating practitioners and services aligned to these implementation phases.

Reference table or matrix