Backup Concepts and Security Best Practices

This lesson doesn't introduce brand-new services — it pulls together principles this course has built up across many earlier modules, now viewed as an operational security review rather than as separate topics:

• Least privilege and IAM roles (Module 2, extended throughout Modules 7–9): every identity — human or workload — should be granted only the specific permissions its task requires. Prefer roles and temporary credentials over long-lived access keys wherever possible, and never use the root account for everyday application operations.
• Security Groups and network boundaries (Module 6): traffic should only be allowed from where it genuinely needs to come from — a database's Security Group referencing its application tier's Security Group specifically, never opened broadly "to avoid connectivity issues."
• The Shared Responsibility Model (Module 1): AWS secures the underlying infrastructure, but the customer remains responsible for IAM configuration, application security, data classification, network configuration, secrets, and their own code — and exactly how much shifts to AWS depends on how managed a given service is, not a fixed, identical split across every service.

This is the practical value of thinking in layers: a mistake or gap in one layer is less likely to become a full incident if the other layers are also sound. This doesn't mean adding every possible control everywhere — it means being deliberate about which layers actually apply to a given resource, and not skipping one just because another layer feels sufficient on its own.

It's worth stating explicitly why backup belongs in this lesson alongside security topics rather than being assumed to already be covered by them: encryption protects data from being read by the wrong party; monitoring helps you notice a problem; neither one helps you recover from data being lost, corrupted, or mistakenly deleted. That's backup's job specifically — Module 5 already introduced this distinction for databases (Backup ≠ High Availability); the same logic applies broadly here: a well-encrypted, well-monitored, well-permissioned system can still lose data to a mistake, and only a genuine backup strategy recovers from that.

One last distinction worth making explicit, tying this module's two halves together: monitoring provides visibility; it does not itself prevent a security incident. A CloudWatch alarm can tell you an application's error rate spiked — that's an availability signal, not automatically evidence of a security compromise. Conversely, a security control like a tightly-scoped IAM policy can be entirely correct and still leave a problem unnoticed if nothing is watching for it. Some real incidents involve both an availability problem and a security concern together; others involve only one. Don't assume the two are the same signal, and don't rely on either one to cover for the other.

A simple, beginner-friendly incident-thinking sequence worth internalizing: Detect (an alarm fires, or something looks wrong) → Investigate (check metrics, logs, recent deployments, and — if an unexpected AWS configuration change is suspected — CloudTrail) → Contain/Correct (stop the immediate problem, fix the underlying cause) → Learn (understand why it happened, to reduce the chance of it recurring). This is not digital forensics — it's a basic, disciplined habit of not skipping straight from "something's wrong" to "we fixed it" without actually understanding what happened.