Cloud Network Security Guide: VPCs and Security Groups

Cloud network security fails quietly: one security group rule open to 0.0.0.0/0, one subnet routed to an internet gateway or one endpoint policy left at its full-access default is enough to expose a workload that every other control assumed was private. Unlike a data centre, every network object in AWS, Azure and Google Cloud is an API call away from changing, so network security is as much about defaults, guardrails and change detection as about rule design. This guide covers VPC and subnet design, security groups and network ACLs, Azure network security groups and Google Cloud firewall rules, private endpoints and PrivateLink, peering, transit gateways and hub-and-spoke designs, and egress control. It is for cloud network engineers, platform teams and security architects.

Key takeaways

• Routes decide exposure before rules do. A subnet is public because its route table points at an internet gateway; review routes, then security groups.
• Know which layer is stateful. Security groups, NSGs and Google Cloud firewall rules track connections; AWS network ACLs do not, and evaluate numbered rules in order.
• Private endpoints are not private by default. AWS endpoint policies start at full access, and an Azure private endpoint does not by itself switch off the public endpoint.
• Connectivity is not transitive, isolation is not automatic. Peering never routes through a third network, but a transit gateway's default route table lets every attachment reach every other.
• Egress is where data leaves. Default outbound rules allow everything on all three clouds; inspect and restrict egress centrally, including DNS.

The building blocks on AWS, Azure and Google Cloud

The three providers use different names for similar objects, and the differences in default behaviour matter more than the names.

VPC design and subnet exposure

• Separate networks by workload: AWS advises: "Use separate VPCs to isolate infrastructure by workload or organizational entity." Use subnets to separate tiers (web, application, database) inside one VPC, and private subnets for anything that should not be reached directly from the internet.
• Define public precisely: an AWS subnet is public when its route table has a route to an internet gateway. A private VPC subnet has no such route, even if instances in it carry public IP addresses. VPC subnet exposure reviews should therefore start with route tables and public IP assignment, not security group names.
• Plan address space early: AWS will not peer VPCs "that have matching or overlapping IPv4 or IPv6 CIDR blocks". Allocate non-overlapping ranges per account and Region from a central plan, so future peering or transit attachments do not force NAT workarounds.
• Keep the default network out of production: the AWS default VPC and the Google Cloud default network are built for convenience. The Google Cloud default network "is pre-populated with firewall rules that allow incoming connections to instances" (default-allow-internal, default-allow-ssh, default-allow-rdp, default-allow-icmp at priority 65534).

The Network Segmentation Guide covers zone design and microsegmentation in depth; this guide focuses on the cloud objects that implement it.

Security groups and network ACLs

Every provider has a cloud security group equivalent, but their defaults and evaluation order differ.

Security group rules that hold up

• Security group ingress: never allow 0.0.0.0/0 or ::/0 to administration ports (22, 3389) or database ports. CIS AWS Foundations Benchmark v5.0.0 requirements 5.3 and 5.4 (Security Hub CSPM controls EC2.53 and EC2.54) ("EC2 security groups should not allow ingress from 0.0.0.0/0 to remote server administration ports", and the same for ::/0) check IPv4 and IPv6 separately, and 5.2 (EC2.21) checks NACLs for 22 and 3389. Use a bastion service or session manager instead of open SSH.
• Reference groups, not addresses: an application tier rule that allows traffic from the web tier's security group survives scaling and IP changes. Within a Region, AWS lets you "reference a security group from the peer VPC" across a peering connection.
• Security group egress: the default outbound rule "allows all traffic". Replace it on sensitive tiers with rules to the specific endpoints, proxies or prefix lists the workload needs.
• Default security group: it cannot be deleted, and AWS attaches it to resources launched without a group. Remove all its rules so accidental attachment means no connectivity. CIS v5.0.0 requirement 5.5 (Security Hub EC2.2: "VPC default security groups should not allow inbound or outbound traffic") tests this.
• Azure NSGs: custom rules sit between 100 and 4096; the defaults AllowVNetInBound (65000) and AllowInternetOutBound (65001) are permissive, so add explicit deny rules above them, as the Azure hub-spoke reference architecture advises. Use application security groups instead of IP lists, and Azure Virtual Network Manager security admin rules, which are "evaluated first", for organisation-wide baselines.
• Google Cloud targets: a network tag is "an arbitrary attribute" that anyone allowed to edit the instance can change, so a user who can edit a VM can move it into a more permissive rule. Target rules by service account for anything sensitive, and put rules that must never be overridden in hierarchical firewall policies.

Security group bypass: paths the rules never see

