Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Respond to a suspected threat in AWS by first preserving the evidence and service context you will need, then scoping the affected accounts and workloads, choosing containment that fits the risk, removing the root cause, and restoring service from a trusted state. For Linux and Kubernetes incidents, the key decision is often whether the compromise is limited to a workload or may extend to its host, identity, or AWS account.
Prepare before an alert
Preparation determines what you can establish after an incident. Assign incident contacts, decision-makers, escalation paths, and preapproved containment criteria. Agree in advance on who can isolate an instance, restrict a principal, or affect a production workload, and how service owners will be involved.
Enable and retain logs before they are needed. AWS identifies CloudTrail, VPC Flow Logs, and Route 53 Resolver query logs as baseline sources for investigation. Add records relevant to your environment, such as EKS control-plane audit logs, Linux operating-system and application logs, and load balancer or web application firewall logs. Choose storage and retention to meet investigation, alerting, and regulatory needs; a baseline is not a complete record of every service or host.
Recommended Free Tools
Enable GuardDuty in supported Regions, including Regions your organization does not actively use, as AWS recommends. AWS Security Incident Response can ingest GuardDuty and Security Hub CSPM alerts, but any automated or preauthorized containment depends on configuration and permissions being in place.
#1 Best Overall
Make response access usable
Confirm responders can reach the accounts, Regions, clusters, and logs they may need, and that their incident roles permit approved actions. If you plan to use EC2 Triage, deploy its required template, install and run SSM Agent, and ensure the target instance is online and managed by Systems Manager. An instance that does not meet those conditions cannot be collected through that workflow.
Scope the threat before changing the environment
Start an incident record with the alert or finding, affected account and Region, cluster and namespace where relevant, suspected identity, workload and node, known times, and actions already taken. Record what is confirmed separately from what is still suspected. This creates a shared working picture and helps prevent one team’s response from obscuring another team’s evidence.
Rank #2
Correlate the alert with CloudTrail, VPC Flow Logs, Kubernetes audit records, host data, and application records that are available. AWS describes triage as evaluating findings alongside service metadata, logs, threat intelligence, and knowledge of the environment. Establish the likely scope: one pod, a worker node, an EC2 instance, an IAM principal, an S3 resource, or broader account activity. Do not treat a single affected pod as proof that the node or account is clean.
Investigate EC2 and Linux instances
On an affected Linux instance, prioritize collection of state that may disappear if the machine is stopped or terminated. AWS EC2 Triage can use Systems Manager Run Command to gather operating-system artifacts including running processes, network connections, and logged-in users. Its use depends on the deployed triage configuration and an online target managed by Systems Manager with SSM Agent running.
Choose containment based on scope and impact
There is no single containment action that is right for every incident. Weigh potential damage, evidence and regulatory requirements, availability impact, effectiveness, time and resources, reversibility, and how long the restriction should remain. A broad action may reduce exposure quickly but disrupt unrelated workloads; a narrow action may preserve service while leaving an attacker room to move.
| Target | Documented containment approach | Scope and operational caveat |
|---|---|---|
| EC2 instance | Replace the instance’s security group to isolate it from future network activity. | Existing tracked connections are not shut down by the security-group replacement; future traffic is blocked. |
| IAM principal | Deny the principal’s actions. | Restricts that identity; assess which legitimate activity may also be affected. |
| S3 access | Restrict access to the affected resource. | Resource access is affected; confirm the restriction matches the incident scope. |
| Kubernetes pod | Apply a targeted deny-all ingress-and-egress NetworkPolicy. | Pod-level isolation may not work if the attacker controls the underlying host. |
| Kubernetes worker host | Consider host-level isolation when host compromise is suspected. | A security-group change affects every container on that host, not only the suspected pod. |
For an EKS incident, identify both the pod and its worker node before choosing a network action. A NetworkPolicy aimed at the pod is narrower, but AWS warns that it may prove ineffective if an attacker has gained access to the underlying host. Changing the host security group has a wider blast radius because it affects all containers on the host. Choose between them based on evidence about the compromise, service impact, and how much isolation is required.
When appropriate, revoke temporary credentials and label affected resources as under investigation so other operators do not accidentally alter or remove them. Keep a record of each containment action, its time, rationale, expected effect, and observed service impact.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Preserve evidence before replacing a workload
Before deleting, stopping, or replacing a suspected compromised workload, collect available volatile state where incident needs and environment capabilities permit. AWS EKS guidance identifies operating-system memory, process and open-port data, container runtime state and logs, and EBS volume snapshots as useful evidence. Collection methods may include tools such as LiME and Volatility and runtime commands such as crictl ps and crictl logs; their availability and suitability depend on the environment.
Do not assume a pod is disposable just because it is managed by a controller. Deleting a vulnerable pod owned by a Deployment or DaemonSet can cause the controller to launch another pod with the same vulnerability. Identify the owning controller and address the exploited weakness before removing the compromised instance.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Eradicate the cause and recover from a trusted state
- Fix the exploited vulnerability. Correct the underlying weakness or configuration that enabled the compromise before bringing a replacement workload into service.
- Launch replacement workloads. Use a trusted, remediated state rather than simply recreating the vulnerable workload.
- Remove compromised workloads. Once needed evidence is collected and the cause is addressed, remove affected resources in a way that accounts for their Deployment, DaemonSet, or other ownership.
- Validate recovery against the incident scope. Confirm that restored services and access align with what was affected and that the root cause has been addressed.
- Restore normal access deliberately. Relax containment only when the relevant checks are complete, and retain incident records and investigation artifacts.
Review the incident and improve readiness
After containment, eradication, and recovery, review what happened and turn the findings into specific prevention work. Check whether logging provided the needed timeline, whether responder access and escalation worked, whether containment was effective without avoidable disruption, and whether evidence was collected before volatile state disappeared. Update response roles, logging coverage, retention, and preapproved actions where the incident exposed a gap. AWS’s incident-response lifecycle includes post-incident review and recommendations to help prevent recurrence.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
