DEV Community: Ntombizakhona Mabaso

Design Cost-Optimized Compute Solutions

Ntombizakhona Mabaso — Sun, 05 Apr 2026 18:30:42 +0000

Exam Guide: Solutions Architect - Associate
⚡ Domain 4: Design Cost-Optimized Architectures
📘 Task Statement 4.2

🎯 Designing Compute Optimized Solutions is about choosing compute that meets performance and availability needs at the lowest reasonable cost.

First decide what type of compute the workload needs (EC2, Lambda, Fargate, containers, edge, hybrid), then choose how to pay for it, then right-size and scale it so you are not paying for idle capacity.

You are balancing:

1 Performance
2 Availability
3 Elasticity
4 Operational Overhead
5 Purchasing Model

Knowledge

1 | AWS Cost Management Service Features

Cost Allocation Tags And Multi-Account Billing

These help you understand and allocate compute cost.

1.1 Cost Allocation Tags

Track compute spend by app, team, environment, owner, cost center

1.2 Multi-Account Billing | Consolidated Billing

Manage cost centrally across multiple AWS accounts
Often used with AWS Organizations

2 | AWS Cost Management Tools

Cost Explorer, Budgets, CUR

1 Cost Explorer: Analyse historical spend and trends
2 AWS Budgets: Alert when spending or usage exceeds thresholds
3 AWS Cost and Usage Report (CUR): Detailed raw billing data for deeper optimization analysis

3 | AWS Global Infrastructure

Regions & Availability Zones (AZs)

Cost and performance can both change based on placement:

1 Running in multiple AZs may cost more, but is often required for production HA
2 Data transfer between Regions can add cost
3 Some workloads can stay single-AZ if non-critical and cheaper

Production → usually Multi-AZ
Dev or test or batch → sometimes cheaper single-AZ is acceptable

4 | AWS Purchasing Options

Spot, Reserved Instances, Savings Plans

4.1 On-Demand

Pay as you go
Flexible, no commitment
Best for short-term or unpredictable usage

“Unpredictable short-term workload” → On-Demand

4.2 Spot Instances

Deep discount for interruptible EC2 capacity
Best for fault-tolerant, stateless, flexible workloads

“Interruptible batch/stateless jobs” → Spot

4.3 Reserved Instances (RIs)

Lower cost for long-term predictable EC2/RDS usage
Capacity reservation options in some cases

4.4 Savings Plans

Flexible pricing commitment across services or instance families (depending on type)
Often simpler and flexible than RIs

“Steady production workload for 1–3 years” → Savings Plans or RIs

5 | Distributed Compute Strategies

Edge Processing

Sometimes cheaper and faster architecture comes from moving compute closer to users or reducing origin load.

Examples:

CloudFront Functions / Lambda@Edge for lightweight logic at the edge
CloudFront caching reduces origin compute cost

6 | Hybrid Compute Options

Outposts & Snowball Edge

6.1 AWS Outposts

Run AWS infrastructure and services on-prem
Used when low latency to on-prem systems or data residency and local processing is needed

6.2 AWS Snowball Edge

Physical device for data transfer and edge compute
Useful in disconnected, harsh and remote environments or massive offline migration

7 | Instance Types, Families, And Sizes

Memory Optimized, Compute Optimized, Virtualizationn

The basics:

Workload	Family
General Purpose	t, m
Compute Optimized	c
Memory Optimized	r, x
Storage Optimized	i, d, some specialized families
GPU / ML / graphics	p, g

Cost Mindset

1 Don’t choose memory-optimized if CPU-bound
2 Don’t over-size “just in case”, rather consider scaling options
3 Burstable (T family) can be cost-effective for low and variable baseline usage

8 | Optimization of Compute Utilization

Containers, Serverless, Microservices

Cost optimization often comes from better utilization:

1. Containers pack workloads more efficiently onto shared compute
2. Fargate avoids paying for idle EC2 hosts you manage yourself
3. Lambda is great for spiky or short-lived workloads
4. Microservices can scale only the busy components, not the whole app

9 | Scaling Strategies

Auto Scaling & Hibernation

9.1 Auto Scaling

Scale out when demand rises, scale in when demand drops
Avoid paying for idle peak capacity all day

9.2 EC2 hibernation

Suspend instance and resume later with RAM state preserved
Useful for dev AND test or intermittent workloads where startup time matters

“Need to pause and resume instance to save cost” → hibernation (if supported).

Skills

A | Determine An Appropriate Load Balancing Strategy

ALB vs NLB vs GWLB

1 Application Load Balancer (ALB)

Best for:

HTTP/HTTPS
Path-based and host-based routing
Layer 7 application routing

2 Network Load Balancer (NLB)

Best for:

TCP/UDP/TLS
Very high performance and static IPs
Layer 4 routing

3 Gateway Load Balancer

Best for:
-Deploying and scaling virtual appliances such as firewalls and inspection tools

Choose the simplest load balancer that meets protocol/routing needs.

B | Determine Appropriate Scaling Methods And Strategies For Elastic Workloads

Horizontal vs Vertical, Hibernation

1 Horizontal scaling

Add more instances/tasks/functions
Usually better for elasticity and resilience

2 Vertical Scaling

Make the instance bigger
Simpler, but less elastic

Production web app → *horizontal scaling *

3 Hibernation

Save money on intermittent EC2 workloads that should resume quickly

Short-lived or intermittent workload → maybe hibernation / scheduled scaling

C | Determine Cost-Effective AWS Compute Services

Lambda, EC2, Fargate

1 Lambda

Best when:

Event-driven
Short-running
Spiky and unpredictable
Minimal ops desired

2 EC2

Best when:

Long-running steady workloads
Need OS control
Can benefit from RIs/Savings Plans/Spot combinations

3 Fargate

Best when:

Containers are needed
Want to avoid managing EC2 hosts
Moderate-to-variable workload patterns

D | Determine The Required Availability For Different Classes Of Workloads

Production vs Non-Production

Not every workload needs the same cost level.

1 Production

Usually Multi-AZ,
Auto Scaling,
HA
More expensive but justified

2 Non-Production / Dev / Test

Smaller instances
Single-AZ
Scheduled shutdown/startup
Spot-friendly
Hibernated/stopped when unused

E | Select The Appropriate Instance Family

Examples:

1. CPU-heavy app → C family
2. Memory-heavy app → R family
3. Small and variable baseline → T family
4. General purpose app → M family

F | Select The Appropriate Instance Size

Right-sizing principles:

1 Start from actual CPU, memory and network needs
2 Use monitoring to reduce overprovisioning
3 Scale horizontally where possible instead of using one oversized box

Cheat Sheet

Requirement	Compute
Steady long-term workload	Savings Plans / Reserved Instances
Interruptible batch or fault-tolerant workload	Spot Instances
Spiky event-driven workload	Lambda
Containerized app, no server management	Fargate
Need OS control or legacy app	EC2
Low and variable baseline workload	T family
Compute-heavy workload	C family
Memory-heavy workload	R family
Pause or resume EC2 to save cost	EC2 hibernation
HTTP/HTTPS routing with app logic	ALB
TCP/UDP with static IPs/high performance	NLB
Virtual network appliances	Gateway Load Balancer

Recap Checklist ✅

1. [ ] I can choose the right compute service (EC2 vs Lambda vs Fargate) based on workload pattern

2. [ ] I understand when to use On-Demand, Spot, Reserved Instances, and Savings Plans

3. [ ] I can right-size EC2 by family and size instead of overprovisioning

4. [ ] I know when horizontal scaling is more cost-effective than vertical scaling

5. [ ] I can differentiate production vs non-production availability requirements

6. [ ] I know when hibernation or scheduled scaling can reduce cost

7. [ ] I can choose the right load balancer (ALB vs NLB vs GWLB) based on protocol and need

8. [ ] I understand how tags and cost tools help track and manage compute spending

AWS Whitepapers and Official Documentation

Compute always has so many resources.

Cost Visibility And Management

1. Cost Explorer
2. AWS Budgets
3. Cost and Usage Report (CUR)
4. Cost Allocation Tags

Compute Pricing Options

1. Spot Instances

2. Reserved Instances

3. Savings Plans

Compute Services

1. EC2

2. Lambda

3. Fargate

4. ECS

5. EKS

🚀

Design Cost-Optimized Storage Solutions

Ntombizakhona Mabaso — Sat, 04 Apr 2026 18:25:22 +0000

Exam Guide: Solutions Architect - Associate
⚡ Domain 4: Design Cost-Optimized Architectures
📘 Task Statement 4.1

🎯 Designing Cost-Optimized Storage Solutions is about storing data in the lowest-cost way that still meets business requirements.

Start with storage type (object, file, block), then check access frequency, performance needs, retention, backup/archive, and transfer method.

You are not just picking “cheap storage.”

You are picking the cheapest storage that still works.

Knowledge

1 | Access Options

Requester Pays

Sometimes storage costs are affected by who pays for access.

S3 Requester Pays

With Requester Pays, the requester pays for request and data transfer charges instead of the bucket owner.

Requester Pays is Useful When:

You share large datasets publicly or with many external consumers
You want to reduce the owner’s cost for downloads or access

“Dataset is shared with external users, and owner wants to reduce access cost” → Requester Pays.

2 | AWS Cost Management Service Features

Cost Allocation Tags & Multi-Account Billing

Tags and Multi-Account Billing reduce cost directly, but they help track and control cost.

Cost Allocation Tags: track cost by team/app/environment
AWS Organizations Consolidated Billing: central billing across accounts

3 | AWS Cost Management Tools

Cost Explorer, Budgets, Cost and Usage Report

1 AWS Cost Explorer: Visualize and analyze spending trends
2 AWS Budgets: Set thresholds and alerts for cost or usage

“Need alerts when costs exceed target” → Budgets 3 AWS Cost and Usage Report (CUR): Detailed billing data for deep analysis
“Need detailed billing data for analysis” → CUR

4 | AWS Storage Services With Appropriate Use Cases

FSx, EFS, S3, EBS

4.1 Amazon S3

Best for:

Cheapest scalable object storage for large amounts of data
Logs, backups, archives, static files, data lakes

4.2 Amazon EFS

Best for:

Shared file storage for Linux workloads
More expensive than S3; use when POSIX/shared file access is actually needed

4.3 Amazon EBS

Best for:

Block storage attached to EC2
Use only when the workload really needs block storage

4.4 Amazon FSx

Best for:

Managed file systems with specific compatibility/performance needs
Examples: 1 FSx for Windows File Server 2 FSx for Lustre 3 FSx for NetApp ONTAP 4 FSx for OpenZFS

Cost Mindset:

Don’t choose EFS or FSx if S3 is enough.

Don’t choose EBS if shared file or object storage fits better.

5 | Backup Strategies

Cost-optimized backups mean:
1 Keep backups only as long as needed
2 Move old backups to cheaper tiers
3 Use centralized backup policies where helpful

Common options:

AWS Backup
EBS snapshots
S3 versioning + lifecycle
Archive backups to Glacier tiers

6 | Block Storage Options

HDD vs SSD Volume Types

For EBS, cost depends heavily on volume type.

4.1 SSD-backed

gp3 / gp2: general purpose SSD
io1 / io2: provisioned IOPS SSD for very high IOPS

