🎓 AWS SAA-C03 STUDY GUIDE - THE 80/20 MASTER BLUEPRINT

+----------------------------------------------------------------------------+
| YOUR APPLICATION                                                           |
+----------------------------------------------------------------------------+
| +----------------------+ +----------------------+ +----------------------+ |
| | Operational          | | Security             | | Reliability          | |
| | Excellence           | |                      | |                      | |
| +----------------------+ +----------------------+ +----------------------+ |
| +----------------------+ +----------------------+ +----------------------+ |
| | Performance          | | Cost                 | | Sustainability       | |
| | Efficiency           | | Optimization         | |                      | |
| +----------------------+ +----------------------+ +----------------------+ |
+----------------------------------------------------------------------------+
                

?? STUDY TOOLKIT - LAST MILE ACCELERATORS

TIER 1 - ARCHITECTURAL FOUNDATIONS (60-70% điểm)

1. AMAZON VPC (Virtual Private Cloud)

        +----------------------------------------------------------------------------+
        | YOUR VPC (10.0.0.0/16)                                                     |
        | +-----------------------------+    +-----------------------------+         |
        | | Public Subnet (Internet)    |    | Private Subnet (Secure)     |         |
        | | - Web Servers (EC2)         |    | - Database (RDS)            |         |
        | | - Public ELB                |    | - Internal Apps (EC2)       |         |
        | +-----------------------------+    +-----------------------------+         |
        +----------------------------------------------------------------------------+
                      |                                |
        (Internet Gateway) --0.0.0.0/0--> (Route Table) --0.0.0.0/0--> (NAT Gateway)
                      |                                |
         (SG: Allow 80/443)                  (SG: Allow 3306 from Web SG)
            

📚 Core Concepts

• VPC: A logically isolated section of the AWS Cloud. Spans all AZs in a region.
• Subnet: A range of IP addresses in your VPC. Tied to a single Availability Zone (AZ).
• Public Subnet: Has a route to an Internet Gateway (IGW). Resources can be reached from the internet.
• Private Subnet: Does NOT have a route to an IGW. Resources cannot be reached from the internet.
• Route Table: A set of rules, called routes, that determine where network traffic is directed.
• Internet Gateway (IGW): Allows communication between your VPC and the internet.
• NAT Gateway: Allows instances in a private subnet to connect to the internet (e.g., for updates), but prevents the internet from initiating connections with those instances. Must be in a public subnet.

🛡️ Security: Security Groups vs. Network ACLs (NACLs)

🌐 Connectivity & Endpoints

• VPC Peering: Connect two VPCs privately. Non-transitive (A-B, B-C does not mean A-C).
• Transit Gateway: A central hub to connect many VPCs and on-premises networks. Simplifies network management.
• VPC Endpoints: Privately connect your VPC to supported AWS services without requiring an IGW or NAT Gateway.
  • Gateway Endpoint: For S3 and DynamoDB. A gateway in your route table.
  • Interface Endpoint (PrivateLink): For most other services. An ENI in your subnet with a private IP. More expensive but more versatile.

2. EC2, ELB & Auto Scaling

⚙️ EC2 (Elastic Compute Cloud)

• Instance Types: Understand the families (e.g., General Purpose - T, M; Compute Optimized - C; Memory Optimized - R, X).
• Pricing Models:
  • On-Demand: Pay by the hour/second. No commitment. Most flexible.
  • Reserved Instances (RI): 1 or 3-year commitment. Significant discount. For steady-state workloads.
  • Savings Plans: More flexible than RIs. Commit to a certain $/hour spend.
  • Spot Instances: Bid on spare capacity. Up to 90% discount. Can be terminated with 2-min notice. For fault-tolerant workloads.
• EBS (Elastic Block Store): Network-attached storage for EC2. Think of it as a "hard drive". Tied to a specific AZ.

⚖️ ELB (Elastic Load Balancing)

📈 Auto Scaling Groups (ASG)

• Purpose: Automatically adjust the number of EC2 instances to meet demand. Ensures high availability and fault tolerance.
• Launch Template/Configuration: Specifies the EC2 instance configuration (AMI, instance type, key pair, security groups).
• Scaling Policies:
  • Target Tracking: "Keep CPU utilization at 50%". The most common and recommended policy.
  • Step/Simple Scaling: "If CPU > 70%, add 2 instances". More manual control.
  • Scheduled Scaling: "Scale up at 8 AM on weekdays". For predictable traffic patterns.

User --> Route 53 --> CloudFront --> ALB --> EC2 Auto Scaling Group
| (in multiple AZs)
v
RDS Multi-AZ DB
            

3. AMAZON S3 (Simple Storage Service)

🗂️ S3 Storage Classes

🛡️ S3 Security

• IAM Policies vs. Bucket Policies: Both control access. Bucket Policies are attached to the bucket itself and are great for cross-account access or making a whole bucket public.
• Block Public Access: A set of settings at the account or bucket level to prevent accidental public exposure. Enabled by default.
• Encryption:
  • Server-Side Encryption (SSE):
  • SSE-S3: S3 manages the keys. Easiest option.
  • SSE-KMS: You manage keys via KMS. Provides an audit trail.
  • SSE-C: You provide your own encryption keys with each request.
  • Client-Side Encryption: You encrypt data *before* uploading it to S3.
• Pre-signed URLs: Grant temporary access to a private object. The user who generates the URL uses their permissions.

🔄 Data Management

• Versioning: Keep a complete history of all object versions. Protects against accidental deletes (a delete adds a "delete marker").
• Replication (CRR & SRR): Automatically copy objects to another bucket.
  • Cross-Region Replication (CRR): For disaster recovery or lower latency access in different regions.
  • Same-Region Replication (SRR): For log aggregation or dev/test account sync.
• Lifecycle Policies: Automate moving objects between storage classes or deleting them after a certain period.

