DEV Community: kevin heidt

AWS Global SQS with Multi-Region Availability

kevin heidt — Mon, 05 May 2025 16:54:59 +0000

This is a submission for the Amazon Q Developer "Quack The Code" Challenge: Exploring the Possibilities

What I Built

AWS Global SQS with Multi-Region Availability

This project demonstrates how to create a .NET application that sends messages to Amazon SQS with multi-region capabilities, allowing it to be agnostic about which regional SQS endpoint the message is being sent to. The routing is controlled via Amazon Route53 weighted routing rules, enabling seamless failover between regions.

The Power of Global Availability for SQS

Amazon SQS is a regional service, but many applications require multi-region resilience. This project demonstrates how to achieve global availability for SQS, similar to what AWS has already implemented for services like:

Amazon S3 Global Accelerator: Provides global endpoints that route to the nearest regional bucket
Amazon EventBridge Global Endpoints: Enables multi-region event routing with automatic failover
AWS Global Accelerator: Provides static IP addresses that route traffic to the optimal AWS endpoint

By implementing a similar pattern for SQS, we gain several benefits:

Increased Availability: If one region experiences issues, messages automatically route to another region
Reduced Latency: Messages can be processed in the region closest to the consumer
Disaster Recovery: Automatic failover ensures business continuity during regional outages
Simplified Architecture: Producers don't need to know which region they're sending to

Key Innovation: Decoupling Producers from Regional Awareness

The most powerful aspect of this implementation is the complete decoupling of the producer from any regional awareness:

The producer sends messages to a single endpoint (sqs-global.example.com)
Route53 weighted routing determines which regional SQS endpoint receives the message
The producer continues functioning even during regional failovers
No code changes or redeployments are needed to handle region changes

This pattern enables true "write anywhere, read anywhere" capabilities for SQS, similar to globally distributed databases, but for messaging.

Demo

In the below image, you can see that the producer (left side) is posting messages to a route53 url rather than a region specific generic AWS SQS endpoint. The consumer (right side) pulls messages from both regions, calling out which region the message was pulled from. Due to the route53 records being weighted, some messages went to us-east-1 (green), some went to us-west-2 (blue).

In a failover scenario, it would be simple to change the weights of either region to 0, forcing all messages to go to the other region. This is important because failing over to a specific region may be due to an application issue with the consumer, and doesn't have to necessarily be an AWS outage. If the consumer application is having trouble in east, it may want messages to end up in the west where it becomes the active instance. Meanwhile, if a producer was posting to east with a failback to west if the east SQS was down, it wouldn't know that it needed to switch if it was strictly based on the health of the SQS service. In an enterprise scenario, with lots of distributed computing, it's important to be as decoupled as possible, removing rigidity wherever feasible.

Code Repository

kaheidt / aws-global-sqs

Demonstrates the ability to make your SQS producers regionally agnostic when it comes to posting to SQS endpoints

AWS Global SQS with Multi-Region Availability

Architecture

graph TB
    subgraph "Producer Application"
        A[Message Producer] --> B[SQS Client]
    end
    
    B -->|"Send to sqs-global.example.com"| C[Route53 DNS]
    
    C -->|"90% Weight"| D[SQS us-east-1]
    C -->|"10% Weight"| E[SQS us-west-2]
    
    subgraph "Consumer Application"
        F[Message Consumer] --> G[Monitor us-east-1]
        F --> H[Monitor us-west-2]
    end
    
    G --> D
    H --> E
    
    subgraph "Route53 Failover Control"
        I[Failover Toggle] --> C
    end

The Power of Global Availability for SQS

View on GitHub

How I Used Amazon Q Developer

I typically use Github Copilot with Claude 3.7 Sonnet for my AI vibe coding, but I was pleasantly surprised to see how well Amazon Q did from a coding perspective, especially given that I'm using the free tier. This entire project was handled via Amazon Q, and was created in less than a day. I exported the entire conversation with Amazon Q, which you can read here. And now for the writeup that Amazon Q produced in regards to how it was used in this project...

