A potentially compromised EC2 instance creates a conflict between two goals:

• Stop the attacker.
• Preserve enough evidence to understand what happened.

A rushed response can solve one goal while destroying the other. Stopping or terminating an instance can remove volatile evidence. Leaving it fully connected can allow the attacker to continue operating.

The current AWS Certified Security – Specialty exam includes incident-response planning and response to security events, so EC2 containment should be treated as a controlled evidence-preservation process.

Prepare before the incident

The strongest incident-response step happens before compromise.

AWS recommends preparing forensic capabilities in advance.

That can include:

• centralized CloudTrail
• VPC Flow Logs
• host logs
• protected log archives
• forensic accounts
• prebuilt isolation security groups
• Systems Manager access
• snapshot procedures
• memory-capture tooling
• incident-response roles
• containment automation

Strong incident-response planning establishes roles, evidence paths, and escalation rules before an EC2 compromise occurs.

Do not design your evidence workflow for the first time while an attacker is active.

Validate the alert and identify the instance

Start by confirming:

• instance ID
• account
• Region
• VPC and subnet
• instance profile
• security groups
• public IP
• autoscaling membership
• load-balancer membership
• attached EBS volumes

Review the finding that triggered the response.

Possible sources include:

• GuardDuty
• Security Hub CSPM
• endpoint-security platform
• application telemetry
• CloudWatch alarm
• threat-hunting result

The response should be tied to a known resource and observed behavior.

Contain without destroying the instance

AWS documents reversible EC2 containment that keeps the instance running while restricting new network activity.

A common approach is:

1. Create or use a dedicated containment security group.
2. Remove the normal security groups from the compromised instance.
3. Attach the restrictive containment security group.
4. Restrict inbound and outbound communication as required.

AWS provides the AWSSupport-ContainEC2Instance Systems Manager Automation runbook for this purpose.

Keeping the instance running can preserve volatile evidence while limiting attacker movement.

This is an important limitation.

AWS notes that changing security groups does not necessarily terminate existing tracked connections.

The new security-group rules affect new traffic.

If the response requires stopping an already established suspicious connection, additional network controls may be necessary.

The exact containment choice depends on the incident and evidence requirements.

Do not assume “attached isolation security group” means every existing session instantly disappeared.

Preserve disk evidence

EBS snapshots provide a point-in-time copy of EBS volume data.

For a compromised instance, snapshots can preserve disk state for later analysis.

Useful precautions include:

• protect the original instance from accidental termination
• preserve attached volumes
• record snapshot IDs
• copy or share evidence into a dedicated forensic account when appropriate
• document timestamps and actions

The forensic copy should be analyzed separately from the compromised production instance whenever possible.

This reduces the risk of modifying original evidence during investigation.

An EBS snapshot does not capture everything in RAM.

Volatile memory may contain:

• running processes
• injected code
• encryption keys
• active network-session data
• command history not yet written to disk
• malware state

If memory evidence matters, it should be collected before the instance is stopped or rebooted.

AWS publishes automated-forensics guidance that includes memory and disk acquisition for supported EC2 scenarios.

A digital forensics lab can help build analysis skills, but production evidence collection should follow the organization’s approved forensic procedure.

Preserve cloud-side logs

Host evidence is only one source.

AWS-side telemetry can show activity that an attacker cannot easily erase from the compromised operating system.

Collect and preserve relevant records such as:

• CloudTrail
• VPC Flow Logs
• Route 53 Resolver query logs where configured
• load-balancer logs
• GuardDuty findings
• Security Hub findings
• CloudWatch logs
• application logs stored outside the instance

A strong incident timeline combines host and cloud evidence.

Investigate the instance role

A compromised EC2 instance can expose temporary credentials associated with its IAM role.

Review:

• instance profile
• role permissions
• CloudTrail activity by the role
• unusual API calls
• accessed resources
• other instances sharing the same role

Containment may require revoking or restricting the identity path in addition to isolating the network.

Be careful with shared roles.

Changing or invalidating a role used by many instances can create a larger outage.

This is why narrow workload identities reduce incident blast radius.

If the compromised server belongs to an active service, isolate its application role as well.

That can include:

