Thursday, May 7, 2026
Cohort 3 | Project CloudIgnite Topics: AWS CloudTrail, AWS Config, Incident Response & Disaster Recovery Duration: ~3 hours
📌 Legend: Items marked with ☁️ are directly relevant to the AWS Certified Cloud Practitioner (CLF-C02) exam.
Key Takeaways
- AWS CloudTrail: "CCTV for AWS" — logs who, when, what, where for every API call; stored in S3
- AWS Config: compliance monitoring — checks resource configs against rules; alerts via SNS on non-compliance
- CloudTrail vs Config: CloudTrail = who did what (API audit); Config = is my config compliant (state monitoring)
- Incident response: Stop → Inspect → Notify → Remediate → Prevent
- DR metrics: RTO (max downtime), RPO (max data loss); cost increases as RTO/RPO decrease
- DR strategies: Backup & Restore (cheapest) → Pilot Light → Active-Passive → Active-Active (most expensive)
- Lab 280: AWS Network Firewall — blocked malicious URLs using Suricata stateful rules in VPC
1. AWS CloudTrail ☁️
What is CloudTrail?
- An auditing and monitoring service that records API requests made to AWS services (think of it as CCTV for your AWS account).
- Monitors resources such as EC2, S3, and RDS and generates log files.
- Not a system hardening tool, but can be integrated with hardening workflows.
What Does CloudTrail Record?
Each log entry captures:
- Who made the request (IAM user identity, ARN, account ID)
- When the event occurred
- What action was performed (event name)
- Where it occurred (AWS region)
- How the request was made (source IP address, API method)
- Response to the request
Log Storage
- Logs are stored in Amazon S3 in compressed JSON format (
.gzfiles — extract to get the JSON). - A dedicated S3 bucket should be used exclusively for CloudTrail logs.
- Logs are sent approximately every 15 minutes and can grow very rapidly.
- Retention is configurable — common requirements:
- General monitoring: 30 days
- Company/regulatory: 6 months – 1 year
- Financial/banking: 7+ years (use S3 lifecycle policies to move old data to cheaper storage tiers)
⚠️ Infinite Loop Warning
If CloudTrail monitors the same S3 bucket it writes logs to (without exclusion), it creates an infinite loop:
CloudTrail writes to S3 → S3 fires an event → CloudTrail records that event → writes to S3 again → ...
Fix: Exclude the CloudTrail log bucket from being monitored, or use a separate dedicated bucket.
CloudTrail Best Practices ☁️
| Best Practice | Notes |
|---|---|
| Enable log file integrity validation | Detects if logs have been tampered with |
| Aggregate logs into a single S3 bucket | Even across multiple accounts/regions |
| Enable globally across all regions | Ensures no activity goes unrecorded |
| Restrict the log bucket from public access | Only authorized personnel should access/delete logs |
| Integrate with Amazon CloudWatch | CloudWatch can monitor and react to events recorded in CloudTrail |
Pricing
- Not completely free — event history is free, but features like data events, Lambda insights, and CloudTrail Insights are paid.
CloudTrail vs CloudWatch
| CloudTrail | CloudWatch |
|---|---|
| Records API calls and user/resource events | Monitors metrics: CPU, network traffic, etc. |
| Auditing & compliance | Performance monitoring & alerting |
| Integrates with CloudWatch for reaction | Can trigger alarms based on CloudTrail events |
2. AWS Config ☁️
What is AWS Config?
- A security configuration and compliance monitoring service.
- Continuously monitors your AWS resource configurations against a defined baseline/rulebook.
- Detects non-compliance in real time and sends alerts.
- Think of it as an automated compliance officer for your AWS account.
Why Use AWS Config?
CloudTrail records who did what, but AWS Config answers: "Is my environment still configured correctly?"
Example: If a password policy should require 10 characters but someone changes it to 8, CloudTrail won't alert you — AWS Config will.
What Can AWS Config Monitor?
- IAM user password policies
- S3 bucket public access settings
- EC2 instance public IP assignments
- EBS volume encryption status
- Any configuration change across all AWS resources
How AWS Config Works
- A configuration change occurs on a resource.
- AWS Config detects and records the change to an S3 bucket.
- It evaluates the change against your predefined rules.
- If a rule is violated, it sends a notification via Amazon SNS (Simple Notification Service).
- A change history is maintained for audit purposes.
AWS Config Capabilities ☁️
- Discover resources — inventory of all AWS resources, including deleted ones.
- Evaluate configuration changes — checks against your rulebook continuously.
- Detect and alert — fires notifications on non-compliance.
AWS Config Rules
- Use AWS-managed rules (pre-built by AWS) or custom rules.
- Custom rules can be created using AWS Lambda.
- Rules are evaluated automatically when a configuration changes.
- A dashboard in the management console shows findings and compliance status.
Example Security Rules
| Rule | What It Checks |
|---|---|
| IAM password policy | Min length, complexity requirements |
| S3 bucket public access | Flags if a bucket is made public |
| EC2 public IP | Checks if instances have public IPs |
| EBS encryption | Ensures volumes are encrypted |
Access Control for AWS Config
- Only high-authority users (e.g., admins, CEO/CTO) should have access to AWS Config settings — enforced via IAM policies.
AWS Config vs CloudTrail
| AWS Config | CloudTrail |
|---|---|
| What is the current/past configuration? | Who made this API call? |
| Compliance & policy enforcement | Auditing & forensics |
| Reacts to configuration state changes | Reacts to any API event |
3. Incident Response ☁️
Response Framework (Analogy: Flat Tyre)
Like getting a flat tyre on the road:
- Stop the affected service/instance (contain the blast radius)
- Inspect — investigate what happened
- Notify stakeholders (team, affected users/customers)
- Remediate — fix the issue
- Prevent — find the root cause and implement measures to stop recurrence
Incident Response Flow
Malicious Event Detected
↓
Investigate the Event
↓
Respond & Remediate
↓
Notify Stakeholders
↓
Prevent Future Occurrence
4. Business Continuity & Disaster Recovery ☁️
Key Concepts
BCP — Business Continuity Plan
- How will you continue critical operations during or after an attack/disaster?
- May run at reduced capacity, but critical systems must stay operational.
DRP — Disaster Recovery Plan
- How will you recover after a disaster (e.g., data centre destroyed by earthquake)?
- Typically involves backups, replication, and redundant infrastructure in another region.
Recovery Metrics ☁️
| Metric | Full Name | What It Means |
|---|---|---|
| RTO | Recovery Time Objective | Maximum tolerable downtime — how long can your system be offline? |
| RPO | Recovery Point Objective | Maximum tolerable data loss — how much data can you afford to lose? |
| WRT | Work Recovery Time | Time needed to restore full service after the system is back online |
Maximum Tolerable Downtime = RTO + WRT
RPO Example:
- Backups taken every hour. Disaster strikes at 9:59 PM (backup was at 9:00 PM).
- You lose 59 minutes of data → this is your RPO in the worst case.
Cost vs RTO/RPO Trade-off:
- Minimising RTO and RPO increases cost.
- Longer tolerated downtime/data loss = lower infrastructure cost.
- Zero downtime is practically impossible (even for Google/Facebook).
Disaster Recovery Options ☁️
| Strategy | Description | Cost |
|---|---|---|
| Backup & Restore | Periodic backups; restore when needed | Lowest |
| Pilot Light | Minimal standby environment always running in another region | Medium |
| Active-Passive | Full standby environment; traffic switched on failure | Higher |
| Active-Active | Both environments serve traffic simultaneously | Highest |
Pilot Light Example:
- Run a 10–25% capacity server in a secondary region (e.g., Singapore + Australia).
- In a disaster, redirect all traffic to the secondary region.
- Databases and EBS must be fully replicated (you pay twice for storage).
- EC2 can run at reduced capacity to save cost.
- Elastic Load Balancing + Auto Scaling are critical for this to work effectively.
5. AWS Network Firewall (Lab 280) ☁️
Concepts Covered in Lab
- Network Firewall is configured inside VPC.
- Uses stateful rule groups for inspecting traffic (stateful = if inbound is allowed, outbound is automatically allowed).
- Rules are written in Suricata-compatible rule string format.
- Stateless (like NACLs) evaluates inbound and outbound independently.
Lab Objective
Block downloads from specific malicious URLs using AWS Network Firewall.
Key Steps
- Connect to EC2 instance via SSM Session Manager.
- Verify you can download files from target URLs (wget).
- Edit the stateless default action → forward all packets to stateful rule group.
- Create a stateful rule group using Suricata rule syntax to drop matching HTTP packets.
- Associate the rule group with the firewall policy.
- Re-test downloads — requests should now time out (packets are blocked).
Notes
- The lab only blocked HTTP (port 80), not HTTPS (port 443) — a separate rule is needed for HTTPS.
- You can also block by IP range or specific domains (e.g., github.com).
- Rules may take a short time to propagate after saving.
6. Upcoming Schedule (as of May 7)
| Day | Plan |
|---|---|
| Tomorrow (May 8) | Finish Security module (Analysis topic + lab), 1 lab |
| Monday (May 12) | Finish Security module before break, start Python after break |
| This Saturday | Catch-up session — complete all pending labs from previous sessions (starts 2 PM) |
Python Module Preview
- 67 slides for introduction alone + many labs (possibly 80+ labs total).
- Focus areas: Python syntax, task automation, and AWS Lambda.
- Recommended version: Python 3.11+ (instructor uses 3.14.4).
- No Django — pure Python and AWS integration.
- Install Python before Monday (straightforward on Windows/Mac/Linux). VS Code recommended.
☁️ CLF-C02 Exam Relevance Summary
The following topics from this lecture are covered in the AWS Certified Cloud Practitioner (CLF-C02) exam:
| Topic | Exam Domain |
|---|---|
| AWS CloudTrail — purpose, what it logs, where logs are stored | Domain 2: Security & Compliance |
| AWS Config — compliance monitoring, rules, SNS notifications | Domain 2: Security & Compliance |
| CloudWatch integration with CloudTrail | Domain 2: Security & Compliance |
| IAM best practices (least privilege, access control to Config) | Domain 2: Security & Compliance |
| Disaster Recovery concepts: RTO, RPO, BCP, DRP | Domain 4: Billing, Pricing & Support / Domain 3: Cloud Technology |
| DR strategies: Backup & Restore, Pilot Light, Active-Active | Domain 3: Cloud Technology & Services |
| AWS Network Firewall (VPC-level traffic inspection) | Domain 2: Security & Compliance |
| S3 storage tiers & lifecycle policies (for log retention) | Domain 3: Cloud Technology & Services |
💡 Tip for exam prep: CloudTrail and AWS Config are frequently tested together — know the difference. CloudTrail = who did what (API audit). Config = is my config compliant (state monitoring).
Notes compiled from lecture — May 7, 2026 | Forward College