Domain 2: New Solutions on Album69

Amazon API Gateway

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 2 (29%). API Gateway is the front door for serverless APIs. Know REST vs HTTP vs WebSocket, throttling, caching, and integration types.

1. API Types

Type	Protocol	Use Case	Key Features
REST API	HTTP/HTTPS	Full-featured APIs	Caching, usage plans, request validation, API keys
HTTP API	HTTP/HTTPS	Low-latency, low-cost APIs	Simpler, cheaper, JWT auth, no caching
WebSocket API	WebSocket	Real-time bidirectional	Chat, gaming, live dashboards

REST API vs HTTP API:

Amazon CloudFront

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 2 (29%). CloudFront is more than a CDN — it’s a security layer, edge compute platform, and global distribution mechanism. Know origins, cache behaviors, OAC, and WAF integration.

1. Overview

Amazon CloudFront is a global content delivery network (CDN) with 400+ edge locations. It caches content close to users, reduces origin load, and integrates with WAF, Shield, and Lambda@Edge for security and edge compute.

2. Core Components

Distributions

Web distribution: HTTP/HTTPS content (static files, APIs, streaming)
One distribution can have multiple origins and cache behaviors

Origins

Origin Type	Use Case
S3 bucket	Static websites, file downloads
ALB / NLB	Dynamic content, APIs
EC2 / custom HTTP	Any HTTP server
API Gateway	Serverless APIs
MediaStore / MediaPackage	Video streaming

Cache Behaviors

