Cloud platforms have changed how networks are built, but they have not removed the need for network segmentation.
In fact, cloud environments can make segmentation more important because infrastructure can be created quickly, services can span multiple accounts or regions and application dependencies can change faster than traditional network documentation.
Good segmentation is not about creating as many subnets as possible. It is about defining sensible trust boundaries and allowing only the communication that workloads genuinely need.
Segmentation limits unnecessary trust
A flat network assumes that systems can communicate freely once they are inside the environment.
That makes administration simple, but it also means a compromised system may have more opportunity to reach other workloads.
Segmentation reduces that implicit trust by separating environments, workloads and management functions according to business and security requirements.
Cloud networks are still networks
Virtual Cloud Networks, VPCs, subnets, route tables, security groups, network security groups and firewalls may use different names across providers, but they still control communication paths.
Cloud-native identity controls are essential, but they do not replace network controls. Identity and network policy should reinforce each other.
DNC’s Cloud Architecture services include network discovery, segmentation review and cloud connectivity design.
Separate production from non-production
Development and test environments often have different users, support processes and security requirements from production.
Allowing unrestricted traffic between them can create an unnecessary path into critical systems.
Segmentation should therefore make production boundaries clear and ensure that only approved dependencies cross them.
Separate application and database tiers
Many applications only require specific traffic between web, application and database tiers.
A database does not normally need to accept connections from every system in the network.
Applying controls at each tier reduces the number of systems that can directly reach sensitive services and makes unexpected communication easier to detect.
Protect management interfaces
Administrative access deserves its own design.
SSH, RDP, database administration, hypervisor management and cloud control interfaces should not be exposed broadly simply because administrators need access.
Bastion services, controlled management networks, privileged access processes and identity-aware access can help limit who can reach management endpoints.
Control north-south and east-west traffic
Traditional perimeter security focused heavily on traffic entering and leaving an organisation.
Cloud environments also need visibility over east-west traffic between workloads.
A strong segmentation model considers both directions: internet and external connectivity, and internal communication between systems, services and environments.
Segmentation supports incident containment
When an incident occurs, segmentation can reduce the scope of movement available to an attacker.
It also helps responders understand which communication paths should exist and which ones are unusual.
This does not guarantee containment, but it creates additional control points that can slow or restrict movement through the environment.
Use security groups close to the workload
Cloud security groups can provide fine-grained controls directly around workloads.
Rules should be based on service requirements rather than broad IP ranges wherever practical.
This makes policy easier to relate to the application itself and reduces dependence on large shared firewall rule sets.
Avoid rule accumulation
Network rules often grow through operational pressure.
A temporary exception is added for a project, another rule is created during troubleshooting and old entries remain because nobody is certain whether they are still needed.
Over time, this can recreate a flat network even when the diagram appears segmented.
Periodic rule review is therefore as important as the original network design.
Map dependencies before tightening controls
Segmentation changes can cause outages if application dependencies are poorly understood.
Before removing broad rules, map the required flows between workloads, shared services, on-premises systems and third parties.
Logging and traffic analysis can help validate whether documented dependencies match reality.
Use segmentation alongside IAM
Network and identity controls solve different parts of the problem.
IAM determines who or what is authorised to perform actions. Network controls determine which communication paths are available.
Using both creates defence in depth. A stolen credential should not automatically provide unrestricted network reach, and network access should not automatically grant application privilege.
DNC’s Cyber Security services can support cloud network and access-control reviews.
Consider third-party connectivity
Suppliers, managed service providers and integration partners may connect through VPNs, private links or public endpoints.
Those connections should terminate in clearly controlled areas and should not provide broader reach than the third party requires.
Ownership, purpose and review dates should be recorded for external access paths.
Keep the architecture understandable
Segmentation should improve control without creating an environment that only one network specialist can understand.
Consistent naming, documented trust zones and reusable patterns help teams understand where workloads belong and how communication should be approved.
What good looks like
A well-segmented cloud environment has clear boundaries between production, non-production, management and sensitive workloads.
Traffic is permitted because there is a known requirement, not because broad connectivity was easier to configure.
Rules are reviewed, dependencies are documented and identity controls reinforce the network design.
Conclusion
Cloud adoption has not made network segmentation obsolete. It has made it more dynamic.
Organisations still need to understand where trust boundaries sit, which systems should communicate and how to limit unnecessary paths between workloads.
If you need help reviewing cloud networking or documenting the current state, see DNC’s Cloud Architecture services or contact DNC.