AWS CloudWatch Console-Only Lab Guide

Uncategorized
Posted on | by Rajesh Kumar

This lab is designed for students who have AWS Console access only. No AWS CLI, no SDK, no terminal, no kubectl, no external tools, and no code changes are required.

The goal is to let students experience CloudWatch in this learning flow:

Collect / discover telemetry → Explore and analyze → Create alarm → Build a basic dashboard

CloudWatch is AWS’s observability service for metrics, logs, alarms, dashboards, application monitoring, infrastructure monitoring, network monitoring, and cross-account visibility. AWS documentation describes CloudWatch as covering metrics, logs, application performance monitoring, infrastructure monitoring, network monitoring, and dashboards. (AWS Documentation)

Part 1: Explain the CloudWatch Left-Side Menu from the Screenshot

Before starting the lab, explain the left navigation panel to students. This helps them understand what each CloudWatch area is used for.

1. Ingestion

Dashboards

This is where users create visual dashboards for metrics and operational views.

Students will use this later to build a simple dashboard with EC2, RDS, and EKS-related metrics. CloudWatch dashboards are meant to provide a common view of critical resource and application measurements. (AWS Documentation)

Alarms

Alarms watch CloudWatch metrics and notify users when a threshold is crossed.

Example:

EC2 CPU utilization is greater than 80% for 5 minutes.

Students will create a basic metric alarm later in the lab.

2. AI Operations

Overview

This section is for AI-assisted operations and incident investigation experiences in CloudWatch. It helps teams understand operational issues faster when supported telemetry exists.

Investigations

Used for guided investigation of operational problems. This is useful in mature environments but not required for a beginner lab.

Configuration

Used to configure AI operations features. For this basic lab, students should only observe this section, not configure it.

3. GenAI Observability

Model Invocations

Used for observing generative AI model usage, such as Amazon Bedrock-related telemetry, where configured.

Bedrock AgentCore

Used for observability around Bedrock AgentCore workloads. This is not needed unless the AWS account is running Bedrock agent workloads.

For this lab, students should only understand that this section is for GenAI-related observability, not general EC2/RDS/EKS monitoring.

4. Application Signals / APM

This section focuses on application performance monitoring.

Services

Shows discovered services and service health when Application Signals is configured.

Application Map

Shows the relationship between application services and dependencies.

Transaction Search

Helps search and analyze application transactions if transaction telemetry is available.

Service Level Objectives / SLO

Used to define reliability goals such as:

99.9% of requests should complete successfully.

Synthetics Canaries

Used to simulate user journeys, such as checking whether a login page or API endpoint is working.

RUM

Real User Monitoring captures browser-side performance and user experience data from actual users.

Traces

Used to inspect distributed traces across application services.

Trace Map

Shows service relationships based on trace data.

Application Insights

Helps monitor applications and detect problems based on configured resources.

For a beginner lab, students should mainly observe this section unless Application Signals, Synthetics, RUM, or traces are already configured. AWS documents CloudWatch APM areas including Application Signals, SLOs, Transaction Search, Synthetics, and RUM. (AWS Documentation)

5. Infrastructure Monitoring

Container Insights

Used for ECS, EKS, and Kubernetes container monitoring. It can show cluster, node, pod, and container-level metrics when enabled.

Database Insights

Used for RDS and Aurora database performance monitoring.

Lambda Insights

Used for Lambda function monitoring.

EC2 Resource Health

Used to understand EC2 resource-level health.

This section is highly relevant for your students because the account has services such as EC2, RDS, and EKS.

6. Logs

Log Management

Used to view and manage CloudWatch log groups.

Log Analytics

A newer analytics experience for logs. In the screenshot it is marked as Preview.

Log Anomalies

Helps detect unusual patterns in logs.

Live Tail

Lets users watch logs as they are arriving.

Logs Insights

Lets users query log data using CloudWatch Logs Insights query language. Logs Insights is useful for finding errors, counting events, and analyzing application activity. (AWS Documentation)

Contributor Insights

Helps identify top contributors to operational behavior, such as top IP addresses, error sources, or request patterns.

7. Metrics

All Metrics

The main place to view AWS service metrics.

Examples:

  • EC2 CPU utilization
  • RDS CPU utilization
  • RDS database connections
  • EKS-related metrics if enabled
  • Load balancer request count
  • Lambda errors

Explorer

A higher-level way to explore metrics by resource tags and properties.

