Skip to main content
On this page

​
Coverage by target cloud

​
How the targets compare

Each row compares a capability of CloudTrail with its adaptation on each target. A dash means this row is not stated for that target.

​
Max adaptation

​
Runtime surface

​
Management surface

​
Infrastructure-only adaptation

​
Runtime surface

​
Management surface

​
On Google Cloud

​
How it works

On AWS, CloudTrail records your control-plane audit trail: who called which API, when, and from where. You do not call a “CloudTrail API” at runtime to make that happen; the platform records it for you. That is the key difference from the request-time edges: there is no runtime call from your application to log. Every cloud already produces the same kind of trail natively, so your aws_cloudtrail declaration maps onto the target’s own native audit log rather than provisioning a separate cross-cloud trail, because each cloud audits itself. The native log is recorded by the platform: on Google Cloud Audit Logs and OCI Audit it is genuinely always on and cannot be disabled; on Kubernetes the API-server audit is recorded whenever your audit policy is in effect, a cluster configuration that is not on by default. Reading history with LookupEvents queries that native log and returns the recorded events in the CloudTrail response shape.
  • Nothing to provision: your aws_cloudtrail declaration maps onto the target’s native audit log; there is no separate cross-cloud trail to stand up.
  • Recorded by the platform: the native audit log records every control-plane API call: always on Google Cloud Audit Logs and OCI Audit, recorded whenever your audit policy is in effect on Kubernetes.
  • History reads come off the native log. LookupEvents queries the native audit log and returns the recorded events; no runtime CloudTrail call in your application makes the trail happen.
On AWS, your control-plane API calls are recorded by CloudTrail as the AWS audit trail. In the target cloud, the same control-plane API calls are recorded natively by the target cloud's own audit log: always-on on Google Cloud and OCI, policy-gated on Kubernetes, and your aws_cloudtrail declaration maps onto that native log. LookupEvents reads history from the native log.On AWS, your control-plane API calls are recorded by CloudTrail as the AWS audit trail. In the target cloud, the same control-plane API calls are recorded natively by the target cloud's own audit log: always-on on Google Cloud and OCI, policy-gated on Kubernetes, and your aws_cloudtrail declaration maps onto that native log. LookupEvents reads history from the native log.

Your aws_cloudtrail declaration maps onto the target’s native audit log; there is no separate cross-cloud trail to provision, because each cloud audits itself; LookupEvents reads history from that native log.

​
The native audit log

Each cloud’s native audit log is its own platform service, so the always-on-versus-policy-gated distinction is real rather than cosmetic. On Google Cloud, the trail maps onto Cloud Audit Logs. Admin Activity audit logs are always on and cannot be disabled; Data Access audit logs are opt-in per service and per type (ADMIN_READ / DATA_READ / DATA_WRITE) via google_project_iam_audit_config. Entries land in Cloud Logging under the cloudaudit.googleapis.com log names. On OCI, the trail maps onto OCI Audit , which is always on for every tenancy and records every API call automatically; oci_audit_configuration controls only the retention period, not whether auditing runs. On Kubernetes, the trail maps onto the API-server audit policy and its backend: a kube-apiserver audit policy (a cluster configuration, not on by default) decides which requests are recorded and at what level (Metadata / Request / RequestResponse), and an audit backend (a log file, or a webhook feeding a log store or SIEM) receives them. It is recorded whenever your audit policy is in effect.
  • Google Cloud Audit Logs. Admin Activity is always-on and cannot be disabled; Data Access is opt-in per service and type via google_project_iam_audit_config.
  • OCI Audit: always on for the tenancy, recording every API call; oci_audit_configuration sets only the retention period.
  • Kubernetes API-server audit: policy-gated: the kube-apiserver audit policy plus an audit backend, not on by default; recorded whenever your policy is in effect.
Per target: Google Cloud maps onto Cloud Audit Logs (Admin Activity plus Data Access via google_project_iam_audit_config), which is always on and cannot be disabled. OCI maps onto OCI Audit, always on for the tenancy with oci_audit_configuration setting only retention. Kubernetes maps onto the API-server audit policy and backend, which is policy-gated and not on by default.Per target: Google Cloud maps onto Cloud Audit Logs (Admin Activity plus Data Access via google_project_iam_audit_config), which is always on and cannot be disabled. OCI maps onto OCI Audit, always on for the tenancy with oci_audit_configuration setting only retention. Kubernetes maps onto the API-server audit policy and backend, which is policy-gated and not on by default.

Each target’s native audit log is its own platform service: always-on on Google Cloud and OCI, policy-gated on Kubernetes; your trail maps onto it.

​
Reading history (LookupEvents)

LookupEvents is CloudTrail’s history read: query the recent window of control-plane events, filtered by LookupAttributes such as EventName, Username, or ResourceType. Because the events are already recorded in the native audit log, a LookupEvents call maps onto a query against that log, and the recorded events are returned in the CloudTrail record shape. The query surface is the native log’s. On Google Cloud the read runs against Cloud Logging (the Logs Explorer or the Logging API), filtering on resource.type and protoPayload.methodName under the cloudaudit.googleapis.com log names. On OCI it runs against the OCI Audit query (or Logging Analytics), filtering on event source and compartment. On Kubernetes it runs against the cluster’s audit backend (the log store or SIEM the audit webhook feeds) using that store’s filters. In every case the recorded events come back, but the attribute-filter surface is a subset of CloudTrail’s LookupAttributes : you filter with what the native log’s query language expresses, and the event body is the native audit entry mapped to a CloudTrail record.
  • Google Cloud. Cloud Logging, filtering on resource.type / protoPayload.methodName under cloudaudit.googleapis.com.
  • OCI: the OCI Audit query (or Logging Analytics), filtering on event source and compartment.
  • Kubernetes: the cluster’s audit backend (the log store / SIEM the audit webhook feeds), using that store’s filters.
  • A subset of LookupAttributes: the recorded events return in the CloudTrail record shape; the filter surface is the native log’s, not CloudTrail’s full attribute set.