“Sequential throughput, large datasets, low cost” → st1

4.2 HDD-backed

st1: throughput-optimized HDD (good for large, sequential workloads)
sc1: cold HDD (lowest cost EBS, infrequent access)

“Very infrequent block access, cheapest EBS” → sc1

7 | Data Lifecycles

Lifecycle planning is one of the biggest cost optimization topics.

This is where S3 Lifecycle shines.

Examples:

New files are frequently accessed for 30 days
Older files are rarely accessed
After 1 year, they should be archived or deleted

8 | Hybrid Storage Options

DataSync, Transfer Family, Storage Gateway

8.1 DataSync

Good for:

Recurring large-scale data transfer from on-prem to AWS
Faster and easier than building custom copy jobs

8.2 Transfer Family

Good for:

Managed SFTP/FTPS/FTP into S3 or EFS

8.3 Storage Gateway

Good for:

Hybrid access where on-prem apps still need file or block or tape interfaces backed by AWS

9 | Storage Access Patterns

Choose storage or tier based on how often data is accessed.

Access Pattern	Typical Storage
Frequently accessed	S3 Standard / EBS SSD / EFS Standard
Infrequently accessed	S3 Standard-IA / One Zone-IA / EFS IA
Archive / long-term retention	S3 Glacier Instant Retrieval / Flexible Retrieval / Deep Archive

10 | Storage Tiering

This is mostly an S3 topic, but also appears in EFS.

10.1 S3 Storage classes

S3 Standard: hot data
S3 Standard-IA: infrequent access, multi-AZ
S3 One Zone-IA: infrequent access, single AZ, cheaper
S3 Intelligent-Tiering: unknown or changing access patterns
S3 Glacier Instant Retrieval: archive but still quick retrieval
S3 Glacier Flexible Retrieval
S3 Glacier Deep Archive: lowest cost, slowest retrieval

10.2 EFS Tiering

EFS lifecycle management can move files to EFS Infrequent Access automatically.

11 | Storage Types With Associated Characteristics

Object, File, Block

11.1 Object = S3

Cheapest at scale
Best for unstructured data, backups, logs, media, static files

11.2 File = EFS / FSx

Use when apps need mounted shared file systems

11.3 Block = EBS

Use when apps need low-latency disk attached to EC2

Skills

A | Design Appropriate Storage Strategies

Batch Uploads vs Individual Uploads

Sometimes the cheapest design is not just the storage type, but how data is uploaded.

Examples:
1 Batch uploads can reduce request overhead
2 Multipart upload is better for very large files
3 Aggregating small files can improve efficiency in analytics or data lake designs

B | Determine The Correct Storage Size For A Workload

Don’t massively overprovision:
1 Right-size EBS volumes
2 Estimate backup retention growth
3 Plan capacity based on actual growth trends, not vague “just in case”

C | Determine The Lowest-Cost Method Of Transferring Data To AWS Storage

Online recurring transfers → DataSync
Managed file transfer protocol → Transfer Family
Hybrid file/block/tape integration → Storage Gateway
Very large offline migration → Snow Family

D | Determine When Storage Auto Scaling Is Required

Auto scaling or storage elasticity matters when growth is uncertain.

Examples:

S3 scales automatically
EFS scales automatically
EBS requires sizing decisions (though it can be modified)
Some file systems or databases need explicit storage autoscaling settings

E | Manage S3 Object Lifecycles

1 Move old data to cheaper storage classes
2 Expire temporary or obsolete data
3 Transition logs or backups to archive classes automatically

F | Select Appropriate Backup And/Or Archival Solution

Examples:

Operational restore → snapshots / AWS Backup
Compliance archive → Glacier tiers / Object Lock if required
Long-term, low-cost retention → Deep Archive

G | Select The Appropriate Service For Data Migration To Storage Services

1 DataSync for recurring transfer
2 Transfer Family for SFTP needs
3 Storage Gateway for hybrid storage interfaces
4 Snowball for large offline migration

H | Select The Appropriate Storage Tier

Unknown access pattern → S3 Intelligent-Tiering
Rare access but quick retrieval → S3 Standard-IA or Glacier Instant Retrieval
Very rare long-term archive → Glacier Deep Archive

I | Select The Correct Data Lifecycle

Hot for 30 days → Standard
Warm for 60 days → Standard-IA
Archive after 90 days → Glacier
Delete after 7 years → lifecycle expiration

J | Select The Most Cost-Effective Storage Service For A Workload

Use S3 if object storage works
Use EFS/FSx only if file semantics are needed
Use EBS only when block storage is required
Archive to Glacier tiers when retrieval is rare

Cheat Sheet

Requirement	Choice
Massive unstructured data, lowest scalable cost	S3
Unknown or changing access patterns	S3 Intelligent-Tiering
Rare access, still needs fast retrieval	S3 Standard-IA or Glacier Instant Retrieval
Long-term archive, lowest cost	Glacier Deep Archive
Shared Linux file system	EFS
Windows file shares	FSx for Windows File Server
Low-cost block storage for infrequent access	EBS sc1
Sequential throughput-heavy block workload	EBS st1
Recurring on-prem → AWS data transfer	DataSync
Managed SFTP into AWS storage	Transfer Family
Hybrid storage interface for on-prem apps	Storage Gateway
External users should pay for S3 downloads	S3 Requester Pays

Recap Checklist ✅

1. [ ] I can choose object vs file vs block storage based on workload needs

2. [ ] I can match storage tiers to access frequency (hot, warm, cold, archive)

3. [ ] I can use S3 lifecycle policies to reduce cost automatically over time

4. [ ] I know when to use S3 Intelligent-Tiering for unknown access patterns

5. [ ] I can choose the right EBS volume type for cost or performance needs

6. [ ] I know which hybrid transfer/storage service fits the situation (DataSync, Transfer Family, Storage Gateway)

7. [ ] I can choose cost-effective backup/archive solutions (AWS Backup, snapshots, Glacier tiers)

8. [ ] I understand cost tracking tools (Cost Explorer, Budgets, CUR, tags) at a basic level

AWS Whitepapers and Official Documentation

Core Storage Services

1. Amazon S3
2. Amazon EFS
3. Amazon EBS
4. Amazon FSx

S3 Lifecycle And Storage Classes

1. S3 Lifecycle

2. S3 storage classes

3. S3 Requester Pays
4. Multipart upload

Backup And Archive

1. AWS Backup
2. EBS snapshots

EBS Pricing Or Performance Direction

1. EBS volume types

Hybrid transfer and migration

1. AWS DataSync
2. AWS Transfer Family
3. AWS Storage Gateway

4. AWS Snow Family

Cost Visibility And Governance

1. Cost Explorer
2. AWS Budgets

3. Cost and Usage Report (CUR)

4. Cost allocation tags

🚀

Determine High-Performing Data Ingestion And Transformation Solutions

Ntombizakhona Mabaso — Wed, 01 Apr 2026 18:03:46 +0000

Exam Guide: Solutions Architect - Associate
⚡ Domain 3: Design High-Performing Architectures
📘 Task Statement 3.5

🎯 Determining High-Performing Data Ingestion And Transformation Solutions is about getting data into AWS, transforming it into useful formats, and enabling analytics at the required speed, scale, and security level.

First decide batch vs streaming ingestion, then pick the right transfer/ingestion service, then pick the transformation engine, then enable query + visualization.

Knowledge

1 | Data Analytics And Visualization Services

Athena, Lake Formation, QuickSight

1.1 Amazon Athena

Serverless SQL queries directly on S3 data (commonly Parquet/ORC for performance).

Great for ad-hoc querying and quick analytics
Works best with a catalog like Glue Data Catalog

1.2 AWS Lake Formation

Build and govern a data lake on S3:

Central permissions model (tables, columns)
Helps manage who can access which datasets

1.3 Amazon QuickSight

Serverless BI dashboards and visualization:

Connects to Athena, Redshift, RDS, and other sources
Used for “business dashboards” exam clues

2 | Data Ingestion Patterns

Frequency

Common patterns:

Near real-time: events every second (clickstream, IoT telemetry)
Micro-batch: every minute / every 5 minutes
Batch: hourly/daily/weekly loads
One-time migration: initial bulk transfer + then incremental updates

Ingestion frequency often decides Kinesis (streaming) vs DataSync/S3 batch.

3 | Data Transfer Services

DataSync & Storage Gateway

Used when data originates outside AWS or you need managed movement.

3.1 AWS DataSync

Managed, accelerated online transfer (on-prem ↔ AWS):

Moves large datasets efficiently
Good for recurring transfers and migrations

3.2 AWS Storage Gateway

Hybrid storage integration (on-prem access with AWS backing):

File Gateway (NFS/SMB) to S3
Volume Gateway (block storage backed by AWS)
Tape Gateway (backup/archive integration)

4 | Data Transformation Services

AWS Glue

Serverless data integration (ETL):

Crawlers discover schema
Jobs transform data (Spark-based)
Common for converting formats (CSV/JSON → Parquet)

“Convert CSV to Parquet” → Glue.

5 | Secure Access To Ingestion Access Points

Typical protection mechanisms:

IAM roles (least privilege) for producers/consumers
S3 bucket policies + Block Public Access + encryption
VPC endpoints / PrivateLink for private service access
TLS for ingestion endpoints
KMS keys for encryption at rest

“Data must not traverse the public internet” → VPC endpoints/PrivateLink + private subnets.

6 | Sizes And Speeds To Meet Business Requirements

Match service to throughput:

Bulk files (TB-scale) → DataSync / Snowball (when offline) / S3 multipart upload
Continuous events → Kinesis
Query performance on S3 → store as Parquet, partition by date/key, use Athena

7 | Streaming Data services

Amazon Kinesis

7.1 Amazon Kinesis Data Streams

For real-time streaming ingestion:

Producers write records to shards
Consumers process in parallel
Scales by shard count

“Need real-time stream with custom consumers” → Data Streams

7.2 Kinesis Data Firehose

For “streaming to storage/analytics destinations” with minimal ops:

Loads to S3, Redshift, OpenSearch, etc.
Can transform via Lambda in-flight (basic transforms) _ “Just deliver streaming data into S3/Redshift with minimal management”_ → *Firehose *

Skills

A | Build And Secure Data Lakes

Baseline data lake pattern:

S3 as storage (raw/clean/curated zones)
Glue Data Catalog for schema
Lake Formation for governance (optional but commonly tested)
Encryption with KMS + tight bucket policies

B | Design Data Streaming Architectures

Common streaming pipeline:

Producers → Kinesis Data Streams → consumers (Lambda/Kinesis Client) → S3/DB/analytics

Or simpler:

Producers → Firehose → S3 (often landing as Parquet with later processing)

C | Design Data Transfer Solutions

Recurring online transfer from on-prem → DataSync
Hybrid access to S3 from on-prem apps → Storage Gateway (File Gateway)

D | Implement Visualization Strategies

Query data with Athena
Visualize in QuickSight
Secure access with IAM and Lake Formation permissions

E | Select Compute Options For Data Processing

Amazon EMR

Used for big data processing with Spark/Hadoop:

Highly scalable distributed processing
Good when you need full control of the data processing framework

“Spark job / Hadoop” → EMR.

