Part 1: Secure Architectures

This section covers the security pillar of the AWS Well-Architected Framework, focusing on protecting data, systems, and assets while delivering business value through risk assessments and mitigation strategies.

Key Security Services Overview

AWS provides multiple layers of security services to protect your infrastructure:

Content

This comprehensive section covers all aspects of designing secure architectures:

• IAM Deep Dive (Roles, Policies, MFA, evaluation logic) - See IAM Workshop (000002)
• KMS Envelope Encryption (workflow, pricing $1/month per customer managed key)
• Security Groups vs NACLs (stateful vs stateless comparison) - See VPC Workshop (000003)
• AWS Security Services (GuardDuty, WAF, Shield, Secrets Manager)
• Common FCJ Midterm Scenarios and Solutions

IAM (Identity and Access Management)

Core Concepts

IAM is AWS’s service for managing access to AWS resources. It enables you to control who can do what in your AWS environment.

Key Components:

1. Users: Individual people or services with permanent credentials
2. Groups: Collections of users with shared permissions
3. Roles: Temporary credentials for AWS services or federated users
4. Policies: JSON documents defining permissions

IAM Best Practices (FCJ Midterm Critical)

Based on official AWS documentation, these are the security best practices you MUST know:

1. ✅ Use temporary credentials (roles) instead of long-term access keys
2. ✅ Enable MFA for root account and privileged users (MANDATORY)
3. ✅ Apply least-privilege principle - start with minimum permissions
4. ✅ Rotate credentials regularly - maximum 90-day rotation
5. ✅ Use IAM Access Analyzer to generate least-privilege policies
6. ✅ Never use root account for everyday tasks
7. ✅ Use policy conditions to further restrict access
8. ✅ Maximum 1,000 IAM roles per AWS account (adjustable)

