Audit Logging

Audit logging supports accountability by recording security-relevant activity rather than only system health or application performance. Useful events identify the actor, action, target resource, timestamp, source context, and outcome. For cloud workloads, the actor might be a person, an assumed role, an application identity, or a managed service. Preserving role-session and identity-provider context helps investigators connect temporary credentials to the originating identity, although attribution depends on the information captured by each source.

Choose sources by starting with the questions an investigation or compliance review must answer. Control-plane API logs establish who changed permissions, created resources, or modified security settings. Data-plane audit events establish who accessed or changed supported data resources, such as objects in storage. Application audit logs capture business actions, such as approving a payment, that infrastructure logs cannot explain. Operating-system authentication logs, database audit logs, network flow logs, DNS query logs, and load balancer access logs provide complementary evidence. Network flow records describe connections, not the user actions or packet contents behind them.

For example, investigating a suspected object-storage disclosure requires more than the event that changed a bucket policy. Investigators may also need object-access events, identity activity, application records, and relevant network evidence. In AWS, CloudTrail management events and data events serve different purposes. Data events generally require explicit configuration and incur additional charges. CloudTrail Event history provides the previous 90 days of management events in each Region; it is not a complete, long-term archive of all activity.

Collection should cover the required accounts, Regions, resource types, and event categories. Organization-wide configuration and centralized storage reduce gaps caused by individually managed accounts. However, centralization alone does not guarantee completeness: selectors, unsupported event types, delivery permissions, encryption-key policies, service quotas, and configuration drift can all affect coverage. Test delivery using known actions, monitor delivery failures, and alert on attempts to disable logging or change its destinations. Do not assume logs arrive immediately or in chronological order.

Storage design follows investigation and retention requirements. Frequently searched records may belong in a searchable log platform, while an object-storage archive can provide economical long-term retention. Lifecycle policies can move older records to lower-cost storage, but retrieval delays and query compatibility must match recovery expectations. Restrict deletion and configuration changes, separate workload administration from archive administration, and use immutable retention where required. Encryption protects confidentiality, while integrity validation helps detect modification; neither substitutes for access control or deletion protection.

Audit records themselves can contain personal information, identifiers, and sensitive request details. Avoid recording credentials or unnecessary payloads, restrict analyst access, and define retention according to legal and operational requirements. More logging is not automatically better: high-volume data events increase ingestion, storage, and analysis costs. Select coverage deliberately, preserve original records alongside normalized copies, and maintain reliable timestamps for correlation. Finally, logging is not detection by itself. Queries, alerts, investigation procedures, and regular coverage tests turn retained records into useful security evidence.