Week Content

Opening Framing

This capstone week brings together everything you've learned throughout CSY302. Cloud security isn't about checking boxes or implementing individual controls in isolation—it's about designing coherent architectures where security is built into every layer, where controls reinforce each other, and where the overall system is greater than the sum of its parts.

You've learned about shared responsibility, identity and access management, network security, data protection, compute hardening, container security, serverless protection, monitoring, IaC security, incident response, and multi-cloud considerations. Now you'll synthesize these into complete, production-ready architectures that address real-world requirements.

This week covers security architecture principles, the AWS Well-Architected Framework security pillar, reference architectures, threat modeling for cloud, and a comprehensive capstone project where you design a secure cloud environment from scratch. You'll demonstrate mastery of cloud security by creating architectures that would pass real-world security reviews.

Key insight: Great security architecture makes secure choices the default and insecure choices require explicit exception.

1) Security Architecture Principles

Foundational principles guide consistent security decisions across all architectural choices:

Core Security Architecture Principles:

DEFENSE IN DEPTH:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│   ┌─────────────────────────────────────────────────────┐   │
│   │ Perimeter: WAF, DDoS Protection, Edge Security      │   │
│   │ ┌─────────────────────────────────────────────────┐ │   │
│   │ │ Network: VPC, Security Groups, NACLs, Firewall │ │   │
│   │ │ ┌─────────────────────────────────────────────┐ │ │   │
│   │ │ │ Identity: IAM, Federation, MFA, PAM        │ │ │   │
│   │ │ │ ┌─────────────────────────────────────────┐ │ │ │   │
│   │ │ │ │ Application: Input validation, AuthZ   │ │ │ │   │
│   │ │ │ │ ┌─────────────────────────────────────┐ │ │ │ │   │
│   │ │ │ │ │ Data: Encryption, Access Control   │ │ │ │ │   │
│   │ │ │ │ └─────────────────────────────────────┘ │ │ │ │   │
│   │ │ │ └─────────────────────────────────────────┘ │ │ │   │
│   │ │ └─────────────────────────────────────────────┘ │ │   │
│   │ └─────────────────────────────────────────────────┘ │   │
│   └─────────────────────────────────────────────────────┘   │
│                                                             │
│   Each layer provides independent protection                │
│   Breach of one layer doesn't compromise all                │
└─────────────────────────────────────────────────────────────┘

LEAST PRIVILEGE:
┌─────────────────────────────────────────────────────────────┐
│ Every identity gets minimum permissions needed              │
│                                                             │
│ Applies to:                                                 │
│ - Human users (role-based, just-in-time)                    │
│ - Service accounts (scoped to specific resources)           │
│ - Applications (only APIs they need)                        │
│ - Networks (only required connectivity)                     │
│ - Data (need-to-know access)                                │
│                                                             │
│ Implementation:                                             │
│ - Start with zero permissions                               │
│ - Add specific permissions as needed                        │
│ - Regular access reviews                                    │
│ - Automated permission analysis                             │
│ - Time-bound elevated access                                │
└─────────────────────────────────────────────────────────────┘

ZERO TRUST:
┌─────────────────────────────────────────────────────────────┐
│ "Never trust, always verify"                                │
│                                                             │
│ Principles:                                                 │
│ - Verify explicitly (authenticate everything)               │
│ - Use least privilege access                                │
│ - Assume breach (limit blast radius)                        │
│                                                             │
│ Cloud Implementation:                                       │
│ - No implicit trust based on network location               │
│ - Authenticate all service-to-service communication         │
│ - Encrypt all traffic (even internal)                       │
│ - Micro-segmentation                                        │
│ - Continuous verification                                   │
│ - Device and context-aware access                           │
└─────────────────────────────────────────────────────────────┘

SECURE BY DEFAULT:
┌─────────────────────────────────────────────────────────────┐
│ Default configurations should be secure                     │
│                                                             │
│ Examples:                                                   │
│ - S3 buckets private by default                             │
│ - Encryption enabled by default                             │
│ - Security groups deny all by default                       │
│ - IMDSv2 required by default                                │
│ - MFA required by default                                   │
│                                                             │
│ Implementation:                                             │
│ - SCPs enforcing secure defaults                            │
│ - IaC modules with security built-in                        │
│ - Policy as code preventing insecure configs                │
│ - Golden images with hardening applied                      │
└─────────────────────────────────────────────────────────────┘

