Turnkey AWS CloudTrail setup for audit and security

CloudTrail setup: what breaks without auditing account activity

CloudTrail is enabled by default in almost every account, and that is exactly why auditing account activity is often considered a solved problem. In reality, the Event history in the console stores only management events for the last 90 days and only for the current region.

Without export to protected storage, this history disappears irrevocably — there will be nothing to investigate an incident with a month later.

Audit gaps accumulate unnoticed. Data events for S3 and DynamoDB, calls to KMS, work with secrets, and some service calls do not appear in the log until they are enabled separately.

An account lives in multiple regions, while the audit trail is configured for one — peripheral regions remain unmonitored. CloudTrail itself does not verify the integrity of delivered records, so a fragment of the log in storage can be replaced without leaving traces.

The most costly part is the loss of traces of permission changes.

Without records of role policy edits, access key creation, and temporary session issuance, unauthorized access can be neither proven nor time-bounded: it is unclear who gained access, when, and what they managed to do.

CloudTrail records must be correlated with network logs and load balancer logs; otherwise the picture of the incident falls apart into unrelated fragments.

We explain how CloudTrail setup closes these blind spots: a unified multi-region trail with integrity validation, a separate archive account for logs, data events, and alerts for sensitive operations.

What a well-built audit provides: investigation time, downtime, failure classes

A correctly collected log answers four questions for every action: who, what, when, and from where. Until that is in place, incident investigation relies on application logs — but they do not know that someone changed access permissions, and the failure looks inexplicable.

When AWS CloudTrail is consolidated into a single contour, investigation starts not with “who is to blame,” but with a query by event.

Checking who and when granted an excessive role or opened access to the outside takes minutes instead of hours of reconstruction from messages and tickets.

Downtime is reduced not because failures have disappeared, but because the cause is found before anyone starts searching blindly.

A whole class of disputed situations also disappears: “these are not our changes,” configuration drift between environments, and shadow edits to access policies.

Events are stored in a separate repository where the retention period is defined by policy — the retrospective window covers the interval between reviews, so traces remain even if the incident surfaces later.

Readiness for an external audit here is a consequence, not a separate effort: the access and change report is assembled from the same log, without manual reconciliation.

Infrastructure observability grows as a side effect — anomalous calls stand out against the general background and reach alerts before they reach investigation.

Event collection modes: single log, multi-account, regions

The organization of event collection determines where logs are written, who has access to them, and how easy it is to prove their integrity during incident investigation.

The scheme is set when the log is created: later changes require rebuilding access policies for the repository, encryption keys, and object lifecycle rules, and events from the past period will no longer enter the new log.

In a multi-account scheme, the choice comes down to three trade-offs. A single organization trail provides an end-to-end picture and one point for connecting alerts, but turns the central account into a bottleneck for permissions and quotas.

Separate logs by business unit remove this limitation, but end-to-end incident investigation becomes a manual reconciliation of several repositories. Global services write events to only one region — this is taken into account before choosing storage regions.

We enable log file integrity validation right away — it can be disabled later, but the log will no longer guarantee record authenticity.

Implementation order: from reviewing current logs to handing over procedures

Collecting events before routing is thought through is pointless: you cannot backfill a log after the fact, and extra collection branches are expensive to clean up later. So we go from inventory to procedures — with a verifiable result at each step.

1. Review of the current state. We record which trails already exist, which regions and accounts they cover, where they write events, and how long they retain them. We list the blind spots: regions without collection, disabled event types, buckets without protection and versioning.

2. Event routing scheme. We determine what to collect centrally and what to collect selectively: management events — across all regions, data events — only for critical repositories. Two streams: an operational receiver for investigation and an archive with long-term retention.

3. Enabling collection and securing the repository. We encrypt logs with a managed key, enable file integrity validation and a lifecycle policy to transition old records to a cold storage class. Public access to the bucket is closed; deletion is allowed only under a separate role.

4. Completeness check. We run control actions and verify that they arrived in full: without gaps across regions, with correct timestamps. We also test the reverse scenario — a record cannot be deleted or replaced without detection.

5. Access procedure. We separate roles: collection administrator, read-only analyst, on-call operator. We do not grant archive deletion rights to everyday roles; sign-in is via multi-factor authentication.

6. Handover of documentation. We provide the flow diagram, access matrix, instructions for standard investigations, and the procedure for delivery failure — so the team can run the system without us.

The output is an integrity-protected log and a team that knows how to work with it.

CloudTrail setup: artifacts and access policies at the output

The customer receives not a work report but a working kit: collection configurations, access policies, and procedures by which the on-call shift acts without us. Below is what is specifically documented in the handover documents.

• Collection configuration. Which event categories are enabled — management actions, data access on critical resources, console sign-in — in which regions, and why the set is exactly this rather than “we log everything indiscriminately.”
• Storage schemes. Where the log resides, how fast search for recent weeks and the long-term archive are separated, and which lifecycle rules and deletion protection are applied.
• Access policies. Who reads the logs and through which roles, why administration and reading are separated, and how modification and deletion of traces are prevented.
• Roles for reading logs. Separate roles for the on-call operator, incident investigator, and auditor — with the minimum necessary set of permissions.
• Response procedures. Which events are considered incidents, who receives the notification, what is done in the first minutes, and who confirms closure.
• Retention periods. How long each event category is stored and what justifies the period.
• Audit documentation. Event flow map, list of control checks, and procedure for exporting evidence on request.