A LookupEvents call with LookupAttributes filters is queried against each target's native audit log: Google Cloud Logging filtering on resource.type and protoPayload.methodName, the OCI Audit query filtering on event source and compartment, and the Kubernetes cluster's audit backend using the log store or SIEM the webhook feeds. Results come back in the CloudTrail record shape; the attribute-filter surface is a subset of CloudTrail's LookupAttributes.A LookupEvents call with LookupAttributes filters is queried against each target's native audit log: Google Cloud Logging filtering on resource.type and protoPayload.methodName, the OCI Audit query filtering on event source and compartment, and the Kubernetes cluster's audit backend using the log store or SIEM the webhook feeds. Results come back in the CloudTrail record shape; the attribute-filter surface is a subset of CloudTrail's LookupAttributes.

A LookupEvents call is queried against the native audit log: Cloud Logging, the OCI Audit query, or the cluster’s audit backend; the recorded events come back in the CloudTrail record shape, and the attribute-filter surface is a subset of LookupAttributes.

​
Data events & selectors

CloudTrail’s default trail records management events, the control-plane calls. Data events are the high-volume data-plane operations (S3 object reads and writes, Lambda invocations), configured with PutEventSelectors, as event_selector and advanced_event_selector. These map onto the native data-access log where the target has one, and the granularity is where they diverge. On Google Cloud, the selectors map onto Data Access audit logs, enabled per service and per type (ADMIN_READ / DATA_READ / DATA_WRITE) via google_project_iam_audit_config; this is per-service-and-type rather than CloudTrail’s per-resource-ARN selectors, so common S3-object-style intent maps but the granularity differs. On OCI, data-plane object access (the Object Storage and Functions analog of S3 data events) rides OCI Logging service logs, which OCI keeps separate from the Audit management stream, so the selector maps onto service logs rather than the audit trail. On Kubernetes, the audit policy itself expresses data-access rules (verb, resource, and subresource at a chosen level); per-object S3- or Lambda-style data events have no direct Kubernetes analog, so this undercovers CloudTrail data events.
  • Google Cloud. Data Access audit logs, per service and type via google_project_iam_audit_config: per-service-and-type, not per-object-ARN.
  • OCI. OCI Logging service logs (Object Storage / function data-plane), kept separate from the Audit management stream.
  • Kubernetes: the audit policy’s verb / resource / subresource rules; no per-object data-event analog, so this undercovers.
CloudTrail data-event selectors, configured with PutEventSelectors as event_selector or advanced_event_selector, map onto each target's native data-access log: Google Cloud Data Access audit logs per service and type via google_project_iam_audit_config, OCI Logging service logs for Object Storage and function data-plane access kept separate from the Audit stream, and the Kubernetes audit policy's verb, resource, and subresource rules, where per-object data events have no direct analog.CloudTrail data-event selectors, configured with PutEventSelectors as event_selector or advanced_event_selector, map onto each target's native data-access log: Google Cloud Data Access audit logs per service and type via google_project_iam_audit_config, OCI Logging service logs for Object Storage and function data-plane access kept separate from the Audit stream, and the Kubernetes audit policy's verb, resource, and subresource rules, where per-object data events have no direct analog.

Data-event selectors map onto the native data-access log where the target has one: per-service-and-type Data Access logs on Google Cloud, OCI Logging service logs on OCI, and audit-policy rules on Kubernetes; the intent maps but the granularity differs.

​
Trail config & logging control

The trail-config surface maps onto the native audit log. CreateTrail stands up nothing new: your aws_cloudtrail declaration maps onto the native log, because the cloud already audits itself, and DescribeTrails, GetTrail, and ListTrails report the mapped trail (name, home region, multi-region and organization flags). UpdateTrail accepts is_multi_region_trail and is_organization_trail changes; an AWS-only destination (an S3 bucket or an SNS topic) is reported back rather than silently applied. Logging control is where the always-on-versus-policy-gated distinction shows through. GetTrailStatus reports IsLogging: on Google Cloud and OCI it is continuously true; on Kubernetes it follows your audit policy. StartLogging returns success, because the always-on clouds are already recording, and on Kubernetes the log records per your policy. StopLogging is the call that diverges most: on Google Cloud Audit Logs and OCI Audit the platform audit log cannot be switched off, so a StopLogging that would blind your control-plane trail is refused rather than silently dropping coverage; on Kubernetes it maps to disabling the kube-apiserver audit policy, which stays the target cluster configuration to manage .
  • CreateTrail maps onto the native log: there is no separate cross-cloud trail to provision; DescribeTrails / GetTrail report the mapped trail.
  • GetTrailStatus reports IsLogging: continuously true on Google Cloud and OCI; per your audit policy on Kubernetes.
  • StopLogging is refused on the always-on clouds. Google Cloud Audit Logs and OCI Audit cannot be switched off; on Kubernetes it maps to managing the audit policy on the cluster.
The trail-config calls (CreateTrail, DescribeTrails, GetTrail, ListTrails, UpdateTrail) map onto the native audit log as the mapped trail. Logging control differs by whether the native log is always-on: on Google Cloud Audit Logs and OCI Audit, GetTrailStatus reports IsLogging true, StartLogging returns success because it is already recording, and StopLogging is refused because the platform audit log cannot be switched off. On Kubernetes, GetTrailStatus reports IsLogging per your audit policy, StartLogging returns success recording per policy, and StopLogging maps to managing the audit policy on the cluster.The trail-config calls (CreateTrail, DescribeTrails, GetTrail, ListTrails, UpdateTrail) map onto the native audit log as the mapped trail. Logging control differs by whether the native log is always-on: on Google Cloud Audit Logs and OCI Audit, GetTrailStatus reports IsLogging true, StartLogging returns success because it is already recording, and StopLogging is refused because the platform audit log cannot be switched off. On Kubernetes, GetTrailStatus reports IsLogging per your audit policy, StartLogging returns success recording per policy, and StopLogging maps to managing the audit policy on the cluster.

