Cloud Monitoring

1. Amazon CloudWatch Metrics

CloudWatch provides metrics for every service in AWS. A metric is a variable to monitor — CPUUtilization, NetworkIn, and so on. Metrics have timestamps, and you can assemble them into CloudWatch dashboards.

The deck shows a billing metric graphed on a dashboard as its worked example.

Important metrics

The slides call out the metrics most likely to appear in a question:

Resource	Metrics
EC2 instances	CPU Utilization, Status Checks, Network — not RAM
EBS volumes	Disk Read/Writes
S3 buckets	BucketSizeBytes, NumberOfObjects, AllRequests
Billing	Total Estimated Charge — only in us-east-1
Service Limits	How much you have been using a service API
Custom metrics	Push your own metrics

For EC2, default metrics come every 5 minutes. There is an option for Detailed Monitoring ($$$): metrics every 1 minute.

Exam tip

Two facts get tested almost verbatim. RAM is not an EC2 metric out of the box — memory needs a custom metric. And the billing metric only exists in us-east-1, so a billing alarm has to be created there.

2. Amazon CloudWatch Alarms

Alarms are used to trigger notifications for any metric. The alarm actions the deck lists:

• Auto Scaling — increase or decrease the EC2 “desired” instance count.
• EC2 Actions — stop, terminate, reboot or recover an EC2 instance.
• SNS notifications — send a notification into an SNS topic.

There are various options (sampling, %, max, min…), and you choose the period on which to evaluate an alarm.

An alarm sits in one of three alarm states: OK, INSUFFICIENT_DATA, ALARM.

Real-world example

The deck’s example is a billing alarm built on the CloudWatch Billing metric: when the Total Estimated Charge crosses your threshold, the alarm fires and publishes to an SNS topic that emails you.

3. Amazon CloudWatch Logs

CloudWatch Logs can collect logs from:

• Elastic Beanstalk — collection of logs from the application.
• ECS — collection from containers.
• AWS Lambda — collection from function logs.
• CloudTrail, based on a filter.
• CloudWatch log agents — on EC2 machines or on-premises servers.
• Route 53 — log DNS queries.

It enables real-time monitoring of logs, with adjustable CloudWatch Logs retention.

CloudWatch Logs for EC2

• By default, no logs from your EC2 instance go to CloudWatch.
• You need to run a CloudWatch agent on the EC2 instance to push the log files you want.
• Make sure IAM permissions are correct.
• The CloudWatch log agent can be set up on-premises too.

Exam tip

“Why don’t I see my application’s logs from EC2 in CloudWatch?” — because the CloudWatch agent is not installed, or the instance’s IAM permissions are wrong. Logs are never pushed automatically from inside an instance.

4. Amazon EventBridge

Amazon EventBridge is the service formerly called CloudWatch Events. It works in two ways:

• Schedule — cron jobs, i.e. scheduled scripts.
• Event Pattern — event rules that react to a service doing something.

Rules can trigger Lambda functions, send SQS/SNS messages, and more. The slide’s two examples: an IAM Root User Sign in event routed to an SNS Topic with Email Notification, and a Schedule Every hour that triggers a script on a Lambda function.

EventBridge rules — sources and destinations

Example sources	Example destinations
EC2 Instance (e.g. Start Instance)	Compute: Lambda, AWS Batch, ECS Task
CodeBuild (e.g. failed build)	Integration: SQS, SNS, Kinesis Data Streams
S3 Event (e.g. upload object)	Orchestration: Step Functions, CodePipeline, CodeBuild
Trusted Advisor (e.g. new Finding)	Maintenance: SSM, EC2 Actions
CloudTrail (any API call)
Schedule or Cron (e.g. every 4 hours)

EventBridge also offers:

• A Schema Registry to model event schemas.
• The ability to archive events (all or filtered) sent to an event bus, indefinitely or for a set period.
• The ability to replay archived events.

Events reach EventBridge over three kinds of bus: the Default Event Bus (AWS services), the Partner Event Bus (AWS SaaS partners) and Custom Event Buses (your own custom apps).

Real-world example

Root-user sign-in alerting: an EventBridge rule matches the IAM root user sign-in event and publishes to an SNS topic, so the security team is emailed the moment someone logs in as root — an account practice that pairs with the root-user rules in Security & Compliance.

5. AWS CloudTrail

AWS CloudTrail provides governance, compliance and audit for your AWS account, and it is enabled by default.

It gives you a history of events / API calls made within your AWS account by:

• the Console
• the SDK
• the CLI
• AWS services

Other facts from the slides:

• You can put logs from CloudTrail into CloudWatch Logs or S3.
• A trail can be applied to All Regions (the default) or a single Region.
• If a resource is deleted in AWS, investigate CloudTrail first!

The diagram shows IAM Users and IAM Roles acting through SDK, CLI and Console; CloudTrail captures that activity for inspection and audit in its console, and ships it to CloudWatch Logs and an S3 bucket.

The monitoring summary also names CloudTrail Insights: automated analysis of your CloudTrail events.

Exam tip

Remember the division of labour: CloudTrail = who did what (API calls, audit), CloudWatch = how is it performing (metrics, logs, alarms). “Who deleted this resource?” is always CloudTrail.

6. AWS X-Ray

The deck sets X-Ray up by describing debugging in production, the good old way: test locally, add log statements everywhere, re-deploy in production. Log formats differ across applications and log analysis is hard. Debugging one big monolith is “easy”; debugging distributed services is “hard”, and there is no common view of your entire architecture.

AWS X-Ray provides visual analysis of our applications. Its advantages, as listed:

• Troubleshooting performance (bottlenecks).
• Understand dependencies in a microservice architecture.
• Pinpoint service issues.
• Review request behavior.
• Find errors and exceptions.
• Answer: Are we meeting time SLA? Where am I throttled?
• Identify users that are impacted.

Exam tip

X-Ray traces requests through a distributed application. If a question mentions microservices, a service map, or finding the bottleneck across several services, it is X-Ray — not CloudWatch Logs.

7. Amazon CodeGuru

Amazon CodeGuru is an ML-powered service for automated code reviews and application performance recommendations. It has two functionalities that sit at opposite ends of the delivery pipeline:

• CodeGuru Reviewer — automated code reviews for static code analysis (development).
• CodeGuru Profiler — visibility and recommendations about application performance during runtime (production).

The slide maps them onto the pipeline: Coding → Reviewer (built-in code reviews with actionable recommendations; detect and optimize the expensive lines of code pre-prod) → Build & Test → Deploy → Profiler (identify performance and cost improvements in production) → Measure.

CodeGuru Reviewer

• Identifies critical issues, security vulnerabilities and hard-to-find bugs.
• Examples: common coding best practices, resource leaks, security detection, input validation.
• Uses Machine Learning and automated reasoning.
• Built on hard-learned lessons across millions of code reviews on 1000s of open-source and Amazon repositories.
• Supports Java and Python.
• Integrates with GitHub, Bitbucket and AWS CodeCommit.

CodeGuru Profiler

• Helps understand the runtime behavior of your application — for example, identify if your application is consuming excessive CPU capacity on a logging routine.
• Identify and remove code inefficiencies.
• Improve application performance (e.g. reduce CPU utilization).
• Decrease compute costs.
• Provides a heap summary — identify which objects are using up memory.
• Anomaly Detection.
• Supports applications running on AWS or on-premises, with minimal overhead.

Real-world example

A Java service quietly burning CPU inside a logging routine: Profiler surfaces it in production with a heap summary and a recommendation, while Reviewer would have flagged the resource leak in the pull request beforehand.

8. AWS Health Dashboard

There are two dashboards, and the exam likes to make you pick between them.

Service History

• Shows all Regions, all services health.
• Shows historical information for each day.
• Has an RSS feed you can subscribe to.
• Previously called AWS Service Health Dashboard.

Your Account

• Previously called AWS Personal Health Dashboard (PHD).
• Provides alerts and remediation guidance when AWS is experiencing events that may impact you.
• Where the Service Health Dashboard displays the general status of AWS services, the Account Health Dashboard gives you a personalized view into the performance and availability of the AWS services underlying your AWS resources.
• Displays relevant, timely information to help you manage events in progress, and provides proactive notification to help you plan for scheduled activities.
• Can aggregate data from an entire AWS Organization.
• It is a global service, showing how AWS outages directly impact you and your AWS resources: alert, remediation, proactive, scheduled activities.

Exam tip

“Is AWS down in general?” → Service History. “Is this AWS event affecting my resources?” → Account Health Dashboard.

9. Section summary

• CloudWatch
  • Metrics — monitor the performance of AWS services and billing metrics.
  • Alarms — automate notification, perform an EC2 action, notify an SNS topic based on a metric.
  • Logs — collect log files from EC2 instances, servers, Lambda functions…
  • Events (or EventBridge) — react to events in AWS, or trigger a rule on a schedule.
• CloudTrail — audit API calls made within your AWS account.
• CloudTrail Insights — automated analysis of your CloudTrail events.
• X-Ray — trace requests made through your distributed applications.
• AWS Health Dashboard — status of all AWS services across all Regions.
• AWS Account Health Dashboard — AWS events that impact your infrastructure.
• Amazon CodeGuru — automated code reviews and application performance recommendations.

Quick recap

Concept	What to remember for the exam
CloudWatch Metrics	A metric is a variable to monitor, with timestamps; available for every AWS service; can be assembled into dashboards
EC2 metrics	CPU Utilization, Status Checks, Network — not RAM; 5 minutes by default, 1 minute with paid Detailed Monitoring
Other key metrics	EBS Disk Read/Writes; S3 BucketSizeBytes / NumberOfObjects / AllRequests; Billing Total Estimated Charge only in us-east-1; Service Limits; custom metrics
CloudWatch Alarms	Trigger on any metric; actions are Auto Scaling, EC2 Actions (stop/terminate/reboot/recover) and SNS; states OK, INSUFFICIENT_DATA, ALARM
CloudWatch Logs	Sources include Elastic Beanstalk, ECS, Lambda, CloudTrail, log agents on EC2/on-premises, Route 53 DNS queries; retention is adjustable
CloudWatch agent	Required on EC2 — no instance logs reach CloudWatch by default; IAM permissions must be right; works on-premises too
Amazon EventBridge	Formerly CloudWatch Events; Schedule (cron) or Event Pattern rules; schema registry, event archive and replay; default, partner and custom event buses
AWS CloudTrail	Enabled by default; history of API calls from Console, SDK, CLI and AWS services; logs to CloudWatch Logs or S3; all Regions by default; first place to look when a resource is deleted
CloudTrail Insights	Automated analysis of CloudTrail events
AWS X-Ray	Traces requests through distributed applications; bottlenecks, dependencies, errors, SLA and throttling, impacted users
CodeGuru Reviewer	Static code analysis during development; Java and Python; GitHub, Bitbucket, AWS CodeCommit
CodeGuru Profiler	Runtime performance in production; heap summary, anomaly detection, lower CPU and compute cost; AWS or on-premises
Health Dashboard – Service History	All Regions, all services, daily history, RSS feed
Health Dashboard – Your Account	Personalized impact, remediation guidance, proactive notifications, aggregates across an AWS Organization, global service