The topic Day 3 — AWS CloudTrail Setup is currently the subject of lively discussion — readers and analysts are keeping a close eye on developments.
This is taking place in a dynamic environment: companies’ decisions and competitors’ reactions can quickly change the picture.
After securing the root account, enabling MFA, and configuring IAM access, the next critical step is visibility.
It is important to know:
If an EC2 instance gets deleted, a security group changes unexpectedly, CloudTrail helps you trace the exact action.
By the end of this setup, logs will be stored securely in S3 and the trail will capture events across all AWS regions.
This setup aligns with AWS security best practices and the AWS Well-Architected Framework.
AWS now provides a very good default setup through:
CloudTrail → Quick create
After Quick Create finishes, go to:
CloudTrail → Trails
and open the newly created trail.
Trail Logging
Logging → Enabled
This confirms CloudTrail is actively recording AWS API activity.
Multi-Region Trail
Multi-region trail → Yes
This ensures all AWS regions are covered automatically.
S3 Log Location
CloudTrail automatically created an S3 bucket for log storage.
Example:
aws-cloudtrail-logs-xxxxxxxx
This is where CloudTrail audit logs are stored.
*Organization Trail *
If you use AWS Organizations you can enable:
Apply trail to my organization
This allows centralized CloudTrail logging across multiple AWS accounts.
API Activity:
Read → Enabled
Write → Enabled
This records infrastructure-level AWS operations such as:
IAM changes,
EC2 actions,
VPC modifications,
Security Group updates,
Route table changes,
and CloudTrail configuration updates.
AWS KMS Events:
Disabled / Unchecked
This provides better visibility into encryption-related activity.
Amazon RDS Data API Events:
Disabled / Unchecked
This keeps database API activity visible in CloudTrail logs.
Data Events
Disabled
Because Data Events can generate very large amounts of logs.
Examples:
Insights Events
Disabled initially
CloudTrail Insights is an anomaly detection feature that analyzes unusual AWS API activity patterns.
Examples:
You can enable it later as infrastructure and security requirements grow.
After creating the trail, it is useful to understand the main sections inside the CloudTrail console.
As your startup infrastructure grows, these sections become increasingly important for troubleshooting, auditing, and security monitoring.
CloudTrail → Dashboard
The Dashboard provides a high-level overview of CloudTrail activity.
Here you can quickly see:
CloudTrail → Event coverage
This section shows how much of your AWS environment is covered by Events logging.
An event in CloudTrail is the record of an activity in an AWS account. This activity can be an action taken by an IAM identity, or service that is monitorable by CloudTrail. CloudTrail events provide a history of both API and non-API account activity made through the AWS Management Console, AWS SDKs, command line tools, and other AWS services.
CloudTrail log files aren’t an ordered stack trace of the public API calls, so events don’t appear in any specific order.
CloudTrail is enabled by default for your AWS account and you automatically have access to the CloudTrail event history. The event history provides a viewable, searchable, downloadable, and immutable record of the past 90 days of management events in an AWS Region.
These events capture activity made through the AWS Management Console, AWS Command Line Interface, and AWS SDKs and APIs. The event history records events in the AWS Region where the event happened. There are no CloudTrail charges for viewing the event history.
Event History is the primary troubleshooting and audit screen.
AWS CloudTrail Insights help AWS users identify and respond to unusual activity associated with API call rates and API error rates by continuously analyzing CloudTrail management and data events.
Once CloudTrail is enabled, every infrastructure action starts leaving an audit trail.
This becomes extremely useful later when you begin working with:
In the next part of this Startup Infrastructure Setup series, we will focus on Infrastructure Governance and Infrastructure as Code. The next stage will move toward building a scalable, centralized, and team-friendly cloud foundation for startup environments.
Templates let you quickly answer FAQs or store snippets for re-use.
Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment’s permalink.
For further actions, you may consider blocking this person and/or reporting abuse
Thank you to our Diamond Sponsors for supporting the DEV Community
Google AI is the official AI Model and Platform Partner of DEV
DEV Community — A space to discuss and keep up software development and manage your software career
Built on Forem — the open source software that powers DEV and other inclusive communities.
We’re a place where coders share, stay up-to-date and grow their careers.