4. AWS IAM (Identity & Access Management)

🔑 Core Components

• Users: An entity that you create in AWS to represent the person or application that uses it to interact with AWS. Has long-term credentials (password, access keys).
• Groups: A collection of IAM users. A way to manage permissions for multiple users at once.
• Roles: An identity with temporary credentials that can be assumed by trusted entities (users, applications, or AWS services like EC2). **This is the preferred way to grant permissions to applications.**
• Policies: A JSON document that defines permissions.
  • Identity-based Policy: Attached to a user, group, or role.
  • Resource-based Policy: Attached to a resource (e.g., S3 bucket policy).

⚖️ Policy Evaluation Logic

1. Starts with an implicit **DENY**.
2. An explicit **ALLOW** in any policy overrides the implicit deny.
3. An explicit **DENY** in any policy overrides any allows.

✅ IAM Best Practices (Crucial for the Exam)

• Never use the root account for daily tasks.
• Apply the Principle of Least Privilege: Grant only the permissions required to perform a task.
• Use IAM Roles for applications running on EC2, ECS, or Lambda. Never store access keys in your code or on an instance.
• Enable MFA (Multi-Factor Authentication) for all users, especially the root account.
• Use IAM Access Analyzer to review policies and identify unintended access.

5. RDS & Aurora

🔄 High Availability vs. Scalability (The MOST important RDS topic)

✨ Amazon Aurora

• AWS's own high-performance, cloud-native database. Compatible with MySQL and PostgreSQL.
• Key Advantages over standard RDS:
  • Performance: Up to 5x faster than MySQL, 3x faster than PostgreSQL.
  • Storage: Auto-scales up to 128 TB. More resilient (copies data 6 times across 3 AZs).
  • Replicas: Supports up to 15 low-latency read replicas (vs. 5 for RDS).
  • Aurora Serverless: Automatically starts up, shuts down, and scales capacity based on application demand. Great for intermittent or unpredictable workloads.

🔌 RDS Proxy

• A fully managed, highly available database proxy for RDS.
• Main Purpose: To pool and share database connections, improving scalability.
• Key Use Case: For applications with many concurrent connections, especially **Lambda**, which can quickly exhaust database connection limits.

6. AWS Lambda - Serverless Compute

                        ┌────────────────────────────────────────────────────────────────┐
                        │ TRADITIONAL SERVER                  vs.        LAMBDA          │
                        ├────────────────────────────────────────────────────────────────┤
                        │ Rent whole building 24/7                  Pay per task         │
                        │ Manage infrastructure                     AWS handles servers  │
                        │ Scale manually                            Auto-scales          │
                        │ Idle cost = $$$$                          Idle cost = $0       │
                        └────────────────────────────────────────────────────────────────┘
                        
                        EVENT SOURCES (Triggers):
                        ┌──────────────┐     ┌──────────────┐     ┌──────────────┐
                        │ API Gateway  │────▶│   LAMBDA     │────▶│  DynamoDB   │
                        │   (HTTP)     │     │  (Process)   │     │   (Store)   │
                        └──────────────┘     └──────────────┘     └──────────────┘
                               │                    ▲                     │
                               │                    │                     │
                        ┌──────▼────────┐    ┌──────┴─────────┐   ┌──────▼────────┐
                        │  S3 Events    │    │  EventBridge   │   │  DDB Streams  │
                        │ (File upload) │    │  (Scheduled)   │   │  (Changes)    │
                        └───────────────┘    └────────────────┘   └───────────────┘
                                    

📚 Core Concepts

• Lambda Function: Your code + runtime + configuration. Executes in response to events.
• Execution Models:
  • Synchronous (Request-Response): Caller waits for response (e.g., API Gateway, ALB, Cognito)
  • Asynchronous (Event-based): Lambda queues event, returns immediately (e.g., S3, SNS, EventBridge)
  • Stream/Poll-based: Lambda polls source and invokes function (e.g., DynamoDB Streams, Kinesis, SQS)
• Cold Start vs. Warm Start:
  • Cold Start: First request or after idle period. AWS must provision execution environment (~100-1000ms)
  • Warm Start: Execution environment already exists. Much faster (~1-10ms)
  • Provisioned Concurrency: Pre-warm functions to eliminate cold starts (costs more)

⚡ Lambda Limits (MEMORIZE THESE!)

🔗 Lambda Integration Patterns (High Exam Probability)

Pattern 1: Serverless Web API

                        User Request → API Gateway → Lambda → DynamoDB
                                     ↓
                                CloudFront (optional caching)
                                
                        Use Case: REST API, mobile backend, single-page apps
                        Benefits: Auto-scaling, pay-per-request, no server management
                        Exam Keywords: "serverless", "cost-effective API", "scales to zero"
                                    

Pattern 2: Real-time File Processing

                        S3 (Upload) → Lambda (Process) → S3 (Output)
                                         ↓
                                    SNS (Notify completion)
                                
                        Use Case: Image thumbnails, video transcoding, data transformation
                        Benefits: Event-driven, parallel processing
                        Exam Keywords: "process uploaded files", "trigger on S3 event"
                                    

Pattern 3: Stream Processing

                        DynamoDB Streams → Lambda → ElastiCache/S3/Another DDB
                        Kinesis Data Stream → Lambda → Data Lake (S3)
                        
                        Use Case: Real-time analytics, data replication, audit logging
                        Benefits: Batch processing, automatic retries
                        Exam Keywords: "real-time data processing", "react to changes"
                                    

Pattern 4: Scheduled Tasks

                        EventBridge (Cron) → Lambda → Task (backup, cleanup, reports)
                        
                        Use Case: Scheduled backups, daily reports, cleanup jobs
                        Benefits: No server to maintain, runs only when needed
                        Exam Keywords: "scheduled task", "cron job", "run daily/hourly"
                                    

