Learning AWS

Compiled for the Solutions Architect certification, from a Java backend perspective. Core idea: what pain point each service solves, when to choose it, and how to distinguish it from similar services.

1. Storage

1.1 Comparison of the three storage types

Type	Representative service	Access unit	Typical scenario
Block storage	EBS, EC2 Instance Store	Block	Databases, OS disks
File storage	EFS, FSx	Files / directory tree	Multi-instance sharing, NFS/SMB mounts
Object storage	S3	Object (Object + Key)	Static assets, backups, data lakes

Block storage  → like a local hard drive; the OS sees a raw device it formats and mounts itself
File storage   → like a NAS; multiple machines can mount the same directory at once
Object storage → like HTTP PUT/GET key-value; no directory concept, simulated with prefixes

1.2 Amazon S3

Quick reference of core features:

Feature	Description	Common exam point
Versioning	Keeps multiple historical versions of the same Key	Required before you can use CRR / MFA Delete
CRR (Cross-Region Replication)	Asynchronous replication to another Region	Disaster recovery, lower latency
Transfer Acceleration	Speeds up uploads via CloudFront edge nodes	Use when uploading to a distant Region
Lifecycle Policy	Automatically moves objects to another storage class by age	Core cost-saving means
S3 File Gateway	Maps a local SMB/NFS share to S3	Hybrid-cloud file migration
Intelligent-Tiering	Automatically switches between Standard ↔ IA	Use when access patterns are unpredictable

S3 storage class selection decision tree:

High access frequency? → S3 Standard
  ↓ no
Low frequency but occasionally needs immediate retrieval? → S3 Standard-IA
  ↓
Only need a single AZ and can accept loss risk? → S3 One Zone-IA (20% cheaper than IA)
  ↓
Rarely accessed (archive-grade)?
  → Glacier Instant Retrieval  ← millisecond retrieval
  → Glacier Flexible Retrieval ← minutes to hours
  → Glacier Deep Archive       ← 12–48 hours, cheapest

Key points for S3 CRR configuration:

1. Both source and target Buckets must have Versioning enabled
2. Configure a Replication Rule on the source Bucket (choose target Bucket/Region)
3. Create/specify an IAM Role (authorize S3 to read source + write target)
4. The target Bucket can be cross-account, and the storage class can be downgraded (to save cost)
5. Existing objects aren't replicated; only new objects created after the rule are

1.3 Amazon EBS vs EFS vs Instance Store

Characteristic	EBS	EFS	Instance Store
Type	Block storage	File storage (NFS)	Block storage (physical, local)
Persistence	✅ Persistent	✅ Persistent	❌ Gone when the instance stops
Multi-instance mount	❌ (single-mount by default) Multi-Attach has limited support	✅ Mounts on thousands simultaneously
Cross-AZ	❌ Same AZ only	✅ Across AZ/Region	❌ Physically bound
Performance	High (optional io2 Block Express)	Medium (NFS protocol overhead)	Very high (local NVMe)
Typical scenario	Databases, single-instance apps	Multi-instance sharing, CMS	Temporary cache, big-data compute

⚠️ The EBS island effect: EBS can only be mounted within the same AZ. To move across AZs, first take a Snapshot, then create a new EBS from the Snapshot in the target AZ.

1.4 AWS DataSync vs Storage Gateway

Service	Positioning	Typical use
DataSync	High-speed data migration/sync tool	One-time migration + scheduled incremental sync; NFS/SMB → S3/EFS/FSx
S3 File Gateway	Long-term hybrid-cloud storage bridge	Local apps keep using NFS/SMB while data is transparently stored in S3

Migration scenario (temporary) → DataSync (fast, bandwidth-efficient, auto-verify)
Continuous hybrid-cloud storage → Storage Gateway (long-term coexistence)

1.5 Amazon FSx types quick reference

Type	Suitable scenario	Protocol
FSx for Windows	Windows apps, AD integration	SMB
FSx for Lustre	HPC, machine learning, high-performance computing	Lustre (can connect directly to S3)
FSx for NetApp ONTAP	Enterprise NAS migration to the cloud	NFS/SMB/iSCSI
FSx for OpenZFS	ZFS filesystem migration	NFS

2. Database

2.1 Database selection quick reference