This project was built with significant assistance from Amazon Q Developer, which helped with:

Architecture Design: Suggesting the Route53-based approach for multi-region routing
Code Generation: Creating the complete .NET solution with proper structure and patterns
AWS Integration: Implementing AWS SDK integration with best practices
Troubleshooting: Resolving build errors and runtime issues
Feature Enhancement: Adding color-coded console output for better visualization

Amazon Q Developer was instrumental in exploring this innovative approach to SQS global availability, helping to implement a solution that isn't documented in standard AWS patterns.

Created by @kevin_heidt_d73c1752454fb

AutoSecure API Gateway: Permissions Redefined

kevin heidt — Sun, 04 May 2025 17:11:48 +0000

This is a submission for the Permit.io Authorization Challenge: Permissions Redefined

Created by @kevin_heidt_d73c1752454fb

What I Built

I built AutoSecure API Gateway, an innovative authorization solution for the automotive industry that tackles the complex web of permissions unique to dealership networks, service centers, and connected vehicle ecosystems.

The automotive industry presents distinctive authorization challenges:

Dealership staff may work across multiple locations with varying permission levels
Service technicians need temporary access to vehicle systems based on work orders
Fleet managers require different access levels based on vehicle ownership arrangements
Vehicle owners expect granular control over who can access their vehicle data
High employee turnover requires immediate permission revocation

AutoSecure addresses these challenges by implementing API-first authorization through Permit.io and NGINX, allowing centralized policy management while maintaining high-performance gateway-level enforcement.

Demo

Try the live demo: AutoSecure API Gateway

Test Credentials:

Admin: admin / 2025DEVChallenge
Regular User: newuser / 2025DEVChallenge

The interactive Swagger UI demonstrates:

Vehicle ownership validation (users can only access vehicles they own)
Role-based access differentiation (fleet managers vs. service technicians)
Dealership-specific permissions (access to service records only at authorized locations)
Temporal authorization (time-limited access for service appointments)

Project Repo

kaheidt / nginx-permitio

Demonstrate API First Development with utilization of permit.io

AutoSecure API Gateway: API-First Authorization for Automotive Industry

An innovative API gateway solution leveraging NGINX and Permit.io to implement fine-grained authorization for automotive industry applications.

LIVE DEMO

Try it out LIVE HERE

Project Overview

AutoSecure API Gateway demonstrates how API-First authorization principles can be applied to modern automotive industry services. It showcases how authorization can be externalized from application code and enforced at the gateway layer using Permit.io's integration with NGINX.

Use Case: Connected Vehicle Services Platform

This project implements a Connected Vehicle Services Platform API with the following components:

Vehicle Telemetry API - Access to real-time vehicle data
Maintenance Services API - Schedule and manage service appointments
Fleet Management API - Monitor and manage vehicle fleets
Driver Behavior Analytics API - Access to driving behavior data

Each API has different access control requirements based on user roles:

Vehicle Owner - Access to their own vehicle data and services
Service…

View on GitHub

The repository includes comprehensive documentation on how the project models and enforces the complex authorization relationships in the automotive industry:

Architecture design with gateway-level enforcement
Authorization model for automotive industry relationships
API documentation showing permission requirements for endpoints

My Journey

Understanding Automotive Access Control Challenges

My first challenge was modeling the complex relationships in automotive dealership networks:

Relationship Complexity: A service technician might work at multiple dealerships but have different certification levels and access rights at each location. For example, a technician certified for Brand A at Dealership X might only have basic access at Dealership Y.
Employee Turnover: The automotive industry experiences high turnover rates (15-20% annually for service technicians). Traditional role-based authorization creates security risks when deprovisioning is delayed.
Multi-tenant Hierarchies: Dealership groups operate multiple locations, with regional managers needing cross-location access while location managers need limited access.
Connected Vehicle Data: Modern vehicles generate telematics data that may need to be shared selectively with service centers only during authorized repair visits.

