Network isolation is the deliberate restriction of network communication between resources or groups of resources. The objective is not always complete disconnection: an isolated workload may retain narrowly authorized access to forensic tools, logging systems, or management endpoints. The essential requirement is that only explicitly justified communication remains possible. Isolation can be a permanent architectural boundary or a temporary containment measure applied during a security incident.
In cloud environments, engineers implement isolation using virtual networks, subnet boundaries, routing controls, workload firewalls, network access control lists, and inspection gateways. Separate virtual networks provide useful boundaries, but peering connections, transit networks, private endpoints, and shared services can create additional paths. A resource without a public IP address is not necessarily isolated: it may still reach the internet through a NAT gateway or communicate with compromised systems over private routes.
During an incident, containment should address both inbound and outbound traffic. Blocking inbound connections alone does not prevent malware from contacting command-and-control infrastructure, exfiltrating data, or attacking neighboring workloads. For example, an engineer investigating a compromised application server can remove it from a load balancer, replace its existing security groups with a restrictive quarantine group, and preserve only approved investigation access. All attached network interfaces and remaining access paths must be considered; adding a restrictive security group alongside permissive groups does not override their allowances.
Control behavior matters when selecting a containment action. AWS security groups are stateful, allow-only controls, and changing their rules does not necessarily terminate tracked connections immediately. Network ACLs are stateless subnet-level controls with explicit deny rules and can interrupt matching traffic, including existing flows. However, an ACL change can affect every resource in the associated subnet, and legitimate connections require appropriate rules in both directions. Some platform traffic, including access to the Amazon-provided DNS resolver, is not filtered by security groups or network ACLs, so these controls should not be treated as a universal packet-blocking mechanism.
Preserve evidence while limiting ongoing harm. Record resource identifiers, network configuration, relevant logs, and the containment actions taken. Where appropriate, capture disk snapshots and volatile evidence before stopping or rebuilding a resource, provided collection does not unacceptably delay containment. An isolated network does not revoke stolen credentials or remove malware. Investigators must also address compromised identities, persistence mechanisms, vulnerable software, and any other affected resources.
Plan investigation access before an emergency. A private management path can avoid reopening public SSH or RDP, but management tools still need working connectivity, permissions, and often an agent. For example, a managed session may depend on interface endpoints or controlled outbound access. Complete disconnection can prevent evidence collection, logging, health checks, and remote remediation. The appropriate balance depends on the severity of the threat and the trustworthiness of the remaining management path.
Recovery should restore trust rather than merely restore connectivity. Rebuild affected workloads from trusted images or restore validated backups into a clean, restricted environment. Patch the original weakness, rotate exposed credentials, check for persistence, and verify application behavior before gradually reconnecting production traffic. Restoring a backup without checking when compromise began can reintroduce the threat. Test isolation runbooks in advance and verify containment with traffic observations and connectivity tests rather than assuming that a successful configuration change proves the resource is contained.