Requirement	Recommended service	Reason
Relational, low traffic	RDS (MySQL/PostgreSQL)	Standard managed, reasonable cost
Relational, high performance/availability	Aurora	5x MySQL performance, automatic multi-replica
NoSQL, ultra-low latency	DynamoDB	Single-digit ms, fully serverless
DynamoDB acceleration	DAX	Microsecond in-memory cache, transparent to the app
OLAP data warehouse	Redshift	Columnar storage, PB-scale analytics queries
In-memory cache	ElastiCache	Managed Redis / Memcached

2.2 What pain point Amazon Aurora solves

Traditional RDS MySQL pain point   Aurora's solution
─────────────────────────────────────────────
Hard to scale               →  Storage auto-scales (up to 128TB)
Hard to keep highly available (crashes easily) → 6 replicas across 3 AZs, 1 writer + up to 15 read replicas
Poor high-concurrency support → Aurora Serverless v2 auto scale in/out
High ops cost               →  Fully managed, automatic patching/backup
Low storage utilization     →  Log-structured storage, shared physical space
Slow startup, poor elasticity → Aurora Serverless second-level cold start

Aurora vs RDS choice:

Need high availability, high concurrency, read scaling → Aurora
Ordinary app, cost-sensitive → RDS

2.3 DynamoDB core concepts

Table
  └── Item (row, max 400KB)
        └── Attribute (column, dynamic schema)

Primary key types:
  Partition Key (hash key)  → determines which partition data lands in
  Partition Key + Sort Key  → composite key, sorted by Sort Key within a partition

Read/write capacity modes:
  Provisioned → manually set RCU/WCU (good for steady traffic, saves money)
  On-Demand   → billed per request (good for variable traffic, no estimating needed)

DAX (DynamoDB Accelerator):

App → DAX (in-memory cache, microsecond response) → DynamoDB
           ↑ cache hit returns directly
           ↓ only on a miss does it go back to DynamoDB

Good for: read-heavy, write-light; the same Query executed repeatedly
Not good for: strongly-consistent reads, write-intensive scenarios

3. Messaging

Characteristic	SNS	SQS	EventBridge
Model	Publish/subscribe (Push)	Queue (Poll)	Event bus (routing)
Consumers	Multiple subscribers receive simultaneously	One consumer processes one message	Multiple Targets routed in parallel
Persistence	❌ (not persistent, gone once sent)	✅ (kept up to 14 days)	❌ (not stored after routing)
Retry	Limited	✅ (Visibility Timeout)	✅ (configurable retry policy)
Message ordering	❌	Supported by FIFO Queue	❌
Typical scenario	Notification broadcast, triggering multiple systems	Task queue, peak shaving	Responding to AWS service events

3.2 The SNS + SQS fan-out pattern ⭐

Scenario: one message needs to be distributed simultaneously to multiple independent consumers (microservices)

                    ┌── SQS Queue A ── Microservice A (send email)
Producer → SNS Topic ┤
                    ├── SQS Queue B ── Microservice B (log)
                    └── SQS Queue C ── Microservice C (update inventory)

Why not use SNS directly?

SNS pushes directly to services; if a microservice is down, the message is permanently lost. With SQS as a buffer, messages pile up in the queue and are consumed after the service recovers — zero loss.

Key configuration points:

1. Create an SNS Topic
2. Create a separate SQS Queue for each downstream service
3. Have each SQS Queue subscribe to the SNS Topic
4. Each downstream service polls its own SQS Queue
5. Enable an SQS DLQ (dead-letter queue) to handle failed messages

3.3 SQS core concepts

Standard Queue → at-least-once delivery, approximate FIFO, high throughput
FIFO Queue     → exactly-once delivery, strictly ordered, 300 TPS cap

Visibility Timeout:
  The time window during which a message, after being taken by a consumer, is invisible to others
  The consumer must DeleteMessage before the timeout, or the message becomes visible again

DLQ (Dead Letter Queue):
  A message that exceeds maxReceiveCount without being processed successfully → moved to the DLQ
  Purpose: troubleshooting, avoiding a poison message jamming the queue

4. Compute

4.1 EC2 core

How an Auto Scaling Group (ASG) works:

Define: min / desired / max instance count
      ↓
