A security engineer is building an Amazon EC2 isolation procedure for incident response. The goal is to block all inbound and outbound traffic to a target instance except access by the forensics team. Each instance has its own security group, and multiple instances share the same subnet. During testing, the engineer opens an SSH session to the target, then removes existing security group rules and adds rules to allow the forensics team on port 22. The existing SSH session remains active, although ICMP to the public IP is blocked. What should the engineer do to fully isolate the instance?

The existing SSH session persists because security group changes are not stateful for established connections. To fully isolate the instance, the engineer must terminate all existing connections. Removing the port 22 rule will prevent new SSH connections but won't kill the active one. By using AWS Systems Manager Session Manager (SSM), the forensics team can access the instance without relying on security group rules for SSH, as SSM uses an agent on the instance and AWS API calls for connectivity. This approach allows for complete security group lockdown while maintaining forensic access. Incorrect options: Adding and immediately deleting 0.0.0.0/0 rules is ineffective for terminating existing connections and creates a brief window of vulnerability. Network ACLs apply at the subnet level and would affect all instances in the subnet, not just the target instance, violating the isolation requirement for a single instance. Host-based firewall rules are effective, but the question implies a need for AWS-native controls for isolation and forensic access. While host-based firewalls could block traffic, they don't provide the secure, auditable access method of SSM.