Operations, Monitoring, and Reliability
Operations, Monitoring, and Reliability tests how you observe a running system, automate its operations, and recover it after failure within stated targets. Most questions hinge on the difference between logging, metrics, and events, and between the disaster-recovery strategies.
The observability trio
CloudWatch holds metrics (CPU, latency, custom metrics), logs (Logs Insights queries), alarms (threshold or metric-math triggers), and dashboards. CloudTrail records API calls for audit - it is not a performance monitor. EventBridge routes events between services and can react to state changes. X-Ray traces requests through distributed services to find latency bottlenecks.
Health awareness
The Service Health Dashboard reports broad, public AWS service status. The Personal Health Dashboard (via AWS Health) reports events affecting your specific account and resources - that distinction is a frequent question.
Operations and automation
Systems Manager provides patching, Run Command, Session Manager, and Parameter Store. CloudFormation and the CDK provision infrastructure as code with drift detection. Elastic Beanstalk and OpsWorks cover application deployment. Trusted Advisor reports across cost optimization, performance, security, fault tolerance, and service quotas.
Recovery strategies and targets
RTO is how long recovery may take; RPO is how much data loss is tolerable. Strategies from cheapest and slowest to costliest and fastest: backup and restore, pilot light (core data replicated, minimal services running), warm standby (scaled-down but fully functional copy), and multi-site active-active (both sites serving traffic).
Worked example
A two-tier application must recover in a second Region within 15 minutes with no more than 5 minutes of data loss. Reasoning: backup and restore gives an RTO measured in hours and cannot meet 15 minutes; pilot light still requires scaling and configuration steps that risk breaching it. Warm standby keeps a scaled-down but complete stack running with continuous replication, so promoting it fits a 15-minute RTO and a 5-minute RPO. Multi-site active-active would also work but doubles steady-state cost, so warm standby is the better-fit answer.
Traps that cost marks
- Choosing pilot light when RTO is minutes rather than hours.
- Confusing RTO with RPO.
- Assuming CloudTrail alarms on its own, or that CloudWatch metrics include API audit history.
- Using the Service Health Dashboard to diagnose an issue isolated to your account.