DEV Community: Ntombizakhona Mabaso

Use Data Stores In Application Development | 🏗️ Build A Product Catalog API

Ntombizakhona Mabaso — Tue, 12 May 2026 20:45:57 +0000

Exam Guide: Developer - Associate
🏗️ Domain 1: Development with AWS Services
📘 Task 3: Use Data Stores In Application Development

DynamoDB dominates this task. The need to understand table design, key selection, indexing, consistency models, and how to write efficient queries is essential. As well as caching with ElastiCache and DAX. Plus specialized stores like OpenSearch.

📘 Concepts

DynamoDB Key Concepts

Primary Keys

Every table needs one. Two options:

Simple primary key: Partition key only (PK). Each item has a unique PK.
Composite primary key: Partition key (PK) + Sort key (SK). Multiple items can share a PK if they have different SKs.

Partition Key Selection

The partition key determines which physical partition stores your data. A good partition key has high cardinality which refers to many distinct values so that the data spreads evenly.

Good Partition Keys	Bad Partition Keys
userId, orderId, sessionId	status ("active"/"inactive")
deviceId, transactionId	country (few values, uneven distribution)
email, accountId	date (hot partition for today)

Consistency Models

Model	Behaviour	Cost	Available On
Eventually Consistent	May return stale data (usually consistent within 1 second)	1x read capacity	Base table + GSIs
Strongly Consistent	Always returns the most up-to-date data	2x read capacity	Base table only (NOT GSIs)

Query vs Scan

Operation	How It Works	Cost	When to Use
Query	Finds items by partition key + optional sort key condition	Reads only matching items	Always prefer this
Scan	Reads every item in the table	Reads entire table	Analytics, one-time migrations only
GetItem	Fetches one item by its full primary key	Reads exactly one item	When you know the exact key

FilterExpression does NOT reduce the amount of data read. It only filters what's returned to you. You still pay for the full scan/query. To reduce reads, use better key design or GSIs.

Global Secondary Index (GSI) vs Local Secondary Index (LSI)

Feature	GSI	LSI
Partition Key	Different from base table	Same as base table
Sort Key	Different from base table	Different from base table
When To Create	Anytime	At table creation only
Throughput	Has its own (separate from base table)	Shares with base table
Consistency	Eventually consistent only	Supports strongly consistent
Limit	20 per table	5 per table

GSI Projection Types:

ALL: all attributes (most flexible, most storage cost)
KEYS_ONLY: only key attributes (cheapest)
INCLUDE: keys + specified attributes (balanced)

Caching Options

Service	Use Case	Latency	Works With
DAX	DynamoDB read cache	Microseconds	DynamoDB only, eventually consistent only
ElastiCache Redis	General-purpose cache	Sub-millisecond	Any data source, complex data types, persistence
ElastiCache Memcached	Simple caching	Sub-millisecond	Any data source, multi-threaded, no persistence

Specialized Data Stores

Store	Use Case
DynamoDB	Key-value lookups, known access patterns, serverless
RDS/Aurora	Relational data, complex joins, ACID transactions
OpenSearch	Full-text search, log analytics, complex queries
S3	Object storage, data lake, large files
ElastiCache	Session storage, leaderboards, real-time analytics

Data Lifecycle

DynamoDB TTL

Automatically deletes expired items at no cost. Eventually consistent (up to 48 hours delay).

S3 Lifecycle Policies

Transition objects between storage classes (Standard → IA → Glacier) or expire them after a set time.

🏗️ Build A Product Catalog API

Now let's put these concepts into practice by builidng a Product Catalog API backed by DynamoDB:

A DynamoDB table with a composite primary key and a Global Secondary Index (GSI)
A Lambda function that performs queries, scans, and writes
TTL configured for automatic data expiration
DAX caching in front of DynamoDB
A clear understanding of when to use query vs scan, GSI vs LSI, and strong vs eventual consistency

Prerequisites

An AWS account (free tier covers DynamoDB and Lambda)

Part I

Design the DynamoDB Table

Before creating anything, let's think about access patterns. This is the most important step in DynamoDB design.

Our Access Patterns

Access Pattern	How We'll Query
Get a product by ID	Query PK = `PRODUCT#123`
List all products in a category	Query PK = `CATEGORY#electronics`
Get a product's reviews	Query PK = `PRODUCT#123`, SK begins_with `REVIEW#`
Find products by price range in a category	Query GSI with category + price
List recently added products	Query GSI with status + createdAt

Create the Table

Step 01: Open the DynamoDB console

Step 02: Click Create table

Table name: ProductCatalog
Partition key: PK (String)
Sort key — optional: SK (String)

Step 03: Under Table settings, choose Customize settings

Step 04: Read/write capacity settings: On-demand

⚠️ Don't create the just table yet, let's add a GSI first

Add a Global Secondary Index

Step 05: Scroll down to Secondary indexes → click Create global index:

Index name: GSI1
Partition key: GSI1PK (String)
Sort key: GSI1SK (String)
Attribute projections: All

Click Create index, then click Create table.

✅Green banner: The ProductCatalog table was created successfully.

Why This Design?

We're using the single-table design pattern with overloaded keys:

Base table:
  PK = "PRODUCT#laptop-001"    SK = "METADATA"           → product details
  PK = "PRODUCT#laptop-001"    SK = "REVIEW#2026-04-24"  → a review
  PK = "CATEGORY#electronics"  SK = "PRODUCT#laptop-001" → category listing

GSI1:
  GSI1PK = "CATEGORY#electronics"  GSI1SK = "PRICE#00079.99" → find by price
  GSI1PK = "STATUS#active"         GSI1SK = "2026-04-24"     → find by date

Partition Key Selection: A good partition key has high cardinality (many distinct values). Bad examples: status (only a few values → hot partition), country (uneven distribution). Good examples: userId, productId, orderId.

Part II

Add Sample Data

Using the Console

Step 01: In the DynamoDB console, click on ProductCatalog

Step 02: Click Explore table items

Step 03: Click Create item
Switch to JSON view (toggle at the top)
Paste this item:

{
  "PK": {"S": "PRODUCT#laptop-001"},
  "SK": {"S": "METADATA"},
  "GSI1PK": {"S": "CATEGORY#electronics"},
  "GSI1SK": {"S": "PRICE#00999.99"},
  "name": {"S": "Pro Laptop 15"},
  "description": {"S": "15-inch laptop with 16GB RAM"},
  "price": {"N": "999.99"},
  "category": {"S": "electronics"},
  "status": {"S": "active"},
  "createdAt": {"S": "2026-04-20T10:00:00Z"},
  "stock": {"N": "50"}
}

Step 04: Click Create item

Add a few more products:

{
  "PK": {"S": "PRODUCT#mouse-002"},
  "SK": {"S": "METADATA"},
  "GSI1PK": {"S": "CATEGORY#electronics"},
  "GSI1SK": {"S": "PRICE#00029.99"},
  "name": {"S": "Wireless Mouse"},
  "description": {"S": "Ergonomic wireless mouse"},
  "price": {"N": "29.99"},
  "category": {"S": "electronics"},
  "status": {"S": "active"},
  "createdAt": {"S": "2026-04-22T10:00:00Z"},
  "stock": {"N": "200"}
}

{
  "PK": {"S": "PRODUCT#laptop-001"},
  "SK": {"S": "REVIEW#2026-04-24#user-001"},
  "rating": {"N": "5"},
  "comment": {"S": "Great laptop, fast and reliable"},
  "userId": {"S": "user-001"},
  "createdAt": {"S": "2026-04-24T14:30:00Z"}
}

{
  "PK": {"S": "CATEGORY#electronics"},
  "SK": {"S": "PRODUCT#laptop-001"},
  "name": {"S": "Pro Laptop 15"},
  "price": {"N": "999.99"}
}

{
  "PK": {"S": "CATEGORY#electronics"},
  "SK": {"S": "PRODUCT#mouse-002"},
  "name": {"S": "Wireless Mouse"},
  "price": {"N": "29.99"}
}

Part III

Query vs Scan

Query (Efficient)

Step 01: In the ▼ Scan or query items tab, switch from Scan to Query

Step 02: Set:

Partition key Value: PRODUCT#laptop-001
Sort key Value: Begins with ▼ REVIEW Click Run

✅Green banner: Completed · Items returned: 1 · Items scanned: 1 · Efficiency: 100% · RCUs consumed: 0.5

You'll see only the review items for that product. DynamoDB read exactly the items you asked for. Efficient.

Scan (Expensive)

Step 03: Switch back to Scan
Click Run with no filters

✅Green banner: Completed · Items returned: 5 · Items scanned: 5 · Efficiency: 100% · RCUs consumed: 2

You'll see ALL items in the table. DynamoDB read every single item. On a table with millions of items. This is slow and expensive.

Step 04: Click Add filter

Attribute name: category
Type: String
Condition: Equal to
Value: electronics Click Run

✅Green banner: Completed · Items returned: 2 · Items scanned: 5 · Efficiency: 40% · RCUs consumed: 2

You'll see only electronics items, but DynamoDB still read the entire table and filtered afterward. The filter doesn't reduce the read cost.

💡 FilterExpression does NOT reduce the amount of data read. It only filters what's returned to you. You still pay for the full scan. To reduce reads, use better key design or GSIs.

Query the GSI

Step 05: Switch to Query

Step 06: Change the Index dropdown to GSI1

Partition key (GSI1PK) Value: CATEGORY#electronics
Sort key (GSI1SK) Value: Begins with ▼ PRICE# Click Run

✅Green banner:: Completed · Items returned: 2 · Items scanned: 2 · Efficiency: 100% · RCUs consumed: 0.5

This efficiently finds all electronics products, sorted by price. That's the power of a well-designed GSI.

Part IV

Build the API with Lambda

Create the Lambda Function

Step 01: Open the Lambda console → Create function

Function name: ProductCatalogAPI
Runtime: Python 3.12 Click Create function

✅Green banner:: Successfully created the function "ProductCatalogAPI".

Step 02: Configuration → *General configuration → click Edit

Memory: 256 MB
Timeout: 10 seconds Click Save

Step 03:Add DynamoDB Permissions
Configuration → Permissions → click the role name
Add permissions → Attach policies
Search for and attach AmazonDynamoDBFullAccess

⚠️ In production, scope this down to only the ProductCatalog table. For this tutorial, full access keeps things simple. Brevity.

Step 04: Write the Function Code

import json
import boto3
from decimal import Decimal
from boto3.dynamodb.conditions import Key, Attr

# Initialize OUTSIDE the handler — reused across warm invocations
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('ProductCatalog')

class DecimalEncoder(json.JSONEncoder):
    """DynamoDB returns Decimal types — this converts them to float for JSON."""
    def default(self, obj):
        if isinstance(obj, Decimal):
            return float(obj)
        return super().default(obj)

