How to Isolate a Compromised EC2 Instance and Preserve Forensic Data

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Terminate the instance immediately

  Why it's wrong here

  Immediately terminating the instance is an irreversible action that destroys volatile memory and disk data needed for forensic analysis, and it forfeits the ability to determine the compromise's scope and root cause. It also does not contain the threat in a way that preserves evidence; any automated scaling activity could launch a new instance from the same vulnerable AMI, recreating the exposure. Proper isolation should cut network access while keeping the instance intact.

• ✓

  Use Amazon GuardDuty to detect the compromise and automatically modify the instance's security group to deny all traffic

  Why this is correct

  Amazon GuardDuty consumes VPC DNS logs, flow logs, and other telemetry to identify suspicious behavior such as outbound traffic to known command-and-control IPs. A high-severity finding can be sent to Amazon EventBridge, which invokes an AWS Lambda function that replaces the instance's security group with a quarantine security group containing a deny-all inbound and outbound rule, instantly severing network connectivity. This agentless containment preserves the running instance and its memory for investigation and is the recommended automated isolation pattern.

• ✗

  Use AWS Config to change the instance's IAM role

  Why it's wrong here

  AWS Config can detect configuration drift and trigger remediation, but changing the instance's IAM role only alters the permissions available to new credential requests via the instance metadata service. It does not modify security group rules, network ACLs, or routing, so the instance can remain fully reachable on the network; in fact, a process already running with assumed role credentials can continue to use them until expiry. Therefore this action does nothing to isolate a compromised instance at the network layer.

• ✗

  Use AWS Systems Manager to run a script that stops the instance

  Why it's wrong here

  AWS Systems Manager Run Command relies on the SSM Agent being installed, healthy, and able to communicate with the Systems Manager service. A compromised instance may have the agent stopped, tampered with, or its outbound registration traffic blocked, so the script may never execute, leaving the instance exposed, and the termination could also fail if the agent is unavailable. Additionally, stopping an instance is a guest/control-plane action rather than a network path change, and it does not preserve memory for forensic capture in the way a security-group-level block does.

Go deeper

Related to this question