DEV Community: Ntombizakhona Mabaso

Developer Associate Exam Guide

Ntombizakhona Mabaso — Fri, 24 Apr 2026 19:27:55 +0000

What Is the AWS Certified Developer – Associate?

The AWS Certified Developer – Associate (DVA-C02) validates your ability to develop, test, deploy, and debug cloud-based applications using AWS. It's aimed at developers with at least one year of hands-on experience building and maintaining AWS applications.

This isn't a theory-only exam. The questions are scenario-based. You'll be given a situation and asked to pick the best approach.

That means you need to understand not just what a service does, but when and how to use it in real code.

Exam Format

Detail	Value
Exam code	DVA-C02
Questions	65
Duration	130 minutes
Format	Multiple choice + multiple select
Passing score	720 / 1000
Cost	$150 USD
Validity	3 years

Multiple choice questions have one correct answer out of four.
Multiple select questions tell you how many answers to pick (usually two out of five).

The Four Domains

The exam is split into four domains, each with a different weight:

Domain	Weight	~Questions
1. Development with AWS Services	32%	~21
2. Security	26%	~17
3. Deployment	24%	~16
4. Troubleshooting and Optimization	18%	~11

Development is the biggest chunk, but Security is close behind.
Don't sleep on Deployment.
Nearly a quarter of the exam is CI/CD, IaC, and deployment strategies.

Domain 1

Development with AWS Services

(32%)

This is the core of the exam.
You need to write code that works with AWS services, not just click through the console.

Task 1.1 Develop code for applications hosted on AWS

Architectural patterns: event-driven, microservices, fanout, choreography vs orchestration
Stateful vs stateless, tightly vs loosely coupled, sync vs async
Building and maintaining APIs with API Gateway
Writing unit tests with SAM
Using messaging services (SQS, SNS, EventBridge)
Working with AWS SDKs
Handling streaming data (Kinesis)
Resilient code: retry logic, circuit breakers, error handling

Task 1.2: Develop code for AWS Lambda

VPC access from Lambda
Configuration: memory, timeout, concurrency, layers, extensions, triggers, destinations
Error handling: DLQs, Lambda Destinations
Testing Lambda functions
Performance tuning
Real-time data processing

Task 1.3: Use data stores in application development

DynamoDB: partition keys, GSIs, LSIs, query vs scan, consistency models
Data serialization and persistence
Data lifecycle management (TTL)
Caching with ElastiCache and DAX
Specialized stores like OpenSearch

Domain 2

Security

(26%)

Security is woven into everything on this exam.
Expect questions that combine security with development scenarios.

Task 2.1: Implement authentication and authorization

Cognito User Pools and Identity Pools
JWT tokens and bearer token validation
IAM roles, policies, and STS AssumeRole
Lambda authorizers
Cross-service auth in microservices

Task 2.2: Implement encryption using AWS services

Encryption at rest vs in transit
KMS: key creation, rotation, cross-account access
Client-side vs server-side encryption
AWS Encryption SDK
Certificate management

Task 2.3: Manage sensitive data in application code

Secrets Manager vs SSM Parameter Store
Encrypting Lambda environment variables
Data classification (PII, PHI)
Data masking and sanitization
Multi-tenant data isolation

Domain 3

Deployment

(24%)

This domain is all about getting code from your machine to production safely and repeatably.

Task 3.1: Prepare application artifacts for deployment

Packaging Lambda functions with dependencies
Container images and ECR
AWS AppConfig for feature flags and configuration
Project structure for SAM/CloudFormation

Task 3.2: Test applications in development environments

SAM local testing
Integration tests against API Gateway stages
Mocking external dependencies
Testing event-driven applications

Task 3.3: Automate deployment testing

Test events for Lambda and API Gateway
Lambda aliases and versions
IaC templates (SAM, CloudFormation)
Environment management
Amazon Q Developer for test generation

Task 3.4: Deploy code using AWS CI/CD services

CodePipeline, CodeBuild, CodeDeploy
Deployment strategies: blue/green, canary, rolling
Rollback strategies
API Gateway stages and custom domains
Dynamic deployments with staging variables

Domain 4

Troubleshooting and Optimization

(18%)

The smallest domain, but the questions can be tricky because they require you to diagnose problems from logs and metrics.

Task 4.1: Assist in root cause analysis

Debugging code and interpreting error messages
CloudWatch Logs, metrics, and traces
CloudWatch Logs Insights queries
Custom metrics with Embedded Metric Format
Troubleshooting deployment failures

Task 4.2: Instrument code for observability

Logging vs monitoring vs observability
Structured logging with correlation IDs
X-Ray tracing: segments, subsegments, annotations
CloudWatch alarms and SNS notifications
Health checks and readiness probes

Task 4.3: Optimize applications

Lambda concurrency and performance tuning
CloudFront caching strategies
ElastiCache for application-level caching
SNS subscription filter policies
Identifying bottlenecks from logs and metrics

Key AWS Services to Know

Here's a quick reference of the services that come up most on this exam:

Compute: Lambda, EC2, ECS, Fargate, Elastic Beanstalk

API & Integration: API Gateway, EventBridge, Step Functions, SQS, SNS, Kinesis

Data: DynamoDB, S3, ElastiCache, DAX, RDS, OpenSearch

Security: IAM, Cognito, KMS, Secrets Manager, SSM Parameter Store, ACM

CI/CD: CodePipeline, CodeBuild, CodeDeploy, CloudFormation, SAM, AppConfig

Observability: CloudWatch (Logs, Metrics, Alarms, Dashboards), X-Ray, CloudTrail

Developer Tools: AWS SDK, AWS CLI, SAM CLI, Amazon Q Developer

How This Series Is Structured

Each article in this series maps directly to an exam task. We'll (You and I...and perhaps your AI Assistant, since that's how we do things these days) cover the concepts you need to know, then get hands-on with real code and CLI commands.

The goal is that by the end of the series, you've not only studied the material but you've built things with it...

Before You Start

Recommended experience:

