Episode 15: Monitoring & Observability - CloudWatch, CloudTrail & AWS Config | Interactive Format | SAA-C03

Hey everyone, Baloo here, welcome back to Tech Top with Baloo, your complete guide to async the AWS solutions architect associate exam. Today we are tackling episode 15 and we are diving into one of the most practical important topics in all of AWS. It's monitoring and observability. We are covering Amazon cloud watch in depth along with two related services that frequently get confused with it, cloud trial and AWS config. Let me set the stage with a question. Imagine you've built a beautiful application on AWS, easy to instances, Lambda functions, Arduous databases, load balances, it all works, it's running great, then one day a user complains that the app itself is slow, another user reports getting errors. Now your boss asks why the database costs jumped last month, a security team member wants to know who deleted that S3 bucket three weeks ago, how do you answer any of these questions? That's where monitoring and observability comes in. Monitoring tells you what's happening right now. Observability lets you understand why something is happened by looking at the data your system produces. AWS gives you three primary tools for this. CloudWatch tracks performance metrics and aggregates the logs. CloudTrail records every API call made in your account. And AWS config tracks the configuration of your resources over time. However, these three services let you understand your AWS environment completely. Today we are going to cover CloudWatch metrics, including custom metrics for things AWS doesn't track by default. We will dive into CloudWatch logs, let's log groups, log streams, retention policies and how to send logs from easy to instances, Lambda and other sources. We'll explore CloudWatch alums in detail, including the trickier topic of composite alums, we'll touch on event bridge again briefly since it's very closely related. Then we'll cover up CloudTrail for API auditing and AWS config for compliance tracking. And finally we'll wrap up with all the important comparisons between these three services, because guess what the exam loves to test which one you use for which scenario. By the end of this episode you will be able to design monitoring solutions for any AWS environment and you will handle the CloudWatch questions on the exam confidently. Before we dive in a very quick note, I'm trying something new in this episode and I think you will love it. Throughout the episode I'm going to drop in quick pulse checks, many questions to make sure the concepts are sticking along with trap spotlights highlighting the exam traps right when the topic is fresh in your mind. And I will throw in a few memory hooks, vivid little phrases or analogies to help concepts stick. So pay attention as we go, this isn't just a lecture, it's interactive. Well let's get started. Let's start by understanding what CloudWatch actually is because it's broader than people realize. CloudWatch is AWS's primary monitoring service, but it's really a suite of capabilities, not just one thing. At its core, CloudWatch does four main things. First, it collects metrics from every AWS service, CPU usage from EC2, request counts from API gateway, latency from load balancers, invocations from Lambda, CloudWatch automatically gathers all of this. Second, it aggregates logs, application logs, operating system logs, audit logs, custom logs, they can all flow into CloudWatch logs where you can search and analyze them. Third, it creates alarms. You can watch any metric and trigger actions when it crosses a threshold. And fourth, it gives you dashboards so you can visualize everything together. Think about how this fits with everything else you have learned. Every service we have covered, that's EC2, Lambda, ADS, S3, ELB, VPC, and even CloudFront, all of them automatically publish metrics to CloudWatch. And the cool thing is you don't have to even configure anything to get the basic metrics. They just appear. That's the beauty of CloudWatch. Now CloudWatch operates in three core data types. Metrics are numerical measurements over time, like CPU utilization at 45% at 315pm, log logs are text events captured from your applications and AWS services, and events which are now mostly handled by EventBridge, they are state changes that happen in your AWS environment. For the example, just remember, CloudWatch is the central monitoring platform. Performance metrics, log aggregation, alarms, and dashboards. It's how you understand what's happening within your AWS environment in real time. Now for a pulse check. Pause and answer this in your head before we move on. If someone asks you, what's the difference between CloudWatch and just any other monitoring tool, what would your one sentence answer be? Well here's mine, CloudWatch is AWS's native monitoring suite that automatically collects metrics from every AWS service, aggregates logs, triggers alarms, and visualizes everything through dashboards. The keyword here is automatically, now that's the magic, log that in. Let's go deeper into CloudWatch metrics now because there is more nuance here than meets the eye. A metric is a variable that you monitor over time. Things like CPU utilization, network in database connections, these are all metrics. Every AWS service publishes its own set of metrics automatically and you can also publish your own custom metrics for things AWS doesn't track by default. Metrics belong to namespaces. And namespaces like a folder that groups related metrics together. AWS namespaces follow the pattern of slash AWS slash service name. So easy to metrics are in the AWS slash easy to namespace. Lambda metrics are in the AWS slash Lambda namespace. When you publish custom metrics, you choose your own namespace name. This keeps everything organized and prevents metrics from different sources from getting mixed up. Now here is an important concept, it's called dimensions. A dimension is an attribute that identifies a specific metric. For an easy to instances CPU utilization, the dimension would be the instance ID because you have multiple instances and you need to know which one CPU you're looking at. Other dimensions might be environment, production, staging, development or region or any other attribute that helps identify the source of the data. You can have up to 30 dimensions per metric. Each metric data point also has a timestamp. CloudWatch stores these as a time series which is what lets you graph them and analyze trends over time. Now let's talk about custom metrics, which is where things get interesting for the exam. AWS automatically publishes metrics for many things but not everything. The classic example is RAM utilization on an easy to instance. AWS publishes CPU, network and this metrics for easy to by default, but not memory. And why is this? Because the hypervisor running your VM can see CPU and network usage from the outside, but it can't see what's happening with memory inside your operating system. To track memory, AWS would need to be inside your operating system and they're not. So if you want to track RAM, this space used inside your file system or any other operating system level metrics, you need to publish them as custom metrics. The CloudWatch unified agent makes this easy. You install it on your easy to instance and your on-premises server, configure what you want to track and it publishes those metrics to CloudWatch automatically. There is also a concept called metric resolution. Standard resolution metrics are collected at one minute intervals. High resolution custom metrics can be collected at 10 seconds, 30 seconds or any multiple of 60 seconds. High resolution costs more but gives you finer granularity for fast moving metrics. One more feature worth mentioning here is CloudWatch metric streams. This lets you continuously stream CloudWatch metrics to a destination in near real time. You can stream to Amazon Kindness's data firewalls and then onto S3 redshift or open search. Or even cooler is that you can stream it directly to third party providers like Datadog, Splunk, New Relic or Diner Trace. You can also filter so you only stream a subset of metrics. This is useful when you have an existing monitoring platform and you want to bring AWS metrics into it. For the exam, remember the metric fundamentals. Metrics are variables you monitor over time. They belong to namespaces. Dimensions identify which specific resource the metric is for. They publish many metrics automatically but for things like RAM, you need CloudWatch unified agent to publish custom metrics. And metric streams continuously export metrics to other destinations on for a trap spotlight. This one is tested very constantly in the exam. The exam will give you a scenario like this for instance and EC2 instance is running slow and you suspect memory pressure. The DevOps team checks CloudWatch but can't see any memory metrics. Now what's the cost? For a second and think about it. The answer is by default AWS cannot see inside your operating system. So memory and the space inside the file system metrics are not collected. To get them, what do you do? You install the CloudWatch unified agent. If you see RAM, memory utilization or disk space used inside the file system in a question, the answer is almost involving a unified agent. Memory hook, AWS sees your VM from the outside, not the inside. That's why CPU and network are free but memory and disk inside need an agent outside metrics versus inside metrics, easy to remember. Okay, now let's dive into CloudWatch logs which is a huge topic and one where the exam can [BLANK_AUDIO] detailed. CloudWatch logs let you collect, store and analyze log data from your applications and AWS services. The hierarchy is very important here. At the top, you have log groups. A log group typically represents an application. So you might have a log group called myaPython prediction. Inside each log group, you have log streams. A log stream represents a specific instance of that application, maybe one log stream per EC2 instance or per container or per log file. So if you have 10 EC2 instances running in your application, you had had one log group with 10 log streams inside it. Each log group has a retention policy. By default, logs are kept forever, but you can configure expiration anywhere from one day to 10 years or to never ever expire. This is important for cost management, because logs don't come free. And if you start accumulating years of debug logs, you will never look at anyway. You're paying for storage you don't need. A best practice is to set appropriate retention policies based on what you will actually use for the logs itself. Compliance might require seven years for audit logs. Development debug logs might only need a few days, so and so forth. Logs are encrypted by default in CloudWatch. You can also enable KMS-based encryption with your own keys for additional control here. This matters for compliance scenarios where you need to demonstrate that your data itself is encrypted with keys that you manage. Now let's talk about how logs get into CloudWatch. There are many sources here. For EC2 instances and on-premises service, you install the CloudWatch logs agent or the newer unified agent. By default, no logs from your EC2 machine go to CloudWatch. You have to set up the agent and configure which logs to push. Make sure your IM permissions are correct so that the agent can write to CloudWatch. There is an important distinction here by the way between the two agents. The older CloudWatch log agents only send logs to CloudWatch logs. The newer CloudWatch unified agent does a bit more. It collects system level metrics like RAM and process counts plus it collects logs. It also supports centralized configuration through what we call SSM parameter store. So for new deployments, you should use the unified agent. Now, we want EC2 many AWS services natively integrate with CloudWatch logs. Lambda automatically logs function output. ECS can send container logs. Elastic Beanstalk collects application logs. VPC flow logs go to CloudWatch logs. API gateway can log request there. Route 53 can log DNS queries. Cloud trial can write to CloudWatch logs based on filters. So you can centralize logs from your entire environment in one place. Once logs are in CloudWatch, you need ways to use them. One option is CloudWatch logs insights. This is a query language built specifically for searching and analyzing log data. You can find a specific IP address inside your logs, count occurrences of the word error, calculate aggregated statistics and you get the idea so on. Insights automatically discovers fields from AWS services and JSON formatted log events. You can save queries and then add them to a dashboard. You can even query multiple log groups across different AWS accounts. The one limitation though to remember is insights is a query engine that scans existing logs. Not a real time engine that triggers on new logs. For real time processing, you use CloudWatch logs subscriptions. A subscription filter lets you forward log events in real time to other destinations. That is, Kindness is data streams for further processing, Kindness is data firehose for batch delivery to S3 or Lambda for custom processing. This is kind of how you build real time learning or stream logs into a third system like OpenSearch. There is also a logs to S3 export feature for bulk export. The API call is called create export task. The catches log data can take up to 12 hours to become available for export so this is not near real time. If you need real time, use subscriptions instead. One more powerful pattern is multi account log aggregation. You can use subscription filters across multiple accounts and regions to send all your organization's logs to a central account. Combined with cross account IAM rules, you can centralize logging for security analysis or compliance reporting. For the exam, remember the structure. Log groups contain log streams. Set appropriate retention policies. EC2 needs the CloudWatch logs agent or unified agent. Lambda, ECS, API gateway, VPC flow logs, all integrate natively. Logs insights can be used for querying, subscriptions for real time processing, S3 export for bulk archival but it does not support real time. Now for pulse check. Quick test, imagine that you need to set up real time analysis of application logs flowing into CloudWatch logs. That's whenever certain pattern appear you want to trigger custom processing immediately. Which feature would you use? The answer is CloudWatch logs subscriptions and not log insights. Remember that insights is a query engine. You run queries against existing logs. Subscriptions stream logs in real time to Lambda, kinases data streams or kinases data firewalls for immediate processing. Okay, now for a trap smart light and here is a sneaky one. S3 export from CloudWatch log is not real time. It can take up to 12 hours for log data to become available for export. If you see real time or near real time in the question the answer is subscriptions and not S3 export. S3 export remember is for bulk archival when latency doesn't matter. Now on for a memory hook, think of it this way. Insights is a librarian searching books on the shelf. Subscriptions is a generalist reporting events as they happen. And S3 export is like a moving truck. It handles bulk transport and it takes time. All right, now we move on to one of the most important features for the exam. It's called CloudWatch alarms. An alarm is a way to trigger actions automatically based on the value of a metric. You define a metric to watch a threshold and an action to take when the metric crosses that threshold. CloudWatch alarms have three possible states. OK means everything is fine. The metric is below your threshold. Alarm means that the threshold has been breached. Something needs attention now. Insufficient data means CloudWatch doesn't have enough data points to determine the state. This often happens at startup or when a service stops reporting. When you create an alarm you configure a few parameters. The metric to watch, of course, the threshold value, the comparison operator, whether it's greater than, less than, etc. The evaluation period, this is the length the time in seconds or which the metric is evaluated. For standard metrics, the minimum period is about one minute. For high resolution custom metrics, you can go down to 10 or 30 seconds. And the number of evaluation periods, this is how many consecutive periods the threshold must be breached before the alarm triggers. This helps avoid false alarms from brief spikes. So what can an alarm actually do? There are three main types of actions. First, easy to actions. An alarm can stop, terminate, reboot or recover an easy to instance. The recall reaction is particularly powerful. If you set an alarm on the status check fail system metric, which monitors the underlying hardware, you can configure automatic recovery here. If the hardware fails, the instance is automatically recovered onto a new hardware, keeping the same private IP, public IP, elastic IP, metadata and the placement group. Now this is great for self-healing infrastructure. There is an important distinction between two types of status checks. The instance status checks verifies the easy to VM itself, things like operating system issues. The system status checks verifies the underlying hardware AWS provides things like network connectivity at the host level. There is also an attached EBS status check. If the system check fails, recovery is appropriate. If the instance check fails, the issue might be inside your OS and recovery won't help in the scenario. Second, auto-scaling actions. We covered this in detail in the auto-scaling episode, an alarm on CPU utilization or another metric can trigger a scaling policy to add or remove instances here. This is the foundation of auto-scaling based on demand. Third, SNS notifications. The alarm publishes a message to an SNS topic, and from there you can almost do anything. Send emails, trigger Lambda functions, send to chat systems or fan out multiple SQS cues. This is the most flexible action because SNS lets you integrate with anything. Now, let me cover composite alarms, which are powerful but very often overlooked. A regular cloud watch alarm watches a single metric. A composite alarm on the other hand watches a state of multiple other alarms and combines them with AND/or logic. Now, why does this all matter? Imagine you have an easy to instance and you want to alert your team only when both CPU is high and IOPS is high. Either alone might not be a problem, maybe high CPU is normal for compute heavy workload and high IOPS is normal during backups, but both at the same time indicates a real issue. Now, with composite alarms you create individual alarms for CPU and IOPS, Thank you. create a composite alarm and then use an analogic that only triggers when both are in the alarm state. As you can guess, the big benefit here is to reduce alarm noise. Instead of getting paged for every individual metric that breaches a threshold, you only get paged when the combination indicates a real problem. This makes your alerting more meaningful and your team less prone to alert fatigue. There's also another important pattern I want to cover, creating alarms based on cloud watch logs metric filters. You can scan your logs for specific patterns and convert them into metrics. For example, you can create a metric filter that counts occurrences of the word error in your application logs. Then you create an alarm that triggers when error count exceeds some threshold per minute. This bridges the gap between logs and alarms letting you alert on log patterns, even though logs aren't natively metrics. One more useful tip for testing, you can manually set an alarm state using the command line interface. The command in AWS cloud watch set alarm state. Let's you do this. This lets you verify your notification pipeline works without actually waiting for the alarm condition to occur naturally. For the example, remember the alarm fundamentals. There are three states. They are OK, alarm and insufficient data. There are three main action types. There is easy to actions, auto scaling actions and SNS notifications. Composite alarms combine multiple alarms with and/or or logic. Status checks failures can trigger automatic instance recovery and metric filters convert log patterns into alarmable metrics. Try the scenario. Your team is getting paid constantly because alarms fire on CPU spikes or IOPS spikes that aren't actually problems individually. You only have and both are higher at the same time. Now what's the solution here? The answer as you guess is to use composites alarm with and and logic. You want to create individual alarms for CPU and IOPS as the building blocks. Then create a composite alarm that only triggers when both individual alarms are in their alarm state. This dramatically reduces alarm noise. On for a trap spotlight, pay attention to the status check distinction. The exam loves to test the difference between instance status checks and system status checks. Instance status check only looks at issues inside your EC2VM that's always level problems. Recovery here typically does not help because the issue is software inside your instance. System status check on the other hand deals with issues in the underlying hardware that AWS provides. Auto recovery here is the right action. The instance gets moved to a new hardware keeping the same IPs and metadata. If the question describes hardware failure, network connectivity at the host level or anything outside the OS itself, that you know is a system check and auto recovery here is your answer. On to a quick memory hook here, system status equals AWS's problem that's recover automatically. Instance status equals your problem. Recovery won't help you. You need to fix your OS or your application. Now I want to briefly revisit event bridge because it ties directly into monitoring even though we covered it in detail in episode 13. Here's the important thing to remember. Event bridge was formerly called cloud watch events. So if you see cloud watch events anywhere in the exam questions, recognize that's the old name for event bridge. They are in fact the same service. Event bridge has two superpowers that matter for monitoring scenarios. First, it lets you schedule things. You can run a lambda function every hour, every day at 2am or any cron expressions you want. Second, it reacts to AWS service events. That's easy to state changes, even bridge can react to all of these and route to dozens of destinations. A common monitoring pattern is to use even bridge to intercept specific cloud trail API calls. If someone calls delete table on a critical dynamo DB table, no problem. Event bridge can pick that API call event and trigger an SNS notification or a lambda function to investigate it. Someone modifies security groups inbound rules. No problem. Again, event bridge can trigger an automated response here. Now, this is real time security monitoring built on top of cloud trails API logging. Event bridge is also how AWS config sends compliance notifications, which we will cover shortly. So while event bridge is more about even driven architecture, it's deeply integrated with monitoring and alerting in AWS. For the exam, just remember, even bridge equals cloud watch events and it's used for scheduling and for reacting to AWS service events. We covered the details back in episode 13, by the way. So now let's tackle cloud trail, which is fundamentally different from cloud watch, but often confused with it. Cloud watch is about performance and operations. Cloud trail is about governance compliance and auditing. The question cloud trail answers is, is who did what in my AWS account and when? Cloud trail is enabled by default in every AWS account. The moment you create your account, cloud trail starts recording. This is important. You don't have to enable it. It's already on by default. It captures the history of events and the API calls made within your AWS account from all the sources, the console, the SDK, the CLI and even calls made by AWS services on your behalf. Every API call gets logged. Someone clicks a button inside the console to delete and easy to instance. Cloud trail records that. Alamda function calls a dynamic DB to read an item. No problem. Cloud trail also records that a user assumes an I am rule. That's also recorded. The records include who made the call, what the API was called, what parameters were passed when it happened and where it came from everything that you need for auditing. The data can be sent to cloud watch log for S3 for storage and analysis. A trail can be configured to apply to all regions, which is the default and the recommended approach here, by the way, or to a single region. So here is an exam critical point. If a resource is unexpectedly deleted or modified AWS, investigate cloud trail first. Cloud trial will tell you exactly who made the change when and from where this is the audit trail you need for security investigations. Now let's talk about the different types of events. Cloud trail tracks. The first category is management events. These are operations performed on resources in your AWS account, configuring security with I am setting up routing with EC2, creating logging with cloud trail itself. These are all basically management events by default trails log all management events. You can also separate them into read events that don't modify resources and write events that may modify resources. The second category is data events. These are not logged by default because they are high volume. Data events include S3 object level activity like get object put object and delete object and lambda function execution activity like invoking API calls. If you are trying to order two access to which S3 objects, then you have to explicitly enable data events for S3 and you can separate read and write events here too. The third category is cloud trail inside events. This is a feature that detects unusual activity in your account. Insights analyzes your normal management event patterns to create a baseline, then it continuously analyzes new write events to detect anomalies. If something unusual happens, that's a certain burst of I am actions inaccurate resource provisioning hitting service limits or gaps in normal putridic activity insights flags it as an anomaly. These anomalies appear in cloud trail console. The event is sent to S3 and an even bridge event is generated for automation. This anomaly detection built into cloud trial. One critical limitation for the exam is that cloud trial events are stored for 90 days in cloud trial itself. After 90 days, they're gone from cloud trial. To keep events longer, you need to log them to S3. Combined with Athena for querying, S3 gives you indefinite retention with searchable archives. This is a common compliance pattern. Let me give you a powerful even bridge plus cloud trial pattern here. Say someone calls Daily Table API on DynamoDB. Cloud trial records this API call. Event bridge has a rule watching for that specific API call. The rule triggers an SNS notification immediately alerting your security team. Another example, someone calls authorised security group ingress to open up a security group. Cloud trial will log it. Event bridge picks it up and you can trigger automated responses here. This is how you build real time security monitoring on top of cloud trials audit logging. For the exam, remember the key cloud trial facts. It's enabled by default. It records all API activity. It sends to cloud watch logs or S3. Logs are stored for 90 days itself in cloud trial and you want to use S3 if you want it longer retention. Management events are on by default. Data events are off by default. Insights detects anomalies. When something gets deleted unexpectedly, you want to check cloud trial first. Here's a critical exam scenario. Your security team needs to audit to access specific S3 objects six months ago. You check cloud trial and there is nothing about object level access. What when wrong and how do you fix it? Well, two things when wrong here. First, data events for S3 are not logged by default. Someone needed to explicitly enable them. Second, even if they were enabled, CloudTrail only retains events for 90 days. For six-month retention, you need to be exporting CloudTrail logs to S3 for long-term storage, then query with Athena. Okay, Trap Spotlight, this is one of the most tested CloudTrail traps. There are two categories of events with different default behaviors. There's management events, these track operations on resources like creating instances, modifying security groups, attaching policies and so on. These are logged by default. Then there is data events. There are events happening on the data. It's like S3 object access where you have a get object or put object and lambda function invocations. Remember that they are not logged by default because they are high volume. If the question is about auditing S3 object reads or writes or tracking lambda invocations, you need to enable data events explicitly. This trap appears in nearly every CloudTrail question on the exam. Quick memory hook, management events track what you do to resources. Data events track what happens inside the resources. Management is on by default. Data is off by default. Management is cheap, but data is expensive, which is why it's off. The third service in our monitoring trial is AWS config and it's fundamentally different from both CloudWatch and CloudTrail. AWS config helps with auditing and recording compliance of your AWS resources. The question config answers is what does my AWS environment look like right now? How has it changed over time? And is it compliant with my rules? Where CloudWatch tracks performance metrics over time and CloudTrail tracks API calls over time, config tracks resource configurations over time? Think about questions you might want to answer. Is there unrestricted SSH access to any of my security groups? Do any of my S3 buckets have public access? How has my application load balancer configuration changed over the last year? Was the configuration drift introduced by a deployment that's done last Tuesday related to the outage we had on Wednesday? Well, so on. These are all the questions config can answer. AWS config is a per region service. If you operate in multiple regions, you enable config in each region. You can aggregate configuration data across regions and across multiple accounts for centralized compliance reporting. Configuration data can be stored in S3 and analyzed with Athena for long term retention and complex queries. The core feature of config is config rules. A config rule defines a compliance requirement. AWS provides over 75 managed rules out of the box rules like checking whether all EBS volumes are encrypted, whether all S3 buckets have version enabled, whether all EC2 instances are using IMDS version two, so and so forth. You can also create custom rules using Lambda functions. The custom rule logic runs as a Lambda function that evaluates the resource configuration and returns compliant or non-compliant. Rules can be evaluated in two ways. They can trigger on each configuration change, so whenever any resource changes, the rule re-evaluates it, or they can be run at regular time intervals like every hour or every day. You can combine both also. Now here is an important exam point. Config rules do not prevent actions from happening. There's also no deny capability here. Config detects non-compliance after the fact and just reports it. If you want to actively prevent non-compliant changes, you need IM policies or service control policies with explicit deny rules here. Config is just the detection here and not the prevention. Remember that. This is a common exam trap. If a question asks how to prevent something from happening, config alone is not the answer. Config does support automated remediation though. That's when a resource is detected as non-compliant, you can trigger an SSM automation document to remediate it. So if config detects an IM access key that hasn't been used in 90 days, you can automatically deactivate it through an automation document. You can use AWS managed automation documents or create custom ones. If the resource is still non-compliant after the first remediation attempt, you can configure remediation retries to try again. Beyond remediation, you can also send notifications when resources are non-compliant. The pattern uses EventBridge or SNS. With EventBridge, you can route compliance state changes to Lambda, SQS, SNS, or any other target. With direct SNS integration, you get all events including configuration changes and compliance state changes. You can then filter them using SNS message filtering. So for the exam, remember the AWS config fundamentals. It tracks resource configurations over time, it's per region service and can aggregate. Rules evaluate compliance, managed rules and custom rules can be done with Lambda. Rules don't prevent, they just detect. Auto remediation via SSM automation documents can be used. Notifications can be enabled via EventBridge or SNS. Now on for a pulse check, an important scenario. If your company has a policy that S3 buckets must never be made public and management wants to prevent anyone from accidentally making a bucket public is AWS config the right tool here. The answer is no. AWS config is detection only. Remember that. It can tell you a bucket was made public and trigger remediation to fix it, but it can't stop the action from happening in the first place. For prevention, you need IAM policies, service control policies, or S3 block public access. Config catches non-compliance after the fact. Now on for a trap spotlight. This is the most common config trap on the exam. The keyword is prevent. If the question asks how to prevent non-compliant resources from being created, the answer is IAM or SCP, not config. On the other hand, if the question asks how to detect non-compliance resources, audit compliance or remediate after the fact, the answer is definitely config. Always reread the question looking for prevent versus detect. That single word changes the right answer. So for a memory hook here, I want you to think of config as a security camera, not a door lock. Cameras detect intruders and let you respond. Door locks prevent intruders from entering in the first place. Config is the camera and an auto call to police wire remediation. IAM or SCP is the lock here. Now we get to the comparison that the exam absolutely loves to test. CloudWatch versus CloudTrial versus config. Let me build a clear mental model for you. CloudWatch is about performance monitoring. The questions it answers are how is my system performing? Are my metrics within acceptable ranges? Should I scale up? Can I see trends over time? Are my logs telling me anything important? So when something is slow or broken, CloudWatch helps you see what's happening operationally. Metrics, logs, alarms, dashboards. CloudTrial is about who did what? The question it answers are who called the API to delete that bucket when was that IAM policy modified? Who is accessing my AWS account from unusual locations? It's an audit trial for security and compliance investigations. Every API call gets logged here. When you need to investigate an incident, CloudTrial is where you look for human or automated actions. AWS config is about resource state. The question it answers are what does my environment look like right now? How has it changed? Is everything compliant with my policies? It's a configuration database showing the current state and historical state of every resource. When you want to know if your environment matches your standards, config is where you look. Let me now give you a great mental shortcut using a real example. Imagine you have an application load balancer. For CloudWatch, you had monitor metrics like incoming connections, response times, and error codes. You had visualized HTTP 5XX errors as a percentage over time. You had make a dashboard showing load balancer performance, performance and operations. For CloudTrial, you had track who made any changes to the load balancer with API calls, who created the load balancer itself, who modified the listener configuration, who deleted the target group, is the audit trial of human and programmatic actions. For config, you had track the actual configuration itself. What security groups are attached? Has the SSL certificate changed? Is the cross zone load balancing enabled? You had ensure an SSL certificate is always assigned to the load balancer as a compliance requirement? See how each service answers different questions about the same resource. They're complimentary but not competing here. Let me give you exam keyword triggers now. For CloudWatch, watch for performance, metrics, CPU, network, latency, dashboards, alarms, log analysis, alerting when a metric crosses a threshold. For CloudTrial, watch for audit, who did what, API calls governance, investigating deleted resources, tracking actions taken in the account, and so forth. For config, watch for compliance, configuration changes, resource state, configuration history, compliance rules, ensuring resources match requirements and automated remediation. If you remember nothing else from this section, remember this. CloudWatch monitors performance, CloudTrial logs API calls, config tracks resource configurations. That is three different jobs, but three different services. Okay, now let's do a rapid fire round. I'll give you a scenario you picked the service. Pause after each one and answer in your head before I tell you the answer. Scenario one. The application response time has degraded, which service do you check first? The answer is cloud watch, because it tracks performance metrics. Okay, now into scenario two. An RDS database was deleted last night without authorization. Who did it? How do you find it? The answer is to use cloud trial, because you can get an audit of the API calls. Scenario three. We need to verify all our EBS volumes are encrypted as per company policy. What would you use? The answer is AWS config, because you can check compliance on the resource configuration. Scenario four. You want to set up automatic notification when an EC2 instances CPU exceeds 80% for five minutes. What do you use? You want to use cloud watch alarm to SNS. Scenario five. You want to track every change made to a specific security group over the last six months. What do you use? You want to use AWS config, because that gives you the configuration history. And finally for scenario six, you want to detect when someone calls the API to disable a cloud trial trial. What do you use? Well, this is layered. Cloud trial captures the API call, even bridge detects the pattern SNS sends the alert. So the primary answer is cloud trial plus event bridge. If you got five or six right here, you are solid. If you missed a few, replay the section and lock all of it in. So for a memory hook, when in doubt, ask what kind of question is the exam asking for? Is it how fast? How much is it healthy? Go for cloud watch? If it's who, when, from where? Then think cloud trail. If it's about compliance, what's changed? What does it look like now versus before? Then think config. Right. Let's go now through the common monitoring traps that catch people up on the exam. Trapped number one, cloud watch versus cloud trial versus config. This is the big one. If the question is about performance, use cloud watch. If the question is about who did what? Use cloud trial. If the question is about configuration changes or compliance, use config. Don't conflate them because they are all monitoring. Trapped number two, cloud watch doesn't track RAM on EC2 by default. AWS publishes CPU network and disk metrics out of the box, but not memory. Memory requires cloud watch unified agent. If a question asks how to monitor RAM, the answer involves installing the unified agent and publishing custom metrics. Trapped number three, cloud trail is enabled by default. You don't need to enable it. The question might describe a scenario where you need API logging and ask how to enable it. The answer might be that it's already enabled. You just need to configure where to send that data to. Trapped number four, cloud trail 90 day retention. Cloud trail stores events for 90 days. If a question asks about long term retention of API logs, the answer is to log them to S3 and use Athena for querying. Don't pick cloud trail alone for compliance scenarios requiring years of audit data. Trapped number five, config doesn't prevent it detects. If a question asks how to prevent users from creating non-compliant resources, config is definitely not the answer here. You need IAM policies or service control policies for prevention. Config detects after the fact and can remediate, but it doesn't deny. Trapped number six, composite alarms reduce alarm noise. If a question describes wanting to alert only when multiple conditions are true simultaneously, the answer is to use composite alarms with and logic, not multiple separate alarms. Trapped number seven, status check distinction. If the question is about hardware failure under your EC2 instance, that's the system status check and the answer is automatic recovery. If the question is about the operating system inside the instance, that's the instant status check and recovery won't help you. Trapped number eight, cloud watch logs insights versus subscriptions. If the question is about querying historical logs to find something specific, you want to use logs insights. If the question is about real time processing of new log events, you want to use subscriptions. Insights is for querying, subscriptions is for streaming. Do remember that. Trapped number nine, data events are not logged by default in cloud trial. If a question asks about auditing s3 object access or lambda invocations, you need to explicitly enable data events. They're off by default because of the cost. Trapped number 10, even bridge equals cloud watch events. If you see cloud watch events anywhere, that's the all name for even bridge. They are basically the same service. Trapped number 11, long retention. Cloud watch logs default retention is forever. If a question asks how to control log storage costs, the answer is configuring appropriate retention policies on log groups. One day to 10 years or never expire. Trapped number 12, finally, aggregating logs for multiple accounts. If a question describes needing to centralize logs from multiple AWS accounts, the answer is cloud watch logs subscription filters with cross account destinations, sending to a central account's kinases data streams or kinases data firewalls. Now onto our final section here. Let me give you the rapid fire summary to lock all of what we've talked in. Cloud watch is a central monitoring platform. Matrix, logs, alarms, dashboards, every AWS service publishes metrics automatically. For RAM and other OS level metrics, install the cloud watch unified agent. Cloud watch logs have log groups containing log streams. Set retention policies to control costs, insights for querying subscriptions for real time streaming, S3 export for bulk archival. Cloud watch alarms have three states. Okay, alarm insufficient data. Actions include easy to actions, auto scaling actions and SNS notifications. Composite alarms combine multiple alarms with ads or or logic. Metric filters convert log patterns into alarm bill metrics. Cloud trail is enabled by default, records all the AP calls, management events are on by default, data events are off. There's a 90 day retention in cloud trial. You use S3 for longer retention. AWS config tracks resource configurations over time. It's a per region service. Rules detect compliance. They don't prevent auto remediation via SSM automation documents can be used. So for the decision framework, performance and metrics question, think cloud watch. Who did what question? Think cloud trial. What's the configuration and is it a complying question? Then think config need to monitor RAM on EC2. Then think cloud watch unified agent. You need real time log processing. Then think log subscriptions. If you need historical log queries, then think logs insights. If you need to alert on combined conditions, then think composite alarms. Alrighty, that is episode 15 right there on monitoring and observability. We covered a lot today. We started with the role of monitoring and observability in operating AWS environments. We don't deep into cloud watch metrics, including custom metrics for things like RAM that AWS doesn't track by default. We explored cloud watch logs in details. That's log groups, log streams, retention policies, sources and how to use insights and subscriptions for the different use cases. We then covered cloud watch alarms thoroughly, including composite alarms, EC2 recovery and metric filters. We briefly revisited even bridge since it's very closely related to monitoring. We then took a deep dive into cloud trial for APA auditing. The difference between management and data events, the 90 day retention limit and the integration patterns with event bridge. We then explored AWS config for compliance tracking and the most important point that config detects but doesn't prevent. And we built a clear mental model for critical comparison of cloud watch versus cloud trail versus config. So your big takeaway is that these three services answer different questions. Cloud watch tells you how your system is performing. Cloud trial tells you who did what and config tells you the configuration state of your resources. But together they give you complete observability of your AWS environment. We have now completed 15 main episodes covering core of SAAC03 material. You have a really comprehensive foundation here of compute storage, databases networking, serverless messaging, content delivery and now your monitoring. The pieces are all coming together. If this episode helped cloud watch cloud trail and config finally click for you, please do consider to leave a feister rating for this episode and share it with anyone studying for the AWS exam. It genuinely helps this channel grow. So until next time, keep monitoring, keep building and I will see you in the next episode. This is Balu signing off. Bye.