Information checked: 21 July 2026.
Cloud hosting can provide flexible resources and reduce dependence on one physical machine, but the word “cloud” is used for very different products. A small business should evaluate the operating model, not assume that a cloud label guarantees automatic scaling or uninterrupted service.
In brief: Cloud hosting is useful when its scaling, recovery and billing behaviour are understood and tested; it is not a substitute for operations.
Three services commonly called cloud hosting
| Model | Who operates it | Main advantage | Main risk |
|---|---|---|---|
| Managed cloud hosting | Provider manages most of the stack | Simpler scaling and support | Limits and responsibilities may be opaque |
| Cloud virtual machine | Customer or agency manages the server | Control and flexible resources | Patching, monitoring and recovery become your responsibility |
| Platform service | Provider manages runtime and deployment tools | Repeatable deployments | Application may need adaptation and platform knowledge |
Scaling is not the same as capacity planning
Some services scale only after a manual upgrade. Others add resources automatically but charge by use. Database connections, third-party APIs, inefficient plugins and checkout locks may remain bottlenecks even when more CPU is available.
Questions to ask before relying on resilience
- Is the service distributed across zones or simply hosted on virtualised hardware?
- Which components remain single points of failure?
- How are backups separated from the live account?
- What happens during a regional incident or account suspension?
- How are usage spikes limited, alerted and billed?
- Can the site run elsewhere from standard exports?
A controlled trial
Create a realistic test site, simulate the busiest safe workload, inspect billing alerts and perform a restore. Confirm what happens when an instance, database or deployment fails. The test should prove recovery, not only a fast benchmark.
When cloud is justified
Cloud hosting is sensible for variable demand, specialised application requirements or an organisation that benefits from infrastructure automation. For a stable brochure site, a simpler managed service may be cheaper and easier to recover.
Example: a traffic spike with a fixed bottleneck
A campaign triples traffic, but the site remains slow because every request waits for a remote booking API. Adding cloud instances does not remove that dependency and may increase cost without improving completion. Capacity tests should identify which component scales, which does not and how the customer journey behaves when the dependency is unavailable.
What the business should retain
- Architecture and dependency diagram
- Scaling rules and billing alerts
- Single-point-of-failure list
- Regional recovery plan
- Portable deployment and data exports
Sources and date checked
Technical and product information was checked against the following primary sources on 21 July 2026. Plans, interfaces and provider terms can change, so recheck them before purchase or migration.
Keep the decision under your control
Retain the relevant accounts, source material, supplier terms and recovery information. Recheck changing prices, interfaces and rules before acting.