6.3 CloudWatch, CloudTrail, and AWS Config

AWS Solutions Architect Associate SAA-C03

Track your progress as you read

Finished sections get a check mark.

1 Introduction

About the AWS Solutions Architect Associate (SAA-C03) Exam Study Strategies and Exam Tips for SAA-C03 The AWS Well-Architected Framework

2 Domain 1: Design Secure Architectures (30%)

1.1 IAM Fundamentals — Users, Groups, Roles, and Policies 1.2 AWS Organizations, SCPs, and Multi-Account Strategy 1.3 VPC Security — Security Groups, NACLs, and VPC Endpoints 1.4 Encryption, KMS, and Secrets Management 1.5 AWS WAF, Shield, and Network Firewall 1.6 GuardDuty, Inspector, Macie, and Security Hub 1.7 The Shared Responsibility Model for Solutions Architects 1.8 Data Protection, Compliance, and Audit Services

3 Domain 2: Design Resilient Architectures (26%)

2.1 Elastic Load Balancing (ELB) — ALB, NLB, and GWLB 2.2 EC2 Auto Scaling — Dynamic, Predictive, and Scheduled 2.3 Multi-AZ and Multi-Region Architectures 2.4 Disaster Recovery Strategies — RTO and RPO 2.5 Decoupling with SQS, SNS, and EventBridge 2.6 AWS Step Functions and Workflow Orchestration

4 Domain 3: Design High-Performing Architectures (24%)

3.1 EC2 Instance Types, Purchasing Options, and Placement Groups 3.2 Lambda, Serverless Compute, and Container Services 3.3 Amazon S3 - Storage Classes, Lifecycle, and Performance 3.4 Block and File Storage - EBS, EFS, and FSx 3.5 Database Services - RDS, Aurora, DynamoDB, and More 3.6 CloudFront, Route 53, and Global Accelerator 3.7 Data Ingestion and Transformation - Kinesis, Glue, and EMR

5 Domain 4: Design Cost-Optimized Architectures (20%)

4.1 Compute Cost Optimization — Right-Sizing, RIs, Savings Plans, and Spot 4.2 Storage Cost Optimization — S3 Tiers, EBS, and Data Transfer 4.3 Database Cost Optimization 4.4 AWS Cost Management and Monitoring Tools

6 VPC and Networking Deep Dive

5.1 VPC Architecture — Subnets, Route Tables, and Gateways 5.2 VPC Connectivity — Peering, Transit Gateway, and Direct Connect 5.3 Amazon API Gateway 5.4 CloudFormation and Infrastructure as Code 5.5 AWS PrivateLink and Endpoint Services

7 Migration, Transfer, and Hybrid Services

6.1 The 7 Rs of Cloud Migration 6.2 AWS Snow Family — Snowball Edge Devices 6.3 CloudWatch, CloudTrail, and AWS Config 6.4 Amazon Cognito and Identity Federation 6.5 AWS DataSync and Transfer Family

8 Serverless Architecture and Application Services

7.1 Serverless Architecture Patterns 7.2 Advanced SQS Patterns — DLQ, Backpressure, and FIFO 7.3 Analytics Services — Athena, OpenSearch, and QuickSight 7.4 Container Orchestration — ECS, EKS, and ECR

9 Advanced Topics and Exam Scenarios

8.1 Advanced IAM — Permission Boundaries, Federation, and Cross-Account 8.2 Caching Strategies and ElastiCache Patterns 8.3 Hybrid Architecture — DNS, Storage, and Compute 8.4 SAA-C03 Scenario Practice — Putting It All Together

6.3 CloudWatch, CloudTrail, and AWS Config

Key Takeaways Explain This Topic AI

Amazon CloudWatch monitors performance metrics, collects logs, sets alarms, and triggers automated actions — it answers 'how are my resources performing?'

AWS CloudTrail records management and data API calls — it is the audit trail answering 'who did what, when, and from where?'

AWS Config records resource configuration over time and evaluates rules — it answers 'is this resource configured correctly and compliant?'

EC2 memory and disk-space utilization are NOT default CloudWatch metrics; you must install the CloudWatch agent to publish them.

CloudWatch metric statistics are retained on a tiered schedule (high-resolution data ages out faster), and alarm actions include SNS, Auto Scaling, EC2 stop/terminate/reboot/recover, and Lambda.

Last updated: June 2026

Amazon CloudWatch — Performance and Observability

Quick Answer: CloudWatch = metrics + logs + alarms ("how is it performing?"). CloudTrail = API call history ("who did what?"). AWS Config = configuration history + compliance rules ("is it configured correctly?"). The exam loves one-line scenarios that hinge on exactly which of these three answers the question.

CloudWatch ingests metrics (time-series numbers), stores logs , and fires alarms that drive automation. Knowing which metrics exist by default is a recurring exam point.

