Amazon Guard Duty Feed Upgrade

Hi there, 

Per the Upgrade to V2 doc:

• Amazon SQS: The migration only supports SQS queues that contain messages from a single Amazon S3 bucket. If your queue receives messages from multiple buckets, create a separate feed for each bucket. Verify that your SQS queue is configured correctly and that the access credentials for both the SQS queue and the Amazon S3 bucket are identical.

I would check that your feed is eligible for the migration. What’s strange is that normally when I’ve seen auto-migrations fail, it will show up as errored and an action item.

My personal recommendation would be to just manually upgrade the feed yourself following this. The auto-migration is cool, but no reason to leave it to fate when you can just stand up a new feed and disable the V1 feed yourself. 

Also probably a good idea to see what logs are in that bucket to get an idea of what is newer than that 9/26 19:07 timestamp.

Exactly the same happened to me, Google migrated all legacy v1 feeds except for Guardduty. When asked why, they claimed “it was flagged because it contains messages from two buckets” which was simply not true 😆.

I ended up creating the feed myself using AMAZON_SQS_V2.

The second link shared by @codyro references AMAZON_S3_V2 directly .
Secops supports both but the usual recommendation for efficiency is SQS because it is event driven. By contrast, AMAZON_S3_V2 relies on periodic polling/listing of the bucket.
 

Keep in mind that SQS queues cannot support multiple independent consumers, make sure to disable the legacy feed so the two feeds don't step on each other. For parallel fan-out architecture you’d need SNS + multiple SQS (one per consumer).
 

Regarding the silence in the Guardduty feed, that might actually be expected. Guardduty produces alert/finding-based data, meaning it only generates events when a finding occurs. Unlike high-volume telemetry sources (e.g., VPC Flow Logs, CloudTrail, Windows Event logs) that stream continuously, GuardDuty can sit completely silent for days.
 

If you want to verify your pipeline end-to-end, AWS GuardDuty has a feature to generate mock findings:

In AWS console > Guardduty > settings > “Generate sample findings”

you might want to exclude them from active detections, they are usually labeled as target.resource.product_object_id = "i-99999999" in Secops.

Ah! Good callout. The doc I shared was specifically linked to the S3 not SQS V2 feed. 

Here’s the SQS_V2 direct link.

https://docs.cloud.google.com/chronicle/docs/reference/feed-management-api#amazon_sqs_v2