FAIL SECURE:
┌─────────────────────────────────────────────────────────────┐
│ When things break, they should break safely                 │
│                                                             │
│ Examples:                                                   │
│ - Authentication failure → deny access                      │
│ - WAF in fail-closed mode                                   │
│ - Circuit breakers that block on failure                    │
│ - Logging failures → alert (don't ignore)                   │
│                                                             │
│ Anti-patterns:                                              │
│ - Fail open (auth fails → allow access)                     │
│ - Silent failures (errors swallowed)                        │
│ - Degraded security during incidents                        │
└─────────────────────────────────────────────────────────────┘

Key insight: Principles provide consistent guidance when specific controls aren't defined. When in doubt, apply principles.

2) AWS Well-Architected Security Pillar

The Well-Architected Framework provides structured guidance for secure cloud architecture:

Well-Architected Security Pillar:

SECURITY DESIGN PRINCIPLES:
┌─────────────────────────────────────────────────────────────┐
│ 1. Implement a strong identity foundation                   │
│    - Centralized identity                                   │
│    - Least privilege                                        │
│    - Separation of duties                                   │
│    - No long-term credentials                               │
│                                                             │
│ 2. Enable traceability                                      │
│    - Log all actions                                        │
│    - Integrate logs with monitoring                         │
│    - Automate alerting                                      │
│    - Retain for compliance                                  │
│                                                             │
│ 3. Apply security at all layers                             │
│    - Edge, VPC, subnet, instance, OS, application           │
│    - Defense in depth                                       │
│                                                             │
│ 4. Automate security best practices                         │
│    - Security as code                                       │
│    - Automated remediation                                  │
│    - Immutable infrastructure                               │
│                                                             │
│ 5. Protect data in transit and at rest                      │
│    - Encryption everywhere                                  │
│    - Key management                                         │
│    - Access controls                                        │
│                                                             │
│ 6. Keep people away from data                               │
│    - Reduce direct access                                   │
│    - Automate data processing                               │
│    - Eliminate need for direct access                       │
│                                                             │
│ 7. Prepare for security events                              │
│    - Incident response plans                                │
│    - Simulations and game days                              │
│    - Automated response                                     │
└─────────────────────────────────────────────────────────────┘

SECURITY FOCUS AREAS:
┌─────────────────────────────────────────────────────────────┐
│ SEC 1: How do you securely operate your workload?           │
│ - Separate workloads using accounts                         │
│ - Secure AWS account root user                              │
│ - Keep up to date with security threats                     │
│ - Automate testing and validation                           │
│                                                             │
│ SEC 2: How do you manage identities?                        │
│ - Use centralized identity provider                         │
│ - Use temporary credentials                                 │
│ - Store and use secrets securely                            │
│ - Rely on centralized IdP                                   │
│                                                             │
│ SEC 3: How do you manage permissions?                       │
│ - Define access requirements                                │
│ - Grant least privilege                                     │
│ - Establish emergency access                                │
│ - Reduce permissions continuously                           │
│ - Establish permission guardrails                           │
│                                                             │
│ SEC 4: How do you detect and investigate events?            │
│ - Configure service and application logging                 │
│ - Analyze logs centrally                                    │
│ - Automate alerting                                         │
│ - Implement actionable events                               │
│                                                             │
│ SEC 5: How do you protect network resources?                │
│ - Create network layers                                     │
│ - Control traffic at all layers                             │
│ - Automate network protection                               │
│ - Implement inspection and protection                       │
│                                                             │
│ SEC 6: How do you protect compute resources?                │
│ - Perform vulnerability management                          │
│ - Reduce attack surface                                     │
│ - Implement managed services                                │
│ - Automate compute protection                               │
│ - Enable people to perform actions at distance              │
│                                                             │
│ SEC 7: How do you classify your data?                       │
│ - Identify data within workload                             │
│ - Define data protection controls                           │
│ - Automate identification and classification                │
│                                                             │
│ SEC 8: How do you protect data at rest?                     │
│ - Implement secure key management                           │
│ - Enforce encryption at rest                                │
│ - Automate data at rest protection                          │
│ - Enforce access control                                    │
│                                                             │
│ SEC 9: How do you protect data in transit?                  │
│ - Implement secure key and certificate management           │
│ - Enforce encryption in transit                             │
│ - Automate detection of unintended data access              │
│ - Authenticate network communications                       │
│                                                             │
│ SEC 10: How do you anticipate and respond to incidents?     │
│ - Identify key personnel and resources                      │
│ - Develop incident management plans                         │
│ - Prepare forensic capabilities                             │
│ - Automate containment capability                           │
│ - Pre-provision access                                      │
│ - Pre-deploy tools                                          │
│ - Run game days                                             │
└─────────────────────────────────────────────────────────────┘