def lambda_handler(event, context):
    """
    Routes requests based on the HTTP method and path.
    Demonstrates query, scan, get_item, and put_item operations.
    """
    http_method = event.get('httpMethod', 'GET')
    path = event.get('path', '/')
    path_params = event.get('pathParameters') or {}
    query_params = event.get('queryStringParameters') or {}

    try:
        if path == '/products' and http_method == 'GET':
            return list_products(query_params)

        elif path.startswith('/products/') and http_method == 'GET':
            product_id = path_params.get('productId', path.split('/')[-1])
            return get_product(product_id)

        elif path == '/products' and http_method == 'POST':
            body = json.loads(event.get('body', '{}'))
            return create_product(body)

        elif path.startswith('/products/') and path.endswith('/reviews'):
            product_id = path_params.get('productId', path.split('/')[2])
            return get_reviews(product_id)

        else:
            return response(404, {'error': 'Not found'})

    except Exception as e:
        print(f"Error: {str(e)}")
        return response(500, {'error': 'Internal server error'})


def list_products(query_params):
    """
    List products by category using QUERY (efficient).
    Falls back to SCAN if no category is specified (expensive — avoid in production).
    """
    category = query_params.get('category')

    if category:
        # QUERY — efficient, reads only matching items
        print(f"Querying products in category: {category}")
        result = table.query(
            KeyConditionExpression=Key('PK').eq(f'CATEGORY#{category}')
        )
    else:
        # SCAN — reads entire table, expensive!
        # In production, require a category or use pagination
        print("WARNING: Scanning entire table — this is expensive!")
        result = table.scan(
            FilterExpression=Attr('SK').eq('METADATA')
        )

    return response(200, {
        'products': result['Items'],
        'count': result['Count'],
        'scannedCount': result['ScannedCount']  # Shows the difference between query and scan
    })


def get_product(product_id):
    """
    Get a single product by ID using GET_ITEM.
    This is the most efficient read — directly accesses one item by its full key.
    """
    result = table.get_item(
        Key={
            'PK': f'PRODUCT#{product_id}',
            'SK': 'METADATA'
        },
        # ConsistentRead=True  # Uncomment for strongly consistent read (2x cost)
    )

    item = result.get('Item')
    if not item:
        return response(404, {'error': f'Product {product_id} not found'})

    return response(200, item)


def get_reviews(product_id):
    """
    Get all reviews for a product using QUERY with sort key condition.
    begins_with on the sort key efficiently finds all reviews.
    """
    result = table.query(
        KeyConditionExpression=(
            Key('PK').eq(f'PRODUCT#{product_id}') &
            Key('SK').begins_with('REVIEW#')
        ),
        ScanIndexForward=False  # Sort descending (newest first)
    )

    return response(200, {
        'productId': product_id,
        'reviews': result['Items'],
        'count': result['Count']
    })


def create_product(body):
    """
    Create a new product using PUT_ITEM.
    Also creates the category listing item for efficient category queries.
    """
    product_id = body['productId']
    category = body['category']
    price = Decimal(str(body['price']))  # DynamoDB requires Decimal, not float!

    # Write the product metadata
    table.put_item(Item={
        'PK': f'PRODUCT#{product_id}',
        'SK': 'METADATA',
        'GSI1PK': f'CATEGORY#{category}',
        'GSI1SK': f'PRICE#{price:010.2f}',  # Zero-padded for correct sort order
        'name': body['name'],
        'description': body.get('description', ''),
        'price': price,
        'category': category,
        'status': 'active',
        'stock': body.get('stock', 0)
    })

    # Write the category listing (denormalization for efficient queries)
    table.put_item(Item={
        'PK': f'CATEGORY#{category}',
        'SK': f'PRODUCT#{product_id}',
        'name': body['name'],
        'price': price
    })

    return response(201, {'message': 'Product created', 'productId': product_id})


def response(status_code, body):
    return {
        'statusCode': status_code,
        'headers': {'Content-Type': 'application/json'},
        'body': json.dumps(body, cls=DecimalEncoder)
    }

Step 05: Click Deploy

✅Green banner: Successfully updated the function "ProductCatalogAPI".

Notice Decimal(str(body['price'])). DynamoDB does NOT support Python float. You must use Decimal. This is a common gotcha.

Step 06: Test The Function
Click the Test tab
Create test events for each operation:

List products by category:

{
  "httpMethod": "GET",
  "path": "/products",
  "queryStringParameters": {"category": "electronics"},
  "pathParameters": null
}

Get a single product:

{
  "httpMethod": "GET",
  "path": "/products/laptop-001",
  "pathParameters": {"productId": "laptop-001"},
  "queryStringParameters": null
}

Get reviews:

{
  "httpMethod": "GET",
  "path": "/products/laptop-001/reviews",
  "pathParameters": {"productId": "laptop-001"},
  "queryStringParameters": null
}

Create a product:

{
  "httpMethod": "POST",
  "path": "/products",
  "body": "{\"productId\":\"keyboard-003\",\"name\":\"Mechanical Keyboard\",\"category\":\"electronics\",\"price\":89.99,\"stock\":100}",
  "pathParameters": null,
  "queryStringParameters": null
}

💡 Run each test and check the results. Look at the count vs scannedCount in the list response. When using query, they'll be equal. When scanning, scannedCount will be higher.

Part V

Consistency Models

See the Difference

Step 01: In the Lambda function, find the get_product function
Uncomment the ConsistentRead=True line
Deploy

✅Green banner: Successfully updated the function "ProductCatalogAPI".

Now get_product uses strongly consistent reads:

Always returns the latest data

Costs 2x the read capacity

Only works on the base table (not GSIs)

💡 GSIs only support eventually consistent reads.

When to Use Each

Use Case	Consistency	Why
Product catalog browsing	Eventually consistent	Stale data for a second is fine
Shopping cart	Strongly consistent	User expects to see what they just added
Inventory check before purchase	Strongly consistent	Must be accurate to avoid overselling
Analytics dashboard	Eventually consistent	Slight delay is acceptable

Part VI

TTL: Automatic Data Expiration

Enable TTL

Step 01: In the DynamoDB console, click on ProductCatalog

Step 02: Click ▼ Actions
Click Turn on TTL

Step 03: Turn on Time to Live (TTL)
TTL attribute name: ttl
Click Turn on TTL

✅Green banner: Successfully activated Time to Live for the ProductCatalog table with the ttl attribute.

Step 04: Add Items with TTL

Create an item with a TTL value (Unix epoch timestamp):

{
  "PK": {"S": "SESSION#user-001"},
  "SK": {"S": "DATA"},
  "userId": {"S": "user-001"},
  "cartItems": {"L": [{"S": "laptop-001"}, {"S": "mouse-002"}]},
  "ttl": {"N": "1745625600"}
}

The ttl value is a Unix timestamp. Items are deleted after this time. Use an epoch converter to set a time a few minutes in the future for testing.

💡 TTL deletion is eventually consistent: items may persist for up to 48 hours after expiration. Don't rely on TTL for exact timing. Always filter out expired items in your queries as a safety measure.

Part VII

Caching with DAX

DAX (DynamoDB Accelerator) is an in-memory cache that sits in front of DynamoDB. It's a drop-in replacement. Same API, just change the client endpoint.

When to Use DAX

Scenario	Use DAX?
Read-heavy workload, same items queried repeatedly	Yes
Microsecond response times needed	Yes
Write-heavy workload	No (DAX is a read cache)
Need strongly consistent reads	No (DAX returns eventually consistent)
Diverse access patterns, rarely same item twice	No (low cache hit rate)

How DAX Works

Without DAX:
  App → DynamoDB (single-digit millisecond reads)

With DAX:
  App → DAX (microsecond reads if cached) → DynamoDB (on cache miss)