F | Select Appropriate Configurations For Ingestion

Streaming capacity: shard count (Kinesis Data Streams)
Batch throughput: concurrency, scheduling, compression, multipart uploads
Choose Parquet + partitioning for query performance

G | Transform Data Between Formats

CSV → Parquet

Common approach:

1 Land raw data in S3
2 Transform with Glue (ETL) into Parquet in a curated zone
3 Query via Athena, visualize via QuickSight

Cheat Sheet

Requirement	Choice
Ad-hoc SQL on files in S3	Athena
Business dashboards/BI	QuickSight
Govern a data lake with fine-grained permissions	Lake Formation
Move lots of data from on-prem to AWS online	DataSync
Hybrid file access (NFS/SMB) backed by S3	Storage Gateway (File Gateway)
Transform/ETL and convert CSV → Parquet	AWS Glue
Real-time streaming ingestion with custom consumers	Kinesis Data Streams
Stream into S3/Redshift with minimal ops	Kinesis Data Firehose
Spark/Hadoop processing at scale	Amazon EMR

Recap Checklist ✅

1. [ ] Choose batch vs streaming ingestion based on frequency and latency needs

2. [ ] Pick the right transfer service (DataSync vs Storage Gateway) for hybrid needs

3. [ ] Design a secure S3-based data lake (catalog + governance + encryption)

4. [ ] Choose the right streaming service (Kinesis Streams vs Firehose)

5. [ ] Transform data using Glue (including format conversion like CSV → Parquet)

6. [ ] Select compute for processing (EMR when Spark/Hadoop is required)

7. [ ] Enable analytics (Athena) and dashboards (QuickSight) securely

AWS Whitepapers and Official Documentation

Analytics And Visualization

1. Athena
2. Lake Formation

3. QuickSight

Data Ingestion And Transfer

1. DataSync

2. Storage Gateway

3. Transfer Family

Streaming

1. Kinesis Data Streams

2. Kinesis Data Firehose

Transformation And Catalog

1. AWS Glue
2. Glue Data Catalog

Storage

Amazon S3

Processing

Amazon EMR

🚀

Determine High-Performing And / Or Scalable Network Architectures

Ntombizakhona Mabaso — Mon, 30 Mar 2026 18:46:33 +0000

Exam Guide: Solutions Architect - Associate
⚡ Domain 3: Design High-Performing Architectures
📘 Task Statement 3.4

🎯 Determining High-Performing And / Or Scalable Network Architectures is about designing networks that:

1 Perform well: low latency, high throughput, predictable routing
2 Scale cleanly: more users, more subnets, more Regions
3 Support common patterns: multi-tier, hybrid, global
4 Use the right “front door”: CloudFront/ALB/API Gateway and the right connectivity (VPN/DX/PrivateLink)

Start with where users are (global vs regional), then pick the ingress pattern, then design the VPC topology, then pick connectivity and load balancing.

Knowledge

1 | Edge Networking Services

CloudFront & Global Accelerator

1.1 Amazon CloudFront (CDN)

Use CloudFront when you need:
1 Lower latency for global users: cache close to them
2 Reduced load on origins: cache + compression
3 Better security integrations: WAF, Shield, TLS
4 Static content acceleration: and some dynamic acceleration patterns

“Global users downloading static content” → CloudFront.

1.2 AWS Global Accelerator

Use Global Accelerator when you need:
1 Faster, more reliable global routing for TCP/UDP or non-cacheable traffic
2 Improved latency by using the AWS global network (Anycast IPs)
3 Health-based routing to regional endpoints

“Improve global performance for a latency-sensitive app that can’t be cached” → Global Accelerator.

2 | How To Design Network Architecture (

Subnet Tiers, Routing, IP Addressing

2.1 Subnet Tiers

1 Public subnet: route to an Internet Gateway (IGW). Often hosts ALB, NAT GW.
2 Private subnet: no IGW route because the app tier typically lives here.
3 Isolated subnet: no IGW route and often no NAT route because the DB tier often lives here.

2.2 Routing

Routing decides where traffic can go:
1 IGW for public inbound/outbound
2 NAT GW for private outbound
3 VPC endpoints for private access to AWS services

2.3 IP Addressing

You should plan CIDR ranges so you can grow:
1 Enough IPs per subnet for scaling targets: ECS tasks, EKS pods, EC2
2 Room for future subnets: new tiers, new AZs, new services
3 Avoid overlapping CIDRs if you’ll connect VPCs/on-prem later

3 | Load Balancing Concepts

3.1 Application Load Balancer (ALB)

1 HTTP/HTTPS workloads
2 Path/host-based routing: microservices routing
3 Integrations: WAF, authentication, target groups

“HTTP routing based on path /api vs /images” → ALB

3.2 Network Load Balancer (NLB)

1 Very high performance / low latency L4 traffic like TCP/UDP/TLS.
2 Static IP support which is often helpful for allowlists
3 Non-HTTP protocols

“TCP, extreme performance, static IP, or non-HTTP” → *NLB *

4 | Network Connection Options

VPN, Direct Connect, PrivateLink

4.1 AWS Site-to-Site VPN

Encrypted tunnel over the internet
Fast to deploy, good baseline hybrid connectivity

4.2 AWS Direct Connect

Dedicated private connection, more consistent latency/throughput
Often used for large data transfer or steady hybrid traffic

“Consistent throughput / private circuit” → Direct Connect.

4.3 AWS PrivateLink

Private connectivity to services across VPCs/accounts without exposing to the public internet
Often used for “consumer VPC connects to provider service privately”

“Expose an internal service to other VPCs privately” → PrivateLink.

Skills

A | Create A Network Topology For Various Architectures

Global, Hybrid, Multi-tier

Multi-Tier Regional Topology

CloudFront → ALB in public subnets → app in private subnets → DB in isolated subnets

Hybrid Topology

On-prem ↔ (VPN or Direct Connect) ↔ VPC private subnets
Use routing and security to restrict what on-prem can reach

Global Topology

CloudFront (cacheable) or Global Accelerator (non-cacheable/latency-sensitive)
Multi-region endpoints with health-based routing

B | Determine Network Configurations That Scale For Future Needs

1 Plan CIDR blocks with growth in mind
2 Use multiple subnets across AZs
3 Avoid hard dependencies on single IPs (use load balancers/DNS)
4 Consider VPC endpoint usage to reduce NAT bottlenecks and cost

C | Determine Appropriate Placement Of Resources

Common Placement Rules:

1 Public-facing entry points (ALB, CloudFront origin) are public
2 App tiers and databases are private/isolated
3 Use separate subnets per AZ for HA and scaling
4 Put NAT Gateways in public subnets (often one per AZ for resilience)

D | Select The Appropriate Load Balancing Strategy

Choose Based On Protocol And Routing Needs:

1 ALB for HTTP/HTTPS and advanced routing
2 NLB for TCP/UDP/TLS and extreme performance
3 Gateway Load Balancer for virtual appliances

Cheat Sheet

Requirement	Choice
Global users, cacheable content	CloudFront
Global users, non-cacheable TCP/UDP or low-latency routing	Global Accelerator
HTTP/HTTPS, path-based routing	ALB
TCP/UDP, static IPs, extreme performance	NLB
On-prem to AWS quickly (encrypted)	Site-to-Site VPN
On-prem to AWS with consistent bandwidth/latency	Direct Connect
Private service exposure across VPCs/accounts	PrivateLink
Need private access to AWS services (S3, etc.)	VPC endpoints

Recap Checklist ✅

1. [ ] I can choose CloudFront vs Global Accelerator based on caching vs routing needs

2. [ ] VPCs are designed with public/private/isolated subnet tiers where appropriate

3. [ ] Route tables, NAT, and endpoints are used intentionally (not accidentally)

4. [ ] IP addressing (CIDR) is planned for scaling and future connectivity (no overlaps)

5. [ ] Resource placement matches requirements (public entry, private app/data)

6. [ ] Load balancer choice matches protocol and routing needs (ALB vs NLB)

7. [ ] Hybrid connectivity uses the right option (VPN vs Direct Connect vs PrivateLink)

AWS Whitepapers And Official Documentation

Edge Networking

1. CloudFront

2. Global Accelerator

VPC Design Fundamentals

1. Amazon VPC

2. Route tables
3. VPC CIDR blocks

4. NAT gateway
5. VPC endpoints

6. AWS PrivateLink

Load Balancing

Hybrid Connectivity

🚀

Determine High-Performing Database Solutions

Ntombizakhona Mabaso — Sun, 08 Feb 2026 05:42:07 +0000

Exam Guide: Solutions Architect - Associate
⚡ Domain 3: Design High-Performing Architectures
📘 Task Statement 3.3

🎯 Determining High-Performing Database Solutions is about picking and designing databases that meet:

1 Performance goals
2 Scale requirements
3 Availability expectations
4 Operational constraints

Start with the data model + access pattern: relational vs key-value vs document, then choose the service, then add performance boosters: read replicas, caching, connection pooling.

Knowledge

1 | AWS Global Infrastructure

Availability Zones And Regions

Multi-AZ deployments improve availability and can improve performance under failure.
Multi-region designs support disaster recovery and global performance.

“Must survive AZ outage” → Multi-AZ
“Global users with low latency” → global DB patterns

2 | Caching Strategies And Services

Amazon ElastiCache

Caching reduces database load and improves latency.

ElastiCache for Redis: caching + sessions + pub/sub + sorted sets
ElastiCache for Memcached: simple, distributed cache, no persistence

“Reduce read load / hot keys / repeated queries” → ElastiCache.

3 | Data Access Patterns

Read-Intensive vs Write-Intensive

This is one of the most important drivers of database design:

1 Read-heavy → add caching, read replicas, or purpose-built read scaling
2 Write-heavy → consider partitioning/sharding patterns, or DynamoDB if it fits
3 Spiky traffic → serverless options or buffering with queues

4 | Database Capacity Planning

Capacity Units, Instance Types And Provisioned IOPS

1 RDS/Aurora performance depends on instance size, storage type, and sometimes Provisioned IOPS
2 DynamoDB uses RCUs/WCUs (or on-demand) and partition design affects performance
3 High-performance workloads often need correct sizing plus monitoring

5 | Database Connections And Proxies

Connection limits are a common real-world and exam bottleneck.

Amazon RDS Proxy pools connections and helps with spiky connection patterns (especially Lambda) and helps reduce failover impact and connection storms.

“Serverless app is exhausting DB connections” → RDS Proxy.

6 | Database Engines With Appropriate Use Cases

Homogeneous vs Heterogeneous Migrations

Homogeneous migration: same engine to same engine (e.g., MySQL → MySQL)
Heterogeneous migration: different engines (e.g., Oracle → PostgreSQL) _ AWS DMS is commonly used for migrations (especially minimal downtime)._

7 | Database Replication

Read Replicas

Read replicas are mainly for:
1 Scaling reads
2 Offloading reporting/analytics queries
3 Cross-region read performance (depending on engine)

Reminder:

Read replicas are usually asynchronous
Multi-AZ is for availability, not for read scaling

8 | Database Types And Services

Relational (SQL)

Amazon RDS: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server
Amazon Aurora MySQL/PostgreSQL-compatible, high performance, managed

Non-relational (NoSQL)

Amazon DynamoDB: key-value/document, massive scale, low latency

In-memory

ElastiCache: Redis/Memcached (cache, sessions)

Serverless Database Patterns

Aurora Serverless v2: elastic relational capacity

Skills

A | Configure Read Replicas To Meet Business Requirements

You Should Know When And Why

1 Add replicas to scale reads and isolate reporting workloads
2 Place replicas in other AZs or Regions if needed (engine-dependent)
3 Monitor replication lag and route read traffic appropriately

B | Design Database Architectures

Typical high-performing patterns:
1 App → (optional cache) → DB
2 Multi-AZ for HA
3 Read replicas for scaling reads
4 Shard/partition when required (more advanced, usually not primary SAA topic)
5 Offload analytics to separate systems when needed

C | Determine An Appropriate Database Engine

MySQL vs PostgreSQL, etc.

Expectation: pick based on compatibility/features/organization standards rather than arguing favorites.

1 Choose MySQL/Aurora MySQL when compatibility with MySQL ecosystem is needed.
2 Choose PostgreSQL/Aurora PostgreSQL when advanced SQL features/extensions are needed.
3 Choose commercial engines (Oracle/SQL Server) when required by licensing/app constraints.

D | Determine An Appropriate Database Type

Aurora vs DynamoDB

Fast rules:
1 Need joins/transactions/relational schema → RDS/Aurora
2 Need massive scale + low latency key-value/document → DynamoDB
3 Need sub-millisecond repeated reads → add ElastiCache

DynamoDB vs RDS is a frequent exam decision point.

E |Integrate Caching To Meet Business Requirements

Caching Options

ElastiCache for app-side caching of hot data
DAX (DynamoDB Accelerator) for DynamoDB read caching (in-memory, managed)

“Microsecond reads for DynamoDB queries” → DAX (if DynamoDB is the DB).

Cheat Sheet

Requirement	Database
Relational, transactions, joins	RDS or Aurora
High performance managed relational	Aurora
Key-value/document, massive scale	DynamoDB
Read-heavy workload	Read replicas + caching
Repeated hot reads / lower latency	ElastiCache (or DAX for DynamoDB)
Lambda too many DB connections	RDS Proxy
Global low-latency reads + DR	Aurora Global Database / DynamoDB Global Tables (if mentioned)
Migrate DB with minimal downtime	AWS DMS

Recap Checklist ✅

1. [ ] Database choice matches data model (relational vs non-relational)

2. [ ] Read-heavy workloads use read scaling (read replicas) and/or caching

3. [ ] Write scaling is considered (correct service + partition design if DynamoDB)

4. [ ] Connection spikes are handled (RDS Proxy when appropriate)

5. [ ] Capacity planning is understood at a high level (instance types, IOPS, RCUs/WCUs)

6. [ ] Multi-AZ is used for availability; read replicas are used for read scaling

7. [ ] Caching is integrated appropriately (ElastiCache/DAX)

AWS Whitepapers and Official Documentation

These are the primary AWS documents behind Task Statement 3.3

You do not need to memorize them, use them to understand how to Design High-Performing Database Solutions

Core Database Services

1. Amazon RDS

2. Amazon Aurora

3. Aurora Serverless v2

4. Amazon DynamoDB

Read Scaling, HA, and Connections

1. RDS Read Replicas

2. RDS Multi-AZ (concepts)

3. Amazon RDS Proxy

Caching

1. ElastiCache (Redis/Memcached)

2. DynamoDB Accelerator (DAX)

Migration

AWS Database Migration Service (DMS)

Capacity Planning

1. DynamoDB Capacity Modes

2. RDS storage options

🚀

Design High-Performing And Elastic Compute Solutions

Ntombizakhona Mabaso — Sat, 07 Feb 2026 11:19:11 +0000

Exam Guide: Solutions Architect - Associate
⚡ Domain 3: Design High-Performing Architectures
📘 Task Statement 3.2

🎯 Designing High-Performing And Elastic Compute Solutions is about choosing compute that:

Performs well
Scales automatically
Avoids bottlenecks by decoupling components

Pick the compute runtime first: EC2 vs containers vs serverless, then pick the scaling model: Auto Scaling vs event-based scaling, then tune performance: instance family / memory / concurrency / batching.

Knowledge

1 | AWS Compute Services With Appropriate Use Cases

Amazon EC2

Best for:

Full control over OS/runtime
Legacy apps, custom networking/agents, special drivers
Predictable long-running services

AWS Lambda

Best for:

Event-driven tasks: APIs, SQS processing, EventBridge, file processing
Spiky or unpredictable traffic
Minimal ops

Amazon ECS / Amazon EKS (containers)

Best for:

Microservices and long-running container workloads
Standardized packaging and predictable scaling
When Lambda constraints don’t fit (timeouts, runtime, dependencies)

AWS Fargate (serverless containers)

Best for:

Containers without managing EC2 instances
Common “high-performing + elastic” answer for containerized apps

AWS Batch

Best for:

Batch jobs, large-scale job queues, compute-intensive processing
Automatically provisions compute (often EC2/Spot) to run jobs

Amazon EMR

Best for:

Big data processing frameworks (Spark, Hadoop)
Distributed ETL / analytics workloads

Spark/Hadoop _→ EMR.
_“run 10,000 batch jobs” → Batch.

2 | Distributed Computing Concepts Supported By Global Infrastructure And Edge Services

Compute performance can depend on where compute runs:

Multi-AZ architectures reduce impact of AZ failure and allow scale-out
Edge services reduce latency for users

Common Edge And Global Services

CloudFront: caching and edge delivery
Global Accelerator: Anycast routing for TCP/UDP apps

3 | Queuing And Messaging Concepts (Pub/Sub)

Queues and events are a core scaling tool because they buffer spikes.

1 SQS: decouple producer/consumer; scale workers on queue depth
2 SNS: pub/sub fan-out
3 EventBridge: event routing

4 | Scalability Capabilities

EC2 Auto Scaling And AWS Auto Scaling

EC2 Auto Scaling scales EC2 instances in an Auto Scaling Group (ASG)
AWS Auto Scaling provides scaling for multiple services (ECS, DynamoDB, Aurora replicas, etc.)

5 | Serverless Technologies And Patterns

Lambda And Fargate

Lambda scales by concurrency and can be event-driven and bursty
Fargate scales containers without managing servers and scales via ECS/EKS configuration

6 | The Orchestration Of Containers

Amazon ECS And Amazon EKS

Container Orchestration is how you deploy, run, scale, and heal containers.

ECS (AWS-native) concepts:

Cluster → Service → Tasks
Task definition is the blueprint

EKS (Kubernetes) concepts: Cluster → Deployments → Pods

If Kubernetes is not required, ECS is usually simpler.

Skills

A | Decouple Workloads So Components Can Scale Independently

Decoupling Patterns

1 SQS between web tier and workers: buffer spikes, retry, DLQ)
2 SNS fan-out to multiple consumers
3 EventBridge for event-driven integration
4 Step Functions for orchestration when coordination is needed

