35  Cloud Data: Platforms and Services

In 60 Seconds

Cloud platforms for IoT offer three service models – IaaS (you manage infrastructure), PaaS (managed development platforms), and SaaS (complete applications) – with major platforms like AWS IoT Core and Azure IoT Hub providing device management, data ingestion, and analytics. Cost optimization requires evaluating the full stack including messaging, storage, and analytics services.

35.1 Introduction

Choosing the right cloud platform for an IoT deployment involves more than comparing feature lists. This chapter examines the three cloud service models (IaaS, PaaS, SaaS), compares major IoT platforms (AWS IoT Core, Azure IoT Hub, and alternatives), and develops quantitative frameworks for cost optimization and total cost of ownership analysis.

35.2 Learning Objectives

By the end of this chapter, you will be able to:

  • Compare Cloud Service Models: Evaluate IaaS, PaaS, and SaaS for IoT applications
  • Select Cloud Platforms: Choose between AWS IoT Core, Azure IoT Hub, and alternatives based on requirements
  • Optimize Cloud Costs: Apply cost optimization strategies including right-sizing, reserved instances, and data lifecycle policies
  • Design TCO Analysis: Calculate and compare total cost of ownership for cloud vs on-premises deployments

Cloud platforms like AWS and Azure offer pre-built services for IoT – device management, data storage, real-time analytics – so you don’t have to build everything from scratch. Think of it like choosing between renting a fully equipped kitchen (SaaS), renting kitchen space with your own appliances (PaaS), or renting just the building and installing everything yourself (IaaS). Each option trades control for convenience, and the right choice depends on your team’s expertise, budget, and how many devices you need to manage.

35.3 Prerequisites

Before diving into this chapter, you should be familiar with:

35.4 Cloud Computing Overview

Time: ~10 min | Level: Foundational | Unit: P10.C03.U02

Diagram showing the three cloud service models -- IaaS, PaaS, and SaaS -- mapped to an IoT data pipeline with data flowing from devices through infrastructure, platform, and application layers
Figure 35.1: Cloud Service Models IaaS PaaS SaaS for IoT Data Pipeline
Vertical layered architecture diagram showing edge devices at the bottom feeding into IaaS infrastructure, then PaaS development platforms, and SaaS applications at the top, with each layer trading control for convenience
Figure 35.2: Alternative view: Vertical layered stack showing how cloud service models build upon each other. Edge devices feed into IaaS infrastructure, which powers PaaS development platforms, ultimately delivering SaaS applications. Each layer trades control for convenience.

This step-by-step view shows how data moves from the device layer toward the cloud while the amount of information is reduced at each stage:

1. Device + sensor

Capture raw readings such as vibration, temperature, location, or status changes at the highest sampling rate.

Typical output: continuous raw measurements or event pulses

2. Gateway + buffering

Batch nearby readings, attach timestamps, handle intermittent connectivity, and remove obvious duplicates.

Typical output: filtered packets or short buffered batches

3. Edge processing

Compute features, threshold alarms, rolling averages, or compressed summaries close to the device.

Typical output: alerts, aggregates, and compact feature vectors

4. Cloud services

Store long-term history, run fleet analytics, train models, and feed dashboards with the reduced data stream.

Typical input: summaries and exceptions instead of full raw sensor streams

This view emphasizes how data volume is progressively reduced at each tier, with the cloud receiving pre-processed summaries rather than raw sensor streams.

Matrix showing which components (networking, storage, OS, runtime, application, data) are managed by the customer versus the cloud provider under IaaS, PaaS, and SaaS models
Figure 35.3: Cloud Responsibility Matrix: Who manages what in each service model

Cloud computing provisions on-demand services to clients, providing shared resources across organizations:

Service Models:

  • IaaS (Infrastructure as a Service): Virtual machines, storage, networks
  • PaaS (Platform as a Service): Development platforms and tools
  • SaaS (Software as a Service): Complete applications

Advantages for IoT:

  • Lower upfront costs: No need to purchase and maintain servers for handling millions of sensor messages
  • Elastic scaling: Automatically handle traffic spikes (e.g., all sensors reporting simultaneously after a power outage)
  • Managed services: Device provisioning, OTA firmware updates, and certificate management handled by the platform
  • Global reach: Deploy ingestion endpoints close to devices worldwide, reducing latency