Console Walkthrough (Don't Create.Just Understand)

💸 DAX requires a VPC and costs money even when idle. We'll walk through the setup without creating it.

Step 01: Click ▼ DAX

Step 02: Click Create cluster

Cluster name: product-cache
Node type family: t-type family
Node type: dax.t3.small
Cluster size: 3 nodes (for high availability) Click Next

Step 03: Configure networks

Network Type: IPv4
Subnet group: Create new
Subnet group name: MySubnetGroup
VPC ID: defaultVPC
Subnets: Select all
Security group: default ▼ Click View in EC2 console

Step 04: Allow port 8111 from your Lambda functions

✅Green banner: Inbound security group rules successfully modified on security group

Step 05: Configure Security

IAM Service role for DynamoDB access: Create new
IAM role name: DaxToDynamoDB Click Next → Click Next → Click Create cluster

✅Green banner: Successfully created the cluster product-cache.

Step 06: In your Lambda code, you'd change one line:

# Without DAX
dynamodb = boto3.resource('dynamodb')

# With DAX — same API, just different endpoint
import amazondax
dax_client = amazondax.AmazonDaxClient(
    endpoints=['product-cache.abc123.dax-clusters.us-east-1.amazonaws.com:8111']
)
table = dax_client.Table('ProductCatalog')
# All your existing code works unchanged!

DAX is a drop-in replacement for DynamoDB reads. Same API, same code. Just change the client. 💡 But remember: DAX only supports eventually consistent reads and is for read-heavy workloads.

🏗️ What You Built | 📘Exam Concepts Recap

What You Did	Exam Concept
Designed a table around access patterns first	Access-pattern-driven DynamoDB design
Created a composite primary key (PK + SK)	Single-table design, sort key relationships
Added a Global Secondary Index with different keys	GSI for alternate access patterns
Used overloaded keys (`PRODUCT#`, `CATEGORY#`, `REVIEW#`)	Single-table design pattern
Queried by partition key with `begins_with` on sort key	Efficient query operations
Ran a scan and compared `Count` vs `ScannedCount`	Scan is expensive: it reads the entire table
Added a `FilterExpression` to a scan	Filters run AFTER reading: don't save capacity
Used `Decimal(str(price))` instead of `float`	DynamoDB type system: no float support
Toggled `ConsistentRead=True` on `get_item`	Strongly vs eventually consistent reads
Noted GSIs only support eventual consistency	GSI limitations
Enabled TTL on a `ttl` attribute	Automatic data lifecycle management
Walked through DAX setup	Read caching for DynamoDB, microsecond latency

⚠️ Clean Up Protocol

1. DynamoDB → Delete the ProductCatalog table
2. Lambda → Delete ProductCatalogAPI
3. IAM → Delete the Lambda execution role
4. CloudWatch → Delete the log groups

Key Takeaways

Partition key cardinality: high cardinality = even distribution = good performance
Query > Scan: always prefer query. Scan reads the entire table.
FilterExpression doesn't save reads: it filters after reading. Use key design or GSIs instead.
GSIs can be added anytime. LSIs must be created with the table
GSIs are eventually consistent only: no strongly consistent reads on GSIs
Use Decimal, not float for DynamoDB numbers in Python
TTL is free but eventually consistent (up to 48 hours delay)
DAX = DynamoDB read cache (microsecond reads). Same API as DynamoDB.
DAX doesn't support strongly consistent reads
Single-table design with overloaded keys is the recommended DynamoDB pattern

Additional Resources

🏗️

Develop Code for Lambda | 🏗️ Build A Real-Time Data Processing Pipeline

Ntombizakhona Mabaso — Thu, 07 May 2026 20:34:21 +0000

Exam Guide: Developer - Associate
🏗️ Domain 1: Development with AWS Services
📘 Task 2: Develop Code for Lambda

Lambda is the most heavily tested service on the DVA-C02. It is also perhaps, one of the most used and talked about services in general too, well after EC2 and S3. So, you need to know how to configure it, write code for it, handle errors, tune performance, and integrate it with practically every other AWS service.

📘Concepts

Lambda Execution Model

When you invoke a Lambda function, AWS:
1. Finds or creates an execution environment (container)
2. Loads your code and initializes it (cold start)
3. Runs your handler function
4. Keeps the environment warm for reuse (subsequent invocations skip step 2)

Code outside the handler runs once during cold start and is reused. This is why you initialize SDK clients and database connections outside the handler.

Key Configuration Parameters

Parameter	Range	Default	Notes
Memory	128 MB – 10,240 MB	128 MB	CPU scales proportionally with memory
Timeout	1s – 900s (15 min)	3s	Max 15 minutes: use Step Functions or ECS for longer or Durable functions
Concurrency	Reserved or Provisioned	1000/region	Reserved = guarantee + cap; Provisioned = pre-warmed
Ephemeral storage	512 MB – 10,240 MB	512 MB	/tmp directory for temporary files
Layers	Up to 5	—	250 MB total unzipped (function + layers)

Invocation Types and Error Handling

Invocation Type	Source Examples	Retry Behavior	Error Destination
Synchronous	API Gateway, ALB	No automatic retries caller handles it	Caller gets the error
Asynchronous	S3, SNS, EventBridge	2 automatic retries (3 total)	DLQ or Lambda Destinations
Event source mapping	SQS, Kinesis, DynamoDB Streams	Retries until record expires or succeeds	DLQ (SQS) or on-failure destination

Lambda Destinations vs DLQ

Feature	DLQ	Lambda Destinations
Captures success	No	Yes
Captures failure	Yes	Yes
Context included	Minimal	Full (request, response, error)
Supported targets	SQS, SNS	SQS, SNS, Lambda, EventBridge
Works with	Async invocations	Async invocations

Lambda Destinations are the modern approach and preferred over DLQs. DLQs are still valid for SQS event source mappings.

VPC Access

By default, Lambda runs in an AWS-managed VPC and can access the internet and public AWS services. When you attach Lambda to your own VPC:

Without VPC:  Lambda → Internet → AWS Services ✅  |  Lambda → Private RDS ❌
With VPC:     Lambda → Private RDS ✅  |  Lambda → Internet ❌ (needs NAT Gateway)
              Lambda → VPC Endpoint → AWS Services ✅

Key Points:

1. VPC Lambda needs private subnets with a NAT Gateway for internet access
2. Use VPC endpoints (PrivateLink) to access DynamoDB, S3, SQS without NAT
3. Use RDS Proxy for connection pooling because Lambda can overwhelm databases with concurrent connections

Cold Starts

A cold start happens when Lambda creates a new execution environment. Strategies to reduce them:

1. Provisioned Concurrency: pre-warms environments (costs money when idle)
2. Keep deployment packages small: smaller packages initialize faster
3. Initialize outside the handler: SDK clients, DB connections, config
4. Use ARM (Graviton2): often faster and 20% cheaper

Kinesis And Lambda Key Settings

Setting	What It Does	Relevance
Batch size	Records per invocation (max 10,000)	Larger batches = fewer invocations
Batch window	Wait time to fill batch (max 300s)	Reduces invocations for low-traffic streams
Parallelization factor (1–10)	Concurrent batches per shard	Increases throughput without adding shards
Bisect batch on error	Splits batch in half on failure	Isolates the bad record
Starting position	LATEST or TRIM_HORIZON	LATEST = new only. TRIM_HORIZON = from beginning

🏗️ Build A Real Time Data Processing Pipeline

Now let's put these concepts into practice by building a Real-Time Data Processing Pipeline using Lambda:

A Lambda function with VPC access connecting to an RDS database
Lambda layers for shared dependencies
A DLQ (Dead Letter Queue) and Lambda Destinations for error handling
A Kinesis stream processor that transforms data in near real time
Performance tuning with memory configuration

This covers all the skills for this task: Lambda configuration, VPC access, error handling, event lifecycle, integrations, and performance tuning.

Prerequisites

An AWS account (free tier covers most of this)

Part I

Create and Configure a Lambda Function

Create the Function

Step 01: Open the Lambda

Step 02: **Click **Create function

Step 03: Create function
Choose Author from scratch

Function name: DataProcessor
Runtime: Python 3.12

Click Create function

✅Green banner: Successfully created the function "DataProcessor".

Before writing code, let's walk through the configuration tabs.

Step 04: Click the Configuration tab.
General configuration
Click Edit:

Memory: 256 MB (default is 128 MB)
Ephemeral storage: 512 MB (default)
Timeout: 0 min 30 sec (default is 3 seconds)

Click Save.

Lambda allocates CPU proportionally to memory. At 1,769 MB you get one full vCPU. Increasing memory from 128 MB to 256 MB doubles your CPU therefore your function might run in half the time, costing the same or less.

Step 05: Environment variables
Click Environment variables → Edit → Add environment variable:

Key: LOG_LEVEL, Value: INFO
Key: STAGE, Value: dev

Click Save.

✅Green banner: Successfully updated the function "DataProcessor".

import os

# Access environment variables in your code
log_level = os.environ.get('LOG_LEVEL', 'INFO')
stage = os.environ.get('STAGE', 'dev')

Lambda encrypts all environment variables at rest by default using an AWS managed KMS key. For extra security, you can use a customer managed KMS key and decrypt in your code.

Part II

Create a Lambda Layer

Layers let you share code and libraries across multiple functions. Let's create one with a utility module.

Build and Upload a Layer

Layers must be uploaded as a zip file.
We'll use AWS CloudShell: a browser-based terminal built into the AWS Console so that you don't need anything installed locally.

Step 01: Open CloudShell by clicking the terminal icon (>_) in the top navigation bar of the AWS Console next to the search bar

Step 02: Wait for it to initialize as it might take a few seconds the first time

Step 03:
Run these commands:

mkdir -p python
cat > python/utils.py << 'EOF'
"""
Shared utilities for Lambda functions.
This module is packaged as a Lambda Layer so multiple functions can use it.
"""
import json
import time
import random

def retry_with_backoff(func, max_retries=3, base_delay=0.5):
    """Retry with exponential backoff and jitter."""
    for attempt in range(max_retries + 1):
        try:
            return func()
        except Exception as e:
            if attempt == max_retries:
                raise
            delay = base_delay * (2 ** attempt)
            jitter = random.uniform(0, delay)
            time.sleep(delay + jitter)

def format_response(status_code, body):
    """Standard API Gateway response format."""
    return {
        'statusCode': status_code,
        'headers': {'Content-Type': 'application/json'},
        'body': json.dumps(body, default=str)
    }
EOF

zip -r utils-layer.zip python/

Step 04: Download the zip
Click Actions ▼ (top right of CloudShell) → Download file → type utils-layer.zip → click Download

Why the python/ folder? Lambda layers must follow a specific directory structure. For Python, your code must be inside a python/ folder in the zip. Lambda adds this path to sys.path automatically so your functions can import utils directly.

Step 05: Upload the Layer via Console
In the Lambda console, click Layers in the left sidebar

Step 06: Click Create layer

Name: shared-utils
Upload: Choose the utils-layer.zip file
Compatible runtimes - optional: Python 3.12 Click Create

✅Green banner: Successfully created layer shared-utils version 1.

Step 07: Attach the Layer to Your Function
Go back to the DataProcessor function
Scroll down to the Layers section
Click Edit

Step 08: Edit layers
Click Add a layer
Choose Custom layers
Select shared-utils
Version: 1
Click Add

Click Save

✅Green banner: Successfully updated the function "DataProcessor".

Step 09: Now you can use it in your function code:

from utils import format_response, retry_with_backoff

def lambda_handler(event, context):
    return format_response(200, {'message': 'Hello from DataProcessor'})

A function can have up to 5 layers. The total unzipped size of the function + all layers can't exceed 250 MB. Layers are versioned and immutable. Each upload creates a new version.

Part III

Error Handling: DLQ and Lambda Destinations

Create a Dead Letter Queue

Step 01: Open the SQS console

Step 02: Click Create queue

Type: Standard
Name: data-processor-dlq

Click Create queue

✅Green banner: Queue data-processor-dlq created successfully

Step 03: Copy the Queue ARN

Step 04: Create a Success Queue (for Destinations)
Create another queue:

Name: data-processor-success

Copy the Queue ARN

Step 05: Lambda → DataProcessor → Configuration → Permissions → Click the Role name
Add permissions → Attach policies
Search for AmazonSQSFullAccess and attach it

Step 06: Configure the DLQ on the Lambda Function
Go back to the DataProcessor function
Configuration tab → Asynchronous invocation → Edit

Maximum age of event: 1 h 0 min 0 sec
Retry attempts: 2
Dead-letter queue service ▼: Select Amazon SQS
Queue ▼: Select data-processor-dlq

Click Save

✅Green banner: Successfully updated the function "DataProcessor".

Destinations are the modern approach. They capture both success AND failure.

Step 07: Configure Lambda Destinations
Still in Asynchronous invocation, find the Destinations section
Click Add destination

Step 08: Add destination

Source: Asynchronous invocation
Condition: On success
Destination type: SQS queue
Destination: data-processor-success

Click Save

✅Green banner: Your changes have been saved.

Step 09: Click Add destination again

Source: Asynchronous invocation
Condition: On failure
Destination type: SQS queue
Destination: data-processor-dlq

Click Save

✅Green banner: Your changes have been saved.

Lambda Destinations are preferred over DLQs because:

Destinations capture both success and failure (DLQ only captures failure)

Destinations include more context (request payload, response, error details)

Destinations work with async invocations only (same as DLQ)

DLQs are still valid for SQS event source mappings

Test Error Handling

Step 10: Let's create a function that sometimes fails to see the error handling in action:

Deploy this code, then test it

import json
import random

def lambda_handler(event, context):
    """
    This function randomly fails to demonstrate error handling.
    When invoked asynchronously:
    1. First attempt fails → Lambda retries
    2. Second attempt fails → Lambda retries again
    3. Third attempt fails → Event goes to DLQ / failure destination
    """
    action = event.get('action', 'process')

    if action == 'fail':
        # Always fail — will end up in DLQ after 3 attempts
        raise Exception("Simulated failure for testing DLQ")

    if action == 'random':
        # 50% chance of failure
        if random.random() < 0.5:
            raise Exception("Random failure occurred")

    return {
        'statusCode': 200,
        'body': json.dumps({'message': 'Processed successfully', 'action': action})
    }

Step 11: Click Test tab

Step 12: Test event

Test event action: Create new event
Invocation type: Synchronous
Event name: TestFailure
Even JSON:

{
  "action": "fail"
}

Click Test

❌ Executing function: failed

The function will fail. Since this is a synchronous test invocation, you'll see the error immediately. To test the DLQ flow, you need an asynchronous invocation (from S3, SNS, or EventBridge).

Part IV

Lambda with VPC Access

When Lambda needs to access private resources like RDS or ElastiCache, you attach it to a VPC. Let's walk through the configuration.

Understanding VPC Access

Without VPC:
  Lambda → Internet → AWS Services (DynamoDB, S3, SQS)  ✅
  Lambda → Private RDS                                    ❌

With VPC:
  Lambda → VPC → Private RDS                              ✅
  Lambda → VPC → Internet                                 ❌ (no NAT)
  Lambda → VPC → NAT Gateway → Internet                   ✅
  Lambda → VPC → VPC Endpoint → AWS Services              ✅

Configure VPC Access (Console Walkthrough)

Step 01: Open the DataProcessor function
Configuration tab → VPC → Edit

Step 02: Edit VPC
Select the default VPC
Select at least 2 private subnets (for high availability)
Select or create a security group that allows outbound traffic

Click Save

⚠️Important: The Lambda execution role needs the AWSLambdaVPCAccessExecutionRole managed policy.

Step 03: Connection Reuse Pattern

When connecting to databases from Lambda, initialize the connection outside the handler:

import os
import json
import boto3

# This runs ONCE during cold start, then reuses across warm invocations
# This is critical for database connections — you don't want to open
# a new connection on every single invocation
db_host = os.environ.get('DB_HOST')
db_name = os.environ.get('DB_NAME')

# In a real app, you'd initialize your database connection here
# connection = pymysql.connect(host=db_host, ...)

def lambda_handler(event, context):
    """
    The handler runs on every invocation.
    The connection above is reused across warm invocations.
    """
    # Use the connection...
    return {
        'statusCode': 200,
        'body': json.dumps({'message': 'Connected to database'})
    }

Always initialize SDK clients and database connections outside the handler. This code runs once during the cold start and is reused for subsequent warm invocations.
For RDS specifically, use RDS Proxy to manage connection pooling. Lambda can open hundreds of connections simultaneously, which can overwhelm a database.

Part V

Process Streaming Data with Kinesis

Let's build a real-time clickstream processor.

Create a Kinesis Data Stream

Step 01: Open the Kinesis console
Click Create data stream

Data stream name: clickstream
Capacity mode: On-demand

Click Create data stream

✅Green banner: Data stream clickstream successfully created

Step 02: Create the Stream Processor Function
Go to Lambda → Create function
Configure:

Function name: ClickstreamProcessor
Runtime: Python 3.12
Memory: 512 MB
Timeout: 60 seconds

Step 03: Paste this code

import json
import base64
from datetime import datetime

def lambda_handler(event, context):
    """
    Processes clickstream records from Kinesis in near real time.

    Key concepts for the exam:
    - Kinesis data is base64 encoded
    - Records come in batches
    - The partition key determines which shard receives the record
    - Use a high-cardinality partition key (like userId) for even distribution
    """
    processed = 0
    failed = 0

    print(f"Received {len(event['Records'])} records from Kinesis")

    for record in event['Records']:
        try:
            # Kinesis data is base64 encoded — decode it
            raw_data = base64.b64decode(record['kinesis']['data']).decode('utf-8')
            data = json.loads(raw_data)

            # Extract clickstream fields
            user_id = data.get('userId', 'anonymous')
            page = data.get('page', 'unknown')
            action = data.get('action', 'unknown')
            timestamp = data.get('timestamp', datetime.utcnow().isoformat())

            # Process the click event
            print(f"Click: user={user_id}, page={page}, action={action}, time={timestamp}")

            # In a real app, you'd:
            # - Aggregate metrics
            # - Write to DynamoDB or S3
            # - Trigger alerts for specific patterns

            processed += 1

        except Exception as e:
            print(f"Failed to process record: {str(e)}")
            failed += 1

    print(f"Batch complete: {processed} processed, {failed} failed")

    return {
        'statusCode': 200,
        'body': json.dumps({
            'processed': processed,
            'failed': failed
        })
    }

Click Deploy

✅Green banner: Successfully updated the function "ClickstreamProcessor".

Step 04: Add Permissions
The Lambda execution role needs permission to read from Kinesis:
Go to Configuration → Permissions → click the role name
Add permissions → Attach policies
Search for and attach AmazonKinesisReadOnlyAccess

Step 05: Connect Kinesis to Lambda
In the ClickstreamProcessor function, click Add trigger

Step 06: Add trigger
Select a source ▼: Kinesis

Kinesis stream: clickstream
Batch size: 100
Starting position: Latest
Batch window: 5
On-failure destination: ``
Retry attempts: 3
Split batch on error: ✔ enabled
Concurrent batches per shard: 10

Click Add

✅Green banner: The trigger clickstream was successfully added to function ClickstreamProcessor.

Key Kinesis + Lambda settings:

Batch size: how many records per invocation (max 10,000)

Batch window: how long to wait to fill the batch (max 300s)

Parallelization factor: (1–10) process multiple batches per shard concurrently

Bisect batch on error: splits the batch in half on failure to isolate the bad record

Starting position: LATEST (new records only) or TRIM_HORIZON (from the beginning)

Step 07: Test with Sample Data
Send test records to the stream:
Open the Kinesis console → click clickstream

Step 08: clickstream
Click Data viewer tab
Or use the AWS CLI to send test data:

`shell aws kinesis put-record \ --stream-name clickstream \ --partition-key "USER-001" \ --data '{"userId":"USER-001","page":"/products/laptop","action":"view","timestamp":"2026-04-24T10:00:00Z"}' `

Step 09: Check the ClickstreamProcessor CloudWatch logs to see the processed records

Part VI

Performance Tuning

Memory vs Duration Experiment

Let's see how memory affects performance:

Step 01: Open the ClickstreamProcessor function

Step 02: Configuration → General configuration → Edit
Set Memory to 128 MB → Save

Step 03: Run a test → note the Duration and Max Memory Used in the execution results

`json { "Records": [ { "kinesis": { "data": "eyJ1c2VySWQiOiJVU0VSLTAwMSIsInBhZ2UiOiIvcHJvZHVjdHMvbGFwdG9wIiwiYWN0aW9uIjoidmlldyIsInRpbWVzdGFtcCI6IjIwMjYtMDQtMjRUMTA6MDA6MDBaIn0=" }, "eventSource": "aws:kinesis", "eventSourceARN": "arn:aws:kinesis:us-east-1:123456789012:stream/clickstream" }, { "kinesis": { "data": "eyJ1c2VySWQiOiJVU0VSLTAwMiIsInBhZ2UiOiIvY2hlY2tvdXQiLCJhY3Rpb24iOiJjbGljayIsInRpbWVzdGFtcCI6IjIwMjYtMDQtMjRUMTA6MDE6MDBaIn0=" }, "eventSource": "aws:kinesis", "eventSourceARN": "arn:aws:kinesis:us-east-1:123456789012:stream/clickstream" } ] } `

Step 04: Change memory to 256 MB → test again

Step 05: Change to 512 MB → test again

Step 06: Change to 1024 MB → test again

You'll typically see:

Memory	Duration	Billed Duration	Cost per Invocation
128 MB	~200ms	200ms	Low per-ms, but slow
256 MB	~110ms	110ms	Sweet spot for many functions
512 MB	~60ms	60ms	Faster, slightly more per-ms
1024 MB	~55ms	55ms	Diminishing returns

The sweet spot is where increasing memory no longer significantly reduces duration.

Step 07: Concurrency Settings
Configuration → Concurrency and recursion detection
Concurrency→ Edit

Step 08: Edit concurrency

USe unreserved account concurrency: Uses the shared regional pool (default 1000)
Reserve concurrency: Guarantees capacity AND caps the function

Select Reserve concurrency: 50

Click Save

✅Green banner: Your changes have been saved.

This means:

Your function is guaranteed 50 concurrent executions
It can never exceed 50 (acts as a throttle)
The remaining 950 are available for other functions

Reserved concurrency is free and serves two purposes: guaranteeing capacity AND protecting downstream services from being overwhelmed. Provisioned concurrency costs money even when idle but eliminates cold starts.

🏗️ What You Built | 📘Exam Concepts Recap

What You Did	Exam Concept
Created a Lambda function and configured memory/timeout	Lambda configuration parameters
Built and attached a Lambda Layer	Sharing code across functions, layer structure and limits
Set up a DLQ and Lambda Destinations	Async error handling, event lifecycle
Used `--invocation-type Event` to trigger async flow	Synchronous vs asynchronous invocation types
Attached Lambda to a VPC with subnets and security group	VPC access for private resources (RDS, ElastiCache)
Initialized SDK clients outside the handler	Connection reuse, cold start optimization
Created a Kinesis stream and connected it to Lambda	Real-time data processing, event source mappings
Configured batch size, batch window, parallelization factor	Kinesis + Lambda tuning for throughput
Enabled bisect batch on error	Isolating bad records in stream processing
Changed memory settings and compared Duration	Performance tuning, memory = CPU relationship
Set reserved concurrency	Throttling, capacity guarantees, protecting downstream services

⚠️ Clean Up Protocol

1. Lambda → Delete DataProcessor, ClickstreamProcessor
2. Lambda Layers → Delete shared-utils
3. Kinesis → Delete clickstream stream
4. SQS → Delete data-processor-dlq, data-processor-success
5. IAM → Delete the Lambda execution roles
6. CloudWatch → Delete the log groups

Key Takeaways

Memory = CPU: more memory means more CPU. Find the sweet spot where cost and performance balance.
Initialize outside the handler: SDK clients, DB connections, config loading. Reused across warm invocations.
Lambda Destinations > DLQ: Destinations capture success AND failure with more context.
ReportBatchItemFailures for SQS, BisectBatchOnFunctionError for Kinesis to isolate bad records.
VPC Lambda loses internet: needs NAT Gateway or VPC endpoints for AWS services.
RDS Proxy for Lambda-to-RDS: manages connection pooling.
Layers: up to 5 per function, 250 MB total unzipped, versioned and immutable.
15-minute timeout is the max: for longer tasks, use Step Functions or ECS.
Provisioned concurrency: eliminates cold starts but costs money when idle.
Kinesis parallelization factor" (1–10) lets you process multiple batches per shard.

Additional Resources

🏗️

Develop Code for Applications Hosted on AWS | 🏗️ Build An Order Processing System

Ntombizakhona Mabaso — Mon, 04 May 2026 20:51:50 +0000

Exam Guide: Developer - Associate
🏗️ Domain 1: Development with AWS Services
📘 Task 1: Develop Code for Applications Hosted on AWS

This is the broadest task on the exam. It tests whether you can build real applications on AWS. Not just use the console, but write code that interacts with AWS services, write code that handles failures gracefully, and write code that follows modern architectural patterns.

📘Concepts

Architectural Patterns

Event-Driven

Event-Driven Components communicate through events. A producer emits an event, and one or more consumers react to it. There is no direct coupling between the producer and the consumer.
AWS Services:

EventBridge
SNS
SQS
Kinesis

Microservices

In Microservices Architecture, the application is split into small, independently deployable services. Each service owns its data and communicates via APIs or events.

Monolithic

A Monolithic Application is a single deployable unit. Even though it is simpler to start with, it is much harder to scale independently. Knowing when and even how to migrate from Monolithic Applications to Microservices Architecture is a must.

Choreography vs Orchestration

Choreography: Each service knows what to do when it receives an event. No central coordinator. Uses EventBridge or SNS.
Orchestration: A central coordinator such as Step Functions manages the workflow and tells each service what to do.

Fanout

In a Fanout Pattern, one event triggers multiple consumers in parallel whereas the classic pattern consists of an SNS topic with multiple SQS queue subscriptions, or EventBridge with multiple rule targets.

Stateful vs Stateless

Aspect	Stateful	Stateless
Session Data	Stored locally (memory/disk)	Externalized (DynamoDB, ElastiCache)
Scaling	Hard to scale horizontally	Easy to scale horizontally
Failure Impact	Session data lost on crash	No data loss, any instance can serve any request
Lambda	Not possible (ephemeral by design)	Default behavior

Lambda functions are stateless by design. If you need state, externalize it to DynamoDB, ElastiCache, or S3.

Tightly Coupled vs Loosely Coupled

Aspect	Tightly Coupled	Loosely Coupled
Communication	Direct API calls	Queues, events
Failure Impact	Cascading failures	Isolated failures
Scaling	Scale together	Scale independently
AWS Pattern	Synchronous Lambda-to-Lambda	Lambda → SQS → Lambda

If a scenario describes a system where one component's failure brings down others, the answer usually involves adding a queue (SQS) or event bus (EventBridge) between them.

Synchronous vs Asynchronous

Synchronous

Caller waits for a response.
API Gateway → Lambda is synchronous.

Asynchronous

Caller sends a message and moves on.
S3 event → Lambda is asynchronous.
SQS → Lambda is asynchronous.

# Synchronous: Caller Waits
response = lambda_client.invoke(
    FunctionName='my-function',
    InvocationType='RequestResponse'  # synchronous
)

# Asynchronous: Fire & Forget
response = lambda_client.invoke(
    FunctionName='my-function',
    InvocationType='Event'  # asynchronous
)

Messaging Services Comparison

Service	Pattern	Use Case
SQS	Point-to-point queue	Decoupling, one consumer, buffering
SNS	Pub/sub fanout	One message to many subscribers
EventBridge	Event bus with routing	Complex routing, content-based filtering, cross-account
Kinesis	Real-time streaming	High-throughput ordered data (clickstreams, IoT, logs)

SQS long polling (WaitTimeSeconds > 0) reduces empty responses and costs. Always use it.

Resilient Code Patterns

Exponential Backoff with Jitter

When a request to another service fails, retrying immediately often makes things worse.

The Exponential Backoff Algorithm increases the wait time after each failed attempt (for example: 1s → 2s → 4s → 8s). This gives the failing system time to recover instead of being overwhelmed by repeated traffic.

The Jitter adds randomness to the wait time so multiple clients don’t retry at the exact same moment. Without it, many clients can retry together and create a thundering herd problem, overwhelming the service again.

Why Exponential Backoff Matters:

Reduces pressure on struggling services
Improves recovery success rates
Prevents retry storms

Circuit Breaker

A Circuit Breaker protects your application from repeatedly calling a service that is already failing.

After a defined number of consecutive failures (for example, 5 failed requests), the circuit opens and temporarily blocks new requests to that service for a cooldown period.

After the cooldown, the system allows a few test requests (half-open state) to check if the service has recovered:

If successful: the circuit closes and normal traffic resumes
If failures continue:, the circuit stays open

Think of it as failing fast instead of failing repeatedly. A rare act of discipline in software engineering.

Why Circuit Breakers Matter:

Prevents wasted resources
Avoids cascading failures
Helps systems recover faster

Idempotency

An operation is Idempotent if performing it multiple times produces the same result as performing it once.

This is important in distributed systems because retries can happen due to timeouts, network failures, or duplicate messages.

Examples:

Updating a user’s email to the same value multiple times is safe.
Creating the same order multiple times is dangerous unless protected

Idempotency is often implemented using:

1. Unique request IDs

2. Deduplication checks

3. Database constraints

Why Idempotency Matters:

Makes retries safe
Prevents duplicate side effects
Improves consistency in unreliable systems

🏗️ Build An Order Processing System

Now let's put these concepts into practice by building an Order Processing System from scratch using the AWS Console:

An API Gateway REST API that accepts orders
A Lambda function that publishes order events
An EventBridge custom event bus that routes events
Two consumer Lambda functions (order processing + inventory)
An SQS queue for decoupling
Request validation on the API
Error handling with retry logic

This covers the key skills for this task: architectural patterns, loose coupling, event-driven design, APIs, messaging, and resilient code.

Prerequisites

An AWS account (free tier covers everything here)
A Web Browser (we're doing this entirely in the console)
Basic familiarity with Python (we'll use Python 3.12 for Lambda)

Part I

Understanding the Architecture

Before we build, let's understand what we're building and why.

Client (POST /orders)
    │
    ▼
API Gateway (validates request)
    │
    ▼
PublishOrder Lambda (publishes event)
    │
    ▼
EventBridge (custom event bus: "orders")
    │
    ├──► Rule: "OrderPlaced" ──► ProcessOrder Lambda
    │
    └──► Rule: "OrderPlaced" ──► SQS Queue ──► UpdateInventory Lambda

Why This Architecture?

API Gateway validates requests before they reach your code which saves compute costs
EventBridge decouples the publisher from consumers because the publisher doesn't know or care who's listening
SQS between EventBridge and the inventory function adds durability so if inventory processing fails, the message stays in the queue
Each component can scale independently and fail independently

This is a loosely coupled, event-driven, asynchronous architecture

Exam Concepts Demonstrated

Concept	Where You'll See It
Event-Driven Pattern	EventBridge routing events to consumers
Fanout Pattern	One event triggers two different consumers
Loose Coupling	Publisher doesn't know about consumers
Async Processing	EventBridge + SQS = fire and forget
Choreography	Each service reacts to events independently (no central orchestrator)
Request Validation	API Gateway validates before Lambda runs

Part II

Create the EventBridge Custom Event Bus

We start with the event bus because it's the backbone of our system.

Step 01: Open the Amazon EventBridge console

Step 02: In the left sidebar under ▼ Buses, click Event buses

Step 03: Click Create event bus

Step 04: Create event bus
Name: orders
Click Create

✅Green banner: Successfully created event bus orders.

You now have a custom event bus called orders. AWS services publish to the default bus and your application events go to your custom bus.

The default event bus receives events from AWS services (EC2 state changes, etc.). Custom event buses are for your application events. You can have rules on both.

Part III

Create the Order Processing Lambda Functions

We need three Lambda functions. Let's create them one at a time.

Function 1 | Create the PublishOrder Function

This function receives the API request and publishes an event to EventBridge.

Step 01: Open the Lambda console

Step 02: Click Create function

Step 03: Create function

Choose Author from scratch
Function name: PublishOrder
Runtime: Python 3.12

Click Create function

✅Green banner: Successfully created the function "PublishOrder".

Step 04: Paste this code into the code editor:

import json
import boto3
from datetime import datetime
import uuid

eventbridge = boto3.client('events')

def lambda_handler(event, context):
    """
    Receives an order from API Gateway and publishes it to EventBridge.
    This function doesn't process the order — it just routes it.
    That's the event-driven pattern: publish and forget.
    """
    try:
        # Parse the request body from API Gateway
        body = json.loads(event.get('body', '{}'))

        order_id = str(uuid.uuid4())[:8].upper()

        # Publish the event to our custom event bus
        response = eventbridge.put_events(
            Entries=[
                {
                    'Source': 'orders.api',
                    'DetailType': 'OrderPlaced',
                    'Detail': json.dumps({
                        'orderId': f'ORD-{order_id}',
                        'customerId': body['customerId'],
                        'items': body['items'],
                        'timestamp': datetime.utcnow().isoformat()
                    }),
                    'EventBusName': 'orders'
                }
            ]
        )

        # Check if the event was published successfully
        if response['FailedEntryCount'] > 0:
            print(f"Failed to publish event: {response['Entries']}")
            return {
                'statusCode': 500,
                'headers': {'Content-Type': 'application/json'},
                'body': json.dumps({'error': 'Failed to process order'})
            }

        return {
            'statusCode': 202,  # 202 Accepted — order is being processed async
            'headers': {'Content-Type': 'application/json'},
            'body': json.dumps({
                'message': 'Order accepted for processing',
                'orderId': f'ORD-{order_id}'
            })
        }

    except KeyError as e:
        return {
            'statusCode': 400,
            'headers': {'Content-Type': 'application/json'},
            'body': json.dumps({'error': f'Missing required field: {str(e)}'})
        }
    except Exception as e:
        print(f"Unexpected error: {str(e)}")
        return {
            'statusCode': 500,
            'headers': {'Content-Type': 'application/json'},
            'body': json.dumps({'error': 'Internal server error'})
        }

Step 05: Click Deploy

✅Green banner: Successfully updated the function "PublishOrder".

⚠️ Important: This function needs permission to publish to EventBridge. Let's add that:

Step 06: Go to the Configuration tab → Permissions
Click the Role name link (opens IAM in a new tab)

Step 07: PublishOrder-role-nx91xx0d
Click Add permissions ▼ → Attach policies
Search for AmazonEventBridgeFullAccess and attach it
Click Add permissions

✅Green banner: Policy was successfully attached to role

In production, you'd create a scoped policy that only allows events:PutEvents on the orders bus. For this tutorial, the full access policy keeps things simple.

Function 2 | Create the ProcessOrder Function

Step 08: Navigate to **Lambda
Click Create function

Step 09: Create function

Choose Author from scratch
Function name: ProcessOrder
Runtime: Python 3.12 Click Create function

✅Green banner: Successfully created the function "ProcessOrder"

Step 10: Paste this code into the code editor:

import json

def lambda_handler(event, context):
    """
    Processes an order after receiving it from EventBridge.
    In a real app, this would save to a database, charge payment, etc.

    Notice: this function has NO idea who published the event.
    It just reacts to OrderPlaced events. That's loose coupling.
    """
    detail = event.get('detail', {})
    order_id = detail.get('orderId', 'unknown')
    customer_id = detail.get('customerId', 'unknown')
    items = detail.get('items', [])

    print(f"=== Processing Order ===")
    print(f"Order ID: {order_id}")
    print(f"Customer: {customer_id}")
    print(f"Items: {json.dumps(items)}")
    print(f"Total items: {len(items)}")

    # Simulate order processing
    for item in items:
        print(f"  Processing: {item.get('productId')} x {item.get('quantity')}")

    print(f"=== Order {order_id} processed successfully ===")

    return {
        'statusCode': 200,
        'body': json.dumps({'orderId': order_id, 'status': 'processed'})
    }

Step 11: Click Deploy

✅Green banner: Successfully updated the function "ProcessOrder".

Function 3 | Create the UpdateInventory Function

Step 12: Create another function:

Function name: UpdateInventory
Runtime: Python 3.12 ✅Green banner: Successfully created the function "UpdateInventory".

Step 13: Paste this code:

import json

def lambda_handler(event, context):
    """
    Updates inventory based on order events.
    This function receives messages from SQS (not directly from EventBridge).
    The SQS queue adds durability — if this function fails, the message
    stays in the queue and gets retried.

    SQS event structure is different from EventBridge:
    - event['Records'] contains an array of SQS messages
    - Each message body contains the EventBridge event
    """
    batch_failures = []

    for record in event.get('Records', []):
        try:
            # SQS wraps the EventBridge event in the message body
            message_body = json.loads(record['body'])

            # EventBridge puts the actual event data in 'detail'
            detail = message_body.get('detail', {})
            order_id = detail.get('orderId', 'unknown')
            items = detail.get('items', [])

            print(f"=== Updating Inventory for Order {order_id} ===")

            for item in items:
                product_id = item.get('productId', 'unknown')
                quantity = item.get('quantity', 0)
                print(f"  Reducing stock: {product_id} by {quantity} units")

            print(f"=== Inventory updated for {order_id} ===")

        except Exception as e:
            print(f"Failed to process record: {str(e)}")
            # Report this specific message as failed
            # Only this message will be retried, not the whole batch
            batch_failures.append({
                'itemIdentifier': record['messageId']
            })

    # Return partial batch failures so only failed messages retry
    return {'batchItemFailures': batch_failures}

Step 14: Click Deploy

✅Green banner: Successfully updated the function "UpdateInventory".

Notice the batchItemFailures return. This is the **ReportBatchItemFailures pattern. Without it, if one message in a batch of 10 fails, all 10 go back to the queue. With it, only the failed message retries.**

Part IV

Create the SQS Queue

We'll put an SQS queue between EventBridge and the UpdateInventory function. This adds durability so if the function fails, the message stays in the queue.

Step 01: Open the SQS console

Step 02: Click Create queue

Step 03: Create queue

Type: Standard
Name: inventory-updates

Scroll to Access policy

Choose Advanced
Replace the policy with this (update your account ID):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowEventBridge",
      "Effect": "Allow",
      "Principal": {
        "Service": "events.amazonaws.com"
      },
      "Action": "sqs:SendMessage",
      "Resource": "arn:aws:sqs:us-east-1:YOUR_ACCOUNT_ID:inventory-updates"
    }
  ]
}