Implementation Breakthroughs

The key breakthrough came when I realized traditional role-based authorization fails to address these complexities. Instead, I needed to:

Model Relationships, Not Just Roles: Using Permit.io's flexible policy model, I created relationship-based rules like:

//Service tech can only access vehicles at their current assigned dealership 
user.role == "service_technician" && resource.current_dealership_id == user.assigned_dealership_id

Implement Time-bound Access: For service appointments, access is granted only during scheduled service windows:

//Service tech can access vehicle diagnostic data only during scheduled 
appointment now() >= resource.appointment_start_time && now() <= resource.appointment_end_time

Use NGINX As The Enforcement Layer: By moving authorization to the API gateway with Permit.io's NGINX integration, I eliminated inconsistent enforcement across microservices.

Technical Challenges Overcome

Performance Concerns: Authorization checks for every API call could create latency. I solved this with:
Local PDP sidecar for low-latency decisions
Intelligent caching of authorization decisions
Optimized JWT processing in NGINX
Complex Authorization Logic: Automotive relationship modeling required intricate policies. I addressed this by:
Creating a hierarchy of policies from simple to complex
Building reusable policy components with Permit.io
Separating base role permissions from contextual rules

Using Permit.io for Authorization

Permit.io transformed how I approached automotive industry authorization in several key ways:

1. Context-Aware Authorization

The automotive industry requires authorization decisions based on multiple contexts that traditional RBAC can't handle:

// A dealership can only access vehicles that were purchased there OR
// are currently being serviced there OR have a valid service agreement
permit.check(
  user, "view", vehicle,
  {
 dealership_id: user.dealership_id,
 context: {
   purchase_location: vehicle.purchase_dealership_id,
   service_location: vehicle.current_service_location,
   service_agreements: vehicle.active_service_agreements
 }
  }
);

2. Relationship-Based Authorization

Using Permit.io's flexible policy model, I created relationship-based rules that reflect the real automotive industry:

// Regional manager can access data across multiple dealerships
user.role == "regional_manager" && 
user.region_id == resource.dealership.region_id

// Service technician access depends on certification level
user.role == "service_technician" && 
user.certification_level >= resource.required_certification_level

// Parts department can view vehicle history only for parts ordering
user.department == "parts" && action == "view_history"

3. Dynamic Permission Adjustments

Employee roles in automotive often change temporarily (covering shifts, special assignments). Permit.io enabled dynamic permission adjustments without code changes:

// Tech temporarily assigned to another dealership
(user.role == "service_technician" && 
 (user.assigned_dealership_id == resource.dealership_id ||
  user.temporary_assignments.includes(resource.dealership_id)))

4. Multi-Brand Dealership Groups

Many dealership groups represent multiple brands, each with different access requirements:

// Brand-specific certification is required for diagnostics
user.role == "service_technician" && 
user.certifications.includes(resource.vehicle.brand) && 
action == "run_diagnostics"

By leveraging Permit.io's flexible policy engine at the NGINX gateway level, AutoSecure provides a comprehensive solution to the automotive industry's unique authorization challenges—finally bringing structured, consistent access control to an industry that has long struggled with it.

Thank you for considering my submission! I hope AutoSecure API Gateway demonstrates how Permit.io can transform authorization in complex multi-relationship environments like the automotive industry.

AutoSecure API Gateway: API-First Authorization Reimagined

kevin heidt — Sun, 04 May 2025 16:55:31 +0000

This is a submission for the Permit.io Authorization Challenge: API-First Authorization Reimagined

Created by @kevin_heidt_d73c1752454fb

What I Built

I built AutoSecure API Gateway, a robust API gateway solution for the automotive industry that implements API-first authorization principles. By leveraging Permit.io's NGINX integration, the project externalizes authorization logic from application code and enforces fine-grained access control at the gateway layer. This ensures consistent, centralized, and declarative policy enforcement across all APIs.