• Component What it does
• Metrics CPUUtilization, NetworkIn/Out, plus custom metrics published via the API
• Logs Centralize application and service logs into log groups/streams
• Alarms Watch a metric/expression and act when a threshold is breached
• Dashboards Visualize metrics and logs across Regions and accounts
• Logs Insights Purpose-built query language over log data
• Synthetics Canaries that probe URLs/APIs on a schedule
• Contributor Insights Identify top-N contributors to a spike
• Default vs. agent-required metrics

• Service Default metrics Requires CloudWatch agent
• EC2 CPUUtilization, NetworkIn/Out, DiskReadOps, StatusCheck Memory utilization, disk free space, swap
• RDS CPU, FreeableMemory, DatabaseConnections, IOPS (comprehensive by default)
• Lambda Invocations, Duration, Errors, Throttles Custom business metrics via SDK
• ALB RequestCount, TargetResponseTime, HTTPCode_Target_5XX (comprehensive by default)

Critical trap: A scenario says "alarm when EC2 memory exceeds 90%." Memory is NOT a default hypervisor-visible metric — install the CloudWatch agent on the instance to publish it, then alarm on the custom metric.

Alarms and automated response

An alarm has three states: OK (within threshold), ALARM (breached), and INSUFFICIENT_DATA (not enough samples). Alarm actions include sending an SNS notification, triggering Auto Scaling , performing an EC2 action (stop, terminate, reboot, recover — recover rebuilds on healthy hardware preserving the instance ID and private IP), or invoking Lambda . Metric filters turn log patterns (such as counting ERROR lines) into metrics you can alarm on, and subscription filters stream logs in real time to Lambda, Kinesis, or OpenSearch.

• CloudTrail and AWS Config — Audit and Compliance
• AWS CloudTrail (the audit log)

CloudTrail records each API call with the identity (IAM principal), action , timestamp , source IP , and request/response details. By default, management events are viewable for 90 days in Event history at no cost; to retain longer or analyze, create a trail that delivers logs to S3.

• Event type Examples Notes
• Management events RunInstances, DeleteBucket, console sign-in 90-day history free; trail for long-term
• Data events S3 GetObject/PutObject, Lambda Invoke High volume; charged; off by default
• Insights events Unusual call-rate anomalies Charged; flags spikes like mass deletes

A single multi-Region trail captures every Region, and an organization trail captures all accounts in AWS Organizations. Log file integrity validation uses hashing to prove logs were not altered — vital for forensic and audit defensibility.

AWS Config (the configuration recorder)

Config continuously records resource configuration items and builds a per-resource timeline you can rewind. Config rules evaluate desired state and mark resources compliant or not; remediation can auto-fix via SSM Automation; an aggregator rolls up many accounts/Regions.

• Rule What it enforces
• encrypted-volumes All EBS volumes are encrypted
• s3-bucket-versioning-enabled Buckets have versioning on
• rds-instance-public-access-check RDS is not publicly reachable
• iam-root-access-key-check Root has no access keys
• The three pillars side by side

Dimension CloudWatch CloudTrail AWS Config

Question How is it performing? Who did what? Is it configured correctly?

• Data Metrics, logs, alarms API call records Config snapshots + history
• Typical use Alarm on CPU/memory Investigate an incident Enforce/auto-remediate compliance

On the Exam: "Who terminated the instance at 2 a.m.?" → CloudTrail. "Alert when CPU > 80%" → CloudWatch. "Continuously verify every bucket has versioning and fix violations" → AWS Config rule + SSM remediation.

How the three pillars work together

The services are complementary, and strong architectures use all three. Imagine an unexpected production outage: CloudWatch alarms first detect the symptom (latency spiked, 5XX errors climbed), CloudTrail then reveals the cause (an engineer modified a security group at 1:58 a.m.), and AWS Config shows the exact before-and-after configuration on its resource timeline and flags that the change violated a compliance rule.

A common multi-account design centralizes all three: an organization CloudTrail writes to a dedicated logging account's S3 bucket, a CloudWatch cross-account dashboard aggregates metrics, and a Config aggregator rolls up compliance — giving security teams one authoritative view.

EventBridge and automated remediation

CloudWatch Events evolved into Amazon EventBridge , which reacts to events (including CloudTrail-recorded API calls and Config rule changes) and routes them to targets like Lambda, SNS, or Step Functions. This is the glue for event-driven remediation : when Config flags a public S3 bucket, an EventBridge rule can invoke a Lambda that blocks public access automatically. Distinguish the roles on the exam — CloudWatch alarms watch numeric metric thresholds, while EventBridge rules match event patterns and content.

A "when an unauthorized API call happens, trigger a workflow" requirement is EventBridge reacting to CloudTrail, not a CloudWatch alarm. Remember also that CloudWatch Logs retention defaults to never expire until you set it, which silently grows storage cost — a frequently tested cost-optimization detail.