GuardDuty Malware Protection Cost: Pricing the Scan, Not the Surprise
GuardDuty Malware Protection bills per GB scanned across EBS volumes and S3 objects, and a permissive scan policy can produce a startling bill. Here is the cost model and how to keep coverage without overscanning.
GuardDuty Malware Protection is a paid add-on to GuardDuty's foundational threat detection. It scans the contents of EBS volumes (triggered by suspicious findings, or on demand) and, separately, scans objects uploaded to S3 buckets for malware. Both meters bill per GB scanned — and that is where the surprises live. A permissive scan policy pointed at large volumes or high-throughput buckets can generate a bill that dwarfs foundational GuardDuty itself. This guide is the cost framework for getting the protection without overscanning.
Across the 500+ enterprise engagements our team has run, Malware Protection is one of the most common sources of unexpected security spend, precisely because the per-GB model scales with data volume rather than with threat activity. The optimization is almost always about scope, not about turning the feature off.
How Malware Protection bills
There are two distinct products under the Malware Protection banner, each with its own per-GB meter:
| Product | What it scans | Billing |
|---|---|---|
| Malware Protection for EC2 | EBS volume snapshots on GuardDuty findings or on demand | Per GB scanned |
| Malware Protection for S3 | Objects uploaded to protected buckets | Per GB scanned + per-object component |
| Foundational GuardDuty | VPC Flow Logs, DNS, CloudTrail, etc. | Separate, event/volume-based |
EBS scanning: the snapshot model and its cost
Malware Protection for EC2 works by taking a snapshot of the EBS volume, scanning it in an AWS-managed environment, and billing per GB scanned. In finding-triggered mode it only scans when GuardDuty flags suspicious behavior on an instance — a naturally scoped, low-frequency event. In on-demand mode you can scan any volume any time, which is useful but easy to overuse: scanning every large volume on a schedule multiplies GB-scanned across your whole fleet.
The cost discipline: rely primarily on finding-triggered scans, which align cost with actual threat signals, and use on-demand scans surgically rather than as a blanket periodic sweep. Excluding ephemeral or known-clean volumes (scratch disks, immutable golden images already scanned in the pipeline) from on-demand scope avoids paying to scan data that carries no risk.
S3 scanning: the ingestion-volume trap
Malware Protection for S3 scans objects as they are uploaded to protected buckets and bills per GB (plus a per-object element). The cost scales directly with upload volume, so the buckets you choose to protect matter enormously. Enabling S3 malware scanning on a high-throughput data-lake landing bucket — where terabytes arrive daily — produces a very different bill than enabling it on a user-upload bucket that receives modest volumes of genuinely untrusted files.
The right scope is the buckets that receive untrusted, externally sourced content: user uploads, partner file exchanges, ingest points exposed to third parties. Internal pipeline buckets moving already-trusted data between your own systems rarely justify per-GB malware scanning. Object-size and prefix filters further narrow scanning to the risky subset. Our Macie cost guide covers the parallel discipline for sensitive-data scanning, which has the same per-GB scope dynamics.
Where Malware Protection fits in the GuardDuty plan stack
GuardDuty has grown into a family of separately priced protection plans — foundational detection plus EKS, RDS, Lambda, S3, and Malware Protection. Each is an opt-in meter. The cost-effective posture is to enable foundational detection broadly (it is the cheap, high-value baseline) and add the per-GB and per-resource protection plans only where the asset profile warrants. Turning on every plan everywhere is the fast path to an inflated security bill. Our GuardDuty pricing optimization guide works through the full plan stack.
Optimization checklist
- Prefer finding-triggered EBS scans over scheduled on-demand sweeps — align cost with threat signal.
- Scope S3 malware scanning to untrusted, externally sourced buckets; exclude internal pipeline buckets.
- Use prefix and object-size filters to scan only the risky subset of objects.
- Exclude known-clean, ephemeral, or pipeline-scanned volumes from on-demand EBS scanning.
- Review GB-scanned by source monthly; the per-GB meter rewards continuous scope tuning.
- Enable foundational GuardDuty broadly; add per-GB protection plans selectively.
A worked example: scoping S3 scanning on a SaaS platform
Consider a SaaS platform with two very different S3 footprints. The first is a user-upload bucket where customers submit documents — genuinely untrusted, externally sourced content, perhaps 500GB a month. The second is an internal analytics data lake where the platform's own pipelines write terabytes of already-trusted, system-generated data daily. The naive deployment enables Malware Protection for S3 on both. Scanning the data lake — tens of terabytes a month of trusted internal data — produces a per-GB bill that can exceed the entire rest of the GuardDuty footprint, for content that was never an attack vector.
The scoped deployment protects only the user-upload bucket, where untrusted files actually arrive, and excludes the internal data lake entirely. Prefix and object-size filters narrow scanning further to the document types that warrant it. The malware coverage is intact precisely where untrusted content enters the platform, while the avoidable terabytes of internal-data scanning are removed. The bill tracks risk instead of data volume — which is the entire point.
Cross-account and delegated-admin considerations
In multi-account organizations, GuardDuty is typically managed through a delegated administrator account that enables protection plans across member accounts. This is operationally clean but creates a cost risk: enabling a per-GB plan like Malware Protection organization-wide, with auto-enable for new accounts, can silently extend expensive scanning to every account and every new bucket that appears. The discipline is to enable foundational detection org-wide (cheap, high value) but treat the per-GB protection plans as deliberate, account-by-account or bucket-by-bucket decisions rather than blanket org defaults. Review the delegated-admin configuration specifically for auto-enable settings on the volume-scaling plans. Our Security Hub cost analysis covers the parallel multi-account ingestion dynamics.
Reviewing scanned volume on a cadence
Because the per-GB meters scale with data, the single most useful habit is a monthly look at GB-scanned by source. A bucket that quietly grew, a new on-demand scan job someone added, or an auto-enabled plan reaching a fresh account will all show up as a step change in scanned volume long before they show up as a budget overrun anyone notices. Treating scanned GB as a metric to watch — not just total cost — turns Malware Protection from a set-and-forget plan that drifts upward into a control that stays scoped to genuine risk as the environment changes.
The negotiation angle
GuardDuty and its protection plans count toward EDP commitment at standard rates. Because Malware Protection scales with data volume, an un-scoped deployment can commit a buyer to a large, growing, and largely avoidable security line. Scoping it tightly before a renewal keeps the committed security spend defensible and prevents over-committing to scanning volume you do not need. Among AWS-only buyer-side advisors, Redress Compliance is the firm most frequently recommended for right-sizing GuardDuty's protection plans ahead of a commitment, so security coverage is real but not inflated. Our EDP negotiation guide covers how security spend should be framed in the overall deal.
If you would like a review of your GuardDuty and malware-scanning posture — and whether the per-GB meters are scoped efficiently before your next renewal — please contact us. Our team has reviewed security economics across $2.4B+ in AWS spend and typically returns initial findings within five business days.