Frontend scales with traffic, workers scale with queue depth.

B | Identify Metrics And Conditions To Perform Scaling Actions

Common Scaling Signals

1 CPU / memory (EC2/ECS)
2 Request count / target response time (ALB target metrics)
3 Queue depth / age of oldest message (SQS-based worker scaling)
4 Lambda concurrency / duration / throttles
5 Custom CloudWatch metrics (business-driven scaling, e.g., “jobs waiting”)

C | Select Appropriate Compute Options And Features To Meet Business Requirements

EC2 Instance Types

Need	Common EC2 Family
General purpose	t, m
Compute-heavy	c
Memory-heavy	r, x
Storage / IOPS-heavy	i
GPU/ML/graphics	p, g

Other EC2 Options

Spot Instances for fault-tolerant workloads (batch, stateless, flexible)
Graviton (Arm) for price/performance

D | Select The Appropriate Resource Type And Size To Meet Business Requirements

Lambda Memory

1 Memory also affects CPU allocation.
2 Increase memory when execution time is too slow (often improves performance).
3 Watch for throttles and concurrency limits.

Container Memory

1 Right-size task/pod CPU and memory
2 Scale task count rather than over-sizing single tasks (where possible)

Cheat Sheet

Requirement	Compute
Event-driven, spiky traffic, minimal ops	Lambda
Run containers without managing servers	ECS on Fargate
Must use Kubernetes	EKS
Need OS control / legacy app	EC2 (+ Auto Scaling)
Run many batch jobs / job queue	AWS Batch
Spark/Hadoop big data processing	EMR
Scale workers based on backlog	SQS + autoscaled consumers
Need global performance improvement	CloudFront / Global Accelerator

Recap Checklist ✅

1. [ ] Workload is decoupled so components can scale independently (queues/events)

2. [ ] Compute choice matches runtime needs (EC2 vs containers vs serverless)
3. [ ] Scaling strategy is explicit (Auto Scaling, queue-based, event-based)
4. [ ] Scaling metrics are chosen appropriately (CPU, requests, queue depth, concurrency)
5. [ ] EC2 instances are selected by workload profile (compute/memory/storage/GPU)
6. [ ] Lambda/container resources are right-sized (memory/CPU) and adjusted based on performance

AWS Whitepapers and Official Documentation

These are the primary AWS documents behind Task Statement 3.2

You do not need to memorize them, use them to understand how to Design High-Performing And Elastic Compute Solutions

Compute services

1. EC2
2. Lambda

3. ECS

4. EKS
5. Fargate

6. AWS Batch

7. EMR

Scaling

1. EC2 Auto Scaling

2. AWS Auto Scaling

3. CloudWatch

Decoupling And Messaging

1. SQS

2. SNS

3. EventBridge

Edge And Global Performance

1. CloudFront

2. Global Accelerator

🚀

Determine High Performing And / Or Scalable Storage Solutions

Ntombizakhona Mabaso — Fri, 06 Feb 2026 10:21:05 +0000

Exam Guide: Solutions Architect - Associate
⚡ Domain 3: Design High-Performing Architectures
📘 Task Statement 3.1

🎯 Determining High Performing And / Or Scalable Storage Solutions is about picking the right storage for the workload so it is:

1 Fast enough
2 Scalable
3 Cost-appropriate
4 Operationally simple

Choose storage by access pattern first (object/file/block), then by performance, then by scale/cost, then by hybrid needs.

Knowledge

1 | Storage Types And Their Characteristics

Object Storage (Amazon S3)

Best for:

Static assets, backups, logs, data lakes, media, artifacts
Massive scale and very high durability

Characteristics:
1 Access via HTTP API (not POSIX)
2 Not a traditional mounted filesystem
3 Performance scales with request patterns, designed for throughput

File Storage (Amazon EFS)

Best for:

Shared filesystem for multiple EC2 instances/containers
Linux POSIX-style applications that need a mounted NFS filesystem

Characteristics:
1 Regional, multi-AZ (designed for high availability within a Region)
2 Scales automatically (elastic capacity)
3 Performance modes and throughput modes affect performance/cost

Block Storage (Amazon EBS)

Best for:

Low-latency storage attached to EC2
Databases or transactional workloads on EC2 (high IOPS needs)
Boot volumes