The trail-config calls map onto the native audit log; logging control differs by whether the native log is always-on (refuse StopLogging) or policy-gated (StopLogging is your audit policy to manage).

​
Limitations

The list below is the whole go/no-go picture for CloudTrail. Control-plane audit coverage is faithful: the native log records every management API call. The differences are the LookupEvents query surface, data-event granularity, StopLogging on the always-on clouds, CloudTrail Insights, log-file integrity, and the absence of a historical backlog. Every one is behavioral and named here rather than discovered later. △ Where CloudTrail and the target’s native audit log diverge, read before you adopt
  • The LookupEvents query surface is a subset: a LookupEvents call is queried against the native audit log (Cloud Logging filters / the OCI Audit query / the cluster’s audit backend), so you filter with the native log’s query language rather than CloudTrail’s full LookupAttributes, and the event body is the native audit entry mapped to a CloudTrail record.
  • Data-event granularity differs. CloudTrail’s per-resource-ARN selectors map onto per-service-and-type Data Access audit logs on Google Cloud (google_project_iam_audit_config), OCI Logging service logs on OCI, and audit-policy verb/resource rules on Kubernetes; the common intent maps but the per-object granularity does not translate one-for-one, and on Kubernetes per-object data events have no direct analog.
  • StopLogging is out of scope on the always-on clouds. Google Cloud Audit Logs (Admin Activity) and OCI Audit cannot be turned off, so StopLogging is refused rather than silently dropping coverage. On Kubernetes it is Partial: it maps to disabling the kube-apiserver audit policy, which stays the target cluster configuration to manage.
  • No CloudTrail Insights analog. PutInsightSelectors / GetInsightSelectors anomaly detection has no native audit-log equivalent and is out of scope; use the target cloud’s own log-based alerting over the native audit log.
  • No digest-file integrity chain. CloudTrail’s enable_log_file_validation SHA-256 digest-file chain (and ListPublicKeys) is CloudTrail-specific; the native audit log has its own tamper-evidence: Cloud Logging’s retention locks, OCI Audit’s managed tamper-resistant retention, or whatever the Kubernetes audit backend’s log store provides.
  • No historical backlog migration: the native audit log is already recording your control-plane activity on this cloud from before cutover; your existing AWS trail history stays in its S3 bucket on AWS, and new events are recorded to the native log going forward. Moving existing CloudTrail history is a separate export/import.

​
Other considerations

Beyond the query-surface and data-event boundaries above, a few facts shape how CloudTrail behaves as a declared edge: nothing runs at request time, the platform already audits itself, and coverage, retention, and cost are the native audit log’s.
  • Nothing is provisioned or called at runtime; the platform already audits itself: unlike the request-time edges, the trail is recorded natively, so your aws_cloudtrail declaration maps onto the existing audit log rather than standing up a cross-cloud trail or a runtime API to call.
  • Coverage is always-on on two clouds and policy-gated on the third. Google Cloud Admin Activity and OCI Audit cannot be turned off (so StopLogging is refused); the Kubernetes API-server audit is recorded only while your audit policy is in effect, so on Kubernetes you own turning audit on and keeping it on.
  • The native log holds the events, with its own retention and tamper-evidence: history lives in Cloud Logging, the OCI Audit stream, or the Kubernetes audit backend, each with its own retention and integrity controls in place of CloudTrail’s digest-file chain.
  • Existing AWS trail history stays on AWS: the native log records this cloud’s activity from cutover forward; your prior CloudTrail history remains in its S3 bucket on AWS, and moving it is a separate export/import.
  • Cost follows the native audit log: management-event auditing is generally included (Admin Activity, OCI Audit), while data-access logging and the Kubernetes audit backend’s log store bill under the target cloud’s own model rather than a CloudTrail per-event charge.

​
On Azure and Private Kubernetes

​
How it works

On AWS, CloudTrail records your control-plane audit trail: who called which API, when, and from where. You do not call a “CloudTrail API” at runtime to make that happen; the platform records it for you. That is the key difference from the request-time edges: there is no runtime call from your application to log. Every cloud already produces the same kind of trail natively, so your aws_cloudtrail declaration maps onto the target’s own native audit log rather than provisioning a separate cross-cloud trail, because each cloud audits itself. The native log is recorded by the platform: on Google Cloud Audit Logs and OCI Audit it is genuinely always on and cannot be disabled; on Kubernetes the API-server audit is recorded whenever your audit policy is in effect, a cluster configuration that is not on by default. Reading history with LookupEvents queries that native log and returns the recorded events in the CloudTrail response shape.
  • Nothing to provision: your aws_cloudtrail declaration maps onto the target’s native audit log; there is no separate cross-cloud trail to stand up.
  • Recorded by the platform: the native audit log records every control-plane API call: always on Google Cloud Audit Logs and OCI Audit, recorded whenever your audit policy is in effect on Kubernetes.
  • History reads come off the native log. LookupEvents queries the native audit log and returns the recorded events; no runtime CloudTrail call in your application makes the trail happen.
On AWS, your control-plane API calls are recorded by CloudTrail as the AWS audit trail. In the target cloud, the same control-plane API calls are recorded natively by the target cloud's own audit log: always-on on Google Cloud and OCI, policy-gated on Kubernetes, and your aws_cloudtrail declaration maps onto that native log. LookupEvents reads history from the native log.On AWS, your control-plane API calls are recorded by CloudTrail as the AWS audit trail. In the target cloud, the same control-plane API calls are recorded natively by the target cloud's own audit log: always-on on Google Cloud and OCI, policy-gated on Kubernetes, and your aws_cloudtrail declaration maps onto that native log. LookupEvents reads history from the native log.