Key insight: Well-Architected provides a systematic review framework. Use it for both design and assessment.

3) Reference Architectures

Reference architectures provide proven patterns for common scenarios:

Secure Three-Tier Web Application:

ARCHITECTURE DIAGRAM:
┌─────────────────────────────────────────────────────────────┐
│                        Internet                             │
│                            │                                │
│                     ┌──────┴──────┐                         │
│                     │  CloudFront │                         │
│                     │  + WAF      │                         │
│                     └──────┬──────┘                         │
│                            │                                │
│ ┌──────────────────────────┼──────────────────────────────┐ │
│ │                     VPC  │                              │ │
│ │                          │                              │ │
│ │  ┌───────────────────────┴───────────────────────────┐  │ │
│ │  │              Public Subnets                       │  │ │
│ │  │  ┌─────────────────────────────────────────────┐  │  │ │
│ │  │  │          Application Load Balancer          │  │  │ │
│ │  │  └────────────────────┬────────────────────────┘  │  │ │
│ │  └───────────────────────┼───────────────────────────┘  │ │
│ │                          │                              │ │
│ │  ┌───────────────────────┴───────────────────────────┐  │ │
│ │  │              Private Subnets (App)                │  │ │
│ │  │  ┌─────────────────────────────────────────────┐  │  │ │
│ │  │  │    ECS/EKS Cluster or EC2 Auto Scaling      │  │  │ │
│ │  │  │    (Application Tier)                       │  │  │ │
│ │  │  └────────────────────┬────────────────────────┘  │  │ │
│ │  └───────────────────────┼───────────────────────────┘  │ │
│ │                          │                              │ │
│ │  ┌───────────────────────┴───────────────────────────┐  │ │
│ │  │              Private Subnets (Data)               │  │ │
│ │  │  ┌─────────────┐           ┌─────────────┐        │  │ │
│ │  │  │    RDS      │           │ ElastiCache │        │  │ │
│ │  │  │  (Primary)  │           │             │        │  │ │
│ │  │  └─────────────┘           └─────────────┘        │  │ │
│ │  └───────────────────────────────────────────────────┘  │ │
│ │                                                         │ │
│ └─────────────────────────────────────────────────────────┘ │
│                                                             │
└─────────────────────────────────────────────────────────────┘

