Forem: Joanne Skiles

I Built a Local AI Podcast Editor Because I'm Done Renting My Own Workflow

Joanne Skiles — Sun, 15 Mar 2026 17:41:09 +0000

Despite how much I post online, I'm pretty deliberate about where my data actually lives. Not in a tinfoil hat way, I use cloud services, I have accounts everywhere. But there's a difference between choosing to share something and having no other option.

I started a podcast. Suddenly I needed to think about marketing, which means Shorts, Reels, vertical cuts, captions. The tools that do this are good. Genuinely good. But they all run on the same model: your files live on their servers, your workflow lives in their interface, and your access lives on their billing page. Cancel your subscription and you're starting over. Want to export your project? Hope they support that. Want to know what they're doing with your footage? Read the terms of service and good luck.

I'm not interested in that trade. I want to own my pipeline the same way I own my code. So I built a POC called DarkRoom.

Local-First Isn't Just a Preference, It's an Architecture

There's a growing conversation in software about local-first design, the idea that your data should live on your device by default and only sync or share when you explicitly choose to. Tools like Obsidian, Excalidraw, and a wave of newer apps are built around this. Your device is the source of truth, not some server you're renting space on.

The content creation space hasn't caught up. Almost everything assumes the cloud is the primary location and your device is just a thin client. That's great for collaboration. But it also means:

You're paying rent on your own data
Your workflow can disappear when a company pivots, gets acquired, or raises prices
You have no real visibility into how your content is used after upload

DarkRoom is an attempt to apply local-first thinking to podcast production. The processing happens on your machine. The files are yours. The workflow is just a Python server and some JSON. You can read every artifact it produces in a text editor, put it in git, move it to another machine, or delete it. No account required. No export wizard. No "your project will be deleted in 30 days."

The only external dependency (which is optional) is one Claude API call per episode, text in and edit decisions out, which you pay for directly at fractions of a cent per use.

What is DarkRoom?

DarkRoom is a local-first, multi-camera podcast editor. You give it your raw camera files, it transcribes them on your machine, an AI generates an edit decision list, you review and tweak it in the browser, and FFmpeg renders the final outputs. Nothing leaves your machine except that one, optional, text-only API call.

The Stack

Layer	Tech
Backend	Python + Flask
Transcription	OpenAI Whisper (runs locally)
AI editing decisions	Claude (`claude-sonnet-4-6`)
Rendering	FFmpeg
Frontend	Vanilla HTML/JS/CSS, one file
State	JSON in a `projects/` folder

No database. No Docker. No SaaS. No monthly fee. Just a Python server you run on your own machine, using open tools that have been around for years.

How It Actually Works

Step 1 - Upload your cameras

You record with 2 to 4 cameras, one per speaker, already synced. Upload each file and tag it with a speaker name.

Step 2 - Local transcription via Whisper

Whisper runs locally on each camera's audio. Because you're uploading one file per speaker, attribution is free. Whisper doesn't need to guess who said what. The result is a merged, time-coded transcript where every line already knows which camera it came from.

Step 3 - AI generates the Edit Decision List

This is the only moment anything leaves your machine. The transcript text gets sent to Claude and Claude returns a JSON Edit Decision List (EDL):

{
  "segments": [
    { "id": "seg_001", "start": 0.0, "end": 12.4, "keep": true, "camera": "A", "layout": "single" },
    { "id": "seg_002", "start": 12.4, "end": 15.1, "keep": false, "camera": "A", "reason": "filler words" }
  ],
  "clips": [
    { "id": "clip_001", "label": "Best 60-90s clip for Shorts", "start": 4.2, "end": 94.2, "reason": "Strong hook, complete thought" }
  ]
}

It tells FFmpeg what to keep, what to cut, which camera to show when, and which chunk would make the best Short. Plain JSON. Read it, edit it by hand, version control it, diff it between episodes.

Step 4 - Review in the browser

A UI served from localhost shows camera previews, per-speaker timeline tracks, and a transcript panel synced to the timeline. Toggle cuts, swap cameras, change layouts. The EDL is just a file on disk so nothing is locked away.

Step 5 - Render

Pick your targets: 16:9 full edit, 9:16 vertical, or the best 60 to 90 second Short. FFmpeg renders them into projects/{id}/output/. They're yours.

The Ownership Model

Your files stay local. Whisper runs on your machine, video never goes anywhere.
Your data is readable. Every project is a folder of MP4s and JSON files.
Your workflow is portable. No account, no export flow, no "download before you cancel."
Your cost is marginal. One Claude API call per episode, typically under $0.10. Pay per use, not per month.
Your stack is replaceable. Want to swap Claude for a local LLM? That's one file. Want to parse the EDL yourself? It's JSON. You're not locked into anything.

Running It

git clone https://github.com/you/darkroom
cd darkroom
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
# add ANTHROPIC_API_KEY to .env
python app.py

Open http://localhost:5000.

What's Next

A few things I want to explore:

Replace Claude with a local LLM. The API call is already isolated in one file (editor.py). Plugging in Ollama or any OpenAI-compatible endpoint would make this fully air-gapped. The tradeoff is edit quality but for someone who wants zero external dependencies, it's a straightforward swap.

Auto-captions baked in. Whisper already produces the transcript. Burning subtitles into the vertical cut is a small FFmpeg step and probably the highest-value addition for short-form content.

Smarter clip selection. Right now Claude picks the best 60 to 90 second window. With a bit more prompt work you could get multiple ranked clip candidates per episode.

A proper timeline UI. The current review interface is functional but minimal. A drag-and-drop timeline where you can scrub through cuts before rendering would make the whole review step a lot nicer.

What This Is (and Isn't)

This is a proof of concept. The AI cuts are a starting point and you still review everything before anything renders. It is not Descript. It will not auto-post to Instagram.

What it is: a working pipeline from raw multi-camera footage to a full edit, a vertical cut, and a Short, on your own hardware, for less than a dime an episode, where every file is something you own and every dependency is something you can replace.

The tools already existed. Whisper, FFmpeg, Claude's API, none of this is new. DarkRoom is just the glue that connects them in a way that keeps you in control.

Repo: https://github.com/chaotictoejam/darkroom
Stack: Python · Flask · Whisper · Claude · FFmpeg

Building "Ghost in The Code" with Kiro: A Kiroween Hackathon Journey 👻

Joanne Skiles — Mon, 24 Nov 2025 04:02:43 +0000

DEMO VIDEO HERE: https://youtu.be/W4fzNJCMGD8

As a contestant on Road to re:Invent, there’s one thing I know for sure: the hackathon is going to use Kiro. So when the Kiroween challenge appeared, I thought, perfect - this is how I get Kiro into my muscle memory before competition day.

One of my biggest passions is making tech fun and accessible for kids.

So naturally: Halloween + STEM = Ghost in The Code

A kid-friendly web game where players help a friendly ghost debug “haunted” code to save the digital world. Each spooky “bug” maps to a real programming concept (loops, conditionals, logic puzzles), and fixing it triggers a fun little animation.

But this wasn’t just a cute idea. It quickly turned into a very real engineering challenge. In a short amount of time, I needed to build:

Multiple interactive coding challenges across core concept types
A badge/achievement system
Smooth animations and visual feedback
AWS infrastructure for text-to-speech
Session-based progress tracking
A full TypeScript codebase with strict mode
All while trying to keep the game fun, polished, and kid-friendly

So yeah, this project had a _lot _ of moving parts.

And that’s exactly where Kiro came in.

How I used Kiro

Steering Kiro with Project Context

Before writing any code, I created a steering document. This is a markdown file that tells Kiro about my project's context, constraints, and preferences. This single file made every interaction with Kiro more productive (I am a busy person and only have a couple of hours at the end of each day to work on a project - I can't be wasting time telling Kiro not to do something 100 times.)

What's in My Steering Doc

I created .kiro/steering/project-context.md with five key sections:

1. Project Overview

An interactive web game where kids help a friendly ghost "debug" haunted code 
to save the digital world. Each bug represents a coding concept (loops, 
conditions, logic puzzles) with spooky animations as rewards.

This one paragraph ensured Kiro always remembered:

Target audience: kids
Theme: friendly ghost, Halloween vibes
Educational goal: teach coding concepts

2. Technology Stack

- Frontend: Vite (for fast development and build)
- Infrastructure: AWS CDK (for deployment)
- Language: TypeScript (for all code where possible)
- Lambda Functions: TypeScript with Node.js 20.x runtime

Kiro never suggested alternatives. No webpack. No CRA. No JavaScript. It stayed strictly within the stack.

3. Development Philosophy

This is a **hackathon project** with the following priorities:
- Focus on core functionality and user experience
- Code should be clean and understandable, but doesn't need to be production-grade
- Prioritize speed of development and demonstrable features
- It's okay to use simplified approaches and mock data where appropriate

This was huge. Kiro understood I didn't need:

Exhaustive test coverage (just core functionality)
Enterprise-level error handling
Over-engineered abstractions
Perfect documentation

It optimized for speed and demonstrable features - exactly what a hackathon needs.

4. Implementation Preferences

- **Always use TypeScript** - All code should be written in TypeScript
- **Follow DRY** - Extract common logic into reusable components
- **No Docker** - Avoid Docker dependencies; use local bundling
- **Self-Documenting Code** - Clear naming, minimal comments

These rules shaped every suggestion:

Kiro never used any types - always proper TypeScript
It extracted duplicate code into hooks and utilities automatically
It never suggested Docker for Lambda bundling
Comments only appeared for complex logic, not obvious code

5. TypeScript Guidelines

- Use TypeScript for all new code (frontend, backend, Lambda functions, CDK infrastructure)
- Enable strict mode in tsconfig.json
- Define proper interfaces and types for all data structures
- Use type guards for runtime type checking
- Avoid `any` type - use `unknown` or proper types instead
- Leverage TypeScript's type inference where appropriate

Every file generated aligned with these constraints. Zero surprises.

Strategies That Made the Biggest Difference

1. Be Explicit About Constraints

