--- schema_version: "1" id: 3f92ae6bfc32849a0a504de866d156865f53af3767f0d67943c4d4ad9bb8cfba title: Flex Gateway Multiple Region Deployments collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/gateway/1.9/flex-architecture-multi-region.md canonical_url: https://docs.mulesoft.com/gateway/1.9/flex-architecture-multi-region source_site: docs.mulesoft.com content_type: documentation content_hash: bd21ffc19ba32c38e878fb32f2b66abafb2daf0a1a6df2843bc28bcd55150210 description: MuleSoft Documentation Site release: "1.9" latest: false --- --- product: Omni Gateway version: 1.9 --- # Flex Gateway Multiple Region Deployments > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Install Flex Gateway in multiple regions to reduce latency and ensure live failover. You can configure most implementations with either multiple Flex Gateways or multiple Flex Replicas. Depending on which you choose, there are different considerations for Redis Shared-Storage, policies, and logging. To learn more about Flex Replicas, see [Flex Replicas](https://docs.mulesoft.com/gateway/1.9/#replicas). All the following diagrams show Flex Gateway running in Connected Mode. For Flex Gateway running in Local Mode, the only difference is that Anypoint Platform isn’t present in the deployment model. This doesn’t affect how information flows between Flex Gateway and the upstream and downstream services. The implementation diagrams use Kubernetes terminology, but you can extend the architecture to other technology stacks that have the appropriate network controls applied. ## Implementation 1: High Availability with the Same APIs in Two Separate Regions Implementation 1 provides high availability for non-region-specific traffic. The DNS service is configured for active-active failover, meaning each region services traffic at all times. ### Implementation 1A: Cross-Regional Flex Gateway In this implementation: - A single Flex Gateway has Flex Replicas distributed across multiple regions. - Flex Gateway is registered once in Anypoint Platform and deployed across multiple regions and availability zones. - Logs and metrics for each Flex Gateway are consolidated in Anypoint Platform. - The DNS service is configured for active-active failover to direct traffic to any region at all times. - APIs deployed to the Gateway are available in all regions and availability zones. - API configurations, including upstream services and policies are the same for all regions. Upstream services must be region-agnostic, meaning either the DNS is local or it lacks any reference to the region. - The Redis cluster must be replicated across regions or Redis shared storage can’t be used. Redis replication is required when traffic isn’t region-specific. - The only cross-regional traffic is Redis synchronization. In the following diagram, Flex Replicas in different regions and availability zones have distinct Kubernetes deployments: ![A detailed view of implementation 1A, which contains the necessary services to support high availability in for Flex Replicas deployed in different regions](/mulesoft/current/en-us/gateway/1.9/_images/high-availability-1a.png) ### Implementation 1B: Region-Specific Flex Gateway In this implementation: - Each region has a distinct Flex Gateway with all resources as independent entities. - A separate Flex Gateway is registered for each region. - Each region-specific API instance has distinct metrics, alerts, and logs in Anypoint Platform. - Policies are region specific even if the configuration is similar across regions. - The DNS service is configured for active-active failover to direct traffic to any region at all times. - API deployments are specific to each Flex Gateway. For each API a region supports, you must deploy an API instance to the region’s Flex Gateway. - API Groups can share contracts (access requests) across regions. An API Group might not be required for your configuration. - Redis shared storage does not require synchronization. - There is no cross-regional traffic. In the following diagram, all APIs are duplicated and don’t require identical configurations: ![A detailed view of implementation 1B, which contains the necessary services to support high availability for region-specific Flex Gateways](/mulesoft/current/en-us/gateway/1.9/_images/high-availability-1b.png) ## Implementation 2: Disaster Recovery for APIs This implementation is similar to [Implementation 1A: Cross-Regional Flex Gateway](#implementation-1a). However, the DNS service is active-passive, so the standby region only receives traffic if the primary region becomes unhealthy. This implementation is less complex to configure than implementation 1A. Redis synchronization is not required if a cache loss during failover is acceptable. In the following diagram, Flex Replicas in different availability zones have distinct Kubernetes deployments. Region B provides high availability but receives traffic only if region A is unhealthy: ![A detailed view of implementation 2, which contains the necessary services to enable disaster recovery for APIs on Flex Gateway](/mulesoft/current/en-us/gateway/1.9/_images/high-availability-2.png) ## Implementation 3: Direct Traffic to the Closest Region In both [Implementation 3A: Direct Traffic to APIs With the Same Policies](#implementation-3a) and [Implementation 3B: Direct Traffic to APIs With the Different Policies](#implementation-3b), Flex Gateway directs traffic to the most convenient region to reduce latency. Choose which implementation according to your policy requirements. ### Implementation 3A: Direct Traffic to APIs With the Same Policies This implementation is similar to [Implementation 1A: Cross-Regional Flex Gateway](#implementation-1a) and has the same considerations. However, Redis replication is not required because requests are sent to specific regions. Configure high availability or disaster recovery zones in each region to ensure API availability: ![A detailed view of implementation 3A, which contains the necessary services to route customer requests to the closest region](/mulesoft/current/en-us/gateway/1.9/_images/high-availability-3a.png) ### Implementation 3B: Direct Traffic to APIs With the Different Policies This implementation is similar to [Implementation 1B: Region-Specific Flex Gateway](#implementation-1b) and has the same considerations. Deploy region-specific gateways and apply the necessary policies to the different APIs. Configure high availability or disaster recovery zones in each region to ensure API availability: ![A detailed view of implementation 3B, which contains the necessary services to route customer requests to the closest region](/mulesoft/current/en-us/gateway/1.9/_images/high-availability-3b.png) > [!NOTE] To apply SLA rate limiting across all regions, the rate limits must be the same for all > regions. Use API groups to consolidate the contracts.