DevOps.Academy
CoursesCurriculumPricing

    Loading…

    ↑ ↓ move · ↵ open · Ctrl K anywhere

    ◔My learningSign in
    DevOps.Academy

    Free, hands-on DevOps lessons. Made with care in India.

    Learn

    All coursesLinux roadmapCurriculumMy learning

    Academy

    PricingCertificates

    Legal

    PrivacyTermsContact

    devops.rajeev.pro

    AWS for DevOpsLesson 13 of 17
    Your progress · 0%
    On this page
    1. Metrics have context
    2. Logs are a stream
    3. Alarms turn data into action
    4. A dashboard answers one question
    5. Events are different from metrics
    6. Audit the API
    7. Audit the configuration
    8. Custom metrics and dimensions
    9. Logs Insights and metric filters
    10. Static, composite and anomaly alarms
    11. Dashboards and the CloudWatch agent
    12. Traces, events and configuration evidence
    ↖ Course roadmap
    Lesson 13 · Monitoring & auditing

    Monitoring and auditing: CloudWatch, CloudTrail and Config

    Read metrics, search logs, set alarms that fire before users notice, and keep an audit trail of every change.

    25 min read · intermediate · hands-on

    By the end of this lesson you'll be able to

    0 of 5 complete

    Metrics have context

    When a user says “the service is slow”, I need a signal that narrows the search. CloudWatch metrics are numbers with context. A metric has a namespace, a name, a unit and zero or more dimensions.

    The namespace keeps unrelated numbers apart. The name says what is measured. A dimension identifies the thing being measured, such as an instance ID or environment. The same metric name with a different dimension is a different time series.

    EC2 publishes metrics such as CPUUtilization for instances. You can also publish an application metric:

    $ aws cloudwatch put-metric-data \
        --namespace DevOpsAcademy/Demo \
        --metric-data 'MetricName=QueueDepth,Dimensions=[{Name=Environment,Value=practice}],Value=3,Unit=Count'
    
    aws cloudwatch put-metric-data \
    • awsthe AWS command line

    I used this command in ap-south-1. It returned no text, which is a successful PutMetricData response. Find it under CloudWatch → Metrics → All metrics → DevOpsAcademy/Demo.

    A custom metric is emitted by your code or an agent. Give it a useful name and stable dimensions. If a process invents a new dimension value for every request, the number of time series grows quickly.

    Logs are a stream

    Metrics tell me that something changed. Logs help me explain why. A log event has a timestamp and a message. A log group is the container for streams from one application or class of resource. Set retention deliberately; the default is Never Expire.

    $ aws logs create-log-group --log-group-name /academy/cloudwatch-demo
    $ aws logs put-retention-policy \
        --log-group-name /academy/cloudwatch-demo \
        --retention-in-days 7
    
    aws logs create-log-group --log-group-name /academy/cloudwatch-demo
    • awsthe AWS command line

    CloudWatch Logs Insights reads selected groups. This query finds recent events:

    fields @timestamp, @message
    | sort @timestamp desc
    | limit 20
    
    Retention is a data decision

    Logs can contain tokens, request bodies or customer data. Do not log secrets. Choose retention with your security and incident-response needs in mind, then restrict who may read the group. Deleting a log group removes its events.

    Alarms turn data into action

    An alarm is a rule over a metric. It needs a statistic, period, threshold and number of evaluation periods. It can be OK, ALARM or INSUFFICIENT_DATA. Missing data is a decision too.

    $ aws cloudwatch put-metric-alarm \
        --alarm-name academy-cloudwatch-demo-alarm \
        --namespace DevOpsAcademy/Demo \
        --metric-name QueueDepth \
        --dimensions Name=Environment,Value=practice \
        --statistic Average \
        --period 60 \
        --evaluation-periods 1 \
        --threshold 10 \
        --comparison-operator GreaterThanOrEqualToThreshold \
        --treat-missing-data notBreaching
    
    aws cloudwatch put-metric-alarm \
    • awsthe AWS command line

    For production, choose a threshold from a service objective. Add an SNS action when a human or automation must be notified. Lesson 14 uses SNS and SQS in detail.

    A dashboard answers one question

    A dashboard is a shared view, not a monitoring strategy. Put the few signals that answer one operational question on it. This widget shows one practice metric:

    $ aws cloudwatch put-dashboard \
        --dashboard-name academy-cloudwatch-demo-dashboard \
        --dashboard-body '{"widgets":[{"type":"metric","x":0,"y":0,"width":12,"height":6,"properties":{"view":"timeSeries","title":"Practice queue depth","region":"ap-south-1","metrics":[["DevOpsAcademy/Demo","QueueDepth","Environment","practice"]],"period":60,"stat":"Average"}}]}'
    
    aws cloudwatch put-dashboard \
    • awsthe AWS command line

    The real command returned a validation response with an empty DashboardValidationMessages array. The widget is small: one graph, one question and no decorative noise.

    Events are different from metrics

    EventBridge carries discrete events, such as “an EC2 instance changed state”. A metric is a measurement over time. Use an EventBridge rule when the fact of the event should trigger a target; use an alarm when a measurement crossing a threshold should trigger action.

    Audit the API

    CloudTrail answers who called which AWS API, when, from which source and with what result. CloudTrail Event history gives a recent view. A production trail sends events to an S3 bucket and often to a log group with controls around retention and access.

    An EC2 launch, a security-group change and the deletion of this lesson’s alarm become API events. CloudTrail records the AWS control plane, not every request handled by your application.

    Audit the configuration

    AWS Config evaluates resource configuration against rules. CloudTrail can tell you that a security group changed; Config can tell you whether the resulting group violates a rule. This gives you both a timeline and current compliance state.

    Config rules and recorders cost money in some configurations. I did not enable a recorder for this lesson because it was outside the approved practice resources. Enable it deliberately in a real account and verify cost first.

    In production

    Start with a service-level question, then choose the signal: metric for a number, log for detail, alarm for a threshold, EventBridge for a discrete event, CloudTrail for API history and Config for resource compliance.

    Custom metrics and dimensions

    Namespaces keep application metrics separate from AWS service metrics. Dimensions identify a time series, so keep their values bounded: Environment=practice is useful; a request ID dimension creates an uncontrolled number of series. Emit a metric from code or the CloudWatch agent when the managed service metric is not enough.

    The custom namespace is selected. The metric and bounded environment dimension identify the series.© Screenshot: DevOps Academy

    The custom namespace is selected. The metric and bounded environment dimension identify the series.© Screenshot: DevOps Academy

    Logs Insights and metric filters

    Logs Insights searches selected log groups with a query language. Start with fields @timestamp, @message, sort by time, and limit the result while investigating. A metric filter turns matching log text such as ERROR into a metric. Filters are useful for simple counters; use structured application metrics when the event needs richer labels.

    The practice log group is the search boundary. Retention is explicit instead of Never Expire.© Screenshot: DevOps Academy

    The practice log group is the search boundary. Retention is explicit instead of Never Expire.© Screenshot: DevOps Academy

    Static, composite and anomaly alarms

    A static alarm is easy to explain: a statistic crosses a threshold for a number of periods. A composite alarm combines child states so an operator receives one decision instead of several related pages. Anomaly detection learns a normal band and alerts when the signal leaves it; it is useful for seasonal or changing workloads, not for a hard safety limit. Alarm actions can publish to SNS, invoke automation or scale a resource. Treat an alarm as a runbook entry, not just a red icon.

    The static alarm is in ALARM because the custom value is above five. A sibling alarm is OK. The composite alarm is visible as a single operational view.© Screenshot: DevOps Academy

    The static alarm is in ALARM because the custom value is above five. A sibling alarm is OK. The composite alarm is visible as a single operational view.© Screenshot: DevOps Academy

    Dashboards and the CloudWatch agent

    A dashboard should answer one question for one audience. Do not turn it into a wall of every metric. The CloudWatch agent adds host memory and disk signals that basic EC2 metrics do not publish. Configure it with least-privilege permissions and a short retention policy for practice data. Container Insights adds task and container dimensions; enable it only when the additional cost and signal volume are justified.

    The dashboard has one question-oriented widget. The time series is the same custom metric used by the alarm.© Screenshot: DevOps Academy

    The dashboard has one question-oriented widget. The time series is the same custom metric used by the alarm.© Screenshot: DevOps Academy

    Traces, events and configuration evidence

    X-Ray traces and Application Signals connect latency across service boundaries; use them when metrics show a symptom but not the slow dependency. EventBridge rules route matching events to targets. CloudTrail records API activity, while AWS Config evaluates resource configuration against rules. They answer different questions: what happened, what event should trigger work, and whether the current resource state meets policy.

    ⌘
    Mini mission

    Make a small monitoring stack

    Publish one custom metric, create one seven-day log group, one alarm and one dashboard, then prove their state with describe commands. Delete every practice resource and verify that the queries return empty results.

    Input: An AWS account, the AWS CLI configured with the anythinkx profile, and ap-south-1Output: A metric, a log group, an OK alarm and a dashboard, followed by empty cleanup queries
    Reveal one safe solution
    $ REGION=ap-south-1
    $ PROFILE=anythinkx
    $ LOG_GROUP=/academy/cloudwatch-demo
    $ ALARM=academy-cloudwatch-demo-alarm
    $ DASHBOARD=academy-cloudwatch-demo-dashboard
    $ aws cloudwatch put-metric-data --profile $PROFILE --region $REGION --namespace DevOpsAcademy/Demo --metric-data 'MetricName=QueueDepth,Dimensions=[{Name=Environment,Value=practice}],Value=3,Unit=Count'
    $ aws logs create-log-group --profile $PROFILE --region $REGION --log-group-name $LOG_GROUP
    $ aws logs put-retention-policy --profile $PROFILE --region $REGION --log-group-name $LOG_GROUP --retention-in-days 7
    $ aws cloudwatch put-metric-alarm --profile $PROFILE --region $REGION --alarm-name $ALARM --namespace DevOpsAcademy/Demo --metric-name QueueDepth --dimensions Name=Environment,Value=practice --statistic Average --period 60 --evaluation-periods 1 --threshold 10 --comparison-operator GreaterThanOrEqualToThreshold --treat-missing-data notBreaching
    $ aws cloudwatch put-dashboard --profile $PROFILE --region $REGION --dashboard-name $DASHBOARD --dashboard-body '{"widgets":[{"type":"metric","x":0,"y":0,"width":12,"height":6,"properties":{"view":"timeSeries","title":"Practice queue depth","region":"ap-south-1","metrics":[["DevOpsAcademy/Demo","QueueDepth","Environment","practice"]],"period":60,"stat":"Average"}}]}'
    $ aws logs describe-log-groups --profile $PROFILE --region $REGION --log-group-name-prefix $LOG_GROUP --query 'logGroups[].logGroupName'
    $ aws cloudwatch describe-alarms --profile $PROFILE --region $REGION --alarm-names $ALARM --query 'MetricAlarms[].StateValue'
    $ aws cloudwatch delete-alarms --profile $PROFILE --region $REGION --alarm-names $ALARM
    $ aws cloudwatch delete-dashboards --profile $PROFILE --region $REGION --dashboard-names $DASHBOARD
    $ aws logs delete-log-group --profile $PROFILE --region $REGION --log-group-name $LOG_GROUP
    $ aws logs describe-log-groups --profile $PROFILE --region $REGION --log-group-name-prefix $LOG_GROUP --query 'logGroups[].logGroupName'
    $ aws cloudwatch describe-alarms --profile $PROFILE --region $REGION --alarm-names $ALARM --query 'MetricAlarms[].AlarmName'
    
    aws cloudwatch put-metric-data --profile $PROFILE --region $REGION --namespace DevOpsAcademy/Demo --metric-data 'MetricName=QueueDepth,Dimensions=[{Name=Environment,Value=practice}],Value=3,Unit=Count'
    • awsthe AWS command line
    • --regionwhich Region
    aws logs describe-log-groups --profile $PROFILE --region $REGION --log-group-name-prefix $LOG_GROUP --query 'logGroups[].logGroupName'
    • --querypick fields from the JSON response

    If you launch an instance for CPU metrics, terminate it first, wait for terminated, then delete any resources you created for it. Never leave a running instance while you move to the next lesson.

    Try it yourself

    0 of 6 steps done

    Run each task in your own account or terminal, then tick it off.

    Knowledge check

    Quick check

    Question 1 of 7

    What identifies one CloudWatch metric stream?

    Go deeper

    Official reading for this lesson

    • DocsCloudWatch user guideAWS Docs ↗
    • DocsCloudWatch metrics conceptsAWS Docs ↗
    • DocsCloudWatch Logs Insights query syntaxAWS Docs ↗
    • DocsAWS CloudTrail user guideAWS Docs ↗
    • DocsAWS Config developer guideAWS Docs ↗

    Or get every quiz answer right and it completes itself.

    ← PreviousLambda: code without serversNext lesson →Messaging: SES, SNS and SQS