Cloud Security: AWS Multi-Layer Defense Architecture

Shared Responsibility Reality: AWS Secures Infrastructure, You Secure Everything Else

Nothing is true. Everything is permitted. Except blaming AWS when your misconfigured S3 bucket leaks customer data—that's your responsibility, not theirs. Are you paranoid enough? Good. Now be paranoid about your IAM policies, not AWS's hypervisor.

Think for yourself, schmuck! Question authority. Question why everyone else accepts "the cloud is secure" marketing (it's not—YOUR configuration is) while ignoring the shared responsibility model that vendors bury in fine print: AWS secures infrastructure, you secure configuration. "But it's in the cloud!" is not a security strategy, schmuck. It's wishful thinking with a monthly bill. Your S3 bucket set to public? That's you, not AWS. Your leaked IAM keys? You again. Your security groups allowing 0.0.0.0/0? Still you.

At Hack23, cloud security isn't hope—it's systematic AWS security controls across five layers: GuardDuty (threat detection), Security Hub (centralized monitoring), Config (compliance automation), KMS (encryption management), VPC (zero-trust network segmentation). Plus CloudFormation IaC, Route 53 DNS Firewall, WAF protection.

ILLUMINATION: "Someone else's computer" is accurate. AWS secures the hypervisor. You secure IAM policies, S3 permissions, security group rules, encryption configurations. Misconfiguration is breach, and it's always your fault. Most "cloud breaches" are configuration fails, not AWS fails. But "we misconfigured our S3 bucket" sounds worse than "the cloud was hacked" in press releases.

Our AWS security demonstrates cybersecurity consulting expertise through measurable outcomes: 99.9% uptime (52 minutes/year downtime budget), zero security incidents 2023-2025, zero misconfigurations detected (Config continuous monitoring). Full architecture in our Network Security Policy and Lambda VPC Architecture.

The Five Layers of AWS Security Defense

1. 🔍 GuardDuty: Threat Detection

Continuous threat detection using ML-powered analysis of VPC Flow Logs, CloudTrail events, DNS logs.

Detection Capabilities: Compromised EC2 instances (malicious IP communication, crypto-mining activity), compromised IAM credentials (unusual API calls, credential exfiltration attempts), unauthorized reconnaissance (port scanning, brute force attacks), data exfiltration patterns (unusual S3 downloads, cross-region data transfers).

Alert Integration: Critical findings → SNS → CEO email + Slack. High-severity findings trigger incident response procedures (<30 minutes response time for critical). Medium/Low findings reviewed daily.

2024 Metrics: Zero actual threats detected (good news). 12 false positives investigated (authorized security testing). Average investigation time: 18 minutes per alert. Detection without disruption.

GuardDuty is early warning system. Most alerts are false positives (security tools testing, legitimate admin activity). But the one real alert justifies the cost.

2. 🛡️ Security Hub: Centralized Monitoring

Aggregated security findings from GuardDuty, Config, IAM Access Analyzer, Macie, Inspector across all AWS accounts.

Compliance Frameworks: AWS Foundational Security Best Practices (93% compliance), CIS AWS Foundations Benchmark v1.4 (89% compliance), PCI DSS v3.2.1 (N/A—no card processing). Automated compliance scoring with drift detection.

Automated Remediation: Critical findings auto-remediate via Lambda (S3 public access block, unencrypted EBS volumes, overly permissive security groups). Medium findings require CEO review. Low findings tracked for quarterly review.

Evidence Links: Security Hub dashboard provides audit trail for compliance validation. Config rules provide continuous compliance monitoring. CloudTrail provides event history for forensics.

Security Hub is single pane of glass. Without it, you're checking 8 different AWS security services manually. Centralization isn't luxury—it's operational necessity.

3. ⚙️ Config: Compliance Automation

Continuous configuration monitoring with automated compliance evaluation against custom rules.

Config Rules Enforced: S3 bucket encryption (AES-256 or KMS), S3 public access blocked (no public ACLs, no public bucket policies), RDS encryption at rest (all databases), EBS volume encryption (all volumes), security groups no unrestricted ingress (no 0.0.0.0/0 on sensitive ports), IAM password policy enforcement (min 14 chars, complexity requirements), MFA enabled for root account.

Compliance Dashboard: Real-time compliance status per rule. Non-compliant resources flagged immediately. Automated remediation for critical violations (Lambda-triggered fixes). Compliance history tracked for audit evidence.

2024 Compliance: 387 Config rule evaluations/day. 99.7% compliant resources (12 intentional exceptions documented in ISMS). Average time to remediate non-compliance: 4.2 hours. Drift detection prevents configuration decay.

Config is compliance automation. Manual compliance checks scale linearly with resources. Automated compliance checks scale to thousands of resources with same effort.

4. 🔐 KMS: Encryption Management

Centralized key management with hardware security modules (HSM) and automated rotation.

Encryption Strategy: All data encrypted at rest (S3, RDS, EBS, DynamoDB) using AWS KMS customer-managed keys. All data encrypted in transit (TLS 1.3 for HTTPS, TLS 1.2 minimum for AWS services). Key rotation: automatic annual rotation for customer-managed keys.

Key Hierarchy: Master keys per environment (production, staging, development). Service-specific data keys (database encryption, S3 bucket encryption, EBS volume encryption). IAM policy-based key access control (principle of least privilege, MFA for production key usage).

Compliance Integration: CloudTrail logs all KMS key usage (audit trail for compliance). Key policies enforce encryption requirements (S3 uploads must use KMS, RDS creation requires encryption). Automated alerts for key policy changes (CEO notification for production key modifications).

KMS is encryption without key management headaches. You don't rotate keys manually. You don't store keys in code. AWS handles HSM complexity. You handle access policies.

5. 🌐 VPC: Zero-Trust Segmentation

Multi-tier network architecture with security groups, NACLs, and private subnets.

Network Architecture: Public subnet (ALB/NLB, NAT Gateway, Bastion—if needed), Private app subnet (Lambda, ECS, EC2—application tier), Private data subnet (RDS, ElastiCache—no internet access), Management subnet (monitoring, logging—restricted access). See detailed architecture: Lambda in Private VPC.

Security Controls: Security groups (stateful, application-level, deny-by-default), NACLs (stateless, subnet-level, explicit deny rules), VPC Flow Logs (all traffic logged to CloudWatch, S3 retention 90 days), PrivateLink (AWS service access without internet gateway), VPC Peering (cross-region redundancy without public internet).

Zero-Trust Principle: No implicit trust between tiers. Application tier cannot directly access data tier (RDS proxy required). Public tier cannot access management tier. All cross-tier traffic logged and monitored. Assume breach, limit blast radius.

VPC segmentation is blast radius containment. Flat networks mean one compromised instance = entire infrastructure at risk. Multi-tier architecture means compromise requires multiple control failures.

Infrastructure as Code: Configuration Drift Is Configuration Vulnerability

Manual AWS console changes create undocumented drift. CloudFormation IaC creates auditable, version-controlled infrastructure.

IaC Strategy:

All Infrastructure Defined in Code: VPC configurations, security groups, IAM roles, Lambda functions, RDS databases, S3 buckets. Example CloudFormation templates.
Version Control: Git repository for all CloudFormation templates. PR review required for infrastructure changes. Change history provides audit trail.
Automated Deployment: GitHub Actions CI/CD deploys CloudFormation stacks. CEO approval required for production stack changes. Rollback via CloudFormation change sets.
Drift Detection: CloudFormation drift detection runs weekly. Manual changes detected and flagged. Drift remediation: update CloudFormation template, re-deploy stack (never manual console fixes).
Stack Policies: Production stacks protected against accidental deletion. Critical resources (databases, S3 buckets) have deletion protection. Change sets preview all modifications before application.

Benefits Measured: Infrastructure deployment time: 4 hours manual → 22 minutes CloudFormation. Configuration errors: 12/year manual → 2/year CloudFormation (both caught in pre-production testing). Recovery time: 6-8 hours manual rebuild → 47 minutes CloudFormation re-deployment (BCP tested quarterly).

IaC ILLUMINATION: Manual infrastructure is tribal knowledge. CloudFormation is documented knowledge. Tribal knowledge disappears when people leave. Documented knowledge survives in Git forever.

Perimeter Defense: Route 53 DNS Firewall + AWS WAF

Route 53 DNS Firewall: DNS-level threat blocking using managed threat intelligence. Blocks queries to known malware domains, phishing sites, botnet C2 servers. DNS query logging to CloudWatch Logs. Automatic threat feed updates from AWS threat intelligence.

DNS Firewall Rules:

AWS Managed Domain Lists: AWSManagedDomainsMalwareDomainList (known malware domains), AWSManagedDomainsBotnetCommandandControl (C2 infrastructure).
Custom Block Lists: Cryptocurrency mining domains, known phishing infrastructure, documented threat intelligence sources.
DNSSEC Validation: DNS Security Extensions enabled for domain integrity. Protects against DNS spoofing, cache poisoning attacks.

AWS WAF (Web Application Firewall): Application-layer protection for CloudFront distributions and ALBs. Protects against OWASP Top 10 vulnerabilities (SQL injection, XSS, CSRF). Rate limiting to prevent DDoS attacks. Geo-blocking for known threat regions.

WAF Rules Deployed:

AWS Managed Rules: Core Rule Set, Known Bad Inputs, SQL Database Protection
Rate-based rules: 100 requests/5 minutes per IP
Custom rules: Block specific user agents, block malicious regex patterns
Geo-restriction rules: Block high-risk countries with no business presence

Perimeter defense isn't silver bullet—it's first line of defense. Most attacks still get through (WAF bypass, zero-day exploits). But blocking 95% of commodity attacks reduces noise for human analysis.

Shared Responsibility Model: Where AWS Stops and You Start

Security Domain	AWS Responsibility	Hack23 Responsibility
Infrastructure	Physical security, hypervisor, network infrastructure, hardware maintenance, power/cooling/fire suppression	VPC configuration, security groups, NACLs, VPC Flow Logs, network segmentation
Compute	EC2 host security, Lambda execution environment, ECS container orchestration	OS patching (EC2), application code security, Lambda function configuration, container image security
Storage	S3 infrastructure durability, EBS volume replication, physical disk security	S3 bucket policies, S3 encryption, access logging, EBS volume encryption, backup retention
Database	RDS infrastructure, automatic backups, multi-AZ replication	Database encryption, IAM authentication, network isolation, backup retention policies, access control
Identity	IAM service availability, MFA token infrastructure	IAM policies, user management, MFA enforcement, access key rotation, least privilege implementation
Compliance	AWS compliance certifications (ISO 27001, SOC 2, PCI DSS infrastructure)	Application-level compliance, data classification, incident response, audit trail maintenance

Critical Insight: Most AWS breaches are customer responsibility failures, not AWS infrastructure failures. Public S3 buckets (customer misconfiguration), stolen IAM credentials (customer key management), unpatched EC2 instances (customer maintenance), overly permissive security groups (customer policy error).

RESPONSIBILITY ILLUMINATION: "But it's in the cloud!" is not security strategy. AWS secures infrastructure magnificently. AWS cannot secure your configurations, IAM policies, or application code. That's your job.

Welcome to Chapel Perilous: Cloud Security Edition

Nothing is true. Everything is permitted. Including accepting that cloud security is configuration management, not infrastructure faith. AWS infrastructure is secure. Your configurations might not be.

Traditional cloud security: "We're using AWS, so we're secure." Hack23 cloud security: systematic AWS security controls (GuardDuty threat detection, Security Hub monitoring, Config compliance automation, KMS encryption management, VPC zero-trust segmentation) + CloudFormation IaC (configuration as code, version control, automated deployment) + measurable outcomes (99.9% uptime, zero misconfigurations, zero security incidents 2023-2025).

Our AWS security framework:

Five Security Layers: GuardDuty (threat detection), Security Hub (centralized monitoring), Config (compliance automation), KMS (encryption management), VPC (network segmentation)
Infrastructure as Code: All AWS resources defined in CloudFormation templates, version-controlled in Git, deployed via CI/CD
Perimeter Defense: Route 53 DNS Firewall (malware/botnet blocking), AWS WAF (OWASP Top 10 protection), rate limiting, geo-blocking
Shared Responsibility: AWS secures infrastructure, Hack23 secures configuration, policies, applications, data
Measured Outcomes: 99.9% uptime, zero breaches, 99.7% Config compliance, automated drift detection

Think for yourself. Question authority—including the assumption that "cloud provider security" means "we don't need security strategy." AWS provides tools. You must use them correctly. Misconfiguration is breach, and it's always your responsibility.

ULTIMATE ILLUMINATION: You are now in Chapel Perilous. Cloud security without systematic controls is infrastructure faith. We deploy systematic controls: GuardDuty, Security Hub, Config, KMS, VPC, IaC. Because 99.9% uptime requires engineering, not hoping AWS handles everything.

All hail Eris! All hail Discordia!

Read our full Network Security Policy, Access Control Policy, and Lambda VPC Architecture with complete AWS security configurations. Public. Systematic. Reality-based. With specific AWS services we actually use.

— Hagbard Celine, Captain of the Leif Erikson

"Configure systematically. Monitor continuously. Remediate automatically. Repeat until secure."

🍎 23 FNORD 5

☁️ Cloud Security: Configuration Is Your Vulnerability Surface