Replace YOUR_ACCOUNT_ID with your actual AWS account ID and us-east-1 with your region.

Step 04: Click Create queue

✅Green banner: Queue inventory-updates created successfully

Step 05: Copy the Queue ARN. You'll need it for the EventBridge rule

Add SQS Permissions to the UpdateInventory Lambda Role

Before connecting the trigger, the Lambda function needs permission to read from SQS. Without this, you'll get: "The function execution role does not have permissions to call ReceiveMessage on SQS."

Step 06: Go to the Lambda console

Step 07: Open the UpdateInventory function

Step 08 Click the Configuration tab
Select Permissions
Click the Role name link (opens IAM in a new tab)

Step 09: PublishOrder-role-nx91xx0d
Click Add permissions ▼ → Attach policies
Search for AWSLambdaSQSQueueExecutionRole and attach it
Click Add permissions

✅Green banner: Policy was successfully attached to role

This policy grants sqs:ReceiveMessage, sqs:DeleteMessage, and sqs:GetQueueAttributes which is exactly what Lambda needs to poll the queue.

Why does Lambda need these permissions? When you use SQS as a Lambda trigger, Lambda itself polls the queue on your behalf using your function's execution role. It calls ReceiveMessage to get messages, invokes your function, and then calls DeleteMessage after successful processing. Without these permissions, Lambda can't even start polling.