• deregister from load balancer
• remove from Auto Scaling group or prevent automatic replacement confusion
• disable traffic routing
• prevent termination while evidence is collected
• mark the resource clearly as quarantined

The goal is to keep users and automation from treating the compromised instance as healthy production capacity.

Containment should not accidentally cause the orchestrator to destroy the evidence.

Rebuild rather than “clean” when possible

After evidence collection, rebuilding from a known-good image is often safer than trying to prove that every attacker artifact was removed.

A recovery workflow can include:

1. fix the initial access path
2. rotate credentials
3. patch the vulnerable software
4. deploy a clean instance from trusted infrastructure code or image
5. restore validated application data
6. monitor closely
7. terminate the compromised resource after evidence requirements are satisfied

Recovery should not reconnect the original server simply because malware scans no longer find anything.

After containment and recovery:

• reconstruct the timeline
• identify root cause
• identify missed detections
• update runbooks
• improve logging
• reduce IAM permissions
• fix network exposure
• test the revised response

Build containment so evidence survives the response

The first minutes of an EC2 incident create tension between stopping harm and preserving evidence. Terminating the instance is fast, but it can destroy volatile context and make timeline reconstruction harder. A stronger runbook uses reversible containment first: remove the instance from load balancing, restrict new network paths with a dedicated isolation security group or routing change, and protect snapshots and logs before destructive actions are considered. The exact containment mechanism depends on the environment, but the principle is to reduce attacker freedom while keeping the investigation observable.

Network isolation also needs a realistic understanding of state. Changing a security group is not equivalent to resetting every existing connection. If an established flow remains tracked, the responder may need an additional action to make containment immediate. That is why the runbook should be tested in advance rather than invented during an active compromise. The test should verify what happens to existing sessions, management access, telemetry delivery, and forensic tooling when the isolation control is applied.

Evidence collection should distinguish persistent and volatile data. EBS snapshots preserve disk state and are invaluable for later analysis, but they do not capture memory. Memory can contain running-process state, decrypted material, network connections, and attacker tooling that never touched disk. If memory acquisition is required, the organization should already know which tool and role can perform it, where the evidence is stored, and how chain-of-custody information is recorded.

Cloud-side evidence is equally important. CloudTrail, VPC Flow Logs, GuardDuty findings, application logs, load-balancer logs, identity events, and Systems Manager or EDR telemetry can explain how the attacker reached the instance and what happened outside the guest operating system. Preserving only the disk image can miss credential misuse or lateral activity performed through AWS APIs.

Recovery should remove the attacker’s foothold, not just the symptom

After containment and evidence preservation, responders need to determine whether the instance role, access keys, secrets, or neighboring resources were exposed. A compromised host with an over-permissioned instance profile can turn a local intrusion into an account-level incident. Reviewing role sessions and CloudTrail activity is therefore part of host response, not a separate IAM task. Credentials that may have been exposed should be rotated or invalidated according to the service involved.

Rebuilding from a trusted image is usually safer than manually "cleaning" a compromised system. A clean replacement can be launched from known infrastructure code or a hardened image, patched, validated, and returned to service while the original evidence remains isolated. That also gives the team an opportunity to close the original entry path rather than returning an unchanged architecture to production.

The final phase should produce specific control changes: narrower IAM permissions, better egress restrictions, improved detections, stronger patch or image pipelines, and tested response automation. A useful incident-response post-mortem connects those corrective actions to the timeline and root cause instead of treating the event as finished when the replacement instance becomes healthy.

A good EC2 incident runbook can therefore be summarized as validate, contain reversibly, preserve evidence, investigate the cloud and host together, eradicate the cause, and rebuild from trust. Speed matters, but response quality comes from knowing which actions are reversible and which evidence disappears once they are taken.
Automation is most useful when it preserves this order of operations. Event-driven response can tag the instance, capture metadata, begin snapshots, notify responders, and apply an isolation control, but destructive steps should usually require stronger evidence or human approval. The runbook should also record timestamps and action IDs so investigators can distinguish attacker activity from responder activity. That simple discipline makes later timeline analysis much more reliable and reduces the chance that well-intentioned containment actions are mistaken for part of the intrusion.

A tested response path is faster precisely because responders do not have to choose evidence and containment actions under pressure.