Your aws_cloudtrail declaration maps onto the target’s native audit log; there is no separate cross-cloud trail to provision, because each cloud audits itself; LookupEvents reads history from that native log.

​
The native audit log

Each cloud’s native audit log is its own platform service, so the always-on-versus-policy-gated distinction is real rather than cosmetic. On Google Cloud, the trail maps onto Cloud Audit Logs. Admin Activity audit logs are always on and cannot be disabled; Data Access audit logs are opt-in per service and per type (ADMIN_READ / DATA_READ / DATA_WRITE) via google_project_iam_audit_config. Entries land in Cloud Logging under the cloudaudit.googleapis.com log names. On OCI, the trail maps onto OCI Audit , which is always on for every tenancy and records every API call automatically; oci_audit_configuration controls only the retention period, not whether auditing runs. On Kubernetes, the trail maps onto the API-server audit policy and its backend: a kube-apiserver audit policy (a cluster configuration, not on by default) decides which requests are recorded and at what level (Metadata / Request / RequestResponse), and an audit backend (a log file, or a webhook feeding a log store or SIEM) receives them. It is recorded whenever your audit policy is in effect.
  • Google Cloud Audit Logs. Admin Activity is always-on and cannot be disabled; Data Access is opt-in per service and type via google_project_iam_audit_config.
  • OCI Audit: always on for the tenancy, recording every API call; oci_audit_configuration sets only the retention period.
  • Kubernetes API-server audit: policy-gated: the kube-apiserver audit policy plus an audit backend, not on by default; recorded whenever your policy is in effect.
Per target: Google Cloud maps onto Cloud Audit Logs (Admin Activity plus Data Access via google_project_iam_audit_config), which is always on and cannot be disabled. OCI maps onto OCI Audit, always on for the tenancy with oci_audit_configuration setting only retention. Kubernetes maps onto the API-server audit policy and backend, which is policy-gated and not on by default.Per target: Google Cloud maps onto Cloud Audit Logs (Admin Activity plus Data Access via google_project_iam_audit_config), which is always on and cannot be disabled. OCI maps onto OCI Audit, always on for the tenancy with oci_audit_configuration setting only retention. Kubernetes maps onto the API-server audit policy and backend, which is policy-gated and not on by default.

Each target’s native audit log is its own platform service: always-on on Google Cloud and OCI, policy-gated on Kubernetes; your trail maps onto it.

​
Reading history (LookupEvents)

LookupEvents is CloudTrail’s history read: query the recent window of control-plane events, filtered by LookupAttributes such as EventName, Username, or ResourceType. Because the events are already recorded in the native audit log, a LookupEvents call maps onto a query against that log, and the recorded events are returned in the CloudTrail record shape. The query surface is the native log’s. On Google Cloud the read runs against Cloud Logging (the Logs Explorer or the Logging API), filtering on resource.type and protoPayload.methodName under the cloudaudit.googleapis.com log names. On OCI it runs against the OCI Audit query (or Logging Analytics), filtering on event source and compartment. On Kubernetes it runs against the cluster’s audit backend (the log store or SIEM the audit webhook feeds) using that store’s filters. In every case the recorded events come back, but the attribute-filter surface is a subset of CloudTrail’s LookupAttributes : you filter with what the native log’s query language expresses, and the event body is the native audit entry mapped to a CloudTrail record.
  • Google Cloud. Cloud Logging, filtering on resource.type / protoPayload.methodName under cloudaudit.googleapis.com.
  • OCI: the OCI Audit query (or Logging Analytics), filtering on event source and compartment.
  • Kubernetes: the cluster’s audit backend (the log store / SIEM the audit webhook feeds), using that store’s filters.
  • A subset of LookupAttributes: the recorded events return in the CloudTrail record shape; the filter surface is the native log’s, not CloudTrail’s full attribute set.
A LookupEvents call with LookupAttributes filters is queried against each target's native audit log: Google Cloud Logging filtering on resource.type and protoPayload.methodName, the OCI Audit query filtering on event source and compartment, and the Kubernetes cluster's audit backend using the log store or SIEM the webhook feeds. Results come back in the CloudTrail record shape; the attribute-filter surface is a subset of CloudTrail's LookupAttributes.A LookupEvents call with LookupAttributes filters is queried against each target's native audit log: Google Cloud Logging filtering on resource.type and protoPayload.methodName, the OCI Audit query filtering on event source and compartment, and the Kubernetes cluster's audit backend using the log store or SIEM the webhook feeds. Results come back in the CloudTrail record shape; the attribute-filter surface is a subset of CloudTrail's LookupAttributes.

A LookupEvents call is queried against the native audit log: Cloud Logging, the OCI Audit query, or the cluster’s audit backend; the recorded events come back in the CloudTrail record shape, and the attribute-filter surface is a subset of LookupAttributes.

​
Data events & selectors

CloudTrail’s default trail records management events, the control-plane calls. Data events are the high-volume data-plane operations (S3 object reads and writes, Lambda invocations), configured with PutEventSelectors, as event_selector and advanced_event_selector. These map onto the native data-access log where the target has one, and the granularity is where they diverge. On Google Cloud, the selectors map onto Data Access audit logs, enabled per service and per type (ADMIN_READ / DATA_READ / DATA_WRITE) via google_project_iam_audit_config; this is per-service-and-type rather than CloudTrail’s per-resource-ARN selectors, so common S3-object-style intent maps but the granularity differs. On OCI, data-plane object access (the Object Storage and Functions analog of S3 data events) rides OCI Logging service logs, which OCI keeps separate from the Audit management stream, so the selector maps onto service logs rather than the audit trail. On Kubernetes, the audit policy itself expresses data-access rules (verb, resource, and subresource at a chosen level); per-object S3- or Lambda-style data events have no direct Kubernetes analog, so this undercovers CloudTrail data events.
  • Google Cloud. Data Access audit logs, per service and type via google_project_iam_audit_config: per-service-and-type, not per-object-ARN.
  • OCI. OCI Logging service logs (Object Storage / function data-plane), kept separate from the Audit management stream.
  • Kubernetes: the audit policy’s verb / resource / subresource rules; no per-object data-event analog, so this undercovers.
