Amazon GuardDuty Malware Protection adds malware scanning to GuardDuty’s threat-detection workflow for EC2/EBS workloads and S3 objects. For EC2, GuardDuty can initiate an agentless scan of attached EBS volumes after certain findings or on demand by creating snapshots and scanning replica volumes in the GuardDuty service account. For S3, GuardDuty scans newly uploaded objects in protected buckets or prefixes and can emit findings or attach scan-result tags.
Within AWS Architecture and Operations, malware protection is a detection-and-containment signal, not an antivirus agent replacement. It should feed incident workflows, quarantine policy, evidence retention, and workload isolation without forcing operators to install scanning software inside every server or container.
The existing AWS security foundation article provides broader context for GuardDuty and account-level controls.
EC2 malware scanning is agentless
When a GuardDuty finding qualifies for a malware scan, GuardDuty can snapshot the relevant EBS volumes and share those snapshots with the GuardDuty malware-protection service account.
The service creates encrypted replica volumes for scanning rather than installing an agent in the original instance.
This reduces workload intrusion but means scan coverage depends on supported EBS volumes and the snapshot/service-role workflow being allowed.
On-demand EC2 scans complement finding-triggered scans
GuardDuty supports on-demand malware scans for an EC2 instance’s attached EBS volumes.
This is useful during incident response when another signal—not a GuardDuty finding—raises suspicion and the team wants malware analysis without modifying the instance.
Use on-demand scans in a controlled incident playbook; repeated ad hoc scanning can consume quota/cost and should not replace root-cause investigation.
Snapshot retention is optional and evidence-sensitive
By default, GuardDuty removes scan snapshots after scanning. You can enable snapshot retention so snapshots associated with detected malware remain in your account.
This can preserve forensic evidence but creates storage, access-control, and sensitive-data obligations.
If snapshot locking is enabled, GuardDuty cannot delete the locked snapshot even if retention is otherwise off, so lifecycle policy should account for locked evidence.
Tag-based scan inclusion and exclusion need governance
GuardDuty-initiated EC2 scans can use user-defined include/exclude tags and support a global GuardDutyExcluded=true exclusion.
Exclusion can be appropriate for unsupported workloads or special operational cases, but it is also a way to create blind spots.
Monitor for exclusion tags and require an owner/expiry so systems do not remain permanently unscanned because of a temporary exception.
S3 Malware Protection scans newly uploaded objects
For S3, GuardDuty can protect an entire bucket or selected prefixes and scans each newly uploaded object or new version that enters the protected scope.
This is useful for file-upload workflows, data landing zones, customer attachments, software artifacts, or document-processing pipelines.
Existing objects are not retroactively covered merely because protection is enabled; re-upload or another explicit process is needed when historical objects require scanning.
S3 scan-result tags can drive quarantine workflows
When optional tagging is enabled, GuardDuty writes a GuardDutyMalwareScanStatus tag to the scanned object with the result.
Applications can use tag-based access control or EventBridge-driven automation to prevent unscanned/malicious objects from flowing into processing pipelines.
Remember that S3 object tagging has cost and tag-count limits, and GuardDuty needs the appropriate tagging permission on the bucket.
GuardDuty can scan S3 independently of the full GuardDuty detector
AWS supports Malware Protection for S3 as an independent feature without enabling the full GuardDuty service.
However, if GuardDuty is not enabled with a detector, potentially malicious S3 objects will not generate GuardDuty findings in the same way; scan result monitoring relies on status/events/tags.
Choose the independent mode only when the operational workflow still has a reliable path from scan result to remediation.
Finding and scan result are not the same thing
For EC2, a GuardDuty finding can trigger the malware scan, and the scan can then add malware-specific findings/details. For S3, the protected-object scan result can feed findings when GuardDuty is enabled.
Incident tooling should preserve both the original threat signal and the malware scan evidence.
This lets responders see whether malware was detected after suspicious network/API behavior or whether an uploaded file was flagged before any execution signal existed.
Automated containment should be scoped carefully
A malicious-object tag can justify moving or denying access to an upload; an EC2 malware result can justify isolating the instance, revoking credentials, or preserving snapshots.
But avoid destructive cleanup before forensic evidence and business impact are understood.
Use EventBridge/automation to create a safe initial state—quarantine, drain, revoke external access, open incident—then let the incident process decide whether to terminate or delete.
Malware protection needs monitoring of the scanner itself
Track scan status, skipped/unsupported volumes, role-permission errors, protected-bucket coverage, object-scan backlog, and finding volume.
A dashboard showing “no malware” is meaningless if the service role broke last week and nothing is being scanned.
Regularly test with known safe test artifacts or supported validation procedures to confirm event/tag/finding pipelines work end to end.
GuardDuty Malware Protection succeeds when detection becomes a controlled response signal
The mature design uses agentless EC2 scans and S3 object scanning where appropriate, governs exclusions, preserves evidence selectively, automates quarantine rather than destruction, and monitors coverage as carefully as findings.
Malware scanning adds value when the organization can prove what was scanned, what was skipped, what was detected, and what operational action followed.
EC2 malware scans should be correlated with the finding that triggered them. If GuardDuty detects suspicious process, credential, network, or container behavior and then finds malware on an attached volume, those two pieces of evidence reinforce one incident narrative. Preserve the original finding ID, scan ID, instance/container metadata, volume IDs, and snapshot-retention decision together.
Volume encryption and KMS permissions deserve testing before an incident. The malware-protection service must be able to create and scan replica volumes according to AWS’s service-role model. A custom KMS policy that blocks the GuardDuty workflow can leave important volumes unscanned even while GuardDuty itself continues to produce findings.
On-demand scanning should be used after containment as well as during triage. If an instance is isolated and suspicious files are removed, a clean follow-up scan plus other forensic evidence can support the decision to return the workload to service. Do not treat one clean scan as proof of no compromise; memory-only malware or credentials theft can exist outside scanned EBS content.
S3 protection works best when uploads land in a quarantine prefix/bucket first. Applications can wait for the GuardDuty scan-result tag or EventBridge status before copying/allowing the object into the trusted processing path. This prevents a malicious attachment from being parsed, indexed, or delivered merely because the scan runs asynchronously after upload.
Prefix scoping should be reviewed when bucket layout changes. If the application moves uploads to a new prefix but the protection plan still covers only the old path, scan coverage disappears silently. Infrastructure tests should assert that every untrusted-ingress prefix is protected and that object-created events still reach GuardDuty.
Malware findings should feed Security Hub/SIEM or the organization’s case system with enough context to locate the workload owner. Add account, environment, application, instance or bucket tags, and deployment metadata so responders can contain the right resource quickly without reverse-engineering who owns an unfamiliar instance ID.
Quotas and object/volume-size support should be part of the operating model. Very large or unsupported artifacts can be skipped or fail scanning depending on current service limits. Track scan status/result and surface “not scanned” distinctly from “no malware detected,” because those are very different security outcomes.
For immutable or regulated evidence, snapshot retention should have a formal evidence-handling process. Restrict who can copy or restore retained snapshots, tag them with incident/case IDs, define retention, and delete them when no longer required. A retained malicious snapshot can contain the same sensitive customer data as the compromised production volume.
Remediation workflows should preserve object and volume ownership. Malware Protection can tell you that a file or EBS snapshot contains malicious content, but it does not know whether the workload is disposable, regulated evidence, a customer upload, or a production database volume. Use tags/CMDB metadata to route the finding to the right playbook and owner.
For S3 ingestion, tag-based access control can enforce a simple state machine such as unscanned, clean, malicious, or scan-failed. Downstream processors should only read objects in an approved state. This is stronger than merely sending a security alert while the same object remains readable by every consumer immediately after upload.
EC2 scanning should be tested on encrypted volumes and custom KMS policies in every account template. A central security team may enable GuardDuty broadly, but application accounts can still introduce key-policy conditions that prevent snapshot handling. Detect that coverage gap during deployment rather than during the first malware incident.
Malware-protection cost and scope should be reviewed periodically. Protecting every bucket and every EC2 volume may be appropriate in some estates; others can focus on untrusted-upload buckets and high-risk workloads. The security decision should be documented so excluded data has compensating controls rather than simply falling outside the scanner unnoticed.
Scanning latency should be incorporated into ingestion workflows. A large S3 object or busy period can delay the scan result, so applications should have a defined pending state instead of assuming ‘not yet malicious’ means clean. Time out or escalate objects that remain unscanned beyond an operational threshold and prevent downstream processing until the policy-approved result is available.
