Core cloud network security strategies are segmenting workloads, replacing broad network trust with identity-aware access, encrypting traffic, watching configuration and logs continuously, and knowing which parts your provider secures. Start with segmentation and posture checks, since they close the most common gaps first.
Why is a cloud network different from a data center?
In a data center you own the cables and the firewalls at the edge. In a cloud account, the network is a set of API objects: virtual networks, route tables, security groups, load balancers. Someone can change any of them with one call, and a mistake is live instantly.
CISA's Cloud Security Technical Reference Architecture, written with the US Digital Service and FedRAMP, splits the problem into three parts: a shared risk model for cloud adoption, how to build a cloud environment, and how to monitor it through cloud security posture management. That split is useful beyond government. Know who is responsible, build with intent, and keep checking that what you built is still what is running.
What does the shared responsibility line mean for networking?
The provider secures the physical network and the virtualization layer. You secure the rules you write on top: which subnets exist, which ports are open, which identities may call which services. A security group with an open inbound rule is your configuration, not the provider's.
Read your provider's shared responsibility page for every managed service you use. The line moves between a virtual machine, a managed database and a serverless function.
Which strategies carry the most weight?
Segment by default. Separate environments (production, staging), separate sensitive data stores, and put them in different networks or accounts. A flaw in a test service should not give a route to a customer database. In 2022 NIST SP 800-215 argued that networks spread across clouds and data centers need security applied around each service and device, not only at one perimeter.
Prefer identity to location. An internal IP address is a weak proof of who is calling. Use workload identities and short-lived credentials so a service proves itself rather than being trusted by subnet.
Reduce public exposure. Keep databases and internal APIs on private endpoints. Put public services behind a load balancer or gateway you control and monitor.
Encrypt in transit everywhere. Include east-west traffic between services, not only the connection from the internet.
Monitor posture and traffic. Check configuration against a baseline continuously, and keep flow logs and audit logs in a store separate from the account being watched.
What does this look like in practice?
A constructed example: a team runs a web app, an internal admin tool and a reporting database in one virtual network with one flat security group. A bug in the admin tool lets an attacker run commands on that host. Because the group allows all internal traffic, the attacker reaches the database directly.
After the fix, the admin tool lives in its own subnet, reachable only through an identity-aware proxy. The database accepts connections only from the web app and the reporting job, by identity. The same bug would still exist, but the blast radius shrinks to one host.
How to check or apply this
- Export every security group and firewall rule. Flag any rule open to the whole internet or to all internal addresses.
- Draw the real traffic paths between your top five services. Remove any path with no business reason.
- Move data stores to private endpoints and confirm nothing in the public address space answers.
- Replace long-lived static keys between services with short-lived credentials.
- Turn on flow and audit logs, and ship them to a separate account or store.
- Run a configuration check weekly and track the count of findings over time.
- Write down, per service, which side of the shared responsibility line each control sits on.
Quick check
Is network segmentation still useful if everything uses identity-based access?
Yes. Identity decides who may call a service. Segmentation limits where a compromised host can even try. They cover different failures.
Who is responsible for an open security group in the cloud?
You are. Providers secure the underlying infrastructure, but the rules you configure on your resources are your responsibility.
Sources
- CISA, Cloud Security Technical Reference Architecture
- NIST SP 800-215, Guide to a Secure Enterprise Network Landscape
Last reviewed: 18 October 2026.