Disadvantages for IoT:

  • Internet dependency: Sensor data cannot reach the cloud during connectivity outages (mitigated by edge buffering)
  • Bandwidth costs: High-frequency sensors (e.g., vibration at 10 kHz) can generate significant egress charges
  • Latency: 50-200ms round-trip may be too slow for real-time control loops requiring <10ms response
  • Data sovereignty: Sensor data crossing geographic boundaries may violate industry regulations (GDPR, HIPAA)

Cloud computing service models diagram showing three layers: IaaS (Infrastructure as a Service) at the bottom with Virtual Machine, Virtual Storage, and Virtual Grid components; PaaS (Platform as a Service) in the middle with security, integration, workflow, UI services, database grid, and application grid components; and SaaS (Software as a Service) at the top supporting multiple applications. Admin Service panel shows packaging, configuration, deployment, scaling, lifecycle management, utilization, and user management capabilities.

Cloud service models architecture showing the layered relationship between IaaS (Infrastructure), PaaS (Platform), and SaaS (Software) with their respective components and interfaces

This diagram illustrates the cloud computing stack showing how IaaS provides virtualized infrastructure (compute, storage, network), PaaS adds development platforms and services on top, and SaaS delivers complete applications to end users. Each layer builds upon the services below it, with Admin Services managing the entire stack.

35.5 IoT Cloud Platform Comparison

With Google Cloud IoT Core discontinued in 2023, the major IoT cloud platforms are AWS IoT Core, Azure IoT Hub, and specialized alternatives like ClearBlade. Each platform bundles device management, message ingestion, storage, and analytics differently, making direct cost comparisons challenging without evaluating the full service stack.

Decision flowchart comparing AWS IoT Core, Azure IoT Hub, and ClearBlade based on device scale, existing infrastructure, and edge processing requirements
Figure 35.4: IoT Cloud Platform Comparison: AWS vs Azure vs ClearBlade decision guide

Use this quick snapshot when you need a readable mobile-friendly comparison of the main platform choices:

AWS IoT Core

Strength: Broadest IoT service ecosystem

Pricing: $1.00 per million messages

Best fit: Teams already invested in AWS analytics, storage, and event services

Azure IoT Hub

Strength: Microsoft enterprise integration

Pricing: $0.80 per million messages on the S3 tier

Best fit: Organizations using Azure AD, Power BI, and wider Microsoft cloud tooling

ClearBlade

Strength: Edge-first orchestration and deployment patterns

Pricing: Usually negotiated or solution-specific rather than commodity message pricing

Best fit: Deployments that need strong edge processing before forwarding data to the cloud

35.6 The Four Vs in the Cloud

Time: ~10 min | Level: Intermediate | Unit: P10.C03.U05

Beyond platform selection, understanding how cloud services address the fundamental challenges of big data helps architects make informed design decisions. The four Vs framework maps each challenge to specific cloud capabilities.

Diagram mapping the four Vs of big data -- Volume, Velocity, Variety, and Veracity -- to corresponding cloud computing solutions such as elastic storage, parallel processing, flexible frameworks, and automated validation
Figure 35.5: Four Vs of Big Data Mapped to Cloud Solutions

The four Vs of big data are addressed differently in the cloud:

Volume: Cloud can expand services and storage to deal with large volumes. Providers have fast Internet connections, potentially giving greater bandwidth. However, users need to track usage and charges.

Velocity: Can be handled by expanding through the cloud. Parallel processing is a key option, distributing workflow to keep up with inward flows.

Variety: While cloud provides processing power, variety still needs coding to support all cases. Machine learning algorithms can automatically deal with multiple channels and variations.

Veracity: Cloud computing does not directly address biases, noise, or abnormalities in sensor data. However, once validation logic is implemented, cloud services can distribute the workload across parallel pipelines and apply learned patterns at scale.

35.7 Cloud Cost Tradeoffs

Tradeoff Decision Guide: Cloud vs On-Premises IoT Data

Initial Cost

Cloud: Low (pay-as-you-go)

On-premises: High (CapEx for hardware)

Choose when: Cloud for startups and pilots; on-premises for teams with existing infrastructure

Scalability

Cloud: Instant elastic scaling

On-premises: Limited by physical capacity

Choose when: Cloud for variable workloads; on-premises for predictable steady-state demand

Data Sovereignty

Cloud: Data leaves your premises

On-premises: Full control over data location

Choose when: On-premises for regulated industries such as healthcare or government

Latency

Cloud: 50-200 ms round-trip

On-premises: Under 10 ms local processing