Instead of: "Use TypeScript"
I wrote: "Always use TypeScript - All code should be written in TypeScript where possible for type safety"

The emphasis and explanation made Kiro prioritize this in every decision.

2. Define Your "Done" Criteria

Quality Standards:
- Tests should cover core functionality only - no need for exhaustive test coverage
- Error handling should be present but can be basic
- Performance optimization is secondary to getting features working

This prevented Kiro from over-engineering. It knew when to stop.

3. State Your Anti-Patterns

- **No Docker** - Avoid Docker dependencies; use local bundling
- **Self-Documenting Code** - Avoid redundant comments

Kiro actively avoided these patterns, instead of me having to correct it (over and over).

4. Include Context About Your Audience

Target Audience: Kids learning coding concepts

This influenced:

Language in UI (simple, encouraging)
Error messages (friendly, not technical)
Educational content (age-appropriate)
Color choices (bright, engaging)

I think it really worked - my 7-year-old keeps wanting to play it.

5. Specify Your Tech Stack Upfront

Kiro never suggested alternatives or asked "should we use X or Y?" It knew the stack and worked within it.

Examples where I used Steering in the Project

Example 1: DRY Principle (Learned the Hard Way)

After building several similar components with repeated code, I realized Kiro wasn't automatically suggesting refactoring. So I added to my steering doc:

- **Follow DRY** - Extract common logic into reusable components

Kiro started proactively refactoring patterns and even generated the usePersistence hook without being asked.

Lesson: If you see a repeated Kiro weakness, add a steering rule.

Example 2: TypeScript

Every generated file had:

interface Props {
  challenge: Challenge;
  onComplete: (success: boolean) => void;
}

// Never:
function handleSubmit(data: any) { ... }

// Always:
function handleSubmit(data: CodeSubmission): void { ... }

Example 3: No Docker

When setting up Lambda bundling, Kiro used:

code: lambda.Code.fromAsset('lambda/polly', {
  bundling: {
    image: lambda.Runtime.NODEJS_20_X.bundlingImage,
    command: ['bash', '-c', 'npm install && cp -r . /asset-output']
  }
})

Native CDK bundling (lightweight phew), no Docker required - exactly as specified. (Why I avoid Docker is another story for another time)

How to Create Effective Steering Docs

Start with these sections:

Project Overview - What are you building? For whom?
Technology Stack - What tools/frameworks are you using?
Development Philosophy - What are your priorities and constraints?
Implementation Preferences - What patterns should Kiro follow/avoid?
Quality Standards - What does "done" look like?

Keep it concise:

My steering doc is ~50 lines
Each rule is 1-2 sentences
Use bold for emphasis on critical rules
Update as you learn what matters

Make it actionable:

Bad: "Write good code"
Good: "Follow DRY - Extract common logic into reusable components"

Include anti-patterns:

What should Kiro NOT do?
What tools should it avoid?
What's out of scope?

The ROI of Steering

15 minutes writing the doc
Hours saved in corrections
Consistent TypeScript, architecture, decisions
No repeated reminders to Kiro
Lower cognitive load

Automating My Workflow with Agent Hooks

One of Kiro's most powerful features is agent hooks - automated workflows that trigger on specific events. I set up four hooks that dramatically improved my development velocity:

1. Auto-run Tests on Save

Every time I saved a TypeScript file, tests automatically ran. This gave me instant feedback:

{
  "name": "Auto-run Tests on Save",
  "when": { "type": "fileEdited", "patterns": ["**/*.ts", "**/*.tsx"] },
  "then": { "type": "runCommand", "command": "npm test -- --run" }
}

Impact: Caught bugs within seconds of writing code. No more "I'll test it later" - testing became automatic.

2. ESLint on Save

Automatic linting kept my code quality high without thinking about it:

{
  "name": "ESLint on Save",
  "when": { "type": "fileEdited", "patterns": ["**/*.ts", "**/*.tsx"] },
  "then": { "type": "runCommand", "command": "npx eslint {{filePath}}" }
}

Impact: Maintained consistent code style across the project. Fixed issues before they made it to commits.

3. Build Validation Check

When I modified core components or configuration, a build automatically triggered:

{
  "name": "Build Validation Check",
  "when": { 
    "type": "fileEdited", 
    "patterns": ["src/components/**/*", "src/engine/**/*", "vite.config.ts"]
  },
  "then": { "type": "runCommand", "command": "npm run build" }
}

Impact: Caught breaking changes immediately. No more "it works on my machine" surprises.

4. CDK Synth Validation (The Smart One)

This hook was special - it triggered Kiro itself to validate infrastructure changes:

{
  "name": "CDK Synth Validation",
  "when": { "type": "fileEdited", "patterns": ["infrastructure/**/*.ts"] },
  "then": { 
    "type": "askAgent",
    "prompt": "Infrastructure code modified. Validate CDK synthesis and check for:
    1. Synthesis errors
    2. CloudFormation issues
    3. IAM policy problems
    4. Breaking changes"
  }
}

Impact: Kiro would automatically run cdk synth, analyze the output, and tell me if my infrastructure changes were valid. It caught IAM permission issues and resource conflicts before I even tried to deploy.

The Compound Effect

These hooks created a continuous validation loop:

Write code → Auto-lint → Auto-test → Auto-build → Get feedback
All within seconds, without manual intervention

This was especially valuable during the hackathon when I was moving fast. The hooks acted as a safety net, catching issues immediately so I could maintain velocity without accumulating technical debt.

Setting Up Hooks

Creating hooks in Kiro is simple - just use the command palette and search for "Kiro Hook UI". You can:

Trigger on file saves, agent completions, or session starts
Run shell commands or ask Kiro to analyze something
Use file patterns to target specific parts of your codebase

For a hackathon project, I recommend starting with:

Auto-run tests on save (catch bugs fast)
Linting on save (maintain quality)
Build validation for critical files (prevent breaking changes)

Spec-Driven Development: Structure Meets Speed

I started with spec-driven development to build the foundation, then switched to vibe coding once the specs were complete. This approach gave me the best of both worlds (in my humble opinion).

What is Spec-Driven Development?

Spec-driven development in Kiro is a structured workflow where you:

Define requirements - User stories with acceptance criteria
Create a design - Architecture, components, data models
Generate tasks - Actionable implementation checklist
Execute incrementally - Kiro implements one task at a time

My Actual Workflow: Spec First, Then Vibe

Phase 1: Spec-Driven Foundation (Days 1-2)

Core game engine and state management
AWS infrastructure with CDK
Challenge system and validation
Basic UI components
Progress tracking and persistence

Phase 2: Vibe Coding Extensions (Days 3-4)

Badge system enhancements
Animation polish and new effects
Voice narration with Polly
Accessibility improvements
UI refinements and styling
GitHub Actions CI/CD (added as a spec when needed)

The Main Game Spec

For the core game, I created a comprehensive spec with:

11 Requirements covering:

Game interface and UX
Challenge system
Animation feedback
Hint system
Progress tracking
Badge system
Accessibility features
Educator dashboard

42 Implementation Tasks including:

Core setup (CDK, Vite, React)
Game engine and state management
UI components
Animation system
Educational content
Accessibility implementation

Spec-Driven vs Vibe Coding: The Comparison

Aspect	Spec-Driven	Vibe Coding
Setup Time	15-30 min (requirements + design)	Immediate
Clarity	Crystal clear roadmap	Figure it out as you go
Complexity	Handles complex features well	Best for simple tasks
Context	Kiro maintains full context	Can lose thread on complex work
Iteration	Structured checkpoints	Continuous refinement
Documentation	Auto-generated	Manual if needed
Best For	Infrastructure, core systems	UI, styling, quick fixes

Why This Workflow Worked Perfectly

Start with Spec = Solid Foundation

Creating the initial spec forced me to think through what features were actually needed, how components would interact, and where complexity would hide. The spec gave me a roadmap with no analysis paralysis and only a little architectural regret (I hate committing sometimes).

Switch to Vibe = Rapid Iteration

Once the foundation was solid, vibe coding let me experiment with animations, try different UI approaches quickly, and add "wow factor" features on the fly.

Around day 2, I had a working game from the spec. Then I switched to vibe coding and added particle burst animations, ghost STT with Polly, badge unlock celebrations, and accessibility options.

The Lesson: Spec the Foundation, Vibe the Features

Day 1: Create a comprehensive spec for your core system. Let Kiro generate the design and task list. Execute foundational tasks methodically to get a "working but basic" state.

Days 2-N: Switch to vibe coding for features, experiments, polish, and quick iterations.

When needed: If a vibe-coded feature gets complex, pause and create a mini-spec.

Starting with a spec prevents architectural walls and wasted refactoring time. Switching to vibe coding after the foundation lets you move fast and stay creative.

What About MCP (Model Context Protocol)?

Kiro supports MCP servers to extend its capabilities with external tools and data sources. I had it configured but honestly? I didn't use it much for this project.

The built-in features (code generation, file operations, AWS knowledge) covered 99% of what I needed. MCP is powerful for specialized workflows (like accessing proprietary APIs or custom data sources), but for a hackathon web game, the core Kiro features were more than enough.

When MCP might have helped:

If I needed real-time data from external APIs
If I was integrating with proprietary systems
If I needed specialized domain knowledge beyond AWS

Why I didn't need it:

Kiro's AWS knowledge was comprehensive
All my data was local (challenge JSON files)
The project was self-contained

MCP is there when you need it, but don't feel like you're missing out if you don't use it. Focus on mastering the core features first.

Final Thoughts

Kiroween challenged me to build something spooky, playful, and creative. Kiro made it possible to build something polished and educational in record time.

Whether you're working on a hackathon project, a side project, or something for production, a steering doc + hybrid development strategy is a game-changer.

Now if you'll excuse me, I have some haunted code to debug with my son... 👻✨

💻 View the code: https://github.com/ChaoticLabs/ghost-in-the-code

Building a Serverless Dungeon Master Agent on AWS

Joanne Skiles — Sun, 28 Sep 2025 18:52:22 +0000

