Business-critical optimization workloads often require continuous availability, even in the face of unexpected cloud service disruptions. To achieve this, Gurobi Instant Cloud allows you to deploy multiple pools, each in a different cloud region, so that your applications can automatically fail over if one region becomes temporarily unavailable.
This article explains:
- Why regional redundancy is important
- How to structure multiple pools across regions
- How to implement automatic failover in your client application
- Optional advanced techniques using the Gurobi Cloud REST API
Why High Availability Matters
Cloud providers occasionally experience regional disruptions, network partitioning, or API rate issues that can affect resource availability. By configuring multiple Instant Cloud pools across regions, you can ensure that your optimization jobs continue to run smoothly, even if one region is impaired.
Each Instant Cloud Pool encapsulates:
- Machine type (e.g.,
m6i.large) - Cloud region (e.g.,
us-east-1,us-west-2,eu-west-1) - Pool settings such as idle shutdown, job timeouts, and scaling behavior
When a client connects to a pool, Gurobi Cloud automatically launches or reuses compute machines in that pool.
Creating a Pool in Gurobi Instant Cloud
Before you can configure failover, you need to create the individual Instant Cloud pools that your clients will connect to. A pool defines a reusable configuration of compute machines (region, size, and other settings) that can be shared across users in your organization.
You can create pools in one of two ways:
1. Using Gurobi Cloud Manager
Create a Pool in Gurobi Instant Cloud
|
2. Using the REST API (Advanced)
Automate Pool Creation via the REST APIYou can also automate pool creation using the Instant Cloud REST API. The endpoint to create a pool is:
Example JSON body:
Reference: Interactive Swagger Console |
Once your pools exist, you can connect to them from any Gurobi client using their Pool Name, along with your Cloud Access ID and Secret Key.
A Standard Multi-Region Pool Strategy
| Purpose | Pool Name | Region | Typical State |
|---|---|---|---|
| Primary | prod-us-east-1 |
us-east-1 |
Active |
| Secondary | prod-us-west-2 |
us-west-2 |
Standby |
Both pools should:
- Use the same configuration (machine type, job queue, version)
- Share the same Cloud Access ID and Secret Key
- Differ only by their cloud region
Your application can connect to either pool simply by changing the CloudPool parameter in your license file.
gurobi-us-east.lic
|
gurobi-us-west.lic
|
[Simple Client Side Approach]
Automating Failover via Client Environment Settings
You can automate failover directly in your client application; no REST calls required. Your code attempts to start a Gurobi environment in the primary pool; if startup fails or takes longer than a configured timeout, it automatically falls back to the next pool in your list (e.g., a different region).
Key parameters (set on an empty Env at runtime or via license):
CloudAccessIDCloudSecretKey-
CloudPool(the pool name, which determines the region)
This approach:
Automatically retries through multiple pools until one connects
Needs only environment parameters; no API setup
Works across any number of backup regions in priority order
Enforces a per-pool startup timeout to avoid long hangs
The example below implements this logic: if Env.start() exceeds the timeout, the client switches to the next pool automatically. Adjust the timeout and pool order to match your SLA and regional preferences.
Python Implementation
|
[Advanced/Optional]
Using the Gurobi Cloud REST API to Check or Pre-Warm a Backup Pool
In addition to client-based failover, you can use the Gurobi Instant Cloud REST API (v2) to proactively monitor and prepare your backup pools. (See the Interactive Swagger Console)
This is especially useful if your workflow requires instant availability or if you want to automate health checks as part of your uptime strategy.
The REST API allows you to:
List your existing pools
Check whether a specific pool has active machines
Start (or “pre-warm”) a backup pool in advance of use
Optionally, wait until a machine is fully ready before connecting
⚠️ Important:
Starting a machine through the API activates a running environment, which incurs billing time. Gurobi Cloud currently bills a minimum of 30-minutes per environment startup, even if the machine is used for a shorter period. For this reason, pre-warming should be used sparingly, only when uptime requirements justify the additional cost.
This example demonstrates how to use the Gurobi Instant Cloud REST API (v2) to check the status of a backup pool and, if necessary, start a machine to pre-warm it before your client applications attempt to connect.
Authenticate: Use your Cloud Access ID and Secret Key (the same credentials that Gurobi clients use).
List your pools: Retrieve all Instant Cloud pools and find the one matching your backup region by name.
Check pool activity: Query the pool’s
/machinesendpoint to see if any compute machines are currently running.Start a machine if needed: If the pool has no active machines, send a
POSTrequest to launch one.Wait until ready: Poll the pool periodically until at least one machine is running (or “ready”), or until a timeout expires.
Connect normally: Once the pool reports an available machine, your standard Gurobi client or failover logic can connect immediately with minimal startup latency.
Python Implementation
|
We recommend that most customers consider the following best practices:
Poll carefully: Add a timeout and short sleep interval between checks (5–10 seconds).
Check machine state: When available, verify the machine’s
"status"field (e.g.,"running"or"ready") instead of just presence.Avoid unnecessary launches: Don’t pre-warm every job; only for mission-critical or latency-sensitive workloads.
Use environment variables for credentials; never hardcode your Access ID or Secret Key.
Integrate with monitoring: You can schedule this check as part of a cron job, AWS Lambda, or Azure Function to keep your secondary region pre-warmed during business hours.
Summary
Failover in Gurobi Instant Cloud is straightforward and powerful. By defining multiple pools in separate regions and using a short retry loop in your client application, you can ensure that your optimization workloads remain reliable, even when a specific region is unavailable.
We recommend that most customers consider the following best practices:
- Maintain at least two pools in distinct regions
- Keep pool configurations identical except for region
- Use short connection timeouts and retry logic for fast failover
- Test failover regularly by forcing connections to the secondary region
- Monitor usage and uptime through Gurobi Cloud Manager
For additional guidance on multi-region deployment, contact your Gurobi Technical Account Manager (TAM) or visit the Gurobi Cloud Documentation.