CloudWatch monitors metrics (CPU, request count, etc.)
      ↓
Triggers a Scaling Policy (scale out / scale in)
      ↓
The ALB automatically registers/deregisters instances

Scaling policy types:

Policy	Description
Target Tracking	Keeps a metric at a target value (most recommended, e.g. CPU=60%)
Step Scaling	Scales by stepped rules (add 2 above 70%, add 5 above 90%)
Scheduled Scaling	Scales on a schedule (scale out at 8am, scale in at 10pm)
Predictive Scaling	ML predicts future traffic and scales out ahead of time

4.2 AWS Lambda

Core limits (frequently tested on SAA):

Max execution time: 15 minutes
Memory: 128MB – 10,240MB
Temporary storage (/tmp): up to 10GB
Concurrency: default 1000/Region (can request an increase)
Deployment package size: 50MB (zip), 250MB (unzipped)

Judging when Lambda fits:

✅ Good for Lambda:
  - Event-triggered (S3 upload, API request, scheduled task)
  - Execution time < 15 minutes
  - Stateless processing
  - Highly variable traffic (don't want to manage servers)

❌ Not good for Lambda:
  - Long-running tasks (>15 minutes) → use Fargate / EC2
  - Need to persist local state → use EC2 + EBS
  - High, continuous load (cold-start cost) → use EC2 + ASG

A typical Lambda + API Gateway architecture (Serverless):

User request → Route 53 → API Gateway
                           ↓
                       Lambda function
                           ↓
                   DynamoDB / S3 / RDS

5. Networking & Connectivity

5.1 CloudFront vs Global Accelerator

Dimension	CloudFront (CDN)	Global Accelerator
Core ability	Caches content, reducing origin fetches	Optimizes the path, reducing network hops
Protocol	HTTP/HTTPS	All protocols (TCP/UDP)
Caching	✅ Has caching	❌ No caching, pass-through
IP address	Dynamic (DNS resolution)	Static Anycast IP (2)
Suitable scenario	Static assets, website acceleration	Gaming, VoIP, financial trading, global APIs

Mnemonic:
CloudFront = content caching (move things close to the user)
Global Accelerator = network speedup (take the AWS highway, not the public internet)

5.2 VPC core components

VPC (Virtual Private Cloud)
├── Subnet
│   ├── Public Subnet  → has an Internet Gateway route; instances can have public IPs
│   └── Private Subnet → no direct public access; egress via a NAT Gateway
├── Internet Gateway (IGW) → the door for the VPC to reach the public internet
├── NAT Gateway  → egress to the public internet for private-subnet instances (one-way)
├── Route Table  → controls traffic direction
├── Security Group (SG) → instance-level, stateful firewall
└── Network ACL (NACL)  → subnet-level, stateless firewall

Key SG vs NACL differences:

Characteristic	Security Group	Network ACL
Scope	Instance (ENI)	Subnet
State	Stateful (return traffic auto-allowed)	Stateless (must write rules for both in and out explicitly)
Rules	Allow only	Allow + Deny
Evaluation	Union of all rules	By rule number, first match wins

⚠️ NACL being stateless is a frequent exam point: if you only allow inbound HTTP but don’t allow the outbound response ports, traffic will be blocked.

5.3 VPC Endpoints

Problem: an EC2 in a VPC accessing S3 sends traffic over the public internet by default → security risk + traffic cost

Solution: VPC Endpoint (private direct connection, bypassing the public internet)

Types:
  Gateway Endpoint  → S3, DynamoDB (free, configured in the Route Table)
  Interface Endpoint → other AWS services (paid, deploys an ENI into the subnet)

5.4 Comparison of connectivity options

Scenario	Recommended option
On-prem data center ↔ AWS (low latency, high security)	AWS Direct Connect (dedicated line, physical connection)
On-prem data center ↔ AWS (encrypted tunnel)	Site-to-Site VPN (over the public internet but encrypted, low cost)
Developer laptop ↔ resources in a VPC	Client VPN
Private connectivity between different VPCs	VPC Peering or Transit Gateway
Star interconnection of multiple VPCs / on-prem	Transit Gateway (hub-spoke topology)

5.5 Route 53 routing policies

Policy	Description	Scenario
Simple	Direct resolution, no special logic	Single endpoint
Weighted	Split by weight (A:70%, B:30%)	Canary release, A/B testing
Latency	Route to the lowest-latency Region	Global multi-Region deployment
Failover	Active-passive switch, triggered by health checks	Disaster recovery
Geolocation	Route by the user’s geographic location	Compliance (European users only reach Europe)
Geoproximity	Route by distance + bias weight	Fine-grained traffic shifting
Multi-Value	Return multiple healthy IPs	Simple client-side load balancing

6. Security & IAM

6.1 IAM core concepts

User    → corresponds to a specific person or program, has AK/SK
Group   → a collection of users; policies attached to the group
Role    → a temporary identity; EC2/Lambda/cross-account assume role
Policy  → a JSON document defining permissions

Policy types:

Type	Attached to	Description
Identity-based Policy	User/Group/Role	What permissions the principal has
Resource-based Policy	S3 Bucket / KMS Key, etc.	Who can access this resource
SCP (Service Control Policy)	AWS Organizations OU	The maximum permission boundary for an entire account/OU

Instance Profile:

Problem: an app on EC2 needs to access S3, but you can't hardcode AK/SK in the code

Solution:
  1. Create an IAM Role with an S3-access policy attached
  2. Create an Instance Profile associated with that Role
  3. Attach the Instance Profile when launching the EC2
  4. The app automatically gets temporary credentials via 169.254.169.254 (the metadata endpoint)

The Java SDK automatically reads temporary credentials from Instance Metadata — no configuration needed

6.2 AWS Secrets Manager vs Parameter Store

Characteristic	Secrets Manager	Parameter Store
Positioning	Designed specifically for sensitive credentials	Config parameters + sensitive info
Automatic rotation	✅ (integrates Lambda to rotate passwords on a schedule)	❌ (no automatic rotation)
Cost	Billed per secret (per/month)	Standard parameters free, advanced parameters paid
Typical use	DB passwords, API keys, OAuth tokens	App config, feature flags, a few secrets
Versioning	✅	✅
Cross-Region replication	✅	❌

Mnemonic: need automatic password rotation → Secrets Manager; ordinary config / occasionally-used secrets → Parameter Store (cheaper)

6.3 The security service matrix

Service	Function	Analogy
GuardDuty	Threat detection (anomalous behavior, malicious IPs)	Intrusion detection system (IDS)
Inspector	Vulnerability scanning (EC2/containers/Lambda)	Automated vulnerability scanner
Security Hub	Aggregates security findings across accounts	SIEM aggregation panel
Macie	S3 data classification, discovering PII	Data security classification (DLP)
Shield	DDoS protection (Standard free, Advanced paid)	Anti-DDoS
WAF	Web application firewall (SQL injection, XSS, etc.)	WAF
Firewall Manager	Unified security rule management across accounts	Centralized security policy
Network Firewall	VPC-level deep packet inspection firewall	Advanced NACL + IPS
KMS	Key management, encryption/decryption service	HSM key management
CloudHSM	Dedicated hardware security module	Physical HSM

6.4 AWS Organizations & SCP

Management Account (root account)
└── Root
    ├── OU (R&D department)
    │   ├── Member Account A (Dev environment)
    │   └── Member Account B (Test environment)
    └── OU (Production department)
        └── Member Account C (Prod environment)

An SCP (Service Control Policy) applies to an OU or account:
  - Grants no permissions, only limits the permission ceiling
  - Even if the IAM Policy allows it, if the SCP denies it, it can't be executed
  - Use: forbid a production account from using unauthorized Regions, forbid deleting CloudTrail

7. Analytics

7.1 The analytics service landscape

Ingestion layer:
  Kinesis Data Streams → real-time data inflow (custom consumers)
  Kinesis Firehose     → delivers data directly to S3/Redshift/ES (no code)
  AWS Glue             → ETL service, data transformation and cleaning

Storage layer:
  S3         → data lake
  Redshift   → data warehouse

Query/analysis layer:
  Athena     → SQL directly over S3 (serverless, billed by scan volume)
  Redshift   → complex OLAP analysis
  EMR        → managed Hadoop/Spark clusters (large-scale processing)

Visualization layer:
  QuickSight → BI dashboards, connects to Athena/Redshift/S3

7.2 The three Kinesis siblings

Service	Positioning	Analogy
Kinesis Data Streams	Real-time data stream, consumers handle it with custom code	Kafka (write your own consumers)
Kinesis Data Firehose	Delivers streaming data directly to a destination, fully managed	Kafka + Fluentd (auto-write)
Kinesis Data Analytics	Runs SQL/Flink queries on stream data	Flink (real-time analytics)

7.3 Athena use cases

Typical scenario:
  S3 holds large amounts of JSON/CSV/Parquet logs
  → you don't want to stand up a Spark cluster
  → just write SQL queries in Athena
  → billed by data scanned (the Parquet columnar format greatly reduces scan volume)

Cost optimization:
  Raw JSON → convert to Parquet (Glue ETL)
  → the same query cost can drop by ~87%

8. Management & Governance

8.1 CloudWatch core

CloudWatch components:
  Metrics    → monitor numeric metrics (CPU, network, custom metrics)
  Logs       → collect and store logs (Log Group > Log Stream)
  Alarms     → trigger alerts based on metrics (notify SNS / trigger ASG)
  Dashboards → visualization panels
  Events     → replaced by EventBridge

Log Group hierarchy:
  Log Group (/aws/lambda/my-function)
    └── Log Stream (2024/01/01/[$LATEST]abc123)
              └── Log Events (an individual log entry)

8.2 CloudTrail vs CloudWatch vs Config

Service	Question it answers	Data type
CloudWatch	How is the system performing now? (What’s the CPU?)	Metrics, logs
CloudTrail	Who did what at what time?	API-call audit logs
AWS Config	What’s the resource configuration change history? Is it compliant?	Configuration snapshots, compliance rules

Remember: CloudTrail = records of human actions; Config = records of resource state; CloudWatch = system runtime monitoring

8.3 AWS SSM (Systems Manager)

Core features:
  Session Manager  → connect to EC2 straight from the browser without SSH/RDP (no need to open port 22)
  Run Command      → run commands remotely in bulk (no SSH into each machine)
  Patch Manager    → automated patch management
  Parameter Store  → configuration parameter storage
  Automation       → define ops Runbooks and execute them automatically

9. Architecture Design Patterns

9.1 High-availability design principles

Core principle: eliminate single points of failure (SPOF)

Multi-AZ deployment:
  EC2 → cross-AZ ASG + ALB
  RDS → Multi-AZ (synchronous replication, automatic failover)
  ElastiCache → Multi-AZ with auto-failover
  
Multi-Region deployment (higher tier):
  Route 53 Failover/Latency routing
  S3 CRR (data replication)
  Aurora Global Database (< 1s RPO)

9.2 Decoupling architecture patterns

Tight coupling (anti-pattern):
  Service A → synchronous HTTP call → Service B
  Problem: if B goes down A goes down too; if B is slow A is slow too

Loose coupling (recommended):
  Service A → SQS Queue → Service B (async processing)
  Advantages: if B is down messages pile up and are consumed after recovery; peak traffic is buffered by the queue

Fan-out decoupling:
  One message → SNS Topic → N SQS → N consumers

9.3 Problem-solving approaches for common architecture scenarios

Scenario 1: reduce database load

Options:
  Read-heavy, write-light → ElastiCache (Redis) caches hot data
  Read scaling            → Aurora read replicas (up to 15)
  Session state           → store sessions in ElastiCache (not local to EC2)

Scenario 2: handle bursty traffic (variable workloads)

Options:
  Compute layer → EC2 ASG (auto scaling) + Target Tracking
  Queue layer   → SQS peak shaving (frontend responds fast, backend processes slowly)
  Lambda        → naturally supports bursts (concurrency auto-scales)

Scenario 3: migrate on-prem data to the cloud

Option selection:
  Data < TB scale, adequate network → AWS DataSync (online migration)
  Data TB–PB scale, slow network    → AWS Snowball Edge (physical device)
  Continuous hybrid-cloud storage    → Storage Gateway
  Database migration                 → AWS DMS (Database Migration Service)

Scenario 4: accelerate access for global users

Static content (images/CSS/JS) → CloudFront CDN
Dynamic API acceleration       → Global Accelerator
Multi-Region deployment        → Route 53 latency-based routing

Scenario 5: multi-account security governance

Account management → AWS Organizations + OU structure
Permission boundary → SCP (prevents IAM privilege escalation within an account)
Unified security    → Firewall Manager (unified WAF/SG rules)
Audit & compliance  → CloudTrail + AWS Config
Threat detection    → GuardDuty (enable on all accounts)

10. Quick Reference of High-Frequency Exam Points

10.1 Judging the storage type

Keyword	Choice
“shared filesystem”, “multiple EC2 mounting at once”	EFS
“database disk”, “single instance”	EBS
“temporary high-speed cache”, “data lost when instance stops”	Instance Store
“object storage”, “static assets”	S3
“Windows file share”, “SMB”	FSx for Windows
“HPC”, “high-performance computing”	FSx for Lustre

10.2 Judging the database type

Keyword	Choice
“schemaless”, “high concurrency, low latency”	DynamoDB
“microsecond reads for DynamoDB”	DAX
“highly available MySQL/PostgreSQL”, “auto-scaling”	Aurora
“data warehouse”, “OLAP”, “PB-scale analytics”	Redshift
“SQL query over S3”	Athena
“managed Spark/Hadoop”	EMR

10.3 Choosing a message queue

Requirement	Choice
Broadcast to multiple consumers	SNS + SQS fan-out
Task queue, peak shaving	SQS Standard
Strict order, no duplicates	SQS FIFO
Real-time data stream	Kinesis Data Streams
Triggered by AWS service events	EventBridge

10.4 Choosing network connectivity

Requirement	Choice
On-prem ↔ AWS dedicated line, low latency	Direct Connect
On-prem ↔ AWS VPN (quick to set up)	Site-to-Site VPN
Access S3/DynamoDB from a VPC (private)	VPC Gateway Endpoint
Private interconnection of multiple VPCs	VPC Peering / Transit Gateway
HTTP acceleration for global users (caching)	CloudFront
Any-protocol acceleration for global users (routing)	Global Accelerator

10.5 Choosing a security service

Requirement	Choice
Detect anomalous API calls, malicious IPs	GuardDuty
Scan EC2 for vulnerabilities	Inspector
Whether there’s PII in S3 data	Macie
DDoS protection	Shield
SQL injection / XSS protection	WAF
API-call auditing	CloudTrail
Resource configuration compliance checks	AWS Config
Automatic key rotation	Secrets Manager
App configuration parameter storage	Parameter Store

1. Storage#

1.1 Comparison of the three storage types#

1.2 Amazon S3#

1.3 Amazon EBS vs EFS vs Instance Store#

1.4 AWS DataSync vs Storage Gateway#

1.5 Amazon FSx types quick reference#

2. Database#

2.1 Database selection quick reference#

2.2 What pain point Amazon Aurora solves#

2.3 DynamoDB core concepts#

3. Messaging#

3.1 SNS vs SQS vs EventBridge#

3.2 The SNS + SQS fan-out pattern ⭐#

3.3 SQS core concepts#

4. Compute#

4.1 EC2 core#

4.2 AWS Lambda#

5. Networking & Connectivity#

5.1 CloudFront vs Global Accelerator#

5.2 VPC core components#

5.3 VPC Endpoints#

5.4 Comparison of connectivity options#

5.5 Route 53 routing policies#

6. Security & IAM#

6.1 IAM core concepts#

6.2 AWS Secrets Manager vs Parameter Store#

6.3 The security service matrix#

6.4 AWS Organizations & SCP#

7. Analytics#

7.1 The analytics service landscape#

7.2 The three Kinesis siblings#

7.3 Athena use cases#

8. Management & Governance#

8.1 CloudWatch core#

8.2 CloudTrail vs CloudWatch vs Config#

8.3 AWS SSM (Systems Manager)#

9. Architecture Design Patterns#

9.1 High-availability design principles#

9.2 Decoupling architecture patterns#

9.3 Problem-solving approaches for common architecture scenarios#

10. Quick Reference of High-Frequency Exam Points#

10.1 Judging the storage type#

10.2 Judging the database type#

10.3 Choosing a message queue#

10.4 Choosing network connectivity#

10.5 Choosing a security service#