The CloudOps Guide to Cloud Computing Service Models

Here's what happens at most engineering orgs: infrastructure grows, cloud bills get harder to explain, and nobody's quite sure which service layer caused the latest spike.

It's not usually a knowledge gap. AWS, GCP, and Azure all publish extensive service catalogs. The documentation exists. What doesn't exist is a clear picture of how service boundaries affect who owns what, where costs accumulate, and why incidents in one layer look completely different from incidents in another.

That's the practical problem this guide addresses. Not "what is IaaS" but "what does IaaS mean for how your team operates, attributes costs, and responds when something goes wrong." If you're also working through how to manage cloud costs across these service layers, our cloud cost optimization strategies guide covers that problem specifically.

What are the core services of cloud computing for CloudOps teams?

Cloud computing services group into four infrastructure categories: compute, storage, networking, and databases. Each carries distinct cost drivers, failure modes, and ownership questions for CloudOps teams.

The distinction matters practically. A storage cost spike and a compute cost spike need different investigation paths. A networking misconfiguration and a database misconfiguration create different blast radii.

The service category isn't just taxonomy. It's a diagnostic starting point.

Compute services: virtual machines, containers, and serverless functions

Compute is where most cloud spend originates and where rightsizing has the highest immediate impact. The three primary compute models each carry different operational tradeoffs.

Virtual machines (VMs)

VMs, EC2 on AWS, Compute Engine on GCP, Azure Virtual Machines, are the most familiar compute unit and the most common source of over-provisioning waste.

They're billed by the hour or second based on instance type, and they run whether or not the workload is using them. A VM at 15% CPU utilization for 30 days isn't a safety margin. It's a cost that doesn't need to be there.

Native rightsizing tools, AWS Compute Optimizer, Google Cloud Recommender, Azure Advisor, surface underutilized instances and suggest alternatives. Continuous monitoring catches the drift between recommendations and what actually gets provisioned.

Containers

Containers, most commonly managed through Kubernetes, introduce a different challenge. The unit of cost shifts from the VM to the pod, but most cloud billing tools don't see at the pod level.

A cluster can look right-sized at the node level while individual containers are heavily over-provisioned. Misconfigured resource requests and limits are one of the most common sources of Kubernetes waste, and they're invisible to instance-level tooling.

Kubecost is the most widely used open-source starting point for pod-level cost visibility. For teams that also need automated rightsizing recommendations, dedicated Kubernetes optimization tooling addresses the gap that native cloud tools leave.

Serverless functions

Serverless, AWS Lambda, Google Cloud Functions, Azure Functions, eliminates VM management in exchange for a different cost model: pay per invocation and per GB-second of execution.

That makes costs variable and occasionally surprising. A Lambda function invoked at 100 times the expected rate can generate significant charges within hours. The operational challenge shifts from rightsizing to invocation monitoring, memory allocation tuning, and catching runaway trigger chains before they turn into a billing conversation.

Storage services: object, block, and file storage

Storage is where orphaned resources accumulate most quietly.

Engineers provision volumes, take snapshots, upload objects. When the workload they support gets decommissioned, the storage often doesn't. It keeps generating charges at a low enough rate that nobody notices, until someone runs a storage audit 18 months later and finds a long list of things that should have been cleaned up months ago.

	Object storage	Block storage	File storage	Key waste pattern
AWS	Amazon S3	Amazon EBS	Amazon EFS	Egress fees on high-volume outbound data
GCP	Google Cloud Storage	Google Persistent Disk	Google Filestore	Orphaned snapshots from terminated instances
Azure	Azure Blob Storage	Azure Managed Disks	Azure Files	Unattached managed disks billed after VM deletion
Billed by	GB stored + requests + egress	GB provisioned (whether used or not)	GB provisioned + I/O operations	Block storage: zombie volumes persist silently after instance deletion
Remediation	Lifecycle policies to tier or delete objects automatically	Automated cleanup of unattached volumes older than defined age	Monitor I/O patterns; consider Aurora I/O-Optimized for high-I/O workloads	Include storage in tag enforcement; audit untagged volumes quarterly

Object storage