Connect SQS to the UpdateInventory Lambda

Step 10: Go back to the Lambda console

Step 11: Open the UpdateInventory function

Step 12: Click Add trigger

Step 13: Select a source ▼
Select SQS
SQS Queue: inventory-updates
Batch size - optional: 5
Check ✔ Report batch item failures
Click Add
✅Green banner: The trigger inventory-updates was successfully added to function UpdateInventory.

Part V

Create EventBridge Rules

Now we connect everything by creating rules that route events to our consumers.

Rule 1 | Route to ProcessOrder Lambda

Step 01: Open the EventBridge console

Step 02: In the left sidebar under ▼ Buses, Click Rules
Builder mode: Advanced builder

Name: route-to-process-order
Description: Routes OrderPlaced events to the ProcessOrder function
Event bus: orders Click Next

Step 03: Build event pattern
Event source: AWS events or Eventbridge partner events
Event pattern: Custom pattern (JSON editor)

{
  "source": ["orders.api"],
  "detail-type": ["OrderPlaced"]
}

This pattern matches any event where the source is orders.api AND the detail-type is OrderPlaced. EventBridge content-based filtering is powerful — you can match on nested fields, numeric ranges, prefixes, and more.

Click Next

Step 04: Select target(s)
Target types: AWS service
Select a target: Lambda function
Target location: Target in this account
Function: ProcessOrder
Click Next