Streams

Used to stream CloudWatch metrics to another destination. This is more advanced and not needed for this lab.

CloudWatch metrics are time-series data, and CloudWatch supports graphing metrics, Metrics Insights, anomaly detection, metric math, and OpenTelemetry metrics. (AWS Documentation)

8. Network Monitoring

Flow Monitors

Used for monitoring network flows where supported.

Internet Monitors

Used for monitoring internet-facing application performance and availability.

Synthetic Monitors

Used for simulated monitoring of endpoints or user journeys.

For this beginner lab, students can observe this section but do not need to configure it.

9. Setup

Getting Started

A guided starting point for CloudWatch.

What’s New

Shows recent CloudWatch updates.

Settings

Used for account-level CloudWatch settings.

Part 2: Lab Assumptions and Rules

Lab Conditions

The students have:

  • AWS Console access only
  • New AWS accounts
  • Existing services such as EC2, RDS, EKS
  • No CLI access
  • No terminal access
  • No kubectl access
  • No application code access
  • No external observability tool access

Important Instructor Note

Because students have console-only access, they can observe a lot of AWS service metrics immediately, but some telemetry requires prior setup.

Telemetry TypeCan Students See It with Console Only?Notes
EC2 CPU/network metricsYesAvailable from AWS service metrics
EC2 memory/disk metricsOnly if CloudWatch Agent is already installedCannot install agent without instance-level access
RDS CPU/storage/connectionsYesAvailable from AWS service metrics
RDS database logsOnly if log exports are enabledCan sometimes be enabled from RDS console
EKS cluster metricsPartiallyMore useful if Container Insights is enabled
EKS pod/container metricsOnly if Container Insights is enabledOtherwise limited visibility
Lambda logsYes, if Lambda functions existLambda automatically sends logs to CloudWatch Logs
Application tracesOnly if tracing/Application Signals is configuredNot available by default
RUM dataOnly if RUM is configured in applicationNot available by default
Synthetics dataOnly if canaries existCreating canaries may create cost

For this lab, the safest beginner path is:

Use already available AWS service metrics first, then explore logs if they exist, then create one basic alarm, then create one basic dashboard.

Part 3: Lab Learning Objectives

By the end of this lab, students should be able to:

  1. Navigate the CloudWatch console.
  2. Understand the difference between metrics, logs, alarms, dashboards, and insights.
  3. Locate EC2, RDS, and EKS-related telemetry.
  4. Explore CloudWatch metrics.
  5. Explore CloudWatch log groups.
  6. Run basic Logs Insights queries if logs exist.
  7. Create a simple CloudWatch alarm.
  8. Create a basic CloudWatch dashboard.
  9. Understand CloudWatch limitations when only console access is available.

Part 4: Recommended Lab Flow

Lab Flow Summary

StageActivityOutcome
1Open CloudWatch and explore navigationStudents understand the CloudWatch UX
2Discover available metricsStudents find EC2, RDS, and EKS metrics
3Explore automatic dashboardsStudents understand built-in AWS views
4Explore logsStudents identify log groups and log streams
5Analyze logs with Logs InsightsStudents run simple queries
6Explore Infrastructure MonitoringStudents check EC2, RDS, EKS views
7Create a basic alarmStudents configure alerting
8Create a basic dashboardStudents build a simple observability view
9Review limitationsStudents understand what requires deeper setup

Part 5: Step-by-Step Lab Guide

Lab 1: Open CloudWatch and Understand the Console

Goal

Become familiar with the CloudWatch console layout.

Steps

  1. Sign in to the AWS Console.
  2. In the top search bar, search for CloudWatch.
  3. Open CloudWatch.
  4. Look at the left-side navigation panel.
  5. Identify these sections:
    • Dashboards
    • Alarms
    • Application Signals / APM
    • Infrastructure Monitoring
    • Logs
    • Metrics
    • Network Monitoring
    • Setup

Student Observation

Ask students:

  • Which CloudWatch section would you use for metrics?
  • Which section would you use for logs?
  • Which section would you use to create alerts?
  • Which section would you use to create a visual monitoring page?

Expected Answer

RequirementCloudWatch Section
View CPU, memory, database metricsMetrics
View log groups and log eventsLogs
Create notifications on problemsAlarms
Build visual pagesDashboards
View EKS/container healthInfrastructure Monitoring → Container Insights
View RDS database performanceInfrastructure Monitoring → Database Insights

