Cloud logging creates an uncomfortable tension. Security teams need enough evidence to investigate suspicious activity, while engineering and finance teams need to control ingestion, analysis, and retention costs.
The wrong way to resolve that tension is to begin with, “Which security service can we turn off?”
I begin with a different question:
Which security decisions must our evidence support, and what is the least expensive trustworthy path to that evidence?
That framing treats telemetry as a control with an operating cost—not as an unlimited archive or an arbitrary expense.
Start with the investigation questions
Before changing a trail, event selector, destination, or retention period, I write down the questions responders need to answer:
Who performed the action?
Which role, session, workload, or external identity was involved?
What resource changed?
Was the action allowed, denied, or anomalous?
From which account, Region, network path, and user agent did it originate?
What happened immediately before and after it?
Can we establish a reliable timeline?
This becomes the minimum evidence contract.
A proposal to reduce telemetry is incomplete unless it explains which questions remain answerable, which become harder, and which can no longer be answered.
Inventory the path, not merely the services
In a multi-account environment, one event can pass through several layers:
A cloud service creates the event.
A trail or service integration selects it.
A destination stores or forwards it.
A security platform ingests and normalizes it.
A retention policy moves or deletes it.
An analyst searches it during an investigation.
Cost and coverage problems often occur between these layers. Two tools may ingest the same event, or a trail may collect broad data events that nobody queries. Conversely, a dashboard may appear healthy while an upstream selector silently excludes important activity.
I therefore document the full path:
source → selector → destination → consumer → retention → investigation owner
That map makes duplication, gaps, and unclear ownership visible.
Measure before changing anything
For CloudTrail, AWS Cost Explorer can break usage down into categories such as Insights events, Lake ingestion, retention, and query data scanned. AWS also documents that enabling Insights on both a trail and an event data store produces separate analysis charges. AWS CloudTrail
Useful baseline measurements include:
Monthly volume and cost by event category
Read versus write management-event volume
Data-event volume by resource type
Insights types enabled on each trail or event data store
Duplicate destinations and downstream ingestion
Query frequency by data tier
Retention by regulatory and investigation requirement
Events actually used in recent investigations
This is deliberately a measurement step. Finding a potentially redundant trail or expensive category does not prove it is safe to remove.
Use selectors as precision controls
CloudTrail advanced event selectors can include or exclude data and network-activity events using fields such as event name, resource type, resource ARN, error code, and VPC endpoint. AWS also permits selected high-volume categories, including certain KMS and RDS Data API events, to be excluded from trails. docs.aws.amazon.com
That creates several safer optimization options:
Collect management events broadly, but scope high-volume data events to sensitive resources.
Exclude demonstrably low-value event categories only after validating their investigation impact.
Avoid analyzing the same event through multiple CloudTrail Insights configurations unless the duplication is intentional.
Route high-value security events to searchable storage while moving older evidence to a lower-cost archive.
Restrict expensive searches to relevant time ranges, accounts, Regions, and event types.
The objective is not “fewer logs.” It is a higher ratio of usable evidence to cost.
Retention needs tiers
Not all telemetry needs identical retrieval speed.
A practical model is:
Hot: Recent evidence needed for alerts and active investigations
Warm: Searchable evidence needed for longer investigations, audits, and trend analysis
Archive: Evidence retained for legal, contractual, or regulatory reasons
Delete: Data with no continuing operational or compliance purpose
Each transition needs a named owner, documented duration, access control, integrity protection, and a tested restoration process. Archived evidence is only useful if responders can retrieve it within the time an incident demands.
Apply Zero Trust to the logging system itself
Logs frequently contain identity details, resource names, network information, and portions of application activity. Centralization improves visibility, but it also creates a valuable target.
I apply least privilege to:
Who can modify trails and selectors
Who can stop logging
Who can read raw events
Which tools can decrypt archives
Who can alter retention policies
Which roles can run broad queries
How emergency access is approved and reviewed
Defense in depth also means protecting evidence with encryption, integrity validation, configuration monitoring, change alerts, and separation between administrators and investigators.
Validate every proposed reduction
For each change, I use a simple control record:
FieldRequired answerProposed changeWhat selector, destination, analysis feature, or retention rule changes?Expected valueWhich usage category should decrease?Security impactWhich detection or investigation capability could change?ValidationWhat sanitized scenario proves required evidence remains available?RollbackHow is the previous configuration restored?OwnerWho approves and reviews the result?
A sanitized validation might perform a permitted configuration change with a test role, confirm that the event reaches the expected destination, and verify that an analyst can reconstruct the actor, resource, time, and outcome.
Until that succeeds, the projected saving is only a proposal.
The operating principle
Cloud telemetry should be intentional, attributable, and testable.
Good optimization removes duplication and low-value volume while preserving the evidence required to detect, investigate, and recover. Bad optimization merely moves cost from the cloud bill to the incident-response timeline.
The most defensible question is therefore not, “How much logging can we remove?”
It is:
What is the minimum trustworthy evidence architecture that still lets us explain and contain an incident?