Activity Log Sync: Using Audit Events as a Cost Signal

Activity log sync is the process of copying cloud control-plane events, the records of API calls that create, modify, scale, start, or stop resources, into a system that analyses cost. Utilization metrics describe how busy a resource is; activity events describe what has been done to it and by whom. A database at 2% CPU that was resized last week is a different case from one at 2% CPU that nobody has touched in months.

Where the events come from

Each provider keeps a control-plane log, with its own defaults:

• AWS CloudTrail keeps 90 days of management events in event history; longer records need a trail or an event data store.
• Google Cloud Audit Logs always write Admin Activity logs; Data Access logs are off by default except for BigQuery.
• Azure Activity Log records control-plane operations and keeps them for 90 days.

Kubernetes adds a second layer, because workload changes happen inside the cluster API rather than the cloud API. On Amazon EKS, control plane logs, including the Kubernetes audit log, are not sent to CloudWatch Logs by default; each log type must be enabled, and CloudWatch ingestion and storage charges apply.

What ZopNight syncs

ZopNight pulls activity events from CloudTrail, GCP Cloud Logging, and Azure Activity Log into its own store, so both the recommendation engine and the UI can see what a resource has been doing. For Kubernetes, EKS audit logs and Azure Activity Log events for AKS objects feed the same store, and GKE arrives through Cloud Logging, so workload rules see real control-plane events such as scale, patch, update, and apply rather than only pod metrics. The sync runs as a daily job.

In the product, the events appear as a Recent Activity tab inside the evidence section of a recommendation, and as a chart card in the metrics view.

What the signal is used for

• Recommendations. Rules read per-period activity totals alongside metrics, so a finding is based on behaviour as well as load.
• Commitment advice. Measured uptime for commitment recommendations comes from activity-derived VM uptime; where uptime is not measured, the savings are reported as unknown rather than assumed.
• Event readiness. The readiness calculator combines current capacity, autoscaler posture, and recent activity-log signal.
• Ownership. The caller recorded on each event is how ZopNight works out who created and last changed a resource; see resource ownership detection.

Practical notes

• If Kubernetes workload recommendations look thin for EKS, check whether the cluster’s audit log type is enabled; without it there are no in-cluster events to read.
• Activity is only as complete as the provider’s retention. An account connected today brings, at most, what the provider still holds.
• ZopNight does not currently show a per-account health status for activity ingest, as it does for billing sync, so a stalled source is not flagged for you. If a resource’s activity tab is unexpectedly empty, check the provider-side logging configuration first.

Related: audit trails for cloud changes and the idle resource problem.