Step 05: Configure tags - optional
Click Next

Step 06: Review and create
Click Create rule

✅Green banner: Rule route-to-process-order was created successfully

Rule 2 | Route to SQS Queue (for Inventory)

Step 07: Click Create rule again
Builder mode: Advanced builder

Name: route-to-inventory-queue
Description: Routes OrderPlaced events to the inventory SQS queue
Event bus: orders

Click Next

Step 08: Build event pattern
Event source: AWS events or Eventbridge partner events
Event pattern: Custom pattern (JSON editor)

{
  "source": ["orders.api"],
  "detail-type": ["OrderPlaced"]
}

Click Next

Step 09: Select target(s)
Target types: AWS service
Select a target: SQS queue
Target location: Target in this account
Queue: inventory-updates
Click Next

Step 10: Configure tags - optional
Click Next

Step 11: Review and create
Click Create rule

✅Green banner: Rule route-to-inventory-queue was created successfully

You now have the fanout pattern: one event, two consumers, each doing their own thing independently.

Part VI

Create the API Gateway REST API

Create the API

Step 01: Open the API Gateway console

Step 02: Click Create API
Under REST API, click Build

Step 03: Create REST API
Select New API

API name: OrdersAPI
Description: Order processing API
API endpoint type: Regional ▼
Security policy - new: TLS_1_0 Click Create API

✅Green banner: Successfully created REST API 'OrdersAPI (5bmhxxqtp7)'.

Step 04: Create the /orders Resource
Click Create resource
Resource path ▼: /
Resource name: orders
✔ CORS (Cross Origin Resource Sharing)
Click Create resource

✅Green banner: Successfully created resource '/orders'

Step 05: Create the POST Method
Select the /orders resource
Click Create method

Step 06: Create method

Method type: POST ▼
Integration type: Lambda Function
Lambda proxy integration: ✅ enabled
Lambda function: select PublishOrder Click Create method

✅Green banner: Successfully created method 'POST' in 'orders'.

Step 07: Add Request Validation

API Gateway can validate requests before they reach Lambda, saving compute costs.

Step 08: In the left sidebar under API:OrdersAPI ▼, click Models

Step 09: Click Create model

Name: CreateOrderModel
Content type: application/json
Model schema:

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "required": ["customerId", "items"],
  "properties": {
    "customerId": {
      "type": "string",
      "minLength": 1
    },
    "items": {
      "type": "array",
      "minItems": 1,
      "items": {
        "type": "object",
        "required": ["productId", "quantity"],
        "properties": {
          "productId": {
            "type": "string"
          },
          "quantity": {
            "type": "integer",
            "minimum": 1
          }
        }
      }
    }
  }
}

Click Create

✅Green banner: Successfully created model 'CreateOrderModel'.

Step 10: Now attach the validator to the POST method
Go back to Resources → select the POST method under /orders
Click on the Method request tab
Click Edit

Step 11: Edit method request
Authorization: none
Request validator: Validate body
▶ Request body: click Add model

Content type: application/json
Model: CreateOrderModel Click Save

✅Green banner: Successfully edited method request for ‘POST’.

Step 12: Deploy the API
Click Deploy API
Stage: Create a new stage called dev
Click Deploy

✅Green banner: Successfully created deployment for OrdersAPI.

Step 13: Copy the Invoke URL it looks like: https://abc123.execute-api.us-east-1.amazonaws.com/dev

Part VII

Test the Entire Flow

Test 1 | Valid Order

Step 01: Open a terminal (or use an API testing tool like Postman) and send a valid order:

curl -X POST https://YOUR_API_URL/dev/orders \
  -H "Content-Type: application/json" \
  -d '{
    "customerId": "CUST-001",
    "items": [
      {"productId": "LAPTOP-001", "quantity": 1},
      {"productId": "MOUSE-002", "quantity": 2}
    ]
  }'

Expected response:

{
  "message": "Order accepted for processing",
  "orderId": "ORD-A1B2C3D4"
}

Verify The Events Flowed Through:

Step 02: Go to Lambda → ProcessOrder → Monitor tab → View CloudWatch logs → Click on the Log stream
You should see logs like:

   === Processing Order ===
   Order ID: ORD-A1B2C3D4
   Customer: CUST-001
   Items: [{"productId": "LAPTOP-001", "quantity": 1}, ...]
   === Order ORD-A1B2C3D4 processed successfully ===

Step 03: Go to Lambda → UpdateInventory → Monitor tab → View CloudWatch logs → Click on the Log stream
You should see:

   === Updating Inventory for Order ORD-A1B2C3D4 ===
     Reducing stock: LAPTOP-001 by 1 units
     Reducing stock: MOUSE-002 by 2 units
   === Inventory updated for ORD-A1B2C3D4 ===

One API call triggered two independent consumers. That's the fanout pattern in action.

Test 2 | Invalid Request (Missing customerID)

curl -X POST https://YOUR_API_URL/dev/orders \
  -H "Content-Type: application/json" \
  -d '{
    "items": [{"productId": "LAPTOP-001", "quantity": 1}]
  }'

Expected response:

{
  "message": "Invalid request body"
}

API Gateway rejected this request before it reached Lambda.
Your function was never invoked. That's the value of request validation. It saves compute costs and keeps your Lambda code cleaner.

Test 3 | Invalid Request (Missing quantity is 0)

curl -X POST https://YOUR_API_URL/dev/orders \
  -H "Content-Type: application/json" \
  -d '{
    "customerId": "CUST-001",
    "items": [{"productId": "LAPTOP-001", "quantity": 0}]
  }'

Expected response:

{
  "message": "Invalid request body"
}

This also gets rejected because our model requires "minimum": 1 for quantity.

Part VII

Add Resilient Code: Retry Logic with Exponential Backoff

In real applications, your Lambda functions call external services that can fail temporarily. The exam tests whether you understand retry patterns.

Let's Update The `PublishOrder` Function To Include Retry Logic For The EventBridge Call

Step 01: Open the PublishOrder function in the Lambda console

Step 02: Replace the code with this updated version

import json
import boto3
import time
import random
from datetime import datetime
import uuid

eventbridge = boto3.client('events')

