GuardDuty: the finding id needs its region and detector

Three fields, one record

GuardDuty is regional. A finding JSON has an Id, a Region, and a detector id on the service block. The id is how you open that finding again in that region, on that detector. Written alone, it does not say which API call to repeat.

The console region in the corner of the page is the view you have open. It is not copied into your note unless you copy the Region field. If you change the console region and search, you are searching a different set.

An empty list is for the detector you asked

list-findings returns ids for the detector id you passed. An empty page means that query, in that region, found nothing under those criteria. It does not describe another region’s detector. Write the detector id and the region on the empty result the same way you would on a hit.

What to file

File Id, Region, and the detector id from the finding or from the command you ran. If Region was not in the paste, write “region not copied” and do not fill it from the console you are looking at now. Do not search a second region and attach a different id because the type string looks familiar.

Worked case: an id looked up in the wrong region

A sandbox note says finding id abcd-1234 and nothing else. The author was viewing us-west-2. The JSON they copied from was Region us-east-1, detector det-east. A teammate searches us-west-2, gets no such id, and writes that the finding was deleted.

The corrected note adds Region us-east-1 and detector det-east. The id opens there. The us-west-2 search is a different query with its own empty result. Nothing was deleted.

Id: abcd-1234
Region: us-east-1
detector: det-east
us-west-2 search: a different query, empty
write: the finding is in us-east-1
not: deleted