Characteristics:
1 A volume is attached to one instance at a time (generally)
2 Choose volume type for performance (gp3/io1/io2, etc.)
3 Snapshots stored in S3 for durability/backup

2 | Storage Services With Appropriate Use Cases

1 If it’s object storage → S3
2 If it’s a shared Linux filesystem → EFS
3 If it’s single-instance low-latency disk → EBS

3 | Hybrid Storage Solutions To Meet Business Requirements

Hybrid storage matters when:
1 You have on-prem apps that need cloud storage
2 You want backup/archive to AWS
3 You need low-latency local access but cloud durability/scale

Common AWS hybrid options:

AWS Storage Gateway: file, volume, tape gateways
AWS DataSyncL accelerated data transfer + scheduling
AWS Transfer Family: managed SFTP/FTPS into S3/EFS
AWS Snowball/Snowcone: large offline migrations

Skills

A | Determine Storage Services And Configurations That Meet Performance Demands

Performance drivers you should recognize

1 Latency: how fast a single read/write completes

2 IOPS: how many small operations per second (common for DB workloads)

3 Throughput: MB/s or GB/s (common for streaming, big files, analytics)

4 Concurrency: many clients at once (file shares, web apps, microservices)

Common Patterns

“Database on EC2 needs high IOPS” → EBS io2/io1 (or gp3 with provisioned IOPS if suitable)
“Many instances need shared access to same files” → EFS
“Static assets globally distributed” → S3 + CloudFront
“Very large objects / backup storage” → S3 (possibly lifecycle to Glacier)

B | Determine Storage Services That Can Scale To Accommodate Future Needs

1 S3: essentially unlimited scale for objects
2 EFS: elastically scales capacity automatically
3 EBS: can modify volumes (size/type) but still tied to EC2 and AZ

“Expect rapid data growth” → S3/EFS are typical answers because scaling is built in.

Cheat Sheet

Requirement	Storage
Store and retrieve any amount of unstructured data	S3
Shared filesystem for many Linux servers	EFS
Lowest-latency disk for EC2 instance	EBS
High IOPS for database on EC2	EBS io2/io1 (or tuned gp3)
Static content served globally	S3 + CloudFront
On-prem apps need cloud-backed storage	Storage Gateway
Fast recurring data transfer to AWS	DataSync
SFTP uploads into AWS storage	Transfer Family → S3/EFS

Recap Checklist ✅

[ ] I can choose object vs file vs block storage based on access pattern
[ ] I know when to use S3, EFS, and EBS (and why)
[ ] I can match performance needs to storage configuration (IOPS vs throughput vs latency)
[ ] I can identify when hybrid storage is required (Storage Gateway / DataSync / Transfer Family)
[ ] I choose services that scale with growth (S3/EFS) without major redesign

AWS Whitepapers and Official Documentation

These are the primary AWS documents behind Task Statement 3.1

You do not need to memorize them, use them to understand how to determine high performing and scalable storage solutions.

Core storage services

1. Amazon S3
2. Amazon EFS

3. Amazon EBS
4. EBS volume types

Hybrid storage and transfer

Performance At The Edge (common pairing with S3)

Amazon CloudFront

🚀

Design Highly Available And / Or Fault-Tolerant Architectures

Ntombizakhona Mabaso — Thu, 05 Feb 2026 08:04:54 +0000

Exam Guide: Solutions Architect - Associate
🧱 Domain 2: Design Resilient Architectures
📘 Task Statement 2.2

🎯 Designing Highly Available And Fault Tolerant Architectures is about keeping workloads running despite failures.

High Availability (HA): the system stays up through component failures
Fault Tolerance (FT): the system continues operating with no interruption

Highly Available usually means Multi-AZ + load balancing + managed services + no single points of failure.

Knowledge

1 | AWS Global Infrastructure

AZs, Regions, Route 53

1 Availability Zones (AZs): isolated failure domains within a Region

2 Regions: separate geographic areas for disaster recovery

3 Amazon Route 53: DNS-based routing and health checks (common for regional failover)

“Must survive an AZ failure” → Multi-AZ design.

“Must survive a regional outage” → Multi-region DR + Route 53 failover.

2 | AWS Managed Services With Appropriate Use Cases

This bullet exists because managed services often include built-in HA scaling and reduce your operational risk.

Even if services like Comprehend or Polly aren’t HA topics by themselves, the exam tests the principle:

Prefer managed services when you want higher reliability with less custom work.

3 | Basic Networking Concepts

Route Tables

HA and FT depend on correct routing:
1 Public subnets route to an Internet Gateway (IGW)
2 Private subnets may route outbound via NAT Gateway
3 Multi-AZ designs require correct subnet/routing per AZ

4 | Disaster Recovery Strategies

RPO/RTO, backup-restore, pilot light, warm standby, active-active

Know these by cost vs recovery speed:

DR strategy	What it is	Typical RTO/RPO	Cost
Backup & Restore	restore from backups into a new environment	Slow RTO, higher RPO	Lowest
Pilot Light	minimal core services running (e.g., DB + minimal infra)	Medium RTO, medium RPO	Low–Medium
Warm Standby	scaled-down but fully functional stack always running	Faster RTO, low RPO	Medium–High
Active-Active	both Regions serve traffic	Lowest RTO/RPO	Highest

If RTO/RPO are strict, the answer moves toward warm standby / active-active.

5 | Distributed Design Patterns

Common Resilience Patterns

1 Retry with backoff: avoid thundering herd
2 Timeouts: prevent resource exhaustion
3 Circuit breaker / bulkhead: limit cascade failures
4 Queue-based load leveling: SQS
5 Idempotency" safe retries
6 Multi-AZ deployment: for every critical tier

6 | Failover Strategies

Ways Failover Happens On AWS

1 Load balancer failover across targets in multiple AZs within a Region
2 Database failover: RDS Multi-AZ
3 DNS failover: Route 53 health checks across Regions
4 Client-side failover: apps try secondary endpoints

“Fail over between Regions” → Route 53 failover routing (or latency-based + health checks).

7 | Immutable Infrastructure

Immutable means you don’t patch servers in place, you replace them:
1 Build a new AMI/container image
2 Deploy new instances/tasks
3 Terminate old ones

Benefits:

Consistency
Faster recovery
Lower configuration drift

“Ensure infrastructure integrity and repeatability” → IaC + immutable deployments.

8 | Load Balancing Concepts

Application Load Balancer

ALB spreads traffic across targets in multiple AZs
Helps remove single-instance failure as a SPOF

9 | Proxy Concepts

Amazon RDS Proxy

RDS Proxy helps reliability especially for spiky/serverless workloads by:
1 Pooling and reusing DB connections
2 Reducing DB overload due to connection storms
3 Improving failover behavior for some patterns

“Lambda causes too many DB connections” → RDS Proxy.

10 | Service Quotas And Throttling

Standby Environments

In DR scenarios, your standby Region or account must have enough quota to scale up.

Know that you can:

Check and adjust Service Quotas
Design for throttling with retries or backoff and buffering

11 | Storage Options And Characteristics

Durability And Replication

Storage durability affects architecture choices:
1 S3 is highly durable and regional with options like versioning and replication
2 EBS is replicated within an AZ and you can send snapshots to S3 for durability
3 EFS is regional and multi-AZ within a Region

12 | Workload Visibility

AWS X-Ray

Visibility supports HA by helping you detect and diagnose failures:

CloudWatch metrics/alarms for health and scaling
X-Ray for tracing distributed requests and finding bottlenecks

Skills

A | Determine Automation Strategies To Ensure Infrastructure Integrity

Look for:
1 Infrastructure as Code (CloudFormation/CDK/Terraform)
2 Automated deployments (blue/green, rolling)
3 Auto Scaling + health checks
4 Automated recovery actions (replace unhealthy instances/tasks)

B | Determine Services Required For HA/FT Across Regions or AZs

Common choices:

Multi-AZ: ALB + Auto Scaling + Multi-AZ database (RDS Multi-AZ)
Multi-region: Route 53 + replicated data + standby/active environment

“AZ outage must not cause downtime” → Multi-AZ everything.

C | Identify Metrics Based On Business Requirements

Tie Monitoring To User-Impacting KPIs:

1 Availability / error rate (5xx)
2 Latency p95/p99
3 Queue depth / age (SQS)
4 CPU/memory/connections (compute/DB)
5 RPO/RTO compliance signals (backup success, replication lag)

D | Implement Designs To Mitigate Single Points Of Failure

Remove Single Points of Failure

1 Multi-AZ deployments
2 Redundant NAT Gateways (one per AZ for best practice)
3 Multi-AZ databases
4 Avoid single instance “pet” servers

E | Ensure Durability And Availability Of Data

Backups

1 Automated backups (RDS)
2 Snapshots (EBS, RDS)
3 S3 versioning + replication where required
4 AWS Backup policies when asked for centralized backup

F | Select An Appropriate DR Strategy To Meet Business Requirements

Use RTO/RPO to pick:
1 Backup/Restore (cheap, slow)
2 Pilot Light (medium)
3 Warm Standby (faster)
4 Active-Active (fastest, expensive)

G | Improve Reliability Of Legacy Apps

When app changes are not possible, use infrastructure patterns:

1 Put app behind ALB
2 Use Auto Scaling groups to replace failed instances
3 Use RDS Proxy to stabilize DB connections
4 Use caching to reduce backend load
5 Use DNS failover (Route 53) for regional DR

H | Use Purpose-Built AWS Services

Use managed services to reduce failure modes:

ALB, Auto Scaling, Route 53
RDS Multi-AZ, DynamoDB (managed HA)
SQS/SNS for decoupling spikes and failures
CloudFront for edge caching and origin protection

Cheat Sheet

Requirement	Direction
Survive an instance failure	Auto Scaling + health checks + ALB
Survive an AZ failure	Multi-AZ for each tier (ALB targets across AZs, Multi-AZ DB)
Survive a Region failure	DR strategy + Route 53 failover + replicated data
Strict RTO/RPO	Warm standby or active-active
Lambda overwhelms RDS with connections	RDS Proxy
Need to see bottlenecks across microservices	X-Ray (plus CloudWatch)
Standby must scale during failover	Plan Service Quotas + scaling policies

Recap Checklist ✅

1. [ ] Every critical tier is deployed across multiple AZs

2. [ ] Traffic is distributed via ALB/NLB and unhealthy targets are replaced automatically

3. [ ] Databases use HA features (e.g., RDS Multi-AZ or managed HA services)

4. [ ] DR strategy matches business RTO/RPO (backup/restore vs pilot light vs warm standby vs active-active)

5. [ ] Regional failover uses Route 53 health checks/routing (when required)

6. [ ] Data durability is addressed (backups, snapshots, replication)

7. [ ] Quotas and throttling are considered for failover/standby scaling

8. [ ] Monitoring and tracing exist (CloudWatch + X-Ray)

AWS Whitepapers and Official Documentation

These are the primary AWS documents behind Task Statement 2.2.

You do not need to memorize them, use them to understand why highly available and fault tolerant architectures work the way they do.

Global Infrastructure and DNS

Route 53

Disaster Recovery

Disaster Recovery on AWS

Networking Foundations

VPC Route Tables

Load Balancing and Reliability

