AWS Global SQS with Multi-Region Availability

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 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. 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 Loading 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… 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

May 5, 2025 - 18:20

AWS Global SQS with Multi-Region Availability

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