Cloud server pricing is the total recurring cost of running a workload—not only the advertised VM plan. The real monthly cost includes compute, storage growth, backups, bandwidth policy, operating-system licensing, supporting services, and the operational effort required to keep the environment reliable.
A low starting price can be appropriate for a small website or test server. It becomes misleading when the production workload also needs a database, staging environment, retained backups, additional storage, monitoring, or Windows licensing.
The right question is not “What is the cheapest cloud server?” It is:
What is the smallest safe infrastructure setup for this workload, and what will the complete monthly bill include?
Cloud server pricing at a glance
| Cost layer | What you are paying for | When it matters |
|---|---|---|
| Compute | vCPU and RAM assigned to the VM | Every workload |
| Base storage | Operating system, application, database, and local files | Every workload |
| Network | Included transfer, egress, public IPs, and private networking | Public or multi-server workloads |
| Data protection | Snapshots, scheduled backups, retention, and recovery storage | Any important production data |
| Operating system | Linux distribution or Windows licensing path | Windows and licensed software workloads |
| Supporting services | Load balancers, databases, object storage, and volumes | Growing or separated architectures |
| Operations | Patching, monitoring, incident response, migration, and support | Production environments |
| Idle capacity | Unused development, staging, preview, and oversized resources | Teams with multiple environments |
A provider’s plan table usually shows only the first line. Budgeting should cover the whole stack.
The base VM price
The base VM price is determined mainly by:
- vCPU count
- memory allocation
- included local storage
- compute profile
- contract term
- operating-system choice
- region or infrastructure tier
Raff’s live pricing page currently lists monthly Linux Cloud Server plans beginning with a 2 vCPU, 2 GB RAM, and 40 GB NVMe configuration. Plans include unmetered bandwidth, private networking, DDoS protection, monitoring, API access, and an included backup-and-snapshot storage pool.
Always use the live Raff pricing page for the current plan table because prices and packaging can change.
The lowest plan is not automatically the cheapest operational decision. A VM that is too small can create slow response times, failed builds, memory pressure, database instability, and avoidable support work.
The correct starting plan is the smallest one that supports normal usage with reasonable headroom.
CPU and RAM drive most sizing decisions
CPU and memory usually determine the VM tier before storage does.
More vCPUs increase capacity for concurrent requests, API processing, CI/CD builds, background workers, report generation, and database queries.
RAM supports application processes, database working sets, operating-system cache, containers, queues, caches, and concurrent Windows sessions.
Memory pressure is often more damaging than moderate CPU pressure. When a VM begins swapping or killing processes, the operational cost can exceed the price difference between plans.
Use the VM sizing guide before comparing monthly totals.
Storage cost grows after deployment
The disk size visible in the plan table is only the initial storage layer.
Production storage often expands through:
- database growth
- uploaded files
- logs
- container images
- build artifacts
- package caches
- temporary processing files
- local backup staging
- monitoring data
Ask:
- How much data exists today?
- How quickly is it growing?
- Which data must remain on fast block storage?
- Which files can move to object storage?
- How much free disk space is required for updates and recovery operations?
A server can have enough CPU and RAM but still fail because its disk fills. Storage monitoring and log rotation are cost controls as well as reliability controls.
Local disk, volumes, and object storage solve different needs
| Storage type | Best for | Cost consideration |
|---|---|---|
| VM local disk | Operating system, application, temporary data | Usually bundled with the VM plan |
| Block storage volume | Databases and persistent files that need expandable disk-like access | Added monthly storage cost |
| Object storage | Backups, exports, media, archives, and application objects | Capacity and request model differ from disks |
| Snapshots | Short-term rollback points | Retention increases storage use |
| Backups | Historical recovery and disaster recovery | Schedule, retention, and protected size affect cost |
Do not choose storage only by price per gigabyte. Access pattern, durability, recovery time, and application compatibility matter.
Bandwidth can be included or metered
Cloud providers commonly price network traffic in one of three ways:
- unmetered bandwidth under an acceptable-use policy
- a fixed monthly transfer allowance with overage charges
- per-gigabyte egress billing
This difference matters for public APIs, file downloads, media delivery, backup transfer, database replication, and multi-server applications.
A VM with a low base price can produce a higher bill when outbound traffic is charged separately.
Raff’s current Cloud Server plans list unmetered bandwidth and a 3 Gbps public network port. Private networking is included for communication between supported Raff resources.
Backups are part of production cost
A production VM without a recovery plan is cheaper only until recovery is needed.
Budget for:
- pre-change snapshots
- automated backup schedules
- retained recovery history
- database-aware backups
- independent copies where required
- restore testing
Snapshots support quick rollback. Scheduled backups support retained historical recovery. Important databases may also require logical backups, physical backups, or point-in-time recovery.
Raff provides a backup-and-snapshot storage pool with Cloud Server plans and additional data-protection capacity beyond the included amount. Use the live Data Protection page and pricing page when calculating the monthly total.
The budget should follow the Recovery Point Objective and Recovery Time Objective. Read RPO vs RTO for Cloud Backups before selecting retention.
Windows pricing requires a licensing decision
Windows VM cost can include more than compute and storage.
The final amount may depend on:
- selected VM resources
- Windows Server version
- evaluation, provider licensing, or eligible BYOL path
- Remote Desktop Services requirements
- SQL Server or other Microsoft software
- number of users
- backup and storage needs
A Windows VM page may show an infrastructure starting price while production licensing is billed or arranged separately. Confirm the full production licensing path before comparing providers.
Linux is usually the simpler cost model for websites, APIs, containers, and open-source databases. Windows is justified when the workload depends on RDP, IIS, .NET Framework, Windows-only applications, Active Directory, or another Microsoft-specific requirement.
Use the current Windows VM product page and applicable Microsoft licensing guidance for the real total.
Supporting services change the architecture cost
A single VM may be enough at launch. As the workload grows, the bill can expand through architecture decisions.
| Requirement | Possible additional service |
|---|---|
| Separate application and database | Second VM or managed database |
| Higher availability | Additional application VM and load balancer |
| Private service communication | Private networking and firewall design |
| Expandable persistent disk | Block storage volume |
| User uploads or backup objects | Object storage |
| Deployment isolation | Staging or preview environment |
| Database operations | Managed database service |
| Container orchestration | Kubernetes nodes and control services |
These costs are justified when they reduce a specific reliability, security, or operating risk. The mistake is adding services without defining which problem each one solves.
Managed services vs self-managed infrastructure
A self-managed database on a VM may have a lower visible infrastructure price. A managed database may include backups, updates, monitoring, failover features, or simplified maintenance.
| Area | Self-managed | Managed service |
|---|---|---|
| OS patching | Your team | Provider-managed service layer |
| Database updates | Your team | Depends on service policy |
| Backup design | Your team | Often integrated |
| Monitoring | Your team | Often included or integrated |
| Failover | Must be designed | May be included by tier |
| Direct monthly price | Often lower | Often higher |
| Engineering effort | Higher | Lower for covered operations |
The cheaper invoice is not always the cheaper operating model. Include team time and incident ownership in the decision.
Idle infrastructure creates silent cost
Cloud waste often comes from resources that were useful when created but no longer have an owner.
Typical examples include:
- abandoned test VMs
- oversized staging servers
- preview environments left online
- unused volumes
- old snapshots
- duplicate databases
- temporary migration servers
Every non-production resource should have an owner, a purpose, an expiry or review date, and a deletion or archive rule.
Monthly, annual, and prepaid billing
Billing structure affects cash flow as well as price.
Raff’s pricing page currently describes monthly subscriptions, one-year subscriptions with a longer-term discount, two-year subscriptions with a larger discount, and prepaid balance usage for supported resources.
Raff does not use an hourly-billing promise as the core Cloud Server offer. Compare providers by converting both offers to the same expected usage period and included features.
Longer commitments are appropriate when the workload is stable, migration risk is low, and the discount is worth more than the lost flexibility. Monthly terms are safer for validation, migration, and changing workloads.
How to calculate the real monthly cost
Monthly infrastructure cost = base compute + additional storage + backups and snapshots + operating-system and software licensing + supporting services + network charges + monitoring or support charges + idle resources
Then add the operating cost:
Total operating cost = monthly infrastructure cost + engineering time + maintenance + incident response + migration and recovery work
Not every team needs to assign an exact dollar value to engineering time. It should still be included in the comparison.
Decision framework
Use this order when evaluating cloud server pricing:
- Define the workload. Document the application, users, data, and performance expectations.
- Choose the smallest safe VM. Include normal headroom, not speculative multi-year growth.
- Add persistent data costs. Include disk growth, volumes, objects, logs, and uploads.
- Add recovery. Define RPO, RTO, backups, snapshots, and restore testing.
- Confirm network pricing. Understand allowances, egress, public IPs, and private networking.
- Confirm licensing. Separate infrastructure pricing from Windows and application licenses.
- Add required services. Include databases, load balancers, and additional environments only when justified.
- Choose the billing term. Balance flexibility against commitment discounts.
- Assign ownership. Review cost and utilization regularly.
- Use the live price. Verify final plan and add-on pricing before purchase.