Cloud computing services: 10 categories compared

Cloud computing services give customers access to computing resources, managed platforms, or finished software over a network. What you receive might be a virtual machine, a database, an AI endpoint, or a file-sharing application. Those services solve different problems and leave different amounts of work with your team.

Start with the service your workload needs, then compare providers within that category. A GPU rental is not equivalent to a managed AI API, and object storage is not a replacement for a shared document editor. This guide compares ten categories, representative providers, pricing units, and where Hivenet fits. It is a service comparison, not a ranking of cloud companies.

Cloud computing service models: who manages what?

The NIST cloud computing definition distinguishes three service models. Infrastructure as a service (IaaS) supplies resources such as processing, storage, and networking. Platform as a service (PaaS) supplies a managed environment for deploying applications. Software as a service (SaaS) supplies an application that customers use.

With IaaS, your team commonly manages the guest operating system and application stack. With PaaS, more of that platform work moves to the provider. With SaaS, the provider operates the application, while you still manage users, permissions, data, settings, and the devices used to access it.

Serverless describes an operating approach in which customers use functions or managed capabilities without operating visible server instances. Servers still exist. Execution limits, scaling rules, runtime support, and minimum charges depend on the product and plan.

These service models are separate from cloud deployment models. Public cloud, private cloud, and hybrid cloud describe how an environment is made available or connected. Choosing a public cloud provider does not tell you whether you are buying infrastructure, a platform, or software.

Benefits of cloud computing services and their limits

Cloud services can reduce hardware procurement and server management work, provide temporary computing resources, and give teams access to managed software. Those benefits depend on the selected service, available capacity, and application design. Your organization still needs access management, cost control, and business continuity plans. Before deploying sensitive data, check the product’s controls and your own recovery procedures. A larger cloud platform does not automatically make those decisions for you.

Ten types of cloud services at a glance

• General-purpose compute: run applications on CPU instances or dedicated servers.
• GPU compute: run workloads that benefit from accelerator hardware.
• Containers and application platforms: deploy packaged applications with varying levels of platform management.
• Serverless functions: run event-driven code within a managed execution service.
• Managed databases: use a database with selected operational tasks handled by the provider.
• Storage: retain objects, disk volumes, shared files, or archived data.
• Networking: connect, protect, and route traffic between services and users.
• Managed AI inference: call a model endpoint without operating its serving infrastructure.
• Data processing, analytics, and HPC: process datasets or coordinate compute-intensive jobs.
• Finished software: use applications for tasks such as collaboration, storage, and file transfer.

1. Cloud infrastructure and general-purpose compute

What you get: CPU computing power, memory, and an operating environment for websites, APIs, development systems, batch jobs, or other software. Virtual machines and bare-metal servers offer different isolation and control boundaries; a VM does not give you control of the physical host.

Who manages it: the cloud provider operates the physical servers, data centers, and specified platform layers. On a typical self-managed VM, your team maintains the guest OS, application dependencies, access controls, monitoring, and recovery procedures.

What to compare: CPU architecture, memory, storage performance, network throughput, supported images, region, quotas, and available capacity. Check how stopping, suspending, or deleting an instance affects billing. Attached storage and other resources may remain chargeable after compute stops.

Provider examples: Amazon EC2 in the AWS service catalog, Microsoft Azure Virtual Machines, Google Compute Engine, DigitalOcean Droplets, OVHcloud instances, and OCI compute. Compare configurations suited to the same job rather than matching vCPU counts alone.

Hivenet fit:Compute with Hivenet is a candidate for customer-managed CPU workloads when its available instance configurations and deployment options meet the requirement. Confirm capacity and the full resource combination before committing a production workload.

2. GPU cloud computing services

What you get: accelerator capacity for model training, fine-tuning, rendering, simulation, or self-managed inference. Some jobs need one GPU with sufficient memory; others need several accelerators with suitable communication between them.

