Destinations in Multiple Regions

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 single destination ARN is configured, the packets will be delivered to it. This may involve cross-region API calls if the region of reception is different than the region in the ARN.
3. If multiple ARNs are configured but none matching the receiption region, the ARNs will be sorted by inter-region latency (per cloudping.co) and the "closest" chosen.
4. If no ARNs are configured, the packets will be dropped.

For optimal performance and reliability it is recommented to deploy destination resources in all regions Proxylity operates. However, that isn't necessary when your backend resources are deployed to a single AWS region. If the additional latency due to cross-region delivery becomes undesirable it's always possible to add ARNs later.

Proxility is able to make use of "same region" resources to eliminate that latency. This is useful for a variety of reasons, including resiliency, performance and compliance. See the sections below for how to configure your destination in different scenarios.

Single ARN

A single ARN may be configure for a destination, specifying a single resource to be used globally by Proxylity. This is common as many systems (and particularly test and developer environments) are what is called "single homed" with storage and processing all happening in one region.

graph TD

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

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

Per-Region ARNs (Best Practice)

For multi-homed/multi-region capable services offer the best latency, scalabiliy and resiliency. Hence, you may want to make use of destination resources in all the AWS regions UDP Gateway supports. This will ensure that packet delivery, processing and replies happen "in region", close to the client.

To specify in-region resources when deploying via CloudFormation, modify the destination configuration to specify ARNs for each region as a map:

"DestinationArn": {
    "us-west-2": "arn:aws:sns:us-west-2:123456789012:example-sns-topic-name",
    "us-east-1": "arn:aws:sns:us-east-1:123456789012:example-sns-topic-name",
    "eu-west-1": "arn:aws:sns:eu-west-1:123456789012:example-sns-topic-name"
}

The service component of each ARN must match, and the region in the ARN should match the key. In the above example packets arriving in us-west-2 would be delivered to the topic in that region. Likewise for us-east-2 and eu-west-1. Packets arriving in other regions will be delivered to one of the three specified resources based on latency, as mentioned above.

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

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;