Teams often assume that a tight security group means a workload can only talk to what the rules allow. AWS documents that security groups "do not filter traffic destined to and from" Amazon DNS, DHCP, EC2 instance metadata, ECS task metadata endpoints, Windows licence activation, the Amazon Time Sync Service and reserved router addresses. Three practical consequences follow.

• DNS as an exit: a workload with no outbound rules can still resolve names through the VPC resolver, so DNS needs its own control, such as Route 53 Resolver DNS Firewall or a forced resolver path in Azure and Google Cloud, with query logging.
• Metadata as a credential source: the metadata service is reachable whatever the rules say. Require IMDSv2 and keep workload roles narrow; see the Cloud Misconfiguration Guide.
• Control-plane access ignores the network: anyone holding credentials can call public service endpoints from anywhere unless resource or IAM policies require a VPC endpoint or source network. Network rules and identity policies must be designed together.

Private endpoints, PrivateLink and endpoint policies

Private connectivity lets workloads reach platform services without an internet path. The NSA and CISA cloud mitigation sheet on segmentation recommends private connectivity and notes that "some CSPs offer private API endpoints that customers can use".

• VPC endpoint types: gateway endpoints send traffic to S3 or DynamoDB through route tables and "do not use AWS PrivateLink"; interface endpoints create network interfaces in your subnets; Gateway Load Balancer endpoints steer traffic to inspection appliances; resource and service-network endpoints reach resources shared from other VPCs.
• AWS PrivateLink services: a provider publishes an endpoint service behind a load balancer. It is "not available to service consumers" until the provider allows specific principals, and connection requests can require manual acceptance. Keep acceptance manual for anything that exposes internal data.
• VPC endpoint policy: a resource-based policy on the endpoint that "does not override or replace identity-based policies or resource-based policies". The default "grants full access", so a compromised workload can use your endpoint to reach any bucket in any account. Restrict principals and resources, for example to buckets in your organisation, within the 20,480-character limit.
• VPC endpoint conditions: on the resource side, an S3 bucket policy that denies requests unless aws:SourceVpce matches your endpoint ID makes the endpoint the only path. Note that aws:SourceIp is absent for requests through a VPC endpoint, so IP-based conditions silently stop matching.
• Azure Private Endpoint: "a network interface that uses a private IP address from your virtual network". Microsoft notes that private endpoints "don't necessarily restrict public network access", so disable public network access on the target resource separately, and configure private DNS zones so the service name resolves to the private IP. Private endpoints support NSGs and user-defined routes through network policies.
• VPC link: Amazon API Gateway's VPC link connects a public or private API to resources inside a VPC. Treat it as an ingress path into the VPC and include it in exposure reviews.

VPC-isolated AI deployment

AI workloads often send sensitive prompts and documents to a model service. On AWS, Amazon Bedrock can be reached "without the use of an internet gateway, NAT device, VPN connection, or Direct Connect connection" through interface endpoints such as com.amazonaws.region.bedrock-runtime, and the default endpoint policy again "allows full access". A VPC-isolated AI deployment combines a private subnet with no internet route, interface endpoints for the model runtime and any vector store or storage, endpoint policies limited to actions such as bedrock:InvokeModel, and deny-unless-endpoint conditions on the data stores. Apply the same pattern with Private Endpoints on Azure and Private Service Connect on Google Cloud. See the AI Infrastructure Workload Identity Guide for the identity side.

Connecting networks: peering, transit gateways and hub-and-spoke

• VPC attachment design: for a transit gateway, create separate route tables for production, non-production and shared services, disable default association and propagation, and propagate only what each segment should reach. AWS describes this as "multiple isolated routers". Enable appliance mode on the inspection VPC attachment so stateful firewalls see both directions of a flow.
• Hub and spoke network: Microsoft's reference architecture places shared services, Azure Firewall as "the primary egress point", gateways and Azure Bastion in the hub, and recommends peering each spoke to a single hub. Turn on DDoS Protection for the hub's public IP addresses.
• Shared VPC roles: separate the Network Admin (compute.networkAdmin, which excludes firewall rules) from the Security Admin (compute.securityAdmin), and grant compute.networkUser at subnet level.

Egress control: internet gateways, NAT and inspection

A NAT gateway lets "instances in a private subnet ... connect to services outside your VPC but external services can't initiate a connection". It prevents inbound exposure; it does not filter what leaves. Effective egress control needs three layers:

1. Central path: send all internet-bound traffic from spokes through an inspection VPC or hub firewall (AWS Network Firewall behind a Gateway Load Balancer or transit gateway, Azure Firewall, or Google Cloud firewall policies with Cloud NAT), and give workload VPCs no internet gateway of their own.
2. Allow-lists: filter by domain or service tag where possible. Azure recommends Azure Firewall Premium for TLS inspection, IDPS and URL filtering.
3. Platform services privately: move storage, secrets and model traffic to endpoints so the egress allow-list stays short.