The project demonstrates real-world use cases, such as managing vehicle telemetry, fleet operations, and driver analytics, while supporting multiple roles like vehicle owners, service technicians, and fleet managers.

Demo

Try the live demo: AutoSecure API Gateway

Admin Credentials:

Username: admin

Password: 2025DEVChallenge
User Credentials:

Username: newuser

Password: 2025DEVChallenge

The repo is also easy to implement locally for modification and testing as desired. Take a look at the Quick Start for more info. Almost everything is scripted for you.

Project Repo

Check out the full project repository here: GitHub - nginx-permitio

kaheidt / nginx-permitio

Demonstrate API First Development with utilization of permit.io

AutoSecure API Gateway: API-First Authorization for Automotive Industry

An innovative API gateway solution leveraging NGINX and Permit.io to implement fine-grained authorization for automotive industry applications.

LIVE DEMO

Try it out LIVE HERE

Project Overview

Use Case: Connected Vehicle Services Platform

This project implements a Connected Vehicle Services Platform API with the following components:

Vehicle Telemetry API - Access to real-time vehicle data
Maintenance Services API - Schedule and manage service appointments
Fleet Management API - Monitor and manage vehicle fleets
Driver Behavior Analytics API - Access to driving behavior data

Each API has different access control requirements based on user roles:

Vehicle Owner - Access to their own vehicle data and services
Service…

View on GitHub

The repository includes:

A detailed README with setup instructions
Documentation on architecture, authorization model, and AWS deployment

My Journey

Building this project was an exciting challenge that required balancing innovation with real-world practicality. You read a full write-up in my development journal, but here are some key highlights:

Challenges Faced:
- Designing a scalable and secure architecture for API-first authorization.
- Ensuring low-latency authorization decisions while maintaining high availability.
- Integrating Permit.io's NGINX Lua module seamlessly with backend services.
Solutions:
- Implemented a local PDP sidecar for fast, reliable policy decisions.
- Used Terraform to automate AWS infrastructure deployment.
- Designed a multi-tenant architecture to support diverse user roles and organizations.
Lessons Learned:
- Externalized authorization simplifies API design and improves security.
- Declarative policies enable real-time updates without service disruptions.
- Permit.io's integration with NGINX is a powerful tool for enforcing access control at scale.
- When in doubt, go native. Switching from JS module to Lua made auth subcalls much easier in nginx.

API-First Authorization

This project embraces API-first principles by externalizing all authorization logic to Permit.io. Key features include:

Centralized Policy Management: Policies are managed in Permit.io's Policy Administration Point (PAP) and synced to the local PDP sidecar.
Declarative Rules: Authorization is defined using declarative policies, not hardcoded logic.
Gateway-Level Enforcement: NGINX acts as the Policy Enforcement Point (PEP), ensuring consistent access control across all APIs.
Real-Time Updates: Policy changes are applied instantly without requiring service restarts.
Fine-Grained Access Control: Combines RBAC and ABAC to support complex automotive use cases.

For a detailed explanation of the architecture and authorization model, see:

Thank you for considering my submission! I hope this project inspires others to explore API-first authorization with Permit.io.

Roboverse!

kevin heidt — Mon, 21 Apr 2025 16:21:42 +0000

This is a submission for the Alibaba Cloud Challenge: Build a Web Game.*

What I Built

RoboVerse is an innovative 3D robot-themed web game that combines creative building mechanics with strategic battle gameplay. Players can design their own unique robots through an intuitive customization system, selecting different heads, bodies, arms, and legs - each affecting the robot's capabilities in battle.

This was my introduction to vibecoding, letting copilot do most of the work.

Demo

https://roboverse.humanless.app/

kaheidt / alibaba-robots

RoboVerse

A 3D robot-themed web game built with React, Three.js, and Alibaba Cloud services.

See it live: https://roboverse.humanless.app/

Features

Interactive 3D robot building and customization
Real-time robot battles with physics
Cloud-based save system using Alibaba Cloud OSS
Global leaderboards powered by ApsaraDB

Prerequisites