CloudTrail data-event selectors, configured with PutEventSelectors as event_selector or advanced_event_selector, map onto each target's native data-access log: Google Cloud Data Access audit logs per service and type via google_project_iam_audit_config, OCI Logging service logs for Object Storage and function data-plane access kept separate from the Audit stream, and the Kubernetes audit policy's verb, resource, and subresource rules, where per-object data events have no direct analog.CloudTrail data-event selectors, configured with PutEventSelectors as event_selector or advanced_event_selector, map onto each target's native data-access log: Google Cloud Data Access audit logs per service and type via google_project_iam_audit_config, OCI Logging service logs for Object Storage and function data-plane access kept separate from the Audit stream, and the Kubernetes audit policy's verb, resource, and subresource rules, where per-object data events have no direct analog.

Data-event selectors map onto the native data-access log where the target has one: per-service-and-type Data Access logs on Google Cloud, OCI Logging service logs on OCI, and audit-policy rules on Kubernetes; the intent maps but the granularity differs.

​
Trail config & logging control

The trail-config surface maps onto the native audit log. CreateTrail stands up nothing new: your aws_cloudtrail declaration maps onto the native log, because the cloud already audits itself, and DescribeTrails, GetTrail, and ListTrails report the mapped trail (name, home region, multi-region and organization flags). UpdateTrail accepts is_multi_region_trail and is_organization_trail changes; an AWS-only destination (an S3 bucket or an SNS topic) is reported back rather than silently applied. Logging control is where the always-on-versus-policy-gated distinction shows through. GetTrailStatus reports IsLogging: on Google Cloud and OCI it is continuously true; on Kubernetes it follows your audit policy. StartLogging returns success, because the always-on clouds are already recording, and on Kubernetes the log records per your policy. StopLogging is the call that diverges most: on Google Cloud Audit Logs and OCI Audit the platform audit log cannot be switched off, so a StopLogging that would blind your control-plane trail is refused rather than silently dropping coverage; on Kubernetes it maps to disabling the kube-apiserver audit policy, which stays the target cluster configuration to manage .
  • CreateTrail maps onto the native log: there is no separate cross-cloud trail to provision; DescribeTrails / GetTrail report the mapped trail.
  • GetTrailStatus reports IsLogging: continuously true on Google Cloud and OCI; per your audit policy on Kubernetes.
  • StopLogging is refused on the always-on clouds. Google Cloud Audit Logs and OCI Audit cannot be switched off; on Kubernetes it maps to managing the audit policy on the cluster.
The trail-config calls (CreateTrail, DescribeTrails, GetTrail, ListTrails, UpdateTrail) map onto the native audit log as the mapped trail. Logging control differs by whether the native log is always-on: on Google Cloud Audit Logs and OCI Audit, GetTrailStatus reports IsLogging true, StartLogging returns success because it is already recording, and StopLogging is refused because the platform audit log cannot be switched off. On Kubernetes, GetTrailStatus reports IsLogging per your audit policy, StartLogging returns success recording per policy, and StopLogging maps to managing the audit policy on the cluster.The trail-config calls (CreateTrail, DescribeTrails, GetTrail, ListTrails, UpdateTrail) map onto the native audit log as the mapped trail. Logging control differs by whether the native log is always-on: on Google Cloud Audit Logs and OCI Audit, GetTrailStatus reports IsLogging true, StartLogging returns success because it is already recording, and StopLogging is refused because the platform audit log cannot be switched off. On Kubernetes, GetTrailStatus reports IsLogging per your audit policy, StartLogging returns success recording per policy, and StopLogging maps to managing the audit policy on the cluster.

The trail-config calls map onto the native audit log; logging control differs by whether the native log is always-on (refuse StopLogging) or policy-gated (StopLogging is your audit policy to manage).

​
Limitations

The list below is the whole go/no-go picture for CloudTrail. Control-plane audit coverage is faithful: the native log records every management API call. The differences are the LookupEvents query surface, data-event granularity, StopLogging on the always-on clouds, CloudTrail Insights, log-file integrity, and the absence of a historical backlog. Every one is behavioral and named here rather than discovered later. △ Where CloudTrail and the target’s native audit log diverge, read before you adopt
  • The LookupEvents query surface is a subset: a LookupEvents call is queried against the native audit log (Cloud Logging filters / the OCI Audit query / the cluster’s audit backend), so you filter with the native log’s query language rather than CloudTrail’s full LookupAttributes, and the event body is the native audit entry mapped to a CloudTrail record.
  • Data-event granularity differs. CloudTrail’s per-resource-ARN selectors map onto per-service-and-type Data Access audit logs on Google Cloud (google_project_iam_audit_config), OCI Logging service logs on OCI, and audit-policy verb/resource rules on Kubernetes; the common intent maps but the per-object granularity does not translate one-for-one, and on Kubernetes per-object data events have no direct analog.
  • StopLogging is out of scope on the always-on clouds. Google Cloud Audit Logs (Admin Activity) and OCI Audit cannot be turned off, so StopLogging is refused rather than silently dropping coverage. On Kubernetes it is Partial: it maps to disabling the kube-apiserver audit policy, which stays the target cluster configuration to manage.
  • No CloudTrail Insights analog. PutInsightSelectors / GetInsightSelectors anomaly detection has no native audit-log equivalent and is out of scope; use the target cloud’s own log-based alerting over the native audit log.
  • No digest-file integrity chain. CloudTrail’s enable_log_file_validation SHA-256 digest-file chain (and ListPublicKeys) is CloudTrail-specific; the native audit log has its own tamper-evidence: Cloud Logging’s retention locks, OCI Audit’s managed tamper-resistant retention, or whatever the Kubernetes audit backend’s log store provides.
  • No historical backlog migration: the native audit log is already recording your control-plane activity on this cloud from before cutover; your existing AWS trail history stays in its S3 bucket on AWS, and new events are recorded to the native log going forward. Moving existing CloudTrail history is a separate export/import.