Who manages it: the provider supplies the hardware and the software layers included in the service. Your team manages the workload, dependencies, data pipeline, checkpoints, and any serving stack left outside that boundary. Driver and runtime responsibilities differ between VMs, containers, and managed platforms.

What to compare: GPU memory, supported precision, GPU count, interconnects, CPU and RAM allocation, data loading, and capacity. Measure cost per completed training run, rendered frame, or usable output. The same GPU name does not guarantee the same end-to-end performance.

Provider examples: AWS, Azure, Google Cloud, Oracle Cloud Infrastructure, CoreWeave, and Hivenet offer GPU-related services. CoreWeave's managed Kubernetes service illustrates why the surrounding platform matters as well as the hardware.

Hivenet fit: Compute with Hivenet can suit GPU jobs that fit its currently available configurations. Compare actual runtime and data movement with alternatives. Request a quote for the available configuration and benchmark your workload before comparing costs.

3. Containers and cloud platforms for applications

What you get: a way to run container images or deploy application code. Options range from a container on a compute instance to managed Kubernetes and a PaaS that also handles application deployment and runtime operations.

Who manages it: read the service boundary carefully. A managed Kubernetes control plane does not necessarily include worker-node maintenance, workload scaling, ingress configuration, or application recovery. Your team remains responsible for its images, code, secrets, permissions, and data.

What to compare: deployment workflow, supported runtimes, persistent storage, network access, scaling limits, observability, and portability. Charges can combine worker resources, a control-plane fee, load balancing, storage, and transfer.

Provider examples:DigitalOcean lists Kubernetes and App Platform; Azure offers AKS and App Service; Google Cloud offers GKE and Cloud Run. These products leave different operational tasks with the customer.

Hivenet fit: its VM and container options provide workload environments. Container availability should not be presented as a managed Kubernetes or general application-platform offering. Choose based on the deployment and operations work your team can own.

4. Serverless computing and functions

What you get: an execution service for code triggered by events or requests. Functions can suit webhook processing, scheduled tasks, lightweight transformations, and connecting other services.

Who manages it: the provider runs the execution infrastructure. Customers manage function code, permissions, dependencies, event sources, and configuration. Supported managed runtimes can reduce maintenance, but custom runtime and container choices can leave more patching work with you.

What to compare: execution duration limits, memory, concurrency, startup delay, retries, and connection behavior. A retried event can repeat a side effect unless your application handles duplicates. Pricing may include requests and resource duration, with additional charges for reserved capacity or related services.

Provider examples: AWS Lambda and Azure Functions. Lambda's pricing documentation shows why the execution option and surrounding services matter when estimating a bill.

Hivenet fit: the reviewed public catalog does not establish a comparable managed functions service. Running event-driven code on Compute with Hivenet is possible when you build the necessary stack, but that leaves a different operating responsibility.

5. Managed database services

What you get: a relational, document, key-value, or other database service with defined operational tasks handled by the provider. A cache and a transactional database may both be managed services, but they meet different durability and query requirements.

Who manages it: the provider's work may include provisioning, engine maintenance, backups, or failover, depending on the product and configuration. Customers still design schemas, queries, permissions, retention policies, and recovery requirements. Test restoration rather than assuming an enabled backup feature proves recoverability.

What to compare: engine compatibility, extensions, consistency, backup retention, recovery objectives, migration tools, and maintenance behavior. Bills can include compute, storage, I/O, replicas, backup storage, and transfer.

Provider examples: Amazon RDS, Google Cloud SQL, DigitalOcean Managed Databases, and Azure SQL Database in Microsoft's cloud product catalog. Check each specific engine and tier.

Hivenet fit: a database hosted on a Hivenet compute instance remains customer-managed unless a separate agreement says otherwise. The reviewed catalog does not establish a broad managed database service equivalent to these examples.

6. Cloud data storage services

