Servisphere

Module 9 · SAA-C03

Monitoring, operations and infrastructure as code

CloudWatch, CloudTrail, Config, Systems Manager, CloudFormation: observability, audit trails, operations automation.

  • DomainResilient architectures
  • DomainSecure architectures
  • 11 diagrams
  • 10 scenarios
  • 11 services

5-minute essentials

  1. Three questions, three services: how is it performing → CloudWatch; who called which API → CloudTrail; how has a resource's configuration changed and does it follow the rules → AWS Config.Exams often mix these three services; read carefully whether the question needs metrics, an action log, or configuration history.
  2. EC2 sends metrics every 5 minutes by default (basic, free); enable detailed monitoring for 1-minute metrics (charged).Auto Scaling reacts faster to 1-minute metrics.
  3. EC2 does not send memory or used disk space metrics by itself: install the CloudWatch agent (it also sends logs)."Alert when RAM exceeds 80%" → CloudWatch agent + custom metric + alarm.
  4. Custom metrics can be high-resolution (1 second); alarms on these metrics can be evaluated every 10 or 30 seconds.Standard AWS metrics are 1 minute; for faster, publish high-resolution metrics yourself.
  5. A CloudWatch alarm has 3 states, OK / ALARM / INSUFFICIENT_DATA; actions: send to SNS, scaling policy, EC2 action (stop, terminate, reboot, recover), Systems Manager.To auto-recover EC2 after a hardware failure: alarm on StatusCheckFailed_System with the recover action.
  6. CloudWatch Logs keeps logs forever by default; set retention per log group to cut costs.A metric filter turns log lines into a metric (count 5xx errors…) so you can set an alarm; use Logs Insights to query.
  7. A subscription filter pushes logs in real time to Kinesis, Firehose or Lambda (then S3, OpenSearch…).Centralize logs from many accounts, or analyze logs in near real time.
  8. CloudTrail is on by default: Event history keeps 90 days of management events in each Region. To keep longer: create a trail that writes to S3 (or CloudTrail Lake).An organization trail records for all accounts; enable log file validation to detect tampered logs.
  9. Data events (S3 GetObject / PutObject, Lambda Invoke…) are not recorded by default and cost extra.Question asks "who read / deleted an object in the bucket": you must enable data events for that bucket.
  10. AWS Config records configuration history and evaluates compliance with Config rules; it supports automatic remediation through Systems Manager Automation."Detect a security group opening port 22 to 0.0.0.0/0 and fix it automatically" → Config rule + remediation.
  11. X-Ray traces a request across multiple services (service map, per-segment latency).To find slow or failing parts in microservices / serverless: X-Ray, not CloudTrail.
  12. Systems Manager: Session Manager (access instances without SSH, bastion or port 22), Patch Manager, Run Command, Parameter Store, Automation.Patch and manage EC2 / on-premises machines at scale; instances in a private subnet need SSM VPC endpoints or a NAT.
  13. CloudFormation: infrastructure as code (template → stack); StackSets deploy to multiple accounts / Regions; drift detection finds manual changes.Rebuild an identical environment in another Region (DR, multiple environments) quickly and consistently.

Diagrams

CloudWatch alarm: from metric to action

CloudWatch alarm: from metric to actionAuto Scaling group112add instances333EC2EC2MetricCPUUtilizationAlarm> 70% for 3 × 1 minScaling policySNS → emailEC2 action: recoverStatusCheckFailed_System
When a metric breaches the threshold for enough periods, the alarm moves to ALARM and runs an action: add instances, notify the team, or auto-recover an instance with a hardware fault.

Step by step

  1. EC2 sends metrics (5 minutes; enable detailed monitoring for 1 minute).
  2. The alarm compares against the threshold over several consecutive periods, avoiding false alarms from a single noisy point.
  3. On ALARM: it calls the scaling policy and sends SNS; an alarm on the system status check can recover the instance.

CloudWatch agent: OS-level metrics and application logs

CloudWatch agent: OS-level metrics and application logsEC2 / on-prem server1112222Application/var/log/app.logCloudWatch agentCustom metricmem_used_percentLog groupretention 30 daysMetric filtercounts "ERROR"AlarmSNS
The agent reads memory, disk and log files on the machine (EC2 or on-premises). A metric filter counts errors in logs so you can set an alarm; use Logs Insights to query.

Step by step

  1. The agent sends memory / disk metrics (namespace CWAgent) and pushes log files into a log group.
  2. A metric filter turns ERROR lines into a metric; an alarm on that metric or on memory notifies via SNS.

CloudTrail: organization trail to a dedicated log account

CloudTrail: organization trail to a dedicated log accountAWS Organizations112lifecycle23metric filter3Prod accountDev accountOrganization trailmgmt + data eventsS3 (Object Lock)log file validationGlacier (7 years)CloudWatch LogsAlarm: root login
One trail for all accounts and Regions. Logs go to an S3 bucket in the log account (Object Lock, validation) and to CloudWatch Logs to alert on sensitive actions.