Lab 2: Explore Automatic CloudWatch Dashboards

Goal

Let students see what CloudWatch already provides without creating anything.

Steps

  1. In CloudWatch, go to Dashboards.
  2. Look for any existing dashboards.
  3. If no custom dashboards exist, return to the CloudWatch home or overview area.
  4. Look for automatic AWS service views or widgets.
  5. Ask students to identify visible AWS services, such as:
    • EC2
    • RDS
    • EKS
    • Lambda
    • Load Balancers
    • SQS
    • DynamoDB

What to Explain

CloudWatch can show automatic dashboards and service-level views based on AWS resources in the account. These are useful for initial exploration because they require little or no setup. AWS recommends using automatic dashboards to get started with service-level monitoring. (AWS Documentation)

Student Task

Ask students to write down:

  • Which AWS services are visible?
  • Which services have metrics?
  • Which services show no data?
  • Which region are they viewing?

Important Teaching Point

CloudWatch data is regional. If students do not see metrics, they may be in the wrong AWS Region.

Lab 3: Explore EC2 Metrics

Goal

Find and graph EC2 metrics using only the console.

Steps

  1. In the CloudWatch left menu, go to Metrics.
  2. Click All metrics.
  3. Look for EC2.
  4. Open EC2 metrics.
  5. Choose a metric category such as:
    • Per-Instance Metrics
    • InstanceId
    • Auto Scaling Group metrics, if available
  6. Select an EC2 instance.
  7. Select CPUUtilization.
  8. View the graph.
  9. Change the time range:
    • 1 hour
    • 3 hours
    • 12 hours
    • 1 day
  10. Change the statistic:
  • Average
  • Maximum
  • Minimum
  1. Change the period:
  • 1 minute
  • 5 minutes
  • 15 minutes

Student Observation

Ask students:

  • Which EC2 instance has the highest CPU?
  • Does the metric show spikes?
  • Does CPU look stable?
  • What changes when the time range changes?
  • What changes when the statistic changes from Average to Maximum?

Teaching Point

EC2 metrics such as CPU and network are available by default, but memory and disk usage usually require the CloudWatch Agent. With console-only access, students may not be able to collect memory and disk metrics unless the agent is already installed.

Lab 4: Explore RDS Metrics

Goal

Find RDS database metrics and understand database health.

Steps

  1. In CloudWatch, go to Metrics.
  2. Click All metrics.
  3. Search for or choose RDS.
  4. Select database-level metrics.
  5. Choose an RDS database instance.
  6. Select these metrics if available:
    • CPUUtilization
    • DatabaseConnections
    • FreeStorageSpace
    • FreeableMemory
    • ReadIOPS
    • WriteIOPS
    • ReadLatency
    • WriteLatency
  7. Graph at least three metrics.

Student Observation

Ask students:

  • Is the database busy?
  • Are connections increasing?
  • Is free storage decreasing?
  • Is CPU stable or spiking?
  • Is read/write latency high?

Teaching Point

RDS metrics help identify whether a database may be a bottleneck. For example:

SymptomPossible Meaning
High CPUHeavy queries or insufficient instance size
High connectionsConnection pooling issue or traffic increase
Low free storageStorage capacity risk
High latencyDisk, query, or load issue
High IOPSHeavy read/write workload

Lab 5: Explore EKS and Container Metrics

Goal

Introduce students to container observability.

Steps

  1. In CloudWatch, go to Infrastructure Monitoring.
  2. Click Container Insights.
  3. Check whether EKS clusters are visible.
  4. If clusters are visible, explore:
    • Cluster view
    • Node view
    • Pod view
    • Service view
    • Namespace view
  5. Look for metrics such as:
    • CPU utilization
    • Memory utilization
    • Pod count
    • Container restarts
    • Node health

If No Data Appears

Explain:

Container-level visibility usually requires Container Insights to be enabled. If it is not enabled, students may only see limited EKS-related metrics.

Do not ask students to use kubectl or CLI.

Optional Console-Only Instructor Activity

If permissions allow and the instructor wants students to enable more EKS telemetry:

  1. Go to the EKS console.
  2. Open the EKS cluster.
  3. Look for observability, logging, or add-on options.
  4. Enable available CloudWatch or Container Insights options only if approved by the instructor.
  5. Return to CloudWatch → Infrastructure Monitoring → Container Insights.