What you get: object storage for API-accessible data, block storage for attached volumes, file storage for shared filesystem access, or archive tiers for infrequently retrieved data. Select the access model before comparing capacity prices.

Who manages it: the provider operates the storage service. Customers configure access, lifecycle rules, retention, encryption options, and recovery processes. Durability claims describe a service's protection against certain failures; they do not automatically protect against an authorized deletion or a bad application update.

What to compare: API compatibility, consistency, object or file limits, throughput, retrieval time, and deletion behavior. Include stored volume, request counts, retrieval charges, minimum retention periods, and data transfer where applicable. Our guide to cloud sync and cloud backup explains why keeping another copy and synchronizing changes are different jobs.

Provider examples: Amazon S3, Azure Blob Storage, Google Cloud Storage, OCI storage, and the storage options in OVHcloud's public cloud catalog.

Hivenet fit:Hivenet's S3-compatible object storage is relevant for application data and datasets. Evaluate the required S3 operations and tools. Store is a separate finished file-storage application, not another name for the object-storage API.

7. Cloud networking services

What you get: services such as virtual networks, DNS, load balancers, gateways, content delivery, and private connectivity. These determine how traffic reaches a workload and how components communicate.

Who manages it: providers operate the network services they sell. Customers design routing, exposure, segmentation, access policies, and failover. A private subnet or private connection does not replace application authentication and authorization.

What to compare: supported topology, regional coverage, throughput, latency, firewall capabilities, logging, and resilience requirements. Account for outbound and cross-region transfer, gateway processing, public addresses, and load-balancer charges where those apply.

Provider examples: AWS, Azure, Google Cloud, and OVHcloud have networking catalogs alongside their compute and storage services. Compare the actual network path your application needs, including traffic to systems outside that provider.

Hivenet fit: assess the connectivity available with the selected Hivenet product. Access to a compute instance does not establish that Hivenet offers an equivalent standalone global CDN, private-circuit, or managed-networking portfolio.

8. Managed AI inference services

What you get: a model endpoint that your application calls. The provider operates the serving infrastructure, while you build the application around its supported models and API behavior.

Who manages it: customers remain responsible for application access, submitted data, prompts, output evaluation, and any retrieval or business logic they build. Verify data-retention terms, model licenses, processing locations, and supported features before integrating an endpoint.

What to compare: output quality on representative tasks, time to first token, throughput, concurrency, context limits, and availability. Pricing can be based on tokens, requests, or provisioned capacity. Dedicated capacity can remain billable when no request is running.

Provider examples: Amazon Bedrock, Microsoft Foundry, and Hivenet's Inference API. These services differ in model selection, deployment options, and billing.

Hivenet fit: its managed OpenAI-compatible endpoints provide an alternative to operating your own model server. Current pricing is based on replica runtime rather than a general per-token tariff. Check the selected model's availability and configuration; OpenAI compatibility does not promise identical behavior or support for every API feature.

9. Data processing, data analytics, and HPC

What you get: services for batch processing, streaming, analytics, or high-performance computing. A managed data warehouse, a workflow scheduler, and a cluster of GPU machines are different purchases even if they process the same dataset.

Who manages it: managed platforms take on specified scheduling, scaling, or engine operations. On raw compute, your team must supply that stack. In both cases, customers own data quality, job logic, access, and acceptance criteria.

What to compare: data locality, scheduling, distributed communication, storage throughput, interruption handling, and reproducibility. Price the full job, including data ingestion, failed runs, idle workers, and output storage. Some analytics products charge by data processed or reserved capacity rather than VM time.

Provider examples:Google Cloud lists BigQuery and Dataflow; Azure provides Batch and Databricks; Oracle Cloud Infrastructure includes compute options for HPC.

Hivenet fit: CPU or GPU compute with suitable storage can support customer-managed processing jobs. It should not be described as a managed warehouse or universal HPC platform. Use a distributed processing design only when the job can benefit from the coordination and data-movement costs it introduces.

10. Finished cloud software