🛡️ Lambda Security & Best Practices

• Execution Role (IAM Role): Grants Lambda permission to access AWS services (e.g., read from S3, write to DynamoDB). **ALWAYS use IAM roles, NEVER hardcode credentials.**
• Resource-based Policy: Controls who/what can invoke the Lambda function (e.g., allow API Gateway, S3 bucket).
• VPC Integration:
  • By default, Lambda runs in AWS-managed VPC (has internet access, but no access to your VPC resources)
  • Configure Lambda to run in YOUR VPC to access RDS, ElastiCache, or internal APIs
  • ⚠️ VPC Lambda needs NAT Gateway for internet access (or VPC Endpoints for AWS services)
• Environment Variables: Store configuration. Can be encrypted with KMS.
• Lambda Layers: Share code/dependencies across multiple functions (e.g., common libraries, SDKs).
• Versions & Aliases:
  • Version: Immutable snapshot of function code + config
  • Alias: Pointer to a version (e.g., "prod" → v3, "dev" → v5). Supports weighted traffic splitting for blue/green deployments

💰 Lambda Pricing & Cost Optimization

• Pricing Model:
  • Number of requests: $0.20 per 1M requests
  • Duration: Charged per GB-second (memory × execution time)
  • Free Tier: 1M requests/month + 400,000 GB-seconds/month
• Cost Optimization Tips:
  • Right-size memory (more memory = faster execution = lower cost)
  • Reduce cold starts with Provisioned Concurrency (only for critical workloads)
  • Use Lambda Layers to reduce deployment package size
  • Set appropriate timeout to avoid paying for stuck functions

7. CloudWatch & Monitoring

                        ┌────────────────────────────────────────────────────────────────┐
                        │                    CLOUDWATCH ECOSYSTEM                        │
                        ├────────────────────────────────────────────────────────────────┤
                        │                                                                │
                        │  📹 CloudWatch LOGS          📊 CloudWatch METRICS             │
                        │  (What happened?)            (How much/many?)                  │
                        │  - Application logs          - CPU, Memory, Network            │
                        │  - System logs               - Custom business metrics         │
                        │  - VPC Flow Logs             - Auto Scaling triggers           │
                        │                                                                │
                        │  🚨 CloudWatch ALARMS        ⏰ EventBridge (CloudWatch Events)│
                        │  (Alert me when...)          (Do something when...)            │
                        │  - Threshold breached        - Schedule (cron)                 │
                        │  - SNS notification          - Trigger Lambda                  │
                        │  - Auto Scaling action       - Event patterns                  │
                        │                                                                │
                        │  📈 CloudWatch DASHBOARDS    🔍 CloudWatch Insights            │
                        │  (Visualization)             (Query & analyze logs)            │
                        └────────────────────────────────────────────────────────────────┘
                                    

📊 CloudWatch Metrics

• What are Metrics? Time-ordered data points (e.g., CPU utilization over time).
• Default Metrics: AWS services automatically send metrics to CloudWatch
  • EC2: CPU, Network, Disk I/O (every 5 minutes, or 1 minute with detailed monitoring)
  • ⚠️ EC2 does NOT send memory/disk usage by default! Need CloudWatch Agent.
  • RDS: Database connections, CPU, storage
  • Lambda: Invocations, duration, errors, throttles
  • S3: Storage metrics, request metrics
• Custom Metrics: Send your own application metrics using PutMetricData API or CloudWatch Agent.
  • Standard Resolution: 1-minute granularity
  • High Resolution: Up to 1-second granularity

🚨 CloudWatch Alarms

• Purpose: Trigger actions based on metric thresholds.
• States:
  • OK: Metric is within threshold
  • ALARM: Metric breached threshold
  • INSUFFICIENT_DATA: Not enough data to evaluate
• Actions:
  • Send notification to SNS (email, SMS, Lambda)
  • Trigger Auto Scaling policy
  • Perform EC2 action (stop, terminate, reboot, recover)
• Composite Alarms: Combine multiple alarms with AND/OR logic to reduce alarm noise.

📝 CloudWatch Logs

• Structure:
  • Log Group: Collection of log streams (e.g., `/aws/lambda/my-function`)
  • Log Stream: Sequence of log events from same source (e.g., each Lambda execution)
  • Log Event: Single log entry with timestamp and message
• Sources:
  • Lambda functions (automatic)
  • EC2 instances (via CloudWatch Agent)
  • ECS/EKS containers
  • VPC Flow Logs
  • CloudTrail (API audit logs)
  • Route 53 DNS query logs
• CloudWatch Logs Insights: Query language to search and analyze logs

                          fields @timestamp, @message
                          | filter @message like /ERROR/
                          | sort @timestamp desc
                          | limit 20
                                          

• Log Retention: Configurable from 1 day to 10 years, or never expire. Costs increase with retention period.
• Export & Archive:
  • Export to S3 for long-term storage (cheaper than CloudWatch Logs)
  • Stream to Kinesis, Lambda, or Elasticsearch for real-time analysis

⏰ EventBridge (formerly CloudWatch Events)

• Purpose: Serverless event bus for building event-driven applications.
• Event Sources:
  • AWS Services: EC2 state change, S3 upload, CodePipeline stage change, etc.
  • Schedule: Cron expressions or rate expressions (e.g., "every 5 minutes")
  • Custom Applications: Your app sends events via PutEvents API
  • SaaS Integrations: Zendesk, Datadog, Auth0, etc.