Step by step

  1. A trail created in the management account records API calls of all member accounts.
  2. Logs go to a bucket in the log account, protected from modification / deletion; a lifecycle rule moves them to Glacier for cheap long-term retention.
  3. They are also sent to CloudWatch Logs; a metric filter catches sensitive actions (root login, IAM changes) to alert on.

AWS Config: detect misconfiguration and auto-fix

AWS Config: detect misconfiguration and auto-fix1112NON_COMPLIANT33fix3Security groupjust opened port 22S3 bucketEBS volumeConfig recorderconfig historyConfig rulerestricted-sshSSM Automationremoves 0.0.0.0/0 ruleEventBridge → SNS
The recorder records every configuration change. Config rules evaluate resources; non-compliant ones trigger remediation with Systems Manager Automation.

Step by step

  1. Every configuration change is recorded as a configuration item.
  2. The Config rule evaluates as soon as the configuration changes (or periodically).
  3. If non-compliant: remediation removes the port 22 rule automatically; an event is also sent to notify the team.

Centralize logs to S3 and OpenSearch with subscription filters

Centralize logs to S3 and OpenSearch with subscription filters111subscription filter222LambdaEC2 (agent)VPC Flow LogsLog groupsLogs InsightsFirehoseS3Athena queriesOpenSearch
A subscription filter pushes logs in near real time to Firehose; Firehose writes to S3 (long-term, Athena) and OpenSearch (search, dashboards).

Step by step

  1. Logs from Lambda, EC2 and VPC Flow Logs go into CloudWatch Logs (quick queries with Logs Insights).
  2. A subscription filter pushes logs to Firehose for low-cost S3 storage and search in OpenSearch.

X-Ray: tracing a request across services

X-Ray: tracing a request across services111slow12trace2UserAPI Gateway120 msLambda80 msDynamoDB8 msExternal API1,900 msX-Rayservice map
Each service records a segment with a trace ID; X-Ray stitches them into a service map and shows which segment is slow or failing.

Step by step

  1. The request passes through API Gateway, Lambda, then DynamoDB and an external API; the trace ID travels along the whole path.
  2. X-Ray stitches the segments: you immediately see the external API call takes almost all the time.

Systems Manager managing EC2 in a private subnet

Systems Manager managing EC2 in a private subnetVPCPrivate subnetSession Manager1222Ops engineerIAMSystems ManagerVPC endpointssm, ssmmessages, ec2messagesEC2 + SSM agentport 22 closedEC2 + SSM agent
The SSM agent connects out to the service through VPC endpoints (no NAT needed, no inbound ports). Session Manager replaces SSH and bastions; Patch Manager patches on a schedule.

Step by step

  1. The engineer opens a session from the console / CLI; access is controlled with IAM and the session is logged.
  2. The SSM agent connects out through VPC endpoints on its own; no public IP, bastion or inbound port 22 rule is needed.

CloudFormation StackSets: one template, many accounts and Regions

CloudFormation StackSets: one template, many accounts and Regionsap-southeast-1us-east-1 (DR)1222TemplateGitStackSetProd stackDev stackDR stack
The template describes the infrastructure; StackSets creates identical stacks in the target accounts / Regions. Drift detection shows which resources were changed manually.

Step by step

  1. The template in Git is the single source of truth for the infrastructure.
  2. The StackSet deploys identical stacks to multiple accounts and Regions, including the DR Region.

AWS Health: automatically react to AWS incidents and maintenance

AWS Health: automatically react to AWS incidents and maintenance122AWS Healthscheduled EC2 maintenanceEventBridge ruleSNS → on-callLambdastop / start to move host
AWS Health sends events relevant to your resources to EventBridge; rules send notifications or run automation.

Step by step

  1. AWS Health emits events (service incidents, scheduled maintenance) for your account.
  2. An EventBridge rule alerts the on-call team and runs Lambda to handle it before the maintenance window.

The three states of a CloudWatch alarm

The three states of a CloudWatch alarmdata ok, in range1data ok, breaching1M of N breaching2back in range3data missing4INSUFFICIENT_DATAnot enough dataOKwithin thresholdALARMbreach → action
A newly created alarm starts in INSUFFICIENT_DATA. Handling of missing data (TreatMissingData): missing (default), notBreaching, breaching, ignore (keep the previous state). Alarms with stop / terminate / reboot / recover EC2 actions should use missing and act only on ALARM.