Choose when: On-premises for real-time control; cloud for analytics and dashboards

Maintenance

Cloud: Provider-managed

On-premises: Your team maintains the platform

Choose when: Cloud for lean IT teams; on-premises when you have dedicated operations staff

Long-term Cost (3 years)

Cloud: Can exceed on-premises at scale

On-premises: Lower at large, steady scale

Choose when: Cloud below about 1,000 devices; on-premises above about 5,000 steady devices

Quick Decision Rule: Start with cloud for flexibility and rapid iteration; migrate specific workloads on-premises only when you have proven, steady-state data volumes exceeding 10TB/month and dedicated operations staff.

Tradeoff: Serverless Functions vs Containers for IoT Data Processing

Option A (Serverless - AWS Lambda/Azure Functions):

  • Cold start latency: 100-500ms (first invocation), <10ms warm
  • Scaling: Automatic, 0-1000+ concurrent executions in seconds
  • Cost at low volume: $0.20/million requests + $0.0000166/GB-second
  • Cost at 10M requests/month: ~$20-50 (highly efficient for bursty workloads)
  • Max execution time: 15 minutes (Lambda), 10 minutes (Azure Functions consumption plan; unlimited on premium)
  • Memory limit: 10 GB (Lambda), 14 GB (Azure)
  • Ops overhead: Zero infrastructure management

Option B (Containers - ECS/EKS/AKS):

  • Startup latency: 2-30 seconds (container pull + start)
  • Scaling: Manual or auto-scaling with 30-60 second reaction time
  • Cost at low volume: ~$50-100/month minimum (always-on instances)
  • Cost at 10M requests/month: ~$100-300 (fixed cost regardless of traffic)
  • Max execution time: Unlimited (long-running processes supported)
  • Memory limit: Up to 256 GB per container
  • Ops overhead: Cluster management, networking, updates required

Decision Factors:

  • Choose Serverless when: Workload is bursty/unpredictable (sensor alerts), processing completes in <15 minutes, team lacks Kubernetes expertise, cost optimization for variable traffic is critical
  • Choose Containers when: Processing requires >15 minutes (ML batch inference), need persistent connections (MQTT brokers), memory exceeds 10 GB, predictable high-volume steady-state traffic (>50M requests/month makes containers cheaper)
  • Hybrid pattern: Use serverless for event ingestion and routing, containers for heavy processing (e.g., Lambda triggers ECS Fargate task for video analytics)
Tradeoff: Managed Database Services vs Self-Hosted Databases for IoT

Option A (Managed - AWS RDS/Azure SQL/Google Cloud SQL):

  • Setup time: 5-15 minutes via console/CLI
  • Availability SLA: 99.95% (Multi-AZ), automatic failover in 60-120 seconds
  • Backup/restore: Automated daily snapshots, point-in-time recovery to any second
  • Scaling: Vertical in minutes (some downtime), read replicas in hours
  • Cost for 100GB TimescaleDB: ~$150-300/month (db.r5.large equivalent)
  • Ops overhead: Zero patching, monitoring, or backup management
  • Vendor lock-in: High (proprietary extensions, migration complexity)

Option B (Self-Hosted - EC2/VM with PostgreSQL/TimescaleDB):

  • Setup time: 2-8 hours (OS, DB install, security hardening, monitoring)
  • Availability: Manual HA setup required (Patroni, repmgr), failover in 30-300 seconds
  • Backup/restore: Manual configuration (pg_dump, WAL archiving, S3 scripts)
  • Scaling: Full control, but requires planned downtime and expertise
  • Cost for 100GB TimescaleDB: ~$80-120/month (r5.large spot + EBS)
  • Ops overhead: 4-10 hours/month (patching, monitoring, incident response)
  • Vendor lock-in: Low (portable to any cloud or on-premises)

Decision Factors:

  • Choose Managed when: Team has <2 DBAs, uptime SLA >99.9% required, rapid scaling needed (Black Friday spikes), compliance requires automated audit trails
  • Choose Self-Hosted when: Cost optimization is critical (30-50% savings at scale), need unsupported extensions (PostGIS, custom plugins), multi-cloud portability required, team has strong PostgreSQL/MySQL expertise
  • Break-even point: Managed services typically cost-effective below 500GB; self-hosted wins above 2TB with dedicated DBA time
Tradeoff: Single-Region vs Multi-Region Cloud Deployment for IoT Data