Object storage, Amazon S3, Google Cloud Storage, Azure Blob Storage, is billed by GB stored plus per-request charges and data transfer costs. The storage cost itself is usually low.

The trap is egress. Data transfer out of an S3 bucket to the internet costs $0.09/GB on AWS after the free tier. In architectures where applications pull large datasets across regions or serve content to end users without a CDN in front, egress can dominate the storage line item.

Lifecycle policies that automatically transition objects to cheaper storage tiers, S3 Infrequent Access, Glacier, or delete expired data are the most reliable way to prevent quiet accumulation.

Block storage

Block storage, Amazon EBS, Google Persistent Disk, Azure Managed Disks, is billed regardless of whether the instance it was attached to is still running.

Orphaned volumes are one of the most commonly cited sources of quiet cloud waste in practitioner communities. They show up in dedicated storage audits and almost nowhere else. An EBS volume can sit unattached and billing for months before anyone notices.

Automated cleanup policies for volumes older than a defined age and unattached to running instances are the standard fix. Tag enforcement helps ensure the cleanup can be attributed correctly.

File storage

File storage, Amazon EFS, Google Filestore, Azure Files, provides shared filesystem access for workloads that need it.

It's less frequently over-provisioned than block storage, but can generate unexpected costs in high-throughput environments where I/O operations charges compound. Worth monitoring in workloads with heavy read/write patterns.

Networking services: load balancers, CDNs, and virtual private networks

Networking is the most underestimated cost category in cloud environments.

Most teams focus optimization effort on compute and storage. Networking gets reviewed when a spike shows up in the billing report, which is usually too late to do much about the cost that already ran.

Data transfer costs

As of early 2026, AWS charges $0.01/GB for data transfer between Availability Zones in the same region, applied in each direction. That sounds trivial.

It isn't. A microservices architecture with 30 services making frequent cross-AZ calls, or a Kafka cluster generating 30MB/s of throughput, turns that $0.01 into real money fast. Teams have reported $88K/year in AWS networking costs from cross-AZ transfer alone in architectures that weren't designed with data locality in mind.

GCP and Azure have equivalent inter-zone transfer charges. The pattern is the same across all three providers.

Load balancers

Load balancers, Application Load Balancers on AWS, Cloud Load Balancing on GCP, Azure Load Balancer, are billed by the hour plus data processing charges.

Idle load balancers attached to decommissioned services are another source of quiet waste. They rarely show up as a large single line item, but they accumulate. Teams with mature cost practices include load balancer audits in regular reviews alongside compute and storage.

CDNs and VPNs

Content delivery networks, Amazon CloudFront, Google Cloud CDN, Azure CDN, reduce egress costs by moving data transfer from cloud provider egress rates to CDN rates, which are typically lower. For workloads serving content to end users at scale, this is one of the most direct networking cost levers available.

Private connectivity options, AWS Direct Connect, Google Cloud Interconnect, Azure ExpressRoute, introduce monthly commitment charges but eliminate public internet egress costs entirely for workloads where bandwidth is predictable. The math often works in favor of the commitment at sufficient volume.

Database services: relational, NoSQL, and data warehouses

Database services span the widest range of cost complexity of any infrastructure category.

The pricing models vary significantly between types. The cost drivers in a relational database are completely different from those in a NoSQL service, and both are completely different from a data warehouse. Getting the model wrong in any of these creates cost problems that are hard to trace without knowing where to look.

Relational databases

Managed relational databases, Amazon RDS, Google Cloud SQL, Azure Database for PostgreSQL/MySQL, are billed by instance size, storage, and I/O operations.

Like VMs, they're common rightsizing targets. An RDS instance provisioned for a peak load that never arrives can sit at 20% utilization for years without triggering alerts. Aurora Serverless on AWS scales capacity with actual usage, which reduces waste significantly for workloads with unpredictable demand patterns.

NoSQL databases

NoSQL services, Amazon DynamoDB, Google Cloud Bigtable, Azure Cosmos DB, use consumption-based pricing models that can be efficient for the right workloads and surprisingly expensive for the wrong ones.