Teaching Point

EKS has multiple telemetry layers:

LayerExample Telemetry
ClusterCluster health, API server activity
NodeCPU, memory, disk, network
PodCPU, memory, restart count
ContainerResource usage and logs
ApplicationLogs, traces, custom metrics

With console-only access, students can observe what is already configured, but they may not be able to fully instrument applications.

Lab 6: Explore CloudWatch Logs

Goal

Find available logs and understand log groups.

Steps

  1. In CloudWatch, go to Logs.
  2. Click Log Management or Log groups.
  3. Review the list of log groups.
  4. Look for log groups related to:
    • Lambda
    • RDS
    • EKS
    • ECS
    • API Gateway
    • VPC Flow Logs
    • CloudTrail
    • Application logs
  5. Click one log group.
  6. Open a log stream.
  7. Review log events.

Student Observation

Ask students:

  • What log groups exist?
  • Which service created each log group?
  • Are logs recent?
  • Are logs structured or plain text?
  • Do logs contain errors?
  • Can you identify timestamps?

Teaching Point

CloudWatch Logs stores logs in:

ConceptMeaning
Log groupCollection of related logs
Log streamStream of events from a specific source
Log eventIndividual log line or event

CloudWatch Logs is used to monitor, store, and access logs from EC2, CloudTrail, and other sources. (AWS Documentation)

Lab 7: Optional Console-Only RDS Log Collection

Goal

Show students how logs may be enabled from AWS Console if permissions allow.

Use This Only If Instructor Approves

This activity can modify RDS settings, so use caution.

Steps

  1. Open the RDS console.
  2. Go to Databases.
  3. Select a database instance.
  4. Check the Logs & events tab.
  5. Look for available logs.
  6. If CloudWatch log exports are not enabled:
    • Click Modify.
    • Find Log exports.
    • Select available logs, depending on engine type.
    • Examples may include:
      • error log
      • slow query log
      • general log
      • audit log
      • PostgreSQL log
  7. Save changes only if the instructor approves.
  8. Return to CloudWatch → Logs → Log groups.
  9. Look for new RDS log groups.

Teaching Point

RDS metrics are usually visible by default, but RDS logs may require log export configuration.

Lab 8: Optional Console-Only EKS Control Plane Log Collection

Goal

Show students how EKS control plane logs can be enabled from the console if permissions allow.

Use This Only If Instructor Approves

This may create additional CloudWatch log ingestion costs.

Steps

  1. Open the EKS console.
  2. Go to Clusters.
  3. Select the EKS cluster.
  4. Find the Logging or Observability section.
  5. Review available control plane log types:
    • API server
    • Audit
    • Authenticator
    • Controller manager
    • Scheduler
  6. Enable one or two log types only if approved.
  7. Wait a few minutes.
  8. Return to CloudWatch → Logs → Log groups.
  9. Look for EKS-related log groups.

Teaching Point

EKS control plane logs are different from pod/application logs.

Log TypeMeaning
Control plane logsKubernetes API/control plane activity
Pod logsApplication/container logs
Node logsWorker node/system logs

With console-only access, students can enable or inspect some control plane logs, but full pod-level log collection may require Container Insights or agents.

Lab 9: Analyze Logs with Logs Insights

Goal

Run basic log queries from the console.

Steps

  1. In CloudWatch, go to Logs.
  2. Click Logs Insights.
  3. Select one log group with recent data.
  4. Choose a time range, such as Last 1 hour or Last 3 hours.
  5. Run this basic query:
fields @timestamp, @message
| sort @timestamp desc
| limit 20
  1. Run an error search query:
fields @timestamp, @message
| filter @message like /error|ERROR|Exception|Failed|failed/
| sort @timestamp desc
| limit 20
  1. If logs contain structured fields, try:
fields @timestamp, level, service, message
| filter level = "ERROR"
| sort @timestamp desc
| limit 20

Student Observation

Ask students:

  • How many log events were returned?
  • Are errors visible?
  • Are logs structured?
  • Can you identify which service generated the logs?
  • Can you identify a timestamp and message?

Teaching Point

Logs Insights is useful for investigation. Metrics show that something happened; logs help explain why it happened.

Lab 10: Explore Live Tail

Goal

Show students real-time log viewing.