Node.js (compatible with React 19)
Docker and Docker Compose
Terraform (optional, for cloud deployment)
MySQL 8.0 (automatically handled by Docker)

Setup

Clone the repository
Install dependencies:

npm install

Create a .env file in the root directory with your database and server configuration:

# API Server Config
PORT=3001

# Frontend Config
VITE_API_URL=http://localhost:3001/api

# Database Config (Docker)
DB_HOST=localhost
DB_USER=root
DB_PASSWORD=rootpassword
DB_NAME=roboverse
DB_PORT=3306

# Alibaba Cloud Config (Server-side only)
ALIBABA_OSS_REGION=your-region
ALIBABA_OSS_BUCKET=your-bucket
ALIBABA_ACCESS_KEY_ID=your-access-key
ALIBABA_ACCESS_KEY_SECRET=your-secret-key

Start the MySQL database with Docker:

docker-compose up -d

The database will be automatically initialized…

View on GitHub

Alibaba Cloud Services Implementation

Originally designed to run on ECS using an autoscaling group, I shifted the architecture to instead use SAE in an effort to optimize costs, based on the understanding that I didn't need instances running all the time as users would be inconsistent. All architecture is implemented via IAC using terraform, so that it's easy stand-up in another account as needed. Some challenges I had included activating each individual service before I was able to use it via terraform, but the support staff was very quick to help me resolve any issues. I had a little trouble with getting my custom domain to work with the CDN because of some built in blacklisting they have, and also because Cloudflare offers up edge tls for free, but only if you use it as a proxy and not a straight cname dns. This made things a little wonky with domain validation for the CDN, and I didn't want to have to pay for https traffic through the CDN, so I had to do a couple steps to resolve that.

SAE System Components

Content Delivery Network (CDN)
- Global distribution of static assets
- Reduced latency for textures, models and scripts
- Optimized caching policies for different file types
- HTTPS and HTTP/2 support
Serverless App Engine (SAE)
- Auto-scaling Node.js applications
- Built-in load balancing
- Zero infrastructure management
- Pay-per-use model
Object Storage Service (OSS)
- Game assets storage
- Player save data
- Origin server for CDN
ApsaraDB RDS (MySQL)
- Player profiles
- Leaderboard data
- Game statistics
Container Registry
- Application container images
- Automated deployment pipeline
Security Components
- RAM for access control
- VPC security groups
- SSL/TLS encryption

SAE Monthly Cost Estimation (100 Active Users)

Based on Alibaba Cloud pricing in US West 1 region (Silicon Valley):

Serverless App Engine
- vCPU usage: $25.20/month (0.5 vCPU × 720 hours)
- Memory usage: $12.60/month (1GB × 720 hours)
- Request processing: ~$8/month
ApsaraDB RDS (MySQL)
- RDS.MySQL.s1.small: $34.50/month
- Storage (20GB): $2.76/month
Object Storage
- Storage (estimated 50GB): $1.15/month
- Requests and bandwidth: ~$3/month
Container Registry
- Basic instance: Free
- Storage: ~$1/month
Data Transfer
- Internal: Free
- Internet outbound: ~$10/month

Total Estimated Monthly Cost: $98.21

Note: This represents approximately 29% cost savings compared to the ECS-based architecture. Costs may vary based on actual usage patterns, data transfer, and storage needs. The serverless model ensures you only pay for actual resource consumption.

Cost Optimization Tips

Use reserved instances for the base ECS instance to save 30%
Implement proper caching to reduce database load
Configure auto-scaling thresholds carefully
Use OSS lifecycle rules to manage storage costs
Monitor and optimize data transfer patterns

Game Development Highlights

Interactive 3D robot building and customization
Real-time robot battles with physics
Cloud-based save system using Alibaba Cloud OSS
Global leaderboards powered by ApsaraDB
Preloading of sound assets from CDN
Scalability using Serverless App Engine (SAE)

Created by Kevin Heidt @kevin_heidt_d73c1752454fb