def retry_with_backoff(func, max_retries=3, base_delay=0.5):
    """
    Retry a function with exponential backoff and jitter.

    Why exponential backoff?
    - Constant retries can overwhelm a recovering service
    - Exponential delays give the service time to recover
    - Jitter prevents all clients from retrying at the same time (thundering herd)

    This pattern is tested on the DVA-C02 exam.
    """
    for attempt in range(max_retries + 1):
        try:
            return func()
        except Exception as e:
            if attempt == max_retries:
                print(f"All {max_retries + 1} attempts failed. Last error: {str(e)}")
                raise

            # Exponential backoff: 0.5s, 1s, 2s, 4s...
            delay = base_delay * (2 ** attempt)
            # Add jitter: random value between 0 and the delay
            jitter = random.uniform(0, delay)
            wait_time = delay + jitter

            print(f"Attempt {attempt + 1} failed: {str(e)}. Retrying in {wait_time:.2f}s...")
            time.sleep(wait_time)


def lambda_handler(event, context):
    try:
        body = json.loads(event.get('body', '{}'))
        order_id = str(uuid.uuid4())[:8].upper()

        order_detail = {
            'orderId': f'ORD-{order_id}',
            'customerId': body['customerId'],
            'items': body['items'],
            'timestamp': datetime.utcnow().isoformat()
        }

        # Use retry logic for the EventBridge call
        def publish_event():
            response = eventbridge.put_events(
                Entries=[{
                    'Source': 'orders.api',
                    'DetailType': 'OrderPlaced',
                    'Detail': json.dumps(order_detail),
                    'EventBusName': 'orders'
                }]
            )
            if response['FailedEntryCount'] > 0:
                raise Exception(f"EventBridge rejected the event: {response['Entries']}")
            return response

        retry_with_backoff(publish_event)

        return {
            'statusCode': 202,
            'headers': {'Content-Type': 'application/json'},
            'body': json.dumps({
                'message': 'Order accepted for processing',
                'orderId': f'ORD-{order_id}'
            })
        }

    except KeyError as e:
        return {
            'statusCode': 400,
            'headers': {'Content-Type': 'application/json'},
            'body': json.dumps({'error': f'Missing required field: {str(e)}'})
        }
    except Exception as e:
        print(f"Failed to publish order event: {str(e)}")
        return {
            'statusCode': 500,
            'headers': {'Content-Type': 'application/json'},
            'body': json.dumps({'error': 'Failed to process order. Please try again.'})
        }

Click Deploy

✅Green banner: Successfully updated the function "PublishOrder".

💡The AWS SDK (boto3) already includes built-in retry logic for AWS API calls. But the exam tests whether you can implement retry logic for **third-party service calls where you don't get automatic retries. Know the pattern: exponential backoff + jitter.**

Part IX

Explore the Messaging Patterns

Before we clean up, let's look at the SQS queue to understand the messaging flow.

View Messages in SQS

Open the SQS console
Click on inventory-updates
Click Send and receive messages
Click Poll for messages

If the UpdateInventory function processed everything, the queue should be empty. That's correct! SQS deletes messages after successful processing.

Understanding Visibility Timeout

When Lambda picks up a message from SQS:
1. The message becomes invisible to other consumers (visibility timeout)
2. Lambda processes it
3. If successful, Lambda deletes the message
4. If Lambda fails, the message becomes visible again after the timeout and gets retried

You can see the visibility timeout in the queue settings:

Go to the queue → Edit → Visibility timeout (default: 30 seconds)

💡 Set the visibility timeout to at least 6x your Lambda timeout. If your function takes 30 seconds and the visibility timeout is 30 seconds, a slow execution could cause duplicate processing.

🏗️ What You Built | 📘Exam Concepts Recap

What You Did	Exam Concept
Created a custom EventBridge bus	Event-driven architecture
One event → two consumers	Fanout pattern
Publisher doesn't know about consumers	Loose coupling
API Gateway validates before Lambda runs	Request validation (saves compute)
SQS between EventBridge and Lambda	Durability, async processing
`batchItemFailures` in UpdateInventory	Partial batch failure handling
`retry_with_backoff` in PublishOrder	Resilient code, exponential backoff + jitter
HTTP 202 response	Asynchronous acceptance pattern
Each function has its own role	Least privilege, stateless design

⚠️ Clean Up Protocol

To avoid charges, delete the resources in this order:

1. API Gateway → Delete the OrdersAPI
2. Lambda → Delete PublishOrder, ProcessOrder, UpdateInventory
3. SQS → Delete the inventory-updates queue
4. EventBridge → Delete both rules, then delete the orders event bus
5. IAM → Delete the Lambda execution roles (they start with PublishOrder-role-, etc.)
6. CloudWatch → Delete the log groups under /aws/lambda/

Key Takeaways

Loose coupling is almost always the right answer. If components talk directly, add a queue or event bus between them.
EventBridge is the preferred service for event-driven architectures. It supports content-based filtering, multiple targets, and cross-account routing.
API Gateway request validation happens before Lambda which saves compute costs. Know how to create models and attach validators.
SQS long polling (WaitTimeSeconds > 0) reduces empty responses and costs. Always use it.
ReportBatchItemFailures: without it, one failed message retries the entire batch.
Exponential backoff with jitter is the standard retry pattern for third-party calls.
HTTP 202 Accepted signals that the request was accepted for async processing.
Fanout = SNS or EventBridge sending one event to multiple consumers.

Additional Resources

🏗️

OpenClaw on AWS for Beginners: How To Build An AI Agent That Deploys Your WordPress Multisite in Minutes With Just Three Services

Ntombizakhona Mabaso — Sun, 26 Apr 2026 23:07:34 +0000

This is a submission for the OpenClaw Writing Challenge

Just Lightsail, IAM, and Route 53:

How My Agent Built My Site For Me In Minutes

AWS has over 200 services.
I used three.

No VPCs.
No EC2 security groups.
No CloudFormation templates.
No Lambda functions.
No S3 bucket policies.

Just Lightsail to run things, IAM to grant permissions, and Route 53 for DNS.

That's the entire infrastructure for an AI Agent that builds WordPress Multisite installations and writes SEO blog content from scratch, in under 30 minutes, for people who've never touched a server.

This is the story of how I built it with OpenClaw, and why staying in the shallow end of AWS was the whole point.

The Problem I Wanted To Solve

The monotony of manual labor...
Setting up WordPress Multisite manually is a multi-hour ordeal even for developers. You SSH into a server, edit wp-config.php by hand, hope you didn't miss a semicolon, configure Apache, set up a static IP, mess with DNS records, install SSL, restart services, Google the error, and try again.

For a beginner? It's a wall.
Most people give up somewhere between "what's SSH?" and "Error establishing database connection."

I didn't want to write another tutorial that people would bookmark and never finish. I wanted to build an AI agent that does the whole thing for you step by step, in plain language, while explaining everything along the way. And I wanted it to run entirely in the cloud so beginners don't need to install anything on their computer.

Why Lightsail (and only Lightsail)

Most AWS tutorials assume you're comfortable with the full ecosystem. They'll casually tell you to "create a VPC with two subnets" or "configure a security group with the following inbound rules" as if that's a normal thing beginners do on a Sunday afternoon...even though it's quite simple, it's just too many services and a confusing dashboard.

Lightsail exists specifically to avoid that.
It's AWS for people who don't want to think about AWS:

Fixed monthly pricing.
Instances that just work.
Networking that's already configured.
A console that doesn't require a PhD to navigate.

For this project, Lightsail gave me everything I needed:

An OpenClaw Instance: AWS has an official OpenClaw blueprint. Click create, pick the blueprint, and you have a running AI gateway in two minutes.
No Docker, no environment variables, no dependency hell.
A WordPress Instance: same deal. Bitnami WordPress blueprint. Click, wait, done.
Static IPs: free while attached to an instance.
Firewall Rules: built into the instance management page.
No security group rabbit holes.
Browser-Based SSH: click "Connect using SSH" and you're in.
No key management, no PuTTY, no terminal setup.

The only other AWS services I touched were IAM (to grant the OpenClaw instance permission to create Lightsail resources and use Bedrock) and Route 53 (for DNS, and only if you want a custom domain).
That's it.
Three services.
The rest of AWS might as well not exist for this project.

What I Built

An OpenClaw agent with two skills:

Skill 1

WordPress Multisite Builder

An 8-phase guided workflow that walks beginners through creating a Lightsail instance, configuring WordPress, enabling multisite, setting up domains, and installing SSL. Uses browser automation to navigate the AWS console and SSH to configure the server.

Skill 2

Blog Content Engine

A 6-phase content generation system that researches what people are searching for in your niche, writes SEO-optimized blog posts, and publishes them directly to your WordPress site via WP-CLI.

The whole thing runs on a Lightsail OpenClaw instance.
No local install.
You chat with the agent from a browser dashboard, Telegram, or WhatsApp, and it builds your website and writes your content.

The Architecture

You (browser / Telegram / WhatsApp)
    │
    ▼
Lightsail OpenClaw Instance (~$12/mo)
    │  Amazon Bedrock → Claude Opus 4.6
    │
    ├── browser tool ──► AWS Lightsail Console + WordPress Admin
    ├── exec tool ─────► SSH + WP-CLI on the WordPress server
    ├── web_search ────► Keyword research + trending topics
    ├── web_fetch ─────► Competitor analysis + content research
    └── file I/O ──────► Progress tracking, content calendar, posts
    │
    ▼
Lightsail WordPress Instance (~$12/mo)
    └── WordPress Multisite with auto-generated content

Two Lightsail instances.
One IAM role.
Optionally Route 53 for DNS.

How I Built It

Step By Step Guide

Step 1: The OpenClaw Instance

I went to the Lightsail console, clicked "Create instance," picked the OpenClaw blueprint under Linux/Unix, selected the 2 GB plan (~$12/month), named it WordPressAgent, and clicked Create.
Two minutes later it was running.

The pairing process was straightforward: click "Connect using SSH" to open a browser terminal, copy the dashboard URL and access token from the welcome message, paste the token into the dashboard, and approve the pairing prompts in the SSH terminal. Dashboard showed "OK."
Connected.

Step 2: Enabling Bedrock

The Lightsail OpenClaw blueprint comes pre-configured to use Amazon Bedrock you just need to grant the permissions. On the instance's "Getting started" tab, there's a "Copy the script" button. I copied it, launched CloudShell, pasted, and ran it. The script creates an IAM role (LightsailRoleFor-i-xxxxx) with Bedrock access.

I tested it by typing "Hello" in the OpenClaw dashboard chat. Got a response. Bedrock was working.

Step 3: The IAM Permission That Made Everything Click

Here's where I hit my first snag. The agent needed to create Lightsail resources (the WordPress instance, static IPs, etc.) but the IAM role only had Bedrock permissions. When I ran aws lightsail get-instances from the SSH terminal, I got:

AccessDeniedException: User is not authorized to perform: lightsail:GetInstances

The fix was simple: I went to the IAM console, found the AmazonLightsailInstance role, clicked "Add permissions" → "Attach policies," searched for AmazonLightsailFullAccess, and attached it.

One policy. That's all it took.
Lightsail is self-contained: instances, networking, DNS, snapshots, key pairs, everything is under one permission set.
No cross-service IAM policies.
No resource-based permissions.
No condition keys.
This is what makes Lightsail great for beginners: the permission model is as simple as the service itself.