Steps

  1. In CloudWatch, go to Logs.
  2. Click Live Tail.
  3. Select a log group with active logs.
  4. Start Live Tail.
  5. Watch log events arrive in real time.
  6. Stop Live Tail after a short observation.

If No Logs Appear

Explain:

Live Tail only shows value when the selected log group is actively receiving events.

Teaching Point

Live Tail is helpful during active troubleshooting, deployments, and incident response.

Lab 11: Explore Log Anomalies

Goal

Introduce anomaly detection for logs.

Steps

  1. In CloudWatch, go to Logs.
  2. Click Log Anomalies.
  3. Check whether any log anomaly detectors or anomaly patterns exist.
  4. If none exist, explain the purpose rather than configuring it.

Teaching Point

Log anomalies help detect unusual log patterns. This is more useful after an environment has consistent log traffic.

Lab 12: Explore Infrastructure Monitoring

Goal

Let students experience CloudWatch infrastructure-specific views.

Steps

  1. Go to Infrastructure Monitoring.
  2. Open EC2 Resource Health.
  3. Observe available EC2 resources and health information.
  4. Open Database Insights.
  5. Look for RDS or Aurora database views.
  6. Open Container Insights.
  7. Look for EKS or ECS data.
  8. If Lambda exists, open Lambda Insights.

Student Observation

Ask students to complete this table:

AreaData Visible?Useful Metric Seen
EC2 Resource HealthYes/No
Database InsightsYes/No
Container InsightsYes/No
Lambda InsightsYes/No

Teaching Point

Infrastructure Monitoring provides a more guided experience than raw metrics, but it depends on which services and telemetry are enabled.

Lab 13: Explore Application Signals / APM

Goal

Show students where application-level observability appears.

Steps

  1. Go to Application Signals / APM.
  2. Open Services.
  3. Check whether any services appear.
  4. Open Application Map.
  5. Check whether a service map is visible.
  6. Open SLO.
  7. Check whether any service level objectives exist.
  8. Open Traces.
  9. Check whether trace data exists.

If No Data Appears

Explain:

Application Signals and traces usually require application instrumentation, CloudWatch Agent, OpenTelemetry, or supported automatic instrumentation. In a new AWS account, this section may be empty.

Application Signals can correlate service operation metrics with traces, Container Insights, and application logs when configured. (AWS Documentation)

Teaching Point

Metrics and logs are often available before APM. APM requires deeper application observability setup.

Lab 14: Create a Basic EC2 CPU Alarm

Goal

Create a simple CloudWatch alarm using only the console.

Recommended Alarm

Create an alarm for EC2 CPU utilization.

Steps

  1. In CloudWatch, go to Alarms.
  2. Click Create alarm.
  3. Click Select metric.
  4. Choose EC2.
  5. Choose Per-Instance Metrics.
  6. Select one EC2 instance.
  7. Choose CPUUtilization.
  8. Click Select metric.
  9. Configure:
    • Statistic: Average
    • Period: 5 minutes
  10. Set condition:
  • Threshold type: Static
  • Whenever CPUUtilization is Greater than
  • Threshold value: 80
  1. Click Next.
  2. For notification:
  • If SNS topic already exists, select it.
  • If allowed, create a new SNS topic from the console.
  • Add an email address only if instructor approves.
  1. Click Next.
  2. Name the alarm:
Lab-EC2-High-CPU-Alarm
  1. Add a description:
Triggers when average EC2 CPU utilization is greater than 80% for one evaluation period.
  1. Preview and create the alarm.

CloudWatch metric alarms watch a metric or metric math expression and perform actions when the value crosses a threshold for configured periods. (AWS Documentation)

Student Observation

Ask students:

  • What metric did you use?
  • What threshold did you set?
  • What period did you set?
  • What happens if the condition is not met?
  • What is the difference between OK, ALARM, and INSUFFICIENT_DATA?

Teaching Point

CloudWatch alarm states:

StateMeaning
OKMetric is within acceptable condition
ALARMThreshold condition is breached
INSUFFICIENT_DATACloudWatch does not have enough data

Lab 15: Create a Basic RDS Alarm

Goal

Create a database-related alarm.

Recommended Alarm Options

Use one of these:

AlarmMetricSuggested Threshold
High RDS CPUCPUUtilizationGreater than 80%
High DB connectionsDatabaseConnectionsDepends on DB size
Low storageFreeStorageSpaceLess than instructor-defined value