Step by step

  1. A newly created alarm, or a metric with no data yet: INSUFFICIENT_DATA, then OK or ALARM once there are enough data points.
  2. M out of N: for example 3 of the last 5 periods breaching puts it in ALARM and runs the action (SNS, Auto Scaling, EC2 action).
  3. Enough periods back within the threshold returns it to OK (a notification can be sent on OK).
  4. Missing data: depends on TreatMissingData. missing → INSUFFICIENT_DATA; breaching is treated as breaching the threshold; notBreaching as normal; ignore keeps the current state.

From logs to alerts: metric filter and Logs Insights

From logs to alerts: metric filter and Logs Insightswrite logs12metric2ALARM2query3read logs3ApplicationLog groupMetric filterpattern "ERROR" → ErrorCountAlarmErrorCount > 5 / 5 minSNSEngineerLogs Insightsquery when investigating
A metric filter counts patterns in logs (for example "ERROR") into a metric so you can set an alarm; it applies only to logs arriving after the filter is created and does not count old logs retroactively. Logs Insights is for ad hoc log queries during investigation.

Step by step

  1. The application (Lambda logs automatically; EC2 uses the CloudWatch agent) pushes logs into a log group.
  2. The metric filter turns each line matching the pattern into a metric value; an alarm on that metric sends SNS when it breaches the threshold.
  3. When investigating: Logs Insights queries, filters and groups logs without having to create a metric first.

Quick comparisons

CloudWatch, CloudTrail, Config

CloudWatchCloudTrailAWS Config
AnswersHow the system is running (metrics, logs, alarms)Who did what, when, from where (API calls)How a resource is configured, how it changed, whether it is compliant
DataMetrics, logs, traces (X-Ray / Application Signals)API events (management, data, Insights)Configuration items over time
ActionsAlarm → SNS, Auto Scaling, EC2 actionDeliver logs to S3 / CloudWatch Logs; EventBridgeConfig rule → remediation (SSM Automation)
Exam exampleAdd instances when CPU exceeds 80%Who deleted the security group?Which buckets are public? Which volumes are unencrypted?

Data retention

TypeRetention
Metrics with resolution under 60 seconds3 hours
1-minute metrics15 days
5-minute metrics63 days
1-hour metrics455 days (15 months)
CloudWatch LogsNever expires by default (set your own retention)
CloudTrail Event history90 days, management events only
CloudTrail trailUp to you (logs live in your S3 bucket)

Systems Manager: choosing a feature

NeedFeature
Shell access to EC2 without opening port 22, with session logsSession Manager
Scheduled OS patching for a whole fleetPatch Manager + Maintenance Window
Run one command on hundreds of instancesRun Command
Store configuration, connection strings (can be encrypted with KMS)Parameter Store
Automated runbooks (for example Config remediation)Automation

Exam scenarios

1You need an alert when memory usage on EC2 exceeds 85%.

Show answer

Right: Install the CloudWatch agent to send mem_used_percent, set a CloudWatch alarm → SNS
Memory and used disk are OS-level metrics that only the agent can read.

Wrong: Alarm on EC2's built-in MemoryUtilization metric
EC2 has no built-in memory metric.

Wrong: Enable detailed monitoring
It only changes the period to 1 minute; there is still no memory metric.

2A security group was changed to open port 3389 to the internet; you need to know who changed it and when.

Show answer

Right: CloudTrail (AuthorizeSecurityGroupIngress in Event history or a trail)
CloudTrail records the caller, time and source IP of every API call.

Wrong: EC2 CloudWatch metrics
They do not record API actions.

Wrong: VPC Flow Logs
They record network traffic, not who changed the configuration.

3You must continuously check that no security group opens port 22 to 0.0.0.0/0, and fix violations automatically.

Show answer

Right: AWS Config managed rule (restricted-ssh) + automatic remediation with Systems Manager Automation
Config evaluates whenever the configuration changes and runs remediation for non-compliant resources.

Wrong: CloudTrail + reading logs manually every week
Not continuous, no automatic fix.

4Auditors require API logs for all accounts in the organization to be kept for 7 years, tamper-proof.

Show answer

Right: Organization trail writing to an S3 bucket in a dedicated log account, with log file validation, S3 Object Lock and a lifecycle rule to Glacier
One trail for all accounts; validation detects modification; Object Lock prevents deletion.

Wrong: Rely on CloudTrail Event history
Only 90 days, per account.

5You need to know who downloaded a sensitive file in an S3 bucket.

Show answer

Right: Enable CloudTrail data events for that bucket (or S3 server access logging)
Data events record every object read / write; charged per event.

Wrong: CloudTrail Event history
It has management events only; GetObject is a data event.

6A web app writes logs to CloudWatch Logs; you need an alarm when HTTP 500 errors exceed 50 in 5 minutes.

Show answer

Right: A metric filter on the log group counting lines containing "500", and an alarm on that metric
A metric filter turns logs into a metric so you can set an alarm.

Wrong: CloudTrail
It does not read application logs.

