A production incident is the wrong time to learn that CloudTrail events are in one AWS account, Azure activity records are in another tenant, and application logs expired two weeks ago. Investigations slow down, evidence requests become manual, and teams start reconciling timestamps instead of resolving risk. Knowing how to centralize audit logs turns that fragmented trail into an operational record your security, platform, and compliance teams can use.
Centralization does not mean copying every event into the same bucket without a plan. It means creating a governed logging architecture: defined sources, consistent retention, controlled access, normalized time, protected storage, and search paths that work when pressure is high. For organizations running AWS, Azure, or both, the design must also account for account boundaries, subscriptions, regions, and the different event models of each cloud.
Start with the audit questions you need to answer
Before enabling another log export, define the questions your centralized logs must answer. This prevents a common failure mode: collecting high-volume data that nobody can search or use as evidence.
For cloud operations, the baseline questions are practical. Who changed an identity policy? Which role deleted a resource? When did a security group become publicly accessible? Was logging disabled before or after an incident? Which user or service principal accessed sensitive data? For compliance operations, add questions around evidence: Can you demonstrate that privileged actions are recorded, retained, protected, and reviewed?
Your required answers determine which sources matter, how long to retain them, and where they must be searchable. They also establish a defensible scope for standards such as SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR, and NIST 800-53. A log platform can support audit readiness, but it does not replace the control design, review process, or formal certification audit.
Build a complete cloud log inventory
A centralized logging project should begin with an inventory of event producers, not a destination. In AWS, this usually includes organization-level CloudTrail, CloudTrail data events where justified, AWS Config history, VPC Flow Logs, CloudWatch Logs, IAM and identity-provider activity, and security service findings. In Azure, it commonly includes Azure Activity Logs, Microsoft Entra ID sign-in and audit logs, resource diagnostic settings, Azure Policy events, network flow logs, and workload logs from services such as Key Vault, Storage, and AKS.
Do not treat management-plane and data-plane logs as interchangeable. Management events show configuration and control-plane activity, such as a role-policy update or resource deletion. Data events show access to the data itself, such as object reads or key usage. Data-plane logging can be expensive and voluminous, so enable it based on a documented risk decision rather than by default everywhere.
Include logs outside the public cloud control plane. CI/CD systems, infrastructure-as-code pipelines, source control, identity providers, endpoint tools, and critical SaaS services may hold the missing context behind a cloud change. A Terraform plan can explain why an API call occurred; an identity log can explain how the caller authenticated.
Design the central destination before forwarding events
The destination needs three properties: it must be hard to alter, practical to search, and economical enough to retain. Those goals often require a tiered architecture rather than a single tool.
A common pattern is to send raw logs to a dedicated security account or subscription with separate administrative boundaries from production workloads. Store the original records in immutable or write-protected storage, then forward or index the subset needed for near-real-time detection and investigation in a SIEM or analytics platform. Keep parsed and enriched data separate from the original event payload so an analyst can always verify the underlying record.
For AWS, use organization-level collection so new accounts inherit the logging baseline. For Azure, use management groups and policy initiatives to deploy required diagnostic settings across subscriptions. The mechanism matters less than the operating model: new accounts and subscriptions should not depend on an engineer remembering a manual logging checklist.
Separate the log archive from the teams that operate the workloads. If a compromised administrator can modify production resources and delete the evidence in the same trust boundary, centralization has not solved the core problem. Restrict deletion, lifecycle changes, encryption-key administration, and archive access through distinct roles, strong approval paths, and monitored break-glass procedures.
Normalize time, identity, and resource context
Raw logs from AWS and Azure are useful, but cross-cloud investigations fail quickly when fields mean different things. Normalize the context that analysts rely on most: event timestamp, ingestion timestamp, cloud provider, account or subscription, region, actor identity, source IP, action, target resource, outcome, correlation ID, and event source.
Use UTC as the canonical time zone. Preserve the original timestamp and record when the platform received the event. The difference between those values reveals delivery delays, which matter during incident reconstruction and when validating alert logic.
Identity normalization deserves special care. An AWS assumed role, an Azure managed identity, a service principal, and a human user are different actors with different attribution paths. Preserve the raw cloud identity while adding a normalized actor type and, where possible, ownership context. Avoid flattening everything into a display name. Display names change; immutable IDs and session details are often what make an investigation defensible.
Automate collection and validate continuously
Manual configuration is not centralized logging. It is an exception waiting to happen. Define collectors, diagnostic settings, storage policies, retention periods, and access controls as infrastructure-as-code. Apply them through account-vending, landing-zone, or subscription-provisioning workflows so coverage begins when a cloud boundary is created.
Then test the pipeline with controlled events. Create a temporary role change in AWS and a resource change in Azure. Confirm that each action reaches the central archive, arrives in the searchable destination, preserves its source context, and can be queried by the expected identity and resource fields. Test alerts for disabled trails, removed diagnostic settings, failed exports, archive-policy changes, and unexpected permission changes.
This validation must run continuously because logging can drift. Teams add accounts, replace pipelines, move workloads, and change retention to manage costs. Scheduled posture scans can identify missing audit settings and over-permissive archive access before an auditor or incident exposes the gap. CGPulse can support this operating model by evaluating cloud configurations against mapped policy rules, tracking findings, and helping teams remediate governance gaps through one-click fixes or exported infrastructure-as-code templates.
Set retention based on risk, regulation, and query cost
There is no universal retention period. A startup with a limited regulated footprint may need a different policy than a healthcare platform or a company subject to contractual forensic requirements. Establish a written schedule that distinguishes between hot, searchable retention and long-term archive retention.
Keep enough data readily searchable to support your normal detection and investigation window. Archive older records in protected, lower-cost storage according to regulatory, contractual, and internal requirements. Document the rationale, legal-hold process, storage location, encryption approach, and retrieval procedure. If archived records take hours to restore, that may be acceptable for annual evidence collection but not for active incident response.
Cost controls should target noise before they target evidence. Filter duplicated debug telemetry, tune overly broad data events, and use lifecycle tiers. Do not silently shorten retention for high-value identity, administrative, and security-control logs simply because storage spending increased.
Make access auditable too
A centralized archive concentrates sensitive operational data. Logs can contain usernames, IP addresses, resource names, command parameters, and occasionally application-level content that creates privacy obligations. Apply least privilege to search, export, and administration separately.
Security analysts may need query access without permission to alter retention. Compliance managers may need evidence exports without unrestricted access to all raw events. Platform engineers may need service-health visibility without access to identity records. Log every query, export, policy change, and privileged action performed in the logging environment itself. The system that proves accountability must also be accountable.
Run periodic access reviews and test the retrieval path with the same rigor as collection. An archive that is technically retained but cannot be located, decrypted, or exported in a usable format is not reliable evidence.
Centralized logs become useful through operating routines
The final step is procedural. Assign ownership for source coverage, pipeline health, retention exceptions, access reviews, and evidence requests. Establish a cadence to review missing sources, collection failures, and privileged activity. Connect relevant findings to ticketing and incident workflows so a disabled trail or removed diagnostic setting becomes an assigned remediation task, not a dashboard statistic.
The goal is not a larger log repository. It is faster answers with trustworthy evidence: what happened, who did it, what changed, and whether the control worked. When that record is built into your AWS and Azure operating model, audit preparation stops being a scramble and becomes a byproduct of disciplined cloud governance.