12) Cloud Monitoring
Amazon CloudWatch Metrics
Core Service Purpose:
CloudWatch provides performance metrics for virtually every service deployed within Amazon Web Services (AWS).
A metric represents a specific, time-ordered variable monitored over time (e.g.,
CPUUtilization,NetworkIn,NetworkOut).Every metric data point is strictly timestamped, enabling trend tracking, statistical aggregations, and historical analysis.
Metrics can be aggregated and displayed visually on customized, unified CloudWatch dashboards.
Service-Specific Metric Characteristics:
Amazon EC2 Instances:
Monitored default metrics include
CPUUtilization,StatusChecks(System and Instance status checks), and Network traffic metrics (NetworkIn,NetworkOut).RAM / Memory Utilization is not monitored or provided by default; memory is an internal operating system metric that requires a custom agent to track.
Standard Monitoring Interval: Metric data is pushed automatically every .
Detailed Monitoring Interval: Paid option (1\,\text{minute}, enabling faster alerting and Autoscaling response.\n * **Amazon EBS Volumes**:\n * Monitors disk I/O activity, specifically `DiskReadOps`, `DiskWriteOps`, `DiskReadBytes`, and `DiskWriteBytes`.\n * **Amazon S3 Buckets**:\n * Tracks storage volume and usage via `BucketSizeBytes`, overall count with `NumberOfObjects`, and incoming request rates via `AllRequests`.\n * **AWS Billing Metric**:\n * Represents the `Total Estimated Charge` (metric name: `EstimatedCharges`, reported in `USD`).\n * Calculated and published specifically and exclusively within the North Virginia region (`us-east-1`).\n * **Service Limits / Quotas**:\n * Tracks resource consumption against service API limits to warn before reaching account thresholds.\n * **Custom Metrics**:\n * Allows custom applications to push user-defined variables and dimensions directly into CloudWatch using the AWS SDK or CLI.\n\n\n\n# Amazon CloudWatch Alarms\n\n* **Alarm Functionality & Purpose**:\n * Alarms monitor CloudWatch metrics over a configured evaluation period and initiate automated actions when predefined threshold criteria are breached.\n * Evaluation configurations support advanced statistical criteria including sampling intervals, percentages, minimums, maximums, and average thresholds.\n * Configurable evaluation period defines the precise window over which the metric is analyzed before altering the state.\n\n* **Standard Alarm States**:\n * `OK`: The metric value remains within the defined threshold limits.\n * `INSUFFICIENT_DATA`: The alarm has not received sufficient data points to determine whether the threshold is met.\n * `ALARM`: The metric has crossed the configured threshold for the specified number of evaluation periods.\n\n* **Automated Alarm Actions**:\n * **Amazon EC2 Auto Scaling**:\n * Dynamically scales resources by increasing or decreasing the `desired` instance count of an Auto Scaling Group in response to load.\n * **Amazon EC2 Host Actions**:\n * Triggers recovery or lifecycle operations directly on an instance, including `Stop`, `Terminate`, `Reboot`, or `Recover` (migrating a damaged instance to new underlying hardware while retaining its IP and configuration).\n * **Amazon SNS (Simple Notification Service)**:\n * Publishes alerts directly to an SNS Topic, routing messages instantly to subscribers via Email, SMS, or downstream webhooks.\n * **Billing Alarm Example**:\n * A specialized CloudWatch Alarm configured on the `EstimatedCharges` metric in `us-east-1` to dispatch an SNS email notification when total monthly accrued AWS charges cross a predetermined monetary threshold.\n\n# Amazon CloudWatch Logs\n\n* **Log Collection & Sources**:\n * CloudWatch Logs serves as a centralized, managed repository for storing, monitoring, and querying system and application log data in real time.\n * Ingests native log output from multiple AWS managed services:\n * **AWS Elastic Beanstalk**: Application and web server access logs.\n * **Amazon ECS (Elastic Container Service)**: Standard output and error streams generated by containerized tasks.\n * **AWS Lambda**: Automated capture of function invocation traces, runtime errors, and execution logs.\n * **AWS CloudTrail**: Filtered API and management audit events.\n * **Amazon Route 53**: Detailed logging of authoritative DNS queries received by hosted zones.\n * Provides configurable, adjustable retention settings ranging from indefinite retention to specific operational timelines (e.g., 1\,\text{day} to several years).\n\n* **Log Collection for Amazon EC2 and Hybrid Systems**:\n * By default, zero operating system or application log files from an Amazon EC2 instance are pushed to CloudWatch.\n * Ingestion requires deploying and running the dedicated CloudWatch Agent (CloudWatch Logs Agent) directly on the operating system.\n * The host instance must be assigned an IAM Role with appropriate permissions granting write operations to CloudWatch Logs.\n * The CloudWatch Logs Agent is hybrid-compatible and can be deployed on physical on-premises servers to centralize non-cloud enterprise logs.\n\n# Amazon EventBridge\n\n* **Event-Driven Architecture Overview**:\n * Formerly known as CloudWatch Events, Amazon EventBridge is a serverless event bus service that ingests, filters, transforms, and routes real-time data to destination targets.\n * Operates across two principal trigger models:\n * **Scheduled Triggers (Cron/Rate)**: Executes actions on a defined temporal frequency, functioning as automated cloud cron jobs (e.g., triggering a Lambda script every hour, or running recurring maintenance every 4\,\text{hours}).\n * **Event Pattern Rules**: Rules configured with JSON pattern filters that detect and react to specific operational events occurring across AWS resources (e.g., matching an `IAM Root User Sign in Event` and dispatching an email notification via an SNS Topic).\n\n* **Event Sources and Destination Ecosystem**:\n * **Example Sources**:\n * Amazon EC2 (e.g., instance state changes like `Start Instance` or `Stop Instance`).\n * AWS CodeBuild (e.g., build failure events).\n * Amazon S3 (e.g., object upload or deletion notifications).\n * AWS Trusted Advisor (e.g., generation of a new optimization finding).\n * AWS CloudTrail (e.g., triggering on any specific API call recorded).\n * Temporal schedules (e.g., scheduled cron expressions).\n * **Example Destinations (Categorized)**:\n * **Compute Targets**: AWS Lambda, AWS Batch, Amazon ECS Task.\n * **Integration Targets**: Amazon SQS, Amazon SNS, Amazon Kinesis Data Streams.\n * **Orchestration Targets**: AWS Step Functions, AWS CodePipeline, AWS CodeBuild.\n * **Maintenance Targets**: AWS Systems Manager (SSM) Run Command/Automation, EC2 Actions.\n\n\n\n* **Event Bus Varieties & Architecture**:\n * **Default Event Bus**: Pre-provisioned bus that automatically receives events originating from native AWS services.\n * **Partner Event Bus**: Connects directly with external Software-as-a-Service (SaaS) partner systems (e.g., Zendesk, Datadog) without requiring custom polling code.\n * **Custom Event Bus**: Dedicated custom bus deployed to receive, filter, and route application-level events published by internal custom applications.\n\n* **Advanced Governance & Replay Capabilities**:\n * **Schema Registry**: Automatically infers, discovers, and records the structure (schemas) of events routed across buses, allowing developers to generate strongly typed code bindings in popular languages.\n * **Event Archiving**: Allows capturing and persisting all or filtered events routed to an event bus, with retention durations configurable indefinitely or for a defined duration.\n * **Event Replay**: Enables replaying archived events back through the bus to re-process failed transactions, test new business logic, or debug downstream services.\n\n# AWS CloudTrail\n\n* **Core Governance & Compliance Features**:\n * Delivers comprehensive governance, compliance, operational auditing, and risk assessment capabilities for an AWS account.\n * Enabled by default upon AWS account creation.\n * Captures, records, and preserves a complete history of API actions and events initiated across the account.\n * Tracks all actions executed through the AWS Management Console, AWS SDKs, AWS Command Line Interface (CLI), and internal automated AWS service interactions.\n * Records identifying metadata for every call: the caller identity (IAM User, IAM Role), the source IP address, the precise request parameters, and the exact response elements.\n\n* **Architecture, Destinations, and Regional Scope**:\n * Captured CloudTrail log files can be routed to an Amazon S3 Bucket for tamper-resistant long-term archiving, and streamed to CloudWatch Logs for real-time alerting and metric filters.\n * **Scope**: A CloudTrail trail can be created as a multi-region trail applied to **All Regions** (recommended default) or restricted to a single specified AWS Region.\n * **CloudTrail Insights**: Optional automated anomaly detection capability that analyzes operational API usage patterns to detect anomalous call volumes or suspicious management changes.\n * **Fundamental Operational Rule**: Whenever a cloud resource is unexpectedly modified, corrupted, or deleted in AWS, the first diagnostic step is to inspect and audit **AWS CloudTrail**.\n\n\n\n# AWS X-Ray\n\n* **Challenges of Traditional Distributed Debugging**:\n * Traditional debugging relied on running tests locally, sprinkling print and log statements across source code, and redeploying into production.\n * In modern architectures, log formats differ substantially across services, making distributed log aggregation and correlate-based debugging complex.\n * While single monolithic applications are relatively simple to trace and debug, distributed microservice architectures are difficult due to asynchronous call paths and network hops.\n * Standard logging fails to deliver an end-to-end holistic view of overall application topology.\n\n* **Core Observability & Tracing Architecture**:\n * AWS X-Ray provides end-to-end distributed tracing and visual dependency analysis across microservice architectures.\n * Tracks discrete requests as they travel across distributed backends, measuring execution latencies and tracing execution segments.\n * Generates an interactive **Service Map** illustrating system dependencies, average response latency, and per-minute throughput rates.\n\n\n\n* **Service Map Practical Breakdown (Worked Architecture Example)**:\n * External **Clients** route incoming traffic into an Amazon EC2 instance layer (`myfrontend-dev`, type `AWS::EC2::Instance`), exhibiting an average latency of 70\,\text{ms}9\,\text{t/min} (transactions per minute).\n * The frontend instance branches out into three parallel dependent interactions:\n * Queries an internal link-local metadata address (`169.254.169.254`, remote dependency) with an average latency of 3\,\text{ms}0.8\,\text{t/min}.\n * Performs downstream database operations against an Amazon DynamoDB table (`awseb-e-npdwiv3ayq-stack-Start...`, type `AWS::DynamoDB::Table`) with an average latency of 30\,\text{ms}9\,\text{t/min}.\n * Publishes downstream asynchronous notification messages to an Amazon SNS topic (`SNS`, type `AWS::SNS`) with an average latency of 43\,\text{ms}9\,\text{t/min}.\n\n* **Operational Advantages & Diagnostic Capabilities**:\n * Isolates performance bottlenecks and points of high latency across deep microservice dependency chains.\n * Identifies structural dependencies and communication paths across microservices.\n * Pinpoints malfunctioning services, application errors, and uncaught exceptions.\n * Reviews request behavior, path routing, and downstream payload processing.\n * Determines SLA compliance by assessing whether latency thresholds breach contractual Service Level Agreements.\n * Detects exact locations where upstream rate limits or API throttling occur.\n * Pinpoints and identifies specific end-users impacted by service failures.\n\n# AWS Health Dashboard\n\n* **Service History (Public Health Overview)**:\n * Previously designated as the AWS Service Health Dashboard.\n * Delivers a public, global status overview of the operational availability of all AWS services across all commercial geographical AWS regions.\n * Provides a continuous 12\,\text{month} running log of historical service interruptions, degraded performance events, and operational resolutions.\n * Includes regional and service-specific RSS feeds allowing automated subscription to live status changes.\n\n\n\n* **Your Account (Personal Health Dashboard / PHD)**:\n * Previously referred to as the AWS Personal Health Dashboard (PHD).\n * Provides a personalized, account-specific view into the health, availability, and performance of the specific AWS services and infrastructure backing an account's provisioned resources.\n * In contrast to the generic, macro-level Service Health Dashboard, the Account Health Dashboard alerts on events with direct, material impact on the account's operational environment.\n * Issues proactive alerts and detailed remediation guidance to resolve issues when underlying AWS infrastructure fails or degrades.\n * Tracks and categorizes incoming operational updates:\n * **Open Issues**: Active disruptions directly affecting provisioned infrastructure.\n * **Scheduled Changes**: Proactive notices regarding upcoming maintenance windows (e.g., planned EC2 hardware retirement, certificate rotations, database engine patching).\n * **Other Notifications**: General administrative notifications and lifecycle communications.\n * **Event Log**: Historical record of past incidents and operational events.\n * Acts as a global service that can aggregate health data across multiple member accounts using AWS Organizations.\n\n\n\n# AWS Monitoring & Observability Comparative Reference\n\n* **Amazon CloudWatch Metrics**:\n * Focuses on numerical, time-series performance data monitoring infrastructure utilization (CPU, network, disk) and account billing figures.\n* **Amazon CloudWatch Alarms**:\n * Evaluates metrics against static or statistical thresholds to trigger automatic remediation, EC2 lifecycle actions, Auto Scaling adjustments, and SNS notifications.\n* **Amazon CloudWatch Logs**:\n * Centralizes application and infrastructure text logs from Lambda, ECS, Beanstalk, Route 53, and on-premises/EC2 hosts running the CloudWatch Agent.\n* **Amazon EventBridge (CloudWatch Events)**:\n * Manages real-time event routing from AWS services, custom apps, and SaaS partners to downstream targets via pattern matching or cron schedules.\n* **AWS CloudTrail**:\n * Records every management API call, console action, and CLI command for compliance, governance, and security auditing. CloudTrail Insights automatically surfaces anomalous operational behavior.\n* **AWS X-Ray**:\n * Provides distributed tracing, dependency discovery, request timeline visualization, and bottleneck detection across microservice architectures.\n* **AWS Health Dashboard (Service History)**:\n * Macro-level, public view of all AWS service availability across all global regions over the preceding 12\,\text{months}$$.
AWS Health Dashboard (Your Account / PHD):
Micro-level, personalized alerting engine delivering remediation advice and tracking scheduled maintenance affecting specific provisioned cloud assets.