DynamoDB's on-demand pricing eliminates capacity planning but can significantly exceed provisioned capacity costs at high request volumes. Provisioned capacity with auto-scaling works better for predictable patterns.

Getting the configuration wrong in either direction has immediate cost consequences. It's worth validating the pricing model against actual traffic patterns before going to production.

Data warehouses

Data warehouses, Google BigQuery, Amazon Redshift, Snowflake, have cost models that are genuinely distinct from the rest of cloud infrastructure.

BigQuery charges per TB of data scanned. A query that scans an entire table instead of a partitioned subset can cost 50 to 100 times more than a well-structured equivalent. Snowflake costs are driven by warehouse size, suspend settings, and credit consumption per job.

These aren't infrastructure optimization problems. They're query and data architecture problems that require tooling built specifically for the warehouse layer.

General cloud cost platforms show you that BigQuery spend went up. They typically can't show you which query caused it. For teams with significant Snowflake spend, PerfectScale for Snowflake provides the query-level visibility and warehouse rightsizing that cloud-level tooling doesn't reach.

Key types of cloud computing services and their CloudOps use cases

Beyond infrastructure categories, cloud services are grouped into three delivery models: IaaS, PaaS, and SaaS. The model determines how much control CloudOps teams have, how costs accumulate, and who's responsible for what when something goes wrong.

	IaaS	PaaS	SaaS	CloudOps impact
You manage	OS, runtime, middleware, apps, data	Apps and data only	Nothing — provider manages all layers	Most surface area for configuration, most leverage for optimization
Provider manages	Physical hardware, virtualization, network fabric	Hardware, OS, runtime, middleware	Everything	Less ops work per service, but harder to attribute costs
Cost model	Per instance/hour, storage GB, data transfer	Per deployment unit, request, or consumption	Per seat or subscription tier	IaaS most granular to optimize; SaaS requires seat audits
Incident ownership	CloudOps owns from OS up	Shared: provider owns infra, team owns app behavior	Provider owns availability; team owns integration and config	Clear ownership boundaries reduce incident response time
AWS examples	EC2, EBS, VPC, S3	Elastic Beanstalk, EKS, Lambda	Datadog, Snowflake, PagerDuty

Infrastructure as a Service (IaaS) for scalable operations

IaaS is the foundational layer. The cloud provider manages physical hardware, virtualization, and network fabric. You manage everything above that: the OS, middleware, runtime, data, and applications. EC2 instances, EBS volumes, VPCs — these are IaaS.

For CloudOps teams, IaaS is where the most operational control lives and where the most operational responsibility sits. You decide the instance type, the storage configuration, the networking topology.

When something goes wrong, you own the investigation from the OS up. When costs run unexpectedly, the cause is almost always in configuration choices your team made, which means the fix is there too.

IaaS gives you the flexibility to run anything. It also gives you the most surface area for misconfiguration, over-provisioning, and cost drift. Most cloud cost optimization strategies, rightsizing, commitment-based pricing, lifecycle policies, are IaaS problems.

Platform as a Service (PaaS) for application deployment and management

PaaS abstracts the infrastructure layer. The provider manages the OS, runtime, and middleware. You bring the application code and data. Google App Engine, AWS Elastic Beanstalk, Azure App Service, and managed Kubernetes services like GKE, EKS, and AKS all sit in this category.

For CloudOps teams, PaaS reduces the operational surface area for infrastructure but doesn't eliminate cost complexity. Managed Kubernetes is the clearest example: you're not managing the control plane, but you're still responsible for node pool sizing, autoscaling configuration, and container resource requests.

The operational responsibility shifts upward, not away.

PaaS also creates cost visibility challenges. Because the infrastructure is abstracted, it's harder to attribute spend to specific teams or workloads without deliberate tagging and showback. A managed service that looks like a single billing line item may be serving dozens of application teams with very different usage patterns.

SaaS cost management and shadow IT visibility

SaaS is the most abstract model. The provider manages everything including the application. You consume it through a browser or API. Datadog, Snowflake, PagerDuty, and the dozens of developer tools engineering teams adopt — all SaaS.

CloudOps teams don't typically think of SaaS as their domain. But SaaS spend has become a significant and often poorly governed part of cloud infrastructure budgets.