SECURITY CONTROLS BY LAYER:
┌─────────────────────────────────────────────────────────────┐
│ Edge (CloudFront + WAF):                                    │
│ - AWS Shield for DDoS protection                            │
│ - WAF rules for OWASP Top 10                                │
│ - Rate limiting                                             │
│ - Geo-blocking (if applicable)                              │
│ - TLS 1.2+ enforcement                                      │
│ - Custom headers for origin verification                    │
│                                                             │
│ Load Balancer:                                              │
│ - HTTPS only (redirect HTTP)                                │
│ - Security group: allow 443 from CloudFront IPs only        │
│ - Access logging enabled                                    │
│ - SSL policy with modern ciphers                            │
│                                                             │
│ Application Tier:                                           │
│ - Private subnets (no public IPs)                           │
│ - Security group: allow from ALB only                       │
│ - IAM roles with least privilege (IRSA for EKS)             │
│ - Secrets from Secrets Manager                              │
│ - IMDSv2 enforced                                           │
│ - Container scanning (if ECS/EKS)                           │
│ - Pod Security Standards (if EKS)                           │
│                                                             │
│ Data Tier:                                                  │
│ - Private subnets (isolated)                                │
│ - Security group: allow from app tier only                  │
│ - Encryption at rest (KMS CMK)                              │
│ - Encryption in transit (TLS)                               │
│ - IAM database authentication                               │
│ - Automated backups with encryption                         │
│ - No public accessibility                                   │
│                                                             │
│ Cross-Cutting:                                              │
│ - VPC Flow Logs enabled                                     │
│ - CloudTrail with data events                               │
│ - GuardDuty enabled                                         │
│ - Security Hub with standards                               │
│ - Config rules for compliance                               │
│ - Centralized logging                                       │
└─────────────────────────────────────────────────────────────┘

Multi-Account Architecture:

AWS Organizations Security Architecture:

ACCOUNT STRUCTURE:
┌─────────────────────────────────────────────────────────────┐
│                     Management Account                      │
│                     (Organizations, Billing)                │
│                            │                                │
│     ┌──────────────────────┼──────────────────────┐         │
│     │                      │                      │         │
│     ▼                      ▼                      ▼         │
│ ┌────────┐          ┌────────────┐          ┌────────┐      │
│ │Security│          │ Workloads  │          │Sandbox │      │
│ │  OU    │          │    OU      │          │  OU    │      │
│ └───┬────┘          └─────┬──────┘          └───┬────┘      │
│     │                     │                     │           │
│ ┌───┴────┐         ┌──────┴──────┐         ┌───┴────┐       │
│ │Log     │         │ ┌────────┐  │         │Dev1    │       │
│ │Archive │         │ │  Prod  │  │         │Dev2    │       │
│ ├────────┤         │ └────────┘  │         └────────┘       │
│ │Security│         │ ┌────────┐  │                          │
│ │Tooling │         │ │Staging │  │                          │
│ └────────┘         │ └────────┘  │                          │
│                    │ ┌────────┐  │                          │
│                    │ │  Dev   │  │                          │
│                    │ └────────┘  │                          │
│                    └─────────────┘                          │
└─────────────────────────────────────────────────────────────┘

ACCOUNT PURPOSES:
┌─────────────────────────────────────────────────────────────┐
│ Management Account:                                         │
│ - AWS Organizations                                         │
│ - SCPs                                                      │
│ - Consolidated billing                                      │
│ - Minimal workloads (governance only)                       │
│                                                             │
│ Log Archive Account:                                        │
│ - Centralized CloudTrail logs                               │
│ - VPC Flow Logs aggregation                                 │
│ - Config data                                               │
│ - Immutable storage (S3 Object Lock)                        │
│ - Restricted access (read-only for security)                │
│                                                             │
│ Security Tooling Account:                                   │
│ - GuardDuty delegated admin                                 │
│ - Security Hub aggregation                                  │
│ - SIEM/analysis tools                                       │
│ - Incident response tools                                   │
│ - Cross-account security roles                              │
│                                                             │
│ Workload Accounts:                                          │
│ - Separated by environment (prod, staging, dev)             │
│ - Or by application/team                                    │
│ - Blast radius containment                                  │
│ - Independent IAM boundaries                                │
│                                                             │
│ Sandbox Accounts:                                           │
│ - Experimentation                                           │
│ - Learning                                                  │
│ - Isolated from production                                  │
│ - May have relaxed controls                                 │
└─────────────────────────────────────────────────────────────┘

SERVICE CONTROL POLICIES:
┌─────────────────────────────────────────────────────────────┐
│ Root Level (All Accounts):                                  │
│ - Deny leaving organization                                 │
│ - Deny disabling CloudTrail                                 │
│ - Deny disabling GuardDuty                                  │
│ - Require IMDSv2                                            │
│                                                             │
│ Workload OUs:                                               │
│ - Deny unapproved regions                                   │
│ - Require encryption                                        │
│ - Deny public S3                                            │
│                                                             │
│ Production OU:                                              │
│ - Deny deleting VPC Flow Logs                               │
│ - Deny modifying security groups (except via IaC)           │
│ - Require tagging                                           │
│                                                             │
│ Sandbox OU:                                                 │
│ - Limit instance types                                      │
│ - Limit spending                                            │
│ - Allow more experimentation                                │
└─────────────────────────────────────────────────────────────┘

