AWS CloudTrail vs GCP Cloud Audit Logs for security investigations

1. Start with different coverage boundaries

AWS CloudTrail Event history provides the past 90 days of management events for one AWS account and one Region. It excludes data events, Insights events, and network activity events, and it is separate from trails and CloudTrail Lake event data stores.

Google Cloud Audit Logs separates activity into Admin Activity, Data Access, System Event, and Policy Denied logs. Data Access coverage can depend on service configuration and additional permissions, while access to every log type is governed by IAM.

Neither source should be described simply as “all cloud logs.” Before interpreting an absence, verify account or project scope, Region, log type, time window, retention, routing, and reader permissions.

Provider references: AWS Event history and Google Cloud Audit Logs

2. Reconstruct identity using each provider’s model

AWS identity

Start with userIdentity, ARN, principal ID, access key, session context, session issuer, and source identity when present.

GCP identity

Start with protoPayload.authenticationInfo, principal email, service-account delegation, and authorization information.

AWS action

Use eventSource, eventName, request parameters, resources, and response elements.

GCP action

Use serviceName, methodName, resource name, request, response, and resource labels.

Network context

Both can expose request-origin context, but an address can represent a proxy, service, workload, or intermediary—not necessarily a person.

Outcome

Check error or status fields and related entries. A denied or failed operation can still reveal intent or broken automation.

3. Expect different query workflows

CloudTrail Event history and lookup-events are intentionally bounded: one account, one Region, a time range, and one lookup attribute. For longer retention, organization scope, data events, or richer queries, use a trail or CloudTrail Lake.

Google Cloud Logs Explorer supports Boolean filters over fields such as log name, timestamp, resource type, labels, and audit payload fields. Effective queries still begin with a narrow resource and time window before adding a principal, method, or resource.

Query references: AWS CLI lookups and Google Logging query language

4. Use a shared investigation worksheet

• Scope: account or project, Region when applicable, UTC start and end, and relevant log category.
• Actor: human, role session, service account, workload identity, delegated identity, or provider service.
• Action: service, API method, read or write intent, parameters, and result.
• Target: resource identifier, owning account or project, and expected owner.
• Context: caller network, user agent or request metadata, adjacent activity, and change records.
• Confidence: which conclusions are observed, inferred, or still unverified.

5. Where Flare fits—and where it does not

Flare applies a shared ranking and explanation workflow to supported GCP Audit Logs and recent regional AWS CloudTrail management-event history. It helps a small team decide what to inspect first while preserving provider-specific supporting evidence.

Flare does not make the two providers identical, retain a complete copy of every log, or replace durable provider logging. It also does not prove malicious intent or provide real-time containment.