Security & Compliance

Why This Phase Exists

Security is not a phase you pass through. It is a lens applied at every layer. Every architecture decision you have made since Phase 1 has had security implications: the VPC subnet placement, the IAM role scope, the encryption setting on an S3 bucket, the security group rule that allows port 443. Those decisions are security decisions, whether you recognized them as such at the time or not.

So why dedicate an entire phase to security services? Because AWS provides purpose-built services that implement security controls at a depth and scale no team could maintain manually. These are not theoretical concepts. They are operational systems that detect threats in real time, enforce policy across hundreds of accounts, manage cryptographic keys without exposing key material, rotate database credentials without application downtime, terminate malicious requests at the edge before they reach your compute layer, and aggregate compliance findings into a single actionable dashboard.

This phase teaches you those dedicated security services. But the Solutions Architect mindset integrates security into every decision from Phase 1 onwards. The network isolation you learned in Phase 2 is a security control. The least-privilege IAM policies from Phase 3 are security controls. The encryption-at-rest you configured in Phase 4 is a security control. Phase 8 gives you the specialized tools, but the security posture of your architecture depends on every phase working together.

The threat landscape is not static. Attackers probe for misconfigured S3 buckets, overly permissive security groups, unrotated credentials, and unencrypted data stores. Compliance frameworks (SOC 2, PCI DSS, HIPAA, FedRAMP) mandate specific controls and evidence of their continuous enforcement. A Solutions Architect who cannot design for security and compliance cannot design for production.

What You Will Master

By the end of Phase 8, you will be able to:

• Design multi-account architectures using AWS Organizations and Control Tower that enforce security boundaries through Service Control Policies and automated guardrails
• Implement encryption strategies using AWS KMS with customer managed keys, envelope encryption, and key rotation policies that satisfy regulatory requirements
• Architect secrets management solutions using Secrets Manager and SSM Parameter Store with automatic rotation and zero-secret-in-code guarantees
• Deploy TLS certificates through ACM with automated renewal and proper certificate chain architecture from edge to origin
• Configure AWS WAF rule sets that protect web applications against OWASP Top 10 threats, bot traffic, and application-layer DDoS
• Implement DDoS protection architectures using Shield Standard and Shield Advanced with automatic response capabilities
• Design threat detection pipelines using GuardDuty and Inspector that surface findings in real time and trigger automated remediation
• Build audit and compliance architectures using CloudTrail, AWS Config, and Config Rules that provide continuous compliance evidence
• Aggregate and prioritize security findings using Security Hub and Audit Manager across multi-account environments

Modules in This Phase

The Progressive Path

This phase follows a deliberate progression from organizational structure down to individual finding management.

Module 52 starts at the highest level: how you structure AWS accounts. A single AWS account is a blast radius. If credentials are compromised in a single-account architecture, the attacker has access to everything. AWS Organizations and Control Tower let you isolate workloads, teams, and environments into separate accounts while enforcing policies centrally. You must understand multi-account architecture before the remaining security services make full sense, because services like GuardDuty, Security Hub, and Config operate across accounts through delegated administrator patterns.

Module 53 drops into encryption. Every data store you have configured throughout this program supports encryption, but until now you accepted default key management. This module teaches you how KMS actually works: the key hierarchy, envelope encryption mechanics, key policies versus IAM policies, and the decision framework for when you need customer managed keys versus AWS managed keys. You will also learn CloudHSM for workloads that require FIPS 140-2 Level 3 validated hardware.

Module 54 addresses the credentials problem. Applications need database passwords, API keys, and tokens. Storing them in environment variables, config files, or (worst) source code creates security debt that compounds over time. Secrets Manager and Parameter Store provide the operational patterns for zero-secret-in-code architectures with automatic rotation.

Module 55 covers TLS certificate management. Every production system requires encryption in transit. ACM provides free public certificates with automated renewal, eliminating the operational burden of certificate management that has caused countless production outages at organizations that manage certificates manually.

Modules 56 and 57 protect your edge. WAF inspects HTTP requests and blocks malicious traffic before it reaches your application logic. Shield absorbs volumetric DDoS attacks that would overwhelm your infrastructure. Together they form the perimeter defense layer.

Modules 58 and 59 provide detection and audit. GuardDuty uses machine learning to identify threats from VPC Flow Logs, DNS logs, and CloudTrail events. Inspector scans EC2 instances and container images for vulnerabilities. CloudTrail logs every API call. Config evaluates every resource against your compliance rules continuously.

Module 60 ties everything together. Security Hub aggregates findings from GuardDuty, Inspector, Config, Firewall Manager, and third-party tools into a single pane. Audit Manager maps those findings to compliance frameworks and generates audit-ready evidence.

Services You Will Command

Governance and Account Structure

• AWS Organizations: Multi-account management, OUs, Service Control Policies, consolidated billing
• AWS Control Tower: Automated landing zone with preventive and detective guardrails
• AWS Resource Access Manager: Cross-account resource sharing without duplication

Data Protection

• AWS KMS: Encryption key management, envelope encryption, key rotation, key policies
• AWS CloudHSM: Dedicated hardware security modules for FIPS 140-2 Level 3 requirements
• AWS Secrets Manager: Secret storage with automatic rotation for databases and APIs
• AWS Systems Manager Parameter Store: Hierarchical configuration and encrypted parameter storage
• AWS Certificate Manager: TLS certificate provisioning, deployment, and automated renewal
• ACM Private CA: Internal certificate authority for service-to-service mTLS

Perimeter Protection

• AWS WAF: Web application firewall with managed and custom rule groups
• AWS Firewall Manager: Centralized WAF and Shield policy management across accounts
• AWS Shield Standard: Automatic Layer 3/4 DDoS protection (included with all AWS accounts)
• AWS Shield Advanced: Enhanced DDoS protection with DRT access, cost protection, and health-based detection

Detection and Response

• Amazon GuardDuty: Intelligent threat detection from log analysis and ML
• Amazon Inspector: Automated vulnerability scanning for EC2 and container images
• AWS CloudTrail: API activity logging for audit and forensics
• AWS Config: Continuous resource compliance evaluation

Aggregation and Compliance

• AWS Security Hub: Centralized security finding aggregation and automated response
• AWS Audit Manager: Continuous audit evidence collection mapped to compliance frameworks

Security Architecture Model

The SA mindset approaches security as a system of interlocking controls, not a checklist of services to enable. Each layer in the model below addresses a distinct threat category. The strength comes from the overlap: if an attacker bypasses WAF through a zero-day exploit, the IAM role on the compromised service limits lateral movement. If credentials leak despite Secrets Manager rotation, CloudTrail and GuardDuty detect anomalous usage patterns. No single layer is expected to be impenetrable. The architecture assumes breach at every layer and designs containment accordingly.

A properly secured AWS architecture applies controls at every layer:

                        ┌─────────────────────────────────┐
                        │    AWS Organizations / SCPs      │  ← Account-level guardrails
                        └─────────────────────────────────┘
                                       │
                        ┌─────────────────────────────────┐
                        │   Shield + WAF (Edge Layer)      │  ← DDoS + App-layer filtering
                        └─────────────────────────────────┘
                                       │
                        ┌─────────────────────────────────┐
                        │   VPC + Security Groups + NACLs  │  ← Network isolation
                        └─────────────────────────────────┘
                                       │
                        ┌─────────────────────────────────┐
                        │   IAM Roles + Secrets Manager    │  ← Identity + credential mgmt
                        └─────────────────────────────────┘
                                       │
                        ┌─────────────────────────────────┐
                        │   KMS Encryption + ACM TLS       │  ← Data protection (rest + transit)
                        └─────────────────────────────────┘
                                       │
                        ┌─────────────────────────────────┐
                        │   CloudTrail + GuardDuty + Config │  ← Detection + compliance
                        └─────────────────────────────────┘
                                       │
                        ┌─────────────────────────────────┐
                        │   Security Hub + Audit Manager   │  ← Aggregation + evidence
                        └─────────────────────────────────┘

Each layer operates independently but contributes to the overall security posture. A compromise at one layer is contained by the layers below it. This is defense in depth implemented through dedicated AWS services rather than custom code.

How the model maps to compliance frameworks:

This phase does not teach compliance frameworks directly. It teaches the AWS services that implement the technical controls those frameworks require. When an auditor asks "how do you ensure encryption at rest," your answer references KMS key policies, not a bullet point in a compliance document.

Architecture Context

Phase 8 protects everything you have built in Phases 1 through 7. The VPCs from Phase 2 sit inside accounts governed by Organizations SCPs from Module 52. The S3 buckets and EBS volumes from Phase 4 are encrypted with KMS keys from Module 53. The database credentials your applications use are stored in Secrets Manager from Module 54. The ALBs and CloudFront distributions from Phase 3 present ACM certificates from Module 55 and are protected by WAF rules from Module 56. The EC2 instances and containers from Phases 4 and 5 are scanned by Inspector from Module 58. Every API call across every phase is logged by CloudTrail from Module 59.

The CI/CD pipelines from Phase 7 integrate directly with security services: CodeBuild retrieves secrets from Secrets Manager, CodePipeline gates deployments on Security Hub findings, CloudFormation templates define Config rules alongside infrastructure, and CDK constructs encode security best practices as reusable components.

Looking forward, security is a continuous operational concern. The monitoring and alerting infrastructure from Phase 6 (CloudWatch, SNS) drives automated response to security findings. EventBridge rules trigger Lambda functions that remediate non-compliant resources detected by Config. Step Functions orchestrate multi-step incident response workflows. Security is not separate from operations. It is operations.

Phase Exam

After completing all nine modules, you will take the Phase 8 Security & Compliance exam:

• 35 multiple-choice questions covering multi-account governance, encryption architecture, secrets management, certificate lifecycle, WAF rule design, DDoS protection, threat detection, audit configuration, and security aggregation
• 55 minutes time limit
• 70% pass threshold (25/35 correct)
• Questions emphasize architectural decisions: when to use customer managed keys vs AWS managed keys, how to structure OUs for blast radius containment, which rotation strategy fits a given database topology, where to terminate TLS in a multi-tier architecture, and how to aggregate findings across a multi-account organization
• Expect scenario-based questions that present a security requirement (compliance framework, threat model, operational constraint) and ask you to select the correct service combination, configuration, or architecture pattern
• KMS key policies, SCP deny patterns, WAF rule priority, GuardDuty finding types, Config rule evaluation modes, and Security Hub integration patterns are heavily represented