​
Other considerations

Beyond the query-surface and data-event boundaries above, a few facts shape how CloudTrail behaves as a declared edge: nothing runs at request time, the platform already audits itself, and coverage, retention, and cost are the native audit log’s.
  • Nothing is provisioned or called at runtime; the platform already audits itself: unlike the request-time edges, the trail is recorded natively, so your aws_cloudtrail declaration maps onto the existing audit log rather than standing up a cross-cloud trail or a runtime API to call.
  • Coverage is always-on on two clouds and policy-gated on the third. Google Cloud Admin Activity and OCI Audit cannot be turned off (so StopLogging is refused); the Kubernetes API-server audit is recorded only while your audit policy is in effect, so on Kubernetes you own turning audit on and keeping it on.
  • The native log holds the events, with its own retention and tamper-evidence: history lives in Cloud Logging, the OCI Audit stream, or the Kubernetes audit backend, each with its own retention and integrity controls in place of CloudTrail’s digest-file chain.
  • Existing AWS trail history stays on AWS: the native log records this cloud’s activity from cutover forward; your prior CloudTrail history remains in its S3 bucket on AWS, and moving it is a separate export/import.
  • Cost follows the native audit log: management-event auditing is generally included (Admin Activity, OCI Audit), while data-access logging and the Kubernetes audit backend’s log store bill under the target cloud’s own model rather than a CloudTrail per-event charge.

​
On OCI

​
How it works

On AWS, CloudTrail records your control-plane audit trail: who called which API, when, and from where. You do not call a “CloudTrail API” at runtime to make that happen; the platform records it for you. That is the key difference from the request-time edges: there is no runtime call from your application to log. Every cloud already produces the same kind of trail natively, so your aws_cloudtrail declaration maps onto the target’s own native audit log rather than provisioning a separate cross-cloud trail, because each cloud audits itself. The native log is recorded by the platform: on Google Cloud Audit Logs and OCI Audit it is genuinely always on and cannot be disabled; on Kubernetes the API-server audit is recorded whenever your audit policy is in effect, a cluster configuration that is not on by default. Reading history with LookupEvents queries that native log and returns the recorded events in the CloudTrail response shape.
  • Nothing to provision: your aws_cloudtrail declaration maps onto the target’s native audit log; there is no separate cross-cloud trail to stand up.
  • Recorded by the platform: the native audit log records every control-plane API call: always on Google Cloud Audit Logs and OCI Audit, recorded whenever your audit policy is in effect on Kubernetes.
  • History reads come off the native log. LookupEvents queries the native audit log and returns the recorded events; no runtime CloudTrail call in your application makes the trail happen.
On AWS, your control-plane API calls are recorded by CloudTrail as the AWS audit trail. In the target cloud, the same control-plane API calls are recorded natively by the target cloud's own audit log: always-on on Google Cloud and OCI, policy-gated on Kubernetes, and your aws_cloudtrail declaration maps onto that native log. LookupEvents reads history from the native log.On AWS, your control-plane API calls are recorded by CloudTrail as the AWS audit trail. In the target cloud, the same control-plane API calls are recorded natively by the target cloud's own audit log: always-on on Google Cloud and OCI, policy-gated on Kubernetes, and your aws_cloudtrail declaration maps onto that native log. LookupEvents reads history from the native log.

Your aws_cloudtrail declaration maps onto the target’s native audit log; there is no separate cross-cloud trail to provision, because each cloud audits itself; LookupEvents reads history from that native log.

​
The native audit log

Each cloud’s native audit log is its own platform service, so the always-on-versus-policy-gated distinction is real rather than cosmetic. On Google Cloud, the trail maps onto Cloud Audit Logs. Admin Activity audit logs are always on and cannot be disabled; Data Access audit logs are opt-in per service and per type (ADMIN_READ / DATA_READ / DATA_WRITE) via google_project_iam_audit_config. Entries land in Cloud Logging under the cloudaudit.googleapis.com log names. On OCI, the trail maps onto OCI Audit , which is always on for every tenancy and records every API call automatically; oci_audit_configuration controls only the retention period, not whether auditing runs. On Kubernetes, the trail maps onto the API-server audit policy and its backend: a kube-apiserver audit policy (a cluster configuration, not on by default) decides which requests are recorded and at what level (Metadata / Request / RequestResponse), and an audit backend (a log file, or a webhook feeding a log store or SIEM) receives them. It is recorded whenever your audit policy is in effect.
  • Google Cloud Audit Logs. Admin Activity is always-on and cannot be disabled; Data Access is opt-in per service and type via google_project_iam_audit_config.
  • OCI Audit: always on for the tenancy, recording every API call; oci_audit_configuration sets only the retention period.
  • Kubernetes API-server audit: policy-gated: the kube-apiserver audit policy plus an audit backend, not on by default; recorded whenever your policy is in effect.
