Create Custom CloudWatch Metrics and Alarms for EC2 Memory Usage – SAP-C02 Study Guide

Purpose of This Lesson

Amazon EC2 provides standard CloudWatch metrics such as CPU utilization, network traffic, and disk activity. Memory utilization is not included as a default EC2 metric, so applications that need memory-based monitoring must collect and publish it separately.

This hands-on pattern demonstrates how to:

• Grant an EC2 instance permission to publish metrics to CloudWatch.
• Collect memory utilization with a script running on the instance.
• Publish the value as a custom CloudWatch metric.
• Schedule collection at regular intervals.
• Create a CloudWatch alarm and notify an operator through Amazon SNS.

The lab uses AWS CLI, AWS CloudShell, an EC2 instance, the Instance Metadata Service, and a scheduled Linux task.

Key Concepts

Custom CloudWatch metrics

Custom metrics are application- or infrastructure-specific measurements that AWS does not publish automatically. Examples include:

• EC2 memory utilization
• Queue depth inside a custom application
• Number of business transactions
• Request latency from a private service
• Cache hit ratio

A metric is organized using a namespace, metric name, dimensions, timestamp, value, and unit. In the lab, the conceptual structure is:

• Namespace: Custom/Memory
• Metric name: mem_usage
• Dimension: the EC2 instance ID
• Value: measured memory utilization

Dimensions are important because they allow one metric definition to contain separate time series for different instances, applications, environments, or components.

IAM permissions for metric publication

The EC2 instance needs permission to call cloudwatch:PutMetricData. A typical implementation uses:

1. An IAM policy allowing cloudwatch:PutMetricData.
2. An IAM role with that policy attached.
3. An EC2 instance profile containing the role.
4. An EC2 instance launched with the instance profile attached.

The EC2 service assumes the role through the role’s trust policy. Applications on the instance then obtain temporary credentials automatically rather than storing long-term access keys in configuration files.

The permission should be scoped as narrowly as practical. PutMetricData does not support resource-level restrictions in the same way many resource-oriented APIs do, so use other controls where appropriate, such as account boundaries, tagging strategy, organizational policies, and tightly controlled instance roles.

Instance profiles

An IAM role cannot be attached directly to an EC2 instance. The role must be placed in an instance profile, and that instance profile is associated with the instance.

This distinction frequently appears in exam questions and automation workflows:

• IAM role: identity and permissions.
• Instance profile: EC2 container for the role.
• EC2 instance: receives the instance profile at launch or through an supported association operation.

Instance Metadata Service and IMDSv2

The collection script can retrieve instance-specific information, such as the instance ID, from the EC2 Instance Metadata Service. IMDSv2 uses a session token and is preferred because it requires a token-based request flow.

The instance ID is useful as a CloudWatch dimension. Without a dimension identifying the source instance, data from multiple instances could be combined into one indistinguishable time series.

When designing production systems, configure EC2 metadata options to require IMDSv2 where compatible and protect applications from unintended metadata access.

Scheduling metric collection

The lab uses a Linux script and cron to collect and publish memory utilization once per minute. This demonstrates a simple push model:

1. Read local operating-system memory statistics.
2. Calculate the desired percentage.
3. Call PutMetricData.
4. Repeat on a schedule.

The schedule determines the metric’s effective resolution and affects how quickly an alarm can react. A one-minute schedule generally produces standard-resolution data. Higher-frequency custom metrics may be possible with high-resolution settings, but they increase cost and should be justified by the response-time requirement.

CloudWatch alarms

A CloudWatch alarm evaluates a metric against a condition over one or more evaluation periods. The lab uses a static threshold: memory utilization greater than 40 percent.

An alarm can be in states such as:

• OK: the evaluated data is within the configured condition.
• ALARM: the condition has been met according to the evaluation settings.
• INSUFFICIENT_DATA: CloudWatch does not yet have enough usable data to evaluate the condition.

The alarm configuration must be interpreted as a complete rule. Important fields include:

• Threshold type, such as static or anomaly detection.
• Comparison operator.
• Period length.
• Number of evaluation periods.
• Datapoints to alarm.
• Missing-data treatment.
• Notification or automation actions.

A newly created alarm can initially show INSUFFICIENT_DATA while metric samples are being published.

Amazon SNS notification actions

CloudWatch alarms can publish state-change notifications to an Amazon SNS topic. In the lab, an email subscription is created and must be confirmed before messages are delivered.

The notification workflow is:

1. Create or select an SNS topic.
2. Subscribe an endpoint, such as an email address.
3. Confirm the subscription.
4. Associate the topic with the alarm action.
5. Wait for the alarm to transition into the configured state.

SNS is useful for human notifications, while other alarm actions can trigger automation or incident-management integrations.

Exam-Relevant Takeaways

• EC2 memory utilization is not a standard EC2 CloudWatch metric; use the CloudWatch agent or a custom publishing solution.
• An EC2 workload should use an IAM role and instance profile, not embedded access keys.
• The minimum API permission for publishing a custom metric is cloudwatch:PutMetricData.
• Custom metrics require a clear namespace, metric name, dimensions, units, and publication interval.
• A dimension such as InstanceId prevents data from multiple instances from being merged into one time series.
• INSUFFICIENT_DATA immediately after alarm creation may be normal while samples accumulate.
• SNS email subscriptions require confirmation before delivery.
• Alarm responsiveness depends on the metric publication interval and alarm evaluation period.
• Custom metric cost and API volume should be considered when choosing collection frequency and dimensions.
• For production EC2 monitoring, the CloudWatch agent is generally more maintainable than hand-built scripts and cron jobs.

Architecture Decision Guide

Requirement	Appropriate approach	Important considerations
Monitor EC2 CPU utilization	Use the standard EC2 CloudWatch metric	No custom collector is needed
Monitor EC2 memory utilization	CloudWatch agent or custom PutMetricData publisher	Memory is not provided as a default EC2 metric
Collect several OS metrics consistently	CloudWatch agent	Centralized configuration, logs, and metrics are easier to operate
Run a small proof of concept	Script plus cron	Simple, but requires manual maintenance and failure handling
Notify an operations team	CloudWatch alarm to SNS	Confirm subscriptions and protect the topic appropriately
Identify the source of each sample	Add dimensions such as instance ID	Excessive dimension cardinality can increase cost and complexity
React to a sustained high value	Configure multiple evaluation periods	Reduces false positives from transient spikes
React to a single severe event	Use one datapoint or appropriate alarm logic	More responsive but potentially noisier
Avoid stored AWS credentials on EC2	Attach an IAM role through an instance profile	Credentials are temporary and supplied through the instance metadata credential path

Common Exam Traps

Confusing CloudWatch with CloudTrail

CloudWatch collects and evaluates operational metrics, logs, and events. CloudTrail records AWS API activity for auditing and governance. A memory-utilization alarm is a CloudWatch use case, not a CloudTrail use case.

Assuming every EC2 metric is available by default

Basic EC2 monitoring does not automatically provide guest operating-system memory utilization. The operating system must be queried by an agent or custom application.

Attaching a role incorrectly

The role’s permissions policy is not enough by itself. The role must trust EC2 and be made available through an instance profile attached to the instance.

Using access keys in the script

Hard-coded credentials create rotation, exposure, and compromise risks. Use the EC2 role so the AWS SDK or CLI can obtain temporary credentials.

Forgetting SNS confirmation

Creating an email subscription does not automatically authorize delivery. The recipient must confirm the subscription.

Treating INSUFFICIENT_DATA as an alarm failure

This state often occurs after creating an alarm or when metric publication stops. Investigate the metric stream, period, and missing-data configuration before assuming the threshold is wrong.

Ignoring collection and evaluation timing

If a script publishes once per minute but the alarm evaluates a different period, the resulting behavior may not match the intended detection time. Review publication interval, period, evaluation periods, and missing-data treatment together.

Leaving lab resources running

EC2 instances, custom metrics, SNS resources, and related infrastructure should be reviewed and removed after a lab. Custom metrics and API usage can also create ongoing charges even after the instance is stopped.

Real-World Engineer Notes

• Prefer the unified CloudWatch agent for production operating-system metrics. It supports standard configuration, multiple metric types, log collection, and easier fleet-wide deployment.
• Store agent configuration in a managed deployment mechanism such as Systems Manager, an image pipeline, or configuration management rather than editing instances manually.
• Use an IAM policy that grants only the required actions. Avoid broad permissions such as cloudwatch:* when cloudwatch:PutMetricData is sufficient.
• Design dimensions carefully. High-cardinality dimensions can create many unique time series and increase cost.
• Add units and consistent naming conventions. A metric named MemoryUtilization should not sometimes contain a fraction and sometimes a percentage.
• Decide whether missing data should be treated as breaching, not breaching, ignored, or causing INSUFFICIENT_DATA. The correct choice depends on whether a silent collector should itself be considered an incident.
• A custom metric alone does not prove that collection is healthy. Monitor the collector, agent logs, publication errors, and instance role configuration.
• For fleet-wide monitoring, consider automatic agent deployment and centralized dashboards rather than individual manually created alarms.
• Use alarm actions that match the operational requirement: SNS for notification, automation for remediation, and incident integrations for escalation.

Quick Reference Summary

• Metric source: EC2 operating system memory statistics.
• Publication API: cloudwatch:PutMetricData.
• AWS identity pattern: IAM role attached through an EC2 instance profile.
• Metric organization: namespace, metric name, dimensions, value, unit, and timestamp.
• Example namespace: Custom/Memory.
• Example metric: mem_usage.
• Scheduling example: Linux cron running once per minute.
• Alarm example: memory utilization greater than a static threshold.
• Notification path: CloudWatch alarm → SNS topic → confirmed email subscription.
• Initial alarm state: Often INSUFFICIENT_DATA until enough samples arrive.
• Production recommendation: Use the CloudWatch agent for maintainability and fleet operations.

Flashcards

1. Q: Why is a custom metric needed for EC2 memory utilization?

A: Standard EC2 CloudWatch metrics do not include guest operating-system memory utilization.

1. Q: Which API permission allows an instance to publish custom metric values?

A: cloudwatch:PutMetricData.

1. Q: How does an EC2 instance receive an IAM role?

A: The role is placed in an instance profile, and the instance profile is attached to the EC2 instance.

1. Q: Why should the instance ID be used as a metric dimension?

A: It identifies the source instance and keeps time series from different instances distinct.

1. Q: What is the purpose of a CloudWatch namespace?

A: It logically groups related metrics, especially custom metrics created by an application or organization.

1. Q: What does an alarm state of INSUFFICIENT_DATA mean?

A: CloudWatch does not have enough usable data to evaluate the alarm, often because the metric is new or samples are missing.

1. Q: What must happen before an SNS email subscription receives alarm notifications?

A: The recipient must confirm the subscription.

1. Q: What controls how quickly a custom metric can cause an alarm?

A: The metric publication interval and the alarm’s period and evaluation settings.

1. Q: What is the preferred production alternative to a hand-written memory script?

A: The Amazon CloudWatch agent.

1. Q: Why are embedded access keys a poor choice for an EC2 metric publisher?

A: They create security and rotation risks; an EC2 IAM role provides temporary credentials automatically.

1. Q: What is the difference between CloudWatch and CloudTrail in this context?

A: CloudWatch monitors operational data and triggers alarms; CloudTrail records AWS API activity for auditing.

1. Q: Why can custom metric dimensions affect cost?

A: Each unique combination of metric name and dimensions can create a separate custom time series.

Practice Questions

Question 1

A company needs to alarm when memory utilization on a fleet of EC2 instances exceeds a threshold. CPU and network metrics are already available in CloudWatch, but memory data is missing. Which solution is most appropriate?

A. Enable AWS CloudTrail data events for the instances.
B. Install and configure the CloudWatch agent with memory collection enabled.
C. Create an SNS topic and subscribe the instances to it.
D. Enable detailed monitoring without installing any software.

Correct answer: B

Explanation: Guest operating-system memory is not a default EC2 metric. The CloudWatch agent is the standard maintainable solution for collecting and publishing memory data. CloudTrail records API activity, SNS distributes messages, and detailed monitoring does not add guest memory metrics.

Question 2

An EC2-based custom metric publisher fails with an AccessDenied error when calling CloudWatch. The policy allows cloudwatch:PutMetricData, but the role was created without an instance profile. What is the best correction?

A. Attach the IAM role directly to the application process using a static ARN.
B. Place the role in an instance profile and attach the profile to the EC2 instance.
C. Add cloudwatch:GetMetricData to the policy.
D. Create an SNS subscription for the role.

Correct answer: B

Explanation: EC2 receives IAM role credentials through an instance profile. GetMetricData is not required to publish metrics, and SNS does not provide EC2 permissions.

Question 3

A CloudWatch alarm for a new custom metric remains in INSUFFICIENT_DATA several minutes after creation. Which troubleshooting step should be performed first?

A. Replace the alarm with a CloudTrail event rule.
B. Confirm that the publisher is successfully sending samples with the expected namespace, metric name, dimensions, and timestamps.
C. Delete the IAM role because alarms cannot use IAM.
D. Change the threshold to zero immediately.

Correct answer: B

Explanation: The alarm cannot evaluate data that is absent or published under a different metric identity. Validate publication, permissions, dimensions, and timing before changing the threshold.

Question 4

A custom metric is published every minute. The architect wants to alert only when memory utilization is above 80 percent for several consecutive minutes, avoiding alerts caused by brief spikes. Which alarm design best matches the requirement?

A. Configure multiple evaluation periods and require the relevant datapoints to breach the threshold.
B. Configure the alarm for one evaluation period and treat all missing data as breaching.
C. Remove the instance ID dimension.
D. Replace CloudWatch with IAM Access Analyzer.

Correct answer: A

Explanation: Multiple evaluation periods or a datapoints-to-alarm configuration can require sustained threshold breaches. Treating missing data as breaching may create false alarms, and neither removing dimensions nor using IAM Access Analyzer addresses metric evaluation.

Question 5

An organization publishes a custom metric separately for thousands of resource identifiers, creating unexpectedly high custom-metric costs. What design review is most relevant?

A. Increase the number of SNS email subscriptions.
B. Reduce all CloudTrail retention periods.
C. Review metric dimensions and avoid unnecessary high-cardinality combinations.
D. Disable the EC2 instance profile.

Correct answer: C

Explanation: Unique combinations of metric names and dimensions create separate time series. Excessive or high-cardinality dimensions can increase cost and complicate dashboards and alarms.