A few patterns come up consistently in practitioner communities:

• Shadow SaaS adoption: Engineering teams subscribe to tools independently, often on personal or team credit cards, without procurement visibility. These subscriptions don't appear in cloud billing reports, don't get tagged, and don't get reviewed in cost optimization cycles. They accumulate quietly.
• Overlapping capabilities: Organizations frequently pay for multiple tools that solve the same problem, three different APM platforms, two log aggregators, a monitoring tool that duplicates native cloud monitoring. Rationalizing the SaaS stack is often a faster cost win than any infrastructure rightsizing effort.
• Unused seat licenses: SaaS tools are typically licensed per seat. When employees leave or teams change tools, seat licenses often stay active. Regular audits of active versus licensed users in high-cost SaaS tools are a straightforward source of savings.

The governance question isn't whether CloudOps teams should manage SaaS spend. Most teams don't have that mandate.

It's whether SaaS spend gets surfaced alongside infrastructure spend so that the total cost of running engineering is visible to the people making tool adoption decisions. That visibility changes behavior.

How cloud computing services support CloudOps workflows

Knowing the categories is the easy part. The harder part is knowing which service layer is relevant to which operational problem.

Monitoring, incident response, capacity planning, and cost accountability all look different depending on where in the stack the issue lives.

Automated scaling and resource management

Every major cloud provider offers autoscaling at the compute layer. AWS Auto Scaling Groups, Google Cloud Managed Instance Groups, and Azure VM Scale Sets handle horizontal scaling for VM workloads. Kubernetes Horizontal Pod Autoscaler and Cluster Autoscaler handle containerized workloads.

Autoscaling reduces the cost of over-provisioning for peak loads. Instead of running at peak capacity continuously, resources scale up when demand arrives and back down when it passes.

The catch is that policies need to be tuned correctly. Scale-up thresholds set too conservatively cause performance degradation. Scale-down thresholds set too aggressively cause flapping. Scale-in protection settings that are never reviewed create instances that never terminate.

Autoscaling is also where some of the most surprising cloud bills originate. A misconfigured trigger that causes a fleet to scale to maximum capacity and stay there, particularly in a dev or staging environment, can generate significant charges before anyone notices. Monitoring autoscaling events as part of cost anomaly detection is a worthwhile addition to any CloudOps monitoring setup.

Monitoring, logging, and observability integration

Native observability tooling covers the basics at every service layer. Amazon CloudWatch, Google Cloud Monitoring, and Azure Monitor handle metrics, logs, and alerting within their respective clouds. For single-cloud environments, native tooling is usually sufficient.

Multi-cloud environments introduce a fragmentation problem. Three clouds means three monitoring consoles, three alert routing systems, and three log aggregation pipelines. Cross-provider correlation, "this AWS Lambda spike is connected to this GCP Pub/Sub backlog," becomes a manual exercise rather than an automated one.

The observability layer also intersects directly with cost attribution. Logs and metrics tell you what's happening. Tags tell you who owns it.

When tag coverage is incomplete, even excellent monitoring data can't tell you which team or workload is responsible for an anomaly. This is why tagging enforcement belongs in your observability strategy, not separate from it.

Cost allocation and financial accountability across services

Cost allocation is the organizational problem that sits underneath all the technical ones.

You can rightsize every instance, optimize every Savings Plan, and tune every autoscaling policy, and still have no way to tell finance which team spent $40K last month, or why.

Effective cost allocation requires three things working together: consistent resource tagging across all providers (team, environment, application, cost center at minimum), billing exports to a queryable store (AWS Cost and Usage Report to S3, GCP billing export to BigQuery, Azure Cost Management exports to Azure Storage), and a layer that maps spend to organizational context that finance and engineering actually care about.

Native billing tools show spend by service and by tag. They don't show spend by product, by customer, or by business unit without custom work. That gap is where most teams get stuck.

DoiT's CloudOps platform provides the cross-service visibility and attribution layer that makes cost data actionable for the people making infrastructure decisions, not just the people reading the billing console.

Best practices for selecting and integrating cloud computing services in CloudOps