The kit is assembled so that an audit can be passed without us: the documentation shows where the required event is stored, who has access to it, and what has already been done for a similar incident.

Case study: auditing an account with untracked roles and access rights

The customer came with a picture typical of overgrown infrastructure: the number of accounts had grown several times over a few years, and permissions for roles were granted manually and without procedure.

It was impossible to check who expanded access and when — some logs were kept only in individual accounts, no one controlled retention periods, and any administrator could disable logging, leaving no traces of it.

At the start, three facts were recorded: the completeness of collected events was below half, there was no log integrity control, and it was impossible to reconstruct the chain of “who — when — changed what.” Any investigation of suspicious activity turned into manual log enumeration across accounts and ended with the conclusion “no data.”

What we did

We deployed AWS CloudTrail as a single organization-level trail: logging from all accounts and regions, delivery of logs to an isolated audit account to which operational teams have no access.

The retention policy was set at the repository level — transition to a cold storage class and deletion by age, protection against modification and deletion of the logs themselves.

Disabling logging, edits to retention periods, and changes to access policies were tied to alerts for the on-call shift, and log file integrity validation was moved into a separate regular check.

Separately, we built a role registry: we matched log records with actually used permissions and marked unused and excessive ones. Role auditing ceased to be a one-time project — a regular report appeared: new roles, permission expansion, access to sensitive data.

Metrics before and after

Event completeness for management operations grew from 58% to 100%. Incident investigation time decreased from two to three days to 40 minutes: the chain across all accounts is assembled with a single query.

Role auditing produced 470 records, of which 70 were unused and 34 had excessive permissions — the excess ones were revoked. The class of failures also changed: instead of “logs not found,” the investigation comes up against a specific event and its context.

What to do if some actions are already being written to the old log?

The old collection scheme is not turned off with a single switch. The standard path is parallel logging: the previous stream continues to put events into the old repository, while the new one writes the same actions to the target.

CloudTrail itself allows multiple trails at the same time, so both collections coexist for several weeks until statistics are gathered across all sources and regions.

The main difficulty of this period is event duplication. The same action appears in both logs but with different record identifiers, and simple merging produces double counting during incident investigation.

Therefore, we normalize fields at ingestion: event time, request identifier, account, and source are brought to a unified form, and matches are collapsed at load time, not in the report.

Next is completeness reconciliation. Once a day, we compare sets by event type: which management actions and data accesses the new collection sees, and which are still written only by the old one.

Zero discrepancy across all types is the only criterion that no blind spots remain during the transition.

We migrate history as a separate stream: the old archive is parsed and loaded into the target repository with a period label, so it is not mixed with new events and does not bloat the working index.

While log migration is in progress, incident search is performed across two repositories — this is described in advance in the investigation scheme so that the on-call operator does not waste time guessing.

We disable the old collection only after reconciliation, usually one source at a time, retaining the archive for the period specified by the retention policy.

This way, the transition does not leave gaps in history and does not turn into a day when it is unclear where to look for an event.

Technical concerns: event completeness, volumes, delivery delays

Before starting, the same set of questions comes up: will all services be included in the audit, what will the repository look like in a year, and how long to wait for an event before investigation.

Below are answers at the configuration level: we set up AWS CloudTrail as an audit system, not as a checkbox.

What will happen to storage volume in a year?

The scheme is designed with retention by event type, compression, and transition of old records to cold storage. Similar events are aggregated, and those needed for investigation remain hot — the registry grows with the load, but predictably.

How quickly are events available for investigation?

For regular auditing, a few minutes is enough. Where reaction to data deletion or permission changes matters, the stream is delivered almost immediately and goes into alerts, bypassing batch logging. We measure latency in a test environment before putting it into operation.

What if the receiver is unavailable?

Delivery is retried, undelivered records are retained and sent after connectivity is restored; we monitor lag so that a gap is visible in advance.

Records go to protected storage with limited modification rights and integrity validation — this is sufficient for audit requirements.

Let’s discuss your task: work plan and timeline estimate for your account

For an estimate, read-only access to the account, a list of regions and services that must be included in the trail, and compliance requirements are sufficient.

We look at how event logging is currently organized, where archives are stored, and what organizational constraints prevent combining them — this forms the work plan and timeline estimate.

• Inventory of accounts and regions: where a shared trail is needed, where a local one is sufficient, and where logs are already consolidated into a single archive.
• Delivery scheme: a separate repository for the trail, retention period, protection against deletion and modification, separation by account and business unit.
• Event set: we enable management events everywhere, data access events — selectively by service, so that volume remains manageable.
• Selection rules: incident events go into the investigation stream, while the full trail remains in the archive for audits.
• Access: a separate read-only role for auditing, restriction by external ID, and separate permissions for automation and the on-call shift.
• Verification and handover: test operations confirming that an event reached the archive, plus diagrams and instructions for those who investigate incidents.

We start with a pilot phase on one account or group: enable the trail, make sure the required events reach the repository in full and without delays, and only then roll out the scheme across the entire organization.

Describe the task and provide access to the configuration — we will return with a work plan and timeline estimate for your account.