5 questions to ask before choosing a cloud compute provider

A cloud compute provider can look suitable until a real workload meets the limits behind the pricing page. The advertised GPU, CPU, or hourly rate does not tell you whether the environment supports your software, whether capacity will be available when you need it, or what happens when a job fails.

Use this checklist with one representative workload. Record the data involved, preferred region, runtime, access method, performance target, recovery needs, and operating constraints. Then ask every shortlisted provider the same five questions and require written evidence for answers that affect cost, security, or availability.

1. Does the provider fit your workload and runtime?

Start with the work, not the provider's product categories. A training job, rendering task, simulation, notebook, background service, and production API can need different hardware and operating models.

Write down the minimum technical specification:

• Accelerator or CPU: identify whether the workload benefits from a GPU, which software stack it requires, and whether a CPU-only instance is sufficient.
• Memory: calculate GPU VRAM, system RAM, and local storage from the model, batch size, data, and expected concurrency.
• Scale: confirm whether the software supports multiple GPUs or multiple instances. More hardware does not automatically make a workload faster.
• Runtime: decide whether a prepared container is enough or whether you need a virtual machine, root access, custom system packages, or kernel-level control.
• Connectivity: list the required SSH, HTTPS, TCP, UDP, private-network, and data-transfer paths.
• Location: choose acceptable regions based on latency, capacity, data residency, and customer commitments.

Ask the provider which choices are available now, not which are planned. Hivenet's instance-choice documentation, for example, distinguishes containers from virtual machines and explains GPU, vCPU, RAM, storage, region, and access options. Its current GPU and CPU instance options should still be tested against your actual workload.

Run a small, repeatable job before committing. Record setup time, runtime, throughput, errors, utilization, and output quality. A short test can expose an incompatible image, insufficient VRAM, slow data path, or missing permission before the same problem affects a large job.

2. What is the full cost of one completed workload?

Hourly rates are useful inputs, but they are not a cost model. Compare the cost of a completed, usable result. Include time spent preparing the environment, transferring data, waiting for capacity, rerunning failed jobs, and keeping resources available between runs.

Ask each provider to document:

• billing granularity, minimum charges, and the point at which billing starts and stops;
• prepaid or postpaid terms, minimum balances, credit expiration, refunds, taxes, and payment methods;
• what the instance price includes for storage, network traffic, public addresses, images, and support;
• charges for stopped resources, retained disks, snapshots, backups, ingress, egress, and cross-region traffic;
• quotas, commitments, discounts, cancellation terms, and any price that can change during the contract;
• the financial effect of interruption, a failed job, or a capacity shortage.

Hivenet's current documentation describes prepaid organization credits and per-second billing for eligible usage while an instance runs, without an hourly minimum. Check current Compute pricing immediately before estimating a job instead of copying a rate into a long-lived budget.

Use the same worksheet for every provider: setup hours + transfer charges + active compute + retained resources + expected reruns + exit costs. The lowest advertised rate can produce the highest total cost if engineering time, failure risk, or data movement is expensive. The GPU VM cost model explains these cost drivers in more detail.

3. What happens when capacity changes or an instance stops?

Availability claims need a scope. Ask whether capacity is reserved or allocated on demand, which regions and configurations are covered, and what happens when you start, stop, restart, resize, or replace an instance.

Request written answers for:

• current capacity by region and the process when the requested configuration is unavailable;
• whether stopping an instance releases the host, GPU, or local storage;
• how long stopped data persists and when automatic termination or deletion occurs;
• who owns backups and which recovery options are included;
• status, incident, and maintenance communication channels;
• the service-level agreement's covered service, measurement period, exclusions, credits, and claim process;
• recovery time and recovery point commitments, if the provider offers them.

Do not treat an uptime percentage as a recovery plan. A service-level credit may compensate part of a bill while leaving the customer responsible for data restoration and application continuity.

Hivenet's stop, restart, and capacity documentation states that stopping an instance releases underlying capacity. A later restart depends on current demand, and stopped instances are temporary. That is the kind of lifecycle detail every provider should disclose before you design a production workflow around it.

4. Can the provider show the security and compliance evidence you need?

Security due diligence should examine responsibilities, controls, and evidence. A list of badges cannot tell you whether the relevant service, region, or operation is covered.

Map who owns identity, operating-system and application updates, network exposure, secrets, logging, backups, deletion, and incident response. Ask how workloads are isolated; how data is protected in transit and at rest; who can access hosts or storage; which logs are available; and how vulnerabilities and incidents are handled. The cloud security due-diligence guide provides a broader control checklist.