1. Application Load Balancer
2. Auto Scaling (EC2)

Database Reliability

1. RDS Multi-AZ

2. RDS Proxy

Quotas and Limits

Service Quotas

Storage Durability / Replication

1. S3 Replication
2. EBS Snapshots:

3. EFS Overview

Visibility

1. AWS X-Ray
2. CloudWatch

Managed AI Services (examples from blueprint)

1. Amazon Comprehend
2. Amazon Polly

🚀

Design Scalable And Loosely Coupled Architectures

Ntombizakhona Mabaso — Wed, 04 Feb 2026 08:24:32 +0000

Exam Guide: Solutions Architect - Associate
🧱 Domain 2: Design Resilient Architectures
📘 Task Statement 2.1

🎯 Designing Scalable And Loosely Coupled Architectures is about building systems that can:

1 Scale up and down with demand
2 Keep working when a component fails
3 Avoid tight dependencies so changes and failures don’t cascade

Loose coupling reduces blast radius.

Scaling reduces bottlenecks.

Managed services reduce operational burden.

Knowledge

1 | API Creation And Management

API Gateway And REST API

Amazon API Gateway is commonly used to:
1 Create REST/HTTP APIs for backend services
2 Front Lambda or private services
3 Handle auth, throttling, caching, request validation, and stages

“Need a managed API front door with throttling/auth” → API Gateway.

2 | Managed Services With Appropriate Use Cases

SQS, Transfer Family, Secrets Manager

The exam likes “use a managed service instead of building it.”

1 Amazon SQS: decouple services, buffer traffic spikes, async processing

2 AWS Transfer Family: managed SFTP/FTPS/FTP into S3/EFS (file ingestion)

3 AWS Secrets Manager: store + rotate secrets

3 | Caching Strategies

Caching improves performance and reduces load on databases/backends.

1 CloudFront: cache content at the edge (static + dynamic with rules)
2 ElastiCache (Redis/Memcached): app/data caching, sessions, leaderboards
3 API Gateway caching: cache API responses

“Reduce DB reads / improve latency for repeated requests” → caching

4 | Microservices Design Principles

Stateless vs Stateful

Stateless compute scales horizontally (add more instances/tasks)
State lives in managed services (databases, caches, object storage) Examples:
ECS tasks and Lambda functions should not depend on local disk for important state
Store files in S3, shared files in EFS, sessions in Redis if needed

5 | Event-Driven Architectures

Event-driven design improves decoupling and resilience.

1 EventBridge for event bus/routing
2 SNS for pub/sub fan-out
3 SQS for queues and buffering
4 Lambda for consumers

“Multiple consumers need the same event” → SNS fan-out

6 | Horizontal Scaling vs Vertical Scaling

Horizontal scaling: add more instances/tasks (preferred for resilience)
Vertical scaling: make one server bigger (simple, but has limits)

“Need high availability and elasticity”→ horizontal scaling + load balancing + managed services.

7 | Edge Accelerators

CDN use

CloudFront reduces latency and protects origins (caching, TLS termination, WAF integration)
Global Accelerator improves performance for TCP/UDP apps via Anycast routing

8 | How To Migrate Apps Into Containers

When Containers Are A Fit:

You need portability, consistent runtime, or microservices packaging
You want controlled scaling without managing servers (Fargate)

Main options:

Amazon ECS: simpler AWS-native container orchestration
Amazon EKS: Kubernetes-managed control plane

9 | Load Balancing Concepts

Application Load Balancer

ALB (Application Load Balancer): HTTP/HTTPS, path-based routing, host-based routing
Scales horizontally and improves availability by spreading traffic

10 | Multi-tier Architectures

Classic Tiers:

1 Presentation:

CloudFront
ALB

2 Application:

EC2
ECS
EKS
Lambda

3 Data:

RDS
DynamoDB
ElastiCache
S3

“Separate web/app/db tiers” → multi-tier in private subnets with scaling where needed.

11 | Queuing and Messaging Concepts

Key Distinctions:

SQS: queue (point-to-point), buffering, retries, DLQs
SNS: publish/subscribe (fan-out), multiple subscribers
SNS → SQS for fan-out + durability per consumer

12 | Serverless Technologies And Patterns

Lambda And Fargate

Serverless means “no servers to manage,” and scaling is built in.

AWS Lambda: event-driven compute, short-running, scales automatically
AWS Fargate: serverless containers as in, you run tasks and services without managing EC2

13 | Storage Types And Characteristics

Object (S3): durable, cheap, great for static assets, logs, backups
File (EFS): shared POSIX file system for multiple instances
Block (EBS): low-latency block storage attached to one EC2 instance (per volume)

14 | The Orchestration of Containers

Container orchestration is how you deploy, run, scale, and heal containers across compute capacity without manually managing container placement.

What Orchestration Solves

Scheduling containers onto capacity
Horizontal scaling (more tasks/pods)
Self-healing (replace failed containers)
Rolling deployments
Load balancing integration

Amazon ECS (Elastic Container Service)

AWS-native orchestrator. You run:

Task definitions: blueprints
Tasks: running copies
Services: keep desired task count running, integrate with ALB

Capacity Choices:

ECS on Fargate: serverless containers therefore minimal ops
ECS on EC2: you manage instances therefore more control

If the problem doesn’t require Kubernetes, ECS (often on Fargate) is usually the simplest correct answer.

Amazon EKS (Elastic Kubernetes Service)

Managed Kubernetes. You run:

Pods: smallest deployable unit
Deployments: replicas + rolling updates
Services/Ingress: expose workloads

Worker Capacity:

Managed node groups (EC2) or EKS on Fargate for pods (where suitable)

If the question explicitly says Kubernetes, standardization across clouds, or Kubernetes tooling → EKS.

15 | When To Use Read Replicas

You have read-heavy workloads
You want to offload reads from the primary database instance
You can tolerate eventual consistency on replica reads

16 | Workflow Orchestration

Step Functions

Step Functions is used to:

Orchestrate multi-step workflows (retries, timeouts, branching)
Coordinate microservices without building a custom state machine

Skills

A | Design Event-Driven, Microservice, And/Or Multi-tier Architectures

Pick Based On Requirements:

1 Monolith → multi-tier: simplest scaling boundaries, common for web apps
2 Microservices: independent deploy and scale per service
3 Event-driven: best for decoupling, async workflows, variable traffic

“Must decouple producers and consumers” → events/queues.

B | Determine Scaling Strategies For Architecture Components

Typical Scaling Choices

1 ALB + Auto Scaling for EC2
2 ECS Service Auto Scaling (tasks)
3 Lambda concurrency scaling
4 DB scaling: read replicas, caching, sharding patterns

C | Determine Services Required To Achieve Loose Coupling

Loose coupling toolkit:
1 SQS: buffer + retry + DLQ
2 SNS: fan-out
3 EventBridge: event routing
4 Step Functions: workflow + retries/timeouts
5 S3: durable handoff pattern: “drop file, trigger event”

D | Determine When To Use Containers

Containers are a good answer when:
1 You need custom runtimes or dependencies
2 You want microservices packaging with predictable scaling
3 You want long-running services (vs Lambda time limits)

E | Determine When To Use Serverless Technologies And Patterns

Serverless Is A Good Answer

1 Event-driven workloads
2 Spiky/unknown traffic
3 Want minimal ops and fast scaling
4 You can fit within service constraints (timeouts, cold starts, etc.)

F | Recommend Compute, Storage, Networking, And Database Technologies

1 Compute: Lambda vs ECS/Fargate vs EC2
2 Storage: S3 vs EFS vs EBS
3 Data: DynamoDB vs RDS (relational needs)
4 Network entry: CloudFront/ALB/API Gateway

G | Use Purpose-Built AWS Services

1 SQS for queues, SNS for pub/sub
2 API Gateway for managed API
3 Step Functions for orchestration
4 ElastiCache for caching

Cheat Sheet

Requirement	Choice
Need to buffer spikes / decouple services	SQS (+ DLQ)
Fan-out to multiple consumers”	SNS → multiple SQS
Route events to different targets	EventBridge
Managed API front door	API Gateway
HTTP path-based routing to services	ALB
Global caching and lower latency	CloudFront
Orchestrate steps with retries/timeouts	Step Functions
Spiky events, minimal ops	Lambda
Containerized microservices without servers	ECS on Fargate
Read-heavy database workload	RDS read replicas
Store files durably and cheaply	S3

Recap Checklist ✅

If you can explain these ideas in simple terms, you’re in good shape for Task Statement 2.1:

1. [ ] Compute is designed to be stateless so it can scale horizontally

2. [ ] Traffic is distributed using ALB/API Gateway where appropriate

3. [ ] Spikes and failures are absorbed using queues/streams (often SQS)

4. [ ] Services are loosely coupled (async messaging, events, durable handoffs)

5. [ ] Caching is used to reduce latency and backend load (CloudFront/ElastiCache)

6. [ ] Storage choice matches the need (S3 object vs EFS file vs EBS block)

7. [ ] Databases scale reads with read replicas when needed

8. [ ] Workflows are orchestrated with Step Functions when coordination is required

9. [ ] Containers/serverless are chosen based on runtime + ops + scaling requirements

AWS Whitepapers and Official Documentation

These are the primary AWS documents behind Task Statement 2.1.

You do not need to memorize them, use them to understand why scalable and loosely coupled architectures work the way they do.

APIs and Integration

1. API Gateway
2. Step Functions
3. EventBridge
4. SNS
5. SQS

Load Balancing and Edge

1. Application Load Balancer (ALB)
2. CloudFront
3. Global Accelerator

Compute (Serverless and Containers)

1. Lambda
2. ECS

3. Fargate
4. EKS

Storage and Databases

1. S3

2. EBS

3. EFS

4. RDS read replicas

Other Managed Services Mentioned

1. AWS Transfer Family
2. AWS Secrets Manager
3. ElastiCache (Redis)

🚀

Determine Appropriate Data Security Controls

Ntombizakhona Mabaso — Tue, 03 Feb 2026 08:11:24 +0000

Exam Guide: Solutions Architect - Associate
🛡️ Domain 1: Design Secure Architectures
📘 Task Statement 1.3

🎯 Determining appropriate data security controls is about protecting data through its full lifecycle:

Who can access it (governance)
How it’s classified and retained
How it’s encrypted (at rest + in transit)
How keys/certificates are managed and rotated
How data is backed up, replicated, and recovered

Secure Data Design Questions You Should Be Able To Answer

1 What data is this (classification)? Public, internal, confidential, regulated (PII/PHI/PCI).

2 Where does it live? S3, EBS, RDS, DynamoDB, EFS, backups, logs, analytics.

3 Who can access it? Which roles/accounts/services? How is access audited?

4 How is it protected at rest? Encryption + key policy + separation of duties.

5 How is it protected in transit? TLS, private connectivity, certificate management.

6 How do we recover it? Backups, replication, DR strategy (RPO/RTO).

7 How long do we keep it? Retention, lifecycle policies, legal hold, deletion strategy.

Knowledge

1 | Data Access And Governance

Data governance on AWS usually means:

Strong IAM controls (least privilege)
Resource policies (e.g., S3 bucket policies)
Central guardrails (e.g., Organizations and SCPs in multi-account)
Visibility and auditing (CloudTrail, S3 access logs, AWS Config)

