After this lesson, you will be able to: Operate AWS safely: observe with CloudWatch and X-Ray, protect workloads with Secrets Manager, KMS, WAF, and Shield, and detect threats with CloudTrail and GuardDuty.
Deploying to AWS is half the job; knowing what your system is doing and keeping it secure is the other half. CloudWatch and X-Ray are how you see inside a running system. Secrets Manager, KMS, WAF, and Shield are the managed services that keep secrets out of code and attackers out of your app. These are the topics AWS certifications weight heavily and that real on-call engineers live in.
CloudWatch is the central observability service: Logs (every Lambda and many services stream logs here), Metrics (CPU, request count, custom business metrics), Alarms (notify or auto-scale when a metric crosses a threshold), and Dashboards. X-Ray adds distributed tracing: it follows a single request across API Gateway, Lambda, and DynamoDB so you can see exactly which hop was slow. The on-call workflow is: an alarm fires, you open the relevant CloudWatch dashboard and logs, and use an X-Ray trace to localize the slow or failing component. This is the AWS-native version of the reliability and observability ideas from System Design.
Alarms turn a metric crossing a threshold into an action (notify, page, or auto-scale).
resource "aws_cloudwatch_metric_alarm" "api_5xx" {alarm_name = "api-5xx-too-high"comparison_operator = "GreaterThanThreshold"evaluation_periods = 2metric_name = "5XXError"namespace = "AWS/ApiGateway"period = 60statistic = "Sum"threshold = 10alarm_actions = [aws_sns_topic.alerts.arn] # page the on-call}// Fires when the API returns >10 server errors in two consecutive minutes,// then publishes to an SNS topic that emails/pages the on-call engineer.
Secrets Manager stores database passwords, API keys, and tokens encrypted, with fine-grained IAM access and automatic rotation (it can rotate an RDS password on a schedule without downtime). Your app fetches the secret at runtime via the SDK instead of reading it from an environment variable baked into an image (the anti-pattern from the Docker security lesson). KMS (Key Management Service) is the managed encryption-key service underneath: it holds the keys used to encrypt S3 objects, EBS volumes, RDS storage, and Secrets Manager itself, with access controlled by IAM and every use logged. The principle: secrets live in Secrets Manager, encryption keys live in KMS, and neither lives in your code.
CloudTrail records every API call made in your account (who did what, when, from which IP), which is the audit log you need for forensics and compliance: who deleted that bucket, who changed that IAM policy. Enable it in every account and send the trail to a locked-down S3 bucket so it cannot be tampered with. GuardDuty is managed threat detection: it continuously analyzes CloudTrail, VPC flow logs, and DNS logs with AWS threat intelligence and machine learning, then raises findings like 'an EC2 instance is talking to a known crypto-mining host,' 'credentials are being used from an unusual location,' or 'an S3 bucket was made public.' You turn it on with a click (no agents) and route findings to CloudWatch Events / EventBridge so a Lambda or your on-call gets notified. CloudTrail answers 'what happened?'; GuardDuty answers 'is something suspicious happening right now?'
No CloudWatch alarms, so you learn about outages from users instead of from a page. Alarm on error rate and latency at minimum. Reading secrets from baked-in environment variables instead of Secrets Manager, then leaking them in an image or repo. Logging the secret or the full request body to CloudWatch, recreating the leak inside your logs. Assuming Shield Standard or a WAF is on by default with custom rules; Standard DDoS is automatic, but WAF rules are something you configure. Letting CloudWatch Logs retain forever, which quietly becomes a large bill. Set retention per log group.
Pick the correct option.
Sign in and purchase access to unlock this lesson.