CloudTrail Lake: eventID is the record

Two identifiers, two jobs

A CloudTrail event has an eventID. That is the id of this record in CloudTrail. It also has a requestID, the id the service attached to the API request. They are different strings. Quoting one does not stand in for the other when someone has to open the same row.

A support note or an application log may mention the request id. That can help you find the event. The event you found still gets cited by eventID, or you have not said which record you mean.

Do not collapse them

If your paste has only a requestID, write “eventID not in this paste.” Do not relabel the requestID as the event id. A later query that selects eventID can be matched to the requestID only if you kept both on the first note.

Several fields can be present and still easy to swap in a table that lost its headers. Keep the field name on the same line as the value.

What to file

File eventID, requestID when you have it, eventTime, and eventName. Label each. If you matched an application log to requestID, say that the log line and the CloudTrail row are linked by that request id, and still cite eventID for the row.

Worked case: a request id filed as the event

A lab query returns eventID 11111111-2222-3333-4444-555555555555 and requestID req-abc. The ticket quotes only req-abc and calls it the CloudTrail id. A second person searches the store for that string in a column named eventID and finds nothing.

The note labels both. The application log matches req-abc. The CloudTrail record is eventID 11111111-2222-3333-4444-555555555555. The failed search was the wrong field, not a missing event.

eventID: 11111111-2222-3333-4444-555555555555
requestID: req-abc
eventName: DescribeInstances
app log: matches requestID req-abc
write: the row is the eventID
not: req-abc is the event id