Per target: Google Cloud maps onto Cloud Audit Logs (Admin Activity plus Data Access via google_project_iam_audit_config), which is always on and cannot be disabled. OCI maps onto OCI Audit, always on for the tenancy with oci_audit_configuration setting only retention. Kubernetes maps onto the API-server audit policy and backend, which is policy-gated and not on by default.Per target: Google Cloud maps onto Cloud Audit Logs (Admin Activity plus Data Access via google_project_iam_audit_config), which is always on and cannot be disabled. OCI maps onto OCI Audit, always on for the tenancy with oci_audit_configuration setting only retention. Kubernetes maps onto the API-server audit policy and backend, which is policy-gated and not on by default.

Each target’s native audit log is its own platform service: always-on on Google Cloud and OCI, policy-gated on Kubernetes; your trail maps onto it.

​
Reading history (LookupEvents)

LookupEvents is CloudTrail’s history read: query the recent window of control-plane events, filtered by LookupAttributes such as EventName, Username, or ResourceType. Because the events are already recorded in the native audit log, a LookupEvents call maps onto a query against that log, and the recorded events are returned in the CloudTrail record shape. The query surface is the native log’s. On Google Cloud the read runs against Cloud Logging (the Logs Explorer or the Logging API), filtering on resource.type and protoPayload.methodName under the cloudaudit.googleapis.com log names. On OCI it runs against the OCI Audit query (or Logging Analytics), filtering on event source and compartment. On Kubernetes it runs against the cluster’s audit backend (the log store or SIEM the audit webhook feeds) using that store’s filters. In every case the recorded events come back, but the attribute-filter surface is a subset of CloudTrail’s LookupAttributes : you filter with what the native log’s query language expresses, and the event body is the native audit entry mapped to a CloudTrail record.
  • Google Cloud. Cloud Logging, filtering on resource.type / protoPayload.methodName under cloudaudit.googleapis.com.
  • OCI: the OCI Audit query (or Logging Analytics), filtering on event source and compartment.
  • Kubernetes: the cluster’s audit backend (the log store / SIEM the audit webhook feeds), using that store’s filters.
  • A subset of LookupAttributes: the recorded events return in the CloudTrail record shape; the filter surface is the native log’s, not CloudTrail’s full attribute set.
A LookupEvents call with LookupAttributes filters is queried against each target's native audit log: Google Cloud Logging filtering on resource.type and protoPayload.methodName, the OCI Audit query filtering on event source and compartment, and the Kubernetes cluster's audit backend using the log store or SIEM the webhook feeds. Results come back in the CloudTrail record shape; the attribute-filter surface is a subset of CloudTrail's LookupAttributes.A LookupEvents call with LookupAttributes filters is queried against each target's native audit log: Google Cloud Logging filtering on resource.type and protoPayload.methodName, the OCI Audit query filtering on event source and compartment, and the Kubernetes cluster's audit backend using the log store or SIEM the webhook feeds. Results come back in the CloudTrail record shape; the attribute-filter surface is a subset of CloudTrail's LookupAttributes.

A LookupEvents call is queried against the native audit log: Cloud Logging, the OCI Audit query, or the cluster’s audit backend; the recorded events come back in the CloudTrail record shape, and the attribute-filter surface is a subset of LookupAttributes.

​
Data events & selectors

CloudTrail’s default trail records management events, the control-plane calls. Data events are the high-volume data-plane operations (S3 object reads and writes, Lambda invocations), configured with PutEventSelectors, as event_selector and advanced_event_selector. These map onto the native data-access log where the target has one, and the granularity is where they diverge. On Google Cloud, the selectors map onto Data Access audit logs, enabled per service and per type (ADMIN_READ / DATA_READ / DATA_WRITE) via google_project_iam_audit_config; this is per-service-and-type rather than CloudTrail’s per-resource-ARN selectors, so common S3-object-style intent maps but the granularity differs. On OCI, data-plane object access (the Object Storage and Functions analog of S3 data events) rides OCI Logging service logs, which OCI keeps separate from the Audit management stream, so the selector maps onto service logs rather than the audit trail. On Kubernetes, the audit policy itself expresses data-access rules (verb, resource, and subresource at a chosen level); per-object S3- or Lambda-style data events have no direct Kubernetes analog, so this undercovers CloudTrail data events.
  • Google Cloud. Data Access audit logs, per service and type via google_project_iam_audit_config: per-service-and-type, not per-object-ARN.
  • OCI. OCI Logging service logs (Object Storage / function data-plane), kept separate from the Audit management stream.
  • Kubernetes: the audit policy’s verb / resource / subresource rules; no per-object data-event analog, so this undercovers.
CloudTrail data-event selectors, configured with PutEventSelectors as event_selector or advanced_event_selector, map onto each target's native data-access log: Google Cloud Data Access audit logs per service and type via google_project_iam_audit_config, OCI Logging service logs for Object Storage and function data-plane access kept separate from the Audit stream, and the Kubernetes audit policy's verb, resource, and subresource rules, where per-object data events have no direct analog.CloudTrail data-event selectors, configured with PutEventSelectors as event_selector or advanced_event_selector, map onto each target's native data-access log: Google Cloud Data Access audit logs per service and type via google_project_iam_audit_config, OCI Logging service logs for Object Storage and function data-plane access kept separate from the Audit stream, and the Kubernetes audit policy's verb, resource, and subresource rules, where per-object data events have no direct analog.

Data-event selectors map onto the native data-access log where the target has one: per-service-and-type Data Access logs on Google Cloud, OCI Logging service logs on OCI, and audit-policy rules on Kubernetes; the intent maps but the granularity differs.

​
Trail config & logging control