Service selection in cloud environments is rarely a pure technical decision.

The operational complexity a service introduces, its cost predictability, and its impact on team cognitive load matter as much as the feature set. The questions teams should ask before adopting a service are different from the questions most teams actually ask.

Step 1: Evaluate services for operational complexity and cost impact

Before adopting a new cloud service, CloudOps teams that manage costs well ask a consistent set of questions. Not all of them are technical:

• What's the pricing model, and what's the worst-case cost scenario? Usage-based services like BigQuery and Lambda can generate surprising bills under unexpected load patterns. Know the ceiling before the ceiling surprises you.
• What are the egress implications? Moving data into a cloud service is usually free. Moving it out, to the internet, to another region, or to another provider, typically isn't. Services that create high-egress patterns can dominate the networking cost line.
• What does a failure in this service look like operationally? A managed database going unavailable is a different incident than a serverless function cold-starting slowly. Understanding the failure modes helps teams design monitoring and alerting before they need it.
• Who owns it, and how will costs be attributed? A service with no clear team ownership tends to become an untagged line item that nobody investigates when it grows. Establishing ownership before adoption prevents the governance gap that creates zombie infrastructure.
• Does this service overlap with something you already have? Before adopting a new observability, logging, or analytics service, check whether existing tools already cover the use case. SaaS and PaaS sprawl often comes from adoption decisions made in isolation.

Step 2: Build service integration strategies that scale

Cloud services don't operate in isolation. A compute layer depends on storage. An application depends on a database. A monitoring system depends on logs from all of the above.

How those integrations are designed has direct implications for cost, reliability, and operational complexity. A few patterns consistently create problems at scale:

• Cross-region data dependencies: An application in us-east-1 that reads from a database in us-west-2 pays cross-region data transfer costs on every query. In high-throughput applications, this accumulates fast. Designing for data locality, keeping compute and storage in the same region when possible, is one of the highest-leverage architectural decisions for networking cost control.
• Synchronous chains across service boundaries: Microservices architectures that chain synchronous HTTP calls across services multiply latency, create cascading failure risk, and generate inter-service data transfer costs. Asynchronous messaging patterns using managed queues (Amazon SQS, Google Cloud Pub/Sub, Azure Service Bus) reduce both the reliability risk and the networking overhead.
• Unmanaged service sprawl: Each new service in the stack is a new thing to monitor, tag, alert on, and attribute costs for. Adding services is easy. Building the operational context around them, ownership, monitoring, tagging, runbooks, takes time. CloudOps teams that scale well are deliberate about limiting sprawl and retiring services that are no longer earning their operational overhead.

Step 3: Establish governance without slowing development teams

Governance in cloud environments has a reputation problem.

When it's implemented as manual approvals and bureaucratic checklists, it slows teams down and gets bypassed. When it's implemented as automated policy, tagging enforcement, budget alerts, cost attribution, it runs in the background and doesn't get in anyone's way.

The governance patterns that actually stick are the ones developers don't have to think about:

• Tag policies enforced at provisioning time through AWS Tag Policies, GCP Organization Policy, or Azure Policy mean untagged resources can't be created, rather than being created and cleaned up later.
• Budget alerts scoped to teams and cost centers route to the engineers responsible for the spend, not to a central ops inbox that nobody checks.
• Automated shutdown policies for non-production environments run on schedules rather than depending on engineers remembering to turn things off. Dev and test environments that don't run nights and weekends typically save 50% to 70% of their compute cost with no impact on productivity.
• Cost visibility embedded in pull request workflows, showing the estimated infrastructure cost change alongside code changes, brings financial accountability into the development process rather than treating it as a post-deployment concern.

The challenge isn't knowing what good governance looks like. Most CloudOps leads can describe it clearly. The challenge is implementing it across multiple cloud providers, multiple teams, and multiple service layers without building and maintaining a custom tooling stack to do it.

That's the problem DoiT's platform is built to address, cross-provider tagging enforcement, anomaly detection, cost attribution, and rightsizing recommendations in one place, without requiring teams to build the infrastructure themselves.

Maximizing CloudOps efficiency through strategic cloud service management