Steps

  1. Go to CloudWatch → Alarms.
  2. Click Create alarm.
  3. Click Select metric.
  4. Choose RDS.
  5. Select the database instance.
  6. Choose CPUUtilization or another instructor-approved metric.
  7. Click Select metric.
  8. Configure:
    • Statistic: Average
    • Period: 5 minutes
  9. Set threshold:
    • CPUUtilization greater than 80
  10. Click Next.
  11. Configure notification if approved.
  12. Name the alarm:
Lab-RDS-High-CPU-Alarm
  1. Create the alarm.

Teaching Point

RDS alarms are useful because database issues can directly impact application performance.

Lab 16: Create a Basic Dashboard

Goal

Create a simple CloudWatch dashboard for EC2, RDS, and EKS-related metrics.

Steps

  1. In CloudWatch, go to Dashboards.
  2. Click Create dashboard.
  3. Name it:
Lab-Basic-Observability-Dashboard
  1. Click Create dashboard.
  2. Add a widget.
  3. Select Line.
  4. Add EC2 metric:
    • EC2 → Per-Instance Metrics → CPUUtilization
  5. Save widget.
  6. Add another widget.
  7. Select Line.
  8. Add RDS metrics:
  • CPUUtilization
  • DatabaseConnections
  • FreeStorageSpace
  1. Save widget.
  2. Add another widget.
  3. If EKS/Container Insights metrics are available, add:
  • Cluster CPU
  • Cluster memory
  • Pod count
  • Container restart count
  1. If EKS metrics are not available, add another available AWS metric instead.
  2. Save the dashboard.

Suggested Dashboard Layout

WidgetPurpose
EC2 CPU UtilizationServer compute health
RDS CPU and ConnectionsDatabase pressure
RDS Free StorageCapacity risk
EKS Cluster/Container MetricsContainer health
Alarm Status WidgetHigh-level alert view

Student Observation

Ask students:

  • Which metric is most active?
  • Which resource has the most stable usage?
  • Which metric would be useful for an alarm?
  • Which widget helps the operations team most?

Teaching Point

Dashboards are for visibility. Alarms are for action.

Lab 17: Add an Alarm Widget to the Dashboard

Goal

Show alarm state directly in the dashboard.

Steps

  1. Open the dashboard created in Lab 16.
  2. Click Add widget.
  3. Select an alarm/status widget if available.
  4. Choose the EC2 alarm created earlier.
  5. Choose the RDS alarm created earlier.
  6. Save the widget.
  7. Save the dashboard.

Teaching Point

An effective operations dashboard should show both:

  • Current metric trends
  • Current alarm state

Lab 18: Explore Metrics Explorer

Goal

Let students experience a more guided way to explore resources.

Steps

  1. In CloudWatch, go to Metrics.
  2. Click Explorer.
  3. Choose a resource type if available.
  4. Filter by available resource tags or properties.
  5. Try grouping by:
    • Instance type
    • Auto Scaling group
    • Database
    • Service
    • Tag
  6. Observe the graphs.

Teaching Point

Metrics Explorer is useful when resources are tagged well. If the account has poor tagging, the experience is less useful.

Lab 19: Explore Network Monitoring

Goal

Introduce students to network observability areas without advanced configuration.

Steps

  1. In CloudWatch, go to Network Monitoring.
  2. Open Flow monitors.
  3. Observe whether any flow monitors exist.
  4. Open Internet monitors.
  5. Observe whether any internet monitors exist.
  6. Open Synthetic monitors.
  7. Observe whether any synthetic monitors exist.

Teaching Point

Network monitoring is useful for internet-facing and network-heavy systems, but it may require additional configuration.

For this beginner lab, students only need to understand where network observability lives in CloudWatch.

Lab 20: Final Review Activity

Goal

Confirm that students understand the CloudWatch observability workflow.

Ask students to complete this table:

Observability QuestionCloudWatch Area
What is my EC2 CPU usage?Metrics
What errors appeared in application logs?Logs Insights
Is my database under pressure?RDS Metrics / Database Insights
Are containers healthy?Container Insights
When should I notify someone?Alarms
How do I create a visual health page?Dashboards
How do I monitor service-level behavior?Application Signals
How do I simulate user checks?Synthetics
How do I monitor real users?RUM
How do I inspect traces?Traces / Trace Map

Part 6: Recommended Beginner Lab Script for Tutor Delivery

You can present the lab in this order:

Opening Explanation