Option A (Single-Region Deployment):

  • Availability SLA: 99.9-99.95% (region-level redundancy via availability zones)
  • RTO on region failure: 4-24 hours (manual failover to new region, DNS propagation, data restoration)
  • RPO on region failure: Minutes to hours (depends on backup frequency to other regions)
  • Latency: Optimal for devices in same region (10-50ms), degraded for distant devices (100-300ms)
  • Data consistency: Strong - single source of truth, no cross-region sync conflicts
  • Operational complexity: Low - single deployment, straightforward monitoring
  • Monthly cost (100K devices): $2,000-5,000 (single IoT Hub + storage + compute)
  • Compliance: Simpler - data stays in one jurisdiction

Option B (Multi-Region Active-Active Deployment):

  • Availability SLA: 99.99%+ (survives complete region failure with automatic failover)
  • RTO on region failure: 30-120 seconds (traffic automatically routes to healthy region)
  • RPO on region failure: 0-5 seconds (synchronous or near-synchronous replication)
  • Latency: Optimized globally (devices connect to nearest region, 10-50ms worldwide)
  • Data consistency: Eventual or conflict resolution required (last-write-wins, CRDTs)
  • Operational complexity: High - multi-region orchestration, conflict handling, global traffic management
  • Monthly cost (100K devices): $6,000-15,000 (2-3x infrastructure + cross-region data transfer)
  • Compliance: Complex - must handle data sovereignty for each region

Decision Factors:

  • Choose Single-Region when: Devices concentrated in one geography, 99.9% availability meets SLA, budget constrained (3x cost difference), team lacks multi-region expertise, data sovereignty requires single jurisdiction
  • Choose Multi-Region when: Global device fleet requiring low latency everywhere, business-critical systems where region failure causes >$100K/hour loss, regulatory requirements mandate geographic redundancy (financial services), customer SLA requires 99.99%+ uptime
  • Read replica pattern: Single write region with read replicas in other regions - achieves low global read latency at 1.5x cost while maintaining strong consistency for writes

Scenario: A logistics company wants to deploy GPS trackers on 10,000 delivery vehicles. Each tracker reports location, speed, and engine diagnostics every 30 seconds. The company needs to select a cloud platform and estimate monthly costs for the first year.

Given:

  • Fleet size: 10,000 vehicles
  • Reporting interval: Every 30 seconds (2 messages/minute per vehicle)
  • Payload size: 200 bytes per message (GPS + diagnostics)
  • Operating hours: 12 hours/day, 6 days/week
  • Retention requirement: 90 days of raw data, 2 years of aggregated data
  • Analytics: Real-time dashboards + daily route optimization reports
  • Existing infrastructure: Microsoft Azure Active Directory for employee auth

Solution:

Step 1: Calculate message volume

Messages per vehicle per day: - 12 hours × 60 minutes × 2 messages/min = 1,440 messages/vehicle/day

Total daily messages: - 10,000 vehicles × 1,440 = 14.4 million messages/day

Monthly messages (26 operating days): - 14.4M × 26 = 374.4 million messages/month

Step 2: Calculate data volume

Daily data volume: - 14.4M messages × 200 bytes = 2.88 GB/day

Monthly ingest: - 2.88 GB × 26 = 74.88 GB/month

90-day raw storage: - 74.88 GB × 3 months = 224.64 GB

2-year aggregated storage (assume 10:1 compression): - 74.88 GB × 24 months ÷ 10 = 179.7 GB

Step 3: Compare cloud platform pricing

Message pricing

AWS IoT Core: $1.00/million messages

Azure IoT Hub: $0.80/million on the S3 tier

Monthly message cost

AWS IoT Core: 374.4 x $1.00 = $374

Azure IoT Hub: 374.4 x $0.80 = $300

Device registry

AWS IoT Core: Free for the first 500K devices

Azure IoT Hub: Included in the hub tier

Storage (hot tier)

AWS IoT Core: S3 at $0.023/GB

Azure IoT Hub: Blob Storage at $0.018/GB

Stream processing

AWS IoT Core: Kinesis at about $150/month

Azure IoT Hub: Stream Analytics at about $80/month

Integration benefit

AWS IoT Core: No built-in Azure AD equivalent

Azure IoT Hub: Azure AD SSO included

Step 4: Evaluate platform fit

Message cost

AWS IoT Core: $374/month

Azure IoT Hub: $300/month

Decision: Azure wins

Authentication integration

AWS IoT Core: Requires Cognito setup