IAM Policy Structure

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-bucket/*",
    "Condition": {
      "IpAddress": {
        "aws:SourceIp": "203.0.113.0/24"
      }
    }
  }]
}

Components:

• Effect: “Allow” or “Deny”
• Action: AWS service API operation (e.g., s3:GetObject, ec2:StartInstances)
• Resource: ARN of the resource (e.g., arn:aws:s3:::bucket-name/*)
• Condition (optional): Additional constraints (IP address, MFA, time)

IAM Policy Evaluation Logic

Critical for FCJ Midterm: Understand the order of policy evaluation

1. Explicit DENY → Always wins (overrides everything)
2. Explicit ALLOW → Required for access
3. Implicit DENY → Default when no explicit allow

Decision Flow:

User makes request
    ↓
Is there an explicit DENY? → YES → ACCESS DENIED
    ↓ NO
Is there an explicit ALLOW? → YES → ACCESS GRANTED
    ↓ NO
ACCESS DENIED (implicit deny)

IAM Roles - How They Work

IAM Role provides temporary security credentials that applications can use to make AWS API requests.

Use Cases:

1. EC2 instances accessing S3 buckets
2. Lambda functions accessing DynamoDB
3. Cross-account access between AWS accounts
4. Federated users from corporate directory

Benefits:

• ✅ No hardcoded credentials
• ✅ Automatic credential rotation (every 15 minutes to 1 hour)
• ✅ Temporary security credentials via STS (Security Token Service)
• ✅ Audit trail via CloudTrail

How EC2 Uses IAM Roles:

1. Attach IAM role to EC2 instance (instance profile)
2. EC2 instance requests temporary credentials from STS
3. STS returns temporary credentials (access key, secret key, session token)
4. EC2 uses credentials to access AWS services (e.g., S3)
5. Credentials automatically rotate

Multi-Factor Authentication (MFA)

MFA adds an extra layer of security requiring two forms of identification.

MFA Device Types:

1. Virtual MFA - Apps like Google Authenticator, Authy (TOTP standard)
2. Hardware TOTP - Physical devices generating 6-digit codes
3. FIDO Security Keys - U2F/FIDO2 hardware keys (most secure)

When to Use MFA (FCJ Midterm Scenarios):

• ✅ Root account (MANDATORY)
• ✅ Privileged IAM users
• ✅ Sensitive operations (delete resources, change security settings)
• ✅ Compliance requirements (PCI-DSS, HIPAA)

MFA with IAM Policy:

{
  "Effect": "Allow",
  "Action": "s3:DeleteObject",
  "Resource": "*",
  "Condition": {
    "Bool": {
      "aws:MultiFactorAuthPresent": "true"
    }
  }
}

This policy requires MFA to delete S3 objects.

KMS (Key Management Service)

Envelope Encryption

Envelope Encryption is the practice of encrypting plaintext data with a data key, and then encrypting the data key with a KMS key (customer managed key).

How It Works:

Encryption Workflow:

1. Application requests data key from KMS
2. KMS generates:
   - Plaintext data key
   - Encrypted data key (using KMS key)
3. Application encrypts data locally with plaintext key
4. Application deletes plaintext key from memory
5. Store encrypted data + encrypted data key together

Decryption Workflow:

1. Application retrieves encrypted data + encrypted data key
2. Send encrypted data key to KMS for decryption
3. KMS decrypts data key using KMS key
4. Application uses plaintext data key to decrypt data
5. Delete plaintext data key from memory

Benefits:

• ✅ Network efficiency: Only keys sent to KMS, not data
• ✅ Centralized key management: All keys managed in one place
• ✅ Automatic key rotation: Every 365 days
• ✅ Detailed audit logs: CloudTrail tracks all KMS API calls

KMS Pricing:

• Customer managed KMS keys: $1/month per key
• AWS managed keys: FREE (e.g., aws/s3, aws/ebs, aws/rds)
• API requests: $0.03 per 10,000 requests

Encryption Types

Encryption at Rest:

• S3: SSE-S3 (AWS managed), SSE-KMS (you manage), SSE-C (you provide key)
• EBS: AES-256 encryption using KMS
• RDS: Transparent encryption using KMS keys
• DynamoDB: Encryption enabled by default

Encryption in Transit:

• TLS/SSL: Use AWS Certificate Manager (ACM) for free certificates
• VPN: Site-to-Site VPN for on-premises connectivity
• HTTPS: All AWS API calls use HTTPS
• SSL/TLS: Database connections (RDS, Redshift)

Security Groups vs Network ACLs

Critical Differences (Memorize This Table)

Stateful vs Stateless (FCJ Midterm Critical)

Security Groups (Stateful):

Allow inbound on port 443 → Return traffic automatically allowed
No need to create separate outbound rule for return traffic

NACLs (Stateless):

Allow inbound on port 443 → Must also allow outbound ephemeral ports (1024-65535)
Separate rules needed for request and response

Example Scenario:

User accesses web server on HTTPS (port 443):

Security Group:

• Inbound: Allow port 443 from 0.0.0.0/0
• Outbound: Not needed (automatic)

NACL:

• Inbound: Allow port 443 from 0.0.0.0/0
• Outbound: Allow ports 1024-65535 to 0.0.0.0/0 (ephemeral ports)

When to Use Each

Security Groups (Primary Defense):

• Application-specific rules
• Allow access from specific Security Groups
• Dynamic rule updates without downtime
• Most common use case

NACLs (Subnet-Level Blocking):

• Block known bad IP addresses (deny rules)
• Additional layer of defense
• Subnet-wide rules
• Compliance requirements

Best Practice: Use Security Groups as primary firewall, NACLs for additional subnet-level protection.

AWS Security Services

Amazon GuardDuty

Purpose: Intelligent threat detection using machine learning

How It Works:

• Analyzes VPC Flow Logs, CloudTrail events, DNS logs, Kubernetes audit logs
• Uses ML to detect anomalies and threats
• Generates findings with severity levels (Low, Medium, High)
• Integrates with EventBridge for automated responses

Detections:

• Compromised EC2 instances (crypto mining)
• Credential theft attempts
• Reconnaissance activity (port scanning)
• Unusual API calls
• Communication with known malicious IPs/domains

Pricing:

• CloudTrail Management Events: $4.00 per million events
• VPC Flow Logs/DNS Logs (Tiered):
  • First 500 GB: $1.00/GB
  • Next 2,000 GB: $0.50/GB
  • Next 7,500 GB: $0.25/GB
  • Over 10,000 GB: $0.05/GB
• S3 Data Events: $0.80 per million (first 500M), $0.40 per million (next 500M+)
• EKS Audit Logs: $1.60 per million (first 100M), $0.80 per million (100M+)
• 30-Day FREE Trial: Available for new accounts

AWS Secrets Manager

Purpose: Automatic credential rotation for databases

• Amazon Redshift

Rotation Process (4 Steps - FCJ Midterm Critical):

1. createSecret: Create new credentials in database
2. setSecret: Update database with new credentials
3. testSecret: Verify new credentials work
4. finishSecret: Mark new version as current

Supported Databases:

• Amazon RDS (MySQL, PostgreSQL, Oracle, SQL Server)
• Amazon Aurora
• Amazon DocumentDB
• Amazon Redshift

Pricing:

• $0.40 per secret per month
• $0.05 per 10,000 API calls

vs Systems Manager Parameter Store:

• Secrets Manager: Automatic rotation, RDS integration
• Parameter Store: Manual rotation, free tier available

AWS WAF (Web Application Firewall)

Purpose: Protect web applications from common exploits

Protection Types:

• SQL injection attacks
• Cross-site scripting (XSS)
• Rate limiting (DDoS prevention)
• Geo-blocking (allow/block countries)
• IP reputation lists
• Custom rules based on headers, URI, query strings

Pricing (Prorated Hourly):

• Web ACL: $5/month per Web ACL
• Rules: $1/month per rule
• Web Requests: $0.60 per million requests
• Bot Control: $10/month + $1 per million requests
• Fraud Control: $10/month + $1 per million requests
• Managed Rule Groups: $1/month per group + $0.60 per million requests

Integration Points:

• Amazon CloudFront (global CDN)
• Application Load Balancer (regional)
• Amazon API Gateway (REST/HTTP APIs)
• AWS AppSync (GraphQL APIs)

Deployment: Layer 7 (Application Layer) protection with centralized management via AWS Firewall Manager

AWS Shield

Purpose: DDoS (Distributed Denial of Service) protection

Shield Standard (FREE):

• Automatic Layer 3/4 protection
• Available to all AWS customers automatically
• Network and transport layer defenses
• Protection against common DDoS attacks (SYN floods, UDP reflection)
• Network flow monitoring
• Always-on detection and mitigation

Shield Advanced ($3,000/month):

• Enhanced Layer 3/4/7 protection
• 24/7 DDoS Response Team (DRT) access
• Cost protection: AWS credits for attack-related usage spikes
• WAF fees waived when used with Shield Advanced
• 2TB data transfer included per month
• Real-time attack notifications via CloudWatch
• Advanced attack metrics and forensics reports
• 12-month commitment required
• Application layer (Layer 7) protection

Key Differences:

Common FCJ Midterm Scenarios

Scenario 1: Cross-Account S3 Access

Question: EC2 in Account A needs to access S3 bucket in Account B. How?

Answer:

1. Create IAM role in Account B with S3 access policy
2. Configure trust policy to allow Account A
3. Attach role to EC2 in Account A
4. EC2 uses STS AssumeRole to access S3

Scenario 2: Block Malicious IPs

Question: How to block specific IP addresses from accessing your application?

Answer: Use Network ACLs (not Security Groups)

• Security Groups only support ALLOW rules
• NACLs support DENY rules
• Create NACL rule with lower number (e.g., rule #10) to deny IPs
• Lower numbers evaluated first

Scenario 3: Require MFA for Deletion

Question: How to require MFA for deleting S3 objects?

Answer: IAM policy with MFA condition:

{
  "Effect": "Allow",
  "Action": "s3:DeleteObject",
  "Resource": "*",
  "Condition": {
    "Bool": {
      "aws:MultiFactorAuthPresent": "true"
    }
  }
}

FCJ Midterm Preparation Tips

1. IAM roles are always preferred over access keys
2. MFA should be enabled for root account (mandatory)
3. Security Groups are stateful, NACLs are stateless
4. Envelope encryption reduces network overhead
5. GuardDuty for threat detection, CloudTrail for audit logging
6. Secrets Manager for automatic rotation (not Parameter Store)
7. Explicit deny always wins in IAM policy evaluation
8. Least privilege principle should always be applied