Key insight: Multi-account is a security control. Account boundaries provide hard isolation that IAM cannot achieve.

4) Threat Modeling for Cloud

Threat modeling identifies risks specific to your architecture and guides security control selection:

Cloud Threat Modeling:

STRIDE FOR CLOUD:
┌─────────────────────────────────────────────────────────────┐
│ S - Spoofing:                                               │
│     Cloud examples:                                         │
│     - Compromised credentials used to impersonate user      │
│     - Forged tokens or certificates                         │
│     - Metadata service exploitation (SSRF)                  │
│     Controls: MFA, short-lived credentials, IMDSv2          │
│                                                             │
│ T - Tampering:                                              │
│     Cloud examples:                                         │
│     - Modified container images                             │
│     - Altered S3 objects                                    │
│     - Changed configuration                                 │
│     Controls: Image signing, S3 versioning, Config rules    │
│                                                             │
│ R - Repudiation:                                            │
│     Cloud examples:                                         │
│     - Actions without audit trail                           │
│     - Disabled logging                                      │
│     - Tampered logs                                         │
│     Controls: CloudTrail, immutable logs, log integrity     │
│                                                             │
│ I - Information Disclosure:                                 │
│     Cloud examples:                                         │
│     - Public S3 buckets                                     │
│     - Exposed secrets in code                               │
│     - Unencrypted data                                      │
│     Controls: Encryption, access controls, scanning         │
│                                                             │
│ D - Denial of Service:                                      │
│     Cloud examples:                                         │
│     - Resource exhaustion                                   │
│     - DDoS attacks                                          │
│     - Quota exhaustion                                      │
│     Controls: Shield, WAF, rate limiting, auto-scaling      │
│                                                             │
│ E - Elevation of Privilege:                                 │
│     Cloud examples:                                         │
│     - IAM privilege escalation                              │
│     - Container escape                                      │
│     - Cross-account access abuse                            │
│     Controls: Least privilege, permission boundaries        │
└─────────────────────────────────────────────────────────────┘

THREAT MODELING PROCESS:
┌─────────────────────────────────────────────────────────────┐
│ 1. DECOMPOSE THE SYSTEM                                     │
│    - Identify components                                    │
│    - Map data flows                                         │
│    - Identify trust boundaries                              │
│    - Document entry points                                  │
│                                                             │
│ 2. IDENTIFY THREATS                                         │
│    - Apply STRIDE to each component                         │
│    - Consider cloud-specific threats                        │
│    - Map to MITRE ATT&CK Cloud                              │
│    - Consider insider threats                               │
│                                                             │
│ 3. ASSESS RISKS                                             │
│    - Likelihood of each threat                              │
│    - Impact if exploited                                    │
│    - Existing controls                                      │
│    - Residual risk                                          │
│                                                             │
│ 4. MITIGATE                                                 │
│    - Select controls for high risks                         │
│    - Accept low risks (documented)                          │
│    - Avoid some risks (change design)                       │
│    - Transfer some risks (insurance, contracts)             │
│                                                             │
│ 5. VALIDATE                                                 │
│    - Verify controls are implemented                        │
│    - Test effectiveness                                     │
│    - Update model as architecture changes                   │
└─────────────────────────────────────────────────────────────┘

Example Threat Model:

Threat Model: Serverless API

SYSTEM DESCRIPTION:
┌─────────────────────────────────────────────────────────────┐
│ API Gateway → Lambda → DynamoDB                             │
│ Cognito authentication                                      │
│ S3 for file storage                                         │
│ Secrets Manager for credentials                             │
└─────────────────────────────────────────────────────────────┘

