How to prevent Cosmos DB-triggered function app from triggering in disaster recovery region

Question

We are setting up disaster recovery infrastructure, and our Cosmos DB-triggered function apps are firing unexpectedly in the secondary region. Both our change feed function apps in production and DR environments are pointed to the same Cosmos DB resource with geo-replication enabled, and we set PreferredLocation properties in both apps. However, our testing shows that both change feed function apps pick up document writes. Is there a way to prevent this without adding region filtering logic into the function app? If not, what does the PreferredLocations tag actually do if it doesn't filter the document changes by region?

Answer 1

The PreferredLocations setting in your Cosmos DB client configuration (which includes Azure Functions triggered by Cosmos DB) is used to specify the order of preference for regions from which to read data. As we know this is useful for optimizing read latency by directing read operations to the nearest or most preferred region. However, I think it does not inherently limit the change feed processor (or a function triggered by Cosmos DB) to only listen for changes in that preferred region. The change feed will still receive changes from all regions, as it is designed to provide a global view of the data changes.

You can (as a workaround) implement an environment variable or configuration setting in your Azure Functions that can be toggled on or off. When set to "off" in the DR region, the function logic early exits without processing the changes.

Or, use Azure Function Proxies or Azure API Management to control and route the triggers based on the source region. This adds an intermediate layer that can inspect the trigger and decide whether to process it further based on the region. However, this may require some initial setup and maintenance.

Please test and tell us :)