Google Cloud blocks egress to TCP port 25 by default; treat such provider defaults as a bonus, not a control. See the Data Exfiltration Guide.

Implementation roadmap

1. Inventory: list every VPC, VNet and subnet with its route tables, internet gateways, public IPs, peering, transit attachments and endpoints, by account and owner.
2. Close the obvious: remove 0.0.0.0/0 and ::/0 ingress to administration and database ports, strip default security group rules and retire default networks.
3. Turn on telemetry: enable flow logs on all VPCs (CIS v5.0.0 3.7, Security Hub EC2.6) and VNets, and resolver query logs, sent to central logging.
4. Add guardrails: AWS Firewall Manager or SCPs, Azure Policy and Virtual Network Manager security admin rules, and Google Cloud hierarchical firewall policies, deployed in audit or detect mode first.
5. Segment connectivity: move from peering meshes or default transit route tables to segmented route tables and a hub, one environment at a time.
6. Restrict egress and endpoints: introduce inspection and endpoint policies, starting with non-production. Use flow logs from the previous step to build allow-lists.

Testing and rollback: stage route table and rule changes in a non-production account with the same template, watch rejected flows in flow logs for a full business cycle, and keep the previous route table or rule set in infrastructure-as-code so rollback is a revert and redeploy. Network changes affect every workload behind them, so use change windows for transit and hub changes.

Decision guidance

• Security group or NACL: use security groups as the primary control. Add NACLs only for coarse subnet-level denies (blocking a known bad range, or enforcing that a data subnet never talks to the internet), because stateless rules need ephemeral return ports and are easy to break.
• Peering or transit gateway: peering suits a handful of VPCs with stable relationships. Beyond that, a transit gateway or hub gives one place to segment, inspect and log.
• Gateway or interface endpoint for S3: gateway endpoints cost nothing extra but work only from inside the VPC; interface endpoints also serve on-premises and peered networks through private IPs.
• Small organisations: one VPC or VNet per environment, managed security groups, flow logs and a NAT gateway with restricted egress rules is a defensible baseline. Large organisations need a network account or hub subscription, centrally owned firewall policy, segmented transit routing and automated rule review.

Detection and measurement

• Open administration ports: security groups and NSGs allowing internet ingress to 22, 3389 or database ports (target zero).
• Flow log coverage: percentage of VPCs and VNets with flow logs delivered centrally (target 100).
• Default access: endpoints still using the full-access default policy, and resources with private endpoints that still allow public network access.
• Egress via inspection: share of internet-bound traffic that passes the central firewall rather than local NAT or internet gateways.
• Change hygiene: median time from an unapproved rule change to revert.

Common failure patterns

• Internet-reachable services: container hosts and databases left open to the internet are found and abused by automated campaigns, as with the Carbonato botnet on exposed Docker hosts and the DeepSeek database exposure.
• Trusting the edge: a misconfigured edge firewall with a broad role turned one request into bucket access in the Capital One breach; network position should never stand in for least privilege.
• Flat transit routing: every VPC propagates to the default transit route table, so development can reach production.
• Private endpoint, public resource: a private endpoint is added and public network access is left on.
• Open egress: NAT with allow-all outbound rules gives malware and compromised workloads a clean path out.

Framework mapping

Practitioner checklist

• Allocate non-overlapping CIDR ranges centrally and retire default VPCs and networks in production.
• Review route tables for internet gateway routes and public IP assignment in every subnet.
• Remove internet ingress to administration and database ports on IPv4 and IPv6.
• Strip all rules from default security groups and use referenced security groups between tiers.
• Replace full-access endpoint policies and require aws:SourceVpce on sensitive buckets.
• Disable public network access on every resource fronted by a private endpoint.
• Segment transit gateway route tables and route spoke traffic through a hub firewall.
• Restrict egress to allow-lists and control DNS resolution with logging.
• Enable flow logs and resolver query logs everywhere, centrally collected.
• Alert on firewall rule, route, peering and endpoint acceptance changes outside the pipeline.

Standards and references

• NSA and CISA: Implement Network Segmentation and Encryption in Cloud Environments
• NIST: SP 800-215 Guide to a Secure Enterprise Network Landscape
• AWS: Infrastructure security in Amazon VPC
• AWS: Control access to VPC endpoints using endpoint policies
• AWS: How transit gateways work
• Microsoft Learn: Azure network security groups overview
• Microsoft Learn: Hub-spoke network topology in Azure
• Google Cloud: VPC firewall rules

Related NHI Mgmt Group resources: Network Segmentation Guide · Cloud Misconfiguration Guide · AWS Security Guide · Microsoft Azure Security Guide · Google Cloud Security Guide