“Today we are going to use CloudWatch as a beginner observability platform. We will not use CLI, SDK, terminal, kubectl, or any external tool. Everything will be done using the AWS Console.”

Step 1

“First, we will explore what CloudWatch already knows about our AWS account.”

Step 2

“Then we will inspect metrics for EC2, RDS, and EKS.”

Step 3

“Next, we will inspect logs and run basic queries using Logs Insights.”

Step 4

“Then we will create a simple alarm.”

Step 5

“Finally, we will build a basic dashboard showing EC2, RDS, and EKS health.”

Part 7: Key Concepts to Explain During the Lab

Metrics

Metrics are numbers over time.

Example:

EC2 CPUUtilization = 35%

Logs

Logs are timestamped records.

Example:

2026-04-27 10:15:22 ERROR database connection timeout

Alarms

Alarms watch metrics and change state when a threshold is crossed.

Example:

CPUUtilization > 80%

Dashboards

Dashboards visualize metrics and alarms.

Example:

EC2 CPU + RDS Connections + EKS Cluster CPU

Logs Insights

Logs Insights lets students search and analyze logs.

Example:

fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 20

Part 8: What Students Can and Cannot Do with Console-Only Access

Students Can Do

  • View AWS service metrics.
  • View existing log groups.
  • Run Logs Insights queries.
  • View EC2 CPU and network metrics.
  • View RDS performance metrics.
  • View EKS or Container Insights data if already enabled.
  • Create basic alarms.
  • Create dashboards.
  • Explore Application Signals if already configured.
  • Explore Infrastructure Monitoring.
  • Explore Network Monitoring sections.

Students Usually Cannot Do

  • Install CloudWatch Agent on EC2.
  • Collect EC2 memory and disk metrics unless agent already exists.
  • Collect application traces unless application instrumentation exists.
  • Collect custom application metrics unless application already sends them.
  • View pod logs unless log collection is configured.
  • Fully enable deep EKS observability without appropriate permissions and add-ons.
  • Create meaningful RUM data without application integration.
  • Create meaningful APM views without instrumentation.

Part 9: Suggested Lab Timing

SectionTime
CloudWatch menu explanation15 minutes
Metrics exploration25 minutes
Logs exploration20 minutes
Logs Insights queries20 minutes
Infrastructure Monitoring15 minutes
Alarm creation20 minutes
Dashboard creation25 minutes
Review and Q&A20 minutes
TotalAround 2.5 hours

Part 10: Student Lab Checklist

Students should complete the following:

[ ] Opened CloudWatch console
[ ] Identified left-side navigation sections
[ ] Found EC2 metrics
[ ] Graphed EC2 CPUUtilization
[ ] Found RDS metrics
[ ] Graphed RDS CPUUtilization
[ ] Checked EKS or Container Insights
[ ] Opened CloudWatch Logs
[ ] Identified at least one log group
[ ] Ran a Logs Insights query
[ ] Created one EC2 alarm
[ ] Created one RDS alarm
[ ] Created one CloudWatch dashboard
[ ] Added EC2 metric widget
[ ] Added RDS metric widget
[ ] Added alarm widget
[ ] Explained one CloudWatch limitation

Part 11: Simple Final Exercise

Ask each student to answer:

  1. Which CloudWatch section shows metrics?
  2. Which CloudWatch section shows logs?
  3. Which CloudWatch section is used for alerting?
  4. Which metric did you use for your EC2 alarm?
  5. Which metric did you use for your RDS alarm?
  6. What is the difference between a log and a metric?
  7. Why might EC2 memory not appear in CloudWatch?
  8. Why might EKS pods not appear in Container Insights?
  9. What would you put on a production dashboard?
  10. What is one limitation of console-only observability?

Part 12: Final Tutor Summary

End the lab with this message:

“CloudWatch gives us a native AWS observability experience. In this lab, we used only the AWS Console to discover telemetry, explore metrics, inspect logs, run basic log queries, create alarms, and build a dashboard. We learned that CloudWatch can show a lot of AWS service telemetry by default, but deeper observability such as memory metrics, pod logs, traces, Application Signals, and RUM usually requires additional setup. For a beginner AWS operations team, the best starting point is metrics, logs, alarms, and dashboards. Once that foundation is stable, teams can move toward deeper observability with Container Insights, Database Insights, Application Signals, traces, SLOs, and synthetic monitoring.”