Earlier this month, I couldn't help but think, what if I could have a mini AI-Powered Dungeon Master (DM)? What if I could run game-ready DM in the cloud that remembers your character, generates quests, and scales for free-tier fun? Well, with some finagling (utilizing Amazon Bedrock Agents and serverless building blocks), I created my prototype.

In this walkthrough, I’ll show you how I built this Serverless DM Agent using Amazon Bedrock, Lambda, DynamoDB, API Gateway, and S3. You’ll learn the architecture, see the code, and be able to deploy it yourself with AWS CDK.

And on top of it all, it costs less than a monthly coffee subscription!

Amazon Bedrock Meets Serverless Architecture

The Serverless Dungeon Master Agent is a proof-of-concept that combines Amazon Bedrock's AI capabilities with a fully serverless AWS architecture. Here's what makes it special:

Persistent Character Memory - The AI DM remembers characters stats, inventory, backstory, and every decision you've made. No more "Wait, what happened last session?"
Dynamic Storytelling The AI generates narratives on the fly, adapting to choices and creating unique storylines that respond to characters actions.
Real-time Streaming Responses stream back naturally, creating an immersive conversation flow that feels like chatting with a human DM.
Cost-Effective Gaming Runs around $1-5 per month for casual gameplay.

Architecture + Core Components

At its heart, this project is just a set of AWS services working together:

Amazon Bedrock Agents serve as the brain, handling the AI reasoning, memory management, and action orchestration.
Lambda Functions provide the serverless compute layer:
- session-proxy: Manages agent invocation and streams responses
- game-actions: Handles character CRUD operations and session logging
DynamoDB stores character sheets, game history, and session state with automatic scaling.
API Gateway exposes a clean REST endpoint for game interactions.
S3 Static Website Hosts the lightweight web client where players type their actions.

How it flows

A player types something like: “I sneak past the guards.”
API Gateway forwards that request to the Lambda session proxy.
Lambda calls the Bedrock Agent. The agent either narrates directly or uses an action group (for example, checking a stealth score in DynamoDB).
The DM’s response streams back to the client.

No servers to manage, no overworked innkeeper behind the console. Just a clean, serverless system.

Key Features That Make It Work

Smart Memory Management

The system maintains context across sessions, remembering:

Character progression and stats
Inventory changes
Story decisions and consequences
Campaign history and world state

Adaptive Difficulty

The AI DM adjusts challenges based on characters level and past performance.

Extensible Game Mechanics

Want to add dice rolling, combat systems, or custom rules? The modular Lambda architecture makes it easy to extend functionality.

Getting Started

Prerequisites

Node.js 20+ and AWS CDK v2
AWS Account with Amazon Bedrock access enabled
Bedrock Model Access: Ensure your account has access to your chosen foundation model
AWS CLI configured with appropriate permissions
Python 3.8+ (for local development server) - you can also use the VS Code Extension - Live Server

The deployment process is simple:

# Clone and install
git clone https://github.com/chaotictoejam/serverless-dungeon-master
cd serverless-dungeon-master/dm-agent
npm install

# Deploy with CDK
npx cdk deploy

# Configure and play (optional)
cd ../web
python serve.py

That's it. The AI DM is ready to run its first campaign.

Try It Yourself

The complete source code is available here, including:

Full CDK infrastructure code
Lambda function implementations
Web client for testing
Detailed setup instructions

Whether you're a developer interested in AI applications, a gamer looking for consistent campaigns, or someone curious about serverless architecture, this project demonstrates how modern cloud services can solve real-world problems in creative ways.

The future of tabletop gaming might just be serverless.

Technical Deep Dive

For those interested in the implementation details, here's how the CDK infrastructure brings this AI DM to life:

CDK Stack Architecture

The entire infrastructure is defined in a single CDK stack that orchestrates five key components:

export class DmAgentStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Configuration with flexible model selection
    const fmId = this.node.tryGetContext("fmId") || 
      "us.anthropic.claude-3-7-sonnet-20250219-v1:0";
    const agentName = this.node.tryGetContext("agentName") || "DungeonMaster";

DynamoDB: Game State Persistence

The game state table uses a composite key design for efficient player/session queries:

const table = new dynamodb.Table(this, "DmGameState", {
  tableName: "dmGameState",
  partitionKey: { name: "playerId", type: dynamodb.AttributeType.STRING },
  sortKey: { name: "sessionId", type: dynamodb.AttributeType.STRING },
  billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
  pointInTimeRecoverySpecification: { pointInTimeRecoveryEnabled: true },
});

This design allows:

Multi-session support per player
Efficient queries by player or session
Automatic scaling with pay-per-request billing
Data protection with point-in-time recovery

Bedrock Agent: The AI Brain

The Bedrock Agent configuration defines the DM's personality and capabilities:

