Multi-Region Destinations

Proxylity UDP Gateway supports flexible multi-region deployments that allow you to optimize for performance, reliability, and compliance. This page explains how to configure destinations across multiple AWS regions using the recommended approach with UdpGatewayDestinationArn custom resources.

Key Concepts

• Listeners are global resources, created once and available in all supported regions
• Destinations are declared with Listeners and represent logical targets for packet delivery
• Destination ARNs are the connections between Destinations and actual AWS resources, configured as key/value pairs where:
  • The key (ingress region key) is an AWS region name (e.g., us-west-2) or * for fallback
  • The value is the full AWS resource ARN
  • All ARNs for a given Destination must be for the same AWS service

Packet Routing Logic

When packets arrive at a UDP Gateway point of presence, the following steps determine which destination resource (ARN) will receive them:

1. If an ARN with a region matching the reception region is configured, it will be used
2. If a fallback ARN with key * is configured, it will be used
3. If multiple ARNs are configured but none matching the reception region, the ARNs will be sorted by inter-region latency and the "closest" chosen
4. If no ARNs are configured, the packets will be dropped

Deployment Approaches

Single ARN (Simple Deployment)

A single ARN may be configured for a destination, specifying a single resource to be used globally. This is common for test environments or single-region services.

graph TD
global[Global DNS] -->regionalA[Region A Listener]
global -->regionalB[Region B Listener] 
global -->regionalC[Region C Listener]
regionalA --> destination[Single-Region Destination]
regionalB --> destination
regionalC --> destination

classDef default fill:silver,stroke:#9999,stroke-width:1px;

UdpGatewayDestinationArn Resources (Recommended)

The recommended approach for multi-region deployments uses UdpGatewayDestinationArn custom resources to connect regional AWS resources to global Destinations. This approach provides several advantages:

• No need for hard-coded resource names in global templates
• Flexible deployment order - global and regional stacks can be deployed independently
• Easy to add or update regions without modifying the global template
• Optimal performance with in-region packet delivery

Global Template (deployed in one region)

{
  "Type": "Custom::ProxylityUdpGatewayListener",
  "Properties": {
    "Protocols": [ "udp" ],
    "Destinations": [
      {
        "Name": "MyServiceDestination",
        "Role": {
            "Arn": { "Fn::GetAtt": [ "MyDestinationRole", "Arn" ] }
        }
      }
    ]
  }
}

Regional Template (deployed in multiple regions)

{
  "Type": "Custom::ProxylityUdpGatewayDestinationArn",
  "Properties": {
    "Destination": "MyServiceDestination",
    "IngressRegionKey": { "Ref": "AWS::Region" },
    "Arn": { "Fn::GetAtt": [ "MyLambdaFunction", "Arn" ] }
  }
}

Deploy this pattern in each region where you have resources. Using { "Ref": "AWS::Region" } automatically uses the current deployment region as the ingress region key. You can also use * as the key to specify a fallback ARN.

graph TD
global[Global DNS] -->regionalA[Region A Listener]
global -->regionalB[Region B Listener]
global -->regionalC[Region C Listener]
regionalA --> destinationA[Region A Destination]
regionalB --> destinationB[Region B Destination]
regionalC --> destinationC[Region C Destination]

classDef default fill:silver,stroke:#9999,stroke-width:1px;

Legacy Inline ARN Configuration

For backwards compatibility, you can still specify ARNs directly in the Destination configuration:

"Destinations": [
  {
    "Name": "MyServiceDestination",
    "Service": "Lambda",
    "DestinationArn": {
      "us-west-2": "arn:aws:lambda:us-west-2:123456789012:function:MyFunction",
      "us-east-1": "arn:aws:lambda:us-east-1:123456789012:function:MyFunction",
      "eu-west-1": "arn:aws:lambda:eu-west-1:123456789012:function:MyFunction"
    }
  }
]

However, this approach requires hard-coding ARNs or complex parameter management, making the UdpGatewayDestinationArn approach preferable for most use cases.

Supported Regions

UDP Gateway currently supports the following AWS regions: us-west-2, us-east-1, eu-west-1.

For optimal performance and reliability, it is recommended to deploy destination resources in all regions where Proxylity operates. However, this isn't necessary when your backend resources are deployed to a single AWS region. If additional latency due to cross-region delivery becomes undesirable, you can always add regional ARNs later using UdpGatewayDestinationArn resources.