The operational complexity of cloud computing services doesn't decrease as infrastructure grows. It compounds.

More services mean more monitoring surfaces, more cost attribution requirements, more governance touchpoints, and more failure modes to understand.

The teams that manage this well aren't the ones with the most engineers. They're the ones who've built systems that give them leverage. That leverage comes from a few consistent practices:

• Visibility before optimization: You can't rightsize what you can't see, and you can't attribute costs you haven't tagged. Investment in observability and cost attribution infrastructure pays compound returns as the environment scales.
• Automation over manual processes: Manual cost reviews, manual tag audits, and manual rightsizing assessments don't scale with the infrastructure. Teams that automate anomaly detection, tag enforcement, and routine remediation free engineers for the work that actually requires judgment.
• Service selection discipline: The best time to ask "how will we operate and attribute the cost of this service?" is before adopting it, not after it's been running for six months and generating untagged spend.
• Process over projects: Cloud cost optimization and infrastructure governance aren't one-time efforts. They're ongoing operational practices. Teams that build them into sprint planning, architecture reviews, and postmortems sustain the gains. Teams that treat them as projects find themselves starting over every few months.

The practical outcome is faster incident resolution, more predictable costs, and the ability to scale infrastructure without proportionally scaling the team that manages it.

If you want to see how other CloudOps teams have approached this, talk to the DoiT team.

---

Frequently asked questions

What are the core services of cloud computing?

The core services of cloud computing fall into four infrastructure categories: compute (virtual machines, containers, and serverless functions), storage (object, block, and file storage), networking (load balancers, CDNs, VPNs, and data transfer), and databases (relational, NoSQL, and data warehouses). These infrastructure services are delivered through three service models: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS).

What is the difference between IaaS, PaaS, and SaaS?

IaaS gives you control over virtual infrastructure — you manage the OS, runtime, and applications while the cloud provider manages the physical hardware. PaaS abstracts the infrastructure layer so you can focus on deploying and managing applications without managing servers. SaaS delivers fully managed applications through a browser or API, with the provider handling everything from infrastructure to the application layer. For CloudOps teams, the model determines how much operational responsibility you carry and how costs are attributed.

Which cloud providers offer the core cloud computing services?

Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure all offer the full range of core cloud computing services. AWS EC2, Google Compute Engine, and Azure Virtual Machines cover IaaS compute. Amazon S3, Google Cloud Storage, and Azure Blob Storage cover object storage. Amazon RDS, Google Cloud SQL, and Azure Database handle managed relational databases. Each provider has equivalent services across all major categories, with pricing models and feature sets that vary by workload type.

How do cloud computing services affect CloudOps costs?

Different service categories create different cost drivers. Compute costs are driven by instance sizing and utilization. Storage costs are driven by data volume, access frequency, and egress. Networking costs, often underestimated, accumulate from data transfer between availability zones, regions, and the public internet. Database costs vary significantly by service type: managed relational databases bill by instance size, while data warehouses like BigQuery bill by data scanned per query. Understanding which layer is generating cost is the first step in controlling it.

What's the best way to manage costs across multiple cloud services?

Effective cost management across cloud services requires three things working together: consistent resource tagging across all providers and service types, billing exports to a queryable data store (AWS Cost and Usage Report, GCP billing export to BigQuery, Azure Cost Management exports), and continuous monitoring with anomaly detection to catch cost spikes before they compound. For a detailed breakdown of optimization strategies across each service layer, see our cloud cost optimization strategies guide.

What is shadow IT in the context of cloud services?

Shadow IT refers to cloud services and SaaS tools adopted by engineering teams without formal procurement or IT visibility. In cloud environments, this commonly means team subscriptions to monitoring tools, development platforms, or data services that don't appear in central billing reports, don't get tagged with cost attribution metadata, and don't get reviewed in cost optimization cycles. Shadow IT isn't inherently bad, it often reflects teams solving real problems quickly, but without visibility into what's been adopted and what it costs, it becomes a governance gap that accumulates quietly.

---

---

Related reading

• Cloud Cost Optimization Strategies for CloudOps
• Cloud Architecture Explained: Key Elements and Strategies
• DoiT CloudOps Platform