7A serverless app (API Gateway → Lambda → DynamoDB) is occasionally slow; you need to find which segment causes the slowness.

Show answer

Right: Enable AWS X-Ray tracing for API Gateway and Lambda
Traces show the time of each segment and a service map.

Wrong: CloudTrail
It records management API calls, not request latency.

8The operations team needs shell access to EC2 in a private subnet; the company forbids opening port 22 and does not want a bastion.

Show answer

Right: Systems Manager Session Manager (SSM agent + IAM role; VPC endpoints ssm, ssmmessages, ec2messages)
Sessions go through SSM's channel, are authorized with IAM, and session logs go to S3 / CloudWatch Logs.

Wrong: Bastion host in a public subnet
The question forbids a bastion, and port 22 would still have to be open.

9You need an identical environment in a second Region for DR, and to deploy the same security configuration to 50 accounts.

Show answer

Right: CloudFormation template; StackSets to deploy across multiple accounts / Regions
Infrastructure as code, repeatable and identical; drift detection finds manual changes.

Wrong: Build by hand following documentation
Slow and prone to drift.

10You need to automatically notify the team when AWS schedules hardware maintenance affecting your EC2 instances.

Show answer

Right: AWS Health event → EventBridge rule → SNS / Lambda
AWS Health sends events about incidents and maintenance affecting your resources.

Wrong: CloudWatch CPU metric
It knows nothing about the maintenance schedule.

Quick picks

What do you need to monitor / manage?

When you needUse
Metric-based alerts and automatic actions (scale, recover, SNS)CloudWatch alarm · see diagram
Memory, disk, application logs from EC2 / on-premisesCloudWatch agent · see diagram
Count errors in logs, then alertMetric filter + alarm · see diagram
Who called which APICloudTrail (trail / organization trail) · see diagram
Who read / wrote S3 objectsCloudTrail data events · see diagram
Configuration history, compliance checks, auto-fixAWS Config rules + remediation · see diagram
Push logs to S3 / OpenSearch in near real timeSubscription filter → Firehose · see diagram
Find the slow segment in microservicesAWS X-Ray · see diagram
Access without SSH, patching, bulk commandsSystems Manager · see diagram
Infrastructure as code, multiple accounts / RegionsCloudFormation StackSets · see diagram
Learn about AWS incidents / maintenance affecting youAWS Health + EventBridge · see diagram
Recommendations for cost savings, security, service limitsTrusted Advisor

Common pitfalls

  • Looking for a built-in EC2 memory metric: you must install the CloudWatch agent.
  • Thinking detailed monitoring adds more metrics: it only changes the 5-minute period to 1 minute.
  • Using CloudWatch to answer "who did it": that is CloudTrail.
  • Using CloudTrail to check whether configuration follows the rules: that is AWS Config.
  • Believing Event history is kept forever: it is only 90 days, management events only.
  • Forgetting to enable data events, so you cannot see who read S3 objects.
  • Keeping log groups forever, then being surprised by the log storage bill.
  • Opening port 22 and building a bastion when Session Manager does the job without either.
  • Instances in a private subnet have no SSM VPC endpoints (or NAT), so they do not show up in Systems Manager.
  • Using X-Ray to audit configuration changes, or CloudTrail to measure latency.
  • Manually modifying resources created by CloudFormation, so the stack drifts.

Services in this module

Numbers that change (checked against AWS docs)

  • CloudWatch metrics: under 60 seconds kept 3 hours; 1 minute kept 15 days; 5 minutes kept 63 days; 1 hour kept 455 days. High-resolution custom metrics are 1 second; high-resolution alarms have a 10 or 30 second period. checked 2026-10-16 ↗
  • EC2 basic monitoring: 5-minute metrics (status checks 1 minute), free; detailed monitoring: 1 minute, charged per metric. checked 2026-10-16 ↗
  • Memory (mem_used_percent) and disk (disk_used_percent) metrics are collected by the CloudWatch agent, in addition to EC2's default metrics. checked 2026-10-16 ↗
  • CloudWatch Logs stores logs indefinitely by default; retention is set per log group. checked 2026-10-16 ↗
  • CloudTrail Event history: 90 days of management events per Region, free, excludes data events. checked 2026-10-16 ↗
  • Trails and event data stores do not record data events by default; recording data events costs extra. checked 2026-10-16 ↗
  • An alarm has three states: OK, ALARM, INSUFFICIENT_DATA; INSUFFICIENT_DATA also applies right after the alarm is created. checked 2026-10-19 ↗
  • TreatMissingData: notBreaching, breaching, ignore, missing (default); EC2 alarms with stop / terminate / reboot / recover actions should use missing. checked 2026-10-19 ↗
  • A metric filter does not retroactively filter old logs: it only creates data points for logs that arrive after the filter is created. checked 2026-10-19 ↗
Practice this module →