SAA-C03 Strict Comparison Tables
Mastering the nuances between similar services is key to passing the AWS Solutions Architect Associate (SAA-C03) exam. Use these strict comparison tables to identify the right service based on specific requirements.
1. NAT Gateway vs. NAT Instance
Scenario: You need to allow instances in a private subnet to access the internet (e.g., for updates) but prevent the internet from accessing those instances.
| Feature | NAT Gateway | NAT Instance |
|---|---|---|
| Primary Use Case | Managed service for outbound internet access from private subnets. | Self-managed EC2 instance configured for NAT. |
| Management | AWS fully manages it (patching, scaling, availability). | You manage it (OS patches, software updates, instance sizing). |
| High Availability | Highly available within an Availability Zone (AZ). | Not highly available out-of-the-box (requires scripts/ASG). |
| Scalability | Scales automatically up to 45 Gbps. | Depends on instance size/type; manual scaling required. |
| Security Groups | Does NOT support Security Groups. | Supports Security Groups. |
| Port Forwarding | Not supported. | Supported (can be used as Bastion). |
| Cost Model | Hourly charge + Data processing charge. | Hourly charge for EC2 instance (+ Data transfer). |
| Key Limitations | Cannot be used by instances in the same subnet. | Throughput limited by instance network bandwidth. |
| Exam 'Trigger Words' | "Managed", "Highly available", "Less admin overhead", "Scale automatically". | "Bastion host", "Port forwarding", "Scripted HA", "Cost optimization" (sometimes cheaper for low traffic). |
2. AWS Global Accelerator vs. Amazon CloudFront
Scenario: You want to improve global performance for your application.
| Feature | Global Accelerator | CloudFront |
|---|---|---|
| Primary Use Case | Improving performance for non-HTTP (TCP/UDP) applications (e.g., gaming, IoT, VoIP) or requiring static IP. | Caching and delivering HTTP/HTTPS content (static & dynamic web assets, video). |
| Mechanism | Uses AWS global network to route traffic to the optimal endpoint via Anycast IP. | Uses Edge Locations to cache content closer to users. |
| Protocol Support | TCP and UDP. | HTTP, HTTPS, WebSocket. |
| IP Addresses | Provides 2 Static Anycast IPs (fixed entry points). | Uses dynamic IPs (changes based on edge location). |
| Origin Masking | Does not cache; always routes to origin (ALB, NLB, EC2, IP). | Caches content at the edge (offloads origin). |
| Cost Model | Hourly charge + Data transfer premium. | Data transfer out + Requests. |
| Exam 'Trigger Words' | "Static IP", "Non-HTTP", "UDP", "Gaming", "Fast failover", "Instant region failover". | "Caching", "Static content", "S3 Website", "CDN", "Edge locations", "Video streaming". |
3. S3 Standard-IA vs. S3 One Zone-IA
Scenario: You want to save costs on infrequently accessed data.
| Feature | S3 Standard-IA (Infrequent Access) | S3 One Zone-IA |
|---|---|---|
| Primary Use Case | Infrequently accessed data that requires multi-AZ resilience (critical data). | Infrequently accessed data that implies re-creatable data or secondary backups. |
| Availability Zones | Stored across minimum 3 AZs. | Stored in only 1 AZ. |
| Durability | 99.999999999% (11 9s). | 99.999999999% (11 9s) (But data lost if AZ destroyed). |
| Availability | 99.9%. | 99.5%. |
| Cost Model | Lower storage cost than Standard, higher retrieval fee. | 20% cheaper storage cost than Standard-IA. |
| Key Limitations | Retrieval fees apply. Minimum 30-day retention. | Risk of data loss if the specific AZ fails. |
| Exam 'Trigger Words' | "Infrequent access", "Multi-AZ", "Critical backup", "Disaster recovery". | "Re-creatable data", "Secondary backup", "Single AZ", "Lowest cost for IA", "Non-critical". |
4. Security Groups vs. Network ACLs (NACLs)
Scenario: You need to secure your VPC networking.
| Feature | Security Group | Network ACL (NACL) |
|---|---|---|
| Level of Control | Instance level (Network Interface). | Subnet level. |
| State | Stateful: Return traffic is automatically allowed. | Stateless: Return traffic must be explicitly allowed. |
| Rules | Allow rules only (Implicit Deny). | Allow and Deny rules. |
| Order of Evaluation | All rules evaluated (permissive). | Numbered list (evaluated in order, stops at first match). |
| Scope | Applies to specific instances assigned to it. | Applies to all instances in the subnet. |
| Impact | Changes take effect immediately. | Changes take effect immediately. |
| Exam 'Trigger Words' | "Instance encryption", "Stateful", "App tier isolation". | "Subnet boundary", "Block specific IP", "Stateless", "Deny rule". |
5. EBS vs. EFS vs. Amazon FSx
Scenario: You need to choose the right file storage for your application.
| Feature | EBS (Elastic Block Store) | EFS (Elastic File System) | Amazon FSx |
|---|---|---|---|
| Primary Use Case | Block storage for single EC2 instance (boot volumes, databases). | Shared file storage for Linux across multiple EC2 instances (NFS). | High-performance file systems (Windows, Lustre, NetApp ONTAP, OpenZFS). |
| Sharing | One instance at a time (except io2 Multi-Attach for specific use cases). | Multiple instances concurrently (thousands). | Multiple instances (Windows Server, Lustre for HPC). |
| OS Compatibility | Linux and Windows. | Linux only (NFS protocol). | Windows (FSx for Windows), Linux (FSx for Lustre, NetApp, OpenZFS). |
| Performance | High IOPS (up to 64,000 with io2 Block Express). | Scales with storage size; Elastic throughput mode. | Extreme performance for HPC (FSx for Lustre), Windows workloads (FSx for Windows). |
| Availability | Single AZ (data replicated within AZ). | Multi-AZ by default (regional service). | Multi-AZ option (FSx for Windows); Single or Multi-AZ (FSx for Lustre). |
| Cost Model | Pay for provisioned capacity (GB-month) + IOPS (io1/io2). | Pay for storage used + throughput. | Pay for storage + throughput + backups. |
| Key Limitations | Cannot be shared across instances (except Multi-Attach). | Linux only. Higher latency than EBS. | More expensive; specific use cases (Windows, HPC). |
| Exam 'Trigger Words' | "Boot volume", "Database", "Single instance", "High IOPS", "Snapshots". | "Shared file storage", "NFS", "Multi-instance", "Linux", "Content management". | "Windows File Server", "SMB", "Lustre", "HPC", "Machine learning", "NetApp". |
6. Application Load Balancer vs. Network Load Balancer vs. Gateway Load Balancer
Scenario: You need to distribute traffic across multiple targets.
| Feature | ALB (Application Load Balancer) | NLB (Network Load Balancer) | GWLB (Gateway Load Balancer) |
|---|---|---|---|
| Primary Use Case | HTTP/HTTPS traffic (Layer 7) with advanced routing (path, host, headers). | Ultra-high performance TCP/UDP traffic (Layer 4) with static IP. | Third-party virtual appliances (firewalls, IDS/IPS) in the traffic path. |
| OSI Layer | Layer 7 (Application). | Layer 4 (Transport). | Layer 3 (Network Gateway) + Layer 4. |
| Protocol Support | HTTP, HTTPS, gRPC, WebSocket. | TCP, UDP, TLS. | IP packets (all protocols). |
| Routing | Path-based, host-based, query string, headers, HTTP method. | IP protocol data only. | Transparent traffic inspection (GENEVE protocol). |
| Static IP | No (uses DNS). | Yes (Elastic IP per AZ). | No. |
| Target Types | EC2, Lambda, IP addresses, ECS containers. | EC2, IP addresses, ALB. | Target is virtual appliances (EC2 instances). |
| Performance | Good (handles millions of requests). | Extreme (handles millions of requests per second, ultra-low latency). | Depends on appliance capacity. |
| SSL/TLS Termination | Yes (offloads SSL from targets). | Yes (TLS termination). | No (passthrough). |
| Cost Model | Hourly charge + LCU (Load Balancer Capacity Units). | Hourly charge + NLCU (Network LCU). | Hourly charge + GLCU (Gateway LCU). |
| Key Limitations | Higher latency than NLB. No static IP. | No content-based routing. No Lambda targets (only ALB as target). | Requires compatible virtual appliances. |
| Exam 'Trigger Words' | "Path-based routing", "Microservices", "Lambda", "HTTP", "HTTPS", "Content-based". | "Static IP", "Extreme performance", "TCP", "UDP", "Gaming", "Low latency", "Millions RPS". | "Third-party firewall", "IDS/IPS", "Inline inspection", "Virtual appliance". |
7. Amazon RDS vs. Amazon DynamoDB
Scenario: You need to choose a managed database.
| Feature | RDS (Relational Database Service) | DynamoDB |
|---|---|---|
| Primary Use Case | Relational (SQL) databases with ACID transactions (MySQL, PostgreSQL, Oracle, SQL Server, MariaDB). | NoSQL key-value and document database for massive scale, low latency. |
| Database Type | Relational (SQL). | NoSQL (key-value, document). |
| Schema | Fixed schema (defined tables, columns). | Schema-less (flexible). |
| Scaling | Vertical (scale instance size); Read replicas for reads. | Horizontal (auto-scale reads & writes with on-demand or provisioned mode). |
| Performance | Depends on instance type; IOPS. | Single-digit millisecond latency at any scale. |
| Query Language | SQL. | PartiQL (SQL-like), or API calls (GetItem, Query, Scan). |
| Transactions | Full ACID transactions. | ACID transactions (DynamoDB Transactions). |
| Cost Model | Instance hours + storage + IOPS + backups. | On-Demand (pay per request) or Provisioned (RCU/WCU) + storage. |
| Key Limitations | Harder to scale horizontally. Limited by instance size. | No joins. Complex queries are inefficient (use GSI/LSI or DynamoDB Streams). |
| Exam 'Trigger Words' | "SQL", "Relational", "Complex queries", "ACID", "MySQL", "PostgreSQL", "Joins", "Migrate from on-prem DB". | "NoSQL", "Key-value", "Millisecond latency", "Serverless", "Massive scale", "Gaming", "IoT", "Mobile backends". |
8. Amazon Aurora vs. Amazon RDS
Scenario: You need a relational database and are deciding between Aurora and standard RDS.
| Feature | Amazon Aurora | Standard RDS (MySQL/PostgreSQL) |
|---|---|---|
| Primary Use Case | High-performance, cloud-native relational DB with automatic scaling (MySQL/PostgreSQL compatible). | Standard managed relational DB for general workloads. |
| Performance | 5x faster than MySQL, 3x faster than PostgreSQL. | Standard performance. |
| Storage | Auto-scaling (10 GB to 128 TB). | Manual scaling (up to 64 TB for most engines). |
| High Availability | 6 copies across 3 AZs (automatic replication). | Multi-AZ (synchronous standby in another AZ). |
| Read Replicas | Up to 15 read replicas (low-latency promotion, < 30 sec). | Up to 5 read replicas (slower promotion). |
| Failover | Instant (typically < 30 seconds). | 1-2 minutes. |
| Backups | Continuous backup to S3; point-in-time recovery (35 days). | Automated backups; point-in-time recovery (35 days). |
| Cost Model | More expensive (pay for Aurora instance + I/O + storage). | Standard RDS pricing (cheaper). |
| Serverless Option | Aurora Serverless (auto-scaling, pay per second). | No serverless option. |
| Global Database | Aurora Global Database (cross-region, < 1 sec replication). | Cross-region read replicas (manual setup). |
| Key Limitations | More expensive than standard RDS. | Slower failover, fewer read replicas, no serverless. |
| Exam 'Trigger Words' | "High availability", "Fast failover", "Serverless", "Global database", "15 read replicas", "Cloud-native", "Best performance". | "Cost-effective", "Standard workloads", "Oracle", "SQL Server" (not Aurora-compatible). |
9. Amazon SQS vs. Amazon SNS vs. Amazon EventBridge
Scenario: You need to decouple application components or send messages.
| Feature | SQS (Simple Queue Service) | SNS (Simple Notification Service) | EventBridge (formerly CloudWatch Events) |
|---|---|---|---|
| Primary Use Case | Queue for asynchronous message processing (pull model). | Pub/Sub messaging to multiple subscribers (push model). | Event-driven architecture; routing events to multiple targets (advanced event bus). |
| Message Pattern | Point-to-point (one consumer per message). | Pub/Sub (broadcast to many subscribers). | Event routing (pattern matching to multiple targets). |
| Delivery | Pull (consumers poll the queue). | Push (SNS pushes to subscribers). | Push (EventBridge invokes targets). |
| Subscribers/Targets | SQS queue (one consumer group). | Email, SMS, HTTP, SQS, Lambda, Kinesis Data Firehose. | Lambda, SQS, SNS, Step Functions, ECS tasks, Kinesis, API Gateway, etc. |
| Message Retention | 1 minute to 14 days (default 4 days). | No retention (immediate delivery; retries if failed). | No retention (events are delivered once). |
| Filtering | No (consumers process all messages). | Filter policies (JSON-based). | Advanced pattern matching (event rules, content-based filtering). |
| Use Case Examples | Order processing, job queues, buffering. | Alerts, notifications, fanout to multiple systems. | Application integration, scheduled events, cross-account events, SaaS integrations. |
| Cost Model | Per million requests. | Per million publishes + delivery (SMS/email extra). | Per million events + target invocations. |
| Key Limitations | Consumers must poll. No broadcast. | No message retention. | More complex setup. |
| Exam 'Trigger Words' | "Queue", "Decouple", "Async processing", "Retry logic", "FIFO", "Dead-letter queue", "Pull model". | "Pub/Sub", "Fanout", "Multiple subscribers", "Email", "SMS", "Push notification". | "Event-driven", "Event bus", "Pattern matching", "Scheduled events", "SaaS integration (Stripe, Shopify)". |
10. Amazon Kinesis Data Streams vs. Kinesis Data Firehose
Scenario: You need real-time data streaming.
| Feature | Kinesis Data Streams | Kinesis Data Firehose |
|---|---|---|
| Primary Use Case | Real-time streaming for custom processing (e.g., analytics, ML). | Near real-time (buffered) delivery to destinations (S3, Redshift, Elasticsearch, Splunk). |
| Processing | Requires custom consumer (Lambda, KCL, Kinesis Data Analytics). | Fully managed (no consumers needed; auto-delivery). |
| Data Retention | 24 hours (default) to 365 days (extended retention). | No retention (buffers temporarily; delivers to destination). |
| Delivery Latency | Real-time (< 1 second). | Near real-time (60 seconds minimum buffer). |
| Scaling | Manual (add/remove shards) or On-Demand mode. | Auto-scales. |
| Destinations | Custom consumers (you build processing logic). | S3, Redshift, Elasticsearch, Splunk, HTTP endpoints, Datadog, MongoDB. |
| Data Transformation | Requires custom code (Lambda, KCL). | Built-in transformation (Lambda). |
| Cost Model | Shard hours + PUT payload units. | Data processed (per GB). |
| Key Limitations | Requires managing shards and consumers. | Cannot replay data. Buffer delay (60s+). |
| Exam 'Trigger Words' | "Real-time", "Custom processing", "Replay capability", "Multiple consumers", "Data analytics", "Shards". | "Near real-time", "Serverless ingestion", "S3", "Redshift", "Elasticsearch", "Auto-scaling", "No consumer management". |
11. AWS Lambda vs. Amazon ECS vs. Amazon EKS
Scenario: You need to run application code.
| Feature | Lambda | ECS (Elastic Container Service) | EKS (Elastic Kubernetes Service) |
|---|---|---|---|
| Primary Use Case | Serverless event-driven compute (short-lived tasks). | Docker containers on AWS-managed infrastructure (no orchestration complexity). | Kubernetes container orchestration (complex workloads, portability). |
| Management | Fully serverless (no servers to manage). | You manage tasks (AWS manages cluster). | You manage Kubernetes control plane & nodes (or use Fargate). |
| Execution Time | Max 15 minutes. | No time limit. | No time limit. |
| Scaling | Auto-scales instantly (1000s of concurrent invocations). | Auto-scales with Auto Scaling Groups or Fargate. | Auto-scales with Kubernetes HPA (Horizontal Pod Autoscaler) or Fargate. |
| Pricing | Pay per request + compute time (GB-seconds). | Pay for EC2 instances or Fargate tasks. | Pay for EC2 instances (nodes) + EKS control plane fee or Fargate tasks. |
| Containerization | No (code is packaged as ZIP or container image). | Yes (Docker containers). | Yes (Docker containers; Kubernetes pods). |
| Portability | AWS-specific (vendor lock-in). | AWS-specific (but Docker portable). | Kubernetes is portable (multi-cloud, on-prem). |
| Use Cases | Event processing, APIs, automation, ETL. | Microservices, batch jobs, long-running tasks. | Complex microservices, hybrid/multi-cloud, ML pipelines. |
| Key Limitations | 15-minute time limit. Cold starts. Memory limit (10 GB). | More complex than Lambda. | Steep learning curve. Higher cost. |
| Exam 'Trigger Words' | "Serverless", "Event-driven", "Short tasks", "API Gateway", "S3 trigger", "No servers", "Auto-scale instantly". | "Docker", "Containers", "Long-running", "Batch processing", "Microservices", "Fargate" (serverless containers). | "Kubernetes", "Multi-cloud", "Portability", "Complex orchestration", "Helm charts", "Kubernetes API". |
12. Amazon CloudWatch vs. AWS CloudTrail vs. AWS Config
Scenario: You need monitoring, logging, or compliance tracking.
| Feature | CloudWatch | CloudTrail | AWS Config |
|---|---|---|---|
| Primary Use Case | Monitoring & observability (metrics, logs, alarms). | Audit and governance (API call history, "who did what, when"). | Resource configuration tracking and compliance ("what changed, when"). |
| What It Tracks | Metrics (CPU, network), Logs, Events. | API calls (user activity, console actions). | Resource configurations (states, relationships, compliance). |
| Focus | Performance monitoring, alarms, dashboards. | Security, audit, forensics. | Configuration drift, compliance rules. |
| Use Cases | Trigger alarms (EC2 CPU > 80%), visualize metrics, log analysis. | Who created this S3 bucket? Who deleted this resource? | Is my S3 bucket public? Are EC2 instances compliant with rules? |
| Retention | Logs: configurable (default indefinite in log groups). Metrics: 15 months. | Events: 90 days (or export to S3 for long-term). | Configuration history: 7 years. |
| Real-Time | Yes (metrics updated every 1 or 5 minutes; logs in real-time). | Near real-time (typically within 15 minutes). | Configuration changes in minutes. |
| Cost Model | Logs ingestion + storage + API requests + alarms. | First trail free (management events); data events charged. | Configuration items recorded + rules evaluated. |
| Key Limitations | Not for API auditing. | Not for performance monitoring. | Not for real-time API auditing. |
| Exam 'Trigger Words' | "Monitor", "Alarm", "Metrics", "Logs", "Dashboard", "Performance", "CPU", "Latency". | "Audit", "Who did what", "API calls", "Security analysis", "Compliance audit". | "Configuration compliance", "Resource inventory", "Drift detection", "Compliance rules". |
13. AWS Step Functions vs. AWS SWF (Simple Workflow Service)
Scenario: You need to orchestrate distributed workflows.
| Feature | Step Functions | SWF (Simple Workflow Service) |
|---|---|---|
| Primary Use Case | Serverless workflow orchestration (state machines, Lambda, ECS, etc.). | Long-running workflows with external signals or human tasks. |
| Workflow Definition | JSON state machine (visual editor available). | Code-based (write deciders & workers in any language). |
| Execution Time | Standard: up to 1 year. Express: up to 5 minutes. | Unlimited duration. |
| Integration | Native AWS service integrations (Lambda, SQS, SNS, DynamoDB, ECS, Batch, etc.). | More flexible (custom logic, external systems). |
| Development Complexity | Low (declarative, visual). | High (manual task routing, state management). |
| Use Cases | ETL pipelines, order fulfillment, microservices orchestration. | Complex workflows, external signal dependencies, human approvals. |
| Cost Model | Per state transition. | Per task execution + activity task. |
| Exam Recommendation | Preferred for new workflows (modern, serverless). | Legacy (use Step Functions unless specific SWF feature needed). |
| Key Limitations | No external signals (use EventBridge). | More complex to develop. |
| Exam 'Trigger Words' | "Serverless workflow", "State machine", "Visual workflow", "Orchestrate Lambda", "Modern". | "Long-running workflow" (over 1 year), "Human tasks", "External signals", "Legacy". |
14. VPC Peering vs. AWS Transit Gateway vs. AWS PrivateLink
Scenario: You need to connect VPCs or enable private connectivity.
| Feature | VPC Peering | Transit Gateway | PrivateLink |
|---|---|---|---|
| Primary Use Case | One-to-one connection between 2 VPCs (same/different regions, accounts). | Hub-and-spoke connectivity for many VPCs (centralized routing). | Private access to services (expose your service to other VPCs without peering). |
| Connectivity Model | Point-to-point (mesh network if many VPCs—gets complex). | Centralized hub (attach many VPCs, on-prem via VPN/Direct Connect). | Service-to-VPC (no VPC peering needed). |
| Scalability | Doesn't scale well (N*(N-1)/2 connections for N VPCs). | Scales to thousands of VPCs. | Scales well (many consumers connect to single service). |
| Routing | Non-transitive (A→B, B→C doesn't allow A→C). | Transitive (centralized route tables). | No routing (uses ENI in consumer VPC). |
| Use Cases | Connect 2 VPCs (e.g., prod & shared services). | Connect many VPCs, hybrid networks, multi-region. | Expose SaaS service, 3rd-party services, internal apps without peering. |
| Cost Model | Data transfer charges. | Hourly attachment fee + data transfer. | Hourly charge per endpoint + data processed. |
| Key Limitations | Complex at scale. No transitive routing. | More expensive. | Only for service access (not VPC-to-VPC communication). |
| Exam 'Trigger Words' | "Connect 2 VPCs", "Simple connectivity", "Peering". | "Centralized routing", "Many VPCs", "Hub-and-spoke", "Thousands of VPCs", "Transit". | "Private service", "Expose service", "No internet", "Endpoint Service", "No peering". |
15. AWS Direct Connect vs. Site-to-Site VPN
Scenario: You need to connect on-premises network to AWS.
| Feature | Direct Connect | Site-to-Site VPN |
|---|---|---|
| Primary Use Case | Dedicated private connection (high throughput, consistent performance). | Encrypted connection over the public internet (quick setup). |
| Connection Type | Private fiber connection (1 Gbps or 10 Gbps, or hosted connections). | IPsec VPN over internet. |
| Throughput | High (up to 100 Gbps with LAG). | Limited by internet speed (typically up to 1.25 Gbps per tunnel). |
| Latency | Low and consistent. | Variable (depends on internet). |
| Security | Private (not encrypted by default; use MACsec or VPN over Direct Connect). | Encrypted (IPsec). |
| Setup Time | Weeks to months (physical installation). | Minutes to hours. |
| Cost Model | Port hours + outbound data transfer. | Hourly VPN connection fee + data transfer out. |
| Use Cases | Large data transfers, hybrid cloud, consistent performance. | Quick connectivity, disaster recovery, temporary connections. |
| Key Limitations | Expensive, long setup. No encryption by default. | Internet-dependent (latency jitter). Lower throughput. |
| Exam 'Trigger Words' | "Dedicated connection", "High throughput", "Consistent performance", "Private connection", "Low latency". | "Quick setup", "Encrypted", "Over internet", "IPsec", "Cost-effective". |
16. Amazon ECS vs. Amazon EKS vs. AWS Fargate
Scenario: You need to decide on container orchestration.
| Feature | ECS | EKS | Fargate |
|---|---|---|---|
| Primary Use Case | AWS-native container orchestration (simple, integrated). | Kubernetes orchestration on AWS (portability, ecosystem). | Serverless compute for containers (ECS or EKS without managing servers). |
| Orchestration | AWS proprietary (ECS API). | Kubernetes (open-source, standard). | No orchestration (just compute layer for ECS or EKS). |
| Management | AWS manages control plane. | AWS manages Kubernetes control plane. | AWS manages infrastructure (no EC2 instances). |
| Learning Curve | Low (simple AWS console/CLI). | High (Kubernetes complexity). | Low (just define task/pod). |
| Portability | AWS-only. | Portable (Kubernetes runs anywhere). | AWS-only. |
| Pricing | Free (pay for EC2 instances or Fargate). | $0.10/hour per cluster + EC2/Fargate. | Pay per vCPU & memory (more expensive than EC2). |
| Use Cases | Simple containerized apps, AWS-centric workloads. | Multi-cloud, Kubernetes expertise, complex microservices. | Serverless containers, no infrastructure management. |
| Key Limitations | No Kubernetes ecosystem. | More expensive, complex. | More expensive than EC2. No persistent storage (use EFS). |
| Exam 'Trigger Words' | "AWS-native", "Simple", "ECS", "Docker". | "Kubernetes", "Portability", "Helm", "K8s". | "Serverless containers", "No EC2 management", "Fargate". |
17. AWS Backup vs. EBS Snapshots
Scenario: You need to backup AWS resources.
| Feature | AWS Backup | EBS Snapshots |
|---|---|---|
| Primary Use Case | Centralized, policy-based backup across multiple AWS services. | Manual or automated snapshots for EBS volumes only. |
| Supported Services | EBS, RDS, DynamoDB, EFS, FSx, Storage Gateway, DocumentDB, Neptune, S3. | EBS only. |
| Management | Centralized dashboard (backup plans, policies, compliance). | Per-volume snapshots (manual or lifecycle policies). |
| Automation | Backup plans with schedules, retention, lifecycle rules. | Data Lifecycle Manager (DLM) or manual scripts. |
| Cross-Region/Account | Built-in cross-region and cross-account backup. | Manual copy to other regions/accounts. |
| Compliance | Compliance reports (HIPAA, PCI DSS). | No built-in compliance tracking. |
| Cost Model | Pay for storage + restore requests. | Pay for snapshot storage (incremental). |
| Key Limitations | Additional cost. | EBS-only. No centralized management for other services. |
| Exam 'Trigger Words' | "Centralized backup", "Backup across services", "Compliance", "Backup plan", "Policy-based". | "EBS volumes", "Snapshots", "Manual backup". |
18. AWS Systems Manager Parameter Store vs. AWS Secrets Manager
Scenario: You need to store sensitive configuration data.
| Feature | Parameter Store | Secrets Manager |
|---|---|---|
| Primary Use Case | Store configuration and secrets (simple, cost-effective). | Store and auto-rotate secrets (databases, APIs). |
| Secret Rotation | Manual (no built-in rotation). | Automatic rotation (Lambda-based). |
| Pricing | Free (standard tier); Advanced tier ($0.05 per param/month). | $0.40 per secret/month + API calls. |
| Storage Limit | Standard: 10,000 params, 4 KB size. Advanced: 100,000 params, 8 KB. | No limit. |
| Encryption | Optional (KMS encryption). | Always encrypted (KMS). |
| Integration | Wide AWS integration (Lambda, ECS, EC2). | Same + native rotation for RDS, Redshift, DocumentDB. |
| Use Cases | App config, feature flags, simple secrets. | Database credentials, API keys requiring rotation. |
| Key Limitations | No auto-rotation. | More expensive. |
| Exam 'Trigger Words' | "Configuration", "Free tier", "Simple secrets", "Feature flags". | "Auto-rotate", "Database credentials", "Secrets rotation", "RDS password". |
19. Amazon Cognito User Pools vs. Identity Pools
Scenario: You need user authentication/authorization for your application.
| Feature | Cognito User Pools | Cognito Identity Pools |
|---|---|---|
| Primary Use Case | User directory and authentication (sign-up, sign-in, MFA). | Authorization (grant temporary AWS credentials to users). |
| Functionality | User management (registration, login, password reset). | Federated identity (exchange tokens for AWS credentials). |
| Output | JWT tokens (ID, access, refresh tokens). | Temporary AWS credentials (STS tokens for AWS resource access). |
| Use Cases | User sign-up/sign-in, social login, MFA. | Mobile apps accessing S3, DynamoDB directly; guest access. |
| Identity Providers | Built-in (email/password), social (Google, Facebook), SAML, OIDC. | User Pools, social (Google, Facebook, Amazon), SAML, OpenID Connect, anonymous/guest. |
| Access Control | Authentication only (does not grant AWS resource access). | Grants AWS IAM role-based access (via STS). |
| Exam 'Trigger Words' | "User directory", "Sign-up/sign-in", "MFA", "JWT", "User authentication". | "Temporary credentials", "Mobile app", "Guest access", "Federated identity", "Access S3 directly". |
20. AWS WAF vs. AWS Shield vs. AWS Firewall Manager
Scenario: You need to protect your application from attacks.
| Feature | AWS WAF | AWS Shield | AWS Firewall Manager |
|---|---|---|---|
| Primary Use Case | Web application firewall (protect against SQL injection, XSS, etc.). | DDoS protection (distributed denial-of-service). | Centralized firewall management across accounts. |
| Protection Type | Layer 7 (application-level: HTTP/HTTPS). | Layer 3/4 (DDoS: SYN floods, UDP reflection). | Centralized policies (WAF, Shield Advanced). |
| Tiers | N/A (pay per use). | Standard (free) & Advanced (paid). | N/A (requires AWS Organizations). |
| Customization | Highly customizable (web ACLs, rules, IP sets, rate limiting). | Automatic (Standard); Advanced includes DDoS Response Team. | Centralized policy enforcement (WAF rules across AWS Organization). |
| Targets | CloudFront, ALB, API Gateway, AppSync. | CloudFront, Route 53, ALB, NLB, Elastic IP. | Multiple accounts & resources (WAF, Shield Advanced). |
| Cost Model | Web ACL + rules + requests. | Standard: Free. Advanced: $3,000/month + data transfer. | Firewall Manager service fee + WAF/Shield costs. |
| Key Limitations | Requires rule configuration. | Advanced is very expensive. | Requires AWS Organizations. |
| Exam 'Trigger Words' | "Block SQL injection", "XSS", "Web ACL", "Rate limiting", "IP blocking", "Custom rules". | "DDoS protection", "Layer 3/4", "SYN flood", "Free DDoS (Standard)", "Advanced DDoS Response Team". | "Centralized security", "Multiple accounts", "AWS Organizations", "Policy enforcement". |
21. S3 Glacier Instant Retrieval vs. Flexible Retrieval vs. Deep Archive
Scenario: You need long-term archival storage with different retrieval requirements.
| Feature | Glacier Instant Retrieval | Glacier Flexible Retrieval | Glacier Deep Archive |
|---|---|---|---|
| Primary Use Case | Archival data requiring millisecond retrieval (rarely accessed but instant when needed). | Archive data accessed 1-2 times/year with flexible retrieval (minutes to hours). | Lowest-cost archival storage for data accessed rarely (7-10+ years retention). |
| Retrieval Time | Milliseconds (same as S3 Standard). | Expedited: 1-5 min, Standard: 3-5 hours, Bulk: 5-12 hours. | Standard: 12 hours, Bulk: 48 hours. |
| Retrieval Cost | Higher retrieval cost per GB. | Moderate retrieval cost. | Lowest retrieval cost (but longest wait). |
| Storage Cost | Cheaper than S3 Standard-IA. | Cheaper than Instant Retrieval. | Cheapest (lowest cost per GB). |
| Minimum Storage Duration | 90 days. | 90 days. | 180 days. |
| Use Cases | Medical images, news archives (instant access needed). | Quarterly/annual backups, compliance archives. | Long-term regulatory archives, digital preservation. |
| Key Limitations | Still more expensive than Flexible/Deep Archive. | Longer retrieval time. | Very long retrieval time (12-48 hours). |
| Exam 'Trigger Words' | "Millisecond retrieval", "Archive with instant access", "Rare but immediate". | "Flexible retrieval", "Minutes to hours", "1-2 times per year". | "Lowest cost", "48 hours", "Long-term retention", "7-10 years". |
22. Amazon ElastiCache: Redis vs. Memcached
Scenario: You need an in-memory caching solution.
| Feature | Redis | Memcached |
|---|---|---|
| Primary Use Case | Advanced caching with persistence, replication, pub/sub, complex data types. | Simple, fast, multi-threaded caching (key-value only). |
| Data Structures | Strings, lists, sets, sorted sets, hashes, bitmaps, hyperloglogs, geospatial. | Key-value only (strings). |
| Persistence | Yes (snapshots, AOF logs). | No (in-memory only; data lost on restart). |
| Replication | Yes (multi-AZ with automatic failover). | No (horizontal scaling via sharding only). |
| High Availability | Multi-AZ, automatic failover with Redis Cluster. | No failover (application must handle node failure). |
| Multi-threading | Single-threaded (per shard). | Multi-threaded (better for simple operations). |
| Pub/Sub | Yes (messaging patterns). | No. |
| Sorting/Ranking | Built-in (sorted sets). | No (application must handle). |
| Use Cases | Session store, leaderboards, real-time analytics, pub/sub messaging. | Simple caching (web object cache, database query cache). |
| Cost Model | Per node-hour. | Per node-hour (generally cheaper). |
| Key Limitations | More expensive; single-threaded. | No persistence, no failover, simple data types only. |
| Exam 'Trigger Words' | "Persistence", "Pub/Sub", "Leaderboard", "Sorted sets", "Multi-AZ", "Failover", "Replication". | "Multi-threaded", "Simple caching", "Fastest", "Horizontal scaling", "No persistence". |
23. AWS Organizations: Service Control Policies (SCPs) vs. IAM Policies
Scenario: You need to understand permission boundaries and access control.
| Feature | SCPs (Service Control Policies) | IAM Policies |
|---|---|---|
| Primary Use Case | Organization-wide guardrails (maximum permissions for accounts within AWS Organization). | Grant permissions to users, groups, roles within an account. |
| Scope | Applied to OUs (Organizational Units) or accounts (organization-level). | Applied to individual principals (users, groups, roles) within an account. |
| Effect | Deny or Allow (acts as permission boundary; filters what is allowed). | Allow (explicitly grants permissions). |
| Enforcement | Applies to all principals in the OU/account (including root user!). | Applies only to the specific principal (user/role). |
| Use Cases | Prevent accounts from leaving organization, restrict regions, block specific services. | Grant S3 read access, allow EC2 launch permissions. |
| Precedence | SCPs + IAM policies both must allow an action (intersection). | Only IAM policy needs to allow (if no SCP). |
| Key Limitations | Does not grant permissions (only restricts). Requires AWS Organizations. | Cannot enforce organization-wide restrictions. |
| Exam 'Trigger Words' | "Organization-wide", "Maximum permissions", "Guardrails", "Prevent region access", "All accounts", "Root user restrictions". | "Grant permissions", "User permissions", "Role policy", "Specific principal". |
24. AWS DataSync vs. AWS Storage Gateway vs. AWS Snowball
Scenario: You need to transfer data between on-premises and AWS.
| Feature | DataSync | Storage Gateway | Snowball |
|---|---|---|---|
| Primary Use Case | Automated online data transfer (NFS/SMB to S3/EFS/FSx) over internet/Direct Connect. | Hybrid cloud storage (on-prem access to cloud storage with local cache). | Offline data transfer for massive datasets (petabytes) via physical device. |
| Transfer Method | Online (internet or Direct Connect). | Online (internet or Direct Connect). | Offline (ship physical device). |
| Transfer Speed | Up to 10 Gbps per task (depends on bandwidth). | Depends on bandwidth (lower latency with local cache). | High (80 TB or 42-210 TB depending on device; ship to AWS). |
| Use Cases | One-time migration, recurring syncs, disaster recovery replication. | File shares (SMB/NFS), volume backups, tape backups (on-prem to cloud). | Large-scale migration, datacenter shutdown, no/limited internet connectivity. |
| Data Processing | Transfer only (automated scheduling, bandwidth throttling). | Local caching (low-latency access to frequently used data). | Transfer only (load data onto device, ship to AWS). |
| Bandwidth Dependency | Requires adequate internet/Direct Connect bandwidth. | Requires connectivity (but caching reduces latency). | No (offline device shipment). |
| Cost Model | Per GB transferred + hourly rate. | Gateway type + storage + requests. | Per device + shipping + data transfer into AWS (free). |
| Key Limitations | Requires network connectivity. | Ongoing dependency on internet/Direct Connect. | Slow (physical shipping time). Manual device handling. |
| Exam 'Trigger Words' | "Automated sync", "Recurring transfer", "Online migration", "NFS to S3", "Scheduled sync". | "Hybrid storage", "On-prem cache", "File Gateway", "Volume Gateway", "Tape Gateway". | "Offline", "Petabytes", "No internet", "Physical device", "Large-scale migration". |
25. Amazon Route 53 Routing Policies
Scenario: You need to understand how Route 53 routes traffic based on different policies.
| Policy | Primary Use Case | How It Works | Exam 'Trigger Words' |
|---|---|---|---|
| Simple | Single resource (e.g., one web server). | Returns a single resource (or multiple values randomly). | "Single resource", "No special routing". |
| Weighted | A/B testing, gradual migration, traffic distribution. | Distributes traffic based on assigned weights (e.g., 70% to A, 30% to B). | "A/B test", "Gradual rollout", "Traffic split", "Percentage". |
| Latency-based | Minimize latency for global users. | Routes to the region with lowest latency for the user. | "Lowest latency", "Global users", "Best performance". |
| Failover | Active-passive disaster recovery. | Routes to primary resource; fails over to secondary if health check fails. | "Disaster recovery", "Active-passive", "Failover", "High availability". |
| Geolocation | Content localization, compliance (route based on user location). | Routes based on geographic location of user (continent, country, state). | "Geographic location", "Compliance", "Localization", "Regional content". |
| Geoproximity | Route traffic based on proximity to resources with bias. | Routes based on geographic distance (can shift traffic with bias setting). | "Geographic proximity", "Bias", "Shift traffic", "Distance-based". |
| Multi-value Answer | Return multiple healthy resources (simple load balancing). | Returns up to 8 healthy records randomly (like Simple, but with health checks). | "Multiple IPs", "Health checks", "Simple load balancing". |
Key Differences:
- Weighted vs. Geolocation: Weighted is for traffic distribution (e.g., 20/80 split); Geolocation is based on user's physical location.
- Latency vs. Geoproximity: Latency routes to the AWS region with lowest network latency; Geoproximity routes based on geographic distance (with optional bias).
- Failover vs. Multi-value: Failover is active-passive (one primary); Multi-value returns multiple healthy IPs (active-active simple load balancing).
26. Amazon SQS Standard vs. SQS FIFO
Scenario: You need a message queue and must decide between standard and FIFO queues.
| Feature | SQS Standard | SQS FIFO |
|---|---|---|
| Primary Use Case | High throughput messaging where message order doesn't matter. | Strict ordering and exactly-once processing required. |
| Message Order | Best-effort ordering (may be out of order). | Strict FIFO (first-in-first-out, guaranteed order). |
| Delivery | At-least-once (messages may be delivered more than once). | Exactly-once (duplicates eliminated within 5-minute window). |
| Throughput | Unlimited (nearly unlimited TPS). | 3,000 msg/sec with batching (300 without batching). |
| Deduplication | No built-in (application must handle). | Built-in (content-based or message deduplication ID). |
| Message Groups | Not supported. | Message Group ID (parallel processing within groups). |
| Cost | Lower cost per request. | Higher cost per request. |
| Queue Name | Any valid name. | Must end with .fifo suffix. |
| Use Cases | Decoupling, buffering, fan-out (order doesn't matter). | Financial transactions, inventory updates, order processing. |
| Key Limitations | No ordering guarantee. Possible duplicates. | Lower throughput. Queue name must end in .fifo. |
| Exam 'Trigger Words' | "High throughput", "At-least-once", "Order doesn't matter", "Decoupling". | "Exactly-once", "Order matters", "FIFO", "Strict ordering", "Deduplication", "Financial transactions". |
27. Reserved Instances vs. Savings Plans vs. Spot Instances
Scenario: You need to optimize EC2 costs.
| Feature | Reserved Instances (RI) | Savings Plans | Spot Instances |
|---|---|---|---|
| Primary Use Case | Predictable workloads with known instance types (1 or 3 year commitment). | Flexible commitment across compute services (any instance type/region). | Fault-tolerant workloads that can handle interruptions (up to 90% savings). |
| Discount | Up to 72% off On-Demand. | Up to 72% off On-Demand. | Up to 90% off On-Demand. |
| Commitment | Specific instance type, region, OS, tenancy. | Hourly spend commitment (flexible instance types). | No commitment (bid on spare capacity). |
| Flexibility | Limited (locked to instance attributes). Can use Convertible RIs for some flexibility. | High (Compute Savings Plans work across EC2, Lambda, Fargate). | Highest (any instance type, but can be terminated). |
| Term | 1 year or 3 years. | 1 year or 3 years. | No term (hourly pricing based on market). |
| Interruption | No interruption. | No interruption. | Can be interrupted with 2-minute warning. |
| Payment Options | All Upfront, Partial Upfront, No Upfront. | All Upfront, Partial Upfront, No Upfront. | Pay Spot price (varies by supply/demand). |
| Use Cases | Steady-state production workloads, databases. | Mixed workloads, Lambda + EC2 + Fargate usage. | Batch processing, data analysis, CI/CD, stateless workloads. |
| Key Limitations | Inflexible (locked to instance type). | Less savings than RIs for specific instance types. | Interruption risk. Not for critical workloads. |
| Exam 'Trigger Words' | "Predictable workload", "1-3 year commitment", "Specific instance type". | "Flexible", "Any instance type", "Compute commitment", "Lambda + EC2". | "Up to 90% savings", "Interruption tolerant", "Batch processing", "Stateless", "Fault-tolerant". |
28. S3 Cross-Region Replication (CRR) vs. Same-Region Replication (SRR)
Scenario: You need to replicate S3 objects for disaster recovery or compliance.
| Feature | Cross-Region Replication (CRR) | Same-Region Replication (SRR) |
|---|---|---|
| Primary Use Case | Disaster recovery and compliance (data in different geographic regions). | Log aggregation, compliance (same region), test/production sync. |
| Replication Scope | Objects replicated to bucket in different region. | Objects replicated to bucket in same region. |
| Latency | Higher (cross-region data transfer). | Lower (same-region transfer). |
| Cost | S3 data transfer between regions + storage in destination. | Storage in destination only (no inter-region transfer fee). |
| Use Cases | DR across regions, compliance (data in multiple countries), lower latency access. | Log aggregation from multiple buckets, live replication between prod/test, compliance within region. |
| Requirements | Versioning enabled on both buckets. IAM role for replication. | Versioning enabled on both buckets. IAM role for replication. |
| Replication Time | Minutes to hours (depends on object size). | Near real-time (same region). |
| Delete Markers | Optional replication of delete markers. | Optional replication of delete markers. |
| Key Limitations | Higher cost. Longer replication time. | No geographic redundancy (both in same region). |
| Exam 'Trigger Words' | "Disaster recovery", "Cross-region", "Different AWS regions", "Geographic compliance", "Global access". | "Same region", "Log aggregation", "Test and production", "Compliance within region". |
29. Amazon Redshift vs. Amazon Athena vs. Amazon EMR
Scenario: You need to analyze large datasets and must choose the right analytics service.
| Feature | Amazon Redshift | Amazon Athena | Amazon EMR |
|---|---|---|---|
| Primary Use Case | Data warehouse for complex queries on structured data (petabyte-scale). | Serverless ad-hoc queries on S3 data (pay-per-query). | Big data processing with open-source frameworks (Spark, Hadoop, Presto). |
| Data Location | Data loaded into Redshift cluster (columnar storage). | Queries data directly in S3 (no data movement). | Data in S3, HDFS, or other sources (flexible). |
| Management | Managed cluster (you provision nodes). | Serverless (no infrastructure). | Managed cluster (you configure cluster size). |
| Query Engine | PostgreSQL-compatible (optimized for analytics). | Presto/Trino (serverless SQL). | Spark SQL, Hive, Presto, etc. |
| Schema | Schema-on-write (define schema before loading). | Schema-on-read (define schema at query time). | Schema-on-read or write (flexible). |
| Performance | Fastest for complex joins and aggregations on large datasets. | Good for occasional queries; slower for large scans. | Depends on cluster configuration; optimized for distributed processing. |
| Cost Model | Hourly cluster cost + storage (can be expensive). | $5 per TB scanned (cost-effective for occasional queries). | Cluster cost (EC2 instances) + storage. |
| Concurrency | Up to 500 connections; Concurrency Scaling for spikes. | Scales automatically. | Depends on cluster; can run multiple jobs. |
| Use Cases | BI dashboards, enterprise reporting, historical data analysis. | Log analysis, one-time queries, data lake queries. | ETL, ML training, streaming analytics, Hadoop workloads. |
| Key Limitations | Expensive for small workloads. Data must be loaded. | Slow for complex joins. Cost increases with data scanned. | Complex setup. Requires cluster management. |
| Exam 'Trigger Words' | "Data warehouse", "Complex queries", "BI", "Reporting", "Structured data", "Columnar". | "Serverless", "Query S3 directly", "Ad-hoc", "Pay per query", "No infrastructure". | "Big data", "Spark", "Hadoop", "ETL", "Machine learning", "Open-source". |
30. VPC Interface Endpoints vs. Gateway Endpoints
Scenario: You need to access AWS services privately from your VPC.
| Feature | Interface Endpoint | Gateway Endpoint |
|---|---|---|
| Primary Use Case | Private access to most AWS services (and PrivateLink services). | Private access to S3 and DynamoDB only. |
| Implementation | Creates ENI (Elastic Network Interface) in your subnet. | Entry in route table (no ENI). |
| Supported Services | Hundreds of services (API Gateway, SQS, SNS, KMS, Secrets Manager, etc.). | Only S3 and DynamoDB. |
| IP Address | Uses private IPs from your subnet. | Uses AWS IP ranges (via route table). |
| Security | Uses Security Groups (can restrict access by SG). | No Security Groups (use VPC Endpoint Policies). |
| Cost | Hourly charge + data processing fee (per GB). | Free (no additional cost). |
| Cross-Region | Same region only (but can access via Transit Gateway). | Same region only. |
| High Availability | Create endpoint in each AZ for HA. | Highly available by default (regional). |
| DNS | Regional and Zonal DNS entries (private DNS supported). | No DNS change (uses route table). |
| Key Limitations | Costs money. Requires ENI in each AZ for HA. | Only S3 and DynamoDB. |
| Exam 'Trigger Words' | "Private access to AWS services", "ENI", "Security Groups", "SQS", "SNS", "KMS", "Secrets Manager". | "S3", "DynamoDB", "Free", "Route table", "No cost". |
Important Exam Note: If the question asks about private access to S3 or DynamoDB, Gateway Endpoint is preferred (free). For all other AWS services, use Interface Endpoint.
31. AWS KMS vs. AWS CloudHSM
Scenario: You need to manage encryption keys for your applications.
| Feature | AWS KMS (Key Management Service) | AWS CloudHSM |
|---|---|---|
| Primary Use Case | Managed key service for most encryption needs (integrated with AWS services). | Dedicated HSM for strict compliance or full key control. |
| Management | Fully managed (AWS manages HSM infrastructure). | Customer-managed (you manage HSM cluster). |
| Key Storage | Keys stored in multi-tenant HSMs (AWS shared infrastructure). | Keys stored in dedicated (single-tenant) HSMs. |
| Compliance | FIPS 140-2 Level 2 (some Level 3). | FIPS 140-2 Level 3 (highest). |
| Access Control | IAM policies + KMS key policies. | You manage users on HSM (no IAM integration for key access). |
| Integration | Native integration with 100+ AWS services (S3, EBS, RDS, Lambda, etc.). | Limited (requires custom application integration). |
| Key Types | Symmetric (AES-256), Asymmetric (RSA, ECC). | Symmetric, Asymmetric, custom key types. |
| Pricing | Per key (first $1/month) + API requests. | $1.60/hour per HSM (expensive for small workloads). |
| High Availability | Built-in (multi-AZ). | You must deploy HSMs in multiple AZs. |
| Use Cases | Encrypt S3, EBS, RDS, Lambda env vars, SSM parameters. | Oracle TDE, Microsoft SQL TDE, PKI, strict regulatory compliance. |
| Key Limitations | Not single-tenant. AWS has access to infrastructure (not keys). | Expensive. Complex setup. Limited AWS integration. |
| Exam 'Trigger Words' | "Managed encryption", "Integrated", "AWS native", "Envelope encryption", "SSE-KMS". | "FIPS 140-2 Level 3", "Dedicated HSM", "Single-tenant", "Full control", "Oracle TDE", "Regulatory compliance". |
32. EC2 Instance Store vs. Amazon EBS
Scenario: You need to choose storage for your EC2 instance.
| Feature | Instance Store (Ephemeral Storage) | EBS (Elastic Block Store) |
|---|---|---|
| Primary Use Case | Temporary storage for cache, buffers, scratch data (extreme IOPS). | Persistent storage for databases, boot volumes, applications. |
| Persistence | Ephemeral (data lost when instance stops, terminates, or fails). | Persistent (data survives instance stop/start). |
| Data Durability | No durability (data lost on instance failure). | Replicated within AZ (99.999% durability). |
| Performance | Extremely high IOPS (physically attached NVMe SSD). | High IOPS (io2: up to 64,000 IOPS, gp3: up to 16,000 IOPS). |
| Size | Fixed (depends on instance type). | Flexible (1 GiB to 64 TiB). |
| Snapshots | Not supported. | Supported (backup to S3). |
| Encryption | Depends on instance type (some support encryption). | Always supports encryption (with KMS). |
| Resizing | Cannot resize (fixed to instance). | Can resize (increase size on the fly). |
| Attachment | Attached only at launch (cannot attach later). | Can attach/detach anytime (except root volume). |
| Cost | Included in instance price (no additional cost). | Hourly charge based on volume type + IOPS + throughput. |
| Key Limitations | Data loss on stop/terminate/failure. No snapshots. | Lower max IOPS than instance store. Attached to single instance (usually). |
| Exam 'Trigger Words' | "Ephemeral", "Temporary", "Cache", "Buffer", "Scratch", "Highest IOPS", "Data loss acceptable". | "Persistent", "Database", "Boot volume", "Snapshots", "Durable storage", "Long-term data". |
Critical Exam Note: If the scenario involves a database or any data that must survive instance termination, always choose EBS. Instance Store is for temporary/cache data only.
33. RDS Read Replicas vs. Multi-AZ Deployments
Scenario: You need high availability or read scaling for your RDS database.
| Feature | Read Replicas | Multi-AZ Deployment |
|---|---|---|
| Primary Use Case | Read scaling (offload read traffic from primary). | High availability and disaster recovery (automatic failover). |
| Purpose | Performance (horizontal read scaling). | Availability (automatic failover on failure). |
| Replication | Asynchronous (some replication lag possible). | Synchronous (zero data loss on failover). |
| Accessible | Yes (read replicas can serve read traffic). | No (standby is not accessible until failover). |
| Failover | Manual promotion (not automatic). | Automatic failover (60-120 seconds). |
| Regions | Can be in same region or cross-region. | Same region only (different AZ). |
| Number Allowed | Up to 5 read replicas (15 for Aurora). | 1 standby instance. |
| Connection String | Each replica has its own endpoint. | Same endpoint (DNS flips on failover). |
| Use Cases | Analytics, reporting, read-heavy workloads. | Production databases requiring HA, automatic failover. |
| Cost | Charged for each replica (like additional RDS instance). | Charged for standby instance (but no active use). |
| Key Limitations | Replication lag. Manual promotion. | Standby cannot serve reads. Same region only. |
| Exam 'Trigger Words' | "Read scaling", "Offload reads", "Reporting queries", "Cross-region replica", "Analytics". | "High availability", "Automatic failover", "Disaster recovery", "Synchronous", "Standby". |
Critical Exam Note:
- For High Availability → Multi-AZ
- For Read Performance → Read Replicas
- For Both → Enable Multi-AZ AND create Read Replicas
34. API Gateway: REST API vs. HTTP API vs. WebSocket API
Scenario: You need to create an API using Amazon API Gateway.
| Feature | REST API | HTTP API | WebSocket API |
|---|---|---|---|
| Primary Use Case | Full-featured API with advanced controls. | Low-latency, cost-effective HTTP API. | Real-time two-way communication. |
| Protocol | HTTP/HTTPS (REST). | HTTP/HTTPS (REST). | WebSocket. |
| Latency | Higher (more features = more processing). | Lower (optimized for speed). | Low (persistent connections). |
| Cost | $3.50 per million requests. | $1.00 per million requests (70% cheaper). | Per message + connection minutes. |
| Lambda Integration | Proxy and custom integrations. | Lambda proxy only (simpler). | Lambda integration. |
| Authentication | IAM, Lambda authorizer, Cognito, API keys. | IAM, Lambda authorizer, Cognito (JWT). | IAM, Lambda authorizer. |
| Request Validation | Yes (schema validation). | No. | No. |
| Request/Response Transformation | Yes (VTL templates). | No. | No. |
| Caching | Yes (API response caching). | No. | No. |
| Usage Plans & API Keys | Yes (throttling, quotas). | No. | No. |
| WAF Integration | Yes. | No. | No. |
| Private Endpoints | Yes (VPC Link). | Yes. | Yes. |
| Use Cases | Enterprise APIs, complex integrations, external APIs with throttling. | Simple APIs, microservices, internal APIs, cost-sensitive. | Chat apps, dashboards, gaming, real-time notifications. |
| Key Limitations | More expensive. Higher latency. | No caching, validation, or transformation. | Stateful (more complex). |
| Exam 'Trigger Words' | "Caching", "Request validation", "Usage plans", "API keys", "WAF", "Full control". | "Low cost", "Simple API", "Fast", "Microservices", "Serverless". | "Real-time", "Two-way", "Chat", "Live updates", "Persistent connection". |
Exam Tip: If the question mentions needing caching, request validation, usage plans, or WAF → REST API. If it's about cost optimization for simple APIs → HTTP API.
35. S3 Object Lock: Governance Mode vs. Compliance Mode
Scenario: You need to protect S3 objects from deletion or modification for regulatory compliance.
| Feature | Governance Mode | Compliance Mode |
|---|---|---|
| Primary Use Case | Soft protection (most users can't delete, but privileged users can). | Hard protection (nobody can delete, even root user). |
| Override Capability | Users with s3:BypassGovernanceRetention permission can delete/modify. | No one can delete or modify (not even AWS account root user). |
| Retention Period | Can be shortened by authorized users. | Cannot be shortened once applied. |
| Legal Hold | Supported (independent of retention period). | Supported (independent of retention period). |
| Use Cases | Testing retention policies, soft compliance, internal governance. | Regulatory compliance (SEC 17a-4, FINRA, HIPAA), legal requirements. |
| Delete | Authorized users can delete before retention expires. | Impossible to delete until retention period expires. |
| WORM | Soft WORM (Write Once Read Many). | True WORM (cannot be overwritten by anyone). |
| Key Limitations | Can be bypassed (not for strict compliance). | Irreversible once applied. Cannot be shortened. |
| Exam 'Trigger Words' | "Soft protection", "Internal governance", "Testing", "Can be overridden", "Privileged users can delete". | "Regulatory compliance", "SEC 17a-4", "WORM", "Nobody can delete", "Legal requirement", "Immutable". |
Critical Exam Note:
- If the scenario mentions regulatory compliance (SEC, FINRA, HIPAA) or true WORM → Compliance Mode
- If the scenario mentions governance or soft protection where admins might need override → Governance Mode
- Legal Hold can be applied to both modes for litigation purposes (locks object indefinitely regardless of retention period)
36. EC2 Placement Groups: Cluster vs. Spread vs. Partition
Scenario: You need to control how EC2 instances are placed on underlying hardware.
| Feature | Cluster Placement Group | Spread Placement Group | Partition Placement Group |
|---|---|---|---|
| Primary Use Case | Lowest latency, high throughput between instances (HPC, tightly-coupled workloads). | High availability (each instance on different hardware). | Large distributed workloads (Hadoop, Cassandra, Kafka). |
| Hardware Distribution | All instances in same rack (or close proximity). | Each instance on different rack (different power/network). | Instances spread across partitions (each partition on separate racks). |
| Max Instances | Limited by instance type availability in the rack. | 7 instances per AZ (hard limit). | 7 partitions per AZ; many instances per partition. |
| Network Performance | 10 Gbps+ enhanced networking (lowest latency). | Standard networking. | Standard networking. |
| Failure Isolation | Low (single rack failure affects all). | Highest (each instance isolated). | Medium (partition failure affects only that partition). |
| Multi-AZ | Single AZ only. | Can span multiple AZs. | Can span multiple AZs. |
| Use Cases | HPC, MPI jobs, low-latency trading, ML training. | Critical applications, small number of instances needing max resilience. | HDFS, HBase, Cassandra, Kafka (need partition awareness). |
| Key Limitations | Single point of failure. Single AZ. Capacity constraints. | Limited to 7 instances per AZ. | Partition-level failure still possible. |
| Exam 'Trigger Words' | "Lowest latency", "HPC", "10 Gbps", "Tightly coupled", "Same rack", "High throughput between instances". | "Max availability", "Critical instances", "Each on different hardware", "Rack failure isolation". | "Hadoop", "Cassandra", "Kafka", "HDFS", "Partition-aware", "Large scale distributed". |
Critical Exam Note:
- Cluster = Performance (low latency) → HPC, ML
- Spread = Availability (isolated hardware) → Critical small clusters
- Partition = Large-scale distributed (partition-aware apps) → Big data
37. EBS Volume Types Comparison
Scenario: You need to choose the right EBS volume type based on workload requirements.
| Feature | gp3 (General Purpose SSD) | gp2 (General Purpose SSD) | io2 Block Express | io1 (Provisioned IOPS) | st1 (Throughput Optimized HDD) | sc1 (Cold HDD) |
|---|---|---|---|---|---|---|
| Primary Use Case | Most workloads (cost-effective, flexible). | Legacy general purpose (being replaced by gp3). | Mission-critical apps needing highest IOPS. | High-performance databases (legacy). | Big data, log processing, data warehouses. | Infrequent access cold data (lowest cost). |
| Volume Type | SSD | SSD | SSD | SSD | HDD | HDD |
| IOPS | Baseline 3,000 IOPS (up to 16,000). | 3 IOPS/GB (up to 16,000). | Up to 256,000 IOPS. | Up to 64,000 IOPS. | Max 500 IOPS. | Max 250 IOPS. |
| Throughput | Baseline 125 MB/s (up to 1,000 MB/s). | Up to 250 MB/s. | Up to 4,000 MB/s. | Up to 1,000 MB/s. | Up to 500 MB/s. | Up to 250 MB/s. |
| Size Range | 1 GiB - 16 TiB. | 1 GiB - 16 TiB. | 4 GiB - 64 TiB. | 4 GiB - 16 TiB. | 125 GiB - 16 TiB. | 125 GiB - 16 TiB. |
| Pricing | IOPS and throughput independent of size. | IOPS tied to volume size. | Highest cost. | High cost. | Low cost. | Lowest cost. |
| Boot Volume | Yes. | Yes. | Yes. | Yes. | No. | No. |
| Multi-Attach | No. | No. | Yes (io2 Block Express only). | Yes. | No. | No. |
| Durability | 99.8% - 99.9%. | 99.8% - 99.9%. | 99.999%. | 99.8% - 99.9%. | 99.8% - 99.9%. | 99.8% - 99.9%. |
| Use Cases | Web servers, dev/test, small DBs. | Legacy workloads. | SAP HANA, Oracle, SQL Server (critical). | High-perf databases. | Streaming, Kafka, ETL, data lakes. | Backups, archives, cold data. |
| Key Limitations | Max 16,000 IOPS. | IOPS linked to size (expensive for high IOPS). | Very expensive. | Max 64,000 IOPS. | Low IOPS (not for transactional). | Lowest performance. |
| Exam 'Trigger Words' | "General purpose", "Cost-effective", "Flexible IOPS", "Default choice". | "Legacy", "gp2" (usually means upgrade to gp3). | "256,000 IOPS", "Mission-critical", "SAP HANA", "Highest performance", "Multi-Attach". | "Provisioned IOPS", "io1", "High-performance database". | "Big data", "Throughput", "Streaming", "Log processing", "Data warehouse", "Sequential reads". | "Cold data", "Lowest cost", "Infrequent access", "Archive". |
Quick Decision Guide:
| If you need... | Choose... |
|---|---|
| General workload, best value | gp3 |
| Highest IOPS (64K+), mission-critical DB | io2 Block Express |
| High IOPS databases (legacy or cost-conscious) | io1 |
| High throughput, sequential (big data) | st1 |
| Lowest cost, cold data | sc1 |
38. Amazon GuardDuty vs. Amazon Inspector vs. Amazon Macie
Scenario: You need to protect your AWS environment from threats or ensure compliance.
| Feature | Amazon GuardDuty | Amazon Inspector | Amazon Macie |
|---|---|---|---|
| Primary Use Case | Threat detection (malicious activity, account compromise, reconnaissance). | Vulnerability scanning (CVEs, network exposure on EC2/containers). | Data security (discover and protect sensitive data in S3). |
| What It Scans | VPC Flow Logs, CloudTrail, DNS logs, EKS audit logs, S3 data events. | EC2 instances, ECR images, Lambda functions (software vulnerabilities). | S3 buckets (PII, credentials, financial data). |
| Detection Type | Threat intelligence + ML anomaly detection. | CVE database (known vulnerabilities), CIS benchmarks. | ML-based pattern matching (sensitive data classification). |
| Real-Time | Near real-time (continuous monitoring). | On-demand or scheduled scans. | Continuous monitoring of S3. |
| Agent Required | No (analyzes AWS logs). | Yes (SSM agent for EC2 deep inspection). | No (analyzes S3 metadata and objects). |
| Findings | Suspicious IPs, crypto mining, compromised credentials, data exfiltration. | CVE IDs, network reachability issues, package vulnerabilities. | PII (SSN, credit cards), API keys, passwords in S3. |
| Remediation | Integrates with EventBridge, Lambda for automated response. | Integrates with Security Hub, EventBridge. | Integrates with EventBridge, Security Hub. |
| Cost Model | Per GB of logs analyzed + per million events. | Per instance/image/Lambda scanned. | Per GB of S3 data processed. |
| Use Cases | Detect hackers, compromised instances, unusual API calls. | Pre-deployment vulnerability assessment, compliance (CIS). | GDPR/PCI compliance, find exposed secrets in S3. |
| Key Limitations | Doesn't remediate (only detects). | Doesn't detect active threats. | S3 only (no EC2 or other services). |
| Exam 'Trigger Words' | "Threat detection", "Malicious activity", "Compromised credentials", "Unusual API activity", "Crypto mining". | "CVE", "Vulnerability scanning", "CIS benchmarks", "EC2 security", "Container scanning", "Package vulnerabilities". | "Sensitive data", "PII", "S3 security", "Data classification", "GDPR", "Find credentials in S3". |
Key Distinction for Exam:
- GuardDuty = "Who is attacking me?" (threat detection, anomalies)
- Inspector = "Am I vulnerable?" (software CVEs, misconfigurations)
- Macie = "Is my S3 data exposed?" (sensitive data discovery)
Quick Summary Cheat Sheet
| If the exam asks for... | And mentions... | The answer is likely... |
|---|---|---|
| High Performance Routing | "Static IP" or "UDP", "Gaming" | Global Accelerator |
| High Performance Content | "Caching", "CDN", "S3" | CloudFront |
| Private Internet Access | "Managed", "Scalable", "HA" | NAT Gateway |
| Private Internet Access | "Bastion", "Port forwarding", "Cost optimize" | NAT Instance |
| Firewall/Security | "Block specific IP", "Deny rule" | Network ACL |
| Firewall/Security | "Stateful", "Instance-level" | Security Group |
| Storage Cost IA | "Re-creatable data", "Single AZ" | S3 One Zone-IA |
| Storage Cost IA | "Disaster Recovery", "Multi-AZ" | S3 Standard-IA |
| File Storage | "Shared", "NFS", "Linux", "Multi-instance" | EFS |
| File Storage | "Windows", "SMB", "File Server" | FSx for Windows |
| File Storage | "HPC", "Lustre", "ML" | FSx for Lustre |
| Block Storage | "Boot volume", "Single instance", "High IOPS" | EBS |
| Load Balancing | "Path-based routing", "HTTP", "Lambda" | ALB |
| Load Balancing | "Static IP", "TCP/UDP", "Ultra-low latency" | NLB |
| Load Balancing | "Third-party appliance", "IDS/IPS", "Inline inspection" | GWLB |
| Database | "SQL", "Relational", "Complex queries", "Joins" | RDS |
| Database | "NoSQL", "Key-value", "Millisecond latency", "Scale" | DynamoDB |
| Database | "High performance", "Cloud-native", "15 read replicas" | Aurora |
| Messaging | "Queue", "Decouple", "Async", "Pull" | SQS |
| Messaging | "Pub/Sub", "Fanout", "Email", "SMS" | SNS |
| Messaging | "Event-driven", "Pattern matching", "SaaS integration" | EventBridge |
| Streaming | "Real-time", "Replay", "Shards" | Kinesis Data Streams |
| Streaming | "Near real-time", "S3", "Redshift", "Auto-scale" | Kinesis Data Firehose |
| Compute | "Serverless", "Event-driven", "15 min max" | Lambda |
| Compute | "Docker", "Long-running", "AWS-native" | ECS |
| Compute | "Kubernetes", "Portability", "Multi-cloud" | EKS |
| Compute | "Serverless containers", "No EC2" | Fargate |
| Monitoring | "Metrics", "Alarms", "Logs", "Dashboard" | CloudWatch |
| Monitoring | "Audit", "Who did what", "API calls" | CloudTrail |
| Monitoring | "Compliance", "Configuration", "Drift" | AWS Config |
| Workflow | "Serverless", "State machine", "Visual" | Step Functions |
| Workflow | "Long-running (1+ year)", "External signals" | SWF |
| VPC Connectivity | "2 VPCs", "Peering" | VPC Peering |
| VPC Connectivity | "Many VPCs", "Hub-and-spoke", "Centralized" | Transit Gateway |
| VPC Connectivity | "Private service", "No peering", "Endpoint" | PrivateLink |
| Hybrid Network | "Dedicated", "High throughput", "Consistent" | Direct Connect |
| Hybrid Network | "Quick setup", "Encrypted", "Over internet" | Site-to-Site VPN |
| Backup | "Centralized", "Multiple services", "Policy-based" | AWS Backup |
| Backup | "EBS", "Snapshots" | EBS Snapshots |
| Secrets | "Configuration", "Free tier", "Simple" | Parameter Store |
| Secrets | "Auto-rotate", "Database credentials" | Secrets Manager |
| User Auth | "Sign-up/sign-in", "User directory", "MFA" | Cognito User Pools |
| User Auth | "Temporary credentials", "Guest access", "Mobile" | Cognito Identity Pools |
| Security | "SQL injection", "XSS", "Web ACL", "Rate limit" | AWS WAF |
| Security | "DDoS", "Layer 3/4", "Free protection" | AWS Shield Standard |
| Security | "Advanced DDoS", "Response Team" | AWS Shield Advanced |
| Security | "Centralized firewall", "Multiple accounts" | Firewall Manager |
| S3 Glacier | "Millisecond retrieval", "Instant access archive" | Glacier Instant Retrieval |
| S3 Glacier | "Minutes to hours", "1-2 times/year" | Glacier Flexible Retrieval |
| S3 Glacier | "Lowest cost", "48 hours", "Long-term" | Glacier Deep Archive |
| ElastiCache | "Persistence", "Pub/Sub", "Leaderboard", "Multi-AZ" | Redis |
| ElastiCache | "Multi-threaded", "Simple cache", "No persistence" | Memcached |
| Permissions | "Organization-wide", "Guardrails", "All accounts" | SCPs (Service Control Policies) |
| Permissions | "Grant permissions", "User/role", "Specific principal" | IAM Policies |
| Data Transfer | "Automated sync", "Recurring", "Online migration" | AWS DataSync |
| Data Transfer | "Hybrid storage", "On-prem cache", "File Gateway" | Storage Gateway |
| Data Transfer | "Offline", "Petabytes", "Physical device", "No internet" | Snowball |
| Route 53 | "A/B test", "Traffic split", "Percentage" | Weighted Routing |
| Route 53 | "Lowest latency", "Global users", "Performance" | Latency-based Routing |
| Route 53 | "Disaster recovery", "Active-passive", "Failover" | Failover Routing |
| Route 53 | "Geographic location", "Compliance", "Localization" | Geolocation Routing |
| Route 53 | "Proximity", "Bias", "Distance-based" | Geoproximity Routing |
| SQS Queue | "Exactly-once", "Strict ordering", "FIFO", "Financial" | SQS FIFO |
| SQS Queue | "High throughput", "At-least-once", "Order doesn't matter" | SQS Standard |
| EC2 Pricing | "Predictable workload", "1-3 year", "Specific instance" | Reserved Instances |
| EC2 Pricing | "Flexible", "Any instance type", "Lambda + EC2" | Savings Plans |
| EC2 Pricing | "90% savings", "Interruption tolerant", "Batch", "Stateless" | Spot Instances |
| S3 Replication | "Disaster recovery", "Different regions", "Geographic" | Cross-Region Replication (CRR) |
| S3 Replication | "Same region", "Log aggregation", "Test/production" | Same-Region Replication (SRR) |
| Analytics | "Data warehouse", "BI", "Complex queries", "Columnar" | Amazon Redshift |
| Analytics | "Serverless", "Query S3 directly", "Ad-hoc", "Pay per query" | Amazon Athena |
| Analytics | "Big data", "Spark", "Hadoop", "ETL", "Open-source" | Amazon EMR |
| VPC Endpoints | "S3", "DynamoDB", "Free", "Route table" | Gateway Endpoint |
| VPC Endpoints | "Other AWS services", "ENI", "Security Groups" | Interface Endpoint |
| Encryption | "Managed", "AWS integrated", "SSE-KMS", "Envelope" | AWS KMS |
| Encryption | "FIPS 140-2 Level 3", "Dedicated HSM", "Single-tenant" | AWS CloudHSM |
| EC2 Storage | "Ephemeral", "Temporary", "Cache", "Highest IOPS" | Instance Store |
| EC2 Storage | "Persistent", "Database", "Boot volume", "Snapshots" | EBS |
| RDS Availability | "High availability", "Automatic failover", "Standby" | Multi-AZ Deployment |
| RDS Availability | "Read scaling", "Offload reads", "Cross-region" | Read Replicas |
| API Gateway | "Caching", "Request validation", "Usage plans", "WAF" | REST API |
| API Gateway | "Low cost", "Simple API", "Microservices" | HTTP API |
| API Gateway | "Real-time", "Two-way", "Chat", "WebSocket" | WebSocket API |
| S3 Object Lock | "Regulatory compliance", "SEC 17a-4", "WORM", "Immutable" | Compliance Mode |
| S3 Object Lock | "Soft protection", "Internal governance", "Can be overridden" | Governance Mode |
| Placement Groups | "Lowest latency", "HPC", "10 Gbps", "Same rack" | Cluster Placement Group |
| Placement Groups | "Max availability", "Each on different hardware", "7 per AZ" | Spread Placement Group |
| Placement Groups | "Hadoop", "Cassandra", "Kafka", "Partition-aware" | Partition Placement Group |
| EBS Volumes | "General purpose", "Cost-effective", "Default" | gp3 |
| EBS Volumes | "256,000 IOPS", "Mission-critical", "SAP HANA" | io2 Block Express |
| EBS Volumes | "Provisioned IOPS", "High-performance database" | io1 |
| EBS Volumes | "Throughput", "Big data", "Streaming", "Sequential" | st1 |
| EBS Volumes | "Lowest cost", "Cold data", "Archive" | sc1 |
| Security Scanning | "Threat detection", "Malicious activity", "Crypto mining" | GuardDuty |
| Security Scanning | "CVE", "Vulnerability", "EC2 scanning", "CIS benchmarks" | Inspector |
| Security Scanning | "PII", "S3 sensitive data", "GDPR", "Data classification" | Macie |