Browse this section

Requesting a cloud resize or capacity change

A larger instance can provide more resources, but the available resize paths and downtime depend on the platform, family and storage layout. Scaling also affects pricing and may require a different commitment. Plan the change before your application runs out of capacity.

Prepare the change request

  • Identify the current service, bottleneck and target resources. Attach recent utilisation graphs and expected growth.
  • Record attached volumes, IP addresses, network rules and any licence tied to the current instance.
  • Confirm backup status, application shutdown requirements, a maintenance window and a rollback option.
  • Ask for the new recurring cost and any one-time charges before authorising the work.

After the change, check application health, resource detection, mounts, networking and monitoring. Do not assume downsizing is supported or that data automatically fits on smaller disks. Support will confirm the feasible procedure for your exact service.

Was this guide helpful?

Related guides

Instance disks, persistent volumes and snapshots

A cloud deployment can combine different storage types. An instance disk, an attached volume and a snapshot are separate resources with different lifecycle and recovery behaviour. Record wh…

Planning a GPU workload

A GPU configuration must fit the software as well as the dataset. Accelerator memory, number of devices, CPU, host RAM and storage throughput can each limit performance. A model that fits i…

Need help applying this to your service?

Tell us your service reference and what you need to achieve. Never include passwords or private keys in a ticket.

Contact support →
← All knowledgebase topics