DEV Community: Ntombizakhona Mabaso

Implement Encryption By Using AWS Services | 🏗️ Create A KMS Customer Managed Key

Ntombizakhona Mabaso — Wed, 03 Jun 2026 00:45:50 +0000

Exam Guide: Developer - Associate
🏗️ Domain 2: Security
📘 Task 2: Implement Encryption By Using AWS Services.

Encryption shows up everywhere, especially on this exam. S3, DynamoDB, SQS, Lambda environment variables, RDS, and more. You need to know the difference between client-side and server-side encryption, how KMS works, and when to use each approach.

📘Concepts

Encryption at Rest vs Encryption In Transit

Encryption At Rest

Data stored on disk: S3 Objects, DynamoDB tables, EBS volumes, RDS databases.

Encryption In Transit

Data moving between services or between client and server: HTTPS, TLS, VPN.

Where	At Rest	In Transit
S3	SSE-S3, SSE-KMS, SSE-C	HTTPS (enforced via bucket policy)
DynamoDB	Encrypted by default (AWS owned or KMS)	HTTPS (always)
RDS	KMS encryption	SSL/TLS connections
SQS	SSE-KMS	HTTPS
Lambda env vars	KMS (default + optional CMK)	HTTPS

KMS Key Types

Type	Managed By	Cost	Use Case
AWS owned keys	AWS	Free	Default encryption (DynamoDB, S3 SSE-S3)
AWS managed keys	AWS (in your account)	Free (per-use charges)	`aws/s3`, `aws/dynamodb` (you can't manage them)
Customer managed keys (CMK)	You	Monthly + per-use	Full control: rotation, policies, cross-account

Envelope Encryption

KMS can only directly encrypt up to 4 KB. For larger data, it uses envelope encryption:

1. KMS generates a data key (plaintext + encrypted copy)
2. You encrypt your data with the plaintext data key
3. You store the encrypted data key alongside the encrypted data
4. You discard the plaintext data key from memory
5. To decrypt: KMS decrypts the data key → you decrypt the data

The AWS Encryption SDK handles this automatically.

Server-Side Encryption Options for S3

Option	Key Management	Use Case
SSE-S3	AWS manages everything	Simplest, no KMS costs
SSE-KMS	You control the KMS key	Audit trail via CloudTrail, key policies
SSE-C	You provide the key with every request	Full key control, AWS doesn't store the key

Client-Side vs Server-Side Encryption

Aspect	Server-Side	Client-Side
Who encrypts	AWS (after receiving data)	You (before sending to AWS)
Data in transit	Encrypted by HTTPS	Encrypted by you + HTTPS
Key management	AWS or KMS	You (via KMS or your own keys)
Complexity	Simple	More complex
Use case	Most workloads	When you can't trust the storage layer

Key Rotation

AWS managed keys: Rotated every year automatically (can't change this)
Customer managed keys: Enable automatic rotation (every year)
Old key material is kept, existing encrypted data still works
The key ID doesn't change with automatic rotation
Manual rotation: Create a new key, update alias to point to it

Certificate Management

Service	What It Does	Cost
ACM	Free public SSL/TLS certificates for AWS services	Free
AWS Private CA	Issue private certificates for internal services	Paid

💡ACM certificates can't be exported. They're bound to AWS services (CloudFront, ALB, API Gateway). They auto-renew.

🏗️ Create A KMS Customer Managed Key

Now let's put these concepts into practice:

Create a KMS customer managed key
Encrypt and decrypt data using KMS
Upload objects to S3 with different encryption options (SSE-S3, SSE-KMS)
Enable automatic key rotation
Encrypt Lambda environment variables with a custom KMS key

Prerequisites

An AWS account
An S3 bucket (we'll create one)

Part I

Create a KMS Customer Managed Key

Step 01: Open the KMS console
Click Create key

Step 02: Configure key

Key type: Symmetric
Key usage: Encrypt and decrypt

Click Next

Step 03: Add labels

Alias: app-encryption-key
Description: Customer managed key for application data

Click Next

Step 04: Define key administrative permissions - optional

Key administrators: Select your IAM user

Click Next

Step 05: Define key usage permissions - optional

Key administrators: Select your IAM user

Click Next

Step 06: Edit key policy - optional
Click Next

Step 07: Review
Click Finish

✅Green banner: Success
Your AWS KMS key was created with alias app-encryption-key and key ID 17fx7cex-17ae-419x-x816-de16fx50x928.

💡 You now have a customer managed KMS key. Note the Key ID and ARN.

Enable Automatic Key Rotation

Step 08: Click on your key (app-encryption-key)

Step 09: Go to the Key material rotations tab
Click Edit

Step 10: Edit automatic key rotation

Key rotation: Enable
Rotation period in days: 365

Click Save

✅Green banner: Successfully enabled automatic key rotation

💡 With automatic rotation, KMS keeps old key material so existing ciphertext can still be decrypted. The key ID and ARN don't change. With manual rotation (creating a new key), you get a new key ID. Use aliases to abstract this.

Part II

Encrypt and Decrypt Data with KMS

Using the Console

💡 In the KMS console, you can't directly encrypt/decrypt from the UI

Step 01: Create a Lambda function to demonstrate
Lambda → Create function:

Name: KMSEncryptionDemo
Runtime: Python 3.12
Deploy: Code:

import json
import boto3
import base64

kms = boto3.client('kms')
KEY_ID = 'alias/app-encryption-key'

def lambda_handler(event, context):
    """
    Demonstrates KMS encrypt/decrypt operations.

    Key concepts:
    - KMS can directly encrypt up to 4 KB
    - For larger data, use GenerateDataKey (envelope encryption)
    - The AWS Encryption SDK handles envelope encryption automatically
    """
    action = event.get('action', 'encrypt')
    plaintext = event.get('data', 'Hello, this is sensitive data!')

    if action == 'encrypt':
        # Encrypt data (up to 4 KB)
        response = kms.encrypt(
            KeyId=KEY_ID,
            Plaintext=plaintext.encode('utf-8')
        )
        ciphertext_b64 = base64.b64encode(response['CiphertextBlob']).decode('utf-8')

        return {
            'statusCode': 200,
            'body': json.dumps({
                'message': 'Data encrypted successfully',
                'ciphertext': ciphertext_b64,
                'keyId': response['KeyId']
            })
        }

    elif action == 'decrypt':
        # Decrypt data
        ciphertext = base64.b64decode(event['ciphertext'])
        response = kms.decrypt(CiphertextBlob=ciphertext)

        return {
            'statusCode': 200,
            'body': json.dumps({
                'message': 'Data decrypted successfully',
                'plaintext': response['Plaintext'].decode('utf-8')
            })
        }

    elif action == 'generate_data_key':
        # Generate a data key for envelope encryption
        response = kms.generate_data_key(
            KeyId=KEY_ID,
            KeySpec='AES_256'
        )

        return {
            'statusCode': 200,
            'body': json.dumps({
                'message': 'Data key generated (envelope encryption)',
                'plaintextKey': '*** exists in memory only — use it to encrypt, then discard ***',
                'encryptedKey': base64.b64encode(response['CiphertextBlob']).decode('utf-8'),
                'note': 'Store the encrypted key alongside your encrypted data'
            })
        }

Step 02: Add KMS permissions to the Lambda role:
Configuration → Permissions → click role name
Add permissions → Attach policies → AWSKeyManagementServicePowerUser

Step 03: Test events
Encrypt:

{"action": "encrypt", "data": "My secret credit card number"}

Generate data key:

{"action": "generate_data_key"}

Part III

S3 Encryption Options

Create an S3 Bucket

Step 01: Open the S3 console → Create bucket

Step 02: General configuration

Bucket type: General purpose
Bucket namespace: Account Regional namespace (recommended)
Bucket name prefix: dva-encryption-demo
Encryption type: Server-side encryption with Amazon S3 managed keys (SSE-S3)

Step 03: Upload with SSE-S3 (Default)

Click Upload
Click Add files
Add a file (any text file)
Click Upload

💡SSE-S3 is applied automatically

Step 04: Upload with SSE-KMS

Click Upload
Click Add files
Expand ▶ Properties
Server side encryption: Specify an encryption key
Encryption settings: Override bucket settings for default encryption
Encryption type: Server-side encryption with AWS Key Management Service keys (SSE-KMS)
AWS KMS Key: Choose from your AWS KMS keys
Available AWS KMS Key: app-encryption-key
Click Upload

Step 05: Verify Encryption
Click on each uploaded file

Step 06: Go to the Properties tab → Server-side encryption settings
You'll see which encryption method was used

💡SSE-KMS gives you an audit trail in CloudTrail (every encrypt/decrypt call is logged). SSE-S3 does not. If a question mentions "audit" or "compliance," SSE-KMS is usually the answer.

Part IV

Encrypt Lambda Environment Variables

Using a Custom KMS Key

Step 01: Open your KMSEncryptionDemo function

Step 02: Configuration → Environment variables → Edit

Step 03: Edit environment variables
Click Add environment variable

Key: DB_PASSWORD
Value: super-secret-password

Step 04: Expand ▶ Encryption configuration

Encryption in transit: ✔ Check Enable helpers for encryption in transit
AWS KMS key to encrypt at rest: Use a customer managed key
Select app-encryption-key
Click the Encrypt button next to DB_PASSWORD

Click Save

The value is now encrypted.
In your code, you'd decrypt it:

import boto3
import base64
import os

kms = boto3.client('kms')

# Decrypt at cold start, cache the result
ENCRYPTED = os.environ['DB_PASSWORD']
DECRYPTED = kms.decrypt(
    CiphertextBlob=base64.b64decode(ENCRYPTED)
)['Plaintext'].decode('utf-8')

def lambda_handler(event, context):
    # Use DECRYPTED: already decrypted at cold start
    print(f"Password length: {len(DECRYPTED)}")  # Don't log the actual password!

🏗️ What You Built | 📘 Exam Concepts Recap

What You Built	Exam Concept
Created a Customer Managed KMS key	Key types: AWS owned vs AWS managed vs customer managed
Assigned key administrators and key users	KMS key policies: separate admin and usage permissions
Enabled automatic key rotation	Old key material preserved, key ID unchanged, seamless decryption
Encrypted data directly with `kms.encrypt()`	KMS direct encryption: limited to 4 KB
Called `generate_data_key` for AES-256	Envelope encryption: encrypt large data locally, protect the key with KMS
Discarded the plaintext data key after use	Security best practice: plaintext key lives only in memory
Uploaded S3 objects with SSE-S3	Default encryption: AWS manages everything, no audit trail
Uploaded S3 objects with SSE-KMS	Audit trail in CloudTrail, key policy control, cross-account possible
Encrypted Lambda environment variables with a CMK	Protecting secrets at rest in Lambda configuration
Decrypted env vars at cold start and cached the result	Performance pattern: avoid decrypting on every invocation

⚠️ Clean Up Protocol

S3 → Empty and delete the bucket
Lambda → Delete KMSEncryptionDemo
KMS → Schedule key deletion (7-day minimum waiting period)
IAM → Delete Lambda execution roles
CloudWatch → Delete log groups

Key Takeaways

KMS encrypts up to 4 KB directly: use envelope encryption (GenerateDataKey) for larger data
SSE-S3: simplest. SSE-KMS: audit trail + key control. SSE-C: you provide the key.
Client-side encryption: you encrypt before sending to AWS
Automatic key rotation keeps old key material and existing data ia still decryptable
Use aliases for seamless manual key rotation
Cross-account KMS requires both a key policy AND an IAM policy
ACM = free public certs (can't export). Private CA = private certs (costs money).
Envelope encryption: the AWS Encryption SDK handles this for you

Additional Resources

🏗️

Implement Authentication And/Or Authorization For Applications And AWS Services | 🏗️ Build A Secure Notes API

Ntombizakhona Mabaso — Tue, 02 Jun 2026 22:54:48 +0000

Exam Guide: Developer - Associate
🏗️ Domain 2: Security
📘 Task 1: Implement Authentication And/Or Authorisation For Applications And AWS
Services

Authentication (who are you?) and Authorisation (what can you do?) are central to the DVA-C02, and just Cloud Development in general.
You need to know Cognito, IAM Roles and Policies, STS, Lambda Authorizers, and how to secure microservice-to-microservice communication or communication within a Microservices Architectural Environment.

📘 Concepts

Authentication vs Authorisation

Term	What It Answers	AWS Services
Authentication	Who are you?	Cognito User Pools, IAM
Authorisation	What can you do?	IAM Policies, Cognito Identity Pools, Lambda Authorizers

Amazon Cognito

User Pools vs Identity Pools

Feature	User Pool	Identity Pool
Purpose	Authentication (sign up, sign in)	Authorisation (temporary AWS credentials)
Returns	JWT tokens (ID, access, refresh)	AWS credentials (access key, secret, session token)
Use When	You need a user directory	Users need to call AWS services directly
Federation	Google, Facebook, SAML, OIDC	Google, Facebook, SAML, User Pools

User Pools = authentication (get tokens).
Identity Pools = authorisation (get AWS credentials).
They're often used together but serve different purposes.

The Three Cognito Tokens

Token	Contains	Use For
ID Token	User identity claims (name, email, groups)	Your application to identify the user
Access Token	Scopes and permissions	API authorisation
Refresh Token	Long-lived credential	Getting new ID/access tokens without re-authentication

API Gateway Authorisation Options

Option	What It Does	When to Use
None	No auth	Public APIs
IAM	SigV4 signing	Internal/service-to-service calls
Cognito Authorizer	Validates JWTs from User Pool	Simple JWT validation
Lambda Authorizer (Token)	Custom logic on the token	Complex auth, external IDPs
Lambda Authorizer (Request)	Custom logic on full request	Auth based on headers, query strings, source IP

IAM Roles vs Users

Type	Credentials	Use Case
IAM User	Long-lived (access key + secret)	Humans, legacy CLI access
IAM Role	Temporary (via STS AssumeRole)	Applications, EC2, Lambda, cross-account

Roles are always preferred for applications. Never hardcode access keys.
Lambda uses an execution role, EC2 uses an instance profile, ECS uses a task role.
All of these give your code temporary credentials automatically.

STS (Security Token Service) Operations

`Operation`	Use Case
`AssumeRole`	Same or cross-account role assumption
`AssumeRoleWithWebIdentity`	Exchange OAuth/OIDC token for AWS credentials
`AssumeRoleWithSAML`	Exchange SAML assertion for AWS credentials
`GetSessionToken`	Temporary credentials (for MFA-protected API calls)

Credential Resolution Order (SDK Default Chain)

The AWS SDK looks for credentials in this order:

1. Environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
2. Shared credentials file (~/.aws/credentials)
3. AWS config file (~/.aws/config)
4. Container credentials (ECS task role)
5. Instance profile (EC2 role)
6. SSO credentials (IAM Identity Center)

🏗️ Build A Secure Notes API

Now lets put these concepts into practice, by building a Secure Notes API with Cognito authentication:

A Cognito User Pool with Managed Login for sign-up/sign-in
An App Client configured with the authorization code grant flow
A Lambda function that stores and retrieves notes
An API Gateway REST API protected by a Cognito authorizer
Test users signing in and calling the API with JWT tokens

Prerequisites

An AWS account

Part I

Create the Cognito User Pool

The Cognito console now uses a streamlined, application-focused setup wizard with Managed Login (the successor to the classic Hosted UI). The wizard creates your user pool and app client in one flow.

Step 01: Open the Cognito console

Step 02: Click Create user pool

Step 03: Set up resources for your application
Application type: Traditional web application
Name your application: My Notes App
Options for sign-in identifiers: Email
Self-registration: ✔
Required attributes for sign-up: email name
Click Create user directory

✅Green banner: Your application "My Notes App" and user pool "User pool - gcvhqy" have been created successfully! Follow the instruction to continue the setup.

💡The new console creates the user pool, app client, and managed login domain all in one step. "Traditional web application" configures the authorization code grant flow with a client secret by default. This is the recommended pattern for server-side apps.

Step 04: Get Your Pool Details
After creation, click on the user pool and note:

User pool ID (looks like us-east-1_ABC123XYZ)
App client ID (from the ▼ Applications tab → App clients)
Cognito domain (from the ▼ Branding tab → Domain )

Part II

Create a Test User

Step 01: In the User Pool, click the ▼ Users management tab
Click Users

Step 02: Users
Click Create user
User Information

Invitation message: Send an email invitation
Email address: Use a real email you can access
Temporary password: Generate a password

Click Create user

✅Green banner: User username@example.com has been created successfully.

You'll receive an email with a temporary password.

⚠️ Don't log in yet. We'll do that through the Managed Login in a moment.

Part III

Test with Managed Login (Authorization Code Flow)

Step 01: View the hosted UI URL
From the ▼ Applications tab → App clients
Click View login page

https://YOUR_COGNITO_DOMAIN.auth.us-east-1.amazoncognito.com/login?
  client_id=YOUR_APP_CLIENT_ID&
  response_type=code&
  scope=email+openid+profile&
  redirect_uri=YOUR_CALLBACK_URL

Step 02: Sign in
Sign in with the user credentials from the email
Cognito will force you to set a permanent password

Step 03: Change password

✅: Success page

Successfully signed in
This is the default redirect page for Amazon Cognito user pools.
You're seeing this page because your Amazon Cognito app client doesn't have a return URL set.

Step 04: After login, you'll be redirected to https://d84l1y8p4kdic.cloudfront.net/?code=2f927666-cd13-4e94-9af9-58887a9d9cd3...

💡Copy the code value from the URL fragment.
You'll need it to call the API.

⚠️ This code is NOT a token. It's a one-time authorization code that expires in a few minutes. You need to exchange it for actual JWT tokens in the next step.

Step 05: Exchange the Code for Tokens
Use the Cognito token endpoint to exchange the authorization code for JWT tokens:

curl -X POST "https://YOUR_COGNITO_DOMAIN.auth.us-east-1.amazoncognito.com/oauth2/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code&code=YOUR_AUTH_CODE&client_id=YOUR_APP_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET&redirect_uri=YOUR_CALLBACK_URL"

⚠️ If your app client has a client secret (default for "Traditional web application"), you also need to include a client_secret parameter, or pass the credentials as a Basic auth header: -H "Authorization: Basic BASE64(client_id:client_secret)"

Expected response:

{
  "id_token": "eyJraWQiOiJ...",
  "access_token": "eyJraWQiOiJ...",
  "refresh_token": "eyJjdHkiOiJ...",
  "expires_in": 3600,
  "token_type": "Bearer"
}

💡 Copy the id_token value. You'll need it to call the API.

response_type=token uses the implicit grant flow (returns tokens directly). response_type=code uses the authorization code flow (returns a code you exchange for tokens via the token endpoint).
Auth code is more secure for production apps.

Part IV

Create the DynamoDB Table

Step 01: Open the DynamoDB console → Create table

Step 02: Create table

Table name: Notes
Partition key: userId (String)
Sort key: noteId (String)
Table settings: Default settings

Click Create table

✅Green banner: The Notes table was created successfully.

Part V

Create the Notes Lambda Function

Step 01: Open Lambda → Create function

Step 02: Create function

Function name: NotesAPI
Runtime: Python 3.12

Click Create function

✅Green banner: Successfully created the function "NotesAPI"

Step 03: Configuration → General configuration → click Edit

Memory: 256 MB
Timeout: 0 min 10 sec

Click Save

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

Step 04: Add DynamoDB Permissions
Configuration → Permissions → click the Role name

Step 05: Add permissions ▼ → Attach policies → search AmazonDynamoDBFullAccess → attach

✅Green banner: Policies have been successfully attached to role.

Step 06: Function Code

import json
import boto3
import uuid
from datetime import datetime
from boto3.dynamodb.conditions import Key

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('Notes')

def lambda_handler(event, context):
    """
    Notes API with user isolation.
    Each user can only access their own notes — enforced by extracting
    the userId from the JWT claims and using it as the partition key.
    """
    http_method = event.get('httpMethod', 'GET')
    path = event.get('path', '/')

    # Extract the authenticated user from Cognito claims
    # API Gateway puts the JWT claims here after the authorizer validates the token
    try:
        claims = event['requestContext']['authorizer']['claims']
        user_id = claims['sub']  # Cognito's unique user ID
        user_email = claims.get('email', 'unknown')
    except KeyError:
        return response(401, {'error': 'Unauthorized'})

    print(f"Request from user {user_email} (ID: {user_id})")

    try:
        if path == '/notes' and http_method == 'GET':
            return list_notes(user_id)

        elif path == '/notes' and http_method == 'POST':
            body = json.loads(event.get('body') or '{}')
            return create_note(user_id, body)

        elif path.startswith('/notes/') and http_method == 'GET':
            note_id = path.split('/')[-1]
            return get_note(user_id, note_id)

        elif path.startswith('/notes/') and http_method == 'DELETE':
            note_id = path.split('/')[-1]
            return delete_note(user_id, note_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_notes(user_id):
    """List all notes for the authenticated user."""
    result = table.query(
        KeyConditionExpression=Key('userId').eq(user_id)
    )
    return response(200, {
        'notes': result['Items'],
        'count': result['Count']
    })


def create_note(user_id, body):
    """Create a new note owned by the authenticated user."""
    note_id = str(uuid.uuid4())
    note = {
        'userId': user_id,           # ← partition key ensures data isolation
        'noteId': note_id,
        'title': body.get('title', 'Untitled'),
        'content': body.get('content', ''),
        'createdAt': datetime.utcnow().isoformat()
    }
    table.put_item(Item=note)
    return response(201, note)


def get_note(user_id, note_id):
    """Get a specific note. User can only access their own notes."""
    result = table.get_item(Key={'userId': user_id, 'noteId': note_id})
    item = result.get('Item')
    if not item:
        return response(404, {'error': 'Note not found'})
    return response(200, item)


def delete_note(user_id, note_id):
    """Delete a note. User can only delete their own notes."""
    table.delete_item(Key={'userId': user_id, 'noteId': note_id})
    return response(204, {})


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

Step 07: Click Deploy.

Notice the user isolation pattern. The userId comes from the JWT claims (set by Cognito, validated by API Gateway), not from the request body. Users can't forge this value because API Gateway won't invoke Lambda without a valid token. This is application-level authorization.

Part VI

Create the API Gateway API

Create the API

Step 01: Open API Gateway → Create API → REST API → Build

Step 02: Create REST API

New API
API name: NotesAPI
API endpoint type: Regional
Security policy - new: TLS_1_0

Click Create API

✅Green banner: Successfully created REST API 'NotesAPI (xoq5e4tu3j)'.

Create the Cognito Authorizer

Step 03: In the left sidebar, click Authorizers
Click Create authorizer

Step 04: Create authorizer

Authorizer name: CognitoAuth
Authorizer type: Cognito
Cognito user pool: Select NotesUserPool
Token source: Authorization (this is the header name)

Click Create authorizer

✅Green banner: Successfully created authorizer 'CognitoAuth'.

Create the Resources and Methods

Step 05: Click Resources → Create resource

Step 06: Create resource

Resource path: /
Resource name: notes
✔ CORS (Cross Origin Resource Sharing)

Click Create resource

✅Green banner: Successfully created resource '/notes'

Step 07: Now create a child resource for /notes/{noteId}:
Select the /notes resource → Create resource

Resource path: /notes/
Resource name: {noteID} (proxy resource)

Click Create resource

✅Green banner: Successfully created resource '/notes/{noteID}'

Add the Methods

Step 08: For each method below, click the resource, then Create method:

Step 09: POST /notes (create a note)

▼ Method type: POST
Integration type: Lambda Function
Lambda proxy integration: ✔
Lambda function: NotesAPI

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

Step 10: GET /notes (list notes)

▼ Method type: GET
Integration type: Lambda Function
Lambda proxy integration: ✔
Lambda function: NotesAPI

✅Green banner: Successfully created method 'GET' in 'notes'.

Step 11: GET /notes/{noteId} (get one note)

▼ Method type: GET
Integration type: Lambda Function
Lambda proxy integration: ✔
Lambda function: NotesAPI

✅Green banner: Successfully created method 'GET' in 'noteID'.

Step 12: DELETE /notes/{noteId} (delete a note)

▼ Method type: DELETE
Integration type: Lambda Function
Lambda proxy integration: ✔
Lambda function: NotesAPI

✅Green banner: Successfully created method 'DELETE' in 'noteID'.

Attach the Authorizer to Each Method

Step 13: For each of the four methods:

13.1: Click the method (e.g., GET under /notes)
13.2: Click Method request → Edit
13.3: Set Authorization to CognitoAuth
13.4: Click Save

✅Green banners: Successfully edited method request for ‘x’

Deploy the API

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

Click Deploy

✅Green banner: Successfully created deployment for NotesAPI.

Step 15: Copy the Invoke URL

Part VII

Test the Authenticated API

Test One: Unauthenticated Request (Should Fail)

curl -X POST https://YOUR_API_URL/dev/notes \
  -H "Content-Type: application/json" \
  -d '{"title": "My first note", "content": "Hello world"}'

Expected response:

{"message": "Unauthorized"}

⚠️ API Gateway rejected the request because there's no JWT token. Lambda was never invoked.

Test Two: Authenticated Request (Should Succeed)

Use the id_token you got from the token exchange in Part III:

curl -X POST https://YOUR_API_URL/dev/notes \
  -H "Authorization: eyJraWQiOiJ..." \
  -d '{"title": "My first note", "content": "Hello world"}'

Expected response:

{
  "userId": "abc-123-def-456",
  "noteId": "7f8e9d0c-...",
  "title": "My first note",
  "content": "Hello world",
  "createdAt": "2026-04-24T10:00:00"
}

💡 Notice the userId was pulled from the JWT claims. The user didn't have to send it.

Test Three: List Your Notes

curl https://YOUR_API_URL/dev/notes \
  -H "Authorization: YOUR_ID_TOKEN"

You'll only see notes belonging to the authenticated user.

Test Four: Invalid Token (Should Fail)

curl https://YOUR_API_URL/dev/notes \
  -H "Authorization: invalid.token.here"

Expected response:

{"message": "Unauthorized"}

Part VIII

Build a Lambda Authorizer (Advanced)

Cognito authorizers are simple.
They just validate JWT signatures.
Lambda authorizers let you implement custom logic.
Let's see how.

Create the Authorizer Function

Step 01: Open Lambda → Create function

Step 02: Create function

Function name: NotesLambdaAuthorizer
Runtime: Python 3.12

Click Create function

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

Step 03: Paste this code

import json

def lambda_handler(event, context):
    """
    Custom Lambda authorizer.
    Returns an IAM policy that allows or denies the API call.

    Lambda authorizer results can be cached (default 5 min, max 1 hour)
    to reduce the number of Lambda invocations.
    """
    token = event.get('authorizationToken', '').replace('Bearer ', '')
    method_arn = event['methodArn']

    print(f"Authorizing request with token: {token[:20]}...")

    # In production, validate the JWT signature using the Cognito JWKS
    # For this demo, we just check if the token starts with a specific prefix
    if not token or token == 'invalid':
        # Deny access
        raise Exception('Unauthorized')

    # Simulate extracting user info from the token
    user_id = 'demo-user-001'
    user_role = 'admin' if 'admin' in token else 'user'

    # Build the policy based on the user's role
    if user_role == 'admin':
        effect = 'Allow'
        # Admin can access everything in the API
        resource = method_arn.rsplit('/', 2)[0] + '/*/*'
    else:
        effect = 'Allow'
        # Regular user can only access the specific method
        resource = method_arn

    return {
        'principalId': user_id,
        'policyDocument': {
            'Version': '2012-10-17',
            'Statement': [{
                'Action': 'execute-api:Invoke',
                'Effect': effect,
                'Resource': resource
            }]
        },
        'context': {
            'userId': user_id,
            'userRole': user_role
        }
    }

Step 04: Click Deploy

✅Green banner: Successfully updated the function "NotesLambdaAuthorizer"

Step 05: Attach It to the API (Walkthrough Only)
In API Gateway:
1. Authorizers → Create authorizer
2. Configure:

Name: LambdaAuth
Authorizer type: Lambda
Lambda function: NotesLambdaAuthorizer
Lambda event payload: Token
Token source: Authorization
Authorization caching: 300 seconds 3. Create authorizer

You could switch methods to use this instead of the Cognito authorizer. We won't switch for this tutorial. The Cognito authorizer is already doing its job.

💡Lambda authorizer results are cached (up to 1 hour). This reduces Lambda invocations but means permission changes aren't immediate. Two types:

Token-based: receives the token, caches by token value

Request-based: receives the full request, caches by specified identity sources.

🏗️ What You Built | 📘Exam Concepts Recap

What You Built	Exam Concept
Created a Cognito User Pool	Authentication via managed user directory
Configured the Cognito Hosted UI	OAuth 2.0 authorization code / implicit grant flows
Signed in and received ID, access, and refresh tokens	The three Cognito token types and their purposes
Attached a Cognito Authorizer to API Gateway methods	JWT validation at the API layer
Extracted `sub` and `email` from JWT claims in Lambda	Passing identity from API Gateway to Lambda
Used `userId` as the DynamoDB partition key	Application-level authorization (data isolation)
Built a Lambda authorizer with custom logic	Fine-grained authorization
Returned an IAM policy from the Lambda authorizer	How Lambda authorizers control access
Set the Lambda authorizer cache TTL	Performance vs permission freshness trade-off
Tested with and without a valid token	API Gateway rejects unauthenticated requests before Lambda

⚠️ Clean Up Protocol

API Gateway → Delete NotesAPI
Lambda → Delete NotesAPI, NotesLambdaAuthorizer
DynamoDB → Delete the Notes table
Cognito → Delete the User Pool (also delete the domain first)
IAM → Delete the Lambda execution roles
CloudWatch → Delete the log groups

Key Takeaways

Cognito User Pools = authentication (tokens). Identity Pools = authorization (AWS credentials).
Three tokens: ID (user identity), Access (API auth), Refresh (getting new tokens).
Cognito Authorizer = simple JWT validation. Lambda Authorizer = custom logic.
Lambda authorizer caching: (up to 1 hour) reduces invocations but delays permission changes.
Never hardcode credentials: use IAM roles (execution role for Lambda, task role for ECS, instance profile for EC2).
STS AssumeRole for cross-account access and temporary credentials.
SigV4 signing is used for IAM authorization on API Gateway (service-to-service).
Credential resolution order: env vars → credentials file → config → container → instance profile.
JWT claims are passed to Lambda via event.requestContext.authorizer.claims.
Application-level authorization: use the authenticated user ID as the partition key to enforce data isolation.

Additional Resources

🏗️

Formerly Known As

Ntombizakhona Mabaso — Wed, 20 May 2026 11:25:01 +0000

Keeping Up With The Renamed World

Tech changes fast.
Sometimes too fast.

One day you are confidently talking about a service, framework, tool, or company… and the next day it has a completely different name, a new logo, a rebrand announcement, and an updated pricing page. 😭

That is exactly why I am starting this series:

"Formerly Known As"

A blog series where I keep up with the former names of current resources, services, platforms, tools, and technologies across Cloud, AI, Web Development, and Tech in general.

Because honestly?

A huge part of learning tech is also learning its history.

If you have ever said things like:

“Wait… wasn’t this called something else before?”
“Isn’t this just a rebrand?”
“I still call it Twitter.”
“When did this AWS service change names?”
“Hold on… what happened to that?”

…then this series is for you, and mostly me.😂

I am going to explore:

1. Old names vs new names
2. Why companies rebrand
3. Mergers and acquisitions
4. Product evolution
5. Retired services
6. Tech nostalgia
7. The confusion these changes create for beginners

And maybe most importantly:
How keeping up with naming changes helps us better understand the tech ecosystem.

Some posts may be quick and fun.
Others may dive deeper into the history behind a platform or service.

Either way, this series is for:

Developers 👩🏽‍💻
Cloud learners ☁️
Curious tech people 🔍
Documentation readers 📚
People who still accidentally use old names 😅
Me.

"Formerly Known As."

The internet never forgets old names…
and apparently neither do we.

No particular frequency.
No particular theme.
Just the renamed things that cross my mind...and my notifications.

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 Built	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

🚀