Azure IoT Hub: Native Azure AD integration

Decision: Azure wins

Analytics tooling

AWS IoT Core: QuickSight at about $250/month

Azure IoT Hub: Power BI included

Decision: Azure wins

Edge SDK maturity

AWS IoT Core: Greengrass is mature

Azure IoT Hub: IoT Edge is mature

Decision: Tie

Scale experience

AWS IoT Core: Proven at 1M+ devices

Azure IoT Hub: Proven at 1M+ devices

Decision: Tie

Step 5: Calculate total monthly cost (Azure)

  • IoT Hub (S3 tier, 300M messages): $3,000
  • Additional messages (74.4M x $0.80): $60
  • Blob Storage (hot tier): $4.05
  • Stream Analytics (6 SU): $80
  • Azure Maps (route optimization): $450
  • Power BI Pro (5 analysts): $50
  • Total: $3,644/month

Annual cost: $3,644 × 12 = $43,728/year Cost per vehicle: $43,728 ÷ 10,000 = $4.37/vehicle/year

Result: Azure IoT Hub is the recommended platform due to existing Azure AD integration, lower per-message costs, and included Power BI licensing. Total first-year cost is approximately $43,728, or $4.37 per vehicle annually—well within typical fleet management budgets of $10-20/vehicle/year.

Key Insight: Cloud platform selection should prioritize existing infrastructure integration over raw pricing. The Azure AD integration alone saves 40+ hours of authentication setup and ongoing maintenance. When evaluating costs, include the full stack (messaging + storage + analytics + visualization) rather than just the IoT service pricing, as auxiliary services often exceed core messaging costs.

35.7.1 IoT Cloud Cost Estimator

Adjust the parameters below to estimate monthly cloud costs for your IoT deployment. The calculator uses typical Azure IoT Hub pricing.

Cloud vs On-Premises TCO for 10,000-sensor deployment over 3 years:

Cloud (AWS/Azure): Messaging \((10,000 \times 2 \text{ msg/min} \times 1440 \text{ min/day} \times 30 \text{ days}) = 864M \text{ msg/month} \times \$0.80/\text{million} = \$691/\text{month}\). Storage \((30 \times 1.73\text{ GB/day}) = 52\text{ GB} \times \$0.023 = \$1.20/\text{month}\). Compute (streaming + batch) \(\$800/\text{month}\). Total: \(\$1,492/\text{month} \times 36 = \$53,712\) over 3 years.

On-Premises: Hardware \(\$85,000\) (servers, storage, network). Annual power \((50\text{ kW} \times 8760\text{ h} \times \$0.10) = \$43,800\). Maintenance (15% of hardware) \(\$12,750/\text{year}\). Staffing (1.5 FTE) \(\$180,000/\text{year}\). Total: \(\$85,000 + (43,800 + 12,750 + 180,000) \times 3 = \$794,650\) over 3 years.

Cloud savings: \((794,650 - 53,712) / 794,650 = 93.2\%\). Cloud wins by eliminating capital costs and dedicated staffing. Break-even at >50,000 sensors with dedicated ops team, where economies of scale favor on-premises.

35.7.2 Cloud vs On-Premises TCO Calculator

Compare total cost of ownership over a multi-year period by adjusting the parameters below.

35.8 Knowledge Check

Scenario: Your fleet of 10,000 smart meters generates 1 KB/reading every 15 minutes. Cloud ingestion costs $0.10/GB, storage $0.023/GB/month, and compute $0.05/hour for analytics. Current architecture: Send all raw data to cloud immediately.

Think about:

  1. What are monthly data transfer costs with current architecture?
  2. How much could you save with edge aggregation (hourly summaries only to cloud)?
  3. What’s the break-even point for adding edge processing hardware?

Key Insight: Current costs: 10,000 meters x 96 readings/day x 1 KB = 0.96 GB/day x 30 days = 28.8 GB/month. Transfer: 28.8 GB x $0.10 = $2.88/month. Storage: 28.8 GB x $0.023 = $0.66/month. Compute (2 hours/day): 60 hours x $0.05 = $3/month. Total: $6.54/month. With edge aggregation (hourly summaries – 24 readings/day instead of 96, a 4x reduction): 7.2 GB/month. New costs: Transfer $0.72 + Storage $0.17 + Compute $3 = $3.89/month (41% savings). At this small data volume, the savings are modest because 28.8 GB/month is relatively small. The real value of edge aggregation emerges at scale: if each reading were 10 KB (richer telemetry with waveform data), monthly volume grows to 288 GB, costing $32/month in transfer + storage alone. Edge aggregation then cuts that to 72 GB and $8/month – saving $24/month ($288/year). This demonstrates the Level 5-6 trade-off: process at edge (Level 3) to reduce cloud costs (Level 5-6).

