Try our new documentation site (beta).
Security and Network Settings
Some organizations may have a firewall in place that can restrict or block the communication between the client and the Instant Cloud resources. Also, your IT department may want some clarification about the security of Gurobi Instant Cloud. In this section, we will review the security features and the required network settings to operate Gurobi Instant Cloud.
Gurobi Instant Cloud Manager
The Gurobi Instant Cloud Manager is designed to streamline the control of the Gurobi Optimizer on the Cloud. With the Gurobi Instant Cloud Manager, Gurobi manages AWS EC2 or Azure instances. The Instant Cloud Manager consists of the website cloud.gurobi.com and a REST APIs. The main function of the Instant Cloud Manager is to configure, start and stop Gurobi Cloud machines. No optimization model data is communicated with the Instant Cloud Manager.
When accessing the website, users must be authenticated with their Gurobi accounts and the communication is secured via HTTP with SSL encryption (HTTPS). The manager website is the only place where the API keys can be generated and revealed. Multiple API keys can be generated so that keys can be replaced in case one of them has been compromised. The website is also the only way to access the machine admin passwords used to run some restricted actions such as aborting a job.
When using the REST API, the clients are authenticated with the API key and API secret and the communication is secured using the HTTPS protocol.
Starting and Stopping Machines
The Gurobi client (gurobi_cl, grbtune, Gurobi library...) will first connect to the Instant Cloud Manager using the secured REST API to check the pool status and launch the machines as necessary on your behalf. In order to enable this connection, the client firewalls must be configured to open the standard HTTPS port 443 to host cloud.gurobi.com
When you start a machine, you get a new EC2 or Azure instance that is not shared with any other Gurobi customers, it is always dedicated. When the machine is terminated, all optimization data are discarded from memory and disk.
While running, the machine reports to the instant cloud manager (status, jobs) and the Gurobi Billing system. The Gurobi billing system consists of a database that records the use of Gurobi Cloud. A machine reports when it starts and stops to a custom web service for this database. The machine also sends basic metadata including its instance type, location, IP address and machine ID. To prevent over-charging a customer in case of failure of a machine, the server sends a periodic ping to the billing database; the billing database assumes the server is shut down if this ping is not detected. Only computer metadata is sent to the billing database. No application data or user credentials are sent to the billing database.
Using machines running the v8.0.x Gurobi Optimizer
Once the machine has been launched, optimization commands are exchanged between the client and the machine. With the v8.0.x (and later), the communication is secured using the HTTPS protocol between the client and the Gurobi region router. The region router consists of a Load Balancer that will terminate TLS and a reverse proxy that will forward the communication to the appropriate machine within the private Gurobi VPC. The load balancer and the reverse proxy are highly available and multi-tenant, the transmitted data is just forwarded to the started machines and it is not stored or used in anyway by these components.
The started machines are not accessible directly and passing through the region router is enforced by the internal firewall rules. The client is authenticated using a machine password or an administrator password for administrative commands. The passwords are managed by the Instant Cloud Manager. The diagram below summarizes the architecture with AWS.
In order to enable this connection, the client firewalls must be configured to open the standard HTTPS port 443 to the following hosts depending on the region:
| Provider | Region | Router |
|---|---|---|
| AWS | us-east-1 | https://compute-us-east-1.gurobi.com |
| AWS | us-west-1 | https://compute-us-west-1.gurobi.com |
| AWS | eu-central-1 | https://compute-eu-central-1.gurobi.com |
| AWS | ap-northeast-1 | https://compute-ap-northeast-1.gurobi.com |
| AWS | ap-southeast-2 | https://compute-ap-southeast-2.gurobi.com |
| Azure | eastus | https://compute-eastus-azure.gurobi.com |
| Azure | westus2 | https://compute-westus2-azure.gurobi.com |
| Azure | westeurope | https://compute-westeurope-azure.gurobi.com |
The architecture is compatible with standard proxy settings using environment variables HTTP_PROXY and HTTPS_PROXY. HTTPS_PROXY takes precedence over HTTP_PROXY for https requests. The values may be either a complete URL or a "host[:port]", in which case the "http" scheme is assumed.
Using machines running the v7.0.x or v7.5.x Gurobi Optimizer (AWS only)
Once the machines have been launched, optimization commands are exchanged directly between the client and the machines. This communication is encrypted with a 256-bit AES algorithm, using a private shared key that is generated randomly for each user. In order to enable this connection, the client firewalls must be configured to open TCP ports 61000-65000. if opening this wide range of ports is not possible, we recommend migrating to the v8.0.x. You can also consider limiting the range of IP using the AWS IP Address Ranges document, or using the static addressing feature of a pool.
