Cloud hosting splits a server into parts you control separately: instances for compute, block volumes for disks, object storage for files, private networks between machines and snapshots for point-in-time copies. It suits workloads that grow, shrink or need several machines. If one steady server is enough, a VPS is usually simpler and cheaper to run.
What cloud hosting actually means
NIST SP 800-145 describes cloud computing by five traits: on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service. In hosting terms that boils down to one practical difference from a classic server: the parts are separate.
On a cloud platform an instance (the virtual machine) is only CPU and memory. Its disks are network-attached block volumes that can be detached, resized, snapshotted and attached to a different instance. Files that do not need a filesystem go into object storage, addressed over HTTPS by key. Machines talk to each other over a private network that is not reachable from the internet unless you route it there. Because these parts are separate, you can replace a failed or undersized instance without moving your data, add a second web node behind a load balancer, or keep a nightly snapshot without copying the whole disk elsewhere.
The cost of that flexibility is more moving parts. Network-attached storage adds a small latency compared with a local disk. Each component is billed or metered on its own line, so forgotten volumes and old snapshots accumulate. Traffic leaving the platform (egress) is often priced separately.
BroadNet Cloud does not run its own data centers. We design, quote, provision and support the layout on established third-party cloud platforms. The supplier, region and every inclusion are named in your written quote. There is no self-serve checkout or customer portal yet, so changes go through us under the terms your quote sets.
Who cloud hosting is for, and who should skip it
A good fit
- Applications that need two or more machines: web and database, workers and a queue, staging and production.
- Load that changes by season, campaign or batch run, where you want to add capacity and later remove it.
- Teams that want data to outlive any single server, using volumes and snapshots they can reattach.
- Products that store large amounts of user files, backups or media better kept in object storage than on a server disk.
- Anyone who needs private networking between components so databases are never exposed publicly.
Probably not a fit
- One brochure site or a small blog: shared hosting is less work.
- One steady application server with predictable load: a VPS has fewer lines on the bill.
- Sustained heavy CPU, very large memory or local NVMe at full speed all month: compare bare metal.
- Teams with nobody to own the operating system: add managed hosting or pick a simpler product.
What you can specify
Every component below is specified in the configurator and confirmed line by line in the quote. Availability of each option depends on the supplier platform and region chosen for you.
| Component | What you specify | Notes |
|---|---|---|
| Instances | vCPU count, memory, CPU class (shared or dedicated), operating system image | Resizing usually needs a reboot; ask how long the platform holds a stopped instance's allocation. |
| Block storage | Volume size, performance tier, number of volumes per instance | Network-attached; survives instance deletion if detached first. |
| Object storage | Capacity estimate, expected requests, public or private buckets, lifecycle rules | Accessed over an S3-compatible API where the supplier offers one Confirmed at quote |
| Private networking | Private subnets, which instances join them, address plan | Use RFC 1918 ranges that do not clash with your office or VPN. |
| Public addressing | Public IPv4 count, IPv6, floating or reserved IPs | IPv4 addresses are scarce and are often charged individually. |
| Load balancing | Listeners, health checks, TLS termination | Optional; needed once you run more than one web node. |
| Snapshots | Schedule, retention count, which volumes | Snapshots are not a full backup on their own (see below). |
| Backups | Frequency, retention, off-platform copy, restore testing | Confirmed at quote |
| Traffic | Expected monthly egress, peak bandwidth | Egress allowance and overage terms are written into the quote. |
| Management | Self-managed or managed | Changes who patches, monitors and restores. |
How cloud hosting differs from a VPS
Both run your workload in a virtual machine, and on the inside they can look identical: same Linux, same root shell. The differences are in what surrounds the machine.
- Storage lifecycle. A VPS usually comes with a disk that lives and dies with the server. In the cloud the disk is a separate volume; you can detach it, snapshot it and attach it to a replacement instance.
- Scaling direction. A VPS scales up (a bigger plan). Cloud designs also scale out: add a second or third instance behind a load balancer, then remove it.
- Networking. Cloud platforms make private networks, security groups and floating IPs first-class objects. On many VPS products a private network is an extra or is not available.
- Billing shape. A VPS is one bundle: CPU, memory, disk and a transfer allowance. Cloud is itemized, which is fairer for variable use and easier to overspend on.
- Disk speed. Local VPS disks can have lower latency than network block storage. Databases that hit the disk hard deserve a test before you choose.
A simple rule: if your architecture diagram has one box, start with a VPS. If it has several boxes and arrows between them, or the number of boxes changes, cloud hosting is the natural fit. The hosting type guide walks through the same choice with more examples.
| Question | Cloud hosting | VPS | Virtual server | Bare metal |
|---|---|---|---|---|
| Unit you buy | Separate instances, volumes, networks | One bundled virtual machine | One VM with reserved CPU and memory | A whole physical server |
| Scales by | Resize and add instances | Move to a bigger plan | Move to a bigger reservation | Add servers; hardware changes |
| CPU sharing | Shared or dedicated classes | Usually shared | Not overcommitted | None |
| Storage | Network block plus object | Usually local or fixed | Defined in quote | Local disks you choose |
| Bill | Itemized | One line | One line | One line plus extras |
| Best for | Multi-tier and variable load | One steady server | Steady load that needs consistency | Sustained heavy load |
Reference configurations
These are shapes to start a conversation, not stocked plans. Your quote may change any line after we look at your real load.
| Layout | Shape | Typical workload | Price |
|---|---|---|---|
| Single app with room to grow | 1 instance, 2 vCPU / 4 GB, 80 GB block volume, daily snapshots | An app that will later split into tiers | Price shown at quote |
| Web plus database | 2 web instances 2 vCPU / 4 GB, 1 database instance 4 vCPU / 16 GB on a private network, load balancer | A SaaS product or busy store | Price shown at quote |
| Worker pool | 1 coordinator plus 2 to 10 worker instances, 4 vCPU / 8 GB each, added and removed with the queue | Batch jobs, media processing, reports | Price shown at quote |
| Storage-heavy | 2 app instances, object storage sized to the archive, lifecycle rules | User uploads, document archives, backups | Price shown at quote |
Use cases and why cloud suits them
A SaaS application with a database
Two small web instances behind a load balancer let you patch or replace one while the other serves traffic. The database sits on a private network with no public address, and its volume is snapshotted before every schema change. The reason to choose cloud here is the separation: you can grow the database instance without touching the web tier.
Seasonal or campaign traffic
A retailer with a heavy month or a launch week can add web instances for the peak and remove them after. The saving only appears if someone actually removes them, so the design should include who decides and when.
Batch and background processing
Workers pull jobs from a queue. Because workers are stateless, they can be added when the queue grows and stopped when it is empty. This is where itemized billing works in your favor.
File-heavy products
Storing millions of uploads on a server disk makes backups slow and migrations painful. Object storage keeps files outside the server, and the application stores only the key. Lifecycle rules can move or expire old objects.
What drives the bill, with worked numbers
The instance line is rarely the surprise. These are the lines buyers underestimate.
- Egress. Data leaving the platform: page views, downloads, API responses, backups copied out.
- Snapshot and backup storage. Retention multiplies storage; a long schedule on a busy volume grows quietly.
- Idle resources. Stopped instances may still be billed for their disks and reserved addresses.
- Storage performance tiers. Faster block tiers cost more per GB; size the tier to measured I/O, not fear.
Worked example: what 2 TB of monthly egress means
Assume 2 TB of data leaves the platform in a 30-day month. 2 TB = 2,000,000 MB = 16,000,000 megabits. A month has 30 x 86,400 = 2,592,000 seconds. Average rate = 16,000,000 / 2,592,000 = about 6.2 Mbit/s.
Traffic is not flat. If your busiest hour runs at five times the average, you need around 31 Mbit/s of headroom at peak. The quote states the egress allowance in GB or TB and the rate for anything above it, so you can check both numbers against this arithmetic.
Worked example: snapshot storage growth
Assume a 100 GB volume, incremental snapshots, about 3 GB of blocks changed per day, and 14 daily snapshots kept. Storage is roughly the first full copy plus the changes: 100 + (14 x 3) = 142 GB. Keep 60 daily snapshots instead and it becomes 100 + (60 x 3) = 280 GB. Whether snapshots are incremental, and how they are billed, depends on the supplier platform and is stated in the quote.
To model cost per user or per request, use the cloud unit cost tool; to compare cloud with a VPS or bare metal over three years, use the TCO calculator.
Snapshots are not a backup plan on their own
A snapshot is a point-in-time copy of a volume, usually kept on the same platform. It is ideal before an upgrade or schema change, because you can roll back fast. It is weak as your only protection: if the account is compromised, the platform has a regional problem or someone deletes the volume and its snapshots, both copies go together.
A backup plan adds a copy that lives somewhere else, a retention policy you chose on purpose, and restore tests that prove you can get data back inside your recovery time objective. For databases, take application-consistent dumps or use the engine's own backup tooling; a disk snapshot of a busy database is only crash-consistent. The backup and recovery guide covers RPO, RTO and the 3-2-1 approach, and the recovery feasibility tool checks whether your restore window is realistic for your data size.
Questions to ask any cloud provider, including us
- Which CPU class is this instance: shared or dedicated? What CPU steal should I expect to see under load?
- Is block storage replicated, and what IOPS and throughput does the tier allow? Is there a burst credit that runs out?
- How much egress is included, how is it measured, and what is the rate above it?
- Are snapshots incremental? Are they stored in the same failure domain as the volume?
- What happens to my data and addresses if I stop an instance, or end the contract?
- What is the written notice period for price changes and planned maintenance?
Our quote answers each in writing.
Who is responsible for what
This is the default split for self-managed cloud hosting. Adding managed hosting moves several rows to BroadNet. The full model is explained in the shared responsibility guide.
| Task | BroadNet | Supplier | You |
|---|---|---|---|
| Physical data center, power, cooling, hardware | - | Owns | - |
| Hypervisor and platform services | - | Owns | - |
| Architecture and sizing design | Owns | - | Approves |
| Provisioning the agreed layout | Owns | - | - |
| Operating system patching | Confirmed at quote | - | Owns |
| Firewall and security group rules | Initial setup | - | Owns |
| Snapshot schedule | Sets up | Stores | Reviews |
| Backups and restore tests | Confirmed at quote | - | Owns |
| Application, data and user accounts | - | - | Owns |
| Billing questions and supplier escalation | Owns | - | - |
Support terms your quote fixes in writing
We do not publish a generic support promise. Each quote states, for your contract:
- How to reach us (email, phone) and the hours support is staffed for your plan.
- Severity levels, what counts as each, and the response targets for each level.
- Planned maintenance notice and how you are told about supplier maintenance.
- Which changes are included (for example, resizing or adding a volume) and which are billed as work.
- The supplier and region, the renewal date and the notice period to cancel.
Read the support terms page for how severity and escalation work in general.
How buying works
- Describe the workload. Use the configurator on the pricing page or contact us. Current server metrics (CPU, memory, disk I/O, monthly egress) help most.
- Design review. We propose a layout, including what we would leave out, and ask about recovery targets.
- Written quote. Supplier, region, every component, egress terms, support terms, renewal and the price.
- Provisioning. Once you accept, we build the layout and hand over access and the network plan.
- Migration and review. We help plan the cutover (see the migration guide), then review sizing once real traffic arrives.
Tools and guides for planning
- Server finder: check whether cloud, VPS or bare metal fits first.
- Cloud unit cost: cost per user, request or GB.
- Migration capacity: how long your data takes to move and what cutover window you need.
- TCO calculator: three-year comparison across hosting types.
- Hosting TCO guide and Linux server hardening.
Frequently asked questions
Is cloud hosting always more reliable than a VPS?
No. A single cloud instance can fail just like a single VPS. Cloud makes it easier to build redundancy, with two web nodes, detachable volumes and snapshots, but you only get that resilience if the design includes it.
Can I start with one instance and split it later?
Yes, and that is often the sensible path. Start with one instance on a separate data volume, then move the database to its own instance on the private network when load justifies it.
Do you offer auto-scaling?
Some supplier platforms support adding instances automatically from metrics. Whether it is available for your region and how it is billed is confirmed in the quote. Many workloads do well with planned scaling around known peaks.
Which supplier will my cloud run on?
The supplier and region are named in your written quote. We do not publish supplier names on the website while contracts are being finalized.
Can I sign up and deploy right now?
Not yet. BroadNet Cloud is quote-led: there is no live checkout or customer portal. You request a quote, receive the price and terms in writing, and we provision after you accept.
What is the biggest hidden cost in cloud hosting?
Usually egress and forgotten storage: old snapshots, detached volumes and reserved addresses. The quote lists egress terms, and a monthly review of unused resources keeps the rest in check.
Sources
Related
Last reviewed . Facts on this page are checked against the sources listed; anything not yet contracted is marked “confirmed at quote”.