The trail-config surface maps onto the native audit log. CreateTrail stands up nothing new: your aws_cloudtrail declaration maps onto the native log, because the cloud already audits itself, and DescribeTrails, GetTrail, and ListTrails report the mapped trail (name, home region, multi-region and organization flags). UpdateTrail accepts is_multi_region_trail and is_organization_trail changes; an AWS-only destination (an S3 bucket or an SNS topic) is reported back rather than silently applied. Logging control is where the always-on-versus-policy-gated distinction shows through. GetTrailStatus reports IsLogging: on Google Cloud and OCI it is continuously true; on Kubernetes it follows your audit policy. StartLogging returns success, because the always-on clouds are already recording, and on Kubernetes the log records per your policy. StopLogging is the call that diverges most: on Google Cloud Audit Logs and OCI Audit the platform audit log cannot be switched off, so a StopLogging that would blind your control-plane trail is refused rather than silently dropping coverage; on Kubernetes it maps to disabling the kube-apiserver audit policy, which stays the target cluster configuration to manage .
  • CreateTrail maps onto the native log: there is no separate cross-cloud trail to provision; DescribeTrails / GetTrail report the mapped trail.
  • GetTrailStatus reports IsLogging: continuously true on Google Cloud and OCI; per your audit policy on Kubernetes.
  • StopLogging is refused on the always-on clouds. Google Cloud Audit Logs and OCI Audit cannot be switched off; on Kubernetes it maps to managing the audit policy on the cluster.
The trail-config calls (CreateTrail, DescribeTrails, GetTrail, ListTrails, UpdateTrail) map onto the native audit log as the mapped trail. Logging control differs by whether the native log is always-on: on Google Cloud Audit Logs and OCI Audit, GetTrailStatus reports IsLogging true, StartLogging returns success because it is already recording, and StopLogging is refused because the platform audit log cannot be switched off. On Kubernetes, GetTrailStatus reports IsLogging per your audit policy, StartLogging returns success recording per policy, and StopLogging maps to managing the audit policy on the cluster.The trail-config calls (CreateTrail, DescribeTrails, GetTrail, ListTrails, UpdateTrail) map onto the native audit log as the mapped trail. Logging control differs by whether the native log is always-on: on Google Cloud Audit Logs and OCI Audit, GetTrailStatus reports IsLogging true, StartLogging returns success because it is already recording, and StopLogging is refused because the platform audit log cannot be switched off. On Kubernetes, GetTrailStatus reports IsLogging per your audit policy, StartLogging returns success recording per policy, and StopLogging maps to managing the audit policy on the cluster.

The trail-config calls map onto the native audit log; logging control differs by whether the native log is always-on (refuse StopLogging) or policy-gated (StopLogging is your audit policy to manage).

​
Limitations

The list below is the whole go/no-go picture for CloudTrail. Control-plane audit coverage is faithful: the native log records every management API call. The differences are the LookupEvents query surface, data-event granularity, StopLogging on the always-on clouds, CloudTrail Insights, log-file integrity, and the absence of a historical backlog. Every one is behavioral and named here rather than discovered later. △ Where CloudTrail and the target’s native audit log diverge, read before you adopt
  • The LookupEvents query surface is a subset: a LookupEvents call is queried against the native audit log (Cloud Logging filters / the OCI Audit query / the cluster’s audit backend), so you filter with the native log’s query language rather than CloudTrail’s full LookupAttributes, and the event body is the native audit entry mapped to a CloudTrail record.
  • Data-event granularity differs. CloudTrail’s per-resource-ARN selectors map onto per-service-and-type Data Access audit logs on Google Cloud (google_project_iam_audit_config), OCI Logging service logs on OCI, and audit-policy verb/resource rules on Kubernetes; the common intent maps but the per-object granularity does not translate one-for-one, and on Kubernetes per-object data events have no direct analog.
  • StopLogging is out of scope on the always-on clouds. Google Cloud Audit Logs (Admin Activity) and OCI Audit cannot be turned off, so StopLogging is refused rather than silently dropping coverage. On Kubernetes it is Partial: it maps to disabling the kube-apiserver audit policy, which stays the target cluster configuration to manage.
  • No CloudTrail Insights analog. PutInsightSelectors / GetInsightSelectors anomaly detection has no native audit-log equivalent and is out of scope; use the target cloud’s own log-based alerting over the native audit log.
  • No digest-file integrity chain. CloudTrail’s enable_log_file_validation SHA-256 digest-file chain (and ListPublicKeys) is CloudTrail-specific; the native audit log has its own tamper-evidence: Cloud Logging’s retention locks, OCI Audit’s managed tamper-resistant retention, or whatever the Kubernetes audit backend’s log store provides.
  • No historical backlog migration: the native audit log is already recording your control-plane activity on this cloud from before cutover; your existing AWS trail history stays in its S3 bucket on AWS, and new events are recorded to the native log going forward. Moving existing CloudTrail history is a separate export/import.

​
Other considerations

Beyond the query-surface and data-event boundaries above, a few facts shape how CloudTrail behaves as a declared edge: nothing runs at request time, the platform already audits itself, and coverage, retention, and cost are the native audit log’s.
  • Nothing is provisioned or called at runtime; the platform already audits itself: unlike the request-time edges, the trail is recorded natively, so your aws_cloudtrail declaration maps onto the existing audit log rather than standing up a cross-cloud trail or a runtime API to call.
  • Coverage is always-on on two clouds and policy-gated on the third. Google Cloud Admin Activity and OCI Audit cannot be turned off (so StopLogging is refused); the Kubernetes API-server audit is recorded only while your audit policy is in effect, so on Kubernetes you own turning audit on and keeping it on.
  • The native log holds the events, with its own retention and tamper-evidence: history lives in Cloud Logging, the OCI Audit stream, or the Kubernetes audit backend, each with its own retention and integrity controls in place of CloudTrail’s digest-file chain.
  • Existing AWS trail history stays on AWS: the native log records this cloud’s activity from cutover forward; your prior CloudTrail history remains in its S3 bucket on AWS, and moving it is a separate export/import.
  • Cost follows the native audit log: management-event auditing is generally included (Admin Activity, OCI Audit), while data-access logging and the Kubernetes audit backend’s log store bill under the target cloud’s own model rather than a CloudTrail per-event charge.
Service Catalog.