• Targets: Lambda, SQS, SNS, Kinesis, Step Functions, ECS Tasks, etc.
• Event Pattern Matching: Filter events based on JSON structure

                          {
                            "source": ["aws.ec2"],
                            "detail-type": ["EC2 Instance State-change Notification"],
                            "detail": {
                              "state": ["terminated"]
                            }
                          }
                                          

                        Application → Custom Metric (Active Users) → CloudWatch Alarm 
                                                                    ↓
                                                            Auto Scaling Policy
                                                                    ↓
                                                            Scale EC2/ECS tasks
                        
                        Use Case: Scale based on business metrics, not just CPU
                        Exam Keywords: "scale based on queue length", "active connections"
                                    

                        Multiple EC2/ECS → CloudWatch Logs → CloudWatch Logs Insights (Query)
                                                           ↓
                                                    S3 (Archive, Athena analysis)
                        
                        Use Case: Aggregate logs from multiple sources, long-term storage
                        Exam Keywords: "centralized logging", "log aggregation", "analyze logs"
                                    

                        AWS Event → EventBridge → Lambda → Remediation Action
                        (e.g., EC2 stopped → detect → restart instance)
                        
                        Use Case: Auto-recover from failures, compliance enforcement
                        Exam Keywords: "automated response", "self-healing", "compliance automation"
                                    

                        EventBridge (Cron: 0 2 * * ? *) → Lambda → Backup/Cleanup Task
                        
                        Use Case: Daily backups, weekly reports, monthly cleanup
                        Exam Keywords: "scheduled", "run every day/week", "cron job"
                                    

🔧 CloudWatch Agent

• Purpose: Collect additional metrics and logs from EC2 and on-premises servers.
• What it collects:
  • System-level metrics: Memory usage, disk usage, swap usage (NOT available by default)
  • Custom metrics: Application-specific metrics
  • Log files: Application logs, system logs
• Configuration: JSON config file, can be stored in Parameter Store for easy deployment.

🆚 CloudWatch vs. CloudTrail vs. Config

Security Services - Deep Dive

                        ┌────────────────────────────────────────────────────────────────┐
                        │                    SECURITY LAYERS                             │
                        ├────────────────────────────────────────────────────────────────┤
                        │                                                                │
                        │  🔐 LAYER 1: ENCRYPTION (Data Protection)                      │
                        │  ┌──────────────────────────────────────────────────────┐      │
                        │  │ KMS → Manages encryption keys                         │      │
                        │  │ CloudHSM → Hardware security module for compliance   │      │
                        │  └──────────────────────────────────────────────────────┘      │
                        │                                                                │
                        │  🔑 LAYER 2: SECRETS & CREDENTIALS                             │
                        │  ┌──────────────────────────────────────────────────────┐      │
                        │  │ Secrets Manager → Rotate DB passwords, API keys      │      │
                        │  │ Parameter Store → Store config, lightweight secrets  │      │
                        │  └──────────────────────────────────────────────────────┘      │
                        │                                                                │
                        │  🔍 LAYER 3: AUDIT & COMPLIANCE                                │
                        │  ┌──────────────────────────────────────────────────────┐      │
                        │  │ CloudTrail → WHO did WHAT (API audit)                │      │
                        │  │ Config → Resource config compliance                  │      │
                        │  │ GuardDuty → Threat detection (ML-based)              │      │
                        │  └──────────────────────────────────────────────────────┘      │
                        │                                                                │
                        │  🛡️ LAYER 4: NETWORK PROTECTION                                │
                        │  ┌──────────────────────────────────────────────────────┐      │
                        │  │ WAF → Web app firewall (SQL injection, XSS)          │      │
                        │  │ Shield → DDoS protection                             │      │
                        │  │ Firewall Manager → Centralized firewall rules        │      │
                        │  └──────────────────────────────────────────────────────┘      │
                        └────────────────────────────────────────────────────────────────┘
                                    

🔐 AWS KMS (Key Management Service)

Core Concepts

• Purpose: Managed service to create and control encryption keys.
• Key Types:
  • AWS Managed Keys: Free, automatic rotation, used by AWS services (e.g., `aws/s3`, `aws/rds`)
  • Customer Managed Keys (CMK): You control rotation, key policies, and audit. This is what you use for custom encryption.
  • AWS Owned Keys: Used internally by AWS, you can't view or manage
  • Custom Key Store (CloudHSM): For regulatory compliance requiring dedicated hardware
• Key Material Origin:
  • KMS: AWS generates key material (default, recommended)
  • External: You import your own key material
  • CloudHSM: Key material in dedicated HSM cluster

⚡ Envelope Encryption (Critical Concept)

                        WHY ENVELOPE ENCRYPTION?
                        - Encrypting large data with KMS is slow (4KB limit per API call)
                        - Solution: Use data key to encrypt data, use master key to encrypt data key
                        
                        PROCESS:
                        1. Call KMS GenerateDataKey → Get plaintext + encrypted data key
                        2. Use plaintext data key to encrypt your file locally
                        3. Store encrypted file + encrypted data key together
                        4. Delete plaintext data key from memory
                        
                        DECRYPTION:
                        1. Call KMS Decrypt with encrypted data key → Get plaintext data key
                        2. Use plaintext data key to decrypt file
                        3. Delete plaintext data key from memory
                        
                        ┌─────────────────────────────────────────────────────────┐
                        │  KMS Master Key (never leaves KMS)                      │
                        │         │                                               │
                        │         ├──▶ Encrypts Data Key                          │
                        │         │                                               │
                        │  Data Key (plaintext) ──▶ Encrypts actual data         │
                        │                                                         │
                        │  Stored: Encrypted Data + Encrypted Data Key           │
                        └─────────────────────────────────────────────────────────┘
                                    

🔑 Key Policies & Permissions

• Key Policy: Resource-based policy attached to KMS key. Required for all KMS keys.
  • Defines who can use and manage the key
  • Default: Root account has full access
• Grants: Temporary, programmatic permissions (used by AWS services)
• IAM Policies: Work together with key policies (both must allow)

📊 KMS Integration with AWS Services

🔄 Key Rotation

• Automatic Rotation (Customer Managed Keys):
  • Enabled per key, rotates every 1 year
  • AWS keeps old key versions for decryption
  • No application changes needed