What you get: an application for a defined task, such as email, document collaboration, file storage, or file transfer. Users work with the software rather than deploying its underlying infrastructure.

Who manages it: the provider operates the application and supporting platform. Your organization still manages accounts, permissions, shared content, retention choices, and endpoint devices. An application subscription does not settle your internal information-handling rules.

What to compare: user workflows, collaboration controls, export formats, integrations, recovery options, accessibility, and account administration. Pricing often depends on users, a subscription tier, storage allowances, or usage limits.

Provider examples:Google Workspace provides a collaboration suite. Hivenet's Store and Send address file storage and transfer.

Hivenet fit: evaluate Store or Send for those specific workflows. They are not substitutes for an entire office, identity-management, or enterprise collaboration suite.

How to compare cloud service providers for your workload

Write down the service boundary

List the tasks your team will own: operating systems, deployment, patching, monitoring, incident response, backups, and restoration. Then identify which tasks the proposed service actually includes. Microsoft's shared-responsibility guidance is useful for understanding why customer obligations continue across IaaS, PaaS, and SaaS.

If a small team cannot maintain a database reliably, a cheaper VM does not resolve that problem. Conversely, a managed platform may add cost and restrictions when the team already has a tested operating stack.

Check cloud security, data location, and access

Identify where primary data, replicas, backups, logs, and support access are handled. A selectable region is useful evidence, but it does not answer every residency or governance question. Review the service terms, technical controls, and contractual commitments together. Our guide to where cloud data is stored explains the physical-location questions behind a cloud service.

Price a complete workload

Compare runtime, storage, requests, data movement, licenses, support, and engineering effort over the same period. Include idle resources and expected recovery work. A discount tied to a long commitment changes the risk if demand falls or the service stops fitting your application.

For a steady workload, test normal demand and failure recovery. For a variable workload, test peaks, startup delay, scaling limits, and cleanup. Request an estimate for the measured configuration rather than multiplying the smallest advertised rate by an optimistic runtime.

Test performance and a cloud migration path

Run a representative workload with your actual data sizes and security settings. Measure useful output, latency, error rates, and total cost. Then export the data and configuration needed to move elsewhere. Standard interfaces can reduce migration work, but they do not remove differences in permissions, extensions, deployment tooling, or operational behavior.

Where Hivenet fits in a cloud services comparison

Hivenet is most relevant here when the requirement matches its published compute, inference, object-storage, or file-application services. Those are separate choices. A team may need Compute with Hivenet for a custom GPU workload, an Inference API endpoint for a supported model, or S3-compatible storage for datasets.

Hivenet's distributed cloud description provides context for its infrastructure and product paths. Distribution alone does not establish a particular service level, lower cost, security outcome, or data-location guarantee. Evaluate the selected product and configuration.

A provider with a broader managed-service catalog may fit better when the project depends on a particular database engine, serverless integration, network service, or enterprise suite. There is no need to force every component onto one platform. If you split services across providers, include the resulting transfer, identity, monitoring, and support work in the decision.

Frequently asked questions

What are the main types of cloud computing services?

IaaS, PaaS, and SaaS are the three standard service models. Compute, storage, networking, databases, AI, and other categories describe what a service does. A category can contain products with different management boundaries.

Which cloud service is best for a small team?

Choose the service that meets the workload's requirements with an operating burden the team can sustain. A managed application or database may be appropriate when there is no one to maintain the underlying stack. Use self-managed infrastructure when the required control justifies that work.

Are cloud services always cheaper than owned infrastructure?

No. The result depends on utilization, hardware requirements, staff time, facilities, transfer, commitments, and the evaluation period. Cloud can avoid an upfront purchase without guaranteeing a lower total cost.

Can I use different cloud providers together?

Yes, provided the services can communicate in the required way and your team can operate the combined system. Test authentication, latency, transfer charges, failure handling, and data export before treating a multi-provider design as ready for production.