| Cost structure |
Pay by a defined period, making it suitable for assigning short-term project costs to a single task |
Pay for the hardware upfront, then account for idle time, space, and ongoing management |
Usually billed by resource size, but verify whether resources are shared with other users |
| Delivery speed |
After confirming the plan, location, and billing cycle, proceed to the order flow |
Requires purchasing, shipping, deployment, network access, and remote access configuration |
Usually quick to create, but hardware and performance limits depend on the service design |
| Resource exclusivity |
One order maps to one dedicated physical machine; the service is not a virtual machine |
The purchaser manages the device and its physical resources are dedicated |
Compute, storage, or host resources may be shared with other instances |
| Upgrade flexibility |
Choose again among the three plans for later tasks and add options as needed |
Upgrades usually require replacing components or buying another device |
Logical specifications may be adjustable, but the actual physical resource limits may not be transparent |
| Best-fit duration |
Short builds, peak scaling, validation experiments, and ongoing projects can all be matched to a billing cycle |
Best for stable, long-term workloads where you can maintain the device and keep utilization consistently high |
Best for general-purpose workloads that can accept shared resource limits |
| Exit costs |
Export required data and clean up before the rental ends; release the machine when the project is complete |
Continue storing, reallocating, disposing of, or managing depreciation for the hardware |
Export data and stop the instance according to the provider's rules |