const agent = new bedrock.CfnAgent(this, "DmAgent", {
  agentName,
  foundationModel: fmId,
  agentResourceRoleArn: agentServiceRole.roleArn,
  instruction: [
    "You are an AI Dungeon Master. Run safe, imaginative adventures.",
    "Style: concise narration + clear choices. Never reveal tools or raw JSON.",
    "When you need to read or persist game state, call the GameActions tools.",
    "Default to PG-13 content; avoid explicit or unsafe material.",
  ].join(" "),
  idleSessionTtlInSeconds: 900,
  autoPrepare: true,

Action Groups: Game Mechanics Integration

The agent connects to game mechanics through a structured action group:

actionGroups: [{
  actionGroupName: "GameActions",
  description: "Game state operations (DynamoDB-backed)",
  actionGroupExecutor: { lambda: gameActionsFn.functionArn },
  functionSchema: {
    functions: [
      {
        name: "get_character",
        description: "Fetch a player character by playerId + sessionId",
        parameters: {
          playerId: { type: "string", description: "Player identifier", required: true },
          sessionId: { type: "string", description: "Session identifier", required: true },
        },
      },
      {
        name: "save_character",
        description: "Save/replace the player character",
        parameters: {
          playerId: { type: "string", required: true },
          sessionId: { type: "string", required: true },
          character: { type: "string", description: "Character data as JSON", required: true },
        },
      },
      {
        name: "append_log",
        description: "Append a narrative log entry to world state",
        parameters: {
          playerId: { type: "string", required: true },
          sessionId: { type: "string", required: true },
          entry: { type: "string", description: "Log entry text", required: true },
        },
      },
    ],
  },
}],

Lambda Functions: Serverless Compute

Session Proxy Lambda

Handles agent invocation and streams responses:

const sessionProxyFn = new lambdaNode.NodejsFunction(this, "SessionProxyFn", {
  entry: "./lambda/session-proxy/index.ts",
  runtime: lambda.Runtime.NODEJS_20_X,
  timeout: cdk.Duration.seconds(60),
  environment: {
    AGENT_ID: agent.attrAgentId,
    ALIAS_ID: alias.attrAgentAliasId,
  },
});

The session proxy implementation handles streaming responses:

const cmd = new InvokeAgentCommand({
  agentId: AGENT_ID,
  agentAliasId: ALIAS_ID,
  sessionId,
  inputText: contextualInput
});

const response = await bedrockAgent.send(cmd);
let text = '';

for await (const chunkEvent of response.completion) {
  const chunk = chunkEvent.chunk;
  const decodedResponse = new TextDecoder("utf-8").decode(chunk?.bytes);
  text += decodedResponse;
}

Game Actions Lambda

Implements the core game mechanics with DynamoDB operations:

if (fn === "save_character") {
  const { playerId, sessionId, character } = params;
  await ddb.send(
    new UpdateCommand({
      TableName: TABLE,
      Key: { playerId, sessionId },
      UpdateExpression: "SET playerCharacter = :c, lastUpdated = :t",
      ExpressionAttributeValues: { ":c": character, ":t": Date.now() },
    })
  );
  return ok(fn, { status: "saved" });
}

API Gateway: HTTP Interface

The API Gateway configuration enables CORS and connects to the session proxy:

const api = new apigwv2.HttpApi(this, "DmApi", { 
  apiName: "dm-agent-api",
  corsPreflight: {
    allowOrigins: ['*'],
    allowMethods: [apigwv2.CorsHttpMethod.POST, apigwv2.CorsHttpMethod.OPTIONS],
    allowHeaders: ['Content-Type', 'Accept']
  }
});

api.addRoutes({
  path: "/play",
  methods: [apigwv2.HttpMethod.POST],
  integration: new integrations.HttpLambdaIntegration("PlayIntegration", sessionProxyFn),
});

Security & IAM Configuration

The stack implements least-privilege access with specific IAM roles:

const agentServiceRole = new iam.Role(this, "AgentServiceRole", {
  assumedBy: new iam.ServicePrincipal("bedrock.amazonaws.com", {
    conditions: { StringEquals: { "aws:SourceAccount": cdk.Aws.ACCOUNT_ID } },
  }),
});

agentServiceRole.addToPolicy(
  new iam.PolicyStatement({
    actions: [
      "bedrock:InvokeModel",
      "bedrock:InvokeModelWithResponseStream",
      "bedrock:GetFoundationModel",
    ],
    resources: ["*"],
  })
);

Deployment Outputs

The stack provides essential outputs for client configuration:

new cdk.CfnOutput(this, "ApiUrl", { value: api.apiEndpoint! });
new cdk.CfnOutput(this, "AgentId", { value: agent.attrAgentId });
new cdk.CfnOutput(this, "AgentAliasId", { value: alias.attrAgentAliasId });

Key Design Decisions

Single-Table DynamoDB Design: Uses composite keys (playerId + sessionId) for efficient queries while supporting multiple concurrent sessions per player.

Streaming Responses: The session proxy processes Bedrock's streaming responses to provide real-time feedback, crucial for maintaining immersion.

Modular Lambda Architecture: Separates concerns between session management and game actions, enabling independent scaling and easier maintenance.

Pay-Per-Request Billing: All services use on-demand pricing, perfect for unpredictable gaming workloads.

Auto-Prepare Agents: Bedrock agents automatically prepare when deployed, reducing cold-start latency.

Lambda Function Deep Dive

Let's examine the Lambda functions that power the game mechanics and session management:

Session Proxy Lambda: The Gateway

The session proxy acts as the bridge between API Gateway and Bedrock Agent:

import { APIGatewayProxyHandlerV2 } from 'aws-lambda';
import { BedrockAgentRuntimeClient, InvokeAgentCommand } from '@aws-sdk/client-bedrock-agent-runtime';

const bedrockAgent = new BedrockAgentRuntimeClient({ region: "us-east-1" });
const AGENT_ID = process.env.AGENT_ID!;
const ALIAS_ID = process.env.ALIAS_ID!;

export const handler: APIGatewayProxyHandlerV2 = async (event) => {
  const corsHeaders = {
    "Content-Type": "application/json",
    "Access-Control-Allow-Origin": "*",
    "Access-Control-Allow-Methods": "POST,OPTIONS,GET",
    "Access-Control-Allow-Headers": "Content-Type, Accept",
  };

Request Processing

The function validates required parameters and enriches the input with context:

const body = event.body ? JSON.parse(event.body) : {};
const { sessionId, playerId, inputText } = body;

if (!sessionId || !playerId || !inputText) {
  return {
    statusCode: 400,
    headers: corsHeaders,
    body: JSON.stringify({
      error: 'Missing required parameters',
      missing: [!sessionId && 'sessionId', !playerId && 'playerId', !inputText && 'inputText'].filter(Boolean)
    })
  };
}

const contextualInput = `Player ID: ${playerId}, Session ID: ${sessionId}\n\n${inputText}`;

Streaming Response Handling

The core streaming logic processes Bedrock's chunked responses:

const cmd = new InvokeAgentCommand({
  agentId: AGENT_ID,
  agentAliasId: ALIAS_ID,
  sessionId,
  inputText: contextualInput
});

const response = await bedrockAgent.send(cmd);
let text = '';

for await (const chunkEvent of response.completion) {
  const chunk = chunkEvent.chunk;
  const decodedResponse = new TextDecoder("utf-8").decode(chunk?.bytes);
  text += decodedResponse;
}

return {
  statusCode: 200,
  headers: corsHeaders,
  body: JSON.stringify({ reply: text })
};

Key Features:

CORS handling for web client compatibility
Input validation with detailed error responses
Context enrichment to provide player/session info to the agent
Streaming aggregation for complete response assembly
Error handling with structured error responses

Game Actions Lambda: The Persistence Layer

The game actions function implements the core CRUD operations for character and world state:

import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, GetCommand, UpdateCommand } from "@aws-sdk/lib-dynamodb";

const ddb = DynamoDBDocumentClient.from(new DynamoDBClient({}));
const TABLE = process.env.TABLE!;

type AgentParam = { name?: string; key?: string; value: any };
type AgentEvent = {
  actionGroup: string;
  function: string;
  parameters?: AgentParam[];
};

Parameter Processing

The function normalizes Bedrock Agent's parameter format:

function toParamMap(params?: AgentParam[]) {
  const p = params || [];
  const entries = p.map((pp) => [pp.name ?? pp.key, pp.value]);
  return Object.fromEntries(entries);
}

function ok(functionName: string, body: any) {
  return {
    messageVersion: "1.0",
    response: {
      actionGroup: "GameActions",
      function: functionName,
      functionResponse: {
        responseBody: {
          TEXT: {
            body: JSON.stringify(body),
          },
        },
      },
    },
  };
}

Character Management

The get_character function retrieves player data:

if (fn === "get_character") {
  const { playerId, sessionId } = params;
  const res = await ddb.send(
    new GetCommand({
      TableName: TABLE,
      Key: { playerId, sessionId },
    })
  );
  const character = res.Item?.playerCharacter ? JSON.parse(res.Item.playerCharacter) : null;
  return ok(fn, {
    character: character,
    world: res.Item?.world ?? null,
  });
}

The save_character function persists character updates:

if (fn === "save_character") {
  const { playerId, sessionId, character } = params;
  await ddb.send(
    new UpdateCommand({
      TableName: TABLE,
      Key: { playerId, sessionId },
      UpdateExpression: "SET playerCharacter = :c, lastUpdated = :t",
      ExpressionAttributeValues: { ":c": character, ":t": Date.now() },
    })
  );
  return ok(fn, { status: "saved" });
}

World State Logging

The append_log function maintains narrative history:

if (fn === "append_log") {
  const { playerId, sessionId, entry } = params;
  await ddb.send(
    new UpdateCommand({
      TableName: TABLE,
      Key: { playerId, sessionId },
      UpdateExpression:
        "SET #world = if_not_exists(#world, :emptyWorld), #world.#logs = list_append(if_not_exists(#world.#logs, :empty), :e), lastUpdated = :t",
      ExpressionAttributeNames: { "#world": "world", "#logs": "logs" },
      ExpressionAttributeValues: {
        ":e": [entry],
        ":empty": [],
        ":emptyWorld": {},
        ":t": Date.now(),
      },
    })
  );
  return ok(fn, { status: "logged" });
}

Key Features:

Flexible parameter handling for Bedrock Agent compatibility
Atomic updates using DynamoDB UpdateExpressions
Conditional operations with if_not_exists for safe initialization
List operations for appending log entries
Structured responses matching Bedrock Agent expectations
Error handling with graceful fallbacks

Lambda Architecture Benefits

Separation of Concerns: The session proxy handles HTTP/streaming while game actions focus purely on data operations.

Independent Scaling: Each function scales based on its specific workload patterns.

Error Isolation: Failures in one function don't affect the other's operation.

Testability: Pure functions with clear inputs/outputs enable comprehensive testing.

Cost Efficiency: Functions only run when needed, with sub-second billing granularity.

This modular approach demonstrates how serverless functions can create clean, maintainable architectures for complex AI applications.

Development Challenges & Solutions

Building this AI DM wasn't without its hurdles. Here are the key challenges encountered and how they were resolved:

Bedrock Model Access Issues

Problem: Initial deployment failed with "AccessDeniedException" when invoking the foundation model.

Root Cause: Bedrock model access isn't automatically enabled for all AWS accounts. Each foundation model requires an explicit access request.

Solution:

Navigate to AWS Bedrock Console → Model Access
Request access to Claude 3.5 Sonnet (or your chosen model)
Wait for approval (usually instant for standard models)
Update CDK configuration with the correct model ID:

const fmId = "us.anthropic.claude-3-7-sonnet-20250219-v1:0"; // Verify exact model ID

Lesson: Always verify model availability in your target region before deployment.

CORS Configuration Nightmare

Problem: Web client requests failing with CORS errors despite API Gateway CORS configuration.

Root Cause: CORS headers needed in both API Gateway AND Lambda responses for proper browser compatibility.

Solution: Implement CORS at multiple layers:

// API Gateway CORS (CDK)
corsPreflight: {
  allowOrigins: ['*'],
  allowMethods: [apigwv2.CorsHttpMethod.POST, apigwv2.CorsHttpMethod.OPTIONS],
  allowHeaders: ['Content-Type', 'Accept']
}

// Lambda CORS headers (every response)
const corsHeaders = {
  "Access-Control-Allow-Origin": "*",
  "Access-Control-Allow-Methods": "POST,OPTIONS,GET",
  "Access-Control-Allow-Headers": "Content-Type, Accept",
};

// Handle OPTIONS preflight
if (event.requestContext?.http?.method === 'OPTIONS') {
  return { statusCode: 200, headers: corsHeaders, body: '' };
}

Lesson: CORS requires configuration at both the gateway and function levels for web clients.

Lambda Timeout Mysteries

Problem: Bedrock Agent calls timing out with the default 3-second Lambda timeout.

Root Cause: AI model inference can take 10-30 seconds, especially for complex reasoning tasks.

Solution: Increase Lambda timeout and add proper error handling:

const sessionProxyFn = new lambdaNode.NodejsFunction(this, "SessionProxyFn", {
  timeout: cdk.Duration.seconds(60), // Increased from default 3s
  // ... other config
});

Lesson: AI workloads require generous timeout configurations.

Bedrock Agent Parameter Confusion

Problem: Game actions Lambda receiving inconsistent parameter formats from Bedrock Agent.

Root Cause: Bedrock Agent can send parameters with either name or key properties depending on the invocation context.

Solution: Flexible parameter parsing:

function toParamMap(params?: AgentParam[]) {
  const p = params || [];
  const entries = p.map((pp) => [pp.name ?? pp.key, pp.value]);
  return Object.fromEntries(entries);
}

Lesson: Always handle parameter format variations in Bedrock Agent integrations.

DynamoDB Conditional Update Failures

Problem: append_log function failing when trying to append to non-existent lists.

Root Cause: DynamoDB list_append requires the list to exist, but new sessions don't have world.logs initialized.

Solution: Use conditional expressions with if_not_exists:

UpdateExpression: "SET #world = if_not_exists(#world, :emptyWorld), #world.#logs = list_append(if_not_exists(#world.#logs, :empty), :e)"

Lesson: DynamoDB conditional operations are essential for handling uninitialized data structures.

Agent Preparation Race Conditions

Problem: Bedrock Agent not ready immediately after CDK deployment, causing initial invocation failures.

Root Cause: Agent preparation is asynchronous, even with autoPrepare: true.

Solution: Add retry logic and use agent aliases:

const alias = new bedrock.CfnAgentAlias(this, "DmAgentAlias", {
  agentId: agent.attrAgentId,
  agentAliasName: "prod",
});

// Use alias ID instead of agent ID for invocations
environment: {
  AGENT_ID: agent.attrAgentId,
  ALIAS_ID: alias.attrAgentAliasId, // More stable than direct agent calls
}

Lesson: Always use agent aliases for production workloads to ensure stability.

Streaming Response Edge Cases

Problem: Occasional empty responses or incomplete streaming from Bedrock Agent.

Root Cause: Network issues or agent processing errors not properly handled.

Solution: Add comprehensive error handling and fallbacks:

if (response.completion === undefined) {
  throw new Error("BedRock Agent completion is undefined");
}

for await (const chunkEvent of response.completion) {
  const chunk = chunkEvent.chunk;
  if (chunk?.bytes) {
    const decodedResponse = new TextDecoder("utf-8").decode(chunk.bytes);
    text += decodedResponse;
  }
}

if (!text) {
  text = 'No response from agent'; // Fallback for empty responses
}

Lesson: Always validate streaming responses and provide fallbacks for edge cases.

Regional Service Availability

Problem: Bedrock services are not available in all AWS regions, causing deployment failures.

Root Cause: Bedrock has limited regional availability compared to core AWS services.

Solution: Hardcode region or validate availability:

const bedrockAgent = new BedrockAgentRuntimeClient({ region: "us-east-1" }); // Bedrock-supported region

Lesson: Check service regional availability before choosing deployment regions.

Debugging Best Practices

CloudWatch Logs: Essential for debugging Lambda and Bedrock Agent interactions:

console.log('Invoking agent with:', { agentId: AGENT_ID, sessionId, inputText });
console.log('Agent response received:', { hasCompletion: !!response.completion });

Structured Error Responses: Help identify issues quickly:

catch (err: any) {
  console.error('Agent invocation error:', {
    message: err.message,
    code: err.code || err.name,
    agentId: AGENT_ID,
    aliasId: ALIAS_ID
  });
  return {
    statusCode: 500,
    body: JSON.stringify({
      error: 'Agent invocation failed',
      message: err.message,
      code: err.code || 'UnknownError'
    })
  };
}

Testing Strategy: Start with simple inputs before complex game scenarios:

Test basic agent invocation with "Hello"
Verify parameter passing with simple character data
Test streaming with longer responses
Validate error handling with invalid inputs

These challenges highlight the importance of thorough testing, proper error handling, and understanding the nuances of AI service integrations in serverless architectures.

Next Steps: Migration to Amazon Bedrock Agent Core

While the current Bedrock Agents implementation serves as a decent POC, Amazon Bedrock Agent Core offers a more sophisticated framework for building production-grade AI agents.

Why Migrate to Bedrock Agent Core?

Enhanced Control Flow: Agent Core provides fine-grained control over reasoning chains, tool orchestration, and decision-making processes compared to standard Bedrock Agents.
Advanced Memory Management: Built-in support for long-term memory, context compression, and intelligent information retrieval across extended gaming sessions.
Multi-Agent Orchestration: Native support for multiple specialized agents (combat manager, story narrator, rule enforcer) working together seamlessly.
Performance Optimization: Reduced latency through optimized model routing, caching strategies, and parallel processing capabilities.
Enterprise Features: Enhanced monitoring, audit trails, and compliance features essential for production deployments.

Conclusion

Building this Serverless Dungeon Master Agent began as a “what if” idea and evolved into a working and somewhat scalable prototype. By combining Amazon Bedrock with serverless building blocks, I demonstrated how to create an AI-powered DM that remembers, adapts, and entertains—while remaining cost-effective.

Whether you use it as a foundation for your own gaming experiments or as inspiration for other AI-driven applications, the takeaway is clear: serverless architectures make it possible to turn imaginative ideas into practical, low-maintenance solutions.

The future of gaming, and beyond, might just be serverless.

How To Connect a Squarespace Domain to a Website Hosted on GitHub Pages

Joanne Skiles — Sun, 18 May 2025 23:58:57 +0000

If you’ve built a portfolio or project site hosted on GitHub Pages and want to use a custom domain you purchased through Squarespace, you're in luck; this is absolutely doable and takes just a few steps.

This post will walk you through how to point your Squarespace-purchased domain to your GitHub Pages site, whether you're hosting on a user site (yourusername.github.io) or a project site (yourusername.github.io/your-project).

Prerequisites

Before we begin, you should have:

A working site hosted on GitHub Pages
A custom domain purchased via Squarespace (not a Squarespace-hosted website)
Access to GitHub and Squarespace admin panels

Step 1: Determine Your GitHub Pages URL

You'll need your GitHub Pages URL, which will look like one of these:

For user or organization pages:
https://yourusername.github.io/
For project pages:
https://yourusername.github.io/project-name

Make sure your GitHub Pages site is already published and publicly viewable.

Step 2: Add a CNAME File

If you're using a custom domain, GitHub Pages needs to know about it.

In your GitHub repository, create a file called CNAME (no extension).
Inside it, write your custom domain (e.g. www.yourcustomdomain.com)
Commit and push the file to your repo's default branch (usually main or master)

This tells GitHub Pages to expect traffic from that domain.

Step 3: Get Your GitHub Pages IP Addresses

Squarespace doesn’t support CNAME flattening or ALIAS records, so you’ll need to use A records pointing to GitHub’s static IPs.

As of this writing, GitHub Pages uses the following IPs:

185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153

GitHub recommends using all four A records for redundancy.

Step 4: Update DNS Settings in Squarespace

Log in to Squarespace.
Go to Domains and select the domain you purchased.
Click DNS Settings.
Add or update the following DNS records:

Type	Host	Value	TTL
A	@	185.199.108.153	Default
A	@	185.199.109.153	Default
A	@	185.199.110.153	Default
A	@	185.199.111.153	Default
CNAME	www	yourusername.github.io	Default

This will:

Point the root domain (yourcustomdomain.com) to GitHub Pages
Point www.yourcustomdomain.com to GitHub via CNAME

⚠️ Note: Squarespace might already have default records— delete any existing A or CNAME records that conflict.

Step 5: Wait for DNS Propagation

DNS changes can take anywhere from a few minutes to 24–48 hours to fully propagate. You can use tools like whatsmydns.net to track progress.

Step 6: Verify the Setup

After DNS has propagated, go to your custom domain in a browser. You should see your GitHub Pages site served through your domain!

Troubleshooting Tips

Getting a 404? Make sure your GitHub Pages is publishing from the correct branch.
Still loading Squarespace? Clear DNS cache and check that the default Squarespace records were removed.
Mixed content warnings? Make sure your GitHub site supports HTTPS (GitHub Pages offers this for free).

Conclusion

Connecting a Squarespace domain to your GitHub Pages site gives you the best of both worlds: a professional domain and free static hosting. With a few DNS tweaks and a CNAME file, your project will be live and looking sharp.

Happy coding!

Getting Started with AWS: Tips That Actually Helped Me

Joanne Skiles — Wed, 09 Apr 2025 19:02:35 +0000

When I first started learning AWS, I remember staring at the endless list of services and wondering, Where do I even begin?

It’s easy to feel overwhelmed with all the options—EC2, S3, Lambda, CloudFormation, IAM, Route 53, etc. The good news? You don’t have to master everything at once. AWS is powerful, but the learning journey doesn’t need to be intimidating.

Here are some practical AWS learning tips that helped me—and I hope they’ll help you, too.

1. Start with the Basics

Before diving into every shiny new service, it’s important to build a solid foundation. Understanding the core AWS services will give you the context and confidence to explore more advanced tools later on. These core services include:

EC2 (Elastic Compute Cloud): Think of this as your virtual machine in the cloud. If you understand how a typical server works, you can grasp EC2 fairly quickly.
S3 (Simple Storage Service): This is AWS's highly scalable object storage service. It’s great for storing static assets, backups, and even hosting static websites.
IAM (Identity and Access Management): One of the most crucial services to understand early. IAM helps you manage permissions securely across your AWS account.
Lambda: AWS's serverless compute service that lets you run code without provisioning or managing servers. Great for automating small tasks or building microservices.

Taking the time to truly understand how these services work and how they connect to one another can save you hours (if not days) down the road.

Helpful links:

2. Get Hands-On as Early as Possible

Watching tutorials and reading documentation are helpful, but nothing beats actually using the services. AWS offers a very interactive experience through its Console, and getting hands-on will reinforce your learning.

A good beginner project? Deploying a simple Lambda function. Here’s an example in Python:

# A simple AWS Lambda function in Python
def lambda_handler(event, context):
    return {
        'statusCode': 200,
        'body': 'Hello from Lambda!'
    }

This function can be tested directly in the AWS Console. It might seem simple, but running your own code in the cloud is empowering and builds your confidence to try more complex things.

Also try:

Hosting a static website using S3
Creating an EC2 instance and connecting to it via SSH
Writing a basic IAM policy

3. Take Advantage of the Free Tier (Just Don’t Forget to Clean Up)

The AWS Free Tier is your best friend as a beginner. It gives you access to many services for free for the first 12 months (and some forever).

You can:

Run EC2 instances (750 hours/month for t2.micro or t3.micro)
Store 5GB in S3
Execute 1M Lambda requests
Store 25 GB on DynamoDB

BUT… always remember to shut things down when you're done. AWS doesn’t always send big alerts for charges. Use the Billing Dashboard and set up alerts through the AWS Budgets feature.

Trust me, the first surprise bill is not a fun milestone.

4. Certifications Are Great—But Don’t Let Them Be the Only Goal

AWS certifications like Solutions Architect Associate are valuable, especially for structuring your learning.

But don't fall into the trap of memorizing for exams without understanding the "why" behind each service. Real-world projects give context to that knowledge and help it stick. Combine cert prep with actual building.

Try:

Going through AWS Skill Builder's free training
Pairing Udemy courses or A Cloud Guru content with personal projects
Taking notes in your own words after every study session

Recommended free study resources:

5. You Don’t Have to Learn Everything

There are over 200 AWS services. Nobody expects you to know them all.

Instead, focus on what aligns with your goals:

Web developer? Learn S3, CloudFront, API Gateway, and Lambda.
Backend engineer? Dive into DynamoDB, RDS, and ECS.
DevOps or Infra-focused? Master CloudFormation, IAM, and CodePipeline.

Use AWS’s Architecture Center to browse common use cases and decide where to focus.

Let your learning be project-driven, not list-driven.

6. Find Community

Learning in isolation is tough. Thankfully, the AWS community is one of the most active and supportive in tech. Engage with others to stay motivated and solve problems faster.

Places to connect:

AWS User Groups
r/aws on Reddit
LinkedIn hashtags like #AWSCommunity and #BuildOnAWS

Ask questions, share your projects, and don’t hesitate to say, "I don’t get this yet."

Final Thoughts

AWS can feel like a lot—because it is. But if you take it one step at a time, keep building, and stay connected to a supportive community, you’ll get there.

Whether you're just starting or picking things back up, remember that cloud skills are built one small project at a time.

What AWS tip helped you the most? Share it—I'd love to learn from your journey too.

Why Everyone* Should Learn About Cloud Computing and AI

Joanne Skiles — Fri, 28 Mar 2025 14:48:50 +0000

Yesterday, I hosted an Orlando AWS User Group meetup at UCF. We had a great turnout, but as always, I bought way too much pizza (I blame my upbringing, which is that everyone must eat until they are completely stuffed). So, as we were wrapping up, I started handing out slices to anyone nearby.

One of those lucky recipients was a student majoring in film. As we chatted, I could tell they were curious about the tech buzz in the room. But the unspoken question lingered:

Why should someone in film care about AWS or cloud computing at all?

Here’s my answer, not just for that student but for everyone reading this:

You need to learn about cloud computing.
And you really need to learn about AI.

The Future Isn't Coming—It's Already Here

We tend to associate cloud computing with software engineers, system architects, and DevOps folks. But the truth is, the cloud is powering everything—from the apps on your phone to the CGI rendering engines in your favorite blockbuster films.

AI? It's not just for techies in lab coats anymore. It’s generating storyboards, editing footage, optimizing marketing campaigns, and even editing scripts.

Why It Matters—No Matter Your Major

Whether you’re in film, marketing, healthcare, agriculture, education, or any other industry—cloud and AI are the invisible engines behind today’s innovation.

In film, cloud services like AWS render farms help produce high-quality visuals faster and cheaper. AI tools are revolutionizing editing workflows, enhancing sound design, and creating personalized viewer experiences.
In education, AI is shaping personalized learning paths. Cloud computing supports scalable platforms for remote learning.
In healthcare, AI is accelerating diagnostics, predicting disease outbreaks, and improving patient outcomes. Cloud platforms store and process massive amounts of medical data securely—enabling faster research and collaboration across the globe.
In marketing, machine learning predicts trends, automates campaigns, and analyzes customer behavior in real time.
In farming and agriculture, AI is driving precision farming—analyzing soil data, monitoring crop health with drones, and optimizing irrigation. The cloud powers real-time dashboards and data pipelines that help farmers make smarter decisions and improve yields sustainably.
In business, data-driven decisions are no longer optional. They're critical. And where does all that data live? You guessed it—the cloud.

You Don’t Have to Be a Coder to Be Cloud-Literate

Knowing the basics of cloud computing doesn't mean you have to spin up an EC2 instance tomorrow (though that would be cool). It means understanding how modern tools work so you can make informed decisions, collaborate better with technical teams, and stay competitive in your field.

AI literacy is becoming just as essential. With generative tools, prompt engineering, and low-code/no-code platforms, you don’t have to be an ML expert to harness the power of artificial intelligence—but you do need to understand what’s happening under the hood at a high level.

And yes, you don’t have to be a coder, but please don’t just start "vibe" coding. I’ve seen it too many times: folks diving into tools and services without understanding the underlying principles. You will have a bad time if you don’t understand the fundamentals. Take the time to learn the “why” behind the tech. It will save you countless hours and headaches later.

Because let’s be real—just clicking around in the AWS console without a plan is like getting behind the wheel without learning how to drive—sooner or later, something’s going to crash.

“But I’m a Hermit on a Mountain-Top…”

Ok, fine—you probably don’t need to learn about cloud computing if you’re truly off-grid, living that solar-powered, goat-herding, no-internet life (i.e. every Senior Engineer's dream).

But… I have a question.
How are you reading this post? 🤔

If you’re connected enough to be scrolling dev.to, LinkedIn, or whatever platform you found a link to this post on, then you’re already participating in a cloud-powered world.

It’s okay to be skeptical of change. It’s healthy, even. But if you don’t want to make yourself obsolete, you’ve got to be willing to learn. You don’t have to chase every shiny new tool, but being a Luddite to all new tech won’t serve you either.

Adaptation isn't just for survival—it’s for thriving.

Final Thought: Curiosity Is Your Superpower

That film student didn’t come to school that day expecting a tech pitch, but they walked away thinking a little differently. And that’s all it takes—a spark of curiosity.

So, if you’re reading this and you think cloud computing and AI aren’t for you, I challenge you to reconsider. Start small. Watch a YouTube video. Try a beginner-friendly course. Come to a user group meetup (we’ll have pizza 🍕).

The future belongs to the curious—and the cloud-enabled.

Multi-Region Data Replication with Amazon DynamoDB Global Tables

Joanne Skiles — Tue, 11 Mar 2025 14:20:47 +0000

Ensuring data consistency and availability across multiple AWS regions is critical. Amazon DynamoDB Global Tables provide a fully managed solution for multi-region data replication, enabling low-latency access, high availability, and disaster recovery. This post explores how to implement DynamoDB Global Tables for a resilient and scalable architecture, along with a real-world example.

Why Use DynamoDB Global Tables?

Using DynamoDB Global Tables for multi-region data replication offers several benefits:

Low-Latency Reads and Writes: Users access the nearest region for faster responses.
High Availability: Data remains accessible even if one region experiences downtime.
Automatic Conflict Resolution: DynamoDB ensures consistency across regions.
Scalability: Supports high-throughput applications with minimal operational overhead.

Key Strategies for Multi-Region Data Replication

1. Setting Up DynamoDB Global Tables

DynamoDB Global Tables automatically replicate data across selected AWS regions, providing a seamless experience for distributed applications.

Steps to Create a DynamoDB Global Table:

Create a table in one AWS region.
Enable global table replication and select additional regions.
DynamoDB handles data replication automatically.

Example AWS CLI Command to Create a Global Table:

aws dynamodb create-table \
  --table-name UserProfiles \
  --attribute-definitions AttributeName=UserID,AttributeType=S \
  --key-schema AttributeName=UserID,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST \
  --region us-east-1

aws dynamodb update-table \
  --table-name UserProfiles \
  --replica-updates '[{"Create": {"RegionName": "eu-west-1"}}]'

2. Handling Multi-Region Reads and Writes

Applications should always read from and write to the nearest DynamoDB replica for optimal performance. AWS SDKs support endpoint discovery to dynamically route requests to the closest region.

Example API Call in Python Using Boto3:

import boto3

dynamodb = boto3.resource('dynamodb', region_name='us-east-1')
table = dynamodb.Table('UserProfiles')

# Write data
table.put_item(Item={'UserID': '123', 'Name': 'Alice', 'Region': 'US'})

# Read data
response = table.get_item(Key={'UserID': '123'})
print(response['Item'])

3. Ensuring Conflict Resolution

DynamoDB Global Tables use last writer wins (LWW) conflict resolution by default. Applications should:

Implement timestamps to track data changes.
Use event-driven mechanisms (e.g., AWS Lambda + DynamoDB Streams) to resolve conflicts if needed.

Real-World Example: A Global E-Commerce Platform

An e-commerce company with customers across North America and Europe requires a distributed user profile database to enhance customer experience.

Architecture Breakdown:

DynamoDB Global Tables
- Stores user profiles replicated across us-east-1 and eu-west-1.
- Ensures user data is available with minimal latency.
API Gateway & Route 53
- Routes API requests to the nearest region.
CloudFront Caching
- Improves response times for frequently accessed profile data.
AWS CloudWatch & X-Ray
- Monitors performance and detects anomalies.

Benefits for Users:

Faster profile updates and retrievals based on their location.
Seamless experience even if a region goes offline.
Real-time data consistency across multiple geographies.

Conclusion

Using Amazon DynamoDB Global Tables for multi-region data replication ensures high availability, scalability, and low-latency access for global applications. By implementing region-aware API calls, conflict resolution strategies, and automatic failover mechanisms, businesses can provide a seamless experience for users worldwide.

In the next post, we’ll explore multi-region event-driven architectures using Amazon SNS and SQS to distribute real-time messages across regions.

Have you used DynamoDB Global Tables in your projects? Share your thoughts and questions in the comments!

Global API Management with API Gateway and Route 53

Joanne Skiles — Tue, 18 Feb 2025 16:54:08 +0000

When you have a global application, providing a seamless, low-latency experience to users worldwide is crucial. By deploying regional AWS API Gateway endpoints and using Amazon Route 53 for latency-based routing, you can ensure fast response times, high availability, and robust failover mechanisms. This post explores how to implement global API management with AWS services and provides a real-world example. If this looks familiar, you're right, some of this we touched on in the previous post.

Why Use Multi-Region API Gateways?

Deploying API Gateway in multiple AWS regions and managing routing with Route 53 offers key benefits:

Low Latency: Directs users to the nearest API endpoint for faster response times.
High Availability: Ensures service continuity even if one region experiences downtime.
Better Performance Scaling: Distributes API traffic efficiently across multiple regions.
Compliance & Data Sovereignty: Supports data sovereignty requirements by processing requests in specific regions.

Key Strategies for Global API Management

To effectively manage global APIs, follow these best practices:

1. Deploy Regional API Gateway Endpoints

Instead of relying on a single API Gateway instance, deploy regional API Gateway endpoints in multiple AWS regions. This allows:

Traffic to be processed closer to the user.
More control over caching and data processing in each region.
Better fault tolerance by avoiding a single point of failure.

Example AWS CLI Commands for API Gateway Deployment:

# Deploy an API Gateway in US-East-1
aws apigateway create-rest-api --name "ExchangeAPI-US" --region us-east-1

# Deploy an API Gateway in EU-West-1
aws apigateway create-rest-api --name "ExchangeAPI-EU" --region eu-west-1

2. Use Amazon Route 53 Latency-Based Routing

Amazon Route 53 can direct users to the API Gateway endpoint with the lowest latency. This is achieved using latency-based routing policies, which evaluate where a request originates and send it to the closest AWS region.

Example Route 53 Configuration:

US-based users are routed to the API Gateway in us-east-1.
European users are routed to the API Gateway in eu-west-1.
If one region is unavailable, failover routing directs traffic to the next best available region.

Example AWS CLI Command for Route 53 Record Setup:

aws route53 change-resource-record-sets --hosted-zone-id Z123456ABCDEFG \
  --change-batch '{
    "Changes": [
      {
        "Action": "UPSERT",
        "ResourceRecordSet": {
          "Name": "api.example.com",
          "Type": "A",
          "SetIdentifier": "US Region",
          "Region": "us-east-1",
          "TTL": 60,
          "ResourceRecords": [{"Value": "192.0.2.1"}]
        }
      },
      {
        "Action": "UPSERT",
        "ResourceRecordSet": {
          "Name": "api.example.com",
          "Type": "A",
          "SetIdentifier": "EU Region",
          "Region": "eu-west-1",
          "TTL": 60,
          "ResourceRecords": [{"Value": "192.0.2.2"}]
        }
      }
    ]
  }'

3. Implement Failover Routing for High Availability

If one region becomes unavailable, Route 53 failover routing ensures API traffic is redirected to an operational region. This setup improves resilience by:

Using health checks to monitor API availability.
Automatically switching traffic in case of failures.

Example Route 53 Health Check Configuration:

aws route53 create-health-check --caller-reference "api-healthcheck" \
  --health-check-config '{
    "IPAddress": "192.0.2.1",
    "Port": 443,
    "Type": "HTTPS",
    "ResourcePath": "/status",
    "RequestInterval": 30,
    "FailureThreshold": 3
  }'

Real-World Example: Fintech Currency Exchange API

A fintech company offering real-time currency exchange services needs a globally distributed API to provide users with the latest exchange rates instantly.

Architecture Breakdown:

API Gateway
- Deploys regional API Gateway endpoints in us-east-1 and eu-west-1.
- Handles user requests efficiently based on their location.
Route 53 (Latency-Based Routing)
- Directs requests to the closest API endpoint.
- Uses failover routing in case of outages.
AWS Lambda (Currency Rate Processing)
- Fetches live exchange rates from a data provider.
- Processes calculations before returning results.
Amazon DynamoDB Global Tables
- Stores exchange rate history across regions.
- Provides data consistency with real-time replication.
CloudWatch & X-Ray
- Monitors API performance and logs request traces.

Benefits for Users:

Fast response times due to latency-based routing.
Minimal service disruptions with automatic failover.
Accurate exchange rates retrieved in real-time.

Conclusion

Implementing global API management with API Gateway and Route 53 ensures low-latency, highly available, and scalable API services. By leveraging latency-based routing, failover mechanisms, and regional API deployments, businesses can improve user experience and reliability.

In the next post, we’ll explore using DynamoDB Global Tables for multi-region data replication to ensure real-time consistency across distributed applications.

Deploying Serverless Functions Across Regions with AWS Lambda

Joanne Skiles — Wed, 12 Feb 2025 01:06:30 +0000

Providing seamless user experiences across different regions is crucial in a globalized digital world. Deploying AWS Lambda functions in multiple regions ensures low latency, high availability, and better fault tolerance. This post will explore deploying serverless functions effectively across AWS regions, focusing on best practices, automation strategies, and a real-world example.

Why Deploy AWS Lambda Functions Across Regions?

Deploying serverless functions across multiple AWS regions offers several advantages:

Reduced Latency: Users in different geographic locations experience faster response times.
Improved Availability: Ensures business continuity in case of regional failures.
Compliance & Data Sovereignty: Some applications require region-specific processing due to legal and regulatory requirements.
Scalability & Redundancy: Balances workloads and provides failover mechanisms in case of outages.

Key Strategies for Multi-Region AWS Lambda Deployment

To efficiently deploy AWS Lambda functions across multiple regions, follow these best practices:

1. Use Infrastructure as Code (IaC) with AWS CloudFormation or Terraform

Managing multi-region deployments manually can be error-prone and inefficient. Using IaC tools like CloudFormation or Terraform allows you to:

Define Lambda functions, API Gateway endpoints, IAM roles, and other resources in code.
Maintain consistent deployments across regions.
Automate rollbacks and version control.

Example Terraform Code for Multi-Region Deployment

provider "aws" {
  region = "us-east-1"
}

resource "aws_lambda_function" "lambda_us" {
  function_name    = "reservation-processor"
  handler         = "index.handler"
  runtime         = "nodejs18.x"
  role            = aws_iam_role.lambda_exec.arn
  filename        = "lambda.zip"
}

provider "aws" {
  alias  = "eu"
  region = "eu-west-1"
}

resource "aws_lambda_function" "lambda_eu" {
  provider        = aws.eu
  function_name   = "reservation-processor"
  handler         = "index.handler"
  runtime         = "nodejs18.x"
  role            = aws_iam_role.lambda_exec.arn
  filename        = "lambda.zip"
}

2. Implement CI/CD Pipelines with AWS CodePipeline or GitHub Actions

Automating deployments ensures consistency and reduces manual errors. A CI/CD pipeline:

Deploys Lambda functions to multiple regions automatically.
Allows rollbacks in case of failures.
Ensures version control and controlled releases.

Example GitHub Actions Workflow for Multi-Region Deployment

name: Deploy Multi-Region Lambda

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v3

      - name: Deploy to US-East-1
        run: aws lambda update-function-code --function-name reservation-processor --zip-file fileb://lambda.zip --region us-east-1

      - name: Deploy to EU-West-1
        run: aws lambda update-function-code --function-name reservation-processor --zip-file fileb://lambda.zip --region eu-west-1

3. Use AWS Lambda Versions and Aliases for Controlled Releases

AWS Lambda allows function versioning and aliasing for better deployment control. You can:

Maintain multiple versions of a function.
Use aliases like production, staging, or beta to route traffic gradually.
Implement blue-green deployments to minimize downtime.

Example AWS CLI Commands for Versioning and Aliases

# Publish a new version
aws lambda publish-version --function-name reservation-processor --region us-east-1

# Create an alias pointing to the new version
aws lambda create-alias --function-name reservation-processor --name production --function-version 2 --region us-east-1

Case Study: Travel Booking Application

In my last post, we discussed a global travel booking platform that processes flight and hotel reservations. To provide fast and reliable service, the company would need to deploy its reservation-processing Lambda function in both North America (us-east-1) and Europe (eu-west-1).

Architecture Breakdown:

API Gateway routes requests to the closest region using latency-based routing via Amazon Route 53.
Lambda functions in both regions handle reservation processing.
DynamoDB Global Tables ensure real-time data replication across regions.
CloudWatch and X-Ray provide monitoring and tracing for performance insights.

Benefits for Users:

A traveler booking a flight from New York gets routed to us-east-1, experiencing low latency.
A traveler booking from London gets routed to eu-west-1, ensuring fast processing.
In case us-east-1 goes down, requests automatically fail over to eu-west-1.

Conclusion

Deploying AWS Lambda functions across multiple regions enhances performance, availability, and compliance for global applications. By leveraging Infrastructure as Code, CI/CD automation, and version control, you can ensure a scalable and resilient architecture.

In the next post, we’ll explore global API management using API Gateway and Route 53 to efficiently direct user traffic across regions.

Going Global with Serverless: Multi-Region Architectures on AWS

Joanne Skiles — Tue, 04 Feb 2025 20:48:31 +0000

In today’s fast-paced digital landscape, ensuring low latency and high availability for users worldwide is crucial. Whether you're building a SaaS product, an e-commerce platform, or a real-time data processing system, a multi-region serverless architecture on AWS can help you achieve global reach with minimal operational overhead. In this post, we'll explore strategies for designing multi-region serverless applications on AWS, including best practices, challenges, and key services to leverage.

Why Go Multi-Region?

A multi-region architecture enables your application to:

Reduce Latency: Serve users closer to their geographic location for faster response times.
Improve Availability: Ensure business continuity by distributing workloads across multiple regions.
Enhance Disaster Recovery: Avoid single points of failure by leveraging AWS’s global infrastructure.
Meet Compliance Requirements: Store and process data in specific regions to comply with regulations.

Core AWS Services for Multi-Region Serverless

AWS provides several services that facilitate building a scalable and resilient multi-region serverless architecture:

Amazon API Gateway & AWS Lambda: Deploy API endpoints and backend functions across multiple regions to serve requests locally.
Amazon Route 53: Implement latency-based routing to direct users to the nearest AWS region.
Amazon DynamoDB Global Tables: Replicate data automatically across multiple regions to provide low-latency reads and high availability.
Amazon S3 with Cross-Region Replication (CRR): Sync data across regions to ensure redundancy and minimize delays.
AWS Step Functions: Orchestrate workflows across multiple regions with stateful execution.
Amazon EventBridge & SNS/SQS: Enable cross-region event-driven communication between serverless components.

Designing a Multi-Region Serverless Architecture

1. Deploying Serverless Functions Across Regions

AWS Lambda allows you to deploy functions in multiple regions. To manage deployments effectively:

Use Infrastructure as Code (IaC) with AWS CloudFormation or Terraform.
Implement CI/CD pipelines with AWS CodePipeline or GitHub Actions.
Use AWS Lambda versions and aliases for controlled releases across regions.
Example: A travel booking application can deploy its reservation processing Lambda functions in both North America and Europe to ensure users experience low latency when making bookings.

2. Global API Management with API Gateway and Route 53

Deploy regional API Gateway endpoints in multiple AWS regions.
Use Route 53 latency-based routing to direct users to the closest API endpoint.
Implement failover routing to ensure availability in case of regional failures.
Example: A fintech company providing currency exchange services can deploy API Gateway endpoints in multiple regions to process requests quickly, ensuring users always get the latest exchange rates with minimal delays.

3. Data Synchronization with DynamoDB Global Tables

Store data in a multi-region DynamoDB Global Table to provide fast reads/writes globally.
Ensure conflict resolution strategies in case of simultaneous writes in different regions.
Monitor replication lag using AWS CloudWatch.
Example: A multiplayer gaming platform can use DynamoDB Global Tables to synchronize player stats and leaderboard updates across different continents, ensuring a seamless experience for global users.

4. Cross-Region Event Processing with EventBridge and SQS

Use Amazon EventBridge to forward events between regions.
Leverage Amazon SNS and SQS for decoupled messaging between services.
Implement deduplication and idempotency in Lambda functions processing cross-region events.
Example: An IoT-based smart home system can use EventBridge to process sensor data from devices in multiple regions, triggering automated responses like turning on lights or adjusting thermostats in real-time.

5. Storage & Caching Optimization

Utilize Amazon S3 with CRR to synchronize static assets across regions.
Deploy Amazon CloudFront as a global CDN to cache and serve content efficiently.
Implement Amazon ElastiCache (Redis/Memcached) for reducing database load.
Example: A video streaming platform can use S3 with Cross-Region Replication to distribute video content to different regions and CloudFront to ensure optimal streaming performance.

Challenges & Mitigation Strategies

1. Data Consistency

Challenge: Replicating data across regions can introduce delays and conflicts.
Solution: Design for eventual consistency and use DynamoDB conflict resolution mechanisms.

2. Increased Complexity

Challenge: Managing infrastructure across multiple regions requires additional configuration.
Solution: Automate deployments using Infrastructure as Code (IaC) and CI/CD pipelines.

3. Cost Management

Challenge: Running services in multiple regions can increase operational costs.
Solution: Optimize resources with AWS Cost Explorer and leverage on-demand pricing models.

Wrap Up

A well-designed multi-region serverless architecture can significantly improve performance, availability, and resilience for global applications. By leveraging AWS services like Lambda, API Gateway, DynamoDB Global Tables, and EventBridge, you can build scalable solutions with minimal maintenance overhead. While challenges exist, implementing best practices for data replication, routing, and event-driven communication ensures a robust and cost-efficient architecture.

In the upcoming posts, we'll dive deeper into each of the multi-region scenarios discussed in this article. I’ll provide hands-on examples, architecture diagrams, and implementation guides to help you build global-ready serverless applications.

In the meantime, are you building a multi-region serverless application on AWS? Share your experiences and challenges in the comments below!

15 Git Tips You Should Know

Joanne Skiles — Thu, 30 Jan 2025 18:35:03 +0000

Git is an essential tool in every developer's workflow, but are you using it to its full potential? In this post, I want to discuss some of my favorite Git tips to improve productivity and make you look like a Git wizard.

1. Undo the Last Commit Without Losing Changes

Made a mistake in your last commit? You can undo it while keeping your changes staged:

git reset --soft HEAD~1

This resets the commit but preserves your work so you can fix and recommit.

2. Stash Selectively

Sometimes you only want to stash specific files. Use:

git stash push -m "Partial changes" <file1> <file2>

This stashes only the specified files, keeping the rest of your work intact.

3. Find Out Who Changed What and When

Curious about who introduced a bug? Use git blame:

git blame <file>

It shows the commit hash, author, and date for each line of the file.

Be careful though you might find out you're the problem

4. Clean Up Your Commit History with Interactive Rebase

Want a cleaner commit history? Use interactive rebase to combine, edit, or reorder commits:

git rebase -i HEAD~<number-of-commits>

This allows you to squash multiple commits into one or rewrite commit messages.

5. Quickly Check Out Previous Branches

Switching back and forth between branches? Use git checkout - to quickly switch to your previous branch:

git checkout -

It saves time when you’re toggling between two branches.

6. Diff Changes Before Staging

Before staging changes, review what you’ve modified:

git diff

Want to see changes in a specific file?

git diff <file>

This ensures you’re only committing what you intend to.

7. Fix the Last Commit

Forgot to add something to your last commit? Use:

git commit --amend

This lets you modify the most recent commit, whether it’s adding files or updating the message.

8. Find and Fix Typos in Commit Messages

Typos in commit messages happen to the best of us. If it’s in the latest commit, use:

git commit --amend -m "New message"

If the typo is in an older commit, use git rebase -i and update the message there.

9. Use `git log` Like a Pro

Tired of scrolling through a wall of commits? Customize your git log output:

git log --oneline --graph --decorate --all

This gives you a visual representation of your branch history with concise commit messages.

10. Restore Deleted Branches

Accidentally deleted a branch? If it wasn’t pushed, you can recover it:

git reflog  
git checkout -b <branch-name> <commit-hash>

Find the commit hash from the reflog output and recreate the branch.

11. Resolve Merge Conflicts Faster

Merge conflicts are inevitable, but you can make them easier to handle. Use:

git merge --abort

This stops the merge and resets your branch to its pre-merge state if things get messy.

Alternatively, try a graphical merge tool:

git mergetool

12. Pull Without Merge Commits

Avoid unnecessary merge commits when pulling changes by using:

git pull --rebase

This keeps your history clean and linear.

13. Track Down a Bug Using `git bisect`

Isolating bugs in large codebases can be daunting. Use git bisect to find the commit where things went wrong:

git bisect start  
git bisect bad  
git bisect good <commit>

Git will automatically narrow down the commit range for you to test.

14. Trigger CI/CD Pipelines Without Changing Code

Ever needed to re-run your CI/CD pipeline without making any code changes? Instead of pushing random changes, you can use an empty commit:

git commit --allow-empty -m "Trigger pipeline rerun"  
git push

This creates a commit without modifying any files, letting you trigger the pipeline cleanly.

15. Create Lightweight Aliases for Common Commands

Speed up your workflow by creating Git aliases:

git config --global alias.co checkout  
git config --global alias.br branch  
git config --global alias.st status

Now you can type git co, git br, or git st instead of the full commands.

Git is a powerhouse of features—these tips are just the beginning. Incorporate them into your workflow and see the difference they make!

Do you have a favorite Git tip or trick? Drop it in the comments and share your wisdom!

Event-Driven Design: Choosing Between SNS, SQS, and EventBridge

Joanne Skiles — Thu, 23 Jan 2025 02:02:38 +0000

Event-driven design is a cornerstone of modern application architecture, especially in serverless systems where decoupled components must communicate efficiently.

In the world of AWS there are three messaging and event-routing services:

Amazon Simple Notification Service (SNS)
Amazon Simple Queue Service (SQS)
Amazon EventBridge.

Each service excels in different scenarios, therefore understanding their nuances can help you design robust and scalable solutions.

Amazon SNS: Publish/Subscribe Messaging

Amazon SNS is a fully managed publish/subscribe (pub/sub) service. It allows a publisher to send messages to multiple subscribers simultaneously.

Key Features:

Broadcast Messaging: SNS pushes messages to multiple subscribers in real-time.
Multiple Protocol Support: Subscribers can receive messages over HTTP/S, email, SMS, or AWS services like Lambda and SQS.
Fan-Out Pattern: Combine SNS with SQS to ensure message durability while maintaining pub/sub communication.

When to Use SNS:

Real-Time Updates: Notify multiple systems or users about an event immediately (e.g., sending order confirmation emails and updating a dashboard).
Fan-Out Architecture: Distribute messages to multiple processing pipelines (e.g., log processing, alerting systems).
Cross-Region Notifications: Enable globally distributed applications to communicate efficiently.

Example:

A news publishing platform uses SNS to notify users of breaking news. Each subscriber chooses a preferred delivery channel—email, SMS, or mobile push notifications.

Example Architecture:

Amazon SQS: Decoupled Queuing

Amazon SQS is a fully managed message queuing service. It decouples components of distributed systems, allowing them to communicate asynchronously.

Key Features:

Message Durability: Messages are stored until they are processed or expire.
Processing Guarantee: Messages are delivered at least once (Standard Queue) or exactly once (FIFO Queue).
Scalability: Supports massive throughput and unlimited queue size.

When to Use SQS:

Task Queues: Process tasks asynchronously, such as image processing or order fulfillment.
Message Retention: Ensure messages are not lost if a consumer is temporarily unavailable.
Rate Limiting: Buffer requests to avoid overwhelming downstream systems.

Example:

An e-commerce platform uses SQS to manage order processing. Orders are added to a queue and processed asynchronously by a fleet of worker instances.

Example Architecture:

Amazon EventBridge: Event Bus for Rule-Based Routing

Amazon EventBridge is an event bus service that allows you to ingest and route events from various sources based on customizable rules.

Key Features:

Event Routing: Route events to multiple targets based on rules.
Integrated Sources: Ingest events from AWS services, SaaS applications, or custom applications.
Schema Discovery: Automatically discover and use schemas for events.

When to Use EventBridge:

Event-Driven Workflows: Trigger workflows or orchestrate tasks based on specific event patterns (e.g., serverless pipelines).
Complex Routing: Implement fine-grained routing logic for event processing.
Integrating SaaS Applications: Easily connect third-party SaaS events into your workflows.

Example:

A logistics company uses EventBridge to trigger a Lambda function when a shipment's status changes in its tracking system, enabling real-time notifications to customers and automated updates to internal dashboards.

Example Architecture:

Choosing the Right Service

The choice between SNS, SQS, and EventBridge depends on your use case:

Feature	SNS	SQS	EventBridge
Message Type	Pub/Sub	Queue	Event Bus
Delivery Model	Push	Pull	Push
Routing Capability	Limited	None	Advanced
Durability	Limited (requires SQS for durable fan-out)	High	High
Use Cases	Real-time notifications, fan-out	Task queues, async processing	Event-driven workflows

Hybrid Patterns

Combining these services can unlock even greater flexibility. For example:

SNS + SQS: Use SNS for fan-out to multiple SQS queues, ensuring durability and decoupled processing.
EventBridge + SQS: Route events to specific SQS queues based on event patterns for targeted processing.

Conclusion

SNS, SQS, and EventBridge each play a vital role in event-driven architectures. SNS excels in real-time pub/sub messaging, SQS in decoupled queuing, and EventBridge in advanced event routing. By evaluating your requirements, you can choose the right service or combination of services to build your robust and scalable solution.