Rules that map URL path patterns to origins and cache settings
Default behavior (*) catches all unmatched paths
More specific paths take precedence (e.g., /api/* before *)

Distribution
├── /api/* → ALB origin (no caching, forward all headers)
├── /static/* → S3 origin (cache 1 year, compress)
└── * → ALB origin (default behavior)

3. Origin Access Control (OAC)

Restricts S3 bucket access to CloudFront only — prevents direct S3 access:

Amazon DynamoDB

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 2 (29%). DynamoDB is a managed key-value/document database that can provide low-latency access at scale when the access pattern, partition key, capacity, and consistency model fit. Know partition keys, GSIs, streams, DAX, Global Tables, and capacity modes.

1. Overview

Amazon DynamoDB is a fully managed NoSQL key-value and document database. It removes database-server provisioning, but table design, capacity mode, quotas, partition-key distribution, consistency, and cost still require architecture decisions. Latency depends on workload and configuration; do not treat a typical service characteristic as an end-to-end guarantee.

Amazon EBS

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 2 (29%). EBS is the block storage behind most EC2 workloads. At the Professional level, focus on volume type selection, snapshot mechanics, and encryption — not just “what is EBS.”

1. Volume Type Selection

Type	Backed by	Use when
gp3	SSD, baseline 3,000 IOPS + 125 MiB/s, independently scalable	Default choice — decouple IOPS/throughput from size
gp2	SSD, bursty IOPS tied to volume size	Legacy; gp3 is cheaper and more flexible for new workloads
io2 / io2 Block Express	SSD, provisioned IOPS, 99.999% durability	I/O-intensive databases needing sustained provisioned IOPS
st1	HDD, throughput-optimized	Big data, log processing — sequential access
sc1	HDD, cold	Infrequent access, lowest cost

Decision rule: Start with gp3 (the current default). Move to io2 only when the workload needs provisioned IOPS beyond what gp3 offers or multi-attach. Use st1/sc1 only for throughput-oriented, non-latency-sensitive workloads — never for boot volumes or databases.

Amazon EC2 Advanced

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 2 (29%). At the professional level, focus on purchasing options, placement groups, instance types for specific workloads, and Spot integration patterns.

1. Purchasing Options

Option	Use Case	Commitment	Discount
On-Demand	Unpredictable, short-term	None	None
Reserved Instances (RI)	Steady-state, predictable	1 or 3 years	Up to 72%
Savings Plans	Flexible steady-state	1 or 3 years	Up to 66%
Spot Instances	Fault-tolerant, flexible	None	Up to 90%
Dedicated Hosts	Licensing, compliance	On-demand or reserved	Varies
Dedicated Instances	Isolation requirement	On-demand or reserved	~10%
Capacity Reservations	Guaranteed capacity in AZ	None (pay on-demand rate)	None

Reserved Instances vs Savings Plans

Feature	Reserved Instances	Savings Plans
Flexibility	Locked to instance type/region	Flexible across instance family, region, OS
Types	Standard, Convertible, Scheduled	Compute, EC2 Instance, SageMaker
Convertible RIs	Can exchange for different type	N/A
Compute Savings Plans	N/A	Most flexible — covers EC2, Lambda, Fargate

Spot Instances

AWS can reclaim with 2-minute warning
Best for: batch processing, CI/CD workers, stateless web servers, HPC
Spot Fleet: mix of Spot + On-Demand across instance types and AZs
EC2 Auto Scaling with Spot: use mixed instances policy for resilience
Spot Blocks (deprecated): verify current availability

2. Placement Groups

Type	Behavior	Use Case
Cluster	Same rack, same AZ	Low latency, high throughput (HPC, ML training)
Spread	Different racks, different AZs	Critical instances, max fault isolation (max 7 per AZ)
Partition	Groups of instances on separate racks	Distributed systems (Hadoop, Kafka, Cassandra)

Cluster: highest network performance (up to 100 Gbps with enhanced networking) but single point of failure at rack level
Spread: max 7 instances per AZ per group — not for large clusters
Partition: up to 7 partitions per AZ, hundreds of instances per partition; each partition is isolated from others

3. Instance Types for Specific Workloads

Family	Optimized For	Examples
C (Compute)	CPU-intensive: web servers, batch, ML inference	c6i, c7g
M (General)	Balanced: app servers, small databases	m6i, m7g
R (Memory)	In-memory databases, caches, big data	r6i, r7g
I (Storage)	High IOPS local NVMe: NoSQL, data warehousing	i3, i4i
G/P (GPU)	ML training, graphics rendering	g5, p4d
Inf (Inferentia)	ML inference (AWS custom chip)	inf2
Trn (Trainium)	ML training (AWS custom chip)	trn1
X (Extra memory)	SAP HANA, large in-memory databases	x2idn
T (Burstable)	Variable workloads with CPU credits	t3, t4g

Graviton (ARM-based)

AWS-designed ARM processors (g suffix: m7g, c7g, r7g)
Up to 40% better price/performance than x86 equivalents
Requires ARM-compatible software/containers
Supported by most Linux distributions and managed services

4. Enhanced Networking and ENA

Elastic Network Adapter (ENA): up to 100 Gbps, lower latency, lower CPU overhead
Elastic Fabric Adapter (EFA): ENA + OS-bypass for HPC/ML (MPI workloads)
Required for cluster placement groups to achieve maximum throughput
Enable with: aws ec2 modify-instance-attribute --ena-support

5. Storage Options

Storage	Type	Use Case
EBS gp3	SSD, network-attached	General purpose, boot volumes
EBS io2 Block Express	SSD, high IOPS	Databases requiring >64K IOPS
EBS st1	HDD, throughput-optimized	Sequential reads: log processing, data warehouse
EBS sc1	HDD, cold	Infrequently accessed large data
Instance Store	NVMe, ephemeral	Temp data, buffers, caches — lost on stop/terminate

EBS Multi-Attach: io1/io2 volumes can attach to multiple instances in same AZ (cluster-aware file systems only)
EBS Snapshots: incremental, stored in S3, can copy cross-region for DR

6. Auto Scaling Integration

Always deploy across multiple AZs with Auto Scaling
Use mixed instances policy for Spot + On-Demand resilience
Warm pools: pre-initialized instances reduce scale-out latency
Instance refresh: rolling replacement of instances with new launch template
Lifecycle hooks: pause instance launch/termination for custom actions (e.g., drain connections, run scripts)

7. Exam Scenarios

Scenario 1: A company runs a tightly coupled HPC workload requiring maximum network throughput between instances. What is the recommended configuration?

Amazon ECS

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 2 (29%). ECS is the AWS-native container orchestration service. Know Fargate vs EC2 launch types, task definitions, service discovery, and deployment strategies.

1. Overview

Amazon Elastic Container Service (ECS) is a fully managed container orchestration service. It runs Docker containers on either AWS-managed infrastructure (Fargate) or EC2 instances you manage.

2. Launch Types

Feature	Fargate	EC2
Infrastructure management	AWS manages	You manage EC2 instances
Scaling	Task-level	Instance + task level
Cost model	Per vCPU/memory per second	EC2 instance cost + task overhead
Use case	Simplicity, variable workloads	GPU, custom AMI, cost optimization at scale
Spot support	Fargate Spot	EC2 Spot instances
Visibility	Limited OS access	Full OS access

3. Core Concepts

Task Definition

Blueprint for a container (image, CPU, memory, ports, env vars, IAM role, logging)
Versioned — new deployments create new revisions
Supports multiple containers per task (sidecar pattern)

Service

Maintains desired number of running tasks
Integrates with ALB/NLB for load balancing
Supports rolling updates, blue/green deployments (via CodeDeploy)
Auto Scaling based on CPU, memory, or custom CloudWatch metrics

Cluster

Logical grouping of tasks and services
For EC2 launch type: also manages the EC2 instances (via ECS Container Agent)

4. IAM Roles

Role	Purpose
Task Role	Permissions for the application running in the container (e.g., S3 access)
Task Execution Role	Permissions for ECS agent (pull ECR image, write CloudWatch logs, read Secrets Manager)

Both roles are required. Task role = application permissions. Execution role = ECS infrastructure permissions.

Amazon EFS

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 2 (29%). EFS is the shared POSIX file system for Linux workloads. Know performance modes, throughput modes, and when to use EFS vs EBS vs FSx.

1. Overview

Amazon Elastic File System (EFS) is a fully managed, scalable NFS file system for Linux workloads. Multiple EC2 instances, ECS tasks, Lambda functions, and EKS pods can mount the same EFS file system simultaneously.

2. Performance Modes

Mode	Use Case	Latency
General Purpose (default)	Web serving, CMS, home directories	Low (sub-ms)
Max I/O	Big data, media processing, parallel workloads	Higher latency, higher aggregate throughput

Set at creation time — cannot change after creation.

Amazon EKS

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 2 (29%). EKS is the managed Kubernetes service. Know node types, networking (VPC CNI), IAM integration (IRSA), and when to choose EKS over ECS.

1. Overview

Amazon Elastic Kubernetes Service (EKS) is a managed Kubernetes control plane. AWS manages the Kubernetes API server and etcd. You manage the worker nodes (or use Fargate).

EKS vs ECS:

Factor	EKS	ECS
Orchestrator	Kubernetes (open standard)	AWS proprietary
Portability	High — runs anywhere Kubernetes runs	AWS-only
Complexity	Higher — Kubernetes expertise required	Lower
Ecosystem	Large Kubernetes ecosystem	AWS-native integrations
Use case	Kubernetes workloads, multi-cloud, existing K8s	AWS-native, simpler container workloads

2. Node Types

Type	Description	Use Case
Managed Node Groups	AWS provisions and manages EC2 nodes	Standard workloads, automated updates
Self-managed nodes	You manage EC2 instances	Custom AMI, specific configurations
Fargate profiles	Serverless pods — no EC2 management	Variable workloads, simplicity

Fargate Profiles

Define which pods run on Fargate using namespace and label selectors
No node management, no capacity planning
Does not support DaemonSets or privileged containers
Each pod gets its own isolated compute environment

3. Networking — VPC CNI

EKS uses the AWS VPC CNI plugin by default:

Amazon ElastiCache

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 2 (29%). ElastiCache is the in-memory caching layer. Know Redis vs Memcached, caching patterns, and when to use DAX instead.

1. Redis vs Memcached

Feature	Redis	Memcached
Data structures	Strings, hashes, lists, sets, sorted sets, bitmaps, streams	Strings only
Persistence	Yes (RDB snapshots, AOF)	No
Replication	Yes (primary + replicas)	No
Multi-AZ	Yes (automatic failover)	No
Clustering	Yes (Redis Cluster — sharding)	Yes (multi-node)
Pub/Sub	Yes	No
Lua scripting	Yes	No
Geospatial	Yes	No
Use case	Sessions, leaderboards, pub/sub, complex data, HA	Simple caching, horizontal scaling, multi-threaded

Choose Redis for almost all production use cases — it supports HA, persistence, and complex data structures. Choose Memcached only when you need simple, multi-threaded caching with no persistence requirement.

Amazon EventBridge

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domains 2, 3. EventBridge is the event routing backbone. Know event buses, rules, pipes, scheduler, and cross-account patterns.

1. Overview

Amazon EventBridge is a serverless event bus that connects AWS services, SaaS applications, and custom applications using events. It enables loosely coupled, event-driven architectures.

2. Event Buses

Bus Type	Source	Use Case
Default	AWS services	Receive events from all AWS services automatically
Custom	Your applications	Route application events
Partner	SaaS partners (Zendesk, Datadog, etc.)	Receive SaaS events

3. Rules

Rules match incoming events and route them to targets:

Amazon FSx

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 2 (29%). FSx covers four file system types. Know which to use for Windows, HPC, NetApp, and OpenZFS workloads.

1. FSx File System Types

Type	Protocol	Use Case
FSx for Windows File Server	SMB	Windows applications, Active Directory, home directories
FSx for Lustre	Lustre	HPC, ML training, financial modeling, media processing
FSx for NetApp ONTAP	NFS, SMB, iSCSI	Enterprise storage, multi-protocol, data management
FSx for OpenZFS	NFS	Linux workloads needing ZFS features, migration from on-prem ZFS

2. FSx for Windows File Server

Fully managed Windows file system built on Windows Server
SMB protocol — compatible with all Windows applications
Active Directory integration — user authentication via AWS Managed AD or self-managed AD
DFS Namespaces: aggregate multiple file shares under a single namespace
Multi-AZ: active-standby configuration for HA; automatic failover
Single-AZ: lower cost, no automatic failover
Supports: shadow copies (VSS), data deduplication, encryption at rest (KMS)

Use Cases

Lift-and-shift Windows file servers
Home directories for Windows users
SharePoint, SQL Server (user databases), .NET applications

3. FSx for Lustre

High-performance parallel file system for compute-intensive workloads
Sub-millisecond latency, hundreds of GB/s throughput, millions of IOPS
S3 integration: link to S3 bucket; lazy-load data on first access; write results back to S3
Deployment types:
- Scratch: temporary, no replication, highest performance — for short-term processing
- Persistent: replicated within AZ, long-term storage — for ongoing workloads

Use Cases

ML training (SageMaker integration)
HPC simulations
Media rendering and transcoding
Financial risk modeling
Genomics processing

4. FSx for NetApp ONTAP

Fully managed NetApp ONTAP file system
Supports NFS, SMB, and iSCSI simultaneously (multi-protocol)
SnapMirror: replicate to on-premises NetApp or another FSx ONTAP
FlexClone: instant zero-cost clones of volumes (dev/test environments)
Tiering: automatically tier cold data to S3
Multi-AZ and Single-AZ deployment options

Use Cases

Lift-and-shift NetApp workloads
Multi-protocol shared storage
Dev/test with instant clones
Hybrid cloud with on-premises NetApp replication

5. FSx for OpenZFS

Fully managed OpenZFS file system
NFS protocol (v3, v4, v4.1, v4.2)
ZFS features: snapshots, clones, compression, data integrity checksums
Up to 1 million IOPS, sub-millisecond latency
Single-AZ only

Use Cases

Migrate on-premises ZFS workloads to AWS
Linux workloads needing ZFS data management features
Dev/test with instant snapshots and clones

6. Comparison Table

Feature	Windows FS	Lustre	ONTAP	OpenZFS
Protocol	SMB	Lustre	NFS/SMB/iSCSI	NFS
OS	Windows	Linux	Both	Linux
AD integration	Yes	No	Yes	No
S3 integration	No	Yes	No	No
Multi-AZ	Yes	No	Yes	No
Multi-protocol	No	No	Yes	No
HPC performance	No	Yes	No	No

7. Exam Scenarios

Scenario 1: A company is migrating Windows file servers to AWS. Users authenticate with Active Directory. What is the solution?

Amazon Kinesis

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 2 (29%). Kinesis is the real-time streaming platform. Know Data Streams vs Firehose vs Data Analytics and when to use Kinesis vs SQS vs MSK.

1. Kinesis Services Overview

Service	Purpose
Kinesis Data Streams	Real-time data streaming, custom consumers
Kinesis Data Firehose	Managed delivery to S3, Redshift, OpenSearch, Splunk
Kinesis Data Analytics	Real-time SQL/Apache Flink analytics on streams
Kinesis Video Streams	Stream video from devices for ML/analytics

2. Kinesis Data Streams

Architecture

Producers → Kinesis Data Stream (shards) → Consumers
(EC2, Lambda, [shard 1] [shard 2] (Lambda, KCL app,
 IoT, mobile) [shard 3] [shard 4] Firehose, Analytics)

Shards

Each shard: 1 MB/s write, 2 MB/s read
Scale by adding/removing shards (resharding)
Enhanced fan-out: 2 MB/s per consumer per shard (dedicated throughput)
Partition key determines which shard receives the record

Retention

Default: 24 hours
Extended: up to 365 days (additional cost)
Records are immutable — consumers track position with sequence numbers

Consumers

Consumer Type	Throughput	Use Case
Standard (polling)	2 MB/s shared across all consumers	Low-volume, cost-sensitive
Enhanced fan-out	2 MB/s per consumer per shard	Multiple consumers, low latency

Lambda Integration

Lambda polls shards (event source mapping)
Batch size: 1–10,000 records
Parallelization factor: up to 10 concurrent Lambda invocations per shard
Failed batches: retry until success or record expires (use bisect on error + DLQ)

3. Kinesis Data Firehose

Fully managed delivery stream — no shards, no consumers to manage
Near real-time: buffers data (60 seconds or 1–128 MB) before delivery
Destinations: S3, Redshift, OpenSearch, Splunk, HTTP endpoints, Datadog
Built-in data transformation via Lambda
Built-in format conversion: JSON → Parquet/ORC (for Athena/Redshift Spectrum)
Automatic scaling — no capacity management

Producers → Firehose → (optional Lambda transform) → S3 / Redshift / OpenSearch

4. Kinesis Data Analytics

Run SQL queries or Apache Flink applications on streaming data
Input: Kinesis Data Streams or Firehose
Output: Kinesis Data Streams, Firehose, Lambda
Use cases: real-time dashboards, anomaly detection, time-series analytics

5. Kinesis vs SQS vs MSK

Feature	Kinesis Data Streams	SQS	MSK (Kafka)
Ordering	Per shard	FIFO only	Per partition
Retention	24h–365 days	Up to 14 days	Configurable (days–forever)
Consumers	Multiple (replay)	One per message	Multiple consumer groups
Replay	Yes	No	Yes
Throughput	MB/s per shard	Unlimited	Very high
Management	Low	None	Higher (MSK managed)
Use case	Real-time streaming, replay	Work queues, decoupling	Kafka ecosystem, high throughput

Key differentiator: Kinesis and Kafka support replay (re-read old records). SQS does not — messages are deleted after consumption.

Amazon MSK (Managed Streaming for Apache Kafka)

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 2 (29%). MSK is the answer when the question mentions Kafka, existing Kafka workloads, or Kafka ecosystem tools.

1. Overview

Amazon MSK is a fully managed Apache Kafka service. It provisions, configures, and maintains Kafka brokers and ZooKeeper nodes. You retain full Kafka API compatibility.

When to choose MSK over Kinesis:

Existing Kafka workloads or Kafka expertise
Need Kafka ecosystem tools (Kafka Connect, Kafka Streams, Schema Registry)
Very high throughput requirements
Long message retention (days to forever)
Multiple consumer groups with independent offsets

2. MSK vs Kinesis Data Streams

Feature	MSK	Kinesis Data Streams
API	Kafka API	AWS proprietary
Ecosystem	Full Kafka ecosystem	AWS-native only
Retention	Configurable (unlimited)	24h–365 days
Consumer groups	Multiple independent	Multiple (enhanced fan-out)
Management	More (broker config, ZooKeeper)	Less (shard management only)
Throughput	Very high	High (per shard)
Pricing	Per broker hour	Per shard hour + data
Use case	Kafka migration, ecosystem tools	AWS-native streaming

3. MSK Serverless

No broker management — fully serverless
Automatically scales capacity
Pay per usage (storage + throughput)
Supports standard Kafka APIs
Use for: variable workloads, new Kafka applications without capacity planning

4. MSK Connect

Managed Kafka Connect — run connectors without managing workers
Source connectors: ingest data from databases, S3, etc. into Kafka
Sink connectors: deliver Kafka data to S3, OpenSearch, databases, etc.
Auto-scaling connector workers

5. Security

Encryption in transit: TLS between clients and brokers
Encryption at rest: KMS
Authentication: TLS mutual auth, SASL/SCRAM, IAM (MSK Serverless)
VPC: brokers deployed in your VPC subnets
Private connectivity: access via VPC, VPN, or Direct Connect

6. Exam Scenarios

Scenario 1: A company is migrating an on-premises Kafka cluster to AWS. They use Kafka Connect, Kafka Streams, and Schema Registry. What is the solution?

Amazon OpenSearch Service

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 2 (29%). OpenSearch is the answer for full-text search and log analytics. Know ingestion patterns, domain design, and integration with CloudWatch and Kinesis.

1. Overview

Amazon OpenSearch Service (formerly Elasticsearch Service) is a managed search and analytics engine. It is used for full-text search, log analytics, real-time application monitoring, and clickstream analytics.

When to choose OpenSearch:

Full-text search with relevance scoring
Log aggregation and analysis (ELK stack replacement)
Real-time analytics on streaming data
Geospatial search

2. Core Concepts

Domain: an OpenSearch cluster (collection of nodes)
Index: collection of documents (like a database table)
Document: JSON object stored in an index
Shard: subdivision of an index for distribution across nodes
Replica shard: copy of a shard for redundancy and read scaling

3. Domain Design

Node Types

Type	Purpose
Data nodes	Store and search data
Master nodes	Cluster management (dedicated recommended for production)
UltraWarm nodes	Low-cost warm storage for infrequently accessed data
Cold storage	S3-backed, lowest cost for rarely accessed data

High Availability

Deploy across 3 AZs with 3 dedicated master nodes
Use Multi-AZ with Standby for automatic failover (OpenSearch 2.x+)
Replica shards in different AZs for data redundancy

4. Ingestion Patterns

Source	Method
CloudWatch Logs	CloudWatch Logs subscription filter → Lambda → OpenSearch
Kinesis Data Firehose	Firehose delivery stream → OpenSearch (built-in integration)
DynamoDB Streams	DynamoDB Streams → Lambda → OpenSearch
S3	S3 → Lambda → OpenSearch
Application	Direct HTTP API (REST)
IoT	IoT Rules → Kinesis → OpenSearch

Kinesis Data Firehose is the recommended pattern for high-volume log ingestion — managed, buffered, no Lambda required.

Amazon RDS and Aurora

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 2 (29%). Compare managed relational options by engine compatibility, application requirements, availability, replication, operations, and cost. Know Multi-AZ versus read replicas, Aurora Global Database, and current Aurora Serverless options.

1. RDS Overview

Amazon RDS is a managed relational database service supporting: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Db2.

Multi-AZ Deployment

Synchronous replication to a standby in another AZ
Automatic failover; duration and client recovery depend on engine/deployment, connection handling, and DNS/client caching
Standby is not readable — for HA only, not read scaling
Supports Multi-AZ DB Cluster (2 readable standbys) for MySQL and PostgreSQL

Read Replicas

Asynchronous replication — slight lag
Read-replica counts and supported engines/features vary; check current quotas and engine documentation
Can be in different regions (cross-region read replicas)
Can be promoted to standalone DB (for DR or migration)
Readable — offload read traffic from primary

Multi-AZ vs Read Replicas

Feature	Multi-AZ	Read Replica
Purpose	High availability	Read scaling, DR
Replication	Synchronous	Asynchronous
Readable	No (standby)	Yes
Failover	Automatic	Manual promotion
Cross-region	No (same region)	Yes

2. Aurora Overview

Aurora is an AWS relational database engine compatible with MySQL and PostgreSQL. Compatibility does not guarantee identical engine behavior; performance and availability depend on engine/version, cluster design, instance class, and workload. Benchmark representative queries and transactions.

Amazon S3 Advanced

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domains 2, 3, 4. S3 is foundational to almost every architecture. At the professional level, focus on storage classes, lifecycle, replication, encryption, and access patterns.

1. Storage Classes

Class	Use Case	Retrieval	Min Duration	Min Size
S3 Standard	Frequently accessed	Immediate	None	None
S3 Intelligent-Tiering	Unknown/changing access	Immediate	None	None
S3 Standard-IA	Infrequent, rapid access	Immediate	30 days	128 KB
S3 One Zone-IA	Infrequent, single AZ	Immediate	30 days	128 KB
S3 Glacier Instant Retrieval	Archive, millisecond access	Milliseconds	90 days	128 KB
S3 Glacier Flexible Retrieval	Archive, minutes-hours	Minutes–hours	90 days	40 KB
S3 Glacier Deep Archive	Long-term archive	12–48 hours	180 days	40 KB

Intelligent-Tiering automatically moves objects between access tiers based on usage — no retrieval fees, small monitoring fee per object.

Amazon SQS and SNS

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 2 (29%). SQS and SNS are the decoupling backbone. Know Standard vs FIFO, fan-out patterns, DLQ, and when to use each.

1. Amazon SQS

Queue Types

Feature	Standard	FIFO
Throughput	Unlimited	3,000 msg/s with batching, 300 without
Ordering	Best-effort	Strict (First-In-First-Out)
Delivery behavior	At-least-once delivery; messages can arrive more than once and out of order	Orders delivery within a message group; deduplicates sends within the deduplication interval
Deduplication	No	Yes (5-minute dedup window)
Use case	High throughput, order not critical	Order-critical, financial transactions

Key Settings

Setting	Description
Visibility timeout	Time a message is hidden after being received (default 30s, max 12h)
Message retention	How long messages stay in queue (default 4 days, max 14 days)
Delivery delay	Delay before message is visible (default 0, max 15 min)
Max message size	256 KB (use S3 + SQS Extended Client for larger)
Long polling	Wait up to 20s for messages — reduces empty responses and cost

Dead Letter Queue (DLQ)

Messages that fail processing N times are moved to DLQ
Set maxReceiveCount on the source queue’s redrive policy
DLQ must be same type as source (Standard → Standard DLQ, FIFO → FIFO DLQ)
Use DLQ alarms to detect processing failures

Lambda Integration

Lambda polls SQS (event source mapping)
Batch size: 1–10,000 messages
Lambda scales up to 1,000 concurrent executions for Standard queues
Failed batches: entire batch returned to queue (or sent to DLQ if configured)
Use bisect on error to identify the failing message in a batch

2. Amazon SNS

Overview

SNS is a pub/sub messaging service. Publishers send messages to topics; subscribers receive messages.

AWS Auto Scaling

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 2 (29%). Auto Scaling is fundamental to every HA architecture. Know scaling policies, warm pools, lifecycle hooks, and multi-service scaling.

1. Overview

AWS Auto Scaling automatically adjusts capacity for EC2, ECS, DynamoDB, Aurora, and other services based on demand. It maintains availability and optimizes cost.

Services covered by AWS Auto Scaling:

EC2 Auto Scaling Groups (ASG)
ECS Service Auto Scaling
DynamoDB table/index capacity
Aurora read replicas
Spot Fleet

2. EC2 Auto Scaling Group (ASG)

Key Settings

Setting	Description
Min capacity	Minimum number of instances always running
Max capacity	Maximum instances allowed
Desired capacity	Target number of instances
Launch template	Defines instance configuration (AMI, type, SG, IAM role)
AZ distribution	Spread instances across AZs for HA

Scaling Policies

Policy	Trigger	Use Case
Target Tracking	Maintain a metric at a target value	CPU at 60%, ALB requests per target
Step Scaling	CloudWatch alarm thresholds with step adjustments	Fine-grained control
Simple Scaling	Single CloudWatch alarm	Legacy, not recommended
Scheduled Scaling	Time-based	Known traffic patterns
Predictive Scaling	ML-based forecast	Proactive scaling before demand

Target Tracking is the recommended default — simplest to configure and most responsive.

AWS CDK

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 2 (29%). CDK lets you define infrastructure in familiar programming languages. Know constructs, stacks, apps, and how CDK relates to CloudFormation.

1. Overview

AWS Cloud Development Kit (CDK) is an open-source framework for defining cloud infrastructure using familiar programming languages (TypeScript, Python, Java, C#, Go). CDK synthesizes to CloudFormation templates.

CDK vs CloudFormation:

Feature	CDK	CloudFormation
Language	TypeScript, Python, Java, C#, Go	JSON / YAML
Abstraction	High-level constructs	Low-level resource definitions
Reuse	Libraries, npm/PyPI packages	Nested stacks, modules
IDE support	Full (autocomplete, type checking)	Limited
Output	Synthesizes to CloudFormation	Native
Learning curve	Requires programming knowledge	Lower for simple templates

2. Core Concepts

App

Root of the CDK application
Contains one or more stacks

Stack

Unit of deployment — maps to a CloudFormation stack
Contains constructs (resources)
Can be deployed to a specific account and region

Constructs

Three levels of abstraction:

AWS CloudFormation

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domains 2, 3, 4. CloudFormation is the AWS-native IaC service. Know stacks, StackSets, nested stacks, drift detection, and change sets.

1. Overview

AWS CloudFormation provisions and manages AWS infrastructure as code using JSON or YAML templates. It ensures consistent, repeatable deployments and tracks resource state.

2. Template Anatomy

AWSTemplateFormatVersion: "2010-09-09"
Description: "My stack"

Parameters:
 Environment:
 Type: String
 AllowedValues: [dev, staging, prod]

Mappings:
 RegionMap:
 us-east-1:
 AMI: ami-12345678

Conditions:
 IsProd: !Equals [!Ref Environment, prod]

Resources:
 MyBucket:
 Type: AWS::S3::Bucket
 Properties:
 BucketName: !Sub "my-bucket-${Environment}"

Outputs:
 BucketName:
 Value: !Ref MyBucket
 Export:
 Name: !Sub "${AWS::StackName}-BucketName"

3. Stack Operations

Operation	Description
Create	Provision all resources in template
Update	Modify existing stack — uses change sets
Delete	Remove all stack resources
Detect drift	Compare actual vs expected resource configuration

Change Sets

Preview changes before applying an update
Shows: resources to add, modify, replace, or delete
Replace = resource will be deleted and recreated (potential downtime)
Always review change sets before executing in production

Stack Policies

JSON policy that protects stack resources from unintended updates
Deny updates to specific resources (e.g., production databases)

4. Nested Stacks

Break large templates into reusable components:

AWS Global Accelerator

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 2 (29%). Know when to use Global Accelerator vs CloudFront — a common exam trap.

1. Overview

AWS Global Accelerator improves availability and performance of applications by routing traffic through the AWS global network using anycast static IP addresses. It is not a CDN — it does not cache content.

2. How It Works

User → Nearest AWS Edge Location (anycast IP)
 └── AWS Global Network (private backbone)
 └── Optimal endpoint (ALB, NLB, EC2, EIP)

Two static anycast IP addresses assigned per accelerator (global, never change)
Traffic enters the AWS network at the nearest edge location
Routed over AWS private backbone — avoids public internet congestion
Endpoints can be in multiple regions — Global Accelerator routes to the healthiest, lowest-latency endpoint

3. Global Accelerator vs CloudFront

Feature	Global Accelerator	CloudFront
Content caching	No	Yes
Protocol	TCP, UDP	HTTP/HTTPS
Static IPs	Yes (2 anycast IPs)	No
Use case	Non-HTTP (gaming, IoT, VoIP), static IPs, TCP/UDP	HTTP/HTTPS content delivery, caching
Health checks	Yes (endpoint-level)	Via origin health
Failover	Automatic, ~30 seconds	Via Route 53 health checks
DDoS protection	Shield Standard	Shield Standard
Edge caching	No	Yes

Key rule: If the question mentions static IPs, TCP/UDP (non-HTTP), or instant failover → Global Accelerator. If it mentions caching or HTTP content delivery → CloudFront.

AWS IoT (Core & Greengrass)

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 2 (29%). IoT appears in event-driven and edge scenarios. Know the ingestion paths, the Greengrass vs Outposts distinction, and offline behavior.

1. Overview

AWS IoT connects devices to AWS services for ingestion, processing, and management. At the Professional level, the exam tests architectural choices: how device data enters AWS, what happens during intermittent connectivity, and what runs where.

2. IoT Core Ingestion Paths

Path	Behavior
Message broker (MQTT pub/sub)	Standard path; devices publish, rules engine and subscribers consume
Basic Ingest	Routes device messages directly to the rules engine, skipping the broker pub/sub path

Choose Basic Ingest when device telemetry flows onward for processing (rules engine → Lambda/Kinesis/S3) and nothing needs to consume it via broker subscriptions. It removes cost and hops for the pure-ingestion pattern.

AWS Lambda

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domains 2, 3, 4. Lambda is the serverless compute foundation. Know concurrency, triggers, destinations, VPC integration, and SnapStart.

1. Overview

AWS Lambda runs code in response to events without provisioning or managing servers. You pay only for compute time consumed (per 1-ms increments).

Key characteristics:

Max execution timeout: 15 minutes
Max memory: 10,240 MB (10 GB)
Max deployment package: 50 MB (zipped), 250 MB (unzipped), 10 GB (container image)
Ephemeral storage (/tmp): up to 10 GB

2. Concurrency

Type	Description
Unreserved concurrency	Shared pool across all functions in the account
Reserved concurrency	Guarantees capacity for a function; limits its max concurrency
Provisioned concurrency	Pre-initialized execution environments — eliminates cold starts

Default account limit: 1,000 concurrent executions (can be increased)
Reserved concurrency = 0 → function is throttled (useful to disable a function)
Provisioned concurrency → use for latency-sensitive functions; costs more

Cold Starts

Occur when a new execution environment is initialized
Affected by: runtime (Java/C# slower than Python/Node), VPC attachment, package size
Mitigations: Provisioned Concurrency, SnapStart (Java 11+, Python 3.12+, .NET 8+), keep-warm pings (not recommended at scale)

SnapStart (Java, Python, .NET)

Takes a snapshot of initialized execution environment
Restores from snapshot instead of initializing from scratch
Reduces cold start latency for Java functions by up to 90%
Supported for Java 11+ on Corretto runtime

3. Triggers and Event Sources

Trigger	Invocation Type	Notes
API Gateway / ALB	Synchronous	Request/response
S3	Asynchronous	Object events
DynamoDB Streams	Polling (stream)	Ordered, per-shard
Kinesis Data Streams	Polling (stream)	Ordered, per-shard
SQS	Polling (queue)	Batch processing, DLQ support
SNS	Asynchronous	Fan-out pattern
EventBridge	Asynchronous	Event-driven
CloudWatch Events/Logs	Asynchronous	Scheduled, log-based
Cognito	Synchronous	User pool triggers
Step Functions	Synchronous/Async	Orchestration

Invocation Types

Synchronous: caller waits for response (API Gateway, ALB, Cognito)
Asynchronous: Lambda queues the event; retries on failure (S3, SNS, EventBridge)
Polling: Lambda polls the source (SQS, Kinesis, DynamoDB Streams)

4. Destinations (Async Invocations)

Configure what happens after an async invocation succeeds or fails:

AWS Step Functions

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domains 2, 3. Step Functions is the orchestration layer for complex workflows. Know Standard vs Express, state types, error handling, and integration patterns.

1. Overview

AWS Step Functions is a serverless orchestration service that coordinates distributed components using visual workflows (state machines). It manages state, retries, error handling, and parallel execution.

When to use Step Functions:

Multi-step workflows with branching, parallel execution, or error handling
Long-running processes (up to 1 year)
Coordinating multiple Lambda functions or AWS services
Human approval workflows

2. Workflow Types

Feature	Standard	Express
Max duration	1 year	5 minutes
Execution semantics	Exactly-once workflow execution unless Retry behavior is configured	Asynchronous: at-least-once; synchronous: at-most-once
Execution rate	Region/account quotas vary; check current Service Quotas	Region/account quotas vary; check current Service Quotas
Pricing	Per state transition	Per execution, duration, and memory consumed
Audit history	Full execution history	CloudWatch Logs only
Use case	Long-running, durable, auditable workflows	High-volume, short-duration processing where the chosen delivery semantics fit

Express subtypes:

Deployment Strategies and CI/CD

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 2 (29%). Official Domain 2 task 2.1 covers deployment strategy, change management, rollback, IaC, configuration management, and managed services. Choose a rollout pattern from business risk and recovery requirements.

1. Service Roles

Service	Role	Not a substitute for
AWS CodePipeline	Orchestrates source, build, test, approval, and deploy stages	Build execution or application deployment engine by itself
AWS CodeBuild	Runs managed build/test commands in build environments	Release orchestration or production rollback policy
AWS CodeDeploy	Coordinates supported in-place/blue-green deployments for EC2, on-premises, Lambda, and ECS targets	General-purpose source/build pipeline
AWS CloudFormation / CDK	Provisions and updates infrastructure as code	Application testing or safe data migration
AWS Systems Manager	Configuration, automation, patching, and operational actions	Application release strategy on its own

A typical pipeline uses version control, immutable build artifacts, automated tests, approval gates where required, infrastructure deployment, application rollout, and post-deployment validation. Use least-privilege service roles for each stage.

Elastic Load Balancing

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 2 (29%). Know when to use ALB vs NLB vs GWLB. This is a frequent decision point in architecture scenarios.

1. Load Balancer Types

Feature	ALB	NLB	GWLB
Layer	7 (HTTP/HTTPS)	4 (TCP/UDP/TLS)	3 (IP)
Routing	Path, host, header, query, method	IP, port	Transparent bump-in-wire
Static IP	No (use Global Accelerator)	Yes (Elastic IPs)	Yes
WebSocket	Yes	Yes	N/A
gRPC	Yes	No	N/A
TLS termination	Yes	Yes (TLS passthrough or terminate)	No
Health checks	HTTP/HTTPS	TCP/HTTP/HTTPS	HTTP/HTTPS
Use case	Web apps, microservices, containers	TCP/UDP, static IP, extreme performance	Inline traffic inspection
Target types	Instance, IP, Lambda	Instance, IP, ALB	Instance, IP

2. Application Load Balancer (ALB)

Routing Rules

Path-based: /api/* → service A, /web/* → service B
Host-based: api.example.com → service A, app.example.com → service B
Header-based: route by HTTP header value
Query string: route by query parameter
HTTP method: route by GET/POST/etc.
Source IP: route by client IP CIDR

Target Groups

Targets: EC2 instances, ECS tasks, Lambda functions, IP addresses
Health check: HTTP/HTTPS on configurable path and port
Stickiness: session affinity via cookie (duration-based or application-based)

Authentication

Native OIDC and Cognito authentication at the ALB level
Redirects unauthenticated users to IdP — no application code changes needed

Connection Draining (Deregistration Delay)

Allows in-flight requests to complete before deregistering a target
Default: 300 seconds; set to 0 for immediate deregistration

3. Network Load Balancer (NLB)

Operates at Layer 4 — routes based on IP and port
Handles millions of requests per second with ultra-low latency
Static IPs: one per AZ — useful for whitelisting in firewalls
Elastic IPs: assign your own EIPs to NLB for fixed IPs
TLS termination: NLB can terminate TLS or pass through to targets
Preserve source IP: targets see the client’s real IP (unlike ALB which uses X-Forwarded-For)
Supports PrivateLink — expose services to other VPCs/accounts

NLB + ALB

NLB can target an ALB — combines static IPs (NLB) with advanced routing (ALB):

Purpose-Built Database Selector

Fri, 09 Oct 2026 00:00:00 +0000

Exam relevance: Domain 2 (29%). Start from access patterns, consistency, latency, scale, query shape, and operational constraints. “NoSQL” and “managed” are not sufficient selection criteria.

1. Fast Selection Table

Workload shape	Candidate	Strong fit when	Main design work
Relational OLTP, joins, transactions	Amazon RDS / Aurora	SQL and relational integrity are central	Engine/version fit, HA, connection behavior, backups, read scaling
Key-value/document with known access patterns	DynamoDB	Horizontally scaled, low-latency key access fits the data model	Partition/sort keys, indexes, consistency, hot keys, capacity
MongoDB-compatible document workload	DocumentDB	Application uses supported MongoDB APIs/semantics	Compatibility gaps, indexes, query behavior, migration testing
Apache Cassandra-compatible wide-column workload	Keyspaces	Cassandra-compatible APIs and partitioned workloads fit	Partition keys, clustering, consistency, throughput, query restrictions
Highly connected graph traversal	Neptune	Relationships and graph queries are first-class	Graph model/query language, traversals, replication, workload testing
Time-stamped operational metrics/events	Timestream	Time-series ingest, retention, and time-window queries dominate	Memory/magnetic store retention, dimensions, late-arriving data, query cost
Data warehouse / BI analytics	Redshift	Large analytical scans, joins, aggregations, and warehouse SQL fit	Distribution/sort strategy, concurrency, ingestion, workload isolation
Search, log analytics, text retrieval	OpenSearch	Full-text/search and indexed analytics are required	Index mapping, shard sizing, ingestion, refresh, lifecycle, security
In-memory cache	ElastiCache	Repeated reads or ephemeral low-latency state justify caching	Eviction, TTL, invalidation, failover, cache stampede
Object data lake / durable files	S3 + analytics services	Data is object-shaped and consumers can query/process it	Layout, catalog, governance, lifecycle, query/scan cost

2. Decision Sequence

Define operations: point lookup, range, joins, graph traversal, full-text search, time-window aggregation, or analytical scans.
Define correctness: transactions, read/write consistency, ordering, conflict resolution, and acceptable staleness.
Define scale and shape: read/write rate, item size, skew/hot keys, retention, growth, and regional distribution.
Choose the data model before the service: relational schema, key-value/document, wide column, graph, time series, search index, or warehouse.
Plan migration: engine compatibility, schema/code conversion, data movement, CDC, validation, cutover, rollback, and application changes.
Measure total cost: compute, storage, I/O, replicas, backup, requests, data transfer, retrieval, licensing, and operational effort.

3. Common Near-Misses

DynamoDB vs Keyspaces: access-pattern-first key-value/document design versus Cassandra-compatible wide-column APIs and query model.
DocumentDB vs RDS: document compatibility does not replace relational joins/transactions; validate MongoDB API compatibility for the actual application.
Neptune vs OpenSearch: graph relationship traversals versus text/search and indexed-document retrieval.
Timestream vs DynamoDB: time-series-specific retention/query behavior versus a key-value/document model that can store time-stamped items.
Redshift vs RDS/Aurora: analytical warehouse scans/aggregations versus transactional OLTP.
Cache vs source of truth: ElastiCache can reduce latency/load, but data correctness, invalidation, and cache failure behavior remain application concerns.
S3 data lake vs warehouse: flexible object storage and decoupled analytics versus a managed SQL warehouse with dedicated analytical compute.

4. Exam Scenario

Scenario: A telemetry platform stores device measurements, customer profiles, and device-to-device relationships. Analysts need daily fleet-wide aggregates; the application needs millisecond profile lookups and relationship traversal.