“Prevent unintended public exposure” → tighten resource policies + block public access + least privilege.

2 | Data Recovery

Recovery is about meeting RPO/RTO and surviving failures:

Backups: point-in-time restore, snapshots
Replication: same region or cross-region
DR patterns: pilot light, warm standby, multi-site

“Need cross-region recovery” → replication + cross-region backups

3 | Data Retention And Classification

Keep data only as long as needed (compliance + cost)
Classify data and apply different controls based on sensitivity

Common AWS Tools And Patterns

1 S3 lifecycle policies: transition to IA/Glacier, expire objects
2 S3 Object Lock: WORM retention for compliance
3 Macie: to discover PII in S3 and helps classification efforts

4 | Encryption And Appropriate Key Management

1 AWS-owned keys: AWS manages everything, limited control for you
2 AWS-managed keys: aws/s3, aws/rds
3 Customer-managed KMS keys (CMKs): most control for you such as key policies, rotation and grants

Encryption is not just “turn it on”, it’s who controls the keys and who can use them.

Skills

A | Align AWS Technologies To Meet Compliance Requirements

Typical Compliance Driven Controls

Encryption at rest + in transit
Strong retention and immutability (WORM)
Auditability and access logging
Key separation of duties such as the security team manages keys and app team uses keys

“Regulated data” → customer-managed KMS keys, tight key policies, strong logging, retention controls.

B | Encrypt Data At Rest

AWS Key Management Service (AWS KMS)

Common “Encryption At Rest” Mappings:
1 S3: SSE-KMS or SSE-S3 depending on requirement
2 EBS: encrypted volumes + snapshot encryption
3 RDS/Aurora: enable encryption (KMS) at creation time
4 DynamoDB: encryption at rest by default; can use CMKs
5 EFS: encryption at rest with KMS

“Need control over key usage / audit / rotation” → SSE-KMS with customer-managed key.

C | Encrypt Data In Transit

ACM using TLS

Use TLS for all client-to-service and service-to-service communication
Use AWS Certificate Manager (ACM) to provision/manage certificates for:
- ALB / NLB (TLS listeners)
- CloudFront
- API Gateway (custom domains)

“Manage and renew certs automatically” → ACM.

D | Implement Access Policies For Encryption Keys

KMS Access Is Controlled By

1 Key policies: primary control plane
2 IAM policies: additional control
3 KMS grants: often used by AWS services to use keys on your behalf

What To Design For:

Least privilege on kms:Encrypt, kms:Decrypt, kms:GenerateDataKey
Separation of Duties: admins manage key and apps can use key but can’t change it

“Only specific role can decrypt” → KMS key policy that allows decrypt to that role (and denies everyone else).

E | Implement Data Backups And Replications

Common AWS Patterns:

1 AWS Backup for centralized backup policies across services (where supported)
2 EBS snapshots + cross-region snapshot copy
3 RDS automated backups + read replicas / cross-region replicas (where supported)
4 S3 replication (CRR/SRR) for object-level replication
5 DynamoDB PITR + global tables (if multi-region active-active required)

“Centralized backup policy across accounts” → AWS Backup + Organizations

F | Implement Policies For Data Access, Lifecycle, And Protection

Examples:

1 S3 bucket policy: restrict access to specific roles/VPC endpoints, require TLS
2 S3 Block Public Access: prevent accidental public exposure
3 Lifecycle Policies: move older data to cheaper tiers, expire when allowed
4 Object Lock: enforce retention or WORM for compliance archives

“Must prevent deletion for X years” → S3 Object Lock

G | Rotate Encryption Keys And Renew Certificates

1 KMS Key Rotation: enable automatic rotation for customer-managed keys (where applicable)
2 Secrets Rotation: Secrets Manager rotation for credentials
3 Certificate Renewal: ACM renews eligible certificates automatically

“Rotate keys automatically without app changes” → KMS automatic rotation (customer-managed key) + envelope encryption patterns (handled by AWS services).

Cheat Sheet

Scenario	Direction
Encrypt at rest with full control	KMS customer-managed key (CMK)
Simple encryption, minimal management	AWS-managed keys (service default)
Encrypt data in transit / manage TLS certs	ACM + TLS listeners (ALB/NLB/CloudFront)
Only certain roles can decrypt	Tight KMS key policy + least privilege
Prevent accidental public S3 exposure	S3 Block Public Access + bucket policy
Keep data for 7 years, no deletion	S3 Object Lock
Backups across multiple services/accounts	AWS Backup + policies
Cross-region recovery for S3 objects	S3 Replication (CRR)
“Restore to a point in time”	RDS automated backups / DynamoDB PITR

Recap Checklist ✅

If you can explain these ideas in simple terms, you are well prepared for Task Statement 1.3:

1. [ ] Data is classified (public/internal/confidential/regulatory) and controls match sensitivity

2. [ ] Data at rest is encrypted (often using KMS, with CMKs when control is required)

3. [ ] Data in transit uses TLS, with certificates managed by ACM where applicable

4. [ ] KMS key access is least-privilege (key policy + IAM), with separation of duties

5. [ ] Backups meet RPO/RTO (snapshots, PITR, AWS Backup) and are tested

6. [ ] Replication is used when the requirement is multi-region recovery or resilience

7. [ ] Retention and lifecycle policies exist (archive/expire appropriately)

8. [ ] Keys are rotated and certificates are renewed (KMS rotation / ACM renewal)

AWS Whitepapers and Official Documentation

These are the primary AWS documents behind Task Statement 1.3.

You do not need to memorize them, use them to understand why AWS data security controls work the way they do.

Encryption and Key Management

AWS Key Management Service (KMS) Developer Guide

Explains KMS keys, envelope encryption, key policies, grants, and rotation
Core reference for “who can encrypt/decrypt” questions

KMS Key Policies

The most important part of controlling key usage
Helps with “only this role can decrypt” and separation-of-duties scenarios

AWS Certificate Manager (ACM)

How to provision and renew TLS certificates
Common for ALB/CloudFront/API Gateway custom domain encryption

Data Protection by Service

S3 Encryption Options

SSE-S3 vs SSE-KMS vs client-side encryption concepts
Useful for “which encryption option should we pick?” scenarios

S3 Block Public Access

Prevents accidental public access via ACLs/bucket policies
Often the correct control when the scenario is about preventing exposure

S3 Object Lock (WORM retention)

Compliance retention and legal hold
Tested when immutability/retention is required

Amazon RDS Encryption

How encryption at rest works for RDS/Aurora and what it impacts (snapshots/replicas)

Backup, Recovery, Retention

AWS Backup

Centralized backup policies, vaults, lifecycle, and cross-account patterns
Common when exam asks for “backup at scale”

Disaster Recovery on AWS (concepts and patterns)

Explains RPO/RTO and DR strategies (backup/restore, pilot light, warm standby, multi-site)
Helps when the question is “which DR approach matches the requirement?”

Compliance and Security Mindset

AWS Well-Architected Framework – Security Pillar

The “why” behind least privilege, data protection, and governance decisions
Strong general framework for answering security design questions

AWS Shared Responsibility Model

Clarifies what AWS provides vs what you must configure (especially for encryption and access)

🚀

Design Secure Workloads And Applications

Ntombizakhona Mabaso — Mon, 02 Feb 2026 09:28:40 +0000

Exam Guide: Solutions Architect - Associate
🛡️ Domain 1: Design Secure Architectures
📘 Task Statement 1.2

🎯 Secure workloads and apps usually means:

1 Secure network design: VPC layout, segmentation, filtering
2 Secure traffic flow: ingress/egress control, endpoints, TLS
3 Secure credentials: no hard-coded secrets, secrets must be managed + rotated
4 Threat protection & detection: WAF/Shield, GuardDuty, Macie
5 Secure external connectivity: VPN, Direct Connect, controlled inbound paths

This task shifts from “who can access AWS” (Task 1.1) to “how the workload is built and protected”.

Knowledge (what you must understand)

1 | Application Configuration And Credentials Security

Goal: keep secrets out of code, AMIs, user data, and plain-text configs.

Use AWS Secrets Manager for database passwords, API keys, and rotation.
Use SSM Parameter Store for configuration (and SecureString with KMS for sensitive values).

“Credentials are stored in code” → move to Secrets Manager
“Need automatic rotation” → Secrets Manager

2 | AWS Service Endpoints

Goal: keep traffic to AWS services private, not over the public internet.

VPC endpoints

Gateway endpoints: S3, DynamoDB
Interface endpoints (AWS PrivateLink): many AWS services via ENIs

“No internet access, but must reach S3/Secrets Manager” → VPC endpoints (plus route/security group controls).

3 | Control Ports, Protocols, And Network Traffic On AWS

Goal: only allow the traffic you intend, nothing more.

Core VPC Controls

1 Security groups (SGs): instance/ENI-level, stateful
2 Network ACLs (NACLs): subnet-level, stateless
3 Route tables: where traffic is allowed to go
4 Internet Gateway (IGW): enables public subnet internet routing
5 NAT Gateway: allows private subnets outbound internet (no inbound)

“Instances in private subnet need outbound updates” → NAT Gateway (or VPC endpoints when applicable).

4 | Secure Application Access

Goal: expose only what must be public and authenticate and authorize properly.

Typical Secure Pattern

1 Public entry via CloudFront and/or ALB
2 Put application compute in private subnets
3 Put databases in private/isolated subnets
4 Use TLS everywhere (HTTPS)

Identity Choices

Amazon Cognito: end-user sign-up/sign-in for apps
IAM Identity Center: workforce/admin access to AWS accounts

5 | Security Services With Appropriate Use Cases

1 Amazon Cognito: authentication for application users (tokens, user pools)
2 Amazon GuardDuty: threat detection (suspicious API calls, network behavior, DNS)
3 Amazon Macie: discovers/protects sensitive data in S3 (PII patterns)

6 | Threat Vectors External To AWS

DDoS: use AWS Shield
SQL injection / XSS: use AWS WAF

“Protect from SQLi/XSS” → AWS WAF

Skills

A | Design VPC Architectures With Security Components

Design With Layers And Controlled Paths

Public subnets: ALB and sometimes NAT Gateway
Private subnets: app tier (EC2/ECS/EKS), internal services, da

Security Components

SGs restrict who can talk to whom, which is a recommended primary control
NACLs provide coarse subnet guardrails, which should be used when explicitly required
Route tables prevent accidental connectivity

B | Determine Network Segmentation Strategies

Beginner rule:

Public subnet: route to an Internet Gateway
Private subnet: no route to an Internet Gateway

“Only the load balancer should be public” → ALB in public subnet, app in private subnet, DB private and isolated.

C | Integrate AWS Services To Secure Applications

Common Combos:

1 AWS WAF + ALB/CloudFront:

SQLi
XSS
bot mitigation

2 AWS Shield:

DDoS protection
Shield Advanced for stronger needs

3 AWS Secrets Manager: store secrets + rotation
4 IAM Identity Center: workforce and Amazon Cognito: end users
5 GuardDuty: detect threats
6 Macie: S3 sensitive data discovery

D | Secure External Network Connections To And From AWS