THREAT ANALYSIS:
┌─────────────────────────────────────────────────────────────┐
│ Component    │ Threat          │ Risk │ Mitigation          │
├──────────────┼─────────────────┼──────┼─────────────────────┤
│ API Gateway  │ Unauthenticated │ High │ Cognito authorizer  │
│              │ access          │      │                     │
├──────────────┼─────────────────┼──────┼─────────────────────┤
│ API Gateway  │ Injection       │ High │ WAF, input          │
│              │ attacks         │      │ validation          │
├──────────────┼─────────────────┼──────┼─────────────────────┤
│ API Gateway  │ DDoS            │ Med  │ Throttling, WAF     │
│              │                 │      │ rate limiting       │
├──────────────┼─────────────────┼──────┼─────────────────────┤
│ Lambda       │ Code injection  │ High │ Input validation,   │
│              │                 │      │ parameterized       │
├──────────────┼─────────────────┼──────┼─────────────────────┤
│ Lambda       │ Overprivileged  │ High │ Least privilege     │
│              │ role            │      │ IAM per function    │
├──────────────┼─────────────────┼──────┼─────────────────────┤
│ Lambda       │ Dependency      │ Med  │ Scanning, pinned    │
│              │ vulnerabilities │      │ versions            │
├──────────────┼─────────────────┼──────┼─────────────────────┤
│ DynamoDB     │ Data exposure   │ High │ IAM, encryption,    │
│              │                 │      │ VPC endpoint        │
├──────────────┼─────────────────┼──────┼─────────────────────┤
│ S3           │ Public access   │ Crit │ Block public,       │
│              │                 │      │ bucket policy       │
├──────────────┼─────────────────┼──────┼─────────────────────┤
│ Secrets Mgr  │ Secret exposure │ High │ IAM, encryption,    │
│              │                 │      │ rotation            │
├──────────────┼─────────────────┼──────┼─────────────────────┤
│ Cognito      │ Account         │ Med  │ MFA, password       │
│              │ takeover        │      │ policy              │
└──────────────┴─────────────────┴──────┴─────────────────────┘

RESULTING SECURITY REQUIREMENTS:
┌─────────────────────────────────────────────────────────────┐
│ 1. Cognito authentication with MFA for all users            │
│ 2. WAF with OWASP rules on API Gateway                      │
│ 3. Per-function IAM roles with specific resource ARNs       │
│ 4. Input validation in Lambda (JSON schema)                 │
│ 5. S3 Block Public Access enabled                           │
│ 6. DynamoDB accessed via VPC endpoint only                  │
│ 7. All data encrypted with CMK                              │
│ 8. Dependency scanning in CI/CD                             │
│ 9. CloudTrail data events for S3 and DynamoDB               │
│ 10. GuardDuty enabled                                       │
└─────────────────────────────────────────────────────────────┘

Key insight: Threat modeling is most valuable early in design. It's cheaper to redesign than to retrofit security.

5) Capstone Project

The capstone project synthesizes all course concepts into a comprehensive secure cloud architecture:

Capstone Project: Secure SaaS Platform

SCENARIO:
┌─────────────────────────────────────────────────────────────┐
│ You are the security architect for a B2B SaaS startup.      │
│ The platform handles sensitive customer data and must       │
│ comply with SOC 2 Type II requirements.                     │
│                                                             │
│ Business Requirements:                                      │
│ - Multi-tenant application                                  │
│ - Web application and API                                   │
│ - File upload and processing                                │
│ - Integration with customer systems                         │
│ - 99.9% availability SLA                                    │
│ - Data residency requirements (US and EU)                   │
│                                                             │
│ Technical Stack:                                            │
│ - Containerized microservices                               │
│ - PostgreSQL database                                       │
│ - Redis caching                                             │
│ - Asynchronous job processing                               │
│ - Object storage for files                                  │
└─────────────────────────────────────────────────────────────┘

DELIVERABLES:

1. ARCHITECTURE DESIGN (30%)
┌─────────────────────────────────────────────────────────────┐
│ - Complete architecture diagram                             │
│ - Multi-account structure                                   │
│ - Network design (VPC, subnets, connectivity)               │
│ - Data flow diagrams                                        │
│ - Component specifications                                  │
│                                                             │
│ Evaluation Criteria:                                        │
│ - Defense in depth visible in design                        │
│ - Appropriate service selection                             │
│ - Scalability considerations                                │
│ - High availability design                                  │
└─────────────────────────────────────────────────────────────┘