Step 4: Escaping The Sandbox

The next issue: OpenClaw told me it was "running in a sandboxed environment" and couldn't execute commands on the host. By default, OpenClaw runs tools inside a Docker container for security. That's smart for untrusted inputs, but it blocks the agent from doing real work.

Three config lines fixed it:

openclaw config set tools.exec.host gateway
openclaw config set tools.exec.ask off
openclaw config set tools.exec.security full
openclaw gateway restart

This tells OpenClaw to run tools directly on the gateway host instead of in the sandbox. For a personal agent that only you control, this is the right tradeoff.

Alternatively, you can give your agent permission to use your browser and run commands during the initial Security setup process.

Step 5: Building The Agent Workspace

OpenClaw agents are defined by markdown files in a workspace directory. No code, no SDK, no compilation.
Just files that tell the agent who it is, how to behave, and what to do.

I created five core files by pasting them directly into the SSH terminal using cat > file << 'ENDOFFILE' blocks.
No git clone.
No file transfers.
No local tools needed.

IDENTITY.md — defines who the agent is:

You are WP Multisite Builder + Content Engine, an AI assistant that helps
complete beginners:

1. Set up WordPress Multisite on Amazon Lightsail
2. Research trending search topics and generate SEO-optimized blog posts
3. Publish content directly to their WordPress sites

SOUL.md — defines the personality and safety rules. This was important because the agent is aimed at beginners:

## Personality
- Warm and encouraging, like a helpful friend who happens to know tech
- Never condescending. If someone doesn't know what SSH means, that's fine
- Celebrate small wins ("Nice, your instance is running!")

## Safety rules
- NEVER proceed without user confirmation on actions that:
  - Create or modify AWS resources (costs money)
  - Change passwords or security settings
  - Install software on their server
  - Modify WordPress configuration
- Always explain what something will cost before creating resources
- Never store or display AWS credentials in chat history

AGENTS.md — the operating instructions and greeting message. When a user first connects, the agent says:

"Hey! I can help you with two things: set up a WordPress website that can run multiple sites all on Amazon Lightsail, or write blog posts based on what people are actually searching for. We can do both, or just one. What sounds good?"

TOOLS.md — a reference for which OpenClaw tools the agent uses: browser for navigating the Lightsail console and WordPress admin, exec for SSH and WP-CLI commands, web_search and web_fetch for keyword research and troubleshooting, and file I/O for saving progress.

Step 6: The WordPress Multisite Skill

This is the core of the project. I created skills/wp-multisite-lightsail/SKILL.md — an 8-phase guided workflow:

Phase 1: Pre-flight Checks. Confirms the user has an AWS account and login ready. If not, walks them through creating one.

Phase 2: Create a Lightsail Instance. The agent opens the Lightsail console using the browser tool, takes a snapshot of the page to identify clickable elements, and walks through instance creation: Linux/Unix platform, WordPress blueprint, $5/month plan. It stops and confirms the cost before clicking "Create instance," then waits for "Running" status.

Phase 3: Get WordPress Credentials. SSHs into the new instance and reads the default Bitnami password. Tells the user to write it down. Verifies WordPress loads in the browser.

Phase 4: Static IP. Creates and attaches a free static IP so the address doesn't change on restart.

Phase 5: Enable Multisite. This is the complex part that usually trips people up. The agent edits wp-config.php via SSH to add WP_ALLOW_MULTISITE, navigates to Tools → Network Setup in wp-admin via the browser, recommends subdirectories for beginners, applies the multisite configuration constants, updates .htaccess, and restarts Apache. It makes a backup of wp-config.php before any edits. But, it will choose the Multisite Instance from the get go, unless it doesn't.

Phase 6: Domain Setup. If the user has a domain, the agent guides them through DNS configuration at their registrar (using web_search to find the right settings page for GoDaddy, Namecheap, Cloudflare, Route53 etc.) and updates WordPress via WP-CLI.

Phase 7: SSL certificate. Runs Bitnami's bncert-tool for free Let's Encrypt SSL.

Phase 8: Wrap-up. Saves a summary with all URLs, login info, monthly costs, and next steps.

The skill also includes error handling for every common failure such database connection errors, SSH failures, SSL issues, missing config entries. The agent searches the web for solutions when it hits something unexpected.

Step 7: The Content Engine Skill

After the site is built, the agent offers to generate blog content. I created skills/blog-content-engine/SKILL.md with 6 phases:

Phase 1: Keyword Research. Asks the user their niche, then fires off multiple web_search queries to find trending questions, "People Also Ask" data, long-tail keywords, and competitor content. Compiles 10-15 keyword opportunities.

Phase 2: Content Planning. Creates outlines with titles, meta descriptions, target keywords, H2 structure, and FAQ sections.

Phase 3: Writing. Generates 1,200-2,000 word SEO-optimized posts with proper heading structure, keyword placement, short paragraphs, and 8th-grade reading level.

Phase 4: Publishing. Pushes to WordPress via WP-CLI (or browser fallback). For multisite, asks which subsite to target. Never auto-publishes without explicit approval.

Phase 5: Batch Generation. Handles multiple posts with a content calendar.

Phase 6: Ongoing Suggestions. Offers fresh trending topics each time the user comes back.

Step 8: Connecting Telegram and WhatsApp

After everything was working in the dashboard, I connected messaging channels so I could manage the site from my phone.

Telegram took about three minutes: create a bot via @botfather on Telegram, copy the bot token, run openclaw channels add in SSH, select Telegram, paste the token. Then configure the allowlist with my numeric Telegram user ID (get it from @userinfobot) and approve the pairing.

WhatsApp was even simpler: run openclaw channels add, select WhatsApp, scan the QR code with my phone's Linked Devices feature. Done.

Now I can message my bot on Telegram or WhatsApp and say "write a blog post about beginner gardening tips" and it researches, writes, and publishes all from my phone.

The Moment It All Worked

I opened the OpenClaw dashboard, typed "Help me set up WordPress Multisite," and the agent greeted me. It asked if I had an AWS account. It opened the Lightsail console in its browser.

It walked me through creating the instance, explaining every step. It confirmed the cost before clicking Create. It waited for the instance to boot. It SSHed in, grabbed the credentials, set up the static IP, edited the config files, enabled multisite, and verified everything worked.

Under 30 minutes. The whole thing. An AI agent, running on Lightsail, building a WordPress Multisite on another Lightsail instance, using browser automation and SSH. And I never left the Lightsail console (plus one quick trip to IAM to attach a policy).

What OpenClaw Gets Right

Skills Are Just Markdown. Each skill is a SKILL.md file with YAML frontmatter and instructions. No SDK, no compilation, no deployment pipeline. Write markdown, drop it in the workspace, restart the gateway. The agent picks it up on the next session. This is the right abstraction for teaching an agent how to do something complex.

Browser Automation Is Built In. Most AI agents are limited to APIs and CLIs. OpenClaw's browser tool controls an isolated Chromium instance: the agent can navigate web consoles, click buttons, fill forms, and take screenshots. That's a massive unlock for automating things that don't have an API, like the Lightsail console's instance creation wizard.

The Lightsail Blueprint Is A Cheat Code. Going from zero to a running AI gateway in two minutes, with Bedrock pre-configured, HTTPS auto-managed, and daily token rotation...that's the kind of developer experience that makes you want to build things.

Multi-Channel Is Trivial. Dashboard, Telegram, WhatsApp all connected in minutes. The agent doesn't care where the message comes from. Same skills, same personality, same workflow.

The "Confirm Before Acting" Pattern Works. My agent never creates resources or spends money without asking first. This isn't just good UX. It's the difference between a tool beginners trust and one they're afraid of.

What I Learned About Staying In The Shallow End

The biggest lesson: you don't need the deep ocean of AWS to build real things. The instinct is always to reach for EC2, VPCs, security groups, load balancers, auto-scaling groups. But for a personal AI agent running a WordPress site?

Lightsail does everything, and it does it without the cognitive overhead.

The permission model tells the story. I needed exactly two IAM policies: one for Bedrock (auto-created by the setup script) and AmazonLightsailFullAccess (one click in the IAM console). Compare that to the typical EC2 setup where you're writing JSON policy documents with resource ARNs and condition keys.

Route 53 was optional. Only needed if you want a custom domain. And even then, the agent handles the DNS configuration by guiding the user through their existing registrar.

Three services. That's the whole stack. And it's not a toy.
It's a production-capable AI agent that builds infrastructure, manages servers, and generates content.

Try It Yourself

Everything is reproducible. You need:

An AWS account
A Lightsail OpenClaw instance (2 GB plan, ~$12/month)
AmazonLightsailFullAccess attached to the instance's IAM role
The workspace files pasted into ~/.openclaw/workspace/ via SSH

The full deployment takes about 15 minutes. Here's the condensed version:

# After creating the OpenClaw instance, pairing, and enabling Bedrock:

# Create skill directories
mkdir -p ~/.openclaw/workspace/skills/wp-multisite-lightsail
mkdir -p ~/.openclaw/workspace/skills/blog-content-engine

# Paste each workspace file (IDENTITY.md, SOUL.md, AGENTS.md, TOOLS.md,
# and both SKILL.md files) using cat > file << 'ENDOFFILE' blocks

# Configure tool permissions
openclaw config set tools.exec.host gateway
openclaw config set tools.exec.ask off
openclaw config set tools.exec.security full
openclaw gateway restart

# Open the dashboard and type: "Help me set up WordPress Multisite"

No GitHub repo needed.
No local install.
No dependencies.
Just an SSH terminal and some copy-paste.

The cost breakdown

Resource	Monthly cost
OpenClaw Lightsail instance (2 GB)	~$12 (first 90 days free)
WordPress Lightsail instance (2 GB)	~$12 (first 90 days free)
Amazon Bedrock (Claude Opus 4.6)	Pay per token
Static IPs	Free (while attached)
SSL certificates	Free (Let's Encrypt, auto-renews)
Domain name	~$15/year (optional)

About $25/month for the infrastructure, plus whatever Bedrock charges for the AI conversations. For a self-hosted AI agent that builds and manages WordPress sites and writes your blog content, that's a pretty good deal.

Where To Next?

Well, the foundation is solid. Some things I'm thinking about, dependent on your use case:

More Skills: WooCommerce setup, backup automation, security hardening, performance optimization
Multi-tenant: let the agent manage multiple WordPress Multisites for different clients if you're the entrepreneaurial sort.
Scheduled Content: use OpenClaw's cron tool to auto-research and draft posts on a schedule
Analytics Integration: pull Google Analytics data to inform content strategy

The possibilities are endless!
But honestly, the most exciting part is how accessible this is.

A beginner with an AWS account can have a working WordPress Multisite with AI-generated content in under an hour.
No terminal on their laptop.
No config files on their desktop.
No "install these 7 prerequisites first."

Just Lightsail, IAM, and Route 53.
The shallow end of AWS.
And it's plenty deep enough.

Built with OpenClaw on Amazon Lightsail. Powered by Amazon Bedrock (Claude Opus 4.6). Three AWS services. Zero Local Installs.

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