Day 21 covered who can access what (IAM) and how multiple accounts are governed (Organizations). Today's five services answer a different question entirely: once your infrastructure is running, how do you actually know what's happening inside it — what's misconfigured, what's vulnerable, what's healthy, who did what, and what changed? Each of these services answers one specific version of that question, and together they form the operational backbone of running AWS responsibly rather than just deploying and hoping.
AWS Trusted Advisor
Trusted Advisor is AWS's built-in advisor — it scans your account and gives you recommendations across five categories: cost optimization (idle or underutilized resources you're paying for), performance (things like over-provisioned instances or services approaching their limits), security (open security groups, missing MFA, exposed access keys), fault tolerance (single points of failure, missing backups, resources not spread across AZs), and service limits (approaching a hard AWS quota that could block you from scaling further). Think of it as an automated consultant constantly looking over your shoulder for things you're doing suboptimally, without you having to ask.
On the free Basic Support tier, you get a limited set of core checks — the notes mention 5 free checks — enough to catch some genuinely important issues, like a wide-open security group or a root account without MFA enabled. The full set of checks, which runs into the dozens and covers much deeper cost and performance analysis, unlocks with Business or Enterprise support plans. Even at the free tier, it's worth checking in on periodically — the security checks alone are often worth acting on immediately, since they tend to flag the kind of misconfiguration that leads directly to a real incident.
AWS Inspector
Inspector is a vulnerability management service — it inspects your AWS environment and tells you about security issues, specifically around known, documented vulnerabilities. It automatically and continuously scans three types of resources: EC2 instances (checking installed software packages against known vulnerabilities and looking at network reachability — is a vulnerable port actually exposed to the internet, not just present), container images in ECR (scanning layers for vulnerable packages before or after you deploy them), and Lambda functions (checking function code and dependencies for known issues).
The scanning itself cross-references against CVEs (Common Vulnerabilities and Exposures) — the industry-standard public database of documented software vulnerabilities. The real value here isn't the initial scan; it's that Inspector is continuous. As new CVEs get published — which happens constantly — Inspector automatically re-evaluates your existing, already-deployed resources against them. That means you find out about a vulnerability discovered in a package you deployed six months ago, not just at the moment you originally deployed it. Inspector also assigns a risk score to findings, which helps prioritize what to actually fix first instead of facing an undifferentiated wall of alerts.
Amazon CloudWatch
CloudWatch is used to monitor all AWS resources — EC2, ELB, S3, RDS, and effectively everything else — by tracking their metrics: CPU utilization, network traffic, disk activity, request counts, memory usage, and more, depending on the specific service.
The core workflow is alarm-based. You define alarms against specific metrics — for example, "alert me if CPU utilization stays above 80% for 5 minutes." When that threshold is breached, the alarm state changes (from OK to ALARM), and that state change is what actually triggers something. You can get notified by SMS or email by integrating CloudWatch with SNS (Simple Notification Service). Alarms aren't limited to notifications either — they can trigger real infrastructure actions, most notably scaling an Auto Scaling Group up or down, which ties directly back to the elasticity mechanics from Day 13: CloudWatch is often the actual thing watching the metric that an Auto Scaling target-tracking policy reacts to.
Two tiers of monitoring control how quickly you actually notice a problem: basic monitoring gives you a data point every 5 minutes and is free; detailed monitoring gives you a data point every 1 minute but is billable. The difference matters more than it sounds — a traffic spike or resource issue that lasts only 2-3 minutes could be completely invisible on basic monitoring's 5-minute granularity, showing up as barely a blip (or not at all) in the averaged data, while detailed monitoring would catch it clearly.
Beyond metrics and alarms, CloudWatch has a few other components worth knowing:
- CloudWatch Logs centralizes log storage and searching for your applications and AWS services — instead of SSHing into individual instances to tail log files, your applications ship logs to CloudWatch and you search them centrally, including setting up metric filters that turn specific log patterns into their own trackable metrics.
- CloudWatch Dashboards are customizable visual views combining metrics from multiple services into a single at-a-glance operational view — useful for an ops team that wants one screen showing overall system health instead of clicking through a dozen individual service consoles.
- CloudWatch Events/EventBridge (which we actually covered back on Day 14) is closely related — CloudWatch traditionally handled scheduled and reactive triggers before that functionality was expanded into the standalone EventBridge service.
AWS CloudTrail
Where CloudWatch tells you how your resources are performing, CloudTrail tells you who did what. It tracks your entire AWS environment by recording, monitoring, tracking, and auditing activity — specifically, every API call made in your account gets logged, including which IAM user or role made it, from what IP address, at what time, and what the actual request and response looked like.
This is essential for both security auditing and plain operational troubleshooting: if a resource gets deleted unexpectedly, or a security group gets modified in a way that shouldn't have happened, CloudTrail is what tells you exactly which identity made that specific API call and when — turning "something changed and nobody knows why" into a five-minute lookup instead of a mystery.
By default, AWS keeps a rolling 90-day event history you can search immediately with zero setup. For longer retention, more structured analysis, or integration with other tools, you create a trail, which delivers logs continuously to an S3 bucket (and optionally CloudWatch Logs), where they can be retained indefinitely and queried with tools like Athena.
A distinction worth knowing: CloudTrail separates management events (control-plane actions — creating an EC2 instance, deleting an S3 bucket, modifying an IAM policy) from data events (data-plane actions — reading or writing an individual object inside an S3 bucket, invoking a specific Lambda function). Management events are logged by default at no extra cost. Data events, being vastly higher in volume in any active system, need to be explicitly enabled if you want that level of granular detail, and typically cost more to log as a result.
AWS Config
Config rounds out the picture by answering yet another distinct question: what changed, and is it compliant? It continuously monitors the configuration of your AWS resources — not just that an action happened (that's CloudTrail's job) but the actual resulting state of the resource — and keeps a detailed configuration history over time. If anyone modifies a resource's configuration, Config records exactly what changed, when, and what the configuration looked like both before and after, giving you a browsable timeline for any tracked resource.
Beyond just tracking history, Config's more actionable feature is Config Rules — you define what a compliant configuration actually looks like (for example, "all S3 buckets must have encryption enabled," or "all EBS volumes must be encrypted"), and Config continuously evaluates your real resources against that rule, flagging each one as compliant or non-compliant in something close to real time as configurations drift. Some rules go a step further and support automated remediation — instead of just alerting a human, Config can trigger a Lambda function or SSM automation document that actually fixes the non-compliant configuration automatically, closing the loop without manual intervention.
How they fit together
Each of these looks at your AWS environment through a genuinely different lens, and together they cover a full operational picture: Trusted Advisor tells you what you should fix based on best practices, Inspector tells you what's vulnerable, CloudWatch tells you how things are performing right now, CloudTrail tells you who did what, and Config tells you what changed and whether it's still compliant. None of them substitute for the others — a mature AWS setup genuinely runs all five together, because each one would miss something the others catch.
Quick Recap Questions
- What's the difference between what CloudWatch monitors and what CloudTrail tracks?
- Why does the difference between basic and detailed CloudWatch monitoring actually matter in practice?
- What's the difference between a CloudTrail management event and a data event, and why are they treated differently?
- How is AWS Config different from CloudTrail, if both involve "tracking changes" in some sense?
- Why does Inspector's continuous re-scanning matter more than a one-time scan at deployment?
Where to read & follow
- Hashnode: https://sr-palatasingh.hashnode.dev/series/aws-devops-blog
- GitHub: https://github.com/sr-palatasingh/AWS-DevOps-Blog/tree/main/posts
- LinkedIn: https://www.linkedin.com/in/soumyaranjan-palatasingh/
Coming up next
| Day | Topic | Services |
|---|---|---|
| 23 | Security | Encryption (ACM/KMS), Secrets Manager, AWS Backup, WAF, AWS Shield |
Top comments (0)