At least 1 year developing and maintaining AWS applications
Comfortable with at least one programming language (Python, JavaScript/TypeScript, Java, C#, or Go)
Familiar with the AWS Console, CLI, and at least one AWS SDK

What you'll need to follow along:

1. An AWS account (free tier covers most of what we'll do)
2. AWS CLI v2 installed and configured
3. SAM CLI installed
4. A code editor (VS Code recommended)
5. Python 3.12+ or Node.js 20+ (we'll use both in examples)

Additional Resources

🚀

My Solutions Architect Associate Certification Journey and Resources to Certify With Confidence

Ntombizakhona Mabaso — Thu, 23 Apr 2026 18:46:05 +0000

☁️ Exam Guide: Solutions Architect Associate
Resources to Certify With Confidence
My Solutions Architect Associate Certification Journey

🧭 First Things First

The First Attempt

The first time I sat the Solutions Architect Associate exam, I was anxious.

This time? Still anxious.

Outcome? Passed both times.

Ntombizakhona Mabaso - AWS Certified Solutions Architect Associate

So no, the nerves don’t magically disappear just because you’ve done it before. You just get better at performing while anxious which feels like a life skill AWS forgot to list in the exam guide.

That said, I do wish I hadn’t let my certification expire. The smarter move would’ve been to renew by going straight for the Professional exam.

But: we live, we learn.

Takeaway:

Don’t let your Associate cert expire. Use it as a stepping stone:

Renew with Professional certifications and
Build into Specialties

Future you will appreciate the efficiency.
Present you might procrastinate anyway, but at least now you’ve been warned.

📘Resources

If You Took Cloud Practitioner Seriously, You’re Already Ahead

If you didn’t cut corners preparing for Cloud Practitioner, you’re in a strong position for the Solutions Architect Associate.

These exams aren’t isolated. They evolve together.

As cloud knowledge becomes more mainstream and general:

Foundational exams get more demanding and
Associate exams become a bridge to Professional-level thinking

So if SAA-C03 feels familiar at times, that’s not a coincidence. It’s intentional.

You’re not starting from scratch. You’re building on what you already know.
So, revisit the resources here: Resources

🛠️ The Resource That Actually Made a Difference

CloudPulse

The most valuable part of my preparation wasn’t another practice test. It was building something real.

Capstone Project: Architecture Review

Hands-on work changes everything.

It turns:

“This looks complicated” → “Oh, I’ve seen this before”
“Tricky question” → “This is obviously the better design”

If you rely purely on theory, you might scrape a pass or not pass at all. This exam expects you to think like an architect, not a glossary.

So yes, build something.
Even a small project is better than memorizing services like you’re cramming for a trivia night.

💸 The Frugal Architect

Domain Four Feels Repetitive… Because It’s Important

Domain Four focuses on cost optimization. Being a Frugal Architect.

If it feels repetitive, that’s because cost is embedded in nearly every AWS decision. AWS wants to make absolutely sure you don’t forget that running unnecessary resources is basically setting money on fire.

And unlike your bad subscription habits, this one actually matters.

You may not see cost emphasized this heavily again in other exams, so pay attention here. Not just for the exam, but because in real-world architecture, cost-efficient solutions are what separate good engineers from expensive ones.

🧠 What the SAA-C03 Really Teaches You

It’s not just about services or patterns.

It’s about resilience.

The exam is broad.
Concepts overlap.

At some point, you’ll wonder if you’re:

overthinking everything
studying the wrong topics
or slowly losing your grip on reality

All normal.

Push through anyway.

Associate exams aren’t just testing knowledge. They’re building your endurance for continuous learning. And if you’re aiming for Professional or Specialty certifications, you’ll need that stamina.

🚀 Finally

You don’t pass this exam by knowing everything.

You pass by:

understanding enough
recognizing patterns
and not panicking when AWS gives you four answers that all seem correct

Which they will. Repeatedly. For fun.

📚 Additional Resources

1. AWS SAA-C03 Exam Guide (PDF)

2. Exam Guide - Solutions Architect Associate

3. Capstone Project (CloudPulse)

4. The Frugal Architect
5. My Cloud Practitioner Certification Journey and the Resources to Certify with Confidence

Good luck with your exam! 🚀

Technologies And Concepts: Cheat Sheet for Solutions Architect Associate (SAA-C03)

Ntombizakhona Mabaso — Wed, 22 Apr 2026 17:31:28 +0000

☁️ Exam Guide: Solutions Architect Associate
Technologies And Concepts Cheat Sheet
📘 Cheat Sheet

Note: The SAA-C03 exam guide lists technologies and concepts across all four domains. This cheat sheet consolidates that information into a compact, exam-aligned reference. Organized domain by domain. Designed for quick review and efficient study.

📖 Exam Overview

#	Detail	Info
1	Exam Code	SAA-C03
2	Questions	65 total (50 scored, 15 unscored)
3	Passing Score	720 / 1000
4	Question Types	Multiple choice & Multiple response
5	Experience Required	1+ year hands-on designing cloud solutions on AWS

Domain Weightings

#	Domain	Weight
1	Design Secure Architectures	30%
2	Design Resilient Architectures	26%
3	Design High-Performing Architectures	24%
4	Design Cost-Optimized Architectures	20%

🔒 Domain 1

Design Secure Architectures

1.1 Secure Access to AWS Resources

#	Concept	What to Know
1	IAM	Users, Groups, Roles, Policies: Design flexible authorization models
2	IAM Identity Center	Centralized SSO across multiple AWS accounts
3	MFA	Apply to IAM users and root users as a security best practice
4	Cross-Account Access	Use IAM Roles + STS for role switching and cross-account patterns
5	AWS Organizations & SCPs	Manage multi-account security strategy with Service Control Policies
6	AWS Control Tower	Automate landing zones and guardrails across accounts
7	Resource Policies	Determine when to use resource-based vs identity-based policies
8	Federated Access	Directory service + IAM roles for external identity federation
9	Least Privilege	Core security principle: grant only minimum required permissions
10	Shared Responsibility Model	AWS secures the cloud & you secure what's in it

1.2 Secure Workloads and Applications

#	Concept	What to Know
1	VPC Architecture	Security groups, route tables, NACLs, NAT gateways
2	Subnets	Public vs private subnet segmentation strategies
3	AWS Shield	DDoS protection (Standard free, Advanced paid)
4	AWS WAF	Web Application Firewall for Layer 7 (SQL injection, XSS)
5	AWS Secrets Manager	Rotate, manage, retrieve secrets (DB credentials, API keys)
6	Amazon Cognito	User authentication for web/mobile apps
7	AWS GuardDuty	Threat detection using ML on logs/events
8	Amazon Macie	Discover and protect sensitive data (PII) in S3
9	VPN	Site-to-Site VPN and Client VPN for encrypted connectivity
10	AWS Direct Connect	Dedicated private network connection to AWS

1.3 Data Security Controls

#	Concept	What to Know
1	KMS	Managed key creation, rotation, and control for encryption at rest
2	ACM	Certificate Manager: TLS/SSL for encryption in transit
3	CloudHSM	Hardware Security Module for customer-managed key control
4	Data Classification	Categorize data by sensitivity to apply appropriate controls
5	S3 Versioning & MFA Delete	Protect object data from accidental deletion
6	Backup & Replication	Implement data backup, point-in-time recovery, cross-region replication
7	Data Lifecycle Policies	Manage retention and expiry of data at rest
8	Compliance	Align AWS services to regulatory requirements (GDPR, HIPAA, etc.)

🏗️ Domain 2

Design Resilient Architectures

2.1 Scalable and Loosely Coupled Architectures

#	Concept	What to Know
1	Amazon SQS	Decouple components with message queuing (Standard and FIFO)
2	Amazon SNS	Pub/sub messaging for fan-out patterns
3	Amazon EventBridge	Event-driven routing across AWS services and SaaS apps
4	AWS Step Functions	Workflow orchestration for distributed applications
5	API Gateway	Create, publish, and manage REST/HTTP/WebSocket APIs
6	Amazon AppFlow	Managed data integration between SaaS apps and AWS
7	AWS AppSync	Managed GraphQL API service
8	Serverless Patterns	Lambda + API Gateway + SQS/SNS for event-driven design
9	Microservices	Stateless vs stateful workloads & Independent scaling of components
10	Caching Strategies	Reduce load & know when to use caching vs direct reads
11	Horizontal vs Vertical Scaling	Scale out (add instances) vs scale up (bigger instance)
12	Load Balancers	ALB (Layer 7), NLB (Layer 4), GLB (Layer 3/4 for appliances)
13	Amazon MQ	Managed message broker (ActiveMQ/RabbitMQ) for migrations
14	Multi-tier Architectures	Web / App / DB tiers with distinct roles
15	CDN / Edge Accelerators	CloudFront for caching, Global Accelerator for routing performance

2.2 Highly Available and Fault-Tolerant Architectures

#	Concept	What to Know
1	Availability Zones	Deploy across ≥2 AZs for high availability
2	AWS Regions	Choose regions based on latency, compliance, and redundancy
3	Disaster Recovery Strategies	Backup & Restore → Pilot Light → Warm Standby → Active-Active
4	RPO / RTO	Recovery Point Objective (data loss tolerance) vs Recovery Time Objective (downtime tolerance)
5	Amazon Route 53	DNS with health checks, failover routing, latency-based routing
6	RDS Proxy	Pooled DB connections for Lambda and high-concurrency apps
7	Distributed Design Patterns	Retry with backoff, circuit breaker, bulkhead patterns
8	Service Quotas & Throttling	Plan for limits in standby environments
9	AWS X-Ray	Distributed tracing for workload visibility
10	Immutable Infrastructure	Replace rather than patch: ensures consistency
11	Auto Scaling	EC2 Auto Scaling + AWS Auto Scaling for elastic capacity
12	Storage Durability	S3 (11 9s), EBS (99.999%), choose appropriate tier

⚡ Domain 3

Design High-Performing Architectures

3.1 Storage Solutions

#	Service / Concept	Use Case
1	Amazon S3	Object storage: scalable, durable, lifecycle policies
2	Amazon EBS	Block storage for EC2: SSD (gp3, io2) or HDD (st1, sc1)
3	Amazon EFS	Managed NFS: shared file storage for Linux workloads
4	Amazon FSx	Managed file systems: Windows (SMB), Lustre (HPC), NetApp, OpenZFS
5	AWS Storage Gateway	Hybrid storage: file, volume, tape gateway types
6	Storage Types	Object vs File vs Block: know performance and use-case differences
7	S3 Storage Classes	Standard, Intelligent-Tiering, IA, Glacier, Glacier Deep Archive

3.2 Compute Solutions

#	Service / Concept	Use Case
1	Amazon EC2	Virtual machines: choose instance type/family for workload
2	EC2 Auto Scaling	Automatically add/remove instances based on demand
3	AWS Lambda	Serverless functions: event-driven, scale to zero
4	AWS Fargate	Serverless containers: no EC2 management needed
5	Amazon ECS	Container orchestration on EC2 or Fargate
6	Amazon EKS	Managed Kubernetes: supports Anywhere and Distro variants
7	AWS Batch	Managed batch processing: compute-intensive jobs
8	Amazon EMR	Big data on managed Hadoop/Spark clusters
9	AWS Elastic Beanstalk	PaaS: deploy web apps without managing infrastructure
10	AWS Outposts	AWS infrastructure on-premises (hybrid)
11	AWS Wavelength	Deploy workloads at the edge of 5G networks

3.3 Database Solutions

#	Service / Concept	Use Case
1	Amazon RDS	Managed relational DB: MySQL, PostgreSQL, SQL Server, Oracle, MariaDB
2	Amazon Aurora	High-performance relational DB (MySQL/PostgreSQL compatible)
3	Aurora Serverless	On-demand autoscaling for Aurora (v2 generally available)
4	Amazon DynamoDB	Serverless NoSQL: millisecond latency at any scale
5	Amazon ElastiCache	In-memory caching: Redis (complex data) vs Memcached (simple)
6	Amazon Redshift	Data warehouse: columnar storage for analytics queries
7	Amazon DocumentDB	Managed MongoDB-compatible document database
8	Amazon Neptune	Graph database for connected data (social graphs, fraud detection)
9	Amazon Keyspaces	Managed Apache Cassandra-compatible service
10	Read Replicas	Offload read traffic & know when to use vs Multi-AZ
11	Caching Patterns	Cache-aside, write-through, TTL strategies
12	DB Capacity Planning	Capacity Units (DynamoDB), Provisioned IOPS, instance sizing

3.4 Network Architectures

#	Service / Concept	Use Case
1	Amazon VPC	Isolated virtual network: subnets, route tables, IGW, NAT
2	Amazon CloudFront	CDN: cache content at edge locations globally
3	AWS Global Accelerator	Route users to optimal endpoints using AWS global network
4	Elastic Load Balancing	ALB (HTTP/S), NLB (TCP/UDP), GLB (appliances)
5	AWS Direct Connect	Dedicated private line to AWS (predictable performance)
6	AWS Transit Gateway	Hub-and-spoke for connecting many VPCs and on-prem networks
7	VPC Peering	Direct VPC-to-VPC connectivity (no transitive routing)
8	AWS PrivateLink	Private access to AWS services and third-party services
9	Amazon Route 53	DNS. Routing policies: simple, weighted, latency, failover, geolocation
10	Network Topology	Global, hybrid, multi-tier & design for scale

3.5 Data Ingestion and Transformation

#	Service / Concept	Use Case
1	Amazon Kinesis	Real-time streaming data: Data Streams, Data Firehose, Video Streams
2	Amazon Data Firehose	Load streaming data to S3, Redshift, OpenSearch
3	AWS Glue	Serverless ETL: transform and catalog data
4	Amazon Athena	Serverless SQL queries on S3 data
5	AWS Lake Formation	Build, secure, and manage data lakes on S3
6	Amazon EMR	Process large datasets with Hadoop, Spark, Hive
7	Amazon MSK	Managed Apache Kafka for streaming pipelines
8	AWS DataSync	Automate data transfer between on-prem and AWS storage
9	AWS Transfer Family	Managed SFTP/FTPS/FTP to S3 or EFS
10	Amazon QuickSuite	BI and data visualization service
11	Amazon OpenSearch	Search and analytics & also supports vector similarity (RAG)
12	Amazon Redshift	Query structured data at petabyte scale

💰 Domain 4

Design Cost-Optimized Architectures

4.1 Cost-Optimized Storage

#	Concept	What to Know
1	S3 Storage Classes	Match class to access frequency & Glacier for archival
2	S3 Lifecycle Policies	Automate transitions between storage classes
3	S3 Intelligent-Tiering	Auto-move objects between tiers based on access patterns
4	EBS Volume Types	gp3 vs io2 vs st1 vs sc1 & match to IOPS and cost needs
5	Requester Pays	Transfer cost charged to requester, not bucket owner
6	Data Lifecycle Management	Retain only what's needed & expire or archive the rest
7	Hybrid Storage	DataSync, Transfer Family, Storage Gateway for on-prem cost reduction
8	Backup Strategy	Balance recovery needs with cost (snapshots, replication)

4.2 Cost-Optimized Compute

#	Concept	What to Know
1	On-Demand Instances	Pay per use: highest flexibility, highest per-hour cost
2	Reserved Instances	1 or 3 year commitment: up to 72% savings
3	Savings Plans	Flexible commitment (Compute, EC2, SageMaker)
4	Spot Instances	Up to 90% savings for fault-tolerant/interruptible workloads
5	AWS Compute Optimizer	ML-based recommendations for right-sizing EC2, Lambda, EBS
6	AWS Serverless Application Repository	Pre-built serverless apps: reduce build cost
7	EC2 Hibernation	Save instance state to EBS: resume without full reboot
8	Containerization	ECS/EKS/Fargate for higher density and cost efficiency
9	Instance Families	General purpose, compute optimized, memory optimized, storage optimized
10	VMware Cloud on AWS	Extend VMware workloads to AWS without refactoring

4.3 Cost-Optimized Databases

#	Concept	What to Know
1	DynamoDB On-Demand vs Provisioned	On-demand for unpredictable; provisioned for predictable + cheaper
2	Aurora Serverless	Pay per ACU-hour: ideal for intermittent workloads
3	RDS Reserved Instances	Commit to 1 or 3 years for significant savings
4	Read Replicas	Offload reads to reduce primary DB load (and cost)
5	DB Snapshot Policies	Balance frequency vs storage cost
6	Caching	ElastiCache reduces DB query load and cost
7	Data Retention Policies	Define how long to keep data: archive vs delete
8	Right-Sized DB Instances	Don't over-provision: use metrics to guide sizing

4.4 Cost-Optimized Network Architectures

#	Concept	What to Know
1	NAT Gateway vs NAT Instance	NAT Gateway scales automatically but costs more & NAT instance is cheaper at low traffic
2	VPC Endpoints	Eliminate NAT costs for S3/DynamoDB & use Gateway Endpoints (free)
3	Direct Connect vs VPN	Direct Connect more expensive but predictable; VPN cheaper for low volume
4	Region-to-Region Transfer	Data egress fees apply & minimize cross-region traffic
5	Same-AZ Traffic	Free & architect to keep traffic within same AZ where possible
6	CloudFront	Reduce origin data transfer costs with edge caching
7	Transit Gateway Pricing	Attachment + data processing fees & evaluate vs VPC peering
8	Throttling Strategy	Use API Gateway throttling to control overuse and cost spikes

🛠️ AWS Cost Management Tools

Tool	Purpose
AWS Cost Explorer	Visualize and analyze historical spend and forecast costs
AWS Budgets	Set spend/usage thresholds with alerts
AWS Cost and Usage Report	Granular billing data exportable to S3
Savings Plans	Flexible commitment model for compute savings
Cost Allocation Tags	Tag resources to attribute costs to teams/projects
AWS Compute Optimizer	Right-sizing recommendations based on usage
AWS Trusted Advisor	Best-practice checks across cost, security, performance
AWS Well-Architected Tool	Review architecture against the Well-Architected Framework

💡 Disaster Recovery Strategy Comparison

Strategy	RPO	RTO	Cost	Description
Backup & Restore	Hours	Hours	💰 Lowest	Back up to S3/Glacier & restore on failure
Pilot Light	Minutes	10s of minutes	💰💰	Core services always running &scale up on failure
Warm Standby	Seconds/Minutes	Minutes	💰💰💰	Scaled-down live environment & quickly scale to full
Active-Active	Near zero	Near zero	💰💰💰💰 Highest	Full duplicate environment & traffic split between sites

🔑 Key Abbreviations

Abbreviation	Full Term
IAM	Identity and Access Management
SCP	Service Control Policy
MFA	Multi-Factor Authentication
STS	Security Token Service
ACM	AWS Certificate Manager
KMS	Key Management Service
VPC	Virtual Private Cloud
NACL	Network Access Control List
ALB	Application Load Balancer
NLB	Network Load Balancer
GLB	Gateway Load Balancer
CDN	Content Delivery Network
RPO	Recovery Point Objective
RTO	Recovery Time Objective
DR	Disaster Recovery
EBS	Elastic Block Store
EFS	Elastic File System
FSx	Amazon FSx (managed file systems)
SQS	Simple Queue Service
SNS	Simple Notification Service
ETL	Extract, Transform, Load
HDD	Hard Disk Drive
SSD	Solid State Drive
IOPS	Input/Output Operations Per Second
RI	Reserved Instance
ACU	Aurora Capacity Unit
PII	Personally Identifiable Information
SSO	Single Sign-On

🚀 In Scope AWS Services Quick Reference

Compute

Amazon EC2 · EC2 Auto Scaling · AWS Lambda · AWS Fargate · AWS Elastic Beanstalk · AWS Batch · AWS Outposts · VMware Cloud on AWS · AWS Wavelength · AWS Serverless Application Repository

Containers

Amazon ECR · Amazon ECS · ECS Anywhere · Amazon EKS · EKS Anywhere · Amazon EKS Distro

Storage

Amazon S3 · Amazon EBS · Amazon EFS · Amazon FSx · AWS Storage Gateway · AWS Snow Family

Database

Amazon RDS · Amazon Aurora · Aurora Serverless · Amazon DynamoDB · Amazon ElastiCache · Amazon Redshift · Amazon DocumentDB · Amazon Neptune · Amazon Keyspaces

Networking & Content Delivery

Amazon VPC · Amazon CloudFront · AWS Direct Connect · Elastic Load Balancing · AWS Global Accelerator · AWS PrivateLink · Amazon Route 53 · AWS Site-to-Site VPN · AWS Client VPN · AWS Transit Gateway

Analytics

Amazon Athena · Amazon EMR · AWS Glue · Amazon Kinesis · Amazon Data Firehose · Amazon Kinesis Video Streams · Amazon MSK · Amazon OpenSearch Service · Amazon QuickSuite · Amazon Redshift · AWS Lake Formation · AWS Data Exchange

Application Integration

Amazon SQS · Amazon SNS · Amazon EventBridge · Amazon MQ · AWS Step Functions · Amazon AppFlow · AWS AppSync

Security, Identity & Compliance

AWS IAM · AWS IAM Identity Center · Amazon Cognito · AWS KMS · AWS CloudHSM · AWS ACM · Amazon GuardDuty · Amazon Macie · Amazon Detective · AWS Shield · AWS WAF · AWS Secrets Manager · AWS Directory Service · AWS Artifact · AWS Audit Manager

Management & Governance

AWS Organizations · AWS Control Tower · AWS CloudFormation · AWS CloudTrail · Amazon CloudWatch · AWS Config · AWS Systems Manager · AWS Auto Scaling · AWS Compute Optimizer · AWS Trusted Advisor · AWS Well-Architected Tool · AWS Service Catalog · AWS Health Dashboard · AWS License Manager · Amazon Managed Grafana · Amazon Managed Service for Prometheus

Migration & Transfer

AWS DMS · AWS DataSync · AWS Snow Family · AWS Transfer Family · AWS Application Migration Service

Machine Learning

Amazon SageMaker AI · Amazon Comprehend · Amazon Kendra · Amazon Lex · Amazon Polly · Amazon Rekognition · Amazon Textract · Amazon Transcribe · Amazon Translate

Cost Management

AWS Budgets · AWS Cost Explorer · AWS Cost and Usage Report · Savings Plans

Developer Tools

AWS X-Ray

Serverless

AWS Lambda · AWS Fargate · Amazon API Gateway · Amazon DynamoDB · Amazon EventBridge · Amazon SQS · Amazon SNS

⚠️ Important: Always refer to the official exam guide for the most up-to-date list of in-scope and out-of-scope services.

📚 Additional Resources

Good luck with your exam! 🚀

Jog Squad | A Gamified Eco-Jogging App: Fix the Earth. Fix Your Health. One Run at a Time. 🏃

Ntombizakhona Mabaso — Sun, 19 Apr 2026 13:55:29 +0000

This is a submission for Weekend Challenge: Earth Day Edition

I'm a jogger. Not the "I ran a marathon once" kind but the "I need to run or my brain stops working" kind. Running is how I think, how I decompress, how I stay sane.

But here's the thing that drives me crazy: every single run, I pass litter.
Plastic bottles in the grass.
Wrappers caught in fences.
Cans rolling down the sidewalk.
It's literally everywhere, and most people myself included, honestly just jog right past it...hoping the Municipality takes care of it.

So, I love this planet. I love being outside in it. And it frustrates me that the places I run through are slowly being buried in trash that nobody takes responsibility for.

So when this Earth Day challenge dropped, I knew exactly what to build. Not another carbon calculator. Not another awareness app. Something that actually connects the act of running. Something I and many others already do every day. Something that makes picking up trash feel rewarding instead of inconvenient...
Enter: 🏃 #JogSquad

What I Built

Jog Squad is a gamified eco-jogging app that turns every outdoor run into an environmental cleanup mission.

The app connects your personal health to the planet's health through three pillars:

🗑️ Litter Detection & Cleanup: Snap a photo of your route and Gemini Vision AI identifies the litter, scores the area's cleanliness, and explains the environmental impact. Pick up what you find, log it, and earn points.

⚡ Electricity Saved: Every outdoor run you do instead of using a treadmill saves real electricity. Especially in South Africa, where LoadShedding (Controlled Power Cuts) can rear its head any second. The app tracks and quantifies this because treadmills consume roughly 0.7 kWh per hour, and running outside costs zero.

🏃 Health & Fitness: GPS-tracked runs with live mapping, pace calculation, and AI-powered coaching insights that get smarter as you log more runs.

The twist? You lose points for running on a treadmill and for skipping litter cleanup. Accountability through gamification.

Key features:

Live GPS run tracking with real-time map (or demo mode for presentations)
AI environment scanning: upload a photo, get litter detection and cleanliness score
Before/after photo comparison: Gemini narrates your cleanup impact
Points system with rewards AND penalties
AI-generated daily missions
Squad leaderboard
Full impact dashboard: CO₂ saved, electricity saved, litter removed
AI run reflections with pattern detection across your run history

Demo

🔗 Live on Google Cloud Run: Jog Squad

To try the full flow without going outside:
1. Go to Log Run → click "Demo Run (simulated GPS)"
2. Watch the live map track a simulated jog around Johannesburg
3. Finish the run → get AI analysis → log some litter cleanup
4. Check the Impact page to see your environmental stats
5. Try Scan → upload any outdoor photo → Gemini analyzes the litter

Code

Ntombizakhona / jog-squad

Fix the Earth. Fix Your Health. Gamified eco-jogging with Gemini AI.

🏃 Jog Squad

Fix the Earth. Fix Your Health. One Run at a Time.

Jog Squad is a gamified eco-jogging app that turns every outdoor run into an environmental cleanup opportunity. Using Google's Gemini AI, it detects litter from photos, tracks your environmental impact, and rewards you for making the planet cleaner — one jog at a time.

🌍 The Problem

Litter is everywhere. Treadmills waste electricity. People jog past trash every day without thinking about it.

💡 The Solution

Jog Squad connects your health to the earth's health:

Run outdoors instead of on a treadmill → save electricity
Scan your route with AI → see the litter problem
Pick up trash during your run → earn points
Before/after photos → prove your impact with AI comparison
Track everything → CO₂ saved, electricity saved, litter removed

✨ Features

🏃 Run Logging — Distance, time, indoor/outdoor, mood tracking
📸 AI Environment…

View on GitHub

How I Built It

Tech Stack

Frontend: React 18 + Vite, with Leaflet for live mapping
Backend: Node.js + Express
AI: Google Gemini 2.5 Flash (text generation + vision)
Database: Google Cloud Firestore (Native mode)
Deploy: Google Cloud Run (containerized with Docker)

The Gemini Integration (6 distinct uses)

This isn't "AI sprinkled on top." Gemini is doing real work across the entire app:

Run Reflections: After each run, Gemini receives your distance, pace, mood, location type, and your past run history. It generates personalized performance insights, improvement tips, and eco-impact statements. With enough runs, it detects patterns like "you slow down after 3km" or "you perform better in cooler weather."
Environment Scanning: Upload a photo of your running route. Gemini Vision analyzes it and returns structured JSON: litter types detected (plastic, metal, paper, glass), estimated counts, a cleanliness score from 1-10, and an environmental impact statement.
Before/After Comparison: Upload two photos (before and after cleanup). Gemini compares them and narrates the improvement, estimates items removed, and generates an impact statement. This is the feature that makes the cleanup feel real.
Cleanup Summaries: When you log collected litter, Gemini explains how long those items would take to decompose and what the real-world impact of removing them is.
Daily Missions: Gemini generates personalized daily challenges scaled to your experience level. New users get "Run 0.5km and pick up 1 item." Experienced users get harder goals.
Squad Leaderboard: Gemini generates a realistic mock leaderboard that places you among fictional squad members, making the app feel social even as a single-user POC.

Every Gemini call returns structured JSON that the app parses and renders. The prompts are carefully designed to get consistent, parseable responses.

GPS Tracking

The app uses the browser's Geolocation API with watchPosition for real-time tracking. Key decisions:

Haversine formula for distance calculation between GPS coordinates
Accuracy filtering: readings over 30m accuracy are discarded
Jitter filtering: movements under 3m are ignored (GPS noise)
Jump filtering: movements over 500m in one reading are rejected (GPS glitches)
Demo mode: a simulated 20-point route around Emmarentia Dam, Johannesburg, with points dropped every 1.5 seconds

The Points System

Action	Points
Distance run	+10 per km
Outdoor run	+20 bonus
Litter collected	+5 per item
Treadmill run	-15 penalty
Skipped cleanup	-10 penalty

The penalties are the key design decision. Most eco apps only reward. Jog Squad also punishes because running on a treadmill wastes electricity, and jogging past litter without picking it up is a missed opportunity.

Cloud Run Deployment

The Dockerfile uses a multi-stage build: first stage builds the React client with Vite, second stage runs the Express server and serves the static files. Deployed to africa-south1 for low latency from South Africa, with Firestore in the same region.

Prize Categories

Best Use of Google Gemini: Gemini is the backbone of the app, powering 6 distinct features: run reflections with pattern detection, environment photo scanning, before/after cleanup comparison, cleanup impact summaries, daily mission generation, and squad leaderboard generation. It uses both text generation and vision capabilities.

To fix your health, you have to fix the earth. To fix the earth, you have to get out there. Run. Clean. Repeat.

Happy Earth Day 🌍

🏃 #JogSquad

Design Cost Optimized Network Architectures

Ntombizakhona Mabaso — Wed, 15 Apr 2026 15:56:59 +0000

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

🎯 Designing Cost-Optimized Network Architectures is about selecting the cheapest networking design that still meets requirements for performance, availability, security, and scalability.

Start by understanding:

1. Traffic flow
2. Connectivity needs
3. Data transfer patterns

Then choose:

1. Networking services
2. Routing model
3. Edge strategy

Finally optimise using:

Caching
CDN
NAT strategy
Traffic reduction techniques

You are often deciding between:

1 Internet Gateway vs VPN vs Direct Connect

2 NAT Gateway vs NAT Instance

3 VPC Peering vs Transit Gateway

4 Edge caching vs origin traffic

5 Cross-AZ vs single-AZ traffic

📘 Knowledge

1 | AWS Cost Management Features

Network cost optimization starts with visibility into data transfer and routing charges.

Cost Allocation Tags & Multi-Account Billing

Network cost should be tracked by:

1 Environment (prod/dev/test)
2 Application or service
3 Network layer (VPC, NAT, ALB)

1.1 Cost Allocation Tags

Used to track:

1. NAT Gateway cost
2. Load Balancer usage
3. VPC traffic patterns

1.2 Multi-Account Billing (AWS Organizations)

Centralized billing for:

1. Multiple accounts
2. Environment separation
3. Cost visibility across teams

2 | AWS Cost Management Tools

2.1 Cost Explorer

Analyze data transfer trends
Identify expensive network paths

2.2 AWS Budgets

Alerts for unexpected network cost spikes

2.3 Cost and Usage Report (CUR)

Deep-level network cost analysis

3 | Load Balancing Concepts

Application Load Balancer (ALB)

Layer 7 routing
Cost based on usage

4 | NAT Gateways

NAT Gateways vs NAT Instances

4.1 NAT Gateway

Managed
Highly available
Higher cost (per hour + per GB)

Production → NAT Gateway

Avoid NAT Gateway usage for AWS services:

Gateway Endpoint (S3, DynamoDB) → FREE
Interface Endpoint → Private connectivity

4.2 NAT Instance

EC2-based
Cheaper but requires management

Dev/Test → NAT Instance

5 | Network Connectivity Options

5.1 Internet Gateway (IGW)

Public internet access
No additional hourly cost

5.2 AWS Site-to-Site VPN

Encrypted over internet
Quick setup
Lower cost than Direct Connect

5.3 AWS Direct Connect

Dedicated private connection
High performance
Higher fixed cost

6 | Network Routing, Topology, and Peering

6.1 VPC Peering

Direct VPC-to-VPC connection
Low cost
Not scalable for large architectures

6.2 AWS Transit Gateway

Central routing hub
Scalable but adds cost per attachment

7 | Network Services

7.1 Amazon Route 53

Route 53 is a scalable DNS and domain management service used to:

Route user traffic to applications
Improve availability with health checks
Optimize routing decisions (latency, geography, failover)

7.2 AWS Global Accelerator

Optimizes routing
Reduces latency

7.3 Amazon CloudFront

Caches content globally
Reduces origin load and data transfer costs

Skills

A | NAT Strategy

Single NAT Gateway → cost efficient
Multi-AZ NAT → high availability

B | Connectivity Selection

Requirement	Solution
Internet access	IGW
Hybrid connection	VPN
Enterprise private link	Direct Connect

C | Routing Optimization

1 Reduce cross-AZ traffic
2 Use VPC endpoints
3 Use CloudFront for caching

Cross-AZ Traffic

Avoid unnecessary:

Cross-AZ calls
Distributed chatty microservices

Cross-Region Traffic

Use only when needed for:

DR
Global users

VPC Endpoints

Avoid NAT Gateway usage for AWS services.

Gateway Endpoint (S3, DynamoDB) → FREE
Interface Endpoint → Private connectivity

D | CDN Strategy

Amazon CloudFront

Caches content globally
Reduces origin load and data transfer costs

Use CloudFront for:
1 Global users
2 Static assets
3 API acceleration

E | Workload Optimization

Look for:
1 Unused NAT Gateways
2 Cross-region traffic waste
3 Missing caching layers

F | Throttling Strategy

RDS Proxy

Connection pooling
Reduces database/network pressure

API Throttling

Prevents traffic spikes
Reduces scaling cost

G | Bandwidth Allocation

VPN = small workloads
Direct Connect = high traffic workloads
Single VPN → low throughput
Multiple VPNs → higher throughput
Direct Connect → stable high bandwidth

🧠 Cheat Sheet

Requirement	Solution
Reduce NAT cost	VPC Endpoints
Global traffic	CloudFront
Hybrid networking	VPN / Direct Connect
Multi-VPC architecture	Transit Gateway
Simple connectivity	VPC Peering
Reduce DB/network load	RDS Proxy + caching
High bandwidth private link	Direct Connect

Recap Checklist ✅

1. [ ] I can choose NAT Gateway vs NAT Instance

2. [ ] I understand VPN vs Direct Connect trade-offs

3. [ ] I can reduce cost using VPC Endpoints

4. [ ] I understand cross-AZ and cross-region cost impact

5. [ ] I can apply CloudFront for edge optimization

6. [ ] I understand Transit Gateway vs VPC Peering

7. [ ] I can optimize ALB usage

8. [ ] I can identify expensive routing patterns

AWS Whitepapers and Official Documentation

🚀

Design Cost-Optimized Database Solutions

Ntombizakhona Mabaso — Wed, 08 Apr 2026 19:25:23 +0000

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

🎯 Designing Cost-Optimized Database Solutions is about choosing the least expensive database design that still meets application requirements for performance, durability, retention, and availability.

Start with the data model and access pattern, then choose the database type, then optimize cost with right-sizing, caching, retention, connection management, and backup strategy.

You are often deciding between:

1. Relational vs non-relational
2. Provisioned vs serverless or on-demand
3. Read replicas vs caching
4. Keep data online vs archive or delete

Knowledge

1 | AWS Cost Management Features

Cost Allocation Tags & Multi-account Billing

Database cost should be tracked clearly by:

1 Environment (prod/dev/test)
2 Team or business unit
3 Application

We covered Cost Allocation Tags & Multi-account Billing in Task Statement 4.1 and Task Statement 4.2, but repetition is key even if it's monotonous.

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

These help analyze and govern database spending.

We covered AWS Cost Management Tools in Task Statement 4.1 and Task Statement 4.2, but what's worse than repetition? A Bill Shock!

1 Cost Explorer: trend analysis

2 AWS Budgets: alerts

3 Cost and Usage Report (CUR): detailed data

3 | Caching Strategies

Caching can reduce DB cost by reducing:

1 Read load
2 Need for large instance sizes
3 Number of replicas

Caching Services

ElastiCache (Redis/Memcached) for app-side caching
DAX for DynamoDB read caching

“Reduce read cost and latency” → caching is often cheaper than scaling the database.

4 | Data Retention Policies

Retention policy is a major cost lever:

1 Keep only 30 days of operational data in the live DB
2 Archive old records elsewhere
3 Delete data after policy/legal period expires

Cost Principle:

Databases are expensive places to keep cold historical data.

Often, old data should move to S3 or archive systems.

5 | Database Capacity Planning

Capacity Units & Instance Sizing

1 RDS/Aurora: cost depends on instance size, storage, IOPS, backups, replicas
2 DynamoDB: cost depends on read/write capacity mode and access pattern
3 Overprovisioning: costs money every hour

6 | Database Connections And Proxies

Connection storms can force you to over-size a database unnecessarily.

Amazon RDS Proxy

1 Pools/reuses connections
2 Especially useful for Lambda or many short-lived app connections
3 Can reduce need to scale DB just for connection handling

7 | Database Engines

Relational Databases Engines

1 MySQL & Aurora MySQL: common compatibility choice
2 PostgreSQL & Aurora PostgreSQL: rich SQL features
3 Oracle & SQL Server: when app and licensing requirements demand them

Migration Patterns

Homogeneous migration: same engine → same engine
Heterogeneous migration: different engine → different engine

AWS DMS is common for moving data with minimal downtime.

8) Database Replication

Read Replicas

Read replicas cost money, so use them when they solve a real problem:

1 Read scaling
2 Reporting queries
3 Cross-region reads

They are not automatically the cheapest answer.

Sometimes caching is cheaper than adding replicas.

9 | Database Types And Services

9.1 Amazon RDS

Managed relational database
Good when standard SQL engine support is needed

9.2 Amazon Aurora

High-performance managed relational database
Often more scalable and has high-performance than standard RDS engines
Cost-effective when that performance benefit matters

9.3 Amazon DynamoDB

Key-valued database
Massive scale, low latency, no instance management
Often highly cost-effective for the right access pattern

9.4 Serverless Database Patterns

Aurora Serverless v2
DynamoDB On-Demand

Serverless Database Patterns are useful when workload is highly variable and you want to avoid always-on overprovisioning.

Skills

A | Design Appropriate Backup And Retention Policies

Cost-optimized backup strategy means:

1 Back up often enough to meet recovery requirements
2 Don’t retain backups forever unless required
3 Use snapshots and automated backups with retention matched to the business need

Examples:

Daily snapshots for dev, longer retention for prod
Archive historical exports to S3 instead of keeping them in the live DB

B | Determine An Appropriate Database Engine

MySQL vs PostgreSQL

Choose based on:

1 App compatibility
2 Required features
3 Licensing/cost constraints
4 Migration complexity

Don’t migrate to a more expensive/complex engine without a requirement.

Pick the simplest engine that meets needs.

C | Determine Cost-Effective AWS Database Services

DynamoDB vs Amazon RDS vs Serverless

1 Need joins, transaction, and relational schema → RDS & Aurora
2 Need key-valued at massive scale with simple access patterns → DynamoDB
3 Highly variable relational workload → Aurora Serverless v2 may fit
4 Variable NoSQL traffic → DynamoDB On-Demand

D | Determine Cost-Effective Database Types II

Time Series & Columnar

Time-series or event-style data often fits NoSQL better than relational
Analytical and columnar needs are often better outside traditional OLTP databases

Don’t force every dataset into a relational OLTP database, and understand that various types of databases exists for various workloads. 'Purpose Built' as they say.

E | Migrate Database Schemas And Data To Different Locations And / Or Engines

AWS DMS for ongoing and minimal-downtime migration
AWS Schema Conversion Tool (SCT) for heterogeneous schema conversion
Same engine migration → *often easier, lower risk *
Different engine migration → SCT + DMS pattern is common

Cheat Sheet

Requirement	Database
Relational app with joins and transactions	RDS or Aurora
Massive scale key-value/document workload	DynamoDB
Highly variable workload, avoid overprovisioning	Serverless / on-demand model
Reduce DB reads cheaply	ElastiCache (or DAX for DynamoDB)
Lambda/app opening too many DB connections	RDS Proxy
Need relational performance at scale	Aurora
Move data with minimal downtime	AWS DMS
Change DB engine during migration	AWS SCT + DMS
Read-heavy workload	Read replicas or caching (compare cost)
Old data is rarely used	Archive/export old data instead of keeping it in primary DB

Recap Checklist ✅

1. [ ] I can choose RDS/Aurora vs DynamoDB based on data model and access pattern

2. [ ] I understand that caching can be cheaper than constantly scaling the database

3. [ ] I know when read replicas are useful and when they may be unnecessary cost

4. [ ] I can match retention policies to business needs instead of keeping all data online forever

5. [ ] I can choose serverless/on-demand database options for variable workloads

6. [ ] I understand connection pooling with RDS Proxy

7. [ ] I know the migration difference between homogeneous and heterogeneous migrations

8. [ ] I can pick backup frequency/retention that meets recovery goals without overspending

AWS Whitepapers and Official Documentation

Cost Visibility And Governance

1. Cost Explorer

2. AWS Budgets

3. Cost and Usage Report (CUR):

4. Cost allocation tags

Core Database Services

1. Amazon RDS

2. Amazon Aurora

3. Aurora Serverless v2

4. Amazon DynamoDB

Performance

1. ElastiCache
2. DynamoDB DAX

3. RDS Proxy
4. RDS Read Replicas

Capacity And Pricing

1. DynamoDB capacity modes

2. RDS storage concepts

Backup And Migration

1. AWS Backup

2. AWS DMS

3. AWS Schema Conversion Tool (SCT)

🚀

TaaS (418-as-a-Service): An Enterprise-Grade, Cloud-Native, AI-Powered Microservices Platform

Ntombizakhona Mabaso — Mon, 06 Apr 2026 19:26:38 +0000

This is a submission for the DEV April Fools Challenge

What I Built

TaaS (418-as-a-Service): An enterprise-grade, cloud-native, AI-powered microservices platform engineered from the ground up to solve one of computing's greatest challenges: returning HTTP status code 418 I'm a Teapot.

Built with the same architectural best practices as systems serving millions of users, TaaS serves absolutely no one, but does so with unprecedented reliability.

Features:

🫖 Core 418 Engine™: Returns 418. That's it. That's the feature.
🤖 AI-Powered Incident Reports: Gemini generates dramatic corporate incident reports every time someone tries to brew coffee on our teapot.
🧠 AI Teapot Wisdom: Philosophical quotes about being a teapot in a world that wants coffee, powered by Gemini 2.5.
📊 Real-Time Dashboard: Beautiful graphs tracking 418s served over time. The pie chart of status code distribution is 100% one color.
🔐 Teapot Identity Verification: Every request passes through 4 validation layers.

1. Physical Properties
2. Philosophical Status
3. RFC 2324 Compliance,
4. and Quantum Teapot State verification.

📋 SLA Guarantee: 99.999% uptime. 100% of requests return 418.

1. Zero coffee brewed.
2. Zero exceptions.
3. Zero usefulness.

🐳 Fully Containerized: Docker image running as a non-root teapot user.
🔄 CI/CD Pipeline: Includes a status code audit step that fails the build if any non-418 response is detected in the codebase.
🗄️ PostgreSQL Archive: Every 418 ever served is stored for eternity. The table has a CHECK constraint ensuring only 418s can be inserted.
⚡ Redis Cache: Cached 418s. Because sub-millisecond teapot responses matter.

The Anti-Value Proposition:

Metric	Value
Monthly Cloud Bill	~\$25
Status Codes Returned	1
Real-World Problems Solved	0
Services Deployed	5+
Lines of Code	1000+
Regrets	0

Endpoints (They All Return 418):

Endpoint	Purpose	Status Code
`ANY /brew`	Attempt to brew coffee	418
`GET /health`	Health check	418
`GET /sla`	SLA information	418
`GET /api/stats`	Teapot metrics	418
`GET /api/wisdom`	AI-generated wisdom	418
`GET /api/status`	AI-generated status update	418
`GET /api/incidents`	Recent incident reports	418
`GET /api`	API documentation	418
`ANY /*`	Literally anything else	418

Yes, even the health check returns 418. A healthy teapot returns 418. That's just science.

Demo

🔗 Live on Google Cloud Run: TaaS Dashboard

Try it yourself:

# The main event
curl -i https://taas-core-791190606725.africa-south1.run.app/brew

# AI-generated teapot wisdom
curl https://taas-core-791190606725.africa-south1.run.app/api/wisdom

# Check the SLA (spoiler: it's 100%)
curl https://taas-core-791190606725.africa-south1.run.app/sla

# Try to find a page that doesn't return 418 (you can't)
curl https://taas-core-791190606725.africa-south1.run.app/please/give/me/a/200

Sample Response

{
  "status": 418,
  "message": "I'm a teapot",
  "RFC": "RFC 2324",
  "protocol": "HTCPCP/1.0",
  "traceId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "responseTimeMs": 3,
  "infrastructure": {
    "platform": "Google Cloud Run",
    "overkillLevel": "Maximum",
    "servicesInvolved": [
      "Cloud Run",
      "Cloud SQL (PostgreSQL)",
      "Memorystore (Redis)",
      "Gemini API",
      "Secret Manager",
      "Artifact Registry",
      "Cloud Build",
      "Cloud Monitoring"
    ],
    "costToReturnThisNumber": "~\$0.0001 per request"
  },
  "teapotMetadata": {
    "material": "Cloud-native ceramic",
    "capacity": "∞ requests/sec (all return 418)",
    "mood": "Serverlessly content 😌",
    "uptime": "2d 14h 23m 7s of uninterrupted 418 service",
    "motto": "Serverless, but never serviceless (of 418s)"
  },
  "incidentReport": "🚨 INCIDENT REPORT #INC-418-7842\nSeverity: CRITICAL\n\nAt 14:32 UTC, an unauthorized coffee brewing attempt was detected via GET request. The TaaS platform immediately engaged RFC 2324 defense protocols. The teapot's dignity was momentarily threatened but ultimately preserved. A 418 response was deployed in 3ms, neutralizing the threat. We will not yield. We are a teapot. 🫖"
}

AI-Powered Teapot Wisdom

{
  "wisdom": "The profound truth of a 418 isn't in refusal, but in self-aware declaration: knowing what you are, and what you aren't, is the most stable configuration.",
  "statusCode": 418,
  "source": "Gemini-powered teapot philosopher"
}

Code

Ntombizakhona / taas

🫖 TaaS: 418-as-a-Service

Enterprise-grade, cloud-native, AI-powered HTTP 418 delivery platform.

Because returning one status code deserves Google Cloud infrastructure, Terraform, CI/CD, monitoring, and a Gemini-powered AI incident reporter.

What is this?

TaaS is a fully over-engineered enterprise platform that does exactly one thing: return HTTP status code 418 I'm a Teapot.

Every request. Every endpoint. Every time. 418.

curl -i https://your-teapot.run.app/brew
# HTTP/2 418
# {"status": 418, "message": "I'm a teapot", ...}

Why?

Because RFC 2324 defined the Hyper Text Coffee Pot Control Protocol, and when someone asks a teapot to brew coffee, the correct response is 418 I'm a Teapot.

We just added:

☁️ Google Cloud Run (serverless teapot hosting)
🤖 Gemini AI (dramatic incident reports & philosophical wisdom)
🐘 Cloud SQL PostgreSQL (eternal 418 archive)
🔴 Memorystore Redis (sub-millisecond 418 cache)
🏗️ Terraform IaC (infrastructure-as-code for a teapot)
🔄 CI/CD Pipeline (with teapot identity verification step)
…

View on GitHub

Architecture

                    ┌──────────────────┐
                    │   The Internet   │
                    └────────┬─────────┘
                             │
                    ┌────────▼─────────┐
                    │  Google Cloud Run│
                    │  (africa-south1) │
                    │  Port 4018       │
                    └────────┬─────────┘
                             │
               ┌─────────────┼──────────────┐
               │             │              │
        ┌──────▼──────┐ ┌───▼─────┐ ┌──────▼───────┐
        │  Cloud SQL  │ │ Memory  │ │  Gemini API  │
        │ (PostgreSQL)│ │ Store   │ │  (Incident   │
        │  Eternal    │ │ (Redis) │ │   Reports &  │
        │  418 Archive│ │ Cached  │ │   Wisdom)    │
        │             │ │ 418s    │ │              │
        └─────────────┘ └─────────┘ └──────────────┘

Highlights from the codebase:

The Core 418 Engine™

Months Of Engineering Led To This:

res.status(418).json({
  status: 418,
  message: "I'm a teapot"
});

The Database Constraint

Ensuring Data Integrity

CREATE TABLE teapot_requests (
    id SERIAL PRIMARY KEY,
    status_code INTEGER DEFAULT 418 CHECK (status_code = 418)
    -- Yes, there's a CHECK constraint ensuring only 418s are stored
);

The Teapot Validator

Four Layers of Identity Verification

async function validateTeapotStatus() {
  const checks = await Promise.all([
    validatePhysicalProperties(),      // Has spout? Has handle?
    validatePhilosophicalStatus(),     // Cogito ergo teapot
    validateRFCCompliance(),           // RFC 2324 compliant?
    validateQuantumTeapotState()       // Schrödinger's teapot resolved
  ]);
  return { isTeapot: checks.every(c => c.passed) };
}

The CI/CD Pipeline

Failing Builds That Dare Return 200

- name: Check for unauthorized status codes
  run: |
    if grep -r "status(200)" --include="*.js" .; then
      echo "❌ VIOLATION: Found a 200 status code!"
      echo "This is a teapot. We only serve 418."
      exit 1
    fi

How I Built It

The Stack:

Layer	Technology
Runtime	Node.js + Express
AI	Google Gemini API (gemini-2.5-flash)
Hosting	Google Cloud Run (africa-south1)
Database	Cloud SQL (PostgreSQL)
Cache	Memorystore (Redis)
Containers	Docker
CI/CD	Cloud Build + GitHub Actions
Frontend	React + Vite + Tailwind
Tooling	Google AntiGravity

The Google AntiGravity And Claude Opus Experience

I scaffolded this entire project using Google's AntiGravity powered by Claude Opus in about 15 minutes. From Architecture Design to Cloud Run deployment, the entire enterprise teapot platform was generated, refined, and shipped with AI Assistance and Human Guidance. A Teapot did not build this, I promise...

The irony isn't lost on me: I used one of the most advanced AI systems in the world to build something that returns one number.
Peak 2026 energy.

The Google Cloud Experience:

Deploying to Cloud Run in the africa-south1 region was seamless. Two commands and our teapot was live on the internet, backed by Google's global infrastructure, auto-scaling from 0 to 10 instances based on coffee-brewing demand.

The Gemini API (gemini-2.5-flash) integration is the heart of TaaS's personality. Every time someone hits /brew, Gemini generates a dramatic, corporate-style incident report about the attempted RFC 2324 violation. Hit /api/wisdom and get AI-generated philosophical quotes about teapot existence.

Cloud SQL stores every 418 ever served with a database constraint that physically prevents any other status code from being recorded.

Memorystore Redis caches recent 418s for real-time dashboard updates.

Google Cloud Cost Breakdown:

Service	Monthly Cost	Necessity
Cloud Run	~\$0-5	None
Cloud SQL	~\$7-10	None
Memorystore	~\$5-7	None
Gemini API	~\$0-2	None
Total	~\$15-25	Absolutely none

\$25/month. To return one number. From Africa.

Prize Category

🫖 Best Ode to Larry Masinter

This entire project is a monument to RFC 2324 and the HTCPCP protocol. Larry Masinter gave us HTTP 418 as an April Fools' joke in 1998, and 28 years later, I gave it an enterprise cloud platform it never asked for.

How TaaS Honors The Legacy:

1. The entire platform exists solely to return 418
2. Every endpoint including health checks, documentation, and SLA returns 418
3. The database has a CHECK constraint preventing any non-418 from being stored
4. The CI/CD pipeline fails the build if any non-418 status code is found in the codebase
5. AI generates dramatic incident reports when someone violates RFC 2324
6. The server runs teapot identity verification on every request across four dimensions: physical, philosophical, RFC compliance, and quantum state
7. The server port is 4018 (4-018, get it?)
8. The version number is 4.1.8
9. The VPC subnet CIDR is 10.4.18.0/24
10. The database backup time is 04:18 AM

If this isn't an ode to Larry Masinter, I don't know what is.

🤖 Best Google AI Usage

TaaS is built on and deployed across multiple Google Cloud products:

Google Cloud Run: (africa-south1) Hosts the teapot
Gemini API: (gemini-2.5-flash) Powers AI incident reports, teapot wisdom, and status updates
Google AntiGravity" (Powered by Claude Opus) Used to build the entire project in minutes
Cloud SQL: PostgreSQL for eternal 418 storage
Memorystore: Redis for cached 418s
Cloud Build: CI/CD pipeline
Artifact Registry: Docker image storage
Secret Manager: Secure API key storage

The Gemini integration is the heart of TaaS's personality. Without it, we'd just be returning 418. With it, we're returning 418 with dramatic flair, philosophical depth, and enterprise-grade incident documentation.

🏆 Community Favorite

Developers love two things: over-engineering and self-aware humor. TaaS is both, deployed on real cloud infrastructure, burning real money, solving zero real problems.

Monthly cloud bill: \$25
Status codes returned: 1
Infrastructure services used: 9
Lines of code: 1000+
Real-world value: \$0.00
Fun had: Priceless

Built with ☁️ Google Cloud Run (africa-south1) | 🤖 Gemini 2.5 API | 🫖 RFC 2324 Compliance | 🚀 Google AntiGravity Powered by Claude Opus

"We do one thing, and we do it with unnecessary complexity." - TaaS (418-as-a-Service)

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

Scaling And Optimization

1. EC2 Auto Scaling

2. EC2 Hibernation

3. EC2 instance types

4. Burstable instances

5. Compute Optimizer

Load Balancing

1. Application Load Balancer

2. Network Load Balancer

3. Gateway Load Balancer

Edge And Hybrid Compute

1. CloudFront Functions

2. Lambda@Edge

3. AWS Outposts

4. AWS Snowball Edge And Snow Family

🚀

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)