15. Security Architecture
Security Architecture
TL;DR
- Security architecture spans three categories: preventive (IAM, encryption, security groups), detective (GuardDuty, Inspector, Macie, Detective, Security Hub), and responsive (routing findings to action). Most designs only cover the first.
- KMS is the default for key management; CloudHSM is a compliance-driven exception (e.g., specific FIPS 140-2 Level 3 requirements), not a general upgrade.
- Security Hub aggregates and scores findings from GuardDuty/Inspector/Macie against compliance standards — it doesn’t replace them.
- Secret rotation in Secrets Manager only protects if the consuming application actually re-fetches and handles AWSCURRENT/AWSPENDING correctly — configuring rotation is not the same as testing it.
- WAF (Layer 7 filtering) and Shield Advanced (network/transport DDoS) defend against different threat classes and are typically deployed together, not as alternatives.
Core Concepts
The three-layer model: preventive, detective, responsive
A design that is strong on prevention (IAM scoping, encryption, tightly scoped security groups) but has no detection or response plan is incomplete. Prevention assumes nothing ever slips through — not a bet a mature security program makes. Detection without a routed, monitored response path is close to worthless: a finding sitting in a console that nobody reviews until a quarterly audit provides no real protection during the months between reviews.
IAM as the foundation
Least privilege, no long-lived credentials for workloads, and ABAC at scale underpin every other control in this module. Reviewing detection tooling before confirming the identity layer is solid means reviewing the wrong layer first.
KMS vs CloudHSM
KMS handles key management for the vast majority of workloads: managed, multi-tenant, deeply integrated across AWS services. CloudHSM provides dedicated, single-tenant hardware security modules and exists specifically for compliance regimes (certain FIPS 140-2 Level 3 mandates) that KMS’s shared model cannot satisfy. Reaching for CloudHSM as a default “more secure” option adds real operational burden with no corresponding benefit for workloads without that specific compliance driver.
Secrets Manager rotation
Automated rotation only protects a system if the consuming application correctly adopts the new secret value on schedule. Common failure mode: application code caches a secret indefinitely, or doesn’t correctly handle the AWSCURRENT/AWSPENDING version-staging model during a rotation window, causing an outage the first time rotation actually fires. Enabling rotation is not the finish line — testing that the application survives a rotation event is.
ACM certificate management
TLS certificate issuance and renewal, largely automatic once correctly configured. Manually managing certificate renewal carries real operational risk (an expired cert causing an outage) for no benefit over ACM’s automation.
Detection layer: GuardDuty, Inspector, Detective, Macie
- GuardDuty — threat detection from log and network traffic analysis.
- Inspector — vulnerability scanning for EC2, container, and Lambda workloads.
- Detective — investigates and visualizes blast radius once something is flagged.
- Macie — discovers and classifies sensitive data (PII, credentials) in S3.
Security Hub sits above all four as an aggregation and compliance-posture layer, centralizing findings against standards like CIS or PCI-DSS. It is a consolidation layer, not a replacement for the underlying detection services.
WAF vs Shield Advanced
WAF filters application-layer (Layer 7) threats — SQL injection, XSS, malicious bot traffic — based on configured rules. Shield Advanced provides DDoS protection at the network/transport layer, backed by AWS’s DDoS Response Team for large-scale attacks. These are different threat classes, not redundant coverage of the same one; internet-facing workloads with genuine exposure typically need both.
GuardDuty vs Security Hub vs Inspector vs Macie vs Detective
| Aspect | GuardDuty | Security Hub | Inspector | Macie | Detective |
|---|---|---|---|---|---|
| Function | Threat detection | Aggregation / posture management | Vulnerability scanning | Sensitive-data discovery | Investigation / blast-radius analysis |
| Input | VPC flow logs, DNS logs, CloudTrail | Findings from other services | EC2/container/Lambda scan results | S3 object content | GuardDuty/other findings + logs |
| Output | Threat findings | Consolidated compliance score | CVE/vulnerability list | Sensitive data classification | Visualized investigation graph |
| When to use | Always-on threat monitoring | Centralizing posture across services/accounts | Regular vulnerability audits | S3 buckets with PII/sensitive data | Post-finding root-cause investigation |
KMS vs CloudHSM
| Aspect | KMS | CloudHSM |
|---|---|---|
| Tenancy | Multi-tenant, managed | Single-tenant, dedicated hardware |
| Operational burden | Low | High (customer manages HSM cluster) |
| Compliance fit | Broad (FIPS 140-2 Level 2) | Specific (FIPS 140-2 Level 3, certain regimes) |
| Default choice | Yes, for nearly all workloads | No — exception when compliance demands it |
| AWS service integration | Deep, native | Limited, requires custom integration |
Common Pitfalls
- Pitfall: Strong preventive controls with no detection or response plan. Why: Prevention is easier to design and demo than an end-to-end response workflow. Fix: Explicitly map the design against preventive/detective/responsive and treat any missing category as incomplete.
- Pitfall: GuardDuty/Security Hub findings accumulate unreviewed. Why: No one owns triage, and findings sit in a console rather than routing to an actionable destination. Fix: Route findings through EventBridge to a ticketing system or automated remediation, with clear ownership for critical alerts.
- Pitfall: Secret rotation enabled but never tested against the consuming application. Why: Rotation is treated as a configuration task rather than a behavior that needs validation. Fix: Test a rotation event end-to-end before relying on it in production, and verify version-staging handling in application code.
- Pitfall: CloudHSM adopted for “extra security” without a specific compliance driver. Why: It sounds more secure than KMS. Fix: Use KMS by default; adopt CloudHSM only when a named compliance requirement demands it.
- Pitfall: WAF deployed without Shield Advanced, or vice versa. Why: Mistaken belief that one covers both threat classes. Fix: Deploy both for internet-facing workloads with genuine DDoS and application-layer exposure.
Interview Questions
- An org has GuardDuty enabled but no one reviews findings until a quarterly audit. Walk through the fix, step by step, from finding generation to action. — tests whether detection is understood as needing an operationalized response path, not just an enabled service.
- When would the operational cost of CloudHSM over KMS be justified? — tests whether CloudHSM is understood as a compliance-driven exception, not a default upgrade.
- What’s the actual difference between Security Hub and GuardDuty? — tests whether aggregation/posture management is distinguished from threat detection.
- A secret rotation just broke production. Walk through the root-cause investigation. — tests operational debugging instinct around a common, real failure mode.
- Why are WAF and Shield Advanced usually deployed together rather than as alternatives? — tests whether Layer 7 vs network/transport-layer threat classes are understood as distinct.