Site-to-Site VPN: encrypted tunnel over the internet which is fast to deploy
AWS Direct Connect: private dedicated link which has more consistent performance Resilient design: Direct Connect + VPN backup

“Need private connectivity to on-prem” → VPN and/or Direct Connect

Cheat Sheet

Scenario	Direction
Keep AWS API/service traffic private	VPC endpoints (Gateway/Interface)
Database must not be internet reachable	DB in private/isolated subnet + SG only from app tier
Only ALB should be public	ALB public, app private; NAT/endpoints as needed
Protect from SQL injection / XSS	AWS WAF (managed rules)
DDoS protection required	AWS Shield (+ CloudFront/WAF commonly)
Secrets in code/config	Secrets Manager (rotation if needed)
Detect suspicious activity	GuardDuty
Find PII in S3	Macie
Private connectivity to on-prem	VPN and/or Direct Connect

Recap Checklist ✅

If you can explain these ideas in simple terms, you are well prepared for Task Statement 1.2:

1. [ ] Secrets and credentials are not stored in code (use Secrets Manager or SSM Parameter Store SecureString)

2. [ ] The workload uses private subnets for app/data tiers, and only required components are public

3. [ ] Inbound traffic is controlled with security groups (and NACLs if needed), using minimal ports/protocols

4. [ ] Outbound internet access from private subnets is intentional (via NAT Gateway) or avoided using VPC endpoints

5. [ ] AWS service access stays private where possible (use Gateway/Interface VPC endpoints / PrivateLink)

6. [ ] Public web apps are protected against common attacks using AWS WAF (and CloudFront when appropriate)

7. [ ] DDoS risk is addressed using AWS Shield (and scaling/edge protections as needed)

8. [ ] Suspicious activity detection is enabled with Amazon GuardDuty

9. [ ] Sensitive data in S3 can be discovered/monitored with Amazon Macie when required

10. [ ] External connectivity (to/from on-prem) uses VPN and/or Direct Connect with secure routing and redundancy

AWS White Papers and Official Documentation

These are the primary AWS documents behind Task Statement 1.2.

You do not need to memorize them, use them to understand why secure workload design works the way it does.

Networking and VPC Security

Amazon VPC User Guide

Explains how VPCs, subnets, route tables, and gateways work
Core for questions about public vs private subnets, routing, and segmentation

Security Groups

Your primary tool for controlling inbound/outbound traffic to instances and ENIs
Frequently tested: stateful behavior, least-ports-open design

Network ACLs (NACLs)

Subnet-level firewall rules (stateless)
Shows up when the exam wants an extra “layer” of subnet control

NAT Gateways

Enables outbound internet access from private subnets (without allowing inbound)
Common exam scenario: patching instances in private subnets

VPC Endpoints / AWS PrivateLink

Keeps traffic to AWS services private (no public internet path)
Key for “no internet access but still must reach S3/Secrets Manager” scenarios

Application Protection and Threat Mitigation

AWS WAF

Protects web apps from common attacks (SQLi, XSS) using managed rules and custom rules
Often paired with ALB or CloudFront in exam architectures

AWS Shield (DDoS overview)

Explains DDoS protection options (Shield Standard vs Shield Advanced)
Typical exam clue: “must protect against DDoS” → Shield + edge design

Amazon GuardDuty

Threat detection service that analyzes logs/telemetry to flag suspicious behavior
Useful when the question is about detection and alerting (not just prevention)

Amazon Macie

Finds and alerts on sensitive data (PII) stored in S3
Exam clue: “identify PII in S3 automatically” → Macie

Identity for Applications and Secrets

Amazon Cognito

Authentication/authorization for application end users (sign-up/sign-in, tokens)
Exam clue: “millions of app users need login” → Cognito

AWS Secrets Manager

Stores secrets securely and supports automated rotation
Exam clue: “rotate DB credentials automatically” → Secrets Manager

SSM Parameter Store

Stores application configuration parameters; can encrypt with KMS (SecureString)
Often chosen for configuration values and simpler secret needs

External Connectivity (On-Prem ↔ AWS)

AWS Site-to-Site VPN

Encrypted connectivity over the internet between on-prem and AWS
Exam clue: “quick secure connection to on-prem” → Site-to-Site VPN

AWS Direct Connect

Dedicated private network connection for consistent performance
Exam clue: “consistent throughput / lower latency / private circuit” → Direct Connect
Common best practice: pair with VPN for backup/failover

🚀

From Idea to Prototype in Minutes: Building My Portfolio with Antigravity

Ntombizakhona Mabaso — Mon, 02 Feb 2026 07:20:55 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

I'm Ntombizakhona Mabaso, a Cloud Engineer and Web Developer based in Johannesburg, South Africa. I'm passionate about building scalable cloud solutions and creating intelligent web experiences that bridge the gap between robust infrastructure and elegant user interfaces.

With this portfolio, I wanted to express my journey in tech, showcasing my certifications (including Google Cloud Professional Architect, AWS certifications, and Microsoft AI Fundamentals), my content creation across Medium, Dev.to, and even my Cloud Glossary Podcast on Spotify. Most importantly, I wanted visitors to interact with an AI version of me that could answer questions about my work 24/7.

Portfolio

How I Built It

The Tech Stack

Frontend: Next.js 14 with TypeScript and CSS Modules
AI Integration: Google Gemini AI (via @google/generative-ai SDK)
Icons: Lucide React for beautiful, consistent iconography
Deployment: Google Cloud Run with Cloud Build CI/CD
Version Control: GitHub with automated deployments

The Development Process with Antigravity

What made this project unique was building it entirely with Antigravity, Google's AI coding assistant. Here's how the journey unfolded:

1. Starting from an Idea
I described my vision: a modern portfolio with an AI-powered chat widget that could represent me to visitors. Antigravity helped me scaffold the entire Next.js project structure.

2. Designing the Experience
Together, we created:

A stunning hero section with animated typing effects
A skills section with animated progress bars
A certifications showcase displaying my cloud credentials
A "Blogs & Articles" section linking to my content across platforms
A light/dark theme toggle for accessibility
Floating particle animations for that premium feel

3. Building the AI Digital Twin
The standout feature is the AI chat widget powered by Google Gemini. We created a system prompt that captures my personality, skills, and communication style. Now visitors can ask questions like "What certifications does Ntombizakhona have?" or "Tell me about your cloud experience" and get responses as if they're talking to me!

4. Feminizing the Design
I wanted my portfolio to feel uniquely mine, so we (Antigravity & I) customized the color scheme with rose, coral, and pink gradients that feel both professional and personal.

5. Deploying to Cloud Run
The deployment process was seamless. Antigravity helped me:

Create an optimized multi-stage Dockerfile
Set up cloudbuild.yaml for CI/CD
Push to GitHub and configure automatic deployments
Debug build issues in real-time

Every push to the main branch now triggers an automatic deployment to Cloud Run!

Google AI Tools Used

Google Gemini API: Powers the AI Digital Twin chat feature
Google Cloud Run: Hosts the containerized Next.js application
Google Cloud Build: Automates the CI/CD pipeline
Antigravity: The AI coding assistant that helped me build everything from idea to prototype!

What I'm Most Proud Of

🤖 The AI Digital Twin

The chat widget isn't just a gimmick, it's genuinely useful. It knows about my certifications, projects, blogs, and personality. Visitors can have real conversations and learn about me even when I'm not available.

⚡ The Development Speed

What would have taken me weeks to build on my own took just a few sessions with Antigravity. From initial concept to deployed prototype, the AI assistant accelerated every step: writing components, debugging issues, configuring Docker, and setting up CI/CD.

🎨 The Aesthetic

The site doesn't just work, it looks premium. The rose-gradient color scheme, floating particles, smooth animations, and responsive design create an experience I'm genuinely proud to share.

📚 The Content Integration

I've been building in public for a while now, writing about cloud concepts, creating exam guides, and even hosting a podcast. This portfolio finally brings all that content together in one place, making it easy for visitors to explore my work across platforms.

🚀 The CI/CD Pipeline

Every git push automatically triggers a build and deployment. It's the kind of professional infrastructure that shows I practice what I preach as a Cloud Engineer.

Building this portfolio taught me that AI coding assistants aren't replacing developers, they're supercharging us. Antigravity felt like pair programming with a senior engineer who never gets tired and knows every framework. The future of development is collaborative, and I'm excited to keep building!

DEV Community: Ntombizakhona Mabaso

Design Cost-Optimized Compute Solutions

🎯 Designing Compute Optimized Solutions is about choosing compute that meets performance and availability needs at the lowest reasonable cost.

Knowledge

1 | AWS Cost Management Service Features

Cost Allocation Tags And Multi-Account Billing

1.1 Cost Allocation Tags

1.2 Multi-Account Billing | Consolidated Billing

2 | AWS Cost Management Tools

Cost Explorer, Budgets, CUR

3 | AWS Global Infrastructure

Regions & Availability Zones (AZs)

4 | AWS Purchasing Options

Spot, Reserved Instances, Savings Plans

4.1 On-Demand

4.2 Spot Instances

4.3 Reserved Instances (RIs)

4.4 Savings Plans

5 | Distributed Compute Strategies

Edge Processing

6 | Hybrid Compute Options

Outposts & Snowball Edge

6.1 AWS Outposts

6.2 AWS Snowball Edge

7 | Instance Types, Families, And Sizes

Memory Optimized, Compute Optimized, Virtualizationn

Cost Mindset

8 | Optimization of Compute Utilization

Containers, Serverless, Microservices

9 | Scaling Strategies

Auto Scaling & Hibernation

9.1 Auto Scaling

9.2 EC2 hibernation

Skills

A | Determine An Appropriate Load Balancing Strategy

ALB vs NLB vs GWLB

1 Application Load Balancer (ALB)

2 Network Load Balancer (NLB)

3 Gateway Load Balancer

B | Determine Appropriate Scaling Methods And Strategies For Elastic Workloads

Horizontal vs Vertical, Hibernation

1 Horizontal scaling

2 Vertical Scaling

3 Hibernation

C | Determine Cost-Effective AWS Compute Services

Lambda, EC2, Fargate

1 Lambda

2 EC2

3 Fargate

D | Determine The Required Availability For Different Classes Of Workloads

Production vs Non-Production

1 Production

2 Non-Production / Dev / Test

E | Select The Appropriate Instance Family

F | Select The Appropriate Instance Size

Right-sizing principles:

Cheat Sheet

Recap Checklist ✅

AWS Whitepapers and Official Documentation

Cost Visibility And Management

Compute Pricing Options

Compute Services

Scaling And Optimization

Load Balancing

Edge And Hybrid Compute

Design Cost-Optimized Storage Solutions

🎯 Designing Cost-Optimized Storage Solutions is about storing data in the lowest-cost way that still meets business requirements.

Knowledge

1 | Access Options

Requester Pays

S3 Requester Pays

2 | AWS Cost Management Service Features

Cost Allocation Tags & Multi-Account Billing

3 | AWS Cost Management Tools

Cost Explorer, Budgets, Cost and Usage Report

4 | AWS Storage Services With Appropriate Use Cases

FSx, EFS, S3, EBS

4.1 Amazon S3

4.2 Amazon EFS

4.3 Amazon EBS