Review compliance evidence by type:

• GDPR: this is law, not a certification. Establish controller and processor roles, the data processing agreement, subprocessors, transfers, retention, deletion, and assistance with data-subject and incident obligations.
• ISO/IEC 27001: ask for the current certificate, issuer, validity dates, statement of applicability, and exact management-system and service scope.
• SOC 2: ask for the report type, review period, covered systems and Trust Services Criteria, auditor opinion, exceptions, complementary user-entity controls, and bridge letter if the report period has ended.

Confirm that the evidence covers the product you plan to use. A certificate, attestation, or privacy policy for one company or service does not automatically cover every product. For regulated or sensitive work, involve security, privacy, procurement, and legal owners before the trial becomes a production dependency.

5. Can your team operate, automate, and leave cleanly?

A good technical fit can still fail operationally. Test the console and the tasks your team will repeat: create an instance, apply access controls, inspect cost, collect logs, stop and restart, rotate credentials, and terminate resources safely.

If you need automation, review the API rather than accepting an integration claim. Check authentication, available lifecycle operations, request and response formats, pagination, error handling, rate limits, versioning, idempotency, auditability, and the deprecation policy. Hivenet documents a Public Compute API for programmatic access to current Compute operations; this should not be confused with a managed orchestration service.

Support also needs precise terms. Record the available channels, coverage hours, severity definitions, target response times, escalation path, incident updates, migration assistance, and any separate support fee. A community channel, support email, sales engineer, and contractual incident service solve different problems.

Finally, test the exit path. Ask which images, templates, logs, data, and configurations can be exported; whether formats are open; how long export takes; what egress costs; how deletion is confirmed; and how much notice the provider gives before changing or retiring a service. Keep source code, environment definitions, data, and recovery credentials under your control where possible.

Use a scorecard before you commit

Turn the five questions into evidence your team can compare. Use the same representative workload and acceptance threshold for every shortlisted provider.

Requirement	Evidence requested	Trial result	Owner	Decision
Workload fit	Available hardware, runtime, region, and access specification	Setup, runtime, throughput, errors, and output quality	Engineering	Pass / fail
Total cost	Written rates, inclusions, lifecycle charges, and terms	Cost of one completed representative job	Finance and engineering	Pass / fail
Capacity and recovery	Lifecycle rules, SLA scope, status path, backup responsibilities	Stop, restart, failure, and restore test	Operations	Pass / fail
Security and compliance	Responsibility matrix, DPA, scoped certificates or reports	Control and evidence review	Security, privacy, and legal	Pass / fail
Operations and exit	API, support, export, deletion, and deprecation terms	Automation and export test	Platform owner	Pass / fail

Document failures and conditions instead of averaging them away. A provider that fails a mandatory data-region or recovery requirement should not win because it scored well on price. If you still need candidates, use a separate cloud GPU provider shortlist, then apply this scorecard to the providers that fit your basic requirements.

How Hivenet maps to the checklist, and what to do next

Compute with Hivenet currently offers GPU and vCPU instances, container and virtual-machine runtimes, selectable regions, local storage, and several connection methods. Its public documentation describes on-demand per-second billing from prepaid credits, team organizations and roles, and a Public Compute API. Available hardware and capacity vary by region, and stopping an instance releases its underlying capacity.

Hivenet names support through the Compute console and its community channel. Current security and privacy documentation can be requested for a specific review. Buyers should still confirm the precise region, capacity, support coverage, service-level terms, security controls, contractual evidence, and recovery requirements for their workload. The Hivenet Trust page and current Compute documentation are starting points, not substitutes for a scoped review.

Choose one representative workload, define pass and fail conditions, and run a time-boxed trial. Keep the written evidence with the decision so the team can review it when the workload, provider, region, pricing, or terms change.

Is the lowest hourly rate the cheapest option?

Not necessarily. Compare the total cost of a completed job, including setup, data transfer, retained resources, failures, reruns, engineering time, and exit.

What should a cloud service-level agreement cover?

It should identify the covered service, measurement method and period, exclusions, maintenance rules, incident process, credits or remedies, and claim procedure. Your own recovery plan must cover what the agreement does not.

How do I verify a provider's certification or attestation?

Ask for the current document and review its issuer, dates, scope, covered locations and services, exceptions, and customer responsibilities. Confirm that it applies to the product you plan to use.

Compare Compute options