Cloud Analytics: Architecture, Security, Cost, and Migration

Cloud analytics uses cloud-hosted infrastructure or managed services to ingest, store, process, govern, and analyze data. It can provide elastic capacity and reduce selected infrastructure work, but analytics can also run effectively on-premises or at the edge. Placement depends on data gravity, latency, sovereignty, security, integration, skills, service objectives, and total cost.

Cloud services do not make capacity unlimited, cost predictable, access universal, or insight automatic. Define the decision being supported; freshness, latency, concurrency, and recovery targets; classification and residency; quality controls; query and storage profile; and exit constraints. Then test viable architectures.

Compare placement without absolutes

Dimension	Cloud-hosted or managed	On-premises or edge
Capacity	Provision within quotas, regions, and architecture limits.	Plan owned or contracted capacity.
Cost	Usage and service fees plus egress, idle resources, support, and operations.	Capital and lifecycle costs; may suit stable, utilized workloads.
Control	Provider controls part of the stack; responsibility varies by service.	Organization controls and operates more layers.
Location and latency	Useful near cloud data and consumers; transfer and residency constrain design.	Useful for local, regulated, disconnected, or very low-latency work.
Change	Managed services reduce some maintenance while adding quotas and provider evolution.	Versions and windows can be controlled directly, with more maintenance.

Neither placement is inherently more secure, agile, or economical. Compare the lifecycle. The cloud architecture patterns guide helps frame system choices.

Warehouse, lake, and lakehouse

Warehouse

A data warehouse is optimized for governed analytical workloads and commonly exposes structured schemas and SQL. Performance depends on product, physical design, workload management, data quality, and query patterns; data is not automatically clean or trustworthy.

Data lake

A lake stores data in object or distributed storage for multiple processing patterns. “Store everything and decide later” is not governance. Ownership, cataloging, access, retention, quality, file layout, schema evolution, and lifecycle controls begin at ingestion.

Lakehouse

Lakehouse describes architectures adding table management and warehouse-like capabilities over lake storage. Implementations vary. A transaction layer does not create one source of truth or make BI and ML requirements identical. Evaluate concurrency, isolation, governance, latency, interoperability, maturity, and cost against separate or hybrid designs. See data architecture principles.

Select services by responsibility boundary

NIST describes three service models. Product labels overlap, so contracts and documentation—not analogies—determine who configures, patches, secures, backs up, monitors, and recovers each layer.

IaaS: customers provision compute, storage, and networking and control operating systems and applications, but not underlying infrastructure.
PaaS: customers deploy supported applications while providers manage the platform; customers still own code, data, identities, configuration, and application security.
SaaS: customers use a provider application and commonly retain responsibilities for identity, access, data, configuration, integration, retention, and lawful use.

Function services are often called FaaS or serverless. The label does not transfer every operational responsibility.

Design representative analytics workloads

A recommendation system may combine batch preparation, events, online inference, and experiments. Measure lift, latency, fallback, consent, bias, and cold-start behavior. A fraud system may score transactions and route uncertain cases, but geography does not prove fraud; measure false decisions, delay, calibration, investigation capacity, and recovery. Parallel cloud compute may shorten genomic workloads when software parallelizes and transfer and I/O are managed; it does not universally turn years into hours.

Measure unit economics

Establish allocation metadata, budgets, anomaly alerts, and units such as cost per query, pipeline run, terabyte processed, inference, or business outcome. Serverless billing can include requests, execution, scanned data, minimum capacity, storage, orchestration, networking, logs, and downstream services. Test representative workloads; optimize query plans and file layout; suspend idle capacity where supported; include engineering, transfer, resilience, support, and migration costs.

Lifecycle transitions must follow observed access, retention, retrieval latency, request charges, minimum-duration rules, and deletion duties—not an arbitrary 90-day rule.

Apply service-specific security

Provider/customer responsibility changes by service. Classify data and map identities, trust boundaries, flows, and administrative paths. Use least privilege, strong authentication, workload identities, short-lived credentials, encryption with deliberate key ownership and recovery, logs, detections, incident response, backup, and restore tests. A virtual private cloud is logically isolated; routes, gateways, endpoints, firewalls, identities, DNS, policies, and applications determine reachability.

Migrate as a controlled change

Inventory workloads, dependencies, owners, data, consumers, objectives, and obligations.
Benchmark current performance, cost, quality, reliability, and security.
Select a representative, reversible pilot and define exit criteria.
Test migration, reconciliation, rollback, restore, failover, and parallel operation.
Validate consumer results and decommission old paths only after retention and rollback windows.

Connect architecture to a data strategy framework and plan cutover using cloud migration challenges.

Originally published July 11, 2025; technically reviewed and substantially updated September 4, 2026.