• Manual Rotation:
  • Create new key, update applications to use new key
  • Use key aliases to simplify rotation
• AWS Managed Keys: Automatically rotated every 3 years (you can't change this)

🔑 Secrets Manager vs. Parameter Store

Decision Tree: When to use which?

                        Question: Do you need AUTOMATIC ROTATION?
                        │
                        ├─ YES → Secrets Manager
                        │   └─ Examples: RDS passwords, 3rd party API keys
                        │
                        └─ NO → Do you need to store secrets?
                            │
                            ├─ YES → Parameter Store (SecureString)
                            │   └─ Examples: Static passwords, connection strings
                            │
                            └─ NO (just config) → Parameter Store (String)
                                └─ Examples: App settings, feature flags, URLs
                                

                        Secrets Manager (RDS password, auto-rotate every 30 days)
                                 ↓
                        Lambda function (retrieves secret at runtime)
                                 ↓
                        RDS (connects with fresh password)
                        
                        Exam Keywords: "rotate database password", "Lambda + RDS security"
                                    

                        Account A: Secrets Manager secret
                                 ↓ (resource policy allows Account B)
                        Account B: Lambda function retrieves secret
                        
                        Exam Keywords: "cross-account secret access", "central secrets management"
                                    

📋 AWS CloudTrail - API Audit Logging

• Purpose: Records AWS API calls for audit and compliance. Answers "WHO did WHAT, WHEN, and from WHERE".
• What it logs:
  • User identity (who made the call)
  • Time of request
  • Source IP address
  • Request parameters
  • Response elements
• Trail Types:
  • Management Events: Control plane operations (e.g., CreateBucket, TerminateInstance)
  • Data Events: Data plane operations (e.g., GetObject, PutObject in S3, Lambda invocations) - High volume, costs more
  • Insights Events: Detect unusual activity (e.g., burst of IAM actions, spike in resource provisioning)
• Storage: Logs delivered to S3 bucket (can encrypt with SSE-S3 or SSE-KMS). Can also stream to CloudWatch Logs.
• Log File Integrity: Optional validation to detect if logs were modified or deleted.

🔧 AWS Config - Resource Configuration Compliance

• Purpose: Continuously monitor and record AWS resource configurations. Evaluate compliance against desired configurations.
• What it does:
  • Tracks configuration changes over time (who changed what security group rule?)
  • Evaluates resources against Config Rules (managed or custom)
  • Generates compliance reports
  • Can trigger auto-remediation (e.g., via Lambda or Systems Manager)
• Config Rules Examples:
  • Is S3 bucket public? (s3-bucket-public-read-prohibited)
  • Are EBS volumes encrypted? (encrypted-volumes)
  • Is MFA enabled for root account? (root-account-mfa-enabled)
  • Is CloudTrail enabled? (cloudtrail-enabled)
• Aggregator: Centralize Config data from multiple accounts and regions.

🛡️ GuardDuty - Threat Detection

• Purpose: Intelligent threat detection service using ML. Monitors for malicious activity and unauthorized behavior.
• Data Sources:
  • VPC Flow Logs (unusual network traffic)
  • CloudTrail logs (suspicious API calls)
  • DNS logs (queries to malicious domains)
• Findings: GuardDuty generates findings for detected threats (e.g., EC2 instance communicating with known malware C&C server).
• Integration: Send findings to EventBridge → Lambda/SNS for automated remediation.
• Pricing: Pay per million events analyzed. No upfront cost, no infrastructure to manage.

🔒 WAF & Shield - Web Application Protection

• AWS WAF (Web Application Firewall):
  • Protects web apps from common exploits (SQL injection, XSS, etc.)
  • Rules based on IP, geo, rate limiting, request patterns
  • Integrates with: CloudFront, ALB, API Gateway, AppSync
  • Managed Rules: Pre-configured rule sets (AWS or marketplace)
• AWS Shield:
  • Shield Standard: Free, automatic DDoS protection for all AWS customers
  • Shield Advanced: $3,000/month, enhanced DDoS protection + 24/7 DDoS response team (DRT), cost protection

🆚 Security Services Comparison

TIER 2 - ARCHITECTURAL BUILDING BLOCKS (20-25% điểm)

8. Route 53 - Global DNS

• Core Function: Domain Name System (DNS) service. Translates domain names (e.g., `www.amazon.com`) to IP addresses.
• Key Feature for SAA: Routing Policies

  ?? Memory Toolkit (Route 53)

  • Analogy: Global switchboard operator deciding which branch picks up each call.
  • Mnemonic: "Fail-Lat-Weight-Location-Simple-Steer" sequence to recall every routing policy.
  • Red-Flag Keywords: "active/passive" -> Failover, "closest region" -> Latency/Geolocation, "test new version" -> Weighted.
  • Self-Check: Note the decision driver: health, geography, performance, or experiment? Then choose the matching policy.
  • Simple: Default. Route traffic to a single resource.
  • Failover: Active-Passive. Redirects traffic to a secondary resource if the primary is unhealthy. Used for DR.
  • Geolocation: Route traffic based on the user's geographic location (e.g., continent, country).
  • Geoproximity: Route traffic based on the location of your resources, can shift traffic with biases.
  • Latency: Route traffic to the AWS region with the lowest latency for the user.
  • Weighted: Distribute traffic across multiple resources based on a specified weight (e.g., 80% to A, 20% to B). Used for A/B testing or blue-green deployments.

7. Decoupling Services (SQS & SNS)

Event Source --> SNS Topic --> SQS Queue A --> Processor A
\--> SQS Queue B --> Processor B
\--> SQS Queue C --> Processor C
            

8. CloudFront - Content Delivery Network (CDN)

• Purpose: Caches content at Edge Locations around the world to reduce latency for users.
• Origin: The source of the files for the CDN. Can be an S3 bucket, an EC2 instance, an ELB, or any custom HTTP server.
• Key Use Case:
  • Speed up delivery of static content (images, videos, CSS) from S3.
  • Cache dynamic content from an ALB or EC2 instance.
• Security: Can use AWS WAF (Web Application Firewall) for protection. Can restrict access to S3 origins using an **Origin Access Identity (OAI)**.

CloudFormation & Infrastructure as Code

                        ┌────────────────────────────────────────────────────────────────┐
                        │ TRADITIONAL (Manual)        vs.     CloudFormation (IaC)       │
                        ├────────────────────────────────────────────────────────────────┤
                        │ Click in console                    Write template (YAML/JSON) │
                        │ Manual steps                        Automated deployment       │
                        │ Hard to replicate                   Version controlled         │
                        │ Prone to errors                     Consistent & repeatable    │
                        │ No audit trail                      Full change history        │
                        └────────────────────────────────────────────────────────────────┘
                        
                        CLOUDFORMATION WORKFLOW:
                        ┌──────────────┐      ┌──────────────┐      ┌──────────────┐
                        │   Template   │─────▶│    Stack     │─────▶│  Resources   │
                        │ (YAML/JSON)  │      │  (Created)   │      │   (Running)  │
                        └──────────────┘      └──────────────┘      └──────────────┘
                                                     │
                                                     ├─ Update Stack → Change Set (preview)
                                                     ├─ Delete Stack → All resources deleted
                                                     └─ Rollback on failure (automatic)
                                    

📚 Core Concepts

• Template: JSON or YAML file that describes your infrastructure.
  • Resources: (Required) AWS resources to create (EC2, S3, RDS, etc.)
  • Parameters: Input values to customize templates (e.g., instance type, key name)
  • Mappings: Fixed variables, conditional values (e.g., AMI per region)
  • Outputs: Values to export (e.g., Load Balancer DNS name)
  • Conditions: Control resource creation based on parameters
• Stack: A collection of AWS resources managed as a single unit. Created from a template.
• Stack Set: Deploy stacks across multiple accounts and regions from a single template.

⚙️ Key CloudFormation Features

1. Change Sets (Preview Changes)

• Before updating a stack, create a Change Set to preview what will change.
• Shows: Resources to be added, modified, replaced, or deleted.
• ⚠️ Replacement means resource will be deleted and recreated (can cause downtime!).

2. DependsOn Attribute

• Explicitly declare dependency between resources.
• By default, CloudFormation creates resources in parallel. Use DependsOn to enforce order.
• Example: Create RDS instance only after security group is created.

                        Resources:
                          MyDB:
                            Type: AWS::RDS::DBInstance
                            DependsOn: MySecurityGroup  # Wait for SG first
                            Properties:
                              ...
                                

3. DeletionPolicy

• Controls what happens to a resource when its stack is deleted.
• Delete: (Default) Resource is deleted with stack
• Retain: Resource is kept even after stack deletion (e.g., S3 bucket with important data)
• Snapshot: Create snapshot before deletion (RDS, EBS, Redshift)

                        Resources:
                          MyDatabase:
                            Type: AWS::RDS::DBInstance
                            DeletionPolicy: Snapshot  # Create snapshot before deleting
                                

4. UpdateReplacePolicy

• Similar to DeletionPolicy, but applies when resource is replaced during stack update.
• Use Snapshot to preserve data before replacement.

5. Stack Policy

• Prevents accidental updates or deletes of critical resources.
• JSON document that defines which resources can be updated.
• Example: Protect production database from accidental updates.

6. Drift Detection

• Detects if resources were manually modified outside CloudFormation.
• Compares current state vs. template definition.
• Use Case: Ensure infrastructure matches IaC template (detect manual changes).

7. Rollback Behavior

• Create Failure: Rollback enabled by default (deletes all created resources)
• Update Failure: Rollback to previous working state
• Continue Update Rollback: If rollback itself fails, manually fix and continue
• ⚠️ Can disable rollback for troubleshooting (not recommended for production)

🔗 Cross-Stack References

• Share resources between stacks using Outputs and Import.
• Stack A exports a value (e.g., VPC ID)
• Stack B imports that value

                        # Stack A (Network Stack)
                        Outputs:
                          VPCId:
                            Value: !Ref MyVPC
                            Export:
                              Name: NetworkStack-VPCID
                        
                        # Stack B (App Stack)
                        Resources:
                          MyInstance:
                            Type: AWS::EC2::Instance
                            Properties:
                              SubnetId: !ImportValue NetworkStack-VPCID
                                

🆚 CloudFormation vs. Other Deployment Tools

When to use what?

                        CloudFormation:
                        - Full control over infrastructure
                        - Complex multi-tier architectures
                        - Need to manage 10+ AWS resources together
                        - Version control and audit trail required
                        
                        Elastic Beanstalk:
                        - "Just deploy my app, I don't care about infrastructure"
                        - Standard web apps (Node.js, Python, Java, .NET, PHP, Ruby, Go)
                        - Auto-scaling, load balancing handled automatically
                        - Developer-friendly, less control
                        
                        SAM:
                        - Serverless applications (Lambda + API Gateway + DynamoDB)
                        - Simplified syntax for serverless (less boilerplate than CloudFormation)
                        - Local testing with SAM CLI
                        
                        Exam Decision Tree:
                        Question mentions "infrastructure as code" + complex resources → CloudFormation
                        Question mentions "developer wants to deploy app easily" → Elastic Beanstalk
                        Question mentions "serverless" + "simplified template" → SAM
                                

💡 Advanced CloudFormation Concepts

Nested Stacks

• Stack that creates other stacks as resources.
• Use Case: Reusable components (e.g., common VPC template used by multiple stacks).
• Benefit: Modular, easier to maintain.
• ⚠️ Parent stack manages lifecycle of nested stacks.

StackSets

• Deploy same stack across multiple accounts and regions from a single template.
• Use Case: Multi-account governance, compliance (e.g., deploy CloudTrail to all accounts).
• Requires AWS Organizations or manual permission setup.

Custom Resources

• Extend CloudFormation to manage resources not natively supported.
• Backed by Lambda or SNS.
• Example: Call external API, clean up S3 bucket before deletion, fetch data from DynamoDB.

🔍 Troubleshooting CloudFormation

TIER 3 - SPECIALIZED SERVICES (5-10% điểm)

Containers - ECS & Fargate

                        ┌────────────────────────────────────────────────────────────────┐
                        │               AWS CONTAINER SERVICES                           │
                        ├────────────────────────────────────────────────────────────────┤
                        │                                                                │
                        │  🐳 ECS (Elastic Container Service)                            │
                        │  ├─ ECS on EC2: You manage EC2 instances                       │
                        │  │  └─ More control, can use Reserved Instances/Spot          │
                        │  └─ ECS on Fargate: Serverless, AWS manages infrastructure     │
                        │     └─ No EC2 management, pay per task                         │
                        │                                                                │
                        │  ☸️ EKS (Elastic Kubernetes Service)                            │
                        │  └─ Managed Kubernetes for complex container orchestration    │
                        │     └─ Use if you need Kubernetes, multi-cloud portability    │
                        │                                                                │
                        │  📦 ECR (Elastic Container Registry)                            │
                        │  └─ Docker image registry (like Docker Hub)                   │
                        │     └─ Store and manage container images                      │
                        └────────────────────────────────────────────────────────────────┘
                        
                        ARCHITECTURE:
                        ┌──────────────────────────────────────────────────────────────┐
                        │  ALB (Load Balancer)                                         │
                        │    ↓                                                         │
                        │  ECS Service (maintains desired count of tasks)             │
                        │    ↓                                                         │
                        │  ECS Tasks (running containers)                             │
                        │    ├─ Task 1 (Container A + Container B)                    │
                        │    ├─ Task 2 (Container A + Container B)                    │
                        │    └─ Task 3 (Container A + Container B)                    │
                        │    ↓                                                         │
                        │  Launch Type: EC2 (your instances) or Fargate (serverless)  │
                        └──────────────────────────────────────────────────────────────┘
                                    

📚 Core ECS Concepts

• Task Definition: Blueprint for your application. Defines:
  • Docker image to use
  • CPU & memory requirements
  • Environment variables
  • Networking mode
  • IAM role for task
• Task: Instance of a task definition. One or more containers running together.
• Service: Manages long-running tasks. Ensures desired number of tasks are running.
  • Integrates with ELB for load balancing
  • Auto-restart failed tasks
  • Auto Scaling based on metrics
• Cluster: Logical grouping of tasks or services. Can span multiple AZs.

⚖️ ECS Launch Types

🆚 ECS vs EKS vs Lambda

Decision Tree:

                        Need to run containers?
                        │
                        ├─ NO → Use EC2 or Lambda
                        │
                        └─ YES → Do you already use Kubernetes?
                            │
                            ├─ YES → EKS (Elastic Kubernetes Service)
                            │
                            └─ NO → Do you want to manage EC2 instances?
                                │
                                ├─ YES → ECS on EC2 (cost optimization with RI/Spot)
                                │
                                └─ NO → ECS on Fargate (serverless, simplest)
                                

📦 ECR (Elastic Container Registry)

• Purpose: Fully managed Docker container registry (alternative to Docker Hub).
• Features:
  • Store, manage, and deploy Docker images
  • Integration with ECS/EKS
  • Encryption at rest (S3) and in transit (TLS)
  • Image scanning for vulnerabilities
  • Lifecycle policies (auto-delete old images)
• Access Control: IAM-based. Cross-account access via repository policies.

🔗 ECS Integration Patterns

Pattern 1: Microservices with ALB

                        ALB (Path-based routing)
                         ├─ /api/users → ECS Service A (User microservice)
                         ├─ /api/orders → ECS Service B (Order microservice)
                         └─ /api/products → ECS Service C (Product microservice)
                        
                        Each service:
                        - ECS Service with Auto Scaling
                        - Fargate tasks in multiple AZs
                        - Connected to RDS/DynamoDB
                        
                        Exam Keywords: "microservices", "containerized", "path-based routing"
                                    

Pattern 2: Batch Processing

                        S3 Event → EventBridge → ECS Task (Fargate, run once)
                                                   ↓
                                            Process file → Output to S3
                        
                        Use Case: Video transcoding, image processing, data transformation
                        Exam Keywords: "batch", "event-driven containers", "run once"
                                    

Data Streaming - Kinesis Family

                        ┌────────────────────────────────────────────────────────────────┐
                        │                    KINESIS FAMILY                              │
                        ├────────────────────────────────────────────────────────────────┤
                        │                                                                │
                        │  📊 Kinesis Data Streams                                       │
                        │  ├─ Real-time data streaming (custom processing)              │
                        │  ├─ Retain data 1-365 days                                    │
                        │  ├─ Manual scaling (shards)                                   │
                        │  └─ Use: Custom real-time analytics, complex processing       │
                        │                                                                │
                        │  🚰 Kinesis Data Firehose                                      │
                        │  ├─ Load streaming data to destinations                       │
                        │  ├─ Near real-time (60s buffer)                               │
                        │  ├─ Auto-scaling (serverless)                                 │
                        │  └─ Use: Load data to S3, Redshift, Elasticsearch, Splunk     │
                        │                                                                │
                        │  🔬 Kinesis Data Analytics                                     │
                        │  ├─ SQL queries on streaming data                             │
                        │  ├─ Real-time dashboards                                      │
                        │  └─ Use: Real-time metrics, anomaly detection                 │
                        │                                                                │
                        │  📹 Kinesis Video Streams                                      │
                        │  └─ Capture, process, store video streams                     │
                        │     └─ Use: IoT, security cameras, ML on video                │
                        └────────────────────────────────────────────────────────────────┘
                        
                        DATA FLOW COMPARISON:
                        ┌───────────────────────────────────────────────────────────────┐
                        │ Kinesis Data Streams:                                         │
                        │ Producers → Data Stream (shards) → Consumers (custom apps)   │
                        │              ↓ (store 1-365 days)                             │
                        │            Lambda/KCL                                          │
                        │                                                               │
                        │ Kinesis Firehose:                                             │
                        │ Producers → Firehose → S3/Redshift/Elasticsearch/Splunk      │
                        │              ↓ (optional Lambda transform)                    │
                        │          No storage, direct delivery                          │
                        └───────────────────────────────────────────────────────────────┘
                                    

📊 Kinesis Data Streams (Deep Dive)

• Purpose: Real-time data streaming for custom processing. You write the consumer code.
• Key Concepts:
  • Shard: Unit of capacity. Each shard: 1 MB/s write, 2 MB/s read, 1000 records/s write.
  • Partition Key: Determines which shard data goes to. Same key = same shard (ordered within shard).
  • Retention: 24 hours (default), up to 365 days.
• Producers: Applications, Kinesis Agent, SDK, Kinesis Producer Library (KPL)
• Consumers:
  • Lambda: Serverless, auto-scales
  • KCL (Kinesis Client Library): Java library for custom consumers on EC2/ECS
  • Kinesis Data Analytics: SQL queries
  • Kinesis Firehose: Forward to destinations
• Scaling: Add/remove shards manually (resharding). Split (increase) or merge (decrease) shards.

🚰 Kinesis Data Firehose

• Purpose: Easiest way to load streaming data to data stores. Fully managed, auto-scales.
• Destinations:
  • AWS: S3, Redshift (via S3), Elasticsearch, Splunk
  • 3rd party: Datadog, New Relic, MongoDB, Splunk
  • Custom: HTTP endpoints
• Near Real-Time: Buffers data (60 seconds minimum or 1 MB minimum). Not real-time!
• Data Transformation: Optional Lambda function to transform records before delivery.
• No Data Retention: Data is delivered, not stored in Firehose.
• Pricing: Pay for data volume processed.

⚖️ Data Streams vs Firehose (Critical Comparison)

🔬 Kinesis Data Analytics

• Purpose: Run SQL queries on streaming data. No need to write consumer code.
• Input: Kinesis Data Streams or Firehose
• Output: Kinesis Data Streams, Firehose, or Lambda
• Use Cases:
  • Real-time dashboards
  • Real-time metrics (e.g., top 10 products sold in last 5 minutes)
  • Anomaly detection
  • Time-series analytics
• Pricing: Pay for resources consumed (processing units).

🔗 Common Kinesis Patterns

Pattern 1: Real-time Analytics Pipeline

                        IoT Devices → Kinesis Data Streams → Lambda (process) → DynamoDB
                                                            ↓
                                                  Kinesis Data Analytics (SQL)
                                                            ↓
                                                      QuickSight (Dashboard)
                        
                        Use Case: IoT sensor data, real-time monitoring, live dashboards
                        Exam Keywords: "real-time analytics", "streaming data", "dashboard"
                                    

Pattern 2: Data Lake Ingestion

                        Application Logs → Kinesis Firehose → S3 (Data Lake)
                                                  ↓                ↓
                                           (optional Lambda)    Athena (query)
                                                                  ↓
                                                            QuickSight (reports)
                        
                        Use Case: Log aggregation, batch analytics, data warehousing
                        Exam Keywords: "load to S3", "data lake", "batch analysis"
                                    

Pattern 3: Real-time ETL

                        Data Sources → Kinesis Firehose → Lambda (transform) → Redshift
                                                                             ↓
                                                                           S3 backup
                        
                        Use Case: Data warehouse, business intelligence
                        Exam Keywords: "transform and load", "Redshift", "ETL"
                                    

DynamoDB - Managed NoSQL Database

• Type: Fully managed, key-value and document NoSQL database.
• Key Features: Single-digit millisecond latency, fully serverless, auto-scaling.
• When to use it? When you need extreme scalability and performance for simple key-value lookups. Not suitable for complex relational queries (JOINs).
• DAX (DynamoDB Accelerator): An in-memory cache for DynamoDB, providing microsecond read performance.

10. EFS & FSx - Managed File Systems

11. ElastiCache - In-Memory Caching

• Purpose: A managed in-memory data store or cache to improve the performance of web applications.
• Engines:
  • Redis: More advanced data types, replication, high availability.
  • Memcached: Simpler, multi-threaded performance.
• Use Case: Offload read traffic from a database (like RDS) to reduce latency and cost.

🔄 ARCHITECTURAL DECISION MAKING

Start: What are your RTO/RPO requirements?
(RTO: Recovery Time Objective, RPO: Recovery Point Objective)
|
+-- RTO: Hours, RPO: Hours (Low cost, tolerant of downtime)
| `-- Backup and Restore
| `-- Regularly back up data (S3, EBS Snapshots) and restore to a new region when needed.
|
+-- RTO: Tens of minutes, RPO: Minutes (Core services running)
| `-- Pilot Light
| `-- Replicate data to the DR region. Keep a minimal version of the environment (the "pilot light") running.
|
+-- RTO: Minutes, RPO: Seconds (Scaled-down, fully functional copy)
| `-- Warm Standby
| `-- A scaled-down but fully functional copy of your production environment is always running in the DR region.
|
`-- RTO: Seconds, RPO: Near-zero (Full production scale in both regions)
`-- Multi-Site Active-Active
`-- Traffic is served from both regions simultaneously. Use Route 53 for routing. Most expensive and complex.