Key Concepts
  • Cloud Service Models: IaaS (infrastructure control), PaaS (managed platforms), SaaS (complete applications) offering different management-control trade-offs
  • Four Vs in Cloud: Volume (elastic storage), Velocity (parallel processing), Variety (flexible frameworks), Veracity (automated validation)
  • Cost Optimization: Right-sizing resources, reserved/spot instances, lifecycle policies, and per-operation tracking reducing cloud expenditure
  • TCO Analysis: 3-year cost comparison between cloud and on-premises considering capital, operational, and opportunity costs

Choosing a cloud platform is like picking the right tool for a job – you wouldn’t use a hammer to paint a picture!

35.8.1 The Sensor Squad Adventure: The Three Cloud Castles

Sammy the Sensor needed to send her data to the cloud, but there were THREE different Cloud Castles to choose from!

The first castle was AWS Castle (Amazon). It was the BIGGEST castle with the most rooms and tools. “We have everything you could ever need!” said the castle keeper. “Storage rooms, computing halls, messaging towers – you name it!” Max the Microcontroller was impressed. “This is great for huge projects with millions of sensors.”

The second castle was Azure Castle (Microsoft). “We work perfectly with all your Microsoft tools!” said the keeper. “If your school already uses Microsoft, everything connects easily.” Lila the LED noticed that the dashboards looked just like the charts in their favorite spreadsheet program.

The third castle was ClearBlade Castle. “We’re experts at working close to where the sensors are,” explained the keeper. “We start processing data right at the edge before sending it to the cloud!”

Bella the Battery thought carefully. “The best castle depends on what you need. If you need LOTS of tools, go to AWS. If your school uses Microsoft, try Azure. If you want edge processing, try ClearBlade.”

Sammy learned the most important lesson: “Don’t just look at the price of one room – check how much ALL the rooms you need will cost together!”

35.8.2 Key Words for Kids

  • IaaS: Renting the building blocks (like Lego bricks) so you can build your own system
  • PaaS: Renting a workshop with the tools already set up so you can start building immediately
  • SaaS: Renting a finished product that is ready to use right away
  • Platform: A cloud service that gives you the tools and services needed to build IoT solutions

Common Pitfalls

Building device firmware that speaks directly to AWS IoT Core’s proprietary Shadow API or Azure IoT Hub’s device twin protocol makes migration to another cloud provider expensive. Abstract the device-to-cloud interface with a standard protocol (MQTT + standard topic schema) and translate at the gateway.

Managed IoT platform pricing looks cheap per message but compounds rapidly at IoT scale. 1 million messages per day at $0.08 per million costs $29/year but 1 billion messages per day costs $29,000/year. Model pricing at 10x expected growth before committing to a platform.

AWS IoT Core, Azure IoT Hub, and Google Cloud IoT all offer similar features. The right choice depends on your team’s existing cloud expertise, compliance requirements, and which services you already use — not on feature comparison tables.

Modern IoT platforms offer edge compute extensions (AWS Greengrass, Azure IoT Edge). Failing to evaluate these extensions means missing the opportunity to run cloud-managed workloads at the edge without building custom edge infrastructure.

35.9 Summary

Cloud computing provides elastic infrastructure for IoT data processing through three service models. IaaS offers maximum control with infrastructure management responsibility. PaaS provides managed platforms reducing operational overhead. SaaS delivers complete applications requiring minimal management. The four Vs of big data map directly to cloud capabilities: Volume to elastic storage, Velocity to parallel processing, Variety to flexible frameworks, and Veracity to automated validation pipelines. Cost optimization requires understanding pricing models, leveraging reserved instances for predictable workloads, and using tiered storage policies.

35.10 What’s Next

If you want to… Read this
Understand the reference model these platforms implement Cloud Data IoT Reference Model
Explore cloud architecture patterns Cloud Data Architecture Gallery
Learn about data quality and security on these platforms Cloud Data Quality and Security
Study foundational cloud data concepts Data in the Cloud
Return to the module overview Big Data Overview

Cloud & Edge Architecture:

Integration:

Learning Hubs: