Study guide
Technical reference and lesson notes
Purpose of This Lesson
Amazon EC2 provides built-in health checks and CloudWatch metrics that help determine whether an instance and its underlying AWS infrastructure are operating correctly. Understanding the distinction between system status checks and instance status checks is important for troubleshooting, automation, and SAP-C02 architecture questions.
This lesson also covers the difference between basic and detailed monitoring, the role of the CloudWatch agent, and how CloudWatch alarms can trigger notifications or recovery actions.
Key Concepts
EC2 Status Checks
EC2 status checks run automatically and identify conditions that may prevent an instance from running applications successfully. The two primary categories are:
| Check type | What it evaluates | Typical failure domain | Who usually resolves it? |
|---|---|---|---|
| System status check | AWS infrastructure supporting the instance, such as the physical host, underlying network, or power system | AWS infrastructure | AWS, although the customer may need to stop/start or recover the instance depending on the issue |
| Instance status check | The instance operating system and instance-level network configuration | Guest OS or customer configuration | The customer |
A system status check failure generally indicates a problem outside the guest operating system. An instance status check failure can result from issues such as an improperly configured operating system, failed boot process, exhausted system resources, or problems with the instance’s networking stack.
The EC2 console exposes the current status and status-check history. These checks can also be used as the metric source for CloudWatch alarms.
Status-Check Alarms and Automated Actions
CloudWatch alarms can monitor EC2 status-check metrics and respond when an instance becomes impaired. Depending on the failure type and architecture, an alarm may:
- Send an Amazon SNS notification
- Trigger an operational workflow through automation
- Initiate an EC2 recovery action for supported system-level failures
- Support incident response or replacement workflows
A status-check alarm is not a substitute for application-level health checks. An instance can pass EC2 status checks while the application, a critical process, or a dependency is unavailable.
Basic and Detailed Monitoring
EC2 sends standard monitoring metrics to Amazon CloudWatch.
- Basic monitoring generally provides metrics at five-minute intervals at no additional charge for supported standard metrics.
- Detailed monitoring provides metrics at one-minute intervals and incurs additional charges.
Detailed monitoring is useful when scaling decisions, alerting, or operational response requires faster visibility. It does not automatically provide every operating-system metric; it improves the frequency of supported EC2 metrics.
Metrics Available from Standard EC2 Monitoring
Common EC2 metrics include:
- CPU utilization
- Network traffic and packet metrics
- EBS read and write activity
- Status-check metrics
These metrics are available in CloudWatch under EC2 namespaces and can be viewed by instance or, where applicable, by Auto Scaling group.
EBS also exposes volume-level metrics, allowing an engineer to inspect the behavior of individual EBS volumes attached to instances. The relevant metrics can be filtered by volume ID.
CloudWatch Agent
The CloudWatch agent runs on the guest operating system and collects additional operating-system metrics and logs that standard EC2 monitoring does not provide.
Examples include:
- Memory utilization
- Disk-space utilization
- Disk I/O details at the OS level
- Process-level information
- Application and system logs
The agent requires installation and configuration on the instance. It also requires appropriate IAM permissions, commonly through an instance role, to publish metrics and logs to CloudWatch.
CPU utilization from the EC2 service is available through standard monitoring, but the agent can provide additional OS-level views and more granular dimensions. CloudWatch agent metrics should not be confused with the EC2 service metrics collected automatically by AWS.
Exam-Relevant Takeaways
- A system status check focuses on AWS-managed infrastructure beneath the instance.
- An instance status check focuses on the guest operating system and instance-level networking.
- The customer normally investigates and remediates instance status-check failures.
- Detailed monitoring changes the frequency of supported EC2 metrics to one-minute intervals; it does not automatically collect memory or disk-space utilization.
- Use the CloudWatch agent for operating-system metrics such as memory and filesystem utilization.
- EC2 status checks indicate infrastructure or instance health, not application health.
- CloudWatch alarms can notify operators and, for supported scenarios, initiate automated recovery or remediation.
- EC2 metrics and EBS volume metrics are distinct views: one describes the instance, while the other describes a particular block-storage volume.
- Monitoring is not the same as logging. CloudWatch Logs generally requires an agent or another log-publishing integration.
Architecture Decision Guide
| Requirement | Recommended capability | Reason |
|---|---|---|
| Detect failure of the AWS host or underlying infrastructure | EC2 system status checks | Identifies infrastructure-level impairment |
| Detect an unhealthy guest OS or instance networking stack | EC2 instance status checks | Detects problems inside the instance boundary |
| Make EC2 metrics available every minute | Enable detailed monitoring | Provides more frequent supported EC2 metrics |
| Monitor memory or filesystem utilization | Install and configure the CloudWatch agent | These are guest-OS metrics rather than standard EC2 metrics |
| Notify an operations team when an instance is impaired | CloudWatch alarm with Amazon SNS | Converts a metric condition into an alert |
| Recover supported EC2 instances after infrastructure failure | Status-check alarm with an EC2 recovery action | Automates recovery for appropriate system-level failures |
| Confirm that an application endpoint is usable | Application-specific health check, load balancer health check, or synthetic monitoring | EC2 status checks do not validate application behavior |
| Analyze storage performance for a specific block volume | CloudWatch EBS volume metrics | Metrics can be filtered by EBS volume ID |
Common Exam Traps
- Confusing system and instance checks: System checks relate to AWS infrastructure; instance checks relate primarily to the guest OS and instance-level configuration.
- Assuming detailed monitoring includes memory: One-minute EC2 monitoring does not provide memory utilization. Install the CloudWatch agent for that.
- Treating a passing status check as proof the application works: EC2 can be healthy while a web server, database process, or application dependency is broken.
- Assuming CloudWatch automatically collects all OS metrics: Standard EC2 metrics are limited. Additional OS metrics require an agent or another integration.
- Using instance status checks to diagnose every network issue: A failure may be caused by the OS or instance configuration, but broader network dependencies such as security groups, route tables, NAT gateways, or load balancers require separate analysis.
- Ignoring monitoring cost and granularity: Detailed monitoring provides faster data but adds cost. Select it when the operational or scaling requirement justifies the expense.
- Confusing EBS and EC2 metrics: Instance-level storage activity and volume-level EBS metrics answer different troubleshooting questions.
Real-World Engineer Notes
- Use status-check history to identify recurring infrastructure or instance problems rather than inspecting only the current green state.
- Pair infrastructure health with application health. For example, a load balancer target health check can detect an unhealthy HTTP service even when the EC2 instance passes both status checks.
- For Auto Scaling workloads, instance status and application health should influence replacement decisions. A healthy instance that serves failed application traffic may still need replacement or remediation.
- Use the CloudWatch agent configuration consistently through Systems Manager, user data, a golden AMI, or a configuration-management pipeline instead of configuring individual servers manually.
- Apply least-privilege IAM permissions to the instance role used by the CloudWatch agent.
- Choose metric resolution based on the response objective. Five-minute data may be sufficient for trend analysis, while rapid scaling or incident detection may require one-minute data.
- Monitor both aggregate and per-resource views. An Auto Scaling group may appear healthy overall while one instance or EBS volume is experiencing a localized issue.
Quick Reference Summary
- System status check: AWS-managed infrastructure problem.
- Instance status check: Guest OS or instance-level problem.
- Basic monitoring: Standard EC2 metrics at a broader interval, commonly five minutes.
- Detailed monitoring: Supported EC2 metrics at one-minute intervals for an additional charge.
- CloudWatch agent: Collects OS-level metrics and logs, including memory and filesystem data.
- CloudWatch alarm: Evaluates a metric and can notify or automate a response.
- Application health: Requires an application-aware check; EC2 status checks alone are insufficient.
Flashcards
- Q: What does an EC2 system status check evaluate?
A: AWS-managed infrastructure supporting the instance, such as the underlying host or network.
- Q: What does an EC2 instance status check evaluate?
A: The guest operating system and instance-level networking and configuration.
- Q: Who generally resolves an instance status-check failure?
A: The customer, by investigating the OS, boot process, configuration, or instance-level networking.
- Q: What is the main benefit of EC2 detailed monitoring?
A: Supported EC2 metrics are delivered at one-minute intervals instead of the broader basic-monitoring interval.
- Q: Does detailed monitoring provide memory utilization?
A: No. Memory utilization normally requires the CloudWatch agent or another guest-OS monitoring solution.
- Q: What does the CloudWatch agent collect?
A: Additional OS metrics and logs, such as memory, disk-space utilization, process data, and system or application logs.
- Q: What can a CloudWatch alarm do when an EC2 status check fails?
A: It can notify operators and may initiate an appropriate automated action, including supported recovery actions.
- Q: Why can an EC2 instance pass status checks while the application is unavailable?
A: EC2 status checks do not validate application processes, endpoints, dependencies, or business functionality.
- Q: Where would you look for metrics for a specific EBS volume?
A: CloudWatch EBS per-volume metrics, filtered by the volume ID.
- Q: What is the operational tradeoff of detailed monitoring?
A: Better alerting and scaling responsiveness in exchange for additional monitoring cost.
Practice Questions
Question 1
An EC2 instance reports an instance status check failed condition. The application team recently modified the operating system networking configuration. What is the most appropriate initial conclusion?
A. AWS must replace the physical host immediately.
B. The issue is probably within the guest OS or instance-level configuration.
C. The EBS volume has reached its maximum storage capacity.
D. The application is healthy because the system status check passed.
Correct answer: B
Explanation: Instance status checks focus on the guest OS and instance-level networking. Recent OS networking changes make a customer-controlled configuration issue more likely than an underlying AWS host failure.
Question 2
A company wants to alarm when EC2 memory utilization exceeds 80%. The architecture team enables detailed monitoring but still cannot find a memory metric. What should they do?
A. Enable system status checks.
B. Configure an EC2 recovery action.
C. Install and configure the CloudWatch agent.
D. Query EBS volume metrics instead.
Correct answer: C
Explanation: Detailed monitoring changes the frequency of supported EC2 metrics; it does not collect memory utilization. The CloudWatch agent must publish the memory metric from inside the operating system.
Question 3
A web application runs on EC2 instances behind an Application Load Balancer. The instances pass both EC2 status checks, but the load balancer reports HTTP health-check failures. What does this most likely indicate?
A. The underlying AWS host is definitely impaired.
B. The application endpoint or service is unhealthy even though the instance is operational.
C. Detailed monitoring is disabled.
D. The EBS volume cannot publish metrics.
Correct answer: B
Explanation: EC2 status checks verify infrastructure and instance health, not whether the application responds correctly to an HTTP request. The load balancer health check provides application-aware validation.
Question 4
An operations team requires one-minute EC2 CPU and network metrics for rapid scaling decisions. It does not need memory or filesystem metrics. Which solution is most appropriate?
A. Enable EC2 detailed monitoring.
B. Install the CloudWatch agent only.
C. Enable EBS volume monitoring.
D. Use system status checks without CloudWatch alarms.
Correct answer: A
Explanation: Detailed monitoring provides one-minute intervals for supported EC2 metrics such as CPU and network metrics. The CloudWatch agent is needed when additional guest-OS metrics are required.
Question 5
An architect wants automated notification when an EC2 instance becomes impaired and wants supported infrastructure failures to trigger recovery. Which design best meets the requirement?
A. Install the CloudWatch agent and send logs to CloudWatch Logs.
B. Create CloudWatch alarms for EC2 status-check metrics and configure notification and appropriate recovery actions.
C. Enable detailed monitoring without creating an alarm.
D. Monitor only EBS read and write metrics.
Correct answer: B
Explanation: Status-check metrics can drive CloudWatch alarms. The alarm can notify operators and, where supported and appropriate, initiate an EC2 recovery action. The CloudWatch agent and EBS metrics address different monitoring requirements.