2. SECURITY CONTROLS (30%)
┌─────────────────────────────────────────────────────────────┐
│ - Identity and access management design                     │
│ - Network security controls                                 │
│ - Data protection controls                                  │
│ - Compute/container security                                │
│ - Monitoring and detection                                  │
│ - Incident response preparation                             │
│                                                             │
│ For each control:                                           │
│ - What AWS service/feature                                  │
│ - How it's configured                                       │
│ - What threat it mitigates                                  │
│ - How it's monitored                                        │
└─────────────────────────────────────────────────────────────┘

3. THREAT MODEL (20%)
┌─────────────────────────────────────────────────────────────┐
│ - System decomposition                                      │
│ - Threat identification (STRIDE)                            │
│ - Risk assessment                                           │
│ - Control mapping                                           │
│ - Residual risk acceptance                                  │
│                                                             │
│ Minimum 15 threats identified and analyzed                  │
└─────────────────────────────────────────────────────────────┘

4. IMPLEMENTATION (20%)
┌─────────────────────────────────────────────────────────────┐
│ - Terraform/CloudFormation for core infrastructure          │
│ - Security group rules                                      │
│ - IAM policies                                              │
│ - Sample SCPs                                               │
│ - CI/CD pipeline with security gates                        │
│                                                             │
│ Code must pass:                                             │
│ - Checkov/tfsec scan with 0 HIGH/CRITICAL                   │
│ - Policy validation                                         │
└─────────────────────────────────────────────────────────────┘

Evaluation Rubric:

Capstone Evaluation Criteria:

ARCHITECTURE (30 points):
┌─────────────────────────────────────────────────────────────┐
│ Excellent (27-30):                                          │
│ - Comprehensive, production-ready design                    │
│ - All security layers addressed                             │
│ - Clear documentation                                       │
│ - Innovative solutions                                      │
│                                                             │
│ Good (21-26):                                               │
│ - Complete design with minor gaps                           │
│ - Most security layers addressed                            │
│ - Adequate documentation                                    │
│                                                             │
│ Satisfactory (15-20):                                       │
│ - Basic design complete                                     │
│ - Some security gaps                                        │
│ - Documentation needs improvement                           │
│                                                             │
│ Needs Improvement (<15):                                    │
│ - Incomplete design                                         │
│ - Significant security gaps                                 │
│ - Poor documentation                                        │
└─────────────────────────────────────────────────────────────┘

SECURITY CONTROLS (30 points):
┌─────────────────────────────────────────────────────────────┐
│ Evaluated on:                                               │
│ - Completeness of control coverage                          │
│ - Appropriateness of control selection                      │
│ - Defense in depth demonstration                            │
│ - Least privilege implementation                            │
│ - Monitoring and detection capability                       │
│ - Incident response preparation                             │
└─────────────────────────────────────────────────────────────┘

THREAT MODEL (20 points):
┌─────────────────────────────────────────────────────────────┐
│ Evaluated on:                                               │
│ - Thoroughness of threat identification                     │
│ - Realistic risk assessment                                 │
│ - Clear control mapping                                     │
│ - Appropriate risk acceptance decisions                     │
│ - Cloud-specific threat consideration                       │
└─────────────────────────────────────────────────────────────┘

IMPLEMENTATION (20 points):
┌─────────────────────────────────────────────────────────────┐
│ Evaluated on:                                               │
│ - Code quality and organization                             │
│ - Security best practices in code                           │
│ - Passing security scans                                    │
│ - Completeness of implementation                            │
│ - Documentation and comments                                │
└─────────────────────────────────────────────────────────────┘

The capstone demonstrates your ability to apply cloud security knowledge to realistic scenarios.

Real-World Context

Case Study: Building Security Into a Startup

A fintech startup designed security into their architecture from day one. They adopted a multi-account strategy even as a small team, automated security controls via IaC, implemented zero-trust networking, and built comprehensive logging from the start. When they pursued SOC 2 certification two years later, they passed with minimal additional work—the controls were already in place. Competitors who bolted on security later spent months retrofitting controls and rewriting applications. The lesson: security architecture decisions made early pay dividends throughout the company's life.

Case Study: Security Architecture Review Findings

A security architecture review of a large enterprise's cloud deployment found: single AWS account for all workloads, shared IAM roles across teams, no network segmentation, logging disabled to save costs, and secrets in environment variables. Remediation required six months and significant rearchitecting. The review recommended: multi-account structure with SCPs, federated identity with per-application roles, network segmentation with security groups and NACLs, comprehensive logging to central account, and secrets management via Secrets Manager. The initial "simpler" approach created technical debt that was expensive to repay.

Security Architecture Principles Summary:

Cloud Security Architecture Summary:

FOUNDATIONAL PRINCIPLES:
□ Defense in depth at every layer
□ Least privilege for all identities
□ Zero trust (verify explicitly)
□ Secure by default configurations
□ Fail secure on errors
□ Separation of duties
□ Assume breach (limit blast radius)

ACCOUNT STRUCTURE:
□ Multi-account with Organizations
□ Security OU (log archive, security tooling)
□ Workload OUs by environment
□ SCPs for guardrails
□ Centralized identity

NETWORK:
□ VPC per workload with proper segmentation
□ Private subnets for workloads
□ Public subnets only for load balancers
□ Security groups with least privilege
□ VPC endpoints for AWS services
□ VPC Flow Logs enabled

IDENTITY:
□ Federated identity (no IAM users)
□ Per-service IAM roles
□ No long-lived credentials
□ MFA everywhere
□ Regular access reviews

DATA:
□ Encryption at rest (CMK)
□ Encryption in transit (TLS 1.2+)
□ Classification and handling
□ Access controls per classification
□ Backup and recovery

COMPUTE:
□ Hardened images (CIS)
□ Container scanning
□ Pod security standards
□ Immutable infrastructure
□ Automated patching

MONITORING:
□ CloudTrail (all regions, all accounts)
□ VPC Flow Logs
□ GuardDuty enabled
□ Security Hub with standards
□ Centralized SIEM
□ Alerting and response

IaC:
□ All infrastructure as code
□ Security scanning in CI/CD
□ Policy as code
□ No secrets in code
□ Secure state management

INCIDENT RESPONSE:
□ Runbooks documented
□ Forensic capabilities ready
□ Automated containment
□ Regular testing

Security architecture is never "done." It evolves with the business, threats, and cloud platform capabilities.

Capstone Lab: Secure Cloud Architecture

Complete the capstone project by designing and partially implementing a secure cloud architecture.

Project Requirements:

• Multi-tenant SaaS application
• SOC 2 compliance requirements
• US and EU data residency
• 99.9% availability target
• Containerized microservices

Deliverables:

1. Architecture diagram with all components
2. Multi-account structure design
3. Network architecture with security controls
4. IAM design with sample policies
5. Data protection strategy
6. Monitoring and alerting design
7. Threat model (minimum 15 threats)
8. Terraform code for core infrastructure
9. CI/CD pipeline with security gates
10. Security architecture document

Submission Guidelines:

• All diagrams in standard notation
• Code passing Checkov/tfsec scans
• Documentation in markdown format
• Threat model using STRIDE

Week Outcome Check

By the end of this week, you should be able to:

• Apply core security architecture principles to cloud designs
• Use the AWS Well-Architected Framework security pillar
• Design multi-tier web application security architecture
• Create multi-account AWS Organizations structures
• Conduct threat modeling for cloud applications
• Map threats to appropriate security controls
• Create comprehensive security architecture documentation
• Implement security controls in infrastructure as code

🎯 Hands-On Labs (Free & Essential)

Apply everything you've learned—design, build, and defend a production-ready secure cloud architecture.

💡 Lab Strategy: Document your capstone architecture thoroughly—this becomes your portfolio piece for cloud security